From serguei.spitsyn at oracle.com Tue Oct 1 00:34:31 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 01 Oct 2013 00:34:31 -0700 Subject: RFR (S): JDK-8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes In-Reply-To: <5249643F.3030209@oracle.com> References: <5249643F.3030209@oracle.com> Message-ID: <524A7B07.1000300@oracle.com> Hi Frederik, Thank you for jumping on this issue! *src/share/vm/oops/instanceKlass.cpp* 2333 int src_index = 0; 2334 while (src_index < src_length) { 2335 dest[dest_index++] = src[src_index++]; 2336 } 2337 2338 // If we have a hash, append it 2339 if(hash_len > 0) { 2340 int hash_index = 0; 2341 while (hash_index < hash_len) { 2342 dest[dest_index++] = hash_buf[hash_index++]; 2343 } 2344 } The above can be simplified a little bit: // Add the actual class name for (int src_index = 0; src_index < src_length; ) { dest[dest_index++] = src[src_index++]; } // If we have a hash, append it for (int hash_index = 0; hash_index < hash_len; ) { dest[dest_index++] = hash_buf[hash_index++]; } The conditionif(hash_len > 0) is covered by the loop itself. Style-related comments: -wrong indent at the lines: 2316-2319 - need a space after the 'if' at the lines: 2315, 2339 *src/share/vm/prims/jvmtiGetLoadedClasses.cpp *The copyright comment must be up-to-date. The comments at the lines 35-38, 258-260 are not valid anymore. > In this review I still have an outstanding unanswered question about > the need to synchronize the access to the: > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); > and > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); This kind of walking is usually done at safepoint in a VM_Operation. You will find many examples in the jvmtiEnv.cpp, for instance, VM_GetAllStackTraces. The suggestion from Mikael is good too. Should this fix include the getClassLoaderClasses() as well? I'm still trying to realize the impact and consistency of this fix. :( What tests are you going to run for verification? Thanks, Serguei * *On 9/30/13 4:45 AM, Fredrik Arvidsson wrote: > Hi > > Please help me to review the changes below: > > Jira case: https://bugs.openjdk.java.net/browse/JDK-8024423 > Webrev: http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/ > > > In this review I still have an outstanding unanswered question about > the need to synchronize the access to the: > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); > and > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); > > calls in > http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/src/share/vm/prims/jvmtiGetLoadedClasses.cpp.udiff.html > > Please give me advise on this. > > There will be a review soon regarding re-enabling the tests that failed because of the above bug, see: > https://bugs.openjdk.java.net/browse/JDK-8025576 > > Cheers > /Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131001/4e739635/attachment.html From erik.joelsson at oracle.com Tue Oct 1 01:42:55 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 01 Oct 2013 10:42:55 +0200 Subject: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <523D144E.4000002@oracle.com> References: <523D144E.4000002@oracle.com> Message-ID: <524A8B0F.4070704@oracle.com> I have looked at the build changes in the root and jdk repos and they look OK. /Erik On 2013-09-21 05:36, Daniel D. Daugherty wrote: > Greetings, > > I have the initial support for Full Debug Symbols (FDS) on MacOS X done > and ready for review: > > 7165611 implement Full Debug Symbols on MacOS X hotspot > https://bugs.openjdk.java.net/browse/JDK-7165611 > > Here is the JDK8/HSX-25 webrev URL: > > OpenJDK: > http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ > Internal: > http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ > > This webrev includes changes for the follow repos: > > jdk8 > jdk8/hotspot > jdk8/jdk > jdk8/jdk/make/closed > > Once these changes are approved, I'm planning to push them to > RT_Baseline. From there, they can follow the normal path to > Main_Baseline and eventually JDK8. > > This work enables FDS on MacOS X for the 'hotspot' repo; the changes in > the other repos are necessary to support importing the .diz files from > the MacOS X 'hotspot' build into the forest build. I also fixed a few > FDS related errors in the magic incantations for the new build. This is > mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported > from Solaris. In other words, this is Frankenstein's monster... > > Thanks to Staffan Larsen for providing an initial set of changes > which I morphed into what you see here. > > Testing: > - JPRT HSX build and test on all platforms; verification of .diz > files in the MacOS X JPRT bundles > - JPRT JDK8 forest build and test on all platforms; verification of > .diz files in the MacOS X JPRT bundles > Note: In previous FDS changesets, I also did a standalone 'jdk' > repo build and test, but that no longer seems to work. > > As always, comments, questions and suggestions are welcome. > > Dan From jaroslav.bachorik at oracle.com Tue Oct 1 02:01:00 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 01 Oct 2013 11:01:00 +0200 Subject: RFR 6399961: The management agent doesn't support SSL keystore setup when loaded dynamically Message-ID: <524A8F4C.2000908@oracle.com> Hi, Currently it is not possible to configure SSL parameters when loading the management agent. The fix is to forward any javax.net.ssl.* properties to the target JVM. The javax.net.ssl.* properties provided in the agent configuration should never replace any javax.net.ssl.* properties defined by the target JVM. The issue: https://bugs.openjdk.java.net/browse/JDK-6399961 Webrev: http://cr.openjdk.java.net/~jbachorik/6399961/webrev.00 Thanks, -JB- From paul.sandoz at oracle.com Tue Oct 1 03:36:47 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 01 Oct 2013 10:36:47 +0000 Subject: hg: jdk8/tl/jdk: 8024408: Specifications for Collection/List/Set/SortedSet.spliterator() need to document if all the (subclass) instances are required to return SIZED spliterators Message-ID: <20131001103710.3BE6762C36@hg.openjdk.java.net> Changeset: f8b3ab514564 Author: psandoz Date: 2013-10-01 12:19 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8b3ab514564 8024408: Specifications for Collection/List/Set/SortedSet.spliterator() need to document if all the (subclass) instances are required to return SIZED spliterators Reviewed-by: alanb ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/SortedSet.java ! test/java/util/Spliterator/SpliteratorCharacteristics.java From dmitry.samersoff at oracle.com Tue Oct 1 04:51:46 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 01 Oct 2013 15:51:46 +0400 Subject: jmx-dev RFR 6399961: The management agent doesn't support SSL keystore setup when loaded dynamically In-Reply-To: <524A8F4C.2000908@oracle.com> References: <524A8F4C.2000908@oracle.com> Message-ID: <524AB752.2030900@oracle.com> Jaroslav, Agent.java: 99: As far as you intorduce SSL_PREFIX constant, please add one for "com.sun.management." 259: It's better to keep all property manipulations in agentmain and startRemoteManagementAgent - different methods to start Agent might have separate property set and scoping rules. Do you need to modify jcmd as well? -Dmitry On 2013-10-01 13:01, Jaroslav Bachorik wrote: > Hi, > > Currently it is not possible to configure SSL parameters when loading > the management agent. The fix is to forward any javax.net.ssl.* > properties to the target JVM. The javax.net.ssl.* properties provided in > the agent configuration should never replace any javax.net.ssl.* > properties defined by the target JVM. > > The issue: https://bugs.openjdk.java.net/browse/JDK-6399961 > Webrev: http://cr.openjdk.java.net/~jbachorik/6399961/webrev.00 > > Thanks, > > -JB- -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Tue Oct 1 04:59:00 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 01 Oct 2013 15:59:00 +0400 Subject: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <52498025.3040402@oracle.com> References: <523D144E.4000002@oracle.com> <52498025.3040402@oracle.com> Message-ID: <524AB904.4040406@oracle.com> Dan, Sorry, for later answer - was busy trying to run UTE on Mac. I can test non-darwin logic if you give me a link to workspace. -Dmitry On 2013-09-30 17:44, Daniel D. Daugherty wrote: > On 9/30/13 7:13 AM, Staffan Larsen wrote: >> First: thanks for doing this work - it will make debugging on os x so >> much easier! > > That's the plan... > > >> I'm not done with the review, but here are a couple of comments so far. >> >> I tried running with: >> >> $ sh ./configure --with-debug-level=slowdebug --disable-zip-debug-info >> $ make >> >> which results in: >> >> ## Starting hotspot >> ... >> make[5]: *** No rule to make target >> `/Users/staffan/mercurial/hotspot-rt-jdk/build/macosx-x86_64-normal-server-slowdebug/hotspot/dist/jre/lib/amd64/libjsig.dylib.dSYM', >> needed by `generic_export'. Stop. >> make[4]: *** [export_debug] Error 2 >> make[3]: *** [all_debug_universal] Error 2 >> make[2]: *** [universal_debug] Error 2 >> ... > > I'm presuming that you're trying with a forest that includes > closed repos. If so, then you'll need the jdk/make/closed change > in order for the build to work. > > >> Another comment: There are some makefile logic for BSD, non-darwin >> platforms. Have you had a chance to test this logic? >> (hotspot/make/bsd/makefiles/vm.make) > > No, I don't have access to a BSD (non-darwin) platform. However, I'll > be pinging Dmitri Samersoff to ask a few questions... > > >> Nit: hotspot/make/bsd/makefiles/vm.make: L345, L356: wrong indentation. > > These are make cmd lines: > > 344 else > 345 $(QUIETLY) $(OBJCOPY) --only-keep-debug $@ $(LIBJVM_DEBUGINFO) > 346 $(QUIETLY) $(OBJCOPY) > --add-gnu-debuglink=$(LIBJVM_DEBUGINFO) $@ > 347 ifeq ($(STRIP_POLICY),all_strip) > > so they have to be indented by a tab. Very ugly, but necessary. > > Dan > > >> >> >> /Staffan >> >> >> >> On 21 sep 2013, at 05:36, Daniel D. Daugherty >> wrote: >> >>> Greetings, >>> >>> I have the initial support for Full Debug Symbols (FDS) on MacOS X done >>> and ready for review: >>> >>> 7165611 implement Full Debug Symbols on MacOS X hotspot >>> https://bugs.openjdk.java.net/browse/JDK-7165611 >>> >>> Here is the JDK8/HSX-25 webrev URL: >>> >>> OpenJDK: >>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >>> Internal: >>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >>> >>> This webrev includes changes for the follow repos: >>> >>> jdk8 >>> jdk8/hotspot >>> jdk8/jdk >>> jdk8/jdk/make/closed >>> >>> Once these changes are approved, I'm planning to push them to >>> RT_Baseline. From there, they can follow the normal path to >>> Main_Baseline and eventually JDK8. >>> >>> This work enables FDS on MacOS X for the 'hotspot' repo; the changes in >>> the other repos are necessary to support importing the .diz files from >>> the MacOS X 'hotspot' build into the forest build. I also fixed a few >>> FDS related errors in the magic incantations for the new build. This is >>> mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported >>> from Solaris. In other words, this is Frankenstein's monster... >>> >>> Thanks to Staffan Larsen for providing an initial set of changes >>> which I morphed into what you see here. >>> >>> Testing: >>> - JPRT HSX build and test on all platforms; verification of .diz >>> files in the MacOS X JPRT bundles >>> - JPRT JDK8 forest build and test on all platforms; verification of >>> .diz files in the MacOS X JPRT bundles >>> Note: In previous FDS changesets, I also did a standalone 'jdk' >>> repo build and test, but that no longer seems to work. >>> >>> As always, comments, questions and suggestions are welcome. >>> >>> Dan > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From sundararajan.athijegannathan at oracle.com Tue Oct 1 05:14:30 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 01 Oct 2013 12:14:30 +0000 Subject: hg: jdk8/tl/nashorn: 8 new changesets Message-ID: <20131001121439.29E8762C3A@hg.openjdk.java.net> Changeset: 2016a6b9e1f3 Author: hannesw Date: 2013-09-27 16:59 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2016a6b9e1f3 8025515: Performance issues with Source.getLine() Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/Source.java + test/script/basic/JDK-8025515.js Changeset: 1809c9e97c71 Author: hannesw Date: 2013-09-27 17:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1809c9e97c71 8025520: Array.prototype.slice should only copy defined elements Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8025520.js Changeset: efc40aacaee4 Author: hannesw Date: 2013-09-30 15:54 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/efc40aacaee4 8025589: Array.prototype.shift should only copy defined elements in generic mode Reviewed-by: sundar, attila ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8025589.js Changeset: ad5f9ce2a95b Author: jlaskey Date: 2013-09-30 10:24 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ad5f9ce2a95b Merge Changeset: 787e36fdf69a Author: jlaskey Date: 2013-09-30 12:06 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/787e36fdf69a Merge Changeset: 7272ec90f2c6 Author: sundar Date: 2013-09-30 21:33 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7272ec90f2c6 8025629: load function should support a way to load scripts from classpath Reviewed-by: lagergren, hannesw, attila ! make/build.xml ! src/jdk/nashorn/internal/runtime/Context.java + test/script/trusted/JDK-8025629.js + test/src/jdk/nashorn/internal/runtime/resources/load_test.js Changeset: f5aefbe76cec Author: jlaskey Date: 2013-09-30 18:09 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f5aefbe76cec 8025689: fx:base.js classes not loading Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/resources/fx/base.js Changeset: cd7fb58043cb Author: sundar Date: 2013-10-01 14:38 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/cd7fb58043cb 8025488: Error.captureStackTrace should not format error stack Reviewed-by: hannesw, attila ! src/jdk/nashorn/internal/objects/NativeError.java + test/script/basic/JDK-8025488.js + test/script/basic/JDK-8025488.js.EXPECTED From jaroslav.bachorik at oracle.com Tue Oct 1 06:03:35 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 01 Oct 2013 15:03:35 +0200 Subject: jmx-dev RFR 6399961: The management agent doesn't support SSL keystore setup when loaded dynamically In-Reply-To: <524AB752.2030900@oracle.com> References: <524A8F4C.2000908@oracle.com> <524AB752.2030900@oracle.com> Message-ID: <524AC827.9000301@oracle.com> Ok, thanks everyone for taking time reviewing this. Dmitry's comment about jcmd got me looking at the properties available when using the jcmd to start the management agent. It turns out that "com.sun.management.jmxremote.ssl.config.file" allows exactly the thing this issue talks about. So, please, disregard this change completely. Cheers, -JB- On 1.10.2013 13:51, Dmitry Samersoff wrote: > Jaroslav, > > Agent.java: > > 99: > > As far as you intorduce SSL_PREFIX constant, please add one for > "com.sun.management." > > 259: > > It's better to keep all property manipulations in agentmain and > startRemoteManagementAgent - different methods to start Agent might have > separate property set and scoping rules. > > Do you need to modify jcmd as well? > > -Dmitry > > > On 2013-10-01 13:01, Jaroslav Bachorik wrote: >> Hi, >> >> Currently it is not possible to configure SSL parameters when loading >> the management agent. The fix is to forward any javax.net.ssl.* >> properties to the target JVM. The javax.net.ssl.* properties provided in >> the agent configuration should never replace any javax.net.ssl.* >> properties defined by the target JVM. >> >> The issue: https://bugs.openjdk.java.net/browse/JDK-6399961 >> Webrev: http://cr.openjdk.java.net/~jbachorik/6399961/webrev.00 >> >> Thanks, >> >> -JB- > > From alexander.zuev at oracle.com Tue Oct 1 06:04:14 2013 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 01 Oct 2013 13:04:14 +0000 Subject: hg: jdk8/tl/langtools: 7118749: NPE in CreateSymbols caused by bad diagnostic Message-ID: <20131001130418.B759762C3C@hg.openjdk.java.net> Changeset: 1a3e8347f3dd Author: kizune Date: 2013-10-01 17:03 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1a3e8347f3dd 7118749: NPE in CreateSymbols caused by bad diagnostic Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java From david.holmes at oracle.com Tue Oct 1 06:15:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 01 Oct 2013 23:15:07 +1000 Subject: JDK-6989981: jstack causes "fatal error: ExceptionMark destructor expects no pending exceptions" In-Reply-To: <3FE7CB8E-39F4-4915-B82E-AC2F88715189@oracle.com> References: <523C264E.7060704@ysfactory.dip.jp> <97D9FB54-FFF1-4337-942A-E7FE2196A354@oracle.com> <523C534C.7060908@ysfactory.dip.jp> <9367FE2B-C709-4273-BEAE-745841846560@oracle.com> <523C5A8A.8060000@ysfactory.dip.jp> <523C606B.5060204@ysfactory.dip.jp> <952F096A-69D2-4E7C-B979-91E95AFE37F8@oracle.com> <523D786C.5090605@ysfactory.dip.jp> <523EAF7C.3050000@oracle.com> <3FE7CB8E-39F4-4915-B82E-AC2F88715189@oracle.com> Message-ID: <524ACADB.3060600@oracle.com> On 23/09/2013 2:41 AM, Staffan Larsen wrote: > Dmitry: Thanks for the review. > > Yasumasa: Thanks for your contribution! I have pushed the changes into HS25 and will push them to 7u60 as well. I've been on vacation so could not respond in time. I am concerned about this fix. Other than printing a message on the console it pretends that the init has succeeded! That seems wrong to me. What are the consequences of doing this? David ----- > /Staffan > > On 22 sep 2013, at 01:51, Dmitry Samersoff wrote: > >> Yasumasa, >> >> Looks good for me. >> >> -Dmitry >> >> On 2013-09-21 14:43, Yasumasa Suenaga wrote: >>> Hi Staffan, >>> >>>> Can you update your patch, please? >>> >>> Of course! >>> I've attached new patch in this email. >>> >>> Could you check this? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> On 2013/09/21 15:36, Staffan Larsen wrote: >>>> >>>> >>>>> On 20 sep 2013, at 16:49, Yasumasa Suenaga >>>>> wrote: >>>>> >>>>>> On 2013/09/20 23:34, Staffan Larsen wrote: >>>>>> >>>>>>> On 20 sep 2013, at 16:24, Yasumasa Suenaga >>>>>>> wrote: >>>>>>> >>>>>>> I thought your code too. However... >>>>>>> >>>>>>> - These code is different from other code (rule?). >>>>>> >>>>>> Well, you are introducing a new macro that is also different from >>>>>> other code, so I'm not sure how valid that argument is. >>>>> >>>>> My macro is modified from "CATCH" in exceptions.hpp: >>>>> >>>>> #define CATCH \ >>>>> THREAD); if (HAS_PENDING_EXCEPTION) { \ >>>>> oop ex = PENDING_EXCEPTION; \ >>>>> CLEAR_PENDING_EXCEPTION; \ >>>>> ex->print(); \ >>>>> ShouldNotReachHere(); \ >>>>> } (void)(0 >>>>> >>>>> So I think that my macro is not big difference fromother code. >>>>> >>>>> >>>>>>> - Similar crash cases exist. e.g. 6425580 and 7142442. >>>>>>> These crashes are different from 6989981. However, I guess that >>>>>>> crashed >>>>>>> thread had pending exception and we need to fix with similar patch. >>>>>>> >>>>>>> So I think that new macro is useful later. >>>>>> >>>>>> Yes, similar problems may come up in other cases as well. >>>>>> >>>>>> Generally, I don't think it's a good idea to have logging calls >>>>>> hidden away in general macros. What we really should do here is >>>>>> print some context around the stack trace as well. Something like: >>>>>> >>>>>> Initializing the attach listener failed with the following >>>>>> exception in AttachListener::init when initializing the thread_oop: >>>>>> >>>>>> This would be possible with the code I suggested, but very hard in a >>>>>> general macro. >>>>> >>>>> Agree. >>>>> Should we write code as following? >>>>> >>>>> if (HAS_PENDING_EXCEPTION) { >>>>> tty->print_cr("Exception in VM (AttachListener::init) : "); >>>>> java_lang_Throwable::print(PENDING_EXCEPTION, tty); >>>>> CLEAR_PENDING_EXCEPTION; >>>>> return; >>>>> } >>>>> >>>>> I like this way :-) >>>> >>>> Yes, this is what I'd like to see! Can you update your patch, please? >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>>> On 2013/09/20 23:05, Staffan Larsen wrote: >>>>>>>> I see. CHECK_AND_CLEAR_AND_PRINT? Just kidding... :-) >>>>>>>> >>>>>>>> Maybe in this case we should not have this as a macro, but >>>>>>>> actually add the code after the two calls to call_special? >>>>>>>> Something like the code below. I personally think this is more >>>>>>>> readable than obscure macros that I have to go look up to >>>>>>>> understand what they do. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> /Staffan >>>>>>>> >>>>>>>> JavaCalls::call_special(&result, thread_oop, >>>>>>>> klass, >>>>>>>> vmSymbols::object_initializer_name(), >>>>>>>> >>>>>>>> vmSymbols::threadgroup_string_void_signature(), >>>>>>>> thread_group, >>>>>>>> string, >>>>>>>> THREAD); >>>>>>>> >>>>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>>>> java_lang_Throwable::print(PENDING_EXCEPTION, tty); >>>>>>>> CLEAR_PENDING_EXCEPTION; >>>>>>>> return; >>>>>>>> } >>>>>>>> >>>>>>>> KlassHandle group(THREAD, SystemDictionary::ThreadGroup_klass()); >>>>>>>> JavaCalls::call_special(&result, >>>>>>>> thread_group, >>>>>>>> group, >>>>>>>> vmSymbols::add_method_name(), >>>>>>>> vmSymbols::thread_void_signature(), >>>>>>>> thread_oop, // ARG 1 >>>>>>>> THREAD); >>>>>>>> >>>>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>>>> java_lang_Throwable::print(PENDING_EXCEPTION, tty); >>>>>>>> CLEAR_PENDING_EXCEPTION; >>>>>>>> return; >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 20 sep 2013, at 15:53, Yasumasa >>>>>>>>> Suenaga wrote: >>>>>>>>> >>>>>>>>> Hi Staffan, >>>>>>>>> >>>>>>>>> Thank you for your sponsoring! >>>>>>>>> >>>>>>>>> "CHECK_AND_CLEAR" is already defined in exceptions.hpp: >>>>>>>>> ****************** >>>>>>>>> #define CHECK_AND_CLEAR THREAD); if >>>>>>>>> (HAS_PENDING_EXCEPTION) { CLEAR_PENDING_EXCEPTION; return; >>>>>>>>> } (void)(0 >>>>>>>>> ****************** >>>>>>>>> >>>>>>>>> I think that user wants why serviceability tools are failed. >>>>>>>>> So I defined "CHECK_AND_CLEAR" + java_lang_Throwable::print() as >>>>>>>>> "CATCH_AND_RETURN" . >>>>>>>>> >>>>>>>>> >>>>>>>>> I agree rename this macro. >>>>>>>>> Do you have any idea? I don't have a good name :-) >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>>> On 2013/09/20 20:10, Staffan Larsen wrote: >>>>>>>>>> Yasuma, >>>>>>>>>> >>>>>>>>>> Thanks for finding and fixing this! I have re-opened the bug. >>>>>>>>>> Your patch looks good to me, but perhaps CATCH_AND_RETURN should >>>>>>>>>> be renamed CHECK_AND_CLEAR? >>>>>>>>>> >>>>>>>>>> I can sponsor the fix. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> /Staffan >>>>>>>>>> >>>>>>>>>>> On 20 sep 2013, at 12:41, Yasumasa >>>>>>>>>>> Suenaga wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I encountered this bug: >>>>>>>>>>> JDK-6989981: jstack causes "fatal error: ExceptionMark >>>>>>>>>>> destructor expects no pending exceptions" >>>>>>>>>>> >>>>>>>>>>> I read hs_err and attachListener.cpp, Java heap usage is very >>>>>>>>>>> high and >>>>>>>>>>> it could be OutOfMemoryError in AttachListener::init() . >>>>>>>>>>> >>>>>>>>>>> If JavaCalls::call_special() in AttachListener::init() fail >>>>>>>>>>> which is >>>>>>>>>>> caused by OOME, d'tor of EXCEPTION_MARK (~ExceptionMark) will >>>>>>>>>>> generate >>>>>>>>>>> internal error. >>>>>>>>>>> >>>>>>>>>>> So I make a patch for avoiding crash and attached in this email >>>>>>>>>>> (6989981.patch) . >>>>>>>>>>> I'd like to re-open this bug and contribute my patch. >>>>>>>>>>> Could you help me? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --- DETAILS --- >>>>>>>>>>> CHECK macro is used in JavaCalls::call_special() . >>>>>>>>>>> >>>>>>>>>>> ****************** >>>>>>>>>>> void AttachListener::init() { >>>>>>>>>>> EXCEPTION_MARK; >>>>>>>>>>> >>>>>>>>>>> : >>>>>>>>>>> >>>>>>>>>>> // Initialize thread_oop to put it into the system threadGroup >>>>>>>>>>> Handle thread_group (THREAD, Universe::system_thread_group()); >>>>>>>>>>> JavaValue result(T_VOID); >>>>>>>>>>> JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>> klass, >>>>>>>>>>> vmSymbols::object_initializer_name(), >>>>>>>>>>> >>>>>>>>>>> vmSymbols::threadgroup_string_void_signature(), >>>>>>>>>>> thread_group, >>>>>>>>>>> string, >>>>>>>>>>> CHECK); >>>>>>>>>>> >>>>>>>>>>> KlassHandle group(THREAD, >>>>>>>>>>> SystemDictionary::ThreadGroup_klass()); >>>>>>>>>>> JavaCalls::call_special(&result, >>>>>>>>>>> thread_group, >>>>>>>>>>> group, >>>>>>>>>>> vmSymbols::add_method_name(), >>>>>>>>>>> vmSymbols::thread_void_signature(), >>>>>>>>>>> thread_oop, // ARG 1 >>>>>>>>>>> CHECK); >>>>>>>>>>> ****************** >>>>>>>>>>> >>>>>>>>>>> CHECK macro does not clear pending exception of current thread. >>>>>>>>>>> So call_special() fails with runtime exception, d'tor of >>>>>>>>>>> ExceptionMark >>>>>>>>>>> generates fatal error. >>>>>>>>>>> >>>>>>>>>>> ****************** >>>>>>>>>>> ExceptionMark::~ExceptionMark() { >>>>>>>>>>> if (_thread->has_pending_exception()) { >>>>>>>>>>> Handle exception(_thread, _thread->pending_exception()); >>>>>>>>>>> _thread->clear_pending_exception(); // Needed to avoid >>>>>>>>>>> infinite recursion >>>>>>>>>>> if (is_init_completed()) { >>>>>>>>>>> exception->print(); >>>>>>>>>>> fatal("ExceptionMark destructor expects no pending >>>>>>>>>>> exceptions"); >>>>>>>>>>> } else { >>>>>>>>>>> vm_exit_during_initialization(exception); >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> ****************** >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --- HOW TO REPRODUCE --- >>>>>>>>>>> I also crate testcase of this issue (testcase.tar.gz) . This >>>>>>>>>>> testcase contains >>>>>>>>>>> two modules. >>>>>>>>>>> >>>>>>>>>>> - jvmti: JVMTI agent for this issue. This agent traps SIGQUIT and >>>>>>>>>>> calls original (in HotSpot) SIGQUIT handler. >>>>>>>>>>> This signal handler is invoked, MethodEntry event >>>>>>>>>>> callback is >>>>>>>>>>> enabled. MethodEntry generates OutOfMemoryError. >>>>>>>>>>> >>>>>>>>>>> - java : Simple long sleep program. >>>>>>>>>>> >>>>>>>>>>> I can run this testcase in Fedora18 x86_64. See below. >>>>>>>>>>> >>>>>>>>>>> ------- >>>>>>>>>>> $ javac java/LongSleep.java >>>>>>>>>>> $ make -C jvmti >>>>>>>>>>> make: Entering directory >>>>>>>>>>> `/data/share/patch/ExceptionMark/testcase/jvmti' >>>>>>>>>>> gcc -I/usr/lib/jvm/java-openjdk/include >>>>>>>>>>> -I/usr/lib/jvm/java-openjdk/include/linux -fPIC -c oome.c >>>>>>>>>>> gcc -shared -o liboome.so oome.o >>>>>>>>>>> make: Leaving directory >>>>>>>>>>> `/data/share/patch/ExceptionMark/testcase/jvmti' >>>>>>>>>>> $ export JAVA_HOME= >>>>>>>>>>> $ ./test.sh >>>>>>>>>>> ------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> <6989981.patch> >>>>> >>>> >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the source code. > From dmitry.degrave at oracle.com Tue Oct 1 06:46:40 2013 From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com) Date: Tue, 01 Oct 2013 13:46:40 +0000 Subject: hg: jdk8/tl/jaxp: 8024707: TransformerException : item() return null with node list of length != 1 Message-ID: <20131001134642.F253262C3E@hg.openjdk.java.net> Changeset: 84a2b2ee6fc6 Author: aefimov Date: 2013-10-01 17:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/84a2b2ee6fc6 8024707: TransformerException : item() return null with node list of length != 1 Reviewed-by: joehw, lancea ! src/com/sun/org/apache/xml/internal/dtm/ref/DTMAxisIterNodeList.java From dmitry.degrave at oracle.com Tue Oct 1 06:47:11 2013 From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com) Date: Tue, 01 Oct 2013 13:47:11 +0000 Subject: hg: jdk8/tl/jdk: 8024707: TransformerException : item() return null with node list of length != 1 Message-ID: <20131001134724.E31CE62C3F@hg.openjdk.java.net> Changeset: bf52ea6bd9eb Author: aefimov Date: 2013-10-01 17:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf52ea6bd9eb 8024707: TransformerException : item() return null with node list of length != 1 Reviewed-by: joehw, lancea + test/javax/xml/jaxp/parsers/8024707/TestFunc.java + test/javax/xml/jaxp/parsers/8024707/XSLT.java + test/javax/xml/jaxp/parsers/8024707/in.xml + test/javax/xml/jaxp/parsers/8024707/test.xsl From daniel.daugherty at oracle.com Tue Oct 1 06:48:10 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 01 Oct 2013 07:48:10 -0600 Subject: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <524A8B0F.4070704@oracle.com> References: <523D144E.4000002@oracle.com> <524A8B0F.4070704@oracle.com> Message-ID: <524AD29A.3030806@oracle.com> Thanks (again). You previously posted a review for the OpenJDK side on 2013.09.23... :-) Dan On 10/1/13 2:42 AM, Erik Joelsson wrote: > I have looked at the build changes in the root and jdk repos and they > look OK. > > /Erik > > On 2013-09-21 05:36, Daniel D. Daugherty wrote: >> Greetings, >> >> I have the initial support for Full Debug Symbols (FDS) on MacOS X done >> and ready for review: >> >> 7165611 implement Full Debug Symbols on MacOS X hotspot >> https://bugs.openjdk.java.net/browse/JDK-7165611 >> >> Here is the JDK8/HSX-25 webrev URL: >> >> OpenJDK: >> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >> Internal: >> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >> >> This webrev includes changes for the follow repos: >> >> jdk8 >> jdk8/hotspot >> jdk8/jdk >> jdk8/jdk/make/closed >> >> Once these changes are approved, I'm planning to push them to >> RT_Baseline. From there, they can follow the normal path to >> Main_Baseline and eventually JDK8. >> >> This work enables FDS on MacOS X for the 'hotspot' repo; the changes in >> the other repos are necessary to support importing the .diz files from >> the MacOS X 'hotspot' build into the forest build. I also fixed a few >> FDS related errors in the magic incantations for the new build. This is >> mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported >> from Solaris. In other words, this is Frankenstein's monster... >> >> Thanks to Staffan Larsen for providing an initial set of changes >> which I morphed into what you see here. >> >> Testing: >> - JPRT HSX build and test on all platforms; verification of .diz >> files in the MacOS X JPRT bundles >> - JPRT JDK8 forest build and test on all platforms; verification of >> .diz files in the MacOS X JPRT bundles >> Note: In previous FDS changesets, I also did a standalone 'jdk' >> repo build and test, but that no longer seems to work. >> >> As always, comments, questions and suggestions are welcome. >> >> Dan > From yasu at ysfactory.dip.jp Tue Oct 1 07:11:27 2013 From: yasu at ysfactory.dip.jp (Yasumasa Suenaga) Date: Tue, 01 Oct 2013 23:11:27 +0900 Subject: JDK-6989981: jstack causes "fatal error: ExceptionMark destructor expects no pending exceptions" In-Reply-To: <524ACADB.3060600@oracle.com> References: <523C264E.7060704@ysfactory.dip.jp> <97D9FB54-FFF1-4337-942A-E7FE2196A354@oracle.com> <523C534C.7060908@ysfactory.dip.jp> <9367FE2B-C709-4273-BEAE-745841846560@oracle.com> <523C5A8A.8060000@ysfactory.dip.jp> <523C606B.5060204@ysfactory.dip.jp> <952F096A-69D2-4E7C-B979-91E95AFE37F8@oracle.com> <523D786C.5090605@ysfactory.dip.jp> <523EAF7C.3050000@oracle.com> <3FE7CB8E-39F4-4915-B82E-AC2F88715189@oracle.com> <524ACADB.3060600@oracle.com> Message-ID: <524AD80F.2020308@ysfactory.dip.jp> Hi David, > Other than printing a message on the console it pretends that the init has succeeded! No. signal_thread_entry() @ hotspot/src/share/vm/runtime/os.cpp -------- 250 case SIGBREAK: { 251 // Check if the signal is a trigger to start the Attach Listener - in that 252 // case don't print stack traces. 253 if (!DisableAttachMechanism && AttachListener::is_init_trigger()) { 254 continue; 255 } -------- AttachListener::init() is called through is_init_trigger() (line 505). AttachListener::is_init_trigger() @ hotspot/src/share/vm/services/attachListener.cpp -------- 501 if (ret == 0) { 502 // simple check to avoid starting the attach mechanism when 503 // a bogus user creates the file 504 if (st.st_uid == geteuid()) { 505 init(); 506 return true; 507 } 508 } -------- If exception occurs in AttachListner::init(), AttachListner::is_init_trigger() returns "true" . Process of SIGBREAK handler will be stopped (caused by continue statement) and signal_thread_entry() will return top of loop. In my patch, pending exception which occurs in AttachListener initialization is cleared. Thus Signal Dispatcher has no damage. > What are the consequences of doing this? If AttachListener::init() cannot work due to exception, it cannot create UNIX domain socket to accept from java tools (e.g. jstack) . Target VM which tried to invoke AttachListner continues to run. (However, runtime exception such as OOME occurs, target VM will be stopped immediately :-) On the other hand, java tools which tried to attach target VM will fail because it cannot connect UNIX domain socket. Please run my testcase. It's actual behavior. Thanks, Yasumasa On 2013/10/01 22:15, David Holmes wrote: > On 23/09/2013 2:41 AM, Staffan Larsen wrote: >> Dmitry: Thanks for the review. >> >> Yasumasa: Thanks for your contribution! I have pushed the changes into HS25 and will push them to 7u60 as well. > > I've been on vacation so could not respond in time. I am concerned about this fix. Other than printing a message on the console it pretends that the init has succeeded! That seems wrong to me. What are the consequences of doing this? > > David > ----- > >> /Staffan >> >> On 22 sep 2013, at 01:51, Dmitry Samersoff wrote: >> >>> Yasumasa, >>> >>> Looks good for me. >>> >>> -Dmitry >>> >>> On 2013-09-21 14:43, Yasumasa Suenaga wrote: >>>> Hi Staffan, >>>> >>>>> Can you update your patch, please? >>>> >>>> Of course! >>>> I've attached new patch in this email. >>>> >>>> Could you check this? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> On 2013/09/21 15:36, Staffan Larsen wrote: >>>>> >>>>> >>>>>> On 20 sep 2013, at 16:49, Yasumasa Suenaga >>>>>> wrote: >>>>>> >>>>>>> On 2013/09/20 23:34, Staffan Larsen wrote: >>>>>>> >>>>>>>> On 20 sep 2013, at 16:24, Yasumasa Suenaga >>>>>>>> wrote: >>>>>>>> >>>>>>>> I thought your code too. However... >>>>>>>> >>>>>>>> - These code is different from other code (rule?). >>>>>>> >>>>>>> Well, you are introducing a new macro that is also different from >>>>>>> other code, so I'm not sure how valid that argument is. >>>>>> >>>>>> My macro is modified from "CATCH" in exceptions.hpp: >>>>>> >>>>>> #define CATCH \ >>>>>> THREAD); if (HAS_PENDING_EXCEPTION) { \ >>>>>> oop ex = PENDING_EXCEPTION; \ >>>>>> CLEAR_PENDING_EXCEPTION; \ >>>>>> ex->print(); \ >>>>>> ShouldNotReachHere(); \ >>>>>> } (void)(0 >>>>>> >>>>>> So I think that my macro is not big difference fromother code. >>>>>> >>>>>> >>>>>>>> - Similar crash cases exist. e.g. 6425580 and 7142442. >>>>>>>> These crashes are different from 6989981. However, I guess that >>>>>>>> crashed >>>>>>>> thread had pending exception and we need to fix with similar patch. >>>>>>>> >>>>>>>> So I think that new macro is useful later. >>>>>>> >>>>>>> Yes, similar problems may come up in other cases as well. >>>>>>> >>>>>>> Generally, I don't think it's a good idea to have logging calls >>>>>>> hidden away in general macros. What we really should do here is >>>>>>> print some context around the stack trace as well. Something like: >>>>>>> >>>>>>> Initializing the attach listener failed with the following >>>>>>> exception in AttachListener::init when initializing the thread_oop: >>>>>>> >>>>>>> This would be possible with the code I suggested, but very hard in a >>>>>>> general macro. >>>>>> >>>>>> Agree. >>>>>> Should we write code as following? >>>>>> >>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>> tty->print_cr("Exception in VM (AttachListener::init) : "); >>>>>> java_lang_Throwable::print(PENDING_EXCEPTION, tty); >>>>>> CLEAR_PENDING_EXCEPTION; >>>>>> return; >>>>>> } >>>>>> >>>>>> I like this way :-) >>>>> >>>>> Yes, this is what I'd like to see! Can you update your patch, please? >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>>> On 2013/09/20 23:05, Staffan Larsen wrote: >>>>>>>>> I see. CHECK_AND_CLEAR_AND_PRINT? Just kidding... :-) >>>>>>>>> >>>>>>>>> Maybe in this case we should not have this as a macro, but >>>>>>>>> actually add the code after the two calls to call_special? >>>>>>>>> Something like the code below. I personally think this is more >>>>>>>>> readable than obscure macros that I have to go look up to >>>>>>>>> understand what they do. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>> JavaCalls::call_special(&result, thread_oop, >>>>>>>>> klass, >>>>>>>>> vmSymbols::object_initializer_name(), >>>>>>>>> >>>>>>>>> vmSymbols::threadgroup_string_void_signature(), >>>>>>>>> thread_group, >>>>>>>>> string, >>>>>>>>> THREAD); >>>>>>>>> >>>>>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>>>>> java_lang_Throwable::print(PENDING_EXCEPTION, tty); >>>>>>>>> CLEAR_PENDING_EXCEPTION; >>>>>>>>> return; >>>>>>>>> } >>>>>>>>> >>>>>>>>> KlassHandle group(THREAD, SystemDictionary::ThreadGroup_klass()); >>>>>>>>> JavaCalls::call_special(&result, >>>>>>>>> thread_group, >>>>>>>>> group, >>>>>>>>> vmSymbols::add_method_name(), >>>>>>>>> vmSymbols::thread_void_signature(), >>>>>>>>> thread_oop, // ARG 1 >>>>>>>>> THREAD); >>>>>>>>> >>>>>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>>>>> java_lang_Throwable::print(PENDING_EXCEPTION, tty); >>>>>>>>> CLEAR_PENDING_EXCEPTION; >>>>>>>>> return; >>>>>>>>> } >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 20 sep 2013, at 15:53, Yasumasa >>>>>>>>>> Suenaga wrote: >>>>>>>>>> >>>>>>>>>> Hi Staffan, >>>>>>>>>> >>>>>>>>>> Thank you for your sponsoring! >>>>>>>>>> >>>>>>>>>> "CHECK_AND_CLEAR" is already defined in exceptions.hpp: >>>>>>>>>> ****************** >>>>>>>>>> #define CHECK_AND_CLEAR THREAD); if >>>>>>>>>> (HAS_PENDING_EXCEPTION) { CLEAR_PENDING_EXCEPTION; return; >>>>>>>>>> } (void)(0 >>>>>>>>>> ****************** >>>>>>>>>> >>>>>>>>>> I think that user wants why serviceability tools are failed. >>>>>>>>>> So I defined "CHECK_AND_CLEAR" + java_lang_Throwable::print() as >>>>>>>>>> "CATCH_AND_RETURN" . >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I agree rename this macro. >>>>>>>>>> Do you have any idea? I don't have a good name :-) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>>> On 2013/09/20 20:10, Staffan Larsen wrote: >>>>>>>>>>> Yasuma, >>>>>>>>>>> >>>>>>>>>>> Thanks for finding and fixing this! I have re-opened the bug. >>>>>>>>>>> Your patch looks good to me, but perhaps CATCH_AND_RETURN should >>>>>>>>>>> be renamed CHECK_AND_CLEAR? >>>>>>>>>>> >>>>>>>>>>> I can sponsor the fix. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> /Staffan >>>>>>>>>>> >>>>>>>>>>>> On 20 sep 2013, at 12:41, Yasumasa >>>>>>>>>>>> Suenaga wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I encountered this bug: >>>>>>>>>>>> JDK-6989981: jstack causes "fatal error: ExceptionMark >>>>>>>>>>>> destructor expects no pending exceptions" >>>>>>>>>>>> >>>>>>>>>>>> I read hs_err and attachListener.cpp, Java heap usage is very >>>>>>>>>>>> high and >>>>>>>>>>>> it could be OutOfMemoryError in AttachListener::init() . >>>>>>>>>>>> >>>>>>>>>>>> If JavaCalls::call_special() in AttachListener::init() fail >>>>>>>>>>>> which is >>>>>>>>>>>> caused by OOME, d'tor of EXCEPTION_MARK (~ExceptionMark) will >>>>>>>>>>>> generate >>>>>>>>>>>> internal error. >>>>>>>>>>>> >>>>>>>>>>>> So I make a patch for avoiding crash and attached in this email >>>>>>>>>>>> (6989981.patch) . >>>>>>>>>>>> I'd like to re-open this bug and contribute my patch. >>>>>>>>>>>> Could you help me? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> --- DETAILS --- >>>>>>>>>>>> CHECK macro is used in JavaCalls::call_special() . >>>>>>>>>>>> >>>>>>>>>>>> ****************** >>>>>>>>>>>> void AttachListener::init() { >>>>>>>>>>>> EXCEPTION_MARK; >>>>>>>>>>>> >>>>>>>>>>>> : >>>>>>>>>>>> >>>>>>>>>>>> // Initialize thread_oop to put it into the system threadGroup >>>>>>>>>>>> Handle thread_group (THREAD, Universe::system_thread_group()); >>>>>>>>>>>> JavaValue result(T_VOID); >>>>>>>>>>>> JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>> klass, >>>>>>>>>>>> vmSymbols::object_initializer_name(), >>>>>>>>>>>> >>>>>>>>>>>> vmSymbols::threadgroup_string_void_signature(), >>>>>>>>>>>> thread_group, >>>>>>>>>>>> string, >>>>>>>>>>>> CHECK); >>>>>>>>>>>> >>>>>>>>>>>> KlassHandle group(THREAD, >>>>>>>>>>>> SystemDictionary::ThreadGroup_klass()); >>>>>>>>>>>> JavaCalls::call_special(&result, >>>>>>>>>>>> thread_group, >>>>>>>>>>>> group, >>>>>>>>>>>> vmSymbols::add_method_name(), >>>>>>>>>>>> vmSymbols::thread_void_signature(), >>>>>>>>>>>> thread_oop, // ARG 1 >>>>>>>>>>>> CHECK); >>>>>>>>>>>> ****************** >>>>>>>>>>>> >>>>>>>>>>>> CHECK macro does not clear pending exception of current thread. >>>>>>>>>>>> So call_special() fails with runtime exception, d'tor of >>>>>>>>>>>> ExceptionMark >>>>>>>>>>>> generates fatal error. >>>>>>>>>>>> >>>>>>>>>>>> ****************** >>>>>>>>>>>> ExceptionMark::~ExceptionMark() { >>>>>>>>>>>> if (_thread->has_pending_exception()) { >>>>>>>>>>>> Handle exception(_thread, _thread->pending_exception()); >>>>>>>>>>>> _thread->clear_pending_exception(); // Needed to avoid >>>>>>>>>>>> infinite recursion >>>>>>>>>>>> if (is_init_completed()) { >>>>>>>>>>>> exception->print(); >>>>>>>>>>>> fatal("ExceptionMark destructor expects no pending >>>>>>>>>>>> exceptions"); >>>>>>>>>>>> } else { >>>>>>>>>>>> vm_exit_during_initialization(exception); >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> ****************** >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> --- HOW TO REPRODUCE --- >>>>>>>>>>>> I also crate testcase of this issue (testcase.tar.gz) . This >>>>>>>>>>>> testcase contains >>>>>>>>>>>> two modules. >>>>>>>>>>>> >>>>>>>>>>>> - jvmti: JVMTI agent for this issue. This agent traps SIGQUIT and >>>>>>>>>>>> calls original (in HotSpot) SIGQUIT handler. >>>>>>>>>>>> This signal handler is invoked, MethodEntry event >>>>>>>>>>>> callback is >>>>>>>>>>>> enabled. MethodEntry generates OutOfMemoryError. >>>>>>>>>>>> >>>>>>>>>>>> - java : Simple long sleep program. >>>>>>>>>>>> >>>>>>>>>>>> I can run this testcase in Fedora18 x86_64. See below. >>>>>>>>>>>> >>>>>>>>>>>> ------- >>>>>>>>>>>> $ javac java/LongSleep.java >>>>>>>>>>>> $ make -C jvmti >>>>>>>>>>>> make: Entering directory >>>>>>>>>>>> `/data/share/patch/ExceptionMark/testcase/jvmti' >>>>>>>>>>>> gcc -I/usr/lib/jvm/java-openjdk/include >>>>>>>>>>>> -I/usr/lib/jvm/java-openjdk/include/linux -fPIC -c oome.c >>>>>>>>>>>> gcc -shared -o liboome.so oome.o >>>>>>>>>>>> make: Leaving directory >>>>>>>>>>>> `/data/share/patch/ExceptionMark/testcase/jvmti' >>>>>>>>>>>> $ export JAVA_HOME= >>>>>>>>>>>> $ ./test.sh >>>>>>>>>>>> ------- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> <6989981.patch> >>>>>> >>>>> >>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the source code. >> > From staffan.larsen at oracle.com Tue Oct 1 07:32:26 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 1 Oct 2013 16:32:26 +0200 Subject: JDK-6989981: jstack causes "fatal error: ExceptionMark destructor expects no pending exceptions" In-Reply-To: <524ACADB.3060600@oracle.com> References: <523C264E.7060704@ysfactory.dip.jp> <97D9FB54-FFF1-4337-942A-E7FE2196A354@oracle.com> <523C534C.7060908@ysfactory.dip.jp> <9367FE2B-C709-4273-BEAE-745841846560@oracle.com> <523C5A8A.8060000@ysfactory.dip.jp> <523C606B.5060204@ysfactory.dip.jp> <952F096A-69D2-4E7C-B979-91E95AFE37F8@oracle.com> <523D786C.5090605@ysfactory.dip.jp> <523EAF7C.3050000@oracle.com> <3FE7CB8E-39F4-4915-B82E-AC2F88715189@oracle.com> <524ACADB.3060600@oracle.com> Message-ID: On 1 okt 2013, at 15:15, David Holmes wrote: > On 23/09/2013 2:41 AM, Staffan Larsen wrote: >> Dmitry: Thanks for the review. >> >> Yasumasa: Thanks for your contribution! I have pushed the changes into HS25 and will push them to 7u60 as well. > > I've been on vacation so could not respond in time. I am concerned about this fix. Other than printing a message on the console it pretends that the init has succeeded! That seems wrong to me. What are the consequences of doing this? The change is an improvement to the previous error message, but looking at the code again there is similar code in the block below. That code calls vm_exit_during_initialization() if the init failed. The only problem with that is that AttachListener::init() can be called not just during initialization, so it seems a bit drastic to kill the JVM if the init fails. In the case where AttachListener::init() is called during initialization it makes sense to kill the VM if AttachListener::init() fails, in other cases an error message would be better. We now have an ugly combination... If AttachListener::init() fails during runtime, I think it has no other consequences than attach operations not working. /Staffan > > David > ----- > >> /Staffan >> >> On 22 sep 2013, at 01:51, Dmitry Samersoff wrote: >> >>> Yasumasa, >>> >>> Looks good for me. >>> >>> -Dmitry >>> >>> On 2013-09-21 14:43, Yasumasa Suenaga wrote: >>>> Hi Staffan, >>>> >>>>> Can you update your patch, please? >>>> >>>> Of course! >>>> I've attached new patch in this email. >>>> >>>> Could you check this? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> On 2013/09/21 15:36, Staffan Larsen wrote: >>>>> >>>>> >>>>>> On 20 sep 2013, at 16:49, Yasumasa Suenaga >>>>>> wrote: >>>>>> >>>>>>> On 2013/09/20 23:34, Staffan Larsen wrote: >>>>>>> >>>>>>>> On 20 sep 2013, at 16:24, Yasumasa Suenaga >>>>>>>> wrote: >>>>>>>> >>>>>>>> I thought your code too. However... >>>>>>>> >>>>>>>> - These code is different from other code (rule?). >>>>>>> >>>>>>> Well, you are introducing a new macro that is also different from >>>>>>> other code, so I'm not sure how valid that argument is. >>>>>> >>>>>> My macro is modified from "CATCH" in exceptions.hpp: >>>>>> >>>>>> #define CATCH \ >>>>>> THREAD); if (HAS_PENDING_EXCEPTION) { \ >>>>>> oop ex = PENDING_EXCEPTION; \ >>>>>> CLEAR_PENDING_EXCEPTION; \ >>>>>> ex->print(); \ >>>>>> ShouldNotReachHere(); \ >>>>>> } (void)(0 >>>>>> >>>>>> So I think that my macro is not big difference fromother code. >>>>>> >>>>>> >>>>>>>> - Similar crash cases exist. e.g. 6425580 and 7142442. >>>>>>>> These crashes are different from 6989981. However, I guess that >>>>>>>> crashed >>>>>>>> thread had pending exception and we need to fix with similar patch. >>>>>>>> >>>>>>>> So I think that new macro is useful later. >>>>>>> >>>>>>> Yes, similar problems may come up in other cases as well. >>>>>>> >>>>>>> Generally, I don't think it's a good idea to have logging calls >>>>>>> hidden away in general macros. What we really should do here is >>>>>>> print some context around the stack trace as well. Something like: >>>>>>> >>>>>>> Initializing the attach listener failed with the following >>>>>>> exception in AttachListener::init when initializing the thread_oop: >>>>>>> >>>>>>> This would be possible with the code I suggested, but very hard in a >>>>>>> general macro. >>>>>> >>>>>> Agree. >>>>>> Should we write code as following? >>>>>> >>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>> tty->print_cr("Exception in VM (AttachListener::init) : "); >>>>>> java_lang_Throwable::print(PENDING_EXCEPTION, tty); >>>>>> CLEAR_PENDING_EXCEPTION; >>>>>> return; >>>>>> } >>>>>> >>>>>> I like this way :-) >>>>> >>>>> Yes, this is what I'd like to see! Can you update your patch, please? >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>>> On 2013/09/20 23:05, Staffan Larsen wrote: >>>>>>>>> I see. CHECK_AND_CLEAR_AND_PRINT? Just kidding... :-) >>>>>>>>> >>>>>>>>> Maybe in this case we should not have this as a macro, but >>>>>>>>> actually add the code after the two calls to call_special? >>>>>>>>> Something like the code below. I personally think this is more >>>>>>>>> readable than obscure macros that I have to go look up to >>>>>>>>> understand what they do. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>> JavaCalls::call_special(&result, thread_oop, >>>>>>>>> klass, >>>>>>>>> vmSymbols::object_initializer_name(), >>>>>>>>> >>>>>>>>> vmSymbols::threadgroup_string_void_signature(), >>>>>>>>> thread_group, >>>>>>>>> string, >>>>>>>>> THREAD); >>>>>>>>> >>>>>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>>>>> java_lang_Throwable::print(PENDING_EXCEPTION, tty); >>>>>>>>> CLEAR_PENDING_EXCEPTION; >>>>>>>>> return; >>>>>>>>> } >>>>>>>>> >>>>>>>>> KlassHandle group(THREAD, SystemDictionary::ThreadGroup_klass()); >>>>>>>>> JavaCalls::call_special(&result, >>>>>>>>> thread_group, >>>>>>>>> group, >>>>>>>>> vmSymbols::add_method_name(), >>>>>>>>> vmSymbols::thread_void_signature(), >>>>>>>>> thread_oop, // ARG 1 >>>>>>>>> THREAD); >>>>>>>>> >>>>>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>>>>> java_lang_Throwable::print(PENDING_EXCEPTION, tty); >>>>>>>>> CLEAR_PENDING_EXCEPTION; >>>>>>>>> return; >>>>>>>>> } >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 20 sep 2013, at 15:53, Yasumasa >>>>>>>>>> Suenaga wrote: >>>>>>>>>> >>>>>>>>>> Hi Staffan, >>>>>>>>>> >>>>>>>>>> Thank you for your sponsoring! >>>>>>>>>> >>>>>>>>>> "CHECK_AND_CLEAR" is already defined in exceptions.hpp: >>>>>>>>>> ****************** >>>>>>>>>> #define CHECK_AND_CLEAR THREAD); if >>>>>>>>>> (HAS_PENDING_EXCEPTION) { CLEAR_PENDING_EXCEPTION; return; >>>>>>>>>> } (void)(0 >>>>>>>>>> ****************** >>>>>>>>>> >>>>>>>>>> I think that user wants why serviceability tools are failed. >>>>>>>>>> So I defined "CHECK_AND_CLEAR" + java_lang_Throwable::print() as >>>>>>>>>> "CATCH_AND_RETURN" . >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I agree rename this macro. >>>>>>>>>> Do you have any idea? I don't have a good name :-) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>>> On 2013/09/20 20:10, Staffan Larsen wrote: >>>>>>>>>>> Yasuma, >>>>>>>>>>> >>>>>>>>>>> Thanks for finding and fixing this! I have re-opened the bug. >>>>>>>>>>> Your patch looks good to me, but perhaps CATCH_AND_RETURN should >>>>>>>>>>> be renamed CHECK_AND_CLEAR? >>>>>>>>>>> >>>>>>>>>>> I can sponsor the fix. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> /Staffan >>>>>>>>>>> >>>>>>>>>>>> On 20 sep 2013, at 12:41, Yasumasa >>>>>>>>>>>> Suenaga wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I encountered this bug: >>>>>>>>>>>> JDK-6989981: jstack causes "fatal error: ExceptionMark >>>>>>>>>>>> destructor expects no pending exceptions" >>>>>>>>>>>> >>>>>>>>>>>> I read hs_err and attachListener.cpp, Java heap usage is very >>>>>>>>>>>> high and >>>>>>>>>>>> it could be OutOfMemoryError in AttachListener::init() . >>>>>>>>>>>> >>>>>>>>>>>> If JavaCalls::call_special() in AttachListener::init() fail >>>>>>>>>>>> which is >>>>>>>>>>>> caused by OOME, d'tor of EXCEPTION_MARK (~ExceptionMark) will >>>>>>>>>>>> generate >>>>>>>>>>>> internal error. >>>>>>>>>>>> >>>>>>>>>>>> So I make a patch for avoiding crash and attached in this email >>>>>>>>>>>> (6989981.patch) . >>>>>>>>>>>> I'd like to re-open this bug and contribute my patch. >>>>>>>>>>>> Could you help me? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> --- DETAILS --- >>>>>>>>>>>> CHECK macro is used in JavaCalls::call_special() . >>>>>>>>>>>> >>>>>>>>>>>> ****************** >>>>>>>>>>>> void AttachListener::init() { >>>>>>>>>>>> EXCEPTION_MARK; >>>>>>>>>>>> >>>>>>>>>>>> : >>>>>>>>>>>> >>>>>>>>>>>> // Initialize thread_oop to put it into the system threadGroup >>>>>>>>>>>> Handle thread_group (THREAD, Universe::system_thread_group()); >>>>>>>>>>>> JavaValue result(T_VOID); >>>>>>>>>>>> JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>> klass, >>>>>>>>>>>> vmSymbols::object_initializer_name(), >>>>>>>>>>>> >>>>>>>>>>>> vmSymbols::threadgroup_string_void_signature(), >>>>>>>>>>>> thread_group, >>>>>>>>>>>> string, >>>>>>>>>>>> CHECK); >>>>>>>>>>>> >>>>>>>>>>>> KlassHandle group(THREAD, >>>>>>>>>>>> SystemDictionary::ThreadGroup_klass()); >>>>>>>>>>>> JavaCalls::call_special(&result, >>>>>>>>>>>> thread_group, >>>>>>>>>>>> group, >>>>>>>>>>>> vmSymbols::add_method_name(), >>>>>>>>>>>> vmSymbols::thread_void_signature(), >>>>>>>>>>>> thread_oop, // ARG 1 >>>>>>>>>>>> CHECK); >>>>>>>>>>>> ****************** >>>>>>>>>>>> >>>>>>>>>>>> CHECK macro does not clear pending exception of current thread. >>>>>>>>>>>> So call_special() fails with runtime exception, d'tor of >>>>>>>>>>>> ExceptionMark >>>>>>>>>>>> generates fatal error. >>>>>>>>>>>> >>>>>>>>>>>> ****************** >>>>>>>>>>>> ExceptionMark::~ExceptionMark() { >>>>>>>>>>>> if (_thread->has_pending_exception()) { >>>>>>>>>>>> Handle exception(_thread, _thread->pending_exception()); >>>>>>>>>>>> _thread->clear_pending_exception(); // Needed to avoid >>>>>>>>>>>> infinite recursion >>>>>>>>>>>> if (is_init_completed()) { >>>>>>>>>>>> exception->print(); >>>>>>>>>>>> fatal("ExceptionMark destructor expects no pending >>>>>>>>>>>> exceptions"); >>>>>>>>>>>> } else { >>>>>>>>>>>> vm_exit_during_initialization(exception); >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> ****************** >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> --- HOW TO REPRODUCE --- >>>>>>>>>>>> I also crate testcase of this issue (testcase.tar.gz) . This >>>>>>>>>>>> testcase contains >>>>>>>>>>>> two modules. >>>>>>>>>>>> >>>>>>>>>>>> - jvmti: JVMTI agent for this issue. This agent traps SIGQUIT and >>>>>>>>>>>> calls original (in HotSpot) SIGQUIT handler. >>>>>>>>>>>> This signal handler is invoked, MethodEntry event >>>>>>>>>>>> callback is >>>>>>>>>>>> enabled. MethodEntry generates OutOfMemoryError. >>>>>>>>>>>> >>>>>>>>>>>> - java : Simple long sleep program. >>>>>>>>>>>> >>>>>>>>>>>> I can run this testcase in Fedora18 x86_64. See below. >>>>>>>>>>>> >>>>>>>>>>>> ------- >>>>>>>>>>>> $ javac java/LongSleep.java >>>>>>>>>>>> $ make -C jvmti >>>>>>>>>>>> make: Entering directory >>>>>>>>>>>> `/data/share/patch/ExceptionMark/testcase/jvmti' >>>>>>>>>>>> gcc -I/usr/lib/jvm/java-openjdk/include >>>>>>>>>>>> -I/usr/lib/jvm/java-openjdk/include/linux -fPIC -c oome.c >>>>>>>>>>>> gcc -shared -o liboome.so oome.o >>>>>>>>>>>> make: Leaving directory >>>>>>>>>>>> `/data/share/patch/ExceptionMark/testcase/jvmti' >>>>>>>>>>>> $ export JAVA_HOME= >>>>>>>>>>>> $ ./test.sh >>>>>>>>>>>> ------- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> <6989981.patch> >>>>>> >>>>> >>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the source code. >> From karen.kinnear at oracle.com Tue Oct 1 08:04:31 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Tue, 01 Oct 2013 15:04:31 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8011311: Private interface methods. Default conflicts:ICCE. no erased_super_default. Message-ID: <20131001150436.A834A62C47@hg.openjdk.java.net> Changeset: 36b97be47bde Author: acorn Date: 2013-10-01 08:10 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/36b97be47bde 8011311: Private interface methods. Default conflicts:ICCE. no erased_super_default. Reviewed-by: coleenp, bharadwaj, minqi ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/defaultMethods.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klassVtable.cpp From tim.bell at oracle.com Tue Oct 1 08:30:14 2013 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 01 Oct 2013 08:30:14 -0700 Subject: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <524AD29A.3030806@oracle.com> References: <523D144E.4000002@oracle.com> <524A8B0F.4070704@oracle.com> <524AD29A.3030806@oracle.com> Message-ID: <524AEA86.3070405@oracle.com> Open changes look good to me as well. Tim On 10/ 1/13 06:48 AM, Daniel D. Daugherty wrote: > Thanks (again). You previously posted a review for the OpenJDK side > on 2013.09.23... :-) > > Dan > > > On 10/1/13 2:42 AM, Erik Joelsson wrote: >> I have looked at the build changes in the root and jdk repos and they >> look OK. >> >> /Erik >> >> On 2013-09-21 05:36, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have the initial support for Full Debug Symbols (FDS) on MacOS X done >>> and ready for review: >>> >>> 7165611 implement Full Debug Symbols on MacOS X hotspot >>> https://bugs.openjdk.java.net/browse/JDK-7165611 >>> >>> Here is the JDK8/HSX-25 webrev URL: >>> >>> OpenJDK: >>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >>> Internal: >>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >>> >>> >>> This webrev includes changes for the follow repos: >>> >>> jdk8 >>> jdk8/hotspot >>> jdk8/jdk >>> jdk8/jdk/make/closed >>> >>> Once these changes are approved, I'm planning to push them to >>> RT_Baseline. From there, they can follow the normal path to >>> Main_Baseline and eventually JDK8. >>> >>> This work enables FDS on MacOS X for the 'hotspot' repo; the changes in >>> the other repos are necessary to support importing the .diz files from >>> the MacOS X 'hotspot' build into the forest build. I also fixed a few >>> FDS related errors in the magic incantations for the new build. This is >>> mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported >>> from Solaris. In other words, this is Frankenstein's monster... >>> >>> Thanks to Staffan Larsen for providing an initial set of changes >>> which I morphed into what you see here. >>> >>> Testing: >>> - JPRT HSX build and test on all platforms; verification of .diz >>> files in the MacOS X JPRT bundles >>> - JPRT JDK8 forest build and test on all platforms; verification of >>> .diz files in the MacOS X JPRT bundles >>> Note: In previous FDS changesets, I also did a standalone 'jdk' >>> repo build and test, but that no longer seems to work. >>> >>> As always, comments, questions and suggestions are welcome. >>> >>> Dan >> > From daniel.daugherty at oracle.com Tue Oct 1 08:48:19 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 01 Oct 2013 09:48:19 -0600 Subject: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <524AEA86.3070405@oracle.com> References: <523D144E.4000002@oracle.com> <524A8B0F.4070704@oracle.com> <524AD29A.3030806@oracle.com> <524AEA86.3070405@oracle.com> Message-ID: <524AEEC3.9070908@oracle.com> Tim, Thanks for the review. Dan On 10/1/13 9:30 AM, Tim Bell wrote: > Open changes look good to me as well. > > Tim > > On 10/ 1/13 06:48 AM, Daniel D. Daugherty wrote: >> Thanks (again). You previously posted a review for the OpenJDK side >> on 2013.09.23... :-) >> >> Dan >> >> >> On 10/1/13 2:42 AM, Erik Joelsson wrote: >>> I have looked at the build changes in the root and jdk repos and >>> they look OK. >>> >>> /Erik >>> >>> On 2013-09-21 05:36, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have the initial support for Full Debug Symbols (FDS) on MacOS X >>>> done >>>> and ready for review: >>>> >>>> 7165611 implement Full Debug Symbols on MacOS X hotspot >>>> https://bugs.openjdk.java.net/browse/JDK-7165611 >>>> >>>> Here is the JDK8/HSX-25 webrev URL: >>>> >>>> OpenJDK: >>>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >>>> Internal: >>>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >>>> >>>> >>>> This webrev includes changes for the follow repos: >>>> >>>> jdk8 >>>> jdk8/hotspot >>>> jdk8/jdk >>>> jdk8/jdk/make/closed >>>> >>>> Once these changes are approved, I'm planning to push them to >>>> RT_Baseline. From there, they can follow the normal path to >>>> Main_Baseline and eventually JDK8. >>>> >>>> This work enables FDS on MacOS X for the 'hotspot' repo; the >>>> changes in >>>> the other repos are necessary to support importing the .diz files from >>>> the MacOS X 'hotspot' build into the forest build. I also fixed a few >>>> FDS related errors in the magic incantations for the new build. >>>> This is >>>> mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported >>>> from Solaris. In other words, this is Frankenstein's monster... >>>> >>>> Thanks to Staffan Larsen for providing an initial set of changes >>>> which I morphed into what you see here. >>>> >>>> Testing: >>>> - JPRT HSX build and test on all platforms; verification of .diz >>>> files in the MacOS X JPRT bundles >>>> - JPRT JDK8 forest build and test on all platforms; verification of >>>> .diz files in the MacOS X JPRT bundles >>>> Note: In previous FDS changesets, I also did a standalone 'jdk' >>>> repo build and test, but that no longer seems to work. >>>> >>>> As always, comments, questions and suggestions are welcome. >>>> >>>> Dan >>> >> > From daniel.daugherty at oracle.com Tue Oct 1 09:01:48 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 01 Oct 2013 10:01:48 -0600 Subject: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <85C072F5-3EC8-41DB-A058-4055807F242A@oracle.com> References: <523D144E.4000002@oracle.com> <52498025.3040402@oracle.com> <85C072F5-3EC8-41DB-A058-4055807F242A@oracle.com> Message-ID: <524AF1EC.9040101@oracle.com> On 9/30/13 12:00 PM, Staffan Larsen wrote: > On 30 sep 2013, at 15:44, Daniel D. Daugherty wrote: > >> >> I'm presuming that you're trying with a forest that includes >> closed repos. If so, then you'll need the jdk/make/closed change >> in order for the build to work. > Yes, I was running with closed repos. I now have the additional patch, but what I get now is a bit strange. The libjvm.dylib.dSYM directory should be copied from > build/macosx-x86_64-normal-server-slowdebug/hotspot/bsd_amd64_compiler2/debug/ to > build/macosx-x86_64-normal-server-slowdebug/hotspot/dist/jre/lib/server/ to > build/macosx-x86_64-normal-server-slowdebug/jdk/lib/server/ > > But what I get is for each copy, the result is different: > > build/macosx-x86_64-normal-server-slowdebug/hotspot/bsd_amd64_compiler2/debug/libjvm.dylib.dSYM/: > Contents > > build/macosx-x86_64-normal-server-slowdebug/hotspot/dist/jre/lib/server/libjvm.dylib.dSYM/: > Info.plist libjvm.dylib > > build/macosx-x86_64-normal-server-slowdebug/jdk/lib/server/libjvm.dylib.dSYM: > libjvm.dylib > > > Looks like the recursive copy isn't working as expected. Yesterday, I did a JPRT control build and here's what I see: $ unzip -l macosx_x64_10.7-product.zip | grep .diz 2333 10-01-2013 00:13 jre/lib/libjsig.diz 3747 10-01-2013 00:13 jre/lib/libsaproc.diz 204 10-01-2013 00:13 jre/lib/server/libjsig.diz 132330347 10-01-2013 00:14 jre/lib/server/libjvm.diz And inside libjvm.diz: $ unzip -l jre/lib/server/libjvm.diz Archive: jre/lib/server/libjvm.diz Length Date Time Name --------- ---------- ----- ---- 0 09-30-2013 23:59 libjvm.dylib.dSYM/ 0 09-30-2013 23:59 libjvm.dylib.dSYM/Contents/ 641 09-30-2013 23:59 libjvm.dylib.dSYM/Contents/Info.plist 0 09-30-2013 23:59 libjvm.dylib.dSYM/Contents/Resources/ 0 09-30-2013 23:59 libjvm.dylib.dSYM/Contents/Resources/DWARF/ 326461252 09-30-2013 23:59 libjvm.dylib.dSYM/Contents/Resources/DWARF/libjvm.dylib --------- ------- 326461893 6 files so it looks like JPRT is doing the "right thing" for control builds. I had previously verified that a hotspot only JPRT was doing the right thing before my vacation. My personal manual hotspot builds on my MacMini also did the right thing so I'll have to check out what's going on with your style of build invocation. >>> Another comment: There are some makefile logic for BSD, non-darwin platforms. Have you had a chance to test this logic? (hotspot/make/bsd/makefiles/vm.make) >> No, I don't have access to a BSD (non-darwin) platform. However, I'll >> be pinging Dmitri Samersoff to ask a few questions... > OK. If we can't verify the logic, then maybe should leave it out. I'll work with Dmitry S. on getting this tested. If we can't verify that proposed changes work on BSD, then I'll back out that portion. Dan > >> >>> Nit: hotspot/make/bsd/makefiles/vm.make: L345, L356: wrong indentation. >> These are make cmd lines: >> >> 344 else >> 345 $(QUIETLY) $(OBJCOPY) --only-keep-debug $@ $(LIBJVM_DEBUGINFO) >> 346 $(QUIETLY) $(OBJCOPY) --add-gnu-debuglink=$(LIBJVM_DEBUGINFO) $@ >> 347 ifeq ($(STRIP_POLICY),all_strip) >> >> so they have to be indented by a tab. Very ugly, but necessary. > Ouch. :-( > > /Staffan > >> Dan >> >> >>> >>> /Staffan >>> >>> >>> >>> On 21 sep 2013, at 05:36, Daniel D. Daugherty wrote: >>> >>>> Greetings, >>>> >>>> I have the initial support for Full Debug Symbols (FDS) on MacOS X done >>>> and ready for review: >>>> >>>> 7165611 implement Full Debug Symbols on MacOS X hotspot >>>> https://bugs.openjdk.java.net/browse/JDK-7165611 >>>> >>>> Here is the JDK8/HSX-25 webrev URL: >>>> >>>> OpenJDK: http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >>>> Internal: http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >>>> >>>> This webrev includes changes for the follow repos: >>>> >>>> jdk8 >>>> jdk8/hotspot >>>> jdk8/jdk >>>> jdk8/jdk/make/closed >>>> >>>> Once these changes are approved, I'm planning to push them to >>>> RT_Baseline. From there, they can follow the normal path to >>>> Main_Baseline and eventually JDK8. >>>> >>>> This work enables FDS on MacOS X for the 'hotspot' repo; the changes in >>>> the other repos are necessary to support importing the .diz files from >>>> the MacOS X 'hotspot' build into the forest build. I also fixed a few >>>> FDS related errors in the magic incantations for the new build. This is >>>> mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported >>>> from Solaris. In other words, this is Frankenstein's monster... >>>> >>>> Thanks to Staffan Larsen for providing an initial set of changes >>>> which I morphed into what you see here. >>>> >>>> Testing: >>>> - JPRT HSX build and test on all platforms; verification of .diz >>>> files in the MacOS X JPRT bundles >>>> - JPRT JDK8 forest build and test on all platforms; verification of >>>> .diz files in the MacOS X JPRT bundles >>>> Note: In previous FDS changesets, I also did a standalone 'jdk' >>>> repo build and test, but that no longer seems to work. >>>> >>>> As always, comments, questions and suggestions are welcome. >>>> >>>> Dan From staffan.larsen at oracle.com Tue Oct 1 09:36:13 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 1 Oct 2013 18:36:13 +0200 Subject: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <524AF1EC.9040101@oracle.com> References: <523D144E.4000002@oracle.com> <52498025.3040402@oracle.com> <85C072F5-3EC8-41DB-A058-4055807F242A@oracle.com> <524AF1EC.9040101@oracle.com> Message-ID: On 1 okt 2013, at 18:01, "Daniel D. Daugherty" wrote: > On 9/30/13 12:00 PM, Staffan Larsen wrote: >> On 30 sep 2013, at 15:44, Daniel D. Daugherty wrote: >> >>> >>> I'm presuming that you're trying with a forest that includes >>> closed repos. If so, then you'll need the jdk/make/closed change >>> in order for the build to work. >> Yes, I was running with closed repos. I now have the additional patch, but what I get now is a bit strange. The libjvm.dylib.dSYM directory should be copied from >> build/macosx-x86_64-normal-server-slowdebug/hotspot/bsd_amd64_compiler2/debug/ to >> build/macosx-x86_64-normal-server-slowdebug/hotspot/dist/jre/lib/server/ to >> build/macosx-x86_64-normal-server-slowdebug/jdk/lib/server/ >> >> But what I get is for each copy, the result is different: >> >> build/macosx-x86_64-normal-server-slowdebug/hotspot/bsd_amd64_compiler2/debug/libjvm.dylib.dSYM/: >> Contents >> >> build/macosx-x86_64-normal-server-slowdebug/hotspot/dist/jre/lib/server/libjvm.dylib.dSYM/: >> Info.plist libjvm.dylib >> >> build/macosx-x86_64-normal-server-slowdebug/jdk/lib/server/libjvm.dylib.dSYM: >> libjvm.dylib >> >> >> Looks like the recursive copy isn't working as expected. > > Yesterday, I did a JPRT control build and here's what I see: > > $ unzip -l macosx_x64_10.7-product.zip | grep .diz > 2333 10-01-2013 00:13 jre/lib/libjsig.diz > 3747 10-01-2013 00:13 jre/lib/libsaproc.diz > 204 10-01-2013 00:13 jre/lib/server/libjsig.diz > 132330347 10-01-2013 00:14 jre/lib/server/libjvm.diz > > And inside libjvm.diz: > > $ unzip -l jre/lib/server/libjvm.diz > Archive: jre/lib/server/libjvm.diz > Length Date Time Name > --------- ---------- ----- ---- > 0 09-30-2013 23:59 libjvm.dylib.dSYM/ > 0 09-30-2013 23:59 libjvm.dylib.dSYM/Contents/ > 641 09-30-2013 23:59 libjvm.dylib.dSYM/Contents/Info.plist > 0 09-30-2013 23:59 libjvm.dylib.dSYM/Contents/Resources/ > 0 09-30-2013 23:59 libjvm.dylib.dSYM/Contents/Resources/DWARF/ > 326461252 09-30-2013 23:59 libjvm.dylib.dSYM/Contents/Resources/DWARF/libjvm.dylib > --------- ------- > 326461893 6 files > > so it looks like JPRT is doing the "right thing" for control builds. > I had previously verified that a hotspot only JPRT was doing the right > thing before my vacation. > > My personal manual hotspot builds on my MacMini also did the right > thing so I'll have to check out what's going on with your style of > build invocation. The problem I am seeing is with the option --disable-zip-debug-info to configure (which is very useful when compiling and debugging on the same system). > > >>>> Another comment: There are some makefile logic for BSD, non-darwin platforms. Have you had a chance to test this logic? (hotspot/make/bsd/makefiles/vm.make) >>> No, I don't have access to a BSD (non-darwin) platform. However, I'll >>> be pinging Dmitri Samersoff to ask a few questions... >> OK. If we can't verify the logic, then maybe should leave it out. > > I'll work with Dmitry S. on getting this tested. If we can't verify > that proposed changes work on BSD, then I'll back out that portion. Good. /Staffan > > Dan > > >> >>> >>>> Nit: hotspot/make/bsd/makefiles/vm.make: L345, L356: wrong indentation. >>> These are make cmd lines: >>> >>> 344 else >>> 345 $(QUIETLY) $(OBJCOPY) --only-keep-debug $@ $(LIBJVM_DEBUGINFO) >>> 346 $(QUIETLY) $(OBJCOPY) --add-gnu-debuglink=$(LIBJVM_DEBUGINFO) $@ >>> 347 ifeq ($(STRIP_POLICY),all_strip) >>> >>> so they have to be indented by a tab. Very ugly, but necessary. >> Ouch. :-( >> >> /Staffan >> >>> Dan >>> >>> >>>> >>>> /Staffan >>>> >>>> >>>> >>>> On 21 sep 2013, at 05:36, Daniel D. Daugherty wrote: >>>> >>>>> Greetings, >>>>> >>>>> I have the initial support for Full Debug Symbols (FDS) on MacOS X done >>>>> and ready for review: >>>>> >>>>> 7165611 implement Full Debug Symbols on MacOS X hotspot >>>>> https://bugs.openjdk.java.net/browse/JDK-7165611 >>>>> >>>>> Here is the JDK8/HSX-25 webrev URL: >>>>> >>>>> OpenJDK: http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >>>>> Internal: http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >>>>> >>>>> This webrev includes changes for the follow repos: >>>>> >>>>> jdk8 >>>>> jdk8/hotspot >>>>> jdk8/jdk >>>>> jdk8/jdk/make/closed >>>>> >>>>> Once these changes are approved, I'm planning to push them to >>>>> RT_Baseline. From there, they can follow the normal path to >>>>> Main_Baseline and eventually JDK8. >>>>> >>>>> This work enables FDS on MacOS X for the 'hotspot' repo; the changes in >>>>> the other repos are necessary to support importing the .diz files from >>>>> the MacOS X 'hotspot' build into the forest build. I also fixed a few >>>>> FDS related errors in the magic incantations for the new build. This is >>>>> mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported >>>>> from Solaris. In other words, this is Frankenstein's monster... >>>>> >>>>> Thanks to Staffan Larsen for providing an initial set of changes >>>>> which I morphed into what you see here. >>>>> >>>>> Testing: >>>>> - JPRT HSX build and test on all platforms; verification of .diz >>>>> files in the MacOS X JPRT bundles >>>>> - JPRT JDK8 forest build and test on all platforms; verification of >>>>> .diz files in the MacOS X JPRT bundles >>>>> Note: In previous FDS changesets, I also did a standalone 'jdk' >>>>> repo build and test, but that no longer seems to work. >>>>> >>>>> As always, comments, questions and suggestions are welcome. >>>>> >>>>> Dan > From mike.duigou at oracle.com Tue Oct 1 10:29:25 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 01 Oct 2013 17:29:25 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131001173020.8476462C5E@hg.openjdk.java.net> Changeset: 8cfb2bddd95e Author: mduigou Date: 2013-09-30 15:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8cfb2bddd95e 7057785: Add note about optional support of recursive methods for self-referential Collection/Map Reviewed-by: scolebourne, darcy, mduigou Contributed-by: Stephen Colebourne ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Map.java Changeset: f2e2326f787b Author: mduigou Date: 2013-10-01 10:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f2e2326f787b 8025067: Unconditionally throw NPE if null op provided to Arrays.parallelPrefix Reviewed-by: henryjen, chegar, psandoz ! src/share/classes/java/util/Arrays.java ! test/java/util/Arrays/ParallelPrefix.java From mike.duigou at oracle.com Tue Oct 1 10:37:55 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 01 Oct 2013 17:37:55 +0000 Subject: hg: jdk8/tl/jdk: 8025686: Update jdk repo netbeans projects to support NetBeans 7.4 for Java 8 support Message-ID: <20131001173807.4DC8762C60@hg.openjdk.java.net> Changeset: c32ab940a183 Author: mduigou Date: 2013-10-01 10:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c32ab940a183 8025686: Update jdk repo netbeans projects to support NetBeans 7.4 for Java 8 support Reviewed-by: lancea, chegar ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent From staffan.larsen at oracle.com Tue Oct 1 11:46:58 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 1 Oct 2013 20:46:58 +0200 Subject: RFR (S): 8025427 jstat tests fails on 32-bit platforms In-Reply-To: <7483E09E-5283-412F-BEA3-F7CC015A67DC@oracle.com> References: <7483E09E-5283-412F-BEA3-F7CC015A67DC@oracle.com> Message-ID: Any Reviewer who can take a look? Thanks, /Staffan On 27 sep 2013, at 23:59, Staffan Larsen wrote: > This change makes jstat output '-' instead of '\ufffd' when the result of a calculation is NaN. '\ufffd' is typically not displayable in a terminal. > > This change also updates the tests to allow '-' as the output int the CCS (Compressed Class Space Space - Percent Used) column from -gcutil and -gccause. It can be hard to see from the diff but what I have done is change the regexp for that column from: > > [0-9]+\.[0-9]+ > > to: > > ([0-9]+\.[0-9]+)|- > > Testing: Passes tests locally, currently running JPRT. > > webrev: http://cr.openjdk.java.net/~sla/8025427/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8025427 > > Thanks, > /Staffan From zhengyu.gu at oracle.com Tue Oct 1 12:36:42 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Tue, 01 Oct 2013 19:36:42 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets Message-ID: <20131001193649.1BF4E62C63@hg.openjdk.java.net> Changeset: de059a14e159 Author: zgu Date: 2013-10-01 08:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/de059a14e159 8022187: Missing ResourceMark crash when assertion using FormatBufferResource fails Summary: Uses stack for the format buffer instead of resource memory Reviewed-by: kvn, coleenp ! src/share/vm/utilities/array.hpp Changeset: 90b27e931639 Author: zgu Date: 2013-10-01 09:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/90b27e931639 Merge Changeset: 31f0118ea584 Author: zgu Date: 2013-10-01 11:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/31f0118ea584 Merge From eric.mccorkle at oracle.com Tue Oct 1 14:27:00 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Tue, 01 Oct 2013 21:27:00 +0000 Subject: hg: jdk8/tl/jdk: 8024616: JSR292: lazily initialize core NamedFunctions used for bootstrapping Message-ID: <20131001212712.1AB2F62C75@hg.openjdk.java.net> Changeset: 1ed675532589 Author: vlivanov Date: 2013-09-18 20:12 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ed675532589 8024616: JSR292: lazily initialize core NamedFunctions used for bootstrapping Reviewed-by: jrose ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java From eric.mccorkle at oracle.com Tue Oct 1 14:36:18 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Tue, 01 Oct 2013 21:36:18 +0000 Subject: hg: jdk8/tl/jdk: 8021398: j.l.r.Parameter.getAnnotatedType().getType() for not annotated use of type returns null Message-ID: <20131001213630.DA85162C78@hg.openjdk.java.net> Changeset: bf1118ab775b Author: emc Date: 2013-10-01 17:35 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf1118ab775b 8021398: j.l.r.Parameter.getAnnotatedType().getType() for not annotated use of type returns null Summary: Fixed issue with type annotation reflection framework that would cause getType of AnnotatedTypes to be null if no annotations were present. Reviewed-by: darcy, jfranck ! src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java + test/java/lang/reflect/Parameter/GetAnnotatedTypeTest.java From eric.mccorkle at oracle.com Tue Oct 1 14:43:01 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Tue, 01 Oct 2013 21:43:01 +0000 Subject: hg: jdk8/tl/langtools: 8021339: Compile-time error during casting array to intersection Message-ID: <20131001214305.099F362C79@hg.openjdk.java.net> Changeset: de1c5dbe6c28 Author: emc Date: 2013-10-01 17:41 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/de1c5dbe6c28 8021339: Compile-time error during casting array to intersection Summary: Add ability to have arrays in intersection types. Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/ArraysInIntersections.java + test/tools/javac/InferArraysInIntersections.java ! test/tools/javac/generics/typevars/6680106/T6680106.out From eric.mccorkle at oracle.com Tue Oct 1 14:24:14 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Tue, 01 Oct 2013 21:24:14 +0000 Subject: hg: jdk8/tl/jdk: 8001107: @Stable annotation for constant folding of lazily evaluated variables Message-ID: <20131001212426.B496562C73@hg.openjdk.java.net> Changeset: 5a7bd9825c01 Author: vlivanov Date: 2013-09-23 19:51 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5a7bd9825c01 8001107: @Stable annotation for constant folding of lazily evaluated variables Reviewed-by: twisti, kvn, rbackman Contributed-by: john.r.rose at oracle.com, vladimir.x.ivanov at oracle.com ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java + src/share/classes/java/lang/invoke/Stable.java From kumar.x.srinivasan at oracle.com Tue Oct 1 15:42:31 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 01 Oct 2013 22:42:31 +0000 Subject: hg: jdk8/tl/jdk: 8025342: NLS: unsupported translation format in jar/pack/DriverResource.java Message-ID: <20131001224245.5328862C7B@hg.openjdk.java.net> Changeset: 84e7f6685319 Author: ksrini Date: 2013-10-01 15:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/84e7f6685319 8025342: NLS: unsupported translation format in jar/pack/DriverResource.java Reviewed-by: naoto, mfang ! src/share/classes/com/sun/java/util/jar/pack/Driver.java ! src/share/classes/com/sun/java/util/jar/pack/DriverResource.java From john.r.rose at oracle.com Tue Oct 1 19:23:45 2013 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 02 Oct 2013 02:23:45 +0000 Subject: hg: jdk8/tl/jdk: 8022701: Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError Message-ID: <20131002022421.327E062C86@hg.openjdk.java.net> Changeset: d90928a89af5 Author: drchase Date: 2013-09-27 13:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d90928a89af5 8022701: Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError Summary: Inserted code to convert specific exceptions, case-by-case, plus a test. Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/MethodHandleNatives.java + test/java/lang/invoke/8022701/BogoLoader.java + test/java/lang/invoke/8022701/InvokeSeveralWays.java + test/java/lang/invoke/8022701/Invoker.java + test/java/lang/invoke/8022701/MHIllegalAccess.java + test/java/lang/invoke/8022701/MethodSupplier.java From david.holmes at oracle.com Tue Oct 1 19:52:40 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 02 Oct 2013 12:52:40 +1000 Subject: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <523D144E.4000002@oracle.com> References: <523D144E.4000002@oracle.com> Message-ID: <524B8A78.9040807@oracle.com> Hi Dan, Overall thumbs up. A couple of minor issues that need fixing. A few meta-comments (I hate seeing all this stuff duplicated again and again. David ----- - common/autoconf/hotspot-spec.gmk.in Seems a good simplification. ---- - common/autoconf/jdk-options.m4 No comment. --- - common/makefiles/NativeCompilation.gmk So JDK .diz support is phase 2? :) The Windows changes here seem okay given that on windows a .debuginfo file should never be in the target list. --- - hotspot/make/Makefile + $(EXPORT_CLIENT_DIR)/%.dSYM: $(MINIMAL1_BUILD_DIR)/%.dSYM EXPORT_CLIENT_DIR should be EXPORT_MINIMAL_DIR. For fun you can try building minimal on OSX, but I don't know how far you will get: --with-jvm-variants=client,server,minimal1 I'll point out obvious issues with minimal VM support anyway. --- - hotspot/make/bsd/Makefile No comment. - hotspot/make/bsd/makefiles/buildtree.make No comment. - make/bsd/makefiles/defs.make Note that the whole jdk6_or_earlier logic is defunct as this will never be used for jdk6 or earlier. But best to clean all that up at the one time. Sadly I never found a satisfactory solution to the multiplicity and verbosity of the FDS messages, so OSX builds will now be afflicted by them too. 328 else 329 EXPORT_LIST += $(EXPORT_MINIMAL_DIR)/libjvm.debuginfo 330 endif This pre-existing minimal VM code needs to be modified to reference the dSYM directory on OSX as per the client/server cases. --- - hotspot/make/bsd/makefiles/dtrace.make Note related to your changes but I don't think any of the "64" directory stuff has any meaning outside of Solaris. 102 dsymutil $@ I think dsymutil should be assigned to a variable in the platform defs.make as with other tools. Would be nice if objcopy/dsymutil could be hidden behind a single SYM_TOOL variables as well so there wasn't so much duplication of the process. You could have a single set of instructions to invoke SYM_TOOL, STRIP and ZIP (strip would be skipped of course because STRIP_POLICY would never be set on osx). Just wishful thinking ... --- - hotspot/make/bsd/makefiles/gcc.make + FASTDEBUG_CFLAGS += $(DEBUG_CFLAGS/$(BUILDARCH)) should be + FASTDEBUG_CFLAGS += $(FASTDEBUG_CFLAGS/$(BUILDARCH)) Don't we need the USE_CLANG variations here as for linux? --- - hotspot/make/bsd/makefiles/jsig.make - hotspot/make/bsd/makefiles/saproc.make Similar comments to dtrace.make --- - make/bsd/makefiles/universal.gmk I did not understand the additional logic here: 63 # Copy built non-universal binaries in place 64 $(UNIVERSAL_COPY_LIST): 65 BUILT_COPY_FILES="`find $(EXPORT_JRE_LIB_DIR)/{i386,amd64}/$(subst $(EXPORT_JRE_LIB_DIR)/,,$@) 2>/dev/null`"; \ 66 if [ -n "$${BUILT_COPY_FILES}" ]; then \ 67 for i in $${BUILT_COPY_FILES}; do \ 68 if [ -f $${i} ]; then \ 69 $(MKDIR) -p $(shell dirname $@); \ 70 $(CP) -R $${i} $@; \ 71 fi; \ 72 if [ -d $${i} ]; then \ 73 $(MKDIR) -p $@; \ 74 fi; \ 75 done; \ 76 fi until I realized that foo.dSYM is a directory not a file! Even so don't you want to copy the contents of the directory across ? BTW: UNIVERSAL_COPY_LIST doesn't handle minimal VM. --- - make/bsd/makefiles/vm.make Similar comments to dtrace.make ref dsymutil. --- - hotspot/make/defs.make No comment. --- - jdk/make/common/Defs-macosx.gmk No comment - jdk/makefiles/Tools.gmk Not sure about this one. Logically is seems correct but up to now this has been defined for everything without it seeming to cause a problem. So why do we need to change it and what impact will it have? David ----- On 21/09/2013 1:36 PM, Daniel D. Daugherty wrote: > Greetings, > > I have the initial support for Full Debug Symbols (FDS) on MacOS X done > and ready for review: > > 7165611 implement Full Debug Symbols on MacOS X hotspot > https://bugs.openjdk.java.net/browse/JDK-7165611 > > Here is the JDK8/HSX-25 webrev URL: > > OpenJDK: > http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ > Internal: > http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ > > This webrev includes changes for the follow repos: > > jdk8 > jdk8/hotspot > jdk8/jdk > jdk8/jdk/make/closed > > Once these changes are approved, I'm planning to push them to > RT_Baseline. From there, they can follow the normal path to > Main_Baseline and eventually JDK8. > > This work enables FDS on MacOS X for the 'hotspot' repo; the changes in > the other repos are necessary to support importing the .diz files from > the MacOS X 'hotspot' build into the forest build. I also fixed a few > FDS related errors in the magic incantations for the new build. This is > mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported > from Solaris. In other words, this is Frankenstein's monster... > > Thanks to Staffan Larsen for providing an initial set of changes > which I morphed into what you see here. > > Testing: > - JPRT HSX build and test on all platforms; verification of .diz > files in the MacOS X JPRT bundles > - JPRT JDK8 forest build and test on all platforms; verification of > .diz files in the MacOS X JPRT bundles > Note: In previous FDS changesets, I also did a standalone 'jdk' > repo build and test, but that no longer seems to work. > > As always, comments, questions and suggestions are welcome. > > Dan From coleen.phillimore at oracle.com Tue Oct 1 20:10:58 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 02 Oct 2013 03:10:58 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20131002031105.5C7C062C87@hg.openjdk.java.net> Changeset: 5b3b75d9eb2f Author: coleenp Date: 2013-10-01 14:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5b3b75d9eb2f 8025570: Naked oop in test/serviceability/ParserTest Summary: Fix for two naked objArrayOop(s) oops causing test failure Reviewed-by: coleenp, ctornqvi Contributed-by: lois.foltan at oracle.com ! src/share/vm/prims/wbtestmethods/parserTests.cpp Changeset: f21415c32ca1 Author: coleenp Date: 2013-10-01 15:41 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f21415c32ca1 Merge From alan.bateman at oracle.com Tue Oct 1 20:27:06 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 02 Oct 2013 03:27:06 +0000 Subject: hg: jdk8/tl: 8006843: org.w3c.dom.events.UIEvent.getView is specified to return type that is not in the Java SE specification Message-ID: <20131002032706.AFBCC62C89@hg.openjdk.java.net> Changeset: 187a759c08ba Author: alanb Date: 2013-10-02 04:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/187a759c08ba 8006843: org.w3c.dom.events.UIEvent.getView is specified to return type that is not in the Java SE specification Reviewed-by: mduigou, tbell ! common/makefiles/javadoc/CORE_PKGS.gmk From xuelei.fan at oracle.com Tue Oct 1 20:26:43 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Wed, 02 Oct 2013 03:26:43 +0000 Subject: hg: jdk8/tl/jdk: 8025123: SNI support in Kerberos cipher suites Message-ID: <20131002032658.A714B62C88@hg.openjdk.java.net> Changeset: 3fca37c636be Author: xuelei Date: 2013-10-01 20:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3fca37c636be 8025123: SNI support in Kerberos cipher suites Reviewed-by: weijun, xuelei Contributed-by: Artem Smotrakov ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java ! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java ! test/sun/security/krb5/auto/SSL.java From masayoshi.okutsu at oracle.com Tue Oct 1 23:32:25 2013 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Wed, 02 Oct 2013 06:32:25 +0000 Subject: hg: jdk8/tl/jdk: 6902861: (cal) GregorianCalendar roll WEEK_OF_YEAR is broken for January 1 2010 Message-ID: <20131002063239.AC93662C8C@hg.openjdk.java.net> Changeset: 914c29c10bce Author: okutsu Date: 2013-10-02 15:31 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/914c29c10bce 6902861: (cal) GregorianCalendar roll WEEK_OF_YEAR is broken for January 1 2010 Reviewed-by: peytoia ! src/share/classes/java/util/GregorianCalendar.java + test/java/util/Calendar/Bug6902861.java From staffan.larsen at oracle.com Wed Oct 2 00:22:28 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 2 Oct 2013 09:22:28 +0200 Subject: RFR (S): 8016845: SA is unable to use hsdis on windows In-Reply-To: <523C5BD3.1010106@oracle.com> References: <523C5BD3.1010106@oracle.com> Message-ID: <06A81151-E94D-4E81-99A9-8413FA509456@oracle.com> Looks good! Thanks, /Staffan On 20 sep 2013, at 16:29, Fredrik Arvidsson wrote: > Please help me review this: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8016845 > Webrev: http://cr.openjdk.java.net/~allwin/farvidss/8016845/webrev.00/ > > Small change was made in the sa.make file for windows to compile and link sadis.c in to sawindbg.dll providing JNI entrypoints needed to call the hsdis disassembler from SADB on windows. A small change in agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java to have the correct library name when loading library depending if running on 32 or 64 bit platform. > > To test this you have to build the hsdis library yourself, since it cant be bundled due to license issues. Instructions can be found here: http://dropzone.nfshost.com/hsdis.htm (hint, I have pre-built binaries). When running disassembling in HSDB (using the 'dis' command in the console) the hsdis-amd64.dll/hsdis-i386.dll must be in the /bin directory of the JRE/JDK used. > > Cheers > /Fredrik From sean.coffey at oracle.com Wed Oct 2 01:22:34 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Wed, 02 Oct 2013 08:22:34 +0000 Subject: hg: jdk8/tl/jdk: 8024952: ClassCastException in PlainSocketImpl.accept() when using custom socketImpl Message-ID: <20131002082305.2A14B62C96@hg.openjdk.java.net> Changeset: 368172cb6dc5 Author: coffeys Date: 2013-10-02 09:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/368172cb6dc5 8024952: ClassCastException in PlainSocketImpl.accept() when using custom socketImpl Reviewed-by: chegar ! src/windows/classes/java/net/PlainSocketImpl.java + test/java/net/PlainSocketImpl/CustomSocketImplFactory.java From jaroslav.bachorik at oracle.com Wed Oct 2 01:47:26 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 02 Oct 2013 10:47:26 +0200 Subject: RFR 6523160: RuntimeMXBean.getUptime() returns negative values Message-ID: <524BDD9E.1050100@oracle.com> Hello, currently the JVM uptime reported by the RuntimeMXBean is based on System.currentTimeMillis() which makes it susceptible to changes of the OS time (eg. changing timezone, NTP synchronization etc.). The uptime should not depend on the system time and should be calculated using a monotonic clock source. There is already the way to get the actual JVM uptime in ticks. It is accessible as Management::timestamp() and the ticks are convertible to milliseconds using Management::ticks_to_ms(ts_ticks) thus making it very easy to switch to the monotonic clock based uptime. The patch consists of the hotspot and jdk parts. For the hotspot a new constant needs to be introduced in src/share/vm/services/jmm.h and the actual logic to obtain the uptime in milliseconds is added in src/share/vm/services/management.cpp. For the jdk the changes comprise of adding the necessary JNI bridging methods in order to get the new uptime, introducing the same constant that is used in hotspot and changes to mapfile-vers files in order to properly build the native library. Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 Webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 Thanks, -JB- From peter.allwin at oracle.com Wed Oct 2 01:49:04 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Wed, 2 Oct 2013 10:49:04 +0200 Subject: RFR (S): 6313383: SA: Update jmap to support HPROF binary format "JAVA PROFILE 1.0.2" In-Reply-To: <523C4118.2050502@oracle.com> References: <523C4118.2050502@oracle.com> Message-ID: <4F092E8F-8002-4E02-9F75-519A3083AB96@oracle.com> Hi Fredrik, Looks great! Thanks for fixing this, /peter On Sep 20, 2013, at 2:35 PM, Fredrik Arvidsson wrote: > Hi > > Please help me and review the changes below: > > Webrev: http://cr.openjdk.java.net/~allwin/farvidss/6313383/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-6313383 > > This change adds support for dumping large heaps (> 4G) using jmap by implementing the "JAVA PROFILE 1.0.2" file format with segmented heap dump records. > The HPROF binary format specification can be found here: https://java.net/downloads/heap-snapshot/hprof-binary-format.html. > > I added a simple test to verify that heaps smaller than 2G are dumped using the "JAVA PROFILE 1.0.1" format. The last section in the test, aiming to test the format used when dumping heaps larger than 2G, is commented out since the test system didn't like that kind of heap sizes and ultimately failed (OOM and sometimes timeout). The test should be reintroduced once we can reliably support such tests in the test system. > > Thanks 'allwin' for hosting my review :) > > Cheers > /Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131002/6d76ccd9/attachment.html From mikael.gerdin at oracle.com Wed Oct 2 01:51:53 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 02 Oct 2013 10:51:53 +0200 Subject: RFR (S): 8016845: SA is unable to use hsdis on windows In-Reply-To: <523C5BD3.1010106@oracle.com> References: <523C5BD3.1010106@oracle.com> Message-ID: <524BDEA9.5020800@oracle.com> Fredrik, On 09/20/2013 04:29 PM, Fredrik Arvidsson wrote: > Please help me review this: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8016845 > Webrev: http://cr.openjdk.java.net/~allwin/farvidss/8016845/webrev.00/ > the change looks good to me. > > Small change was made in the sa.make file for windows to compile and > link sadis.c in to sawindbg.dll providing JNI entrypoints needed to call > the hsdis disassembler from SADB on windows. A small change in > agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java to have > the correct library name when loading library depending if running on 32 > or 64 bit platform. Thanks for fixing this! /Mikael > > To test this you have to build the hsdis library yourself, since it cant > be bundled due to license issues. Instructions can be found here: > http://dropzone.nfshost.com/hsdis.htm (hint, I have pre-built binaries). > When running disassembling in HSDB (using the 'dis' command in the > console) the hsdis-amd64.dll/hsdis-i386.dll must be in the /bin > directory of the JRE/JDK used. > > Cheers > /Fredrik From staffan.larsen at oracle.com Wed Oct 2 02:23:34 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 2 Oct 2013 11:23:34 +0200 Subject: RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <524BDD9E.1050100@oracle.com> References: <524BDD9E.1050100@oracle.com> Message-ID: <4088022F-6550-4C95-86D5-640F2E737839@oracle.com> Looks good! Thanks, /Staffan On 2 okt 2013, at 10:47, Jaroslav Bachorik wrote: > Hello, > > currently the JVM uptime reported by the RuntimeMXBean is based on System.currentTimeMillis() which makes it susceptible to changes of the OS time (eg. changing timezone, NTP synchronization etc.). The uptime should not depend on the system time and should be calculated using a monotonic clock source. > > There is already the way to get the actual JVM uptime in ticks. It is accessible as Management::timestamp() and the ticks are convertible to milliseconds using Management::ticks_to_ms(ts_ticks) thus making it very easy to switch to the monotonic clock based uptime. > > The patch consists of the hotspot and jdk parts. > > For the hotspot a new constant needs to be introduced in src/share/vm/services/jmm.h and the actual logic to obtain the uptime in milliseconds is added in src/share/vm/services/management.cpp. > > For the jdk the changes comprise of adding the necessary JNI bridging methods in order to get the new uptime, introducing the same constant that is used in hotspot and changes to mapfile-vers files in order to properly build the native library. > > Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 > Webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 > > Thanks, > > -JB- From fredrik.arvidsson at oracle.com Wed Oct 2 02:28:19 2013 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Wed, 02 Oct 2013 11:28:19 +0200 Subject: RFR (S): JDK-8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes In-Reply-To: <524A7B07.1000300@oracle.com> References: <5249643F.3030209@oracle.com> <524A7B07.1000300@oracle.com> Message-ID: <524BE733.2070205@oracle.com> Hi and thanks for all your comments. I have simplified the code in *instanceKlass.cpp* like suggested and here is a new webrev: http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.01/ Regarding the need to synchronize the access to ClassLoaderDataGraph I have come to the conclusion that it should be safe to call this without any additional synchronization since newly loaded and added classes are appended to the end of its 'list' of classes. This would mean that the call could 'miss' the classes added during the collection phase, but this is not a big issue. I hope that my conclusion is correct. I believe that the JvmtiGetLoadedClasses::getClassLoaderClasses(...) method is to be left alone this time since I got the impression that only SystemDictionary 'knows' about initiating class loaders. There is plenty of room for improvement and simplification of much of the code in this area, but I feel that it must wait until another time. The task to re-factor and simplify would quickly grow out of hands I'm afraid :) Cheers /Fredrik On 2013-10-01 09:34, serguei.spitsyn at oracle.com wrote: > Hi Frederik, > > > Thank you for jumping on this issue! > > > *src/share/vm/oops/instanceKlass.cpp* > 2333 int src_index = 0; > 2334 while (src_index < src_length) { > 2335 dest[dest_index++] = src[src_index++]; > 2336 } > 2337 > 2338 // If we have a hash, append it > 2339 if(hash_len > 0) { > 2340 int hash_index = 0; > 2341 while (hash_index < hash_len) { > 2342 dest[dest_index++] = hash_buf[hash_index++]; > 2343 } > 2344 } > > The above can be simplified a little bit: > // Add the actual class name > for (int src_index = 0; src_index < src_length; ) { > dest[dest_index++] = src[src_index++]; > } > // If we have a hash, append it > for (int hash_index = 0; hash_index < hash_len; ) { > dest[dest_index++] = hash_buf[hash_index++]; > } > > The conditionif(hash_len > 0) is covered by the loop itself. > > Style-related comments: > -wrong indent at the lines: 2316-2319 > - need a space after the 'if' at the lines: 2315, 2339 > > > *src/share/vm/prims/jvmtiGetLoadedClasses.cpp > > *The copyright comment must be up-to-date. > The comments at the lines 35-38, 258-260 are not valid anymore. > > > > In this review I still have an outstanding unanswered question about > > the need to synchronize the access to the: > > > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); > > and > > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); > > This kind of walking is usually done at safepoint in a VM_Operation. > You will find many examples in the jvmtiEnv.cpp, for instance, VM_GetAllStackTraces. > The suggestion from Mikael is good too. > > Should this fix include the getClassLoaderClasses() as well? > I'm still trying to realize the impact and consistency of this fix. :( > > What tests are you going to run for verification? > > Thanks, > Serguei > * > *On 9/30/13 4:45 AM, Fredrik Arvidsson wrote: >> Hi >> >> Please help me to review the changes below: >> >> Jira case: https://bugs.openjdk.java.net/browse/JDK-8024423 >> Webrev: >> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/ >> >> >> In this review I still have an outstanding unanswered question about >> the need to synchronize the access to the: >> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >> and >> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >> >> calls in >> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/src/share/vm/prims/jvmtiGetLoadedClasses.cpp.udiff.html >> >> Please give me advise on this. >> >> There will be a review soon regarding re-enabling the tests that failed because of the above bug, see: >> https://bugs.openjdk.java.net/browse/JDK-8025576 >> >> Cheers >> /Fredrik > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131002/49255ad9/attachment-0001.html From Christer.Burtus at delaval.com Wed Oct 2 02:35:42 2013 From: Christer.Burtus at delaval.com (Burtus, Christer) Date: Wed, 2 Oct 2013 11:35:42 +0200 Subject: serviceability-dev Digest, Vol 71, Issue 7 In-Reply-To: Message-ID: ----- Original Message ----- From: serviceability-dev-request at openjdk.java.net [mailto:serviceability-dev-request at openjdk.java.net] Sent: Wednesday, October 02, 2013 11:27 AM W. Europe Standard Time To: serviceability-dev at openjdk.java.net Subject: serviceability-dev Digest, Vol 71, Issue 7 Send serviceability-dev mailing list submissions to serviceability-dev at openjdk.java.net To subscribe or unsubscribe via the World Wide Web, visit http://mail.openjdk.java.net/mailman/listinfo/serviceability-dev or, via email, send a message with subject or body 'help' to serviceability-dev-request at openjdk.java.net You can reach the person managing the list at serviceability-dev-owner at openjdk.java.net When replying, please edit your Subject line so it is more specific than "Re: Contents of serviceability-dev digest..." Today's Topics: 1. hg: jdk8/tl/jdk: 8025123: SNI support in Kerberos cipher suites (xuelei.fan at oracle.com) 2. hg: jdk8/tl/jdk: 6902861: (cal) GregorianCalendar roll WEEK_OF_YEAR is broken for January 1 2010 (masayoshi.okutsu at oracle.com) 3. Re: RFR (S): 8016845: SA is unable to use hsdis on windows (Staffan Larsen) 4. hg: jdk8/tl/jdk: 8024952: ClassCastException in PlainSocketImpl.accept() when using custom socketImpl (sean.coffey at oracle.com) 5. RFR 6523160: RuntimeMXBean.getUptime() returns negative values (Jaroslav Bachorik) 6. Re: RFR (S): 6313383: SA: Update jmap to support HPROF binary format "JAVA PROFILE 1.0.2" (Peter Allwin) 7. Re: RFR (S): 8016845: SA is unable to use hsdis on windows (Mikael Gerdin) 8. Re: RFR 6523160: RuntimeMXBean.getUptime() returns negative values (Staffan Larsen) 9. Re: RFR (S): JDK-8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes (Fredrik Arvidsson) ---------------------------------------------------------------------- Message: 1 Date: Wed, 02 Oct 2013 03:26:43 +0000 From: xuelei.fan at oracle.com Subject: hg: jdk8/tl/jdk: 8025123: SNI support in Kerberos cipher suites To: jdk8-changes at openjdk.java.net, compiler-dev at openjdk.java.net, core-libs-dev at openjdk.java.net, serviceability-dev at openjdk.java.net, security-dev at openjdk.java.net, net-dev at openjdk.java.net Message-ID: <20131002032658.A714B62C88 at hg.openjdk.java.net> Changeset: 3fca37c636be Author: xuelei Date: 2013-10-01 20:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3fca37c636be 8025123: SNI support in Kerberos cipher suites Reviewed-by: weijun, xuelei Contributed-by: Artem Smotrakov ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java ! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java ! test/sun/security/krb5/auto/SSL.java ------------------------------ Message: 2 Date: Wed, 02 Oct 2013 06:32:25 +0000 From: masayoshi.okutsu at oracle.com Subject: hg: jdk8/tl/jdk: 6902861: (cal) GregorianCalendar roll WEEK_OF_YEAR is broken for January 1 2010 To: jdk8-changes at openjdk.java.net, compiler-dev at openjdk.java.net, core-libs-dev at openjdk.java.net, serviceability-dev at openjdk.java.net, security-dev at openjdk.java.net, net-dev at openjdk.java.net Message-ID: <20131002063239.AC93662C8C at hg.openjdk.java.net> Changeset: 914c29c10bce Author: okutsu Date: 2013-10-02 15:31 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/914c29c10bce 6902861: (cal) GregorianCalendar roll WEEK_OF_YEAR is broken for January 1 2010 Reviewed-by: peytoia ! src/share/classes/java/util/GregorianCalendar.java + test/java/util/Calendar/Bug6902861.java ------------------------------ Message: 3 Date: Wed, 2 Oct 2013 09:22:28 +0200 From: Staffan Larsen Subject: Re: RFR (S): 8016845: SA is unable to use hsdis on windows To: Fredrik Arvidsson Cc: serviceability-dev at openjdk.java.net, hotspot-runtime-dev at openjdk.java.net Message-ID: <06A81151-E94D-4E81-99A9-8413FA509456 at oracle.com> Content-Type: text/plain; charset=iso-8859-1 Looks good! Thanks, /Staffan On 20 sep 2013, at 16:29, Fredrik Arvidsson wrote: > Please help me review this: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8016845 > Webrev: http://cr.openjdk.java.net/~allwin/farvidss/8016845/webrev.00/ > > Small change was made in the sa.make file for windows to compile and link sadis.c in to sawindbg.dll providing JNI entrypoints needed to call the hsdis disassembler from SADB on windows. A small change in agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java to have the correct library name when loading library depending if running on 32 or 64 bit platform. > > To test this you have to build the hsdis library yourself, since it cant be bundled due to license issues. Instructions can be found here: http://dropzone.nfshost.com/hsdis.htm (hint, I have pre-built binaries). When running disassembling in HSDB (using the 'dis' command in the console) the hsdis-amd64.dll/hsdis-i386.dll must be in the /bin directory of the JRE/JDK used. > > Cheers > /Fredrik ------------------------------ Message: 4 Date: Wed, 02 Oct 2013 08:22:34 +0000 From: sean.coffey at oracle.com Subject: hg: jdk8/tl/jdk: 8024952: ClassCastException in PlainSocketImpl.accept() when using custom socketImpl To: jdk8-changes at openjdk.java.net, compiler-dev at openjdk.java.net, core-libs-dev at openjdk.java.net, serviceability-dev at openjdk.java.net, security-dev at openjdk.java.net, net-dev at openjdk.java.net Message-ID: <20131002082305.2A14B62C96 at hg.openjdk.java.net> Changeset: 368172cb6dc5 Author: coffeys Date: 2013-10-02 09:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/368172cb6dc5 8024952: ClassCastException in PlainSocketImpl.accept() when using custom socketImpl Reviewed-by: chegar ! src/windows/classes/java/net/PlainSocketImpl.java + test/java/net/PlainSocketImpl/CustomSocketImplFactory.java ------------------------------ Message: 5 Date: Wed, 02 Oct 2013 10:47:26 +0200 From: Jaroslav Bachorik Subject: RFR 6523160: RuntimeMXBean.getUptime() returns negative values To: "serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net" , jmx-dev at openjdk.java.net Message-ID: <524BDD9E.1050100 at oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello, currently the JVM uptime reported by the RuntimeMXBean is based on System.currentTimeMillis() which makes it susceptible to changes of the OS time (eg. changing timezone, NTP synchronization etc.). The uptime should not depend on the system time and should be calculated using a monotonic clock source. There is already the way to get the actual JVM uptime in ticks. It is accessible as Management::timestamp() and the ticks are convertible to milliseconds using Management::ticks_to_ms(ts_ticks) thus making it very easy to switch to the monotonic clock based uptime. The patch consists of the hotspot and jdk parts. For the hotspot a new constant needs to be introduced in src/share/vm/services/jmm.h and the actual logic to obtain the uptime in milliseconds is added in src/share/vm/services/management.cpp. For the jdk the changes comprise of adding the necessary JNI bridging methods in order to get the new uptime, introducing the same constant that is used in hotspot and changes to mapfile-vers files in order to properly build the native library. Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 Webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 Thanks, -JB- ------------------------------ Message: 6 Date: Wed, 2 Oct 2013 10:49:04 +0200 From: Peter Allwin Subject: Re: RFR (S): 6313383: SA: Update jmap to support HPROF binary format "JAVA PROFILE 1.0.2" To: Fredrik Arvidsson Cc: serviceability-dev at openjdk.java.net, hotspot-runtime-dev at openjdk.java.net Message-ID: <4F092E8F-8002-4E02-9F75-519A3083AB96 at oracle.com> Content-Type: text/plain; charset="iso-8859-1" Hi Fredrik, Looks great! Thanks for fixing this, /peter On Sep 20, 2013, at 2:35 PM, Fredrik Arvidsson wrote: > Hi > > Please help me and review the changes below: > > Webrev: http://cr.openjdk.java.net/~allwin/farvidss/6313383/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-6313383 > > This change adds support for dumping large heaps (> 4G) using jmap by implementing the "JAVA PROFILE 1.0.2" file format with segmented heap dump records. > The HPROF binary format specification can be found here: https://java.net/downloads/heap-snapshot/hprof-binary-format.html. > > I added a simple test to verify that heaps smaller than 2G are dumped using the "JAVA PROFILE 1.0.1" format. The last section in the test, aiming to test the format used when dumping heaps larger than 2G, is commented out since the test system didn't like that kind of heap sizes and ultimately failed (OOM and sometimes timeout). The test should be reintroduced once we can reliably support such tests in the test system. > > Thanks 'allwin' for hosting my review :) > > Cheers > /Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131002/6d76ccd9/attachment-0001.html ------------------------------ Message: 7 Date: Wed, 02 Oct 2013 10:51:53 +0200 From: Mikael Gerdin Subject: Re: RFR (S): 8016845: SA is unable to use hsdis on windows To: Fredrik Arvidsson , serviceability-dev at openjdk.java.net, hotspot-runtime-dev at openjdk.java.net Message-ID: <524BDEA9.5020800 at oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Fredrik, On 09/20/2013 04:29 PM, Fredrik Arvidsson wrote: > Please help me review this: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8016845 > Webrev: http://cr.openjdk.java.net/~allwin/farvidss/8016845/webrev.00/ > the change looks good to me. > > Small change was made in the sa.make file for windows to compile and > link sadis.c in to sawindbg.dll providing JNI entrypoints needed to call > the hsdis disassembler from SADB on windows. A small change in > agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java to have > the correct library name when loading library depending if running on 32 > or 64 bit platform. Thanks for fixing this! /Mikael > > To test this you have to build the hsdis library yourself, since it cant > be bundled due to license issues. Instructions can be found here: > http://dropzone.nfshost.com/hsdis.htm (hint, I have pre-built binaries). > When running disassembling in HSDB (using the 'dis' command in the > console) the hsdis-amd64.dll/hsdis-i386.dll must be in the /bin > directory of the JRE/JDK used. > > Cheers > /Fredrik ------------------------------ Message: 8 Date: Wed, 2 Oct 2013 11:23:34 +0200 From: Staffan Larsen Subject: Re: RFR 6523160: RuntimeMXBean.getUptime() returns negative values To: Jaroslav Bachorik Cc: "serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net" , jmx-dev at openjdk.java.net Message-ID: <4088022F-6550-4C95-86D5-640F2E737839 at oracle.com> Content-Type: text/plain; charset=iso-8859-1 Looks good! Thanks, /Staffan On 2 okt 2013, at 10:47, Jaroslav Bachorik wrote: > Hello, > > currently the JVM uptime reported by the RuntimeMXBean is based on System.currentTimeMillis() which makes it susceptible to changes of the OS time (eg. changing timezone, NTP synchronization etc.). The uptime should not depend on the system time and should be calculated using a monotonic clock source. > > There is already the way to get the actual JVM uptime in ticks. It is accessible as Management::timestamp() and the ticks are convertible to milliseconds using Management::ticks_to_ms(ts_ticks) thus making it very easy to switch to the monotonic clock based uptime. > > The patch consists of the hotspot and jdk parts. > > For the hotspot a new constant needs to be introduced in src/share/vm/services/jmm.h and the actual logic to obtain the uptime in milliseconds is added in src/share/vm/services/management.cpp. > > For the jdk the changes comprise of adding the necessary JNI bridging methods in order to get the new uptime, introducing the same constant that is used in hotspot and changes to mapfile-vers files in order to properly build the native library. > > Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 > Webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 > > Thanks, > > -JB- ------------------------------ Message: 9 Date: Wed, 02 Oct 2013 11:28:19 +0200 From: Fredrik Arvidsson Subject: Re: RFR (S): JDK-8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes To: "serguei.spitsyn at oracle.com" Cc: serviceability-dev at openjdk.java.net, hotspot-gc-dev at openjdk.java.net, hotspot-runtime-dev at openjdk.java.net Message-ID: <524BE733.2070205 at oracle.com> Content-Type: text/plain; charset="iso-8859-1" Hi and thanks for all your comments. I have simplified the code in *instanceKlass.cpp* like suggested and here is a new webrev: http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.01/ Regarding the need to synchronize the access to ClassLoaderDataGraph I have come to the conclusion that it should be safe to call this without any additional synchronization since newly loaded and added classes are appended to the end of its 'list' of classes. This would mean that the call could 'miss' the classes added during the collection phase, but this is not a big issue. I hope that my conclusion is correct. I believe that the JvmtiGetLoadedClasses::getClassLoaderClasses(...) method is to be left alone this time since I got the impression that only SystemDictionary 'knows' about initiating class loaders. There is plenty of room for improvement and simplification of much of the code in this area, but I feel that it must wait until another time. The task to re-factor and simplify would quickly grow out of hands I'm afraid :) Cheers /Fredrik On 2013-10-01 09:34, serguei.spitsyn at oracle.com wrote: > Hi Frederik, > > > Thank you for jumping on this issue! > > > *src/share/vm/oops/instanceKlass.cpp* > 2333 int src_index = 0; > 2334 while (src_index < src_length) { > 2335 dest[dest_index++] = src[src_index++]; > 2336 } > 2337 > 2338 // If we have a hash, append it > 2339 if(hash_len > 0) { > 2340 int hash_index = 0; > 2341 while (hash_index < hash_len) { > 2342 dest[dest_index++] = hash_buf[hash_index++]; > 2343 } > 2344 } > > The above can be simplified a little bit: > // Add the actual class name > for (int src_index = 0; src_index < src_length; ) { > dest[dest_index++] = src[src_index++]; > } > // If we have a hash, append it > for (int hash_index = 0; hash_index < hash_len; ) { > dest[dest_index++] = hash_buf[hash_index++]; > } > > The conditionif(hash_len > 0) is covered by the loop itself. > > Style-related comments: > -wrong indent at the lines: 2316-2319 > - need a space after the 'if' at the lines: 2315, 2339 > > > *src/share/vm/prims/jvmtiGetLoadedClasses.cpp > > *The copyright comment must be up-to-date. > The comments at the lines 35-38, 258-260 are not valid anymore. > > > > In this review I still have an outstanding unanswered question about > > the need to synchronize the access to the: > > > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); > > and > > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); > > This kind of walking is usually done at safepoint in a VM_Operation. > You will find many examples in the jvmtiEnv.cpp, for instance, VM_GetAllStackTraces. > The suggestion from Mikael is good too. > > Should this fix include the getClassLoaderClasses() as well? > I'm still trying to realize the impact and consistency of this fix. :( > > What tests are you going to run for verification? > > Thanks, > Serguei > * > *On 9/30/13 4:45 AM, Fredrik Arvidsson wrote: >> Hi >> >> Please help me to review the changes below: >> >> Jira case: https://bugs.openjdk.java.net/browse/JDK-8024423 >> Webrev: >> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/ >> >> >> In this review I still have an outstanding unanswered question about >> the need to synchronize the access to the: >> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >> and >> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >> >> calls in >> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/src/share/vm/prims/jvmtiGetLoadedClasses.cpp.udiff.html >> >> Please give me advise on this. >> >> There will be a review soon regarding re-enabling the tests that failed because of the above bug, see: >> https://bugs.openjdk.java.net/browse/JDK-8025576 >> >> Cheers >> /Fredrik > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131002/49255ad9/attachment.html End of serviceability-dev Digest, Vol 71, Issue 7 ************************************************* "This is an e-mail from a DeLaval company. This e-mail is confidential and may also be privileged. Please delete the email and notify us immediately if you are not the intended recipient. DeLaval does not enter into contracts or contractual obligations via electronic mail, unless otherwise agreed in writing between parties concerned. Thank you." From masayoshi.okutsu at oracle.com Wed Oct 2 01:58:02 2013 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Wed, 02 Oct 2013 08:58:02 +0000 Subject: hg: jdk8/tl/jdk: 8022666: java.util.Calendar.set(int, int, int, int, int, int) documentation typo Message-ID: <20131002085900.D4ADF62C97@hg.openjdk.java.net> Changeset: 82e3150778e0 Author: okutsu Date: 2013-10-02 17:57 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82e3150778e0 8022666: java.util.Calendar.set(int,int,int,int,int,int) documentation typo Reviewed-by: peytoia ! src/share/classes/java/util/Calendar.java From jaroslav.bachorik at oracle.com Wed Oct 2 03:55:03 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 02 Oct 2013 12:55:03 +0200 Subject: jmx-dev RFR: 8024613 javax/management/remote/mandatory/connection/RMIConnector_NPETest.java failing intermittently In-Reply-To: <523C459A.3080303@oracle.com> References: <523C3F8B.6080002@oracle.com> <523C459A.3080303@oracle.com> Message-ID: <524BFB87.10808@oracle.com> On 20.9.2013 14:54, shanliang wrote: > Jaroslav, > > It is a good idea to use the RMI Testlibrary. > > Better to call: > agent.close(); > > at Line 55, close the RMIRegistry (rmid.shutdown(rmidPort) Line 55) > does not ensure the JMX connector doing full clean, it is always better > to do clean within a test. Thanks. Implemented. http://cr.openjdk.java.net/~jbachorik/8024613/webrev.01 -JB- > > Shanliang > > > Jaroslav Bachorik wrote: >> Please, review the following change for JDK-8024613 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8024613 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8024613/webrev.00/ >> >> >> The patch takes care of intermittent test failures caused by timing >> issues when starting the RMID process. It could happen that the RMID >> process hasn't been properly initialized in the timeframe of 5 seconds >> and the test would fail. >> >> The patch replaces the home-brewed RMID process management with the >> one available in the RMI Testlibrary which is used by more tests and >> therefore should be more stable. >> >> Thanks, >> >> -JB- > From jaroslav.bachorik at oracle.com Wed Oct 2 03:57:06 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 02 Oct 2013 12:57:06 +0200 Subject: [ping] Re: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <523B0B30.4020003@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> <5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com> <5231DE69.7090309@oracle.com> <523B0B30.4020003@oracle.com> Message-ID: <524BFC02.4050800@oracle.com> On 19.9.2013 16:33, Jaroslav Bachorik wrote: > The updated webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.03 > > I've moved some of the functionality to the testlibrary. > > -JB - > > On 12.9.2013 17:31, Jaroslav Bachorik wrote: >> On 09/12/2013 05:13 PM, Dmitry Samersoff wrote: >>> Jaroslav, >>> >>> CustomLauncherTest.java: >>> >>> 102: this check could be moved to switch at ll. 108 >>> otherwise test fails on "sunos" and "linux" because PLATFORM remains >>> unset. >> Good idea. Thanks. >> >>> 129: I would prefer don't have pattern like this one ever in shell >>> script. Could you prepare a list of VM's to check and just loop over it? >>> It makes test better readable. Also I think nowdays we can always use >>> server VM. >> I tried to mirror the original shell test as closely as possible. It >> would be nice if we could rely on the "server" vm only. Definitely more >> readable. >> >> -JB- >> >>> -Dmitry >>> >>> >>> On 2013-09-12 18:17, Jaroslav Bachorik wrote: >>>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: >>>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote: >>>>>> On 09/12/2013 04:45 AM, David Holmes wrote: >>>>>>> Hi Jaroslav, >>>>>>> >>>>>>> You need a copyright notice in the new file. >>>>>>> >>>>>>> As written this test can only run on a full JDK - so please add >>>>>>> it to >>>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come >>>>>>> from the test-jdk? And use the VMOPTS passed to the test?) >>>>>>> >>>>>>> Is there a reason this test can't run on OSX? I know it would need >>>>>>> further modification but was wondering if there is something >>>>>>> inherent in >>>>>>> the test that makes it inapplicable to OSX. >>>>>>> >>>>>>> I think the test would be a lot simpler if the jdk tests had the >>>>>>> hotspot >>>>>>> test library's process tools available. :( >>>>>> We have some, is there an obvious gap? >>>>>> >>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ >>>>>> >>>>> Hm, thanks for the info. I should have used this library instead. >>>>> >>>>> Please, stand by for the updated webrev. >>>> I was able to get rid off the JCMD. Using the testlibrary the target >>>> application can recognize its own PID and print it to its stdout. The >>>> main application then just reads the stdout to parse the PID. No need >>>> for JCMD any more. >>>> >>>> I could not find a way to remove the dependency on "test.jdk" system >>>> property. According to the jtreg web documentation >>>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a >>>> "test.java" >>>> system property should be available but in fact is not. But it seems >>>> that the testlibrary uses "test.jdk" system property too. >>>> >>>> The test does not run on OSX because nobody built the launcher >>>> binary :) >>>> I think it is a kind of DIY so I took the liberty of adding a >>>> linux-amd64 launcher while working on the test. >>>> >>>> While working with the test library I realized I was missing a crucial >>>> feature (at least for my purposes) - waiting for a certain message to >>>> appear in the stdout/stderr of the launched process. Very often I need >>>> to wait for the target process to get to certain point before the test >>>> can be allowed to continue - and the point is indicated by a message in >>>> stdout/stderr. Currently all the proc tools are designed to work in >>>> "batch" mode - the whole stdout/stderr is captured in strings and >>>> analyzed after the target process died - and are not suitable for this >>>> kind of usage. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 >>>> >>>>> -JB- >>>>> >>>>>> >>>>>> -Chris. >>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>>>>>> Please, review the patch for an intermittently failing test. >>>>>>>> >>>>>>>> The test is a shell test, using files for the interprocess >>>>>>>> synchronization. This leads to intermittent failures. >>>>>>>> >>>>>>>> In order to fix this the test is rewritten in Java - the original >>>>>>>> functionality and outputs should be 100% preserved. The patch is >>>>>>>> unfortunately a bit difficult to follow since there is no >>>>>>>> similarity >>>>>>>> between the *.sh and *.java file so one needs to go through the new >>>>>>>> source in whole. >>>>>>>> >>>>>>>> The changes in "launcher" files are all about adding permissions to >>>>>>>> execute (0755) and as such the webrev shows no differences. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Issue : JDK-8004926 >>>>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>>>>>> >>>>>>>> -JB- >>>>>>>> >>> > From jaroslav.bachorik at oracle.com Wed Oct 2 03:59:33 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 02 Oct 2013 12:59:33 +0200 Subject: [ping] Re: RFR: 8022220 Intermittent test failures in javax/management/remote/mandatory/connection/RMIConnectionIdTest.java In-Reply-To: <52308A5B.8020206@oracle.com> References: <52308389.6060001@oracle.com> <523086E2.4050307@oracle.com> <52308A5B.8020206@oracle.com> Message-ID: <524BFC95.60605@oracle.com> On 11.9.2013 17:20, Jaroslav Bachorik wrote: > On 09/11/2013 05:06 PM, shanliang wrote: >> The fix looks OK for me. >> >> I am wondering that in case of loopback address, is it better to always >> using "127.0.0.1" to generate a connectionId? this will make sure to >> have a unique id. > > I am afraid we are getting the 127.0.1.1 variant from RMI > (java.rmi.server.RemoteServer#getClientHost()). I don't know what else > might break if we start fiddling around with it. For now I would better > keep it the simplest possible. > > -JB- > >> >> Shanliang >> >> Jaroslav Bachorik wrote: >>> Please, review this simple patch for an intermittently failing test. >>> >>> The test fails in cases when the connection loopback is resolved to be >>> 127.0.1.1 - it may happen under certain circumstances in eg. Ubuntu. The >>> test does not anticipate this possibility and requires the loopback >>> address to be exactly 127.0.0.1 >>> >>> The test will end comparing 127.0.0.1 against 127.0.1.1 and will >>> consider them non equal even though they are both the same loopback. The >>> patch adds a bit of flexibility to the test allowing for any two valid >>> loopback addresses (127.0.0.0/8) to be equal. >>> >>> Issue : JDK-8022220 >>> Webrev : http://cr.openjdk.java.net/~jbachorik/8022220/webrev.00 >>> >>> Thanks, >>> >>> -JB- >>> >> > From paul.sandoz at oracle.com Wed Oct 2 05:25:58 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 02 Oct 2013 12:25:58 +0000 Subject: hg: jdk8/tl/jdk: 8025535: Unsafe typecast in java.util.stream.SortedOps Message-ID: <20131002122644.6D9B862C9D@hg.openjdk.java.net> Changeset: e1b04fd49204 Author: psandoz Date: 2013-10-01 18:20 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e1b04fd49204 8025535: Unsafe typecast in java.util.stream.SortedOps Reviewed-by: mduigou, chegar ! src/share/classes/java/util/stream/SortedOps.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java From dmitry.samersoff at oracle.com Wed Oct 2 07:11:02 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 02 Oct 2013 18:11:02 +0400 Subject: jmx-dev RFR: 8022220 Intermittent test failures in javax/management/remote/mandatory/connection/RMIConnectionIdTest.java In-Reply-To: <52308389.6060001@oracle.com> References: <52308389.6060001@oracle.com> Message-ID: <524C2976.8020109@oracle.com> Jaroslav, As a far as loopback address could be resolved to any of 127.0.0.0/8 client and server have to use the same loopback address. Generally speaking it's not required for 127.0.1.1 to be able to talk to 127.0.0.1 and we are in risk to get a weird fail instead of clear error message. -Dmitry On 2013-09-11 18:51, Jaroslav Bachorik wrote: > Please, review this simple patch for an intermittently failing test. > > The test fails in cases when the connection loopback is resolved to be > 127.0.1.1 - it may happen under certain circumstances in eg. Ubuntu. The > test does not anticipate this possibility and requires the loopback > address to be exactly 127.0.0.1 > > The test will end comparing 127.0.0.1 against 127.0.1.1 and will > consider them non equal even though they are both the same loopback. The > patch adds a bit of flexibility to the test allowing for any two valid > loopback addresses (127.0.0.0/8) to be equal. > > Issue : JDK-8022220 > Webrev : http://cr.openjdk.java.net/~jbachorik/8022220/webrev.00 > > Thanks, > > -JB- > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From ron.durbin at oracle.com Wed Oct 2 07:44:50 2013 From: ron.durbin at oracle.com (Ron Durbin) Date: Wed, 2 Oct 2013 07:44:50 -0700 (PDT) Subject: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <524B8A78.9040807@oracle.com> References: <523D144E.4000002@oracle.com> <524B8A78.9040807@oracle.com> Message-ID: Dan You have my thumbs up changes look good > -----Original Message----- > From: David Holmes > Sent: Tuesday, October 01, 2013 8:53 PM > To: Daniel Daugherty > Cc: serviceability-dev at openjdk.java.net; build-dev; hotspot-runtime-dev at openjdk.java.net > Subject: Re: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) > > Hi Dan, > > Overall thumbs up. A couple of minor issues that need fixing. A few meta-comments (I hate > seeing all this stuff duplicated again and again. > > David > ----- > > - common/autoconf/hotspot-spec.gmk.in > > Seems a good simplification. > > ---- > > - common/autoconf/jdk-options.m4 > > No comment. > > --- > > - common/makefiles/NativeCompilation.gmk > > So JDK .diz support is phase 2? :) > > The Windows changes here seem okay given that on windows a .debuginfo file should never be > in the target list. > > --- > > - hotspot/make/Makefile > > + $(EXPORT_CLIENT_DIR)/%.dSYM: > $(MINIMAL1_BUILD_DIR)/%.dSYM > > EXPORT_CLIENT_DIR should be EXPORT_MINIMAL_DIR. > > For fun you can try building minimal on OSX, but I don't know how far you will get: > > --with-jvm-variants=client,server,minimal1 > > I'll point out obvious issues with minimal VM support anyway. > > --- > > - hotspot/make/bsd/Makefile > > No comment. > > - hotspot/make/bsd/makefiles/buildtree.make > > No comment. > > - make/bsd/makefiles/defs.make > > Note that the whole jdk6_or_earlier logic is defunct as this will never be used for jdk6 or > earlier. But best to clean all that up at the one time. > > Sadly I never found a satisfactory solution to the multiplicity and verbosity of the FDS > messages, so OSX builds will now be afflicted by them too. > > 328 else > 329 EXPORT_LIST += $(EXPORT_MINIMAL_DIR)/libjvm.debuginfo > 330 endif > > This pre-existing minimal VM code needs to be modified to reference the dSYM directory on > OSX as per the client/server cases. > > --- > > - hotspot/make/bsd/makefiles/dtrace.make > > Note related to your changes but I don't think any of the "64" directory stuff has any > meaning outside of Solaris. > > 102 dsymutil $@ > > I think dsymutil should be assigned to a variable in the platform defs.make as with other > tools. > > Would be nice if objcopy/dsymutil could be hidden behind a single SYM_TOOL variables as well > so there wasn't so much duplication of the process. You could have a single set of > instructions to invoke SYM_TOOL, STRIP and ZIP (strip would be skipped of course because > STRIP_POLICY would never be set on osx). Just wishful thinking ... > > --- > > - hotspot/make/bsd/makefiles/gcc.make > > + FASTDEBUG_CFLAGS += $(DEBUG_CFLAGS/$(BUILDARCH)) > > should be > > + FASTDEBUG_CFLAGS += $(FASTDEBUG_CFLAGS/$(BUILDARCH)) > > Don't we need the USE_CLANG variations here as for linux? > > --- > > - hotspot/make/bsd/makefiles/jsig.make > - hotspot/make/bsd/makefiles/saproc.make > > Similar comments to dtrace.make > > --- > > - make/bsd/makefiles/universal.gmk > > I did not understand the additional logic here: > > 63 # Copy built non-universal binaries in place > 64 $(UNIVERSAL_COPY_LIST): > 65 BUILT_COPY_FILES="`find > $(EXPORT_JRE_LIB_DIR)/{i386,amd64}/$(subst $(EXPORT_JRE_LIB_DIR)/,,$@) > 2>/dev/null`"; \ > 66 if [ -n "$${BUILT_COPY_FILES}" ]; then \ > 67 for i in $${BUILT_COPY_FILES}; do \ > 68 if [ -f $${i} ]; then \ > 69 $(MKDIR) -p $(shell dirname $@); \ > 70 $(CP) -R $${i} $@; \ > 71 fi; \ > 72 if [ -d $${i} ]; then \ > 73 $(MKDIR) -p $@; \ > 74 fi; \ > 75 done; \ > 76 fi > > until I realized that foo.dSYM is a directory not a file! Even so don't > you want to copy the contents of the directory across ? > > BTW: UNIVERSAL_COPY_LIST doesn't handle minimal VM. > > --- > > - make/bsd/makefiles/vm.make > > Similar comments to dtrace.make ref dsymutil. > > --- > > - hotspot/make/defs.make > > No comment. > > --- > > - jdk/make/common/Defs-macosx.gmk > > No comment > > - jdk/makefiles/Tools.gmk > > Not sure about this one. Logically is seems correct but up to now this > has been defined for everything without it seeming to cause a problem. > So why do we need to change it and what impact will it have? > > David > ----- > > On 21/09/2013 1:36 PM, Daniel D. Daugherty wrote: > > Greetings, > > > > I have the initial support for Full Debug Symbols (FDS) on MacOS X done > > and ready for review: > > > > 7165611 implement Full Debug Symbols on MacOS X hotspot > > https://bugs.openjdk.java.net/browse/JDK-7165611 > > > > Here is the JDK8/HSX-25 webrev URL: > > > > OpenJDK: > > http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ > > Internal: > > http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ > > > > This webrev includes changes for the follow repos: > > > > jdk8 > > jdk8/hotspot > > jdk8/jdk > > jdk8/jdk/make/closed > > > > Once these changes are approved, I'm planning to push them to > > RT_Baseline. From there, they can follow the normal path to > > Main_Baseline and eventually JDK8. > > > > This work enables FDS on MacOS X for the 'hotspot' repo; the changes in > > the other repos are necessary to support importing the .diz files from > > the MacOS X 'hotspot' build into the forest build. I also fixed a few > > FDS related errors in the magic incantations for the new build. This is > > mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported > > from Solaris. In other words, this is Frankenstein's monster... > > > > Thanks to Staffan Larsen for providing an initial set of changes > > which I morphed into what you see here. > > > > Testing: > > - JPRT HSX build and test on all platforms; verification of .diz > > files in the MacOS X JPRT bundles > > - JPRT JDK8 forest build and test on all platforms; verification of > > .diz files in the MacOS X JPRT bundles > > Note: In previous FDS changesets, I also did a standalone 'jdk' > > repo build and test, but that no longer seems to work. > > > > As always, comments, questions and suggestions are welcome. > > > > Dan From staffan.larsen at oracle.com Wed Oct 2 05:37:32 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Wed, 02 Oct 2013 12:37:32 +0000 Subject: hg: jdk8/tl/jdk: 6696975: JTop plugin fails if connected readonly to target JVM Message-ID: <20131002123745.087CF62C9E@hg.openjdk.java.net> Changeset: 3bb89c509d59 Author: egahlin Date: 2013-10-01 17:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3bb89c509d59 6696975: JTop plugin fails if connected readonly to target JVM Reviewed-by: mchung, jbachorik, sla, sjiang ! src/share/demo/management/JTop/JTop.java From daniel.daugherty at oracle.com Wed Oct 2 08:32:55 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 02 Oct 2013 09:32:55 -0600 Subject: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <524B8A78.9040807@oracle.com> References: <523D144E.4000002@oracle.com> <524B8A78.9040807@oracle.com> Message-ID: <524C3CA7.5070705@oracle.com> David, Thanks for the thorough review (as always)! It will take me a while to process all the comments, but another reply will be forthcoming. Dan On 10/1/13 8:52 PM, David Holmes wrote: > Hi Dan, > > Overall thumbs up. A couple of minor issues that need fixing. A few > meta-comments (I hate seeing all this stuff duplicated again and again. > > David > ----- > > - common/autoconf/hotspot-spec.gmk.in > > Seems a good simplification. > > ---- > > - common/autoconf/jdk-options.m4 > > No comment. > > --- > > - common/makefiles/NativeCompilation.gmk > > So JDK .diz support is phase 2? :) > > The Windows changes here seem okay given that on windows a .debuginfo > file should never be in the target list. > > --- > > - hotspot/make/Makefile > > + $(EXPORT_CLIENT_DIR)/%.dSYM: $(MINIMAL1_BUILD_DIR)/%.dSYM > > EXPORT_CLIENT_DIR should be EXPORT_MINIMAL_DIR. > > For fun you can try building minimal on OSX, but I don't know how far > you will get: > > --with-jvm-variants=client,server,minimal1 > > I'll point out obvious issues with minimal VM support anyway. > > --- > > - hotspot/make/bsd/Makefile > > No comment. > > - hotspot/make/bsd/makefiles/buildtree.make > > No comment. > > - make/bsd/makefiles/defs.make > > Note that the whole jdk6_or_earlier logic is defunct as this will > never be used for jdk6 or earlier. But best to clean all that up at > the one time. > > Sadly I never found a satisfactory solution to the multiplicity and > verbosity of the FDS messages, so OSX builds will now be afflicted by > them too. > > 328 else > 329 EXPORT_LIST += $(EXPORT_MINIMAL_DIR)/libjvm.debuginfo > 330 endif > > This pre-existing minimal VM code needs to be modified to reference > the dSYM directory on OSX as per the client/server cases. > > --- > > - hotspot/make/bsd/makefiles/dtrace.make > > Note related to your changes but I don't think any of the "64" > directory stuff has any meaning outside of Solaris. > > 102 dsymutil $@ > > I think dsymutil should be assigned to a variable in the platform > defs.make as with other tools. > > Would be nice if objcopy/dsymutil could be hidden behind a single > SYM_TOOL variables as well so there wasn't so much duplication of the > process. You could have a single set of instructions to invoke > SYM_TOOL, STRIP and ZIP (strip would be skipped of course because > STRIP_POLICY would never be set on osx). Just wishful thinking ... > > --- > > - hotspot/make/bsd/makefiles/gcc.make > > + FASTDEBUG_CFLAGS += $(DEBUG_CFLAGS/$(BUILDARCH)) > > should be > > + FASTDEBUG_CFLAGS += $(FASTDEBUG_CFLAGS/$(BUILDARCH)) > > Don't we need the USE_CLANG variations here as for linux? > > --- > > - hotspot/make/bsd/makefiles/jsig.make > - hotspot/make/bsd/makefiles/saproc.make > > Similar comments to dtrace.make > > --- > > - make/bsd/makefiles/universal.gmk > > I did not understand the additional logic here: > > 63 # Copy built non-universal binaries in place > 64 $(UNIVERSAL_COPY_LIST): > 65 BUILT_COPY_FILES="`find > $(EXPORT_JRE_LIB_DIR)/{i386,amd64}/$(subst $(EXPORT_JRE_LIB_DIR)/,,$@) > 2>/dev/null`"; \ > 66 if [ -n "$${BUILT_COPY_FILES}" ]; then \ > 67 for i in $${BUILT_COPY_FILES}; do \ > 68 if [ -f $${i} ]; then \ > 69 $(MKDIR) -p $(shell dirname $@); \ > 70 $(CP) -R $${i} $@; \ > 71 fi; \ > 72 if [ -d $${i} ]; then \ > 73 $(MKDIR) -p $@; \ > 74 fi; \ > 75 done; \ > 76 fi > > until I realized that foo.dSYM is a directory not a file! Even so > don't you want to copy the contents of the directory across ? > > BTW: UNIVERSAL_COPY_LIST doesn't handle minimal VM. > > --- > > - make/bsd/makefiles/vm.make > > Similar comments to dtrace.make ref dsymutil. > > --- > > - hotspot/make/defs.make > > No comment. > > --- > > - jdk/make/common/Defs-macosx.gmk > > No comment > > - jdk/makefiles/Tools.gmk > > Not sure about this one. Logically is seems correct but up to now this > has been defined for everything without it seeming to cause a problem. > So why do we need to change it and what impact will it have? > > David > ----- > > On 21/09/2013 1:36 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have the initial support for Full Debug Symbols (FDS) on MacOS X done >> and ready for review: >> >> 7165611 implement Full Debug Symbols on MacOS X hotspot >> https://bugs.openjdk.java.net/browse/JDK-7165611 >> >> Here is the JDK8/HSX-25 webrev URL: >> >> OpenJDK: >> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >> Internal: >> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >> >> This webrev includes changes for the follow repos: >> >> jdk8 >> jdk8/hotspot >> jdk8/jdk >> jdk8/jdk/make/closed >> >> Once these changes are approved, I'm planning to push them to >> RT_Baseline. From there, they can follow the normal path to >> Main_Baseline and eventually JDK8. >> >> This work enables FDS on MacOS X for the 'hotspot' repo; the changes in >> the other repos are necessary to support importing the .diz files from >> the MacOS X 'hotspot' build into the forest build. I also fixed a few >> FDS related errors in the magic incantations for the new build. This is >> mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported >> from Solaris. In other words, this is Frankenstein's monster... >> >> Thanks to Staffan Larsen for providing an initial set of changes >> which I morphed into what you see here. >> >> Testing: >> - JPRT HSX build and test on all platforms; verification of .diz >> files in the MacOS X JPRT bundles >> - JPRT JDK8 forest build and test on all platforms; verification of >> .diz files in the MacOS X JPRT bundles >> Note: In previous FDS changesets, I also did a standalone 'jdk' >> repo build and test, but that no longer seems to work. >> >> As always, comments, questions and suggestions are welcome. >> >> Dan From daniel.daugherty at oracle.com Wed Oct 2 08:33:59 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 02 Oct 2013 09:33:59 -0600 Subject: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: References: <523D144E.4000002@oracle.com> <524B8A78.9040807@oracle.com> Message-ID: <524C3CE7.90500@oracle.com> Ron, Thanks for the review. Dan On 10/2/13 8:44 AM, Ron Durbin wrote: > Dan > > You have my thumbs up changes look good > > >> -----Original Message----- >> >> On 21/09/2013 1:36 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have the initial support for Full Debug Symbols (FDS) on MacOS X done >>> and ready for review: >>> >>> 7165611 implement Full Debug Symbols on MacOS X hotspot >>> https://bugs.openjdk.java.net/browse/JDK-7165611 >>> >>> Here is the JDK8/HSX-25 webrev URL: >>> >>> OpenJDK: >>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >>> Internal: >>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >>> >>> This webrev includes changes for the follow repos: >>> >>> jdk8 >>> jdk8/hotspot >>> jdk8/jdk >>> jdk8/jdk/make/closed >>> >>> Once these changes are approved, I'm planning to push them to >>> RT_Baseline. From there, they can follow the normal path to >>> Main_Baseline and eventually JDK8. >>> >>> This work enables FDS on MacOS X for the 'hotspot' repo; the changes in >>> the other repos are necessary to support importing the .diz files from >>> the MacOS X 'hotspot' build into the forest build. I also fixed a few >>> FDS related errors in the magic incantations for the new build. This is >>> mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported >>> from Solaris. In other words, this is Frankenstein's monster... >>> >>> Thanks to Staffan Larsen for providing an initial set of changes >>> which I morphed into what you see here. >>> >>> Testing: >>> - JPRT HSX build and test on all platforms; verification of .diz >>> files in the MacOS X JPRT bundles >>> - JPRT JDK8 forest build and test on all platforms; verification of >>> .diz files in the MacOS X JPRT bundles >>> Note: In previous FDS changesets, I also did a standalone 'jdk' >>> repo build and test, but that no longer seems to work. >>> >>> As always, comments, questions and suggestions are welcome. >>> >>> Dan From vicente.romero at oracle.com Wed Oct 2 09:06:03 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 02 Oct 2013 16:06:03 +0000 Subject: hg: jdk8/tl/langtools: 8023679: Improve error message for '_' used as a lambda parameter name Message-ID: <20131002160614.8D2F162CA7@hg.openjdk.java.net> Changeset: 1e6088da1740 Author: vromero Date: 2013-10-02 17:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1e6088da1740 8023679: Improve error message for '_' used as a lambda parameter name Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/UnderscoreInLambdaExpression.java From bradford.wetmore at oracle.com Wed Oct 2 09:41:47 2013 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Wed, 02 Oct 2013 16:41:47 +0000 Subject: hg: jdk8/tl/jdk: 8025694: Rename getStrongSecureRandom based on feedback; ... Message-ID: <20131002164200.1A7E462CAB@hg.openjdk.java.net> Changeset: a6ac824b463d Author: wetmore Date: 2013-10-02 09:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a6ac824b463d 8025694: Rename getStrongSecureRandom based on feedback 8014838: getStrongSecureRandom() should require at least one implementation Reviewed-by: mullan, darcy ! src/share/classes/java/security/SecureRandom.java ! src/share/lib/security/java.security-windows ! test/sun/security/provider/SecureRandom/StrongSecureRandom.java From dmitry.samersoff at oracle.com Wed Oct 2 11:43:56 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 02 Oct 2013 22:43:56 +0400 Subject: RR(S): JDK-8022616 u4 should not be used as a type for thread_id In-Reply-To: <5241E953.3060707@oracle.com> References: <524145D4.5020009@oracle.com> <5241DFB2.7020800@oracle.com> <5241E19B.5090308@oracle.com> <5241E953.3060707@oracle.com> Message-ID: <524C696C.5020004@oracle.com> Serguei, I run all runtime tests on MAC OS X - lots of tests fails[1], but this numners is exactly the same with or without my fix. I'd considered it as a good result and plan to push changes tomorrow. Do you have any concerns? [1] TOTAL TESTS IN RUN: 1043 TEST PASS: 502; 48% rate TEST FAIL: 541; 51% rate TEST UNDEFINED: 0; 0% rate TEST INCOMPLETE: 0; 0% rate TESTS NOT RUN: 0 TOTAL TEST IN TESTLIST: 1043 -Dmitry On 2013-09-24 23:34, serguei.spitsyn at oracle.com wrote: > On 9/24/13 12:01 PM, Dmitry Samersoff wrote: >> Sergey, >> >> I'm rely on JPRT in testing. Also I run some tests on FreeBSD. > > It should not be too hard to run the same subset of tests on Mac OS, right? > >> >> So if you think I should run extra tests, let me know which one, I'll >> run it. >> >> Actually the fix doesn't change MacOS X implementation - just move a >> call to ::pthread_mach_thread_np to different place so I don't expect >> any problem. > > It is what we think about the code change. :) > In fact, the change is non-trivial. > It is a good idea to test it anyway. > Not sure the JPRT covers this well. > > Thanks, > Serguei > >> >> -Dmitry >> >> >> On 2013-09-24 22:53, serguei.spitsyn at oracle.com wrote: >>> This looks good module Staffan comment on guarantee. >>> >>> How do you test it? >>> Also, should it be tested on Mac OS as well? >>> >>> >>> Thanks, >>> Serguei >>> >>> On 9/24/13 12:57 AM, Dmitry Samersoff wrote: >>>> Please review changes: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8022616/webrev.02/ >>>> >>>> Story: >>>> >>>> Tracing framework expect u4 as an id of thread >>>> >>>> pthread_t chosen as a tread id for variety of BSD platforms couldn't be >>>> converted to u4 so it cause compilation failure on BSD x64 >>>> >>>> Solution: >>>> >>>> Change thread_id to pid_t and get this id directly from kernel, the >>>> same manner as Linux code does. Mac Os X still uses mach_port >>>> instead of >>>> thread id. >>>> >>>> Tested on FreeBSD and OpenBSD and also code passed jprt. >>>> >>>> -Dmitry >>>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From christian.tornqvist at oracle.com Wed Oct 2 12:03:19 2013 From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com) Date: Wed, 02 Oct 2013 19:03:19 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8025671: Test name changed, test list not updated. Test6878713.sh Message-ID: <20131002190323.5A39B62CB8@hg.openjdk.java.net> Changeset: d574419c5372 Author: mseledtsov Date: 2013-10-02 15:17 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d574419c5372 8025671: Test name changed, test list not updated. Test6878713.sh Summary: Removed the obsolete test from the test group file Reviewed-by: sla, ctornqvi, dholmes ! test/TEST.groups From serguei.spitsyn at oracle.com Wed Oct 2 12:05:40 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 02 Oct 2013 12:05:40 -0700 Subject: RR(S): JDK-8022616 u4 should not be used as a type for thread_id In-Reply-To: <524C696C.5020004@oracle.com> References: <524145D4.5020009@oracle.com> <5241DFB2.7020800@oracle.com> <5241E19B.5090308@oracle.com> <5241E953.3060707@oracle.com> <524C696C.5020004@oracle.com> Message-ID: <524C6E84.7020609@oracle.com> Dmitry, Thank you for running the tests, it is good to be safe. In general it is Ok to judge on the fix quality basing on the test result differences. But I'm surprised the TEST FAIL rate is so high (is it normal for Mac OS?). You may want to take a look how many of them are unexpected. It is in the file tonga.output/testlist.unexpected. Thanks, Serguei On 10/2/13 11:43 AM, Dmitry Samersoff wrote: > Serguei, > > I run all runtime tests on MAC OS X - lots of tests fails[1], but this > numners is exactly the same with or without my fix. > > I'd considered it as a good result and plan to push changes tomorrow. > > Do you have any concerns? > > [1] > TOTAL TESTS IN RUN: 1043 > TEST PASS: 502; 48% rate > TEST FAIL: 541; 51% rate > TEST UNDEFINED: 0; 0% rate > TEST INCOMPLETE: 0; 0% rate > TESTS NOT RUN: 0 > > TOTAL TEST IN TESTLIST: 1043 > > -Dmitry > > > > > On 2013-09-24 23:34, serguei.spitsyn at oracle.com wrote: >> On 9/24/13 12:01 PM, Dmitry Samersoff wrote: >>> Sergey, >>> >>> I'm rely on JPRT in testing. Also I run some tests on FreeBSD. >> It should not be too hard to run the same subset of tests on Mac OS, right? >> >>> So if you think I should run extra tests, let me know which one, I'll >>> run it. >>> >>> Actually the fix doesn't change MacOS X implementation - just move a >>> call to ::pthread_mach_thread_np to different place so I don't expect >>> any problem. >> It is what we think about the code change. :) >> In fact, the change is non-trivial. >> It is a good idea to test it anyway. >> Not sure the JPRT covers this well. >> >> Thanks, >> Serguei >> >>> -Dmitry >>> >>> >>> On 2013-09-24 22:53, serguei.spitsyn at oracle.com wrote: >>>> This looks good module Staffan comment on guarantee. >>>> >>>> How do you test it? >>>> Also, should it be tested on Mac OS as well? >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 9/24/13 12:57 AM, Dmitry Samersoff wrote: >>>>> Please review changes: >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8022616/webrev.02/ >>>>> >>>>> Story: >>>>> >>>>> Tracing framework expect u4 as an id of thread >>>>> >>>>> pthread_t chosen as a tread id for variety of BSD platforms couldn't be >>>>> converted to u4 so it cause compilation failure on BSD x64 >>>>> >>>>> Solution: >>>>> >>>>> Change thread_id to pid_t and get this id directly from kernel, the >>>>> same manner as Linux code does. Mac Os X still uses mach_port >>>>> instead of >>>>> thread id. >>>>> >>>>> Tested on FreeBSD and OpenBSD and also code passed jprt. >>>>> >>>>> -Dmitry >>>>> > From dmitry.samersoff at oracle.com Wed Oct 2 15:40:13 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 03 Oct 2013 02:40:13 +0400 Subject: RR(S): JDK-8022616 u4 should not be used as a type for thread_id In-Reply-To: <524C6E84.7020609@oracle.com> References: <524145D4.5020009@oracle.com> <5241DFB2.7020800@oracle.com> <5241E19B.5090308@oracle.com> <5241E953.3060707@oracle.com> <524C696C.5020004@oracle.com> <524C6E84.7020609@oracle.com> Message-ID: <524CA0CD.6060006@oracle.com> Serguei, UTE attempts to run windows specific (dotnet) tests[1] and it cause huge failure rate. I'd contacted SQE (Leonid) and he is in process of investigation whether it is result of wrong MAC setup or bug in latest UTE. I'd checked - none of these failures is related to my fix. [1] "/Users/dsamerso/ute/local/common/testbase/sqe/8/vm/vm/bin/bin/macos-amd64/runtime/invoker.exe" (in directory "/Users/dsamerso/UTEwork/ResultDir/allocLargeConcurent_copy_8"): error=2, No such file or directory" during execution of "${TONGA_EXECUTE} ${TEST_ARGS} 1>${test_work_dir}/${test_name}.eout" -Dmitry On 2013-10-02 23:05, serguei.spitsyn at oracle.com wrote: > Dmitry, > > Thank you for running the tests, it is good to be safe. > > In general it is Ok to judge on the fix quality basing on the test > result differences. > But I'm surprised the TEST FAIL rate is so high (is it normal for Mac OS?). > You may want to take a look how many of them are unexpected. > It is in the file tonga.output/testlist.unexpected. > > Thanks, > Serguei > > On 10/2/13 11:43 AM, Dmitry Samersoff wrote: >> Serguei, >>reads >> I run all runtime tests on MAC OS X - lots of tests fails[1], but this >> numners is exactly the same with or without my fix. >> >> I'd considered it as a good result and plan to push changes tomorrow. >> >> Do you have any concerns? >> >> [1] >> TOTAL TESTS IN RUN: 1043 >> TEST PASS: 502; 48% rate >> TEST FAIL: 541; 51% rate >> TEST UNDEFINED: 0; 0% rate >> TEST INCOMPLETE: 0; 0% rate >> TESTS NOT RUN: 0 >> >> TOTAL TEST IN TESTLIST: 1043 >> >> -Dmitry >> >> >> >> >> On 2013-09-24 23:34, serguei.spitsyn at oracle.com wrote: >>> On 9/24/13 12:01 PM, Dmitry Samersoff wrote: >>>> Sergey, >>>> >>>> I'm rely on JPRT in testing. Also I run some tests on FreeBSD. >>> It should not be too hard to run the same subset of tests on Mac OS, >>> right? >>> >>>> So if you think I should run extra tests, let me know which one, >>>> I'll >>>> run it. >>>> >>>> Actually the fix doesn't change MacOS X implementation - just move a >>>> call to ::pthread_mach_thread_np to different place so I don't expect >>>> any problem. >>> It is what we think about the code change. :) >>> In fact, the change is non-trivial. >>> It is a good idea to test it anyway. >>> Not sure the JPRT covers this well. >>> >>> Thanks, >>> Serguei >>> >>>> -Dmitry >>>> >>>> >>>> On 2013-09-24 22:53, serguei.spitsyn at oracle.com wrote: >>>>> This looks good module Staffan comment on guarantee. >>>>> >>>>> How do you test it? >>>>> Also, should it be tested on Mac OS as well? >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 9/24/13 12:57 AM, Dmitry Samersoff wrote: >>>>>> Please review changes: >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8022616/webrev.02/ >>>>>> >>>>>> Story: >>>>>> >>>>>> Tracing framework expect u4 as an id of thread >>>>>> >>>>>> pthread_t chosen as a tread id for variety of BSD platforms >>>>>> couldn't be >>>>>> converted to u4 so it cause compilation failure on BSD x64 >>>>>> >>>>>> Solution: >>>>>> >>>>>> Change thread_id to pid_t and get this id directly from kernel, the >>>>>> same manner as Linux code does. Mac Os X still uses mach_port >>>>>> instead of >>>>>> thread id. >>>>>> >>>>>> Tested on FreeBSD and OpenBSD and also code passed jprt. >>>>>> >>>>>> -Dmitry >>>>>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Wed Oct 2 15:59:27 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 02 Oct 2013 15:59:27 -0700 Subject: RR(S): JDK-8022616 u4 should not be used as a type for thread_id In-Reply-To: <524CA0CD.6060006@oracle.com> References: <524145D4.5020009@oracle.com> <5241DFB2.7020800@oracle.com> <5241E19B.5090308@oracle.com> <5241E953.3060707@oracle.com> <524C696C.5020004@oracle.com> <524C6E84.7020609@oracle.com> <524CA0CD.6060006@oracle.com> Message-ID: <524CA54F.3060802@oracle.com> Ok. Thanks, Dmitry! Serguei On 10/2/13 3:40 PM, Dmitry Samersoff wrote: > Serguei, > > UTE attempts to run windows specific (dotnet) tests[1] and it cause huge > failure rate. > > I'd contacted SQE (Leonid) and he is in process of investigation > whether it is result of wrong MAC setup or bug in latest UTE. > > I'd checked - none of these failures is related to my fix. > > [1] > > "/Users/dsamerso/ute/local/common/testbase/sqe/8/vm/vm/bin/bin/macos-amd64/runtime/invoker.exe" > (in directory > "/Users/dsamerso/UTEwork/ResultDir/allocLargeConcurent_copy_8"): > error=2, No such file or directory" during execution of > "${TONGA_EXECUTE} ${TEST_ARGS} 1>${test_work_dir}/${test_name}.eout" > > -Dmitry > > > On 2013-10-02 23:05, serguei.spitsyn at oracle.com wrote: >> Dmitry, >> >> Thank you for running the tests, it is good to be safe. >> >> In general it is Ok to judge on the fix quality basing on the test >> result differences. >> But I'm surprised the TEST FAIL rate is so high (is it normal for Mac OS?). >> You may want to take a look how many of them are unexpected. >> It is in the file tonga.output/testlist.unexpected. >> >> Thanks, >> Serguei >> >> On 10/2/13 11:43 AM, Dmitry Samersoff wrote: >>> Serguei, >>> reads >>> I run all runtime tests on MAC OS X - lots of tests fails[1], but this >>> numners is exactly the same with or without my fix. >>> >>> I'd considered it as a good result and plan to push changes tomorrow. >>> >>> Do you have any concerns? >>> >>> [1] >>> TOTAL TESTS IN RUN: 1043 >>> TEST PASS: 502; 48% rate >>> TEST FAIL: 541; 51% rate >>> TEST UNDEFINED: 0; 0% rate >>> TEST INCOMPLETE: 0; 0% rate >>> TESTS NOT RUN: 0 >>> >>> TOTAL TEST IN TESTLIST: 1043 >>> >>> -Dmitry >>> >>> >>> >>> >>> On 2013-09-24 23:34, serguei.spitsyn at oracle.com wrote: >>>> On 9/24/13 12:01 PM, Dmitry Samersoff wrote: >>>>> Sergey, >>>>> >>>>> I'm rely on JPRT in testing. Also I run some tests on FreeBSD. >>>> It should not be too hard to run the same subset of tests on Mac OS, >>>> right? >>>> >>>>> So if you think I should run extra tests, let me know which one, >>>>> I'll >>>>> run it. >>>>> >>>>> Actually the fix doesn't change MacOS X implementation - just move a >>>>> call to ::pthread_mach_thread_np to different place so I don't expect >>>>> any problem. >>>> It is what we think about the code change. :) >>>> In fact, the change is non-trivial. >>>> It is a good idea to test it anyway. >>>> Not sure the JPRT covers this well. >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2013-09-24 22:53, serguei.spitsyn at oracle.com wrote: >>>>>> This looks good module Staffan comment on guarantee. >>>>>> >>>>>> How do you test it? >>>>>> Also, should it be tested on Mac OS as well? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 9/24/13 12:57 AM, Dmitry Samersoff wrote: >>>>>>> Please review changes: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8022616/webrev.02/ >>>>>>> >>>>>>> Story: >>>>>>> >>>>>>> Tracing framework expect u4 as an id of thread >>>>>>> >>>>>>> pthread_t chosen as a tread id for variety of BSD platforms >>>>>>> couldn't be >>>>>>> converted to u4 so it cause compilation failure on BSD x64 >>>>>>> >>>>>>> Solution: >>>>>>> >>>>>>> Change thread_id to pid_t and get this id directly from kernel, the >>>>>>> same manner as Linux code does. Mac Os X still uses mach_port >>>>>>> instead of >>>>>>> thread id. >>>>>>> >>>>>>> Tested on FreeBSD and OpenBSD and also code passed jprt. >>>>>>> >>>>>>> -Dmitry >>>>>>> > From coleen.phillimore at oracle.com Wed Oct 2 16:07:17 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 02 Oct 2013 23:07:17 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20131002230722.C938562CC4@hg.openjdk.java.net> Changeset: 931f105563c5 Author: coleenp Date: 2013-10-02 13:02 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/931f105563c5 8025569: -XX:+CheckUnhandledOops crashes on Windows Summary: Disable CHECK_UNHANDLED_OOPS in fastdebug builds for JDK 8 on WIndows 32 & 64 bit machines Reviewed-by: coleenp, ctornqvi, zgu Contributed-by: lois.foltan at oracle.com ! make/windows/makefiles/fastdebug.make Changeset: 6f73bc5df986 Author: coleenp Date: 2013-10-02 15:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6f73bc5df986 Merge From eric.mccorkle at oracle.com Wed Oct 2 16:14:18 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Wed, 02 Oct 2013 23:14:18 +0000 Subject: hg: jdk8/tl/jdk: 8020981: Update methods of java.lang.reflect.Parameter to throw correct exceptions Message-ID: <20131002231431.6950C62CC5@hg.openjdk.java.net> Changeset: cb8946eda85b Author: emc Date: 2013-10-02 19:13 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cb8946eda85b 8020981: Update methods of java.lang.reflect.Parameter to throw correct exceptions Summary: Fix behavior of parameter reflection API for malformed class files. Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Executable.java + src/share/classes/java/lang/reflect/MalformedParametersException.java ! src/share/classes/java/lang/reflect/Parameter.java + test/java/lang/reflect/Parameter/BadClassFiles.java From dmitry.samersoff at oracle.com Wed Oct 2 19:38:48 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Thu, 03 Oct 2013 02:38:48 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20131003023855.B1EBD62CCC@hg.openjdk.java.net> Changeset: 2bd38d594b9a Author: dsamersoff Date: 2013-10-02 20:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2bd38d594b9a 8025283: Nits in os_bsd file breaks compilation of open hotspot Summary: Couple of nits in os_bsd.cpp brake compilation of open hotspot on non-apple platforms Reviewed-by: sla, sspitsyn ! src/os/bsd/vm/os_bsd.cpp Changeset: 9855f17334d8 Author: dsamersoff Date: 2013-10-03 01:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9855f17334d8 Merge From dmitry.samersoff at oracle.com Wed Oct 2 22:58:20 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Thu, 03 Oct 2013 05:58:20 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20131003055827.568F462CD0@hg.openjdk.java.net> Changeset: 5705c7ee6dd7 Author: dsamersoff Date: 2013-10-02 22:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5705c7ee6dd7 8025250: SA: Sync linux and bsd versions of ps_core file Summary: linux/ps_core.c and bsd/ps_core.c share most of code, but it has different formatting, comments etc. Reviewed-by: sla, minqi ! agent/src/os/bsd/ps_core.c ! agent/src/os/linux/ps_core.c Changeset: 7ae82c3a781a Author: dsamersoff Date: 2013-10-03 04:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7ae82c3a781a Merge From kevin.walls at oracle.com Thu Oct 3 02:21:23 2013 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 03 Oct 2013 10:21:23 +0100 Subject: RFR 8019375: Internal symbol table size should be tunable. In-Reply-To: References: <52172CC0.30103@oracle.com> Message-ID: <524D3713.6090302@oracle.com> Hi, Revisiting this after further testing, and marking the flag as experimental as Karen suggested (usage will be -XX:+UnlockExperimentalVMOptions -XX:SymbolTableSize=...). After removing an unnecessary method in the SA SymbolTable.java and further testing, here's a webrev: http://cr.openjdk.java.net/~kevinw/8019375/webrev.02/ Making the symbol table size tunable, and removing SymbolTable::symbol_table_size in vmStructs.cpp, affects a Serviceability Agent class, agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java. There we reference the size we've removed, and that class has a method getSymbolTableSize() which returns it, but that method is never called. My succesful testing including e.g the internal test suit nsk/sajdi.nsk/sajdi is with that method removed. The SA SymbolTable has its own tableSize() which still does match the size of the VM's own symboltable, after this change, and when using the new tunable to change the symbol table size, without using the field I removed from vmStructs. How? 8-) sun/jvm/hotspot/memory/SymbolTable initialises using the vmStructs type information that describes the native BasicHashtable (from src/share/vm/utilities/hashtable.hpp), and never needed the field that directly stored the symbol table size. (I see we did something similar in StringTable for 6962930, including removing the table size method in the SA class.) Thanks Kevin On 29/08/13 13:44, Kirk Pepperdine wrote: > Hi all, > > I'm inclined to believe that there are performance benefits to be gained by being able to get statistics and then use those statistics to better size both the dictionary and the String table. The fact that we've not had ready access to these stats and settings in the field has at times compromised tuning efforts. The Code Cache is another example of where an auto-tunable hasn't quite worked out and that the ability to obtain measures and make adjustments would have been invaluable. > > Kind regards, > Kirk Pepperdine > > On 2013-08-29, at 1:55 PM, Karen Kinnear wrote: > >> Kevin, >> >> Let's talk - I was serious about not asking customers to give values that tune our internal metadata sizes - >> we are potentially moving to different types of metadata or combining symbols with other things -- please >> modify to get a PredictedMaxVMStrings (other names welcome) - but to get a size from the customers that >> we then adopt metadata heuristics to. >> >> thanks, >> Karen >> >> On Aug 23, 2013, at 5:34 AM, Kevin Walls wrote: >> >>> Hi, >>> >>> I'd like to get reviews on this change to make the size of the symbol table tunable. This can be a performance benefit to some apps, i.e. when the symbol table becomes overloaded (see PrintStringTableStatistics output). >>> >>> This work here actually comes from Coleen. I'm happy to take any further comments and update. >>> >>> http://cr.openjdk.java.net/~kevinw/8019375/webrev.01/ >>> http://bugs.sun.com/view_bug.do?bug_id=8019375 >>> >>> This uses SymbolTableSize as the tunable name. (Another suggestion and possibile name, was PredictedMaxVMStrings to avoid talking explicity about the internal format. Comments welcome!...) >>> >>> Thanks >>> Kevin From serguei.spitsyn at oracle.com Thu Oct 3 02:23:27 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 03 Oct 2013 02:23:27 -0700 Subject: RFR (S): JDK-8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes In-Reply-To: <524BE733.2070205@oracle.com> References: <5249643F.3030209@oracle.com> <524A7B07.1000300@oracle.com> <524BE733.2070205@oracle.com> Message-ID: <524D378F.9000809@oracle.com> Hi Frederik, Will review this tomorrow. Sorry for the latency, was busy with other things. In general, I do not like the idea to skip the synchronization. Also, it is important to keep the information from JVMTI consistent. The data returned by the getLoadedClasses and getClassLoaderClasses should match. We also need to make sure it is consistent with other info the JVMTI provides. This requirement is not for improvement or simplification. But more tomorrow... Thanks, Serguei On 10/2/13 2:28 AM, Fredrik Arvidsson wrote: > Hi and thanks for all your comments. > > I have simplified the code in *instanceKlass.cpp* like suggested and > here is a new webrev: > http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.01/ > > > Regarding the need to synchronize the access to ClassLoaderDataGraph I > have come to the conclusion that it should be safe to call this > without any additional synchronization since newly loaded and added > classes are appended to the end of its 'list' of classes. This would > mean that the call could 'miss' the classes added during the > collection phase, but this is not a big issue. I hope that my > conclusion is correct. > > I believe that the JvmtiGetLoadedClasses::getClassLoaderClasses(...) > method is to be left alone this time since I got the impression that > only SystemDictionary 'knows' about initiating class loaders. > > There is plenty of room for improvement and simplification of much of > the code in this area, but I feel that it must wait until another > time. The task to re-factor and simplify would quickly grow out of > hands I'm afraid :) > > Cheers > /Fredrik > > On 2013-10-01 09:34, serguei.spitsyn at oracle.com wrote: >> Hi Frederik, >> >> >> Thank you for jumping on this issue! >> >> >> *src/share/vm/oops/instanceKlass.cpp* >> 2333 int src_index = 0; >> 2334 while (src_index < src_length) { >> 2335 dest[dest_index++] = src[src_index++]; >> 2336 } >> 2337 >> 2338 // If we have a hash, append it >> 2339 if(hash_len > 0) { >> 2340 int hash_index = 0; >> 2341 while (hash_index < hash_len) { >> 2342 dest[dest_index++] = hash_buf[hash_index++]; >> 2343 } >> 2344 } >> >> The above can be simplified a little bit: >> // Add the actual class name >> for (int src_index = 0; src_index < src_length; ) { >> dest[dest_index++] = src[src_index++]; >> } >> // If we have a hash, append it >> for (int hash_index = 0; hash_index < hash_len; ) { >> dest[dest_index++] = hash_buf[hash_index++]; >> } >> >> The conditionif(hash_len > 0) is covered by the loop itself. >> >> Style-related comments: >> -wrong indent at the lines: 2316-2319 >> - need a space after the 'if' at the lines: 2315, 2339 >> >> >> *src/share/vm/prims/jvmtiGetLoadedClasses.cpp >> >> *The copyright comment must be up-to-date. >> The comments at the lines 35-38, 258-260 are not valid anymore. >> >> >> > In this review I still have an outstanding unanswered question about >> > the need to synchronize the access to the: >> >> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >> > and >> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >> >> This kind of walking is usually done at safepoint in a VM_Operation. >> You will find many examples in the jvmtiEnv.cpp, for instance, VM_GetAllStackTraces. >> The suggestion from Mikael is good too. >> >> Should this fix include the getClassLoaderClasses() as well? >> I'm still trying to realize the impact and consistency of this fix. :( >> >> What tests are you going to run for verification? >> >> Thanks, >> Serguei >> * >> *On 9/30/13 4:45 AM, Fredrik Arvidsson wrote: >>> Hi >>> >>> Please help me to review the changes below: >>> >>> Jira case: https://bugs.openjdk.java.net/browse/JDK-8024423 >>> Webrev: >>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/ >>> >>> >>> In this review I still have an outstanding unanswered question about >>> the need to synchronize the access to the: >>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >>> and >>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >>> >>> calls in >>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/src/share/vm/prims/jvmtiGetLoadedClasses.cpp.udiff.html >>> >>> Please give me advise on this. >>> >>> There will be a review soon regarding re-enabling the tests that failed because of the above bug, see: >>> https://bugs.openjdk.java.net/browse/JDK-8025576 >>> >>> Cheers >>> /Fredrik >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131003/a9a80317/attachment.html From paul.sandoz at oracle.com Thu Oct 3 03:12:22 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 03 Oct 2013 10:12:22 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131003101314.93FAA62CE2@hg.openjdk.java.net> Changeset: 811c35a6a58f Author: psandoz Date: 2013-10-02 16:34 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/811c35a6a58f 8025534: Unsafe typecast in java.util.stream.Streams.Nodes 8025538: Unsafe typecast in java.util.stream.SpinedBuffer 8025533: Unsafe typecast in java.util.stream.Streams.RangeIntSpliterator.splitPoint() 8025525: Unsafe typecast in java.util.stream.Node.OfPrimitive.asArray() Reviewed-by: chegar ! src/share/classes/java/util/stream/Node.java ! src/share/classes/java/util/stream/Nodes.java ! src/share/classes/java/util/stream/SortedOps.java ! src/share/classes/java/util/stream/SpinedBuffer.java ! src/share/classes/java/util/stream/Streams.java Changeset: c55a7941050c Author: psandoz Date: 2013-10-03 10:59 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c55a7941050c 8025567: Mark relevant public stream tests as serialization hostile Reviewed-by: alanb ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java From dmitry.samersoff at oracle.com Thu Oct 3 05:27:50 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Thu, 03 Oct 2013 12:27:50 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8022616: u4 should not be used as a type for thread_id Message-ID: <20131003122800.B3CDB62CE9@hg.openjdk.java.net> Changeset: faff125a1ead Author: dsamersoff Date: 2013-10-03 12:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/faff125a1ead 8022616: u4 should not be used as a type for thread_id Summary: Usage of u4 as a type for thread_id cause a compilation error on platform, where thread_id is a pointer Reviewed-by: sla, sspitsyn, minqi ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp From dmitry.samersoff at oracle.com Thu Oct 3 05:55:27 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Thu, 03 Oct 2013 12:55:27 +0000 Subject: hg: jdk8/tl/jdk: 8009213: sun/management/jdp/JdpTest.sh fails with exit code 1 Message-ID: <20131003125539.805AB62CEC@hg.openjdk.java.net> Changeset: 5d6dc0cba08f Author: dsamersoff Date: 2013-10-03 16:54 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d6dc0cba08f 8009213: sun/management/jdp/JdpTest.sh fails with exit code 1 Summary: There's no guarantee that the java process has executed far enough to be found by jps when we try to obtain it's pid. Reviewed-by: sla ! test/sun/management/jdp/JdpTest.sh From aleksey.shipilev at oracle.com Thu Oct 3 06:40:20 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 03 Oct 2013 17:40:20 +0400 Subject: RFR (S) JDK-8025700: RuntimeMXBean.getInputArguments() should include -server/-client/-d32/-d64 Message-ID: <524D73C4.7060004@oracle.com> Hi, Please take a look at the potential fix for: https://bugs.openjdk.java.net/browse/JDK-8025700 The webrev is here: http://cr.openjdk.java.net/~shade/8025700/webrev.01/ Rationale: when doing the Java tools which need to replicate the VM launch, e.g. fork the JVM with the same set of command line options, we need the exact command line. Otherwise we miss the significant part of configuration, which confuses people. So far we miss "-server", "-client", "-d32", and "-d64" options from there. I have seen troubles with jmh and jcstress stemming from this very issue. Testing: - new jtreg test, works fine on Linux x86_64; (I can run other platforms as long as the fix approach is sound) - jdk/test/tools/launcher jtreg tests on Linux x86_64 Thanks, -Aleksey From alexander.zuev at oracle.com Thu Oct 3 06:41:00 2013 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Thu, 03 Oct 2013 13:41:00 +0000 Subject: hg: jdk8/tl/jdk: 8025738: locale related test fails on langtools mac 10.7 test host Message-ID: <20131003134121.D9BFE62CEE@hg.openjdk.java.net> Changeset: 9c32a9490eac Author: kizune Date: 2013-10-03 17:40 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9c32a9490eac 8025738: locale related test fails on langtools mac 10.7 test host Reviewed-by: ksrini ! test/tools/launcher/DiacriticTest.java From ivan.gerasimov at oracle.com Thu Oct 3 07:11:02 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 03 Oct 2013 18:11:02 +0400 Subject: RFR [8025886] typo in shell regtest == instead of = Message-ID: <524D7AF6.2000705@oracle.com> Hello! May I please have a review for a simple fix of the shell regtest? Bash seems to accept both = and == comparisons, but sh accepts only =. http://bugs.sun.com/view_bug.do?bug_id=8025886 (not yet visible.) Sincerely yours, Ivan --- a/test/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh +++ b/test/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh @@ -34,7 +34,7 @@ OS=`uname -s` UMASK=`umask` -if [[ $OS == CYGWIN_NT* ]] ; then +if [[ $OS = CYGWIN_NT* ]] ; then OS="Windows_NT" if [ -z "$SystemRoot" ] ; then SystemRoot=$SYSTEMROOT From mandy.chung at oracle.com Thu Oct 3 07:50:51 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 03 Oct 2013 07:50:51 -0700 Subject: RFR (S) JDK-8025700: RuntimeMXBean.getInputArguments() should include -server/-client/-d32/-d64 In-Reply-To: <524D73C4.7060004@oracle.com> References: <524D73C4.7060004@oracle.com> Message-ID: <524D844B.5010103@oracle.com> On 10/3/2013 6:40 AM, Aleksey Shipilev wrote: > Hi, > > Please take a look at the potential fix for: > https://bugs.openjdk.java.net/browse/JDK-8025700 > > The webrev is here: > http://cr.openjdk.java.net/~shade/8025700/webrev.01/ > > Rationale: when doing the Java tools which need to replicate the VM > launch, e.g. fork the JVM with the same set of command line options, we > need the exact command line. Otherwise we miss the significant part of > configuration, which confuses people. So far we miss "-server", > "-client", "-d32", and "-d64" options from there. I have seen troubles > with jmh and jcstress stemming from this very issue. What other command-line options are missing besides -server/-client/-d32/-d64? RuntimeMXBean.getVmName() tells you whether server or client, 32-bit or 64-bit JVM is running. Would that satisfy your need? Mandy From jaroslav.bachorik at oracle.com Thu Oct 3 08:02:37 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 03 Oct 2013 17:02:37 +0200 Subject: jmx-dev RFR: 8022220 Intermittent test failures in javax/management/remote/mandatory/connection/RMIConnectionIdTest.java In-Reply-To: <524C2976.8020109@oracle.com> References: <52308389.6060001@oracle.com> <524C2976.8020109@oracle.com> Message-ID: <524D870D.2080804@oracle.com> On 2.10.2013 16:11, Dmitry Samersoff wrote: > Jaroslav, > > As a far as loopback address could be resolved to any of 127.0.0.0/8 > client and server have to use the same loopback address. AFAIK, all the IPs 127.*.*.* equally designate the loopback interface. This might start breaking when you have more than one loopback interface in the system. But all of this might be irrelevant here - the IPs are retrieved *after* the JMX connection has been established making it clear that they are reachable. > > Generally speaking it's not required for 127.0.1.1 to be able to talk to > 127.0.0.1 and we are in risk to get a weird fail instead of clear error > message. As I said before as long as there is only one loopback interface it is safe to assume that all the loopback IPs are virtually identical. When we start considering multiple loopback interfaces we would need to take into account the also the assigned network interfaces. But it might hardly matter - it seems that the main culprit for this test to fail on this particular configuration was the fact that 127.0.0.1 was *NOT* detected as a loopback IP. This is pretty weird and makes one question the sanity of the test setup... -JB- > > -Dmitry > > > On 2013-09-11 18:51, Jaroslav Bachorik wrote: >> Please, review this simple patch for an intermittently failing test. >> >> The test fails in cases when the connection loopback is resolved to be >> 127.0.1.1 - it may happen under certain circumstances in eg. Ubuntu. The >> test does not anticipate this possibility and requires the loopback >> address to be exactly 127.0.0.1 >> >> The test will end comparing 127.0.0.1 against 127.0.1.1 and will >> consider them non equal even though they are both the same loopback. The >> patch adds a bit of flexibility to the test allowing for any two valid >> loopback addresses (127.0.0.0/8) to be equal. >> >> Issue : JDK-8022220 >> Webrev : http://cr.openjdk.java.net/~jbachorik/8022220/webrev.00 >> >> Thanks, >> >> -JB- >> > > From aleksey.shipilev at oracle.com Thu Oct 3 08:25:29 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 03 Oct 2013 19:25:29 +0400 Subject: RFR (S) JDK-8025700: RuntimeMXBean.getInputArguments() should include -server/-client/-d32/-d64 In-Reply-To: <524D844B.5010103@oracle.com> References: <524D73C4.7060004@oracle.com> <524D844B.5010103@oracle.com> Message-ID: <524D8C69.3050309@oracle.com> Hi Mandy, On 10/03/2013 06:50 PM, Mandy Chung wrote: > What other command-line options are missing besides > -server/-client/-d32/-d64? These four were problematic "in the wild". I didn't see any other options that are problematic, but does not mean there is none other. > RuntimeMXBean.getVmName() tells you whether server or client, 32-bit or > 64-bit JVM is running. Would that satisfy your need? Immediate need: possibly, but this requires stringly guesswork. Moving forward, I can foresee different VMs being requested which can not be guessed that easily. Think -XXaltjvm= or some other black magic in launcher. Because of that, I think more generic solution (like the variant being proposed) is more viable. -Aleksey. From chris.hegarty at oracle.com Thu Oct 3 08:29:48 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 03 Oct 2013 16:29:48 +0100 Subject: jmx-dev RFR: 8022220 Intermittent test failures in javax/management/remote/mandatory/connection/RMIConnectionIdTest.java In-Reply-To: <524D870D.2080804@oracle.com> References: <52308389.6060001@oracle.com> <524C2976.8020109@oracle.com> <524D870D.2080804@oracle.com> Message-ID: <524D8D6C.9050907@oracle.com> On 10/03/2013 04:02 PM, Jaroslav Bachorik wrote: > ....... > But it might hardly matter - it seems that the main culprit for this > test to fail on this particular configuration was the fact that > 127.0.0.1 was *NOT* detected as a loopback IP. This is pretty weird and I have not looked at the specifics, but if you have an InetAddress instance you can invoke the isLoopbackAddress() [1][2] method to correctly determine if the instance is a valid loopback address. -Chris. [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/54e099776f08/src/share/classes/java/net/Inet4Address.java [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/54e099776f08/src/share/classes/java/net/Inet6Address.java > makes one question the sanity of the test setup... > > -JB- > >> >> -Dmitry >> >> >> On 2013-09-11 18:51, Jaroslav Bachorik wrote: >>> Please, review this simple patch for an intermittently failing test. >>> >>> The test fails in cases when the connection loopback is resolved to be >>> 127.0.1.1 - it may happen under certain circumstances in eg. Ubuntu. The >>> test does not anticipate this possibility and requires the loopback >>> address to be exactly 127.0.0.1 >>> >>> The test will end comparing 127.0.0.1 against 127.0.1.1 and will >>> consider them non equal even though they are both the same loopback. The >>> patch adds a bit of flexibility to the test allowing for any two valid >>> loopback addresses (127.0.0.0/8) to be equal. >>> >>> Issue : JDK-8022220 >>> Webrev : http://cr.openjdk.java.net/~jbachorik/8022220/webrev.00 >>> >>> Thanks, >>> >>> -JB- >>> >> >> > From jaroslav.bachorik at oracle.com Thu Oct 3 08:37:02 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 03 Oct 2013 17:37:02 +0200 Subject: jmx-dev RFR: 8022220 Intermittent test failures in javax/management/remote/mandatory/connection/RMIConnectionIdTest.java In-Reply-To: <524D8D6C.9050907@oracle.com> References: <52308389.6060001@oracle.com> <524C2976.8020109@oracle.com> <524D870D.2080804@oracle.com> <524D8D6C.9050907@oracle.com> Message-ID: <524D8F1E.9050904@oracle.com> On 3.10.2013 17:29, Chris Hegarty wrote: > > > On 10/03/2013 04:02 PM, Jaroslav Bachorik wrote: >> ....... >> But it might hardly matter - it seems that the main culprit for this >> test to fail on this particular configuration was the fact that >> 127.0.0.1 was *NOT* detected as a loopback IP. This is pretty weird and > > I have not looked at the specifics, but if you have an InetAddress > instance you can invoke the isLoopbackAddress() [1][2] method to > correctly determine if the instance is a valid loopback address. Yes, and exactly this method seems to have failed to determine 127.0.0.1 being a loopback - according to the test output. I really can't see how because it basically compares the left-most byte of the IP to 127 ... -JB- > > -Chris. > > [1] > http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/54e099776f08/src/share/classes/java/net/Inet4Address.java > > [2] > http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/54e099776f08/src/share/classes/java/net/Inet6Address.java > > >> makes one question the sanity of the test setup... >> >> -JB- >> >>> >>> -Dmitry >>> >>> >>> On 2013-09-11 18:51, Jaroslav Bachorik wrote: >>>> Please, review this simple patch for an intermittently failing test. >>>> >>>> The test fails in cases when the connection loopback is resolved to be >>>> 127.0.1.1 - it may happen under certain circumstances in eg. Ubuntu. >>>> The >>>> test does not anticipate this possibility and requires the loopback >>>> address to be exactly 127.0.0.1 >>>> >>>> The test will end comparing 127.0.0.1 against 127.0.1.1 and will >>>> consider them non equal even though they are both the same loopback. >>>> The >>>> patch adds a bit of flexibility to the test allowing for any two valid >>>> loopback addresses (127.0.0.0/8) to be equal. >>>> >>>> Issue : JDK-8022220 >>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8022220/webrev.00 >>>> >>>> Thanks, >>>> >>>> -JB- >>>> >>> >>> >> From chris.hegarty at oracle.com Thu Oct 3 08:43:20 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 03 Oct 2013 16:43:20 +0100 Subject: jmx-dev RFR: 8022220 Intermittent test failures in javax/management/remote/mandatory/connection/RMIConnectionIdTest.java In-Reply-To: <524D8F1E.9050904@oracle.com> References: <52308389.6060001@oracle.com> <524C2976.8020109@oracle.com> <524D870D.2080804@oracle.com> <524D8D6C.9050907@oracle.com> <524D8F1E.9050904@oracle.com> Message-ID: <524D9098.6030701@oracle.com> On 10/03/2013 04:37 PM, Jaroslav Bachorik wrote: > On 3.10.2013 17:29, Chris Hegarty wrote: >> >> >> On 10/03/2013 04:02 PM, Jaroslav Bachorik wrote: >>> ....... >>> But it might hardly matter - it seems that the main culprit for this >>> test to fail on this particular configuration was the fact that >>> 127.0.0.1 was *NOT* detected as a loopback IP. This is pretty weird and >> >> I have not looked at the specifics, but if you have an InetAddress >> instance you can invoke the isLoopbackAddress() [1][2] method to >> correctly determine if the instance is a valid loopback address. > > Yes, and exactly this method seems to have failed to determine 127.0.0.1 > being a loopback - according to the test output. > > I really can't see how because it basically compares the left-most byte > of the IP to 127 ... Hmm... if this method fails to make the correct determination then we have problems ;-) We use isLoopbackAddress in may other networking, and similar, tests in the jdk. Sorry, I don't know what to say, there must be some other kind of issue on your machine, or address is not truly 127.0.0.1. -Chris. > > -JB- > >> >> -Chris. >> >> [1] >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/54e099776f08/src/share/classes/java/net/Inet4Address.java >> >> >> [2] >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/54e099776f08/src/share/classes/java/net/Inet6Address.java >> >> >> >>> makes one question the sanity of the test setup... >>> >>> -JB- >>> >>>> >>>> -Dmitry >>>> >>>> >>>> On 2013-09-11 18:51, Jaroslav Bachorik wrote: >>>>> Please, review this simple patch for an intermittently failing test. >>>>> >>>>> The test fails in cases when the connection loopback is resolved to be >>>>> 127.0.1.1 - it may happen under certain circumstances in eg. Ubuntu. >>>>> The >>>>> test does not anticipate this possibility and requires the loopback >>>>> address to be exactly 127.0.0.1 >>>>> >>>>> The test will end comparing 127.0.0.1 against 127.0.1.1 and will >>>>> consider them non equal even though they are both the same loopback. >>>>> The >>>>> patch adds a bit of flexibility to the test allowing for any two valid >>>>> loopback addresses (127.0.0.0/8) to be equal. >>>>> >>>>> Issue : JDK-8022220 >>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8022220/webrev.00 >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>>> >>>> >>>> >>> > From robert.field at oracle.com Thu Oct 3 10:24:42 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Thu, 03 Oct 2013 17:24:42 +0000 Subject: hg: jdk8/tl/jdk: 8010433: Remove lambda metafactory work-around to JDK-8005119 Message-ID: <20131003172512.E48F462D0B@hg.openjdk.java.net> Changeset: 8d8b809dd294 Author: rfield Date: 2013-10-03 10:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d8b809dd294 8010433: Remove lambda metafactory work-around to JDK-8005119 Summary: Restore invokespecial to lambda metafactory Reviewed-by: ksrini ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java From coleen.phillimore at oracle.com Thu Oct 3 11:02:45 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 03 Oct 2013 14:02:45 -0400 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV Message-ID: <524DB145.5030109@oracle.com> Summary: Redefined class in stack trace may not be found by method_idnum so handle null. This is a simple change. I had another change to save the method name (as u2) in the backtrace, but it's not worth the extra footprint in backtraces for this rare case. The root problem was that we save method_idnum in the backtrace (u2) instead of Method* to avoid Method* from being redefined and deallocated. I made a change to InstanceKlass::method_from_idnum() to return null rather than the last method in the list, which causes this crash. Dan and I went down the long rabbit-hole of why method_idnum is changed for obsolete methods and we think there's some cleanup and potential bugs in this area. But this is not that change. I'll file another bug to continue this investigation for jdk9 (or 8uN). Staffan created a test - am including core-libs for the review request. Also tested with all of the vm testbase tests, mlvm tests, and java/lang/instrument tests. open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ bug link https://bugs.openjdk.java.net/browse/JDK-8025238 test case for jdk8 repository: open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk Thanks, Coleen From robert.field at oracle.com Thu Oct 3 11:27:36 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Thu, 03 Oct 2013 18:27:36 +0000 Subject: hg: jdk8/tl/jdk: 8020849: jdk/lambda/vm/DefaultMethodsTest.java Message-ID: <20131003182839.8556662D1C@hg.openjdk.java.net> Changeset: 1b3616c4a836 Author: rfield Date: 2013-10-03 11:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1b3616c4a836 8020849: jdk/lambda/vm/DefaultMethodsTest.java Summary: Bridge generation has been removed from the VM. Fix is to remove tests that no longer make sense. Reviewed-by: ksrini ! test/jdk/lambda/vm/DefaultMethodsTest.java From dmitry.samersoff at oracle.com Thu Oct 3 12:09:55 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 03 Oct 2013 23:09:55 +0400 Subject: jmx-dev RFR: 8022220 Intermittent test failures in javax/management/remote/mandatory/connection/RMIConnectionIdTest.java In-Reply-To: <524D870D.2080804@oracle.com> References: <52308389.6060001@oracle.com> <524C2976.8020109@oracle.com> <524D870D.2080804@oracle.com> Message-ID: <524DC103.7080401@oracle.com> Jaroslav, Behevior of mulitple loopback is not specified clearly[1] and is up to OS developers or more precise - kernel setup. Common practice is to assign 127.*.*.* to interfaces like tun, to be able to use some socket-related calls ever if it is not connected to peer. Other common situation - multiple loopback interfaces on host computer to support virtual instances. So on my opinion, it's better to be pessimistic and don't assume that different loopback addresses are able to talk with each other. [1] http://tools.ietf.org/html/rfc3330 127.0.0.0/8 - This block is assigned for use as the Internet host loopback address. A datagram sent by a higher level protocol to an address anywhere within this block should loop back inside the host. This is ordinarily implemented using only 127.0.0.1/32 for loopback, but no addresses within this block should ever appear on any network anywhere. -Dmitry On 2013-10-03 19:02, Jaroslav Bachorik wrote: > On 2.10.2013 16:11, Dmitry Samersoff wrote: >> Jaroslav, >> >> As a far as loopback address could be resolved to any of 127.0.0.0/8 >> client and server have to use the same loopback address. > > AFAIK, all the IPs 127.*.*.* equally designate the loopback interface. > This might start breaking when you have more than one loopback interface > in the system. > But all of this might be irrelevant here - the IPs are retrieved *after* > the JMX connection has been established making it clear that they are > reachable. > >> >> Generally speaking it's not required for 127.0.1.1 to be able to talk to >> 127.0.0.1 and we are in risk to get a weird fail instead of clear error >> message. > > As I said before as long as there is only one loopback interface it is > safe to assume that all the loopback IPs are virtually identical. When > we start considering multiple loopback interfaces we would need to take > into account the also the assigned network interfaces. > > But it might hardly matter - it seems that the main culprit for this > test to fail on this particular configuration was the fact that > 127.0.0.1 was *NOT* detected as a loopback IP. This is pretty weird and > makes one question the sanity of the test setup... > > -JB- > >> >> -Dmitry >> >> >> On 2013-09-11 18:51, Jaroslav Bachorik wrote: >>> Please, review this simple patch for an intermittently failing test. >>> >>> The test fails in cases when the connection loopback is resolved to be >>> 127.0.1.1 - it may happen under certain circumstances in eg. Ubuntu. The >>> test does not anticipate this possibility and requires the loopback >>> address to be exactly 127.0.0.1 >>> >>> The test will end comparing 127.0.0.1 against 127.0.1.1 and will >>> consider them non equal even though they are both the same loopback. The >>> patch adds a bit of flexibility to the test allowing for any two valid >>> loopback addresses (127.0.0.0/8) to be equal. >>> >>> Issue : JDK-8022220 >>> Webrev : http://cr.openjdk.java.net/~jbachorik/8022220/webrev.00 >>> >>> Thanks, >>> >>> -JB- >>> >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Thu Oct 3 12:29:53 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 3 Oct 2013 21:29:53 +0200 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DB145.5030109@oracle.com> References: <524DB145.5030109@oracle.com> Message-ID: Looks good! (Obviously I would think so for the testcase :-) ) Thanks for fixing, /Staffan On 3 okt 2013, at 20:02, Coleen Phillimore wrote: > Summary: Redefined class in stack trace may not be found by method_idnum so handle null. > > This is a simple change. I had another change to save the method name (as u2) in the backtrace, but it's not worth the extra footprint in backtraces for this rare case. > > The root problem was that we save method_idnum in the backtrace (u2) instead of Method* to avoid Method* from being redefined and deallocated. I made a change to InstanceKlass::method_from_idnum() to return null rather than the last method in the list, which causes this crash. Dan and I went down the long rabbit-hole of why method_idnum is changed for obsolete methods and we think there's some cleanup and potential bugs in this area. But this is not that change. I'll file another bug to continue this investigation for jdk9 (or 8uN). > > Staffan created a test - am including core-libs for the review request. Also tested with all of the vm testbase tests, mlvm tests, and java/lang/instrument tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ > bug link https://bugs.openjdk.java.net/browse/JDK-8025238 > > test case for jdk8 repository: > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk > > Thanks, > Coleen From serguei.spitsyn at oracle.com Thu Oct 3 12:50:58 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 03 Oct 2013 12:50:58 -0700 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DB145.5030109@oracle.com> References: <524DB145.5030109@oracle.com> Message-ID: <524DCAA2.7050305@oracle.com> Coleen, The fix looks good. It is nice you've come up with this. Thanks, Serguei On 10/3/13 11:02 AM, Coleen Phillimore wrote: > Summary: Redefined class in stack trace may not be found by > method_idnum so handle null. > > This is a simple change. I had another change to save the method name > (as u2) in the backtrace, but it's not worth the extra footprint in > backtraces for this rare case. > > The root problem was that we save method_idnum in the backtrace (u2) > instead of Method* to avoid Method* from being redefined and > deallocated. I made a change to InstanceKlass::method_from_idnum() to > return null rather than the last method in the list, which causes this > crash. Dan and I went down the long rabbit-hole of why method_idnum > is changed for obsolete methods and we think there's some cleanup and > potential bugs in this area. But this is not that change. I'll file > another bug to continue this investigation for jdk9 (or 8uN). > > Staffan created a test - am including core-libs for the review > request. Also tested with all of the vm testbase tests, mlvm tests, > and java/lang/instrument tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ > bug link https://bugs.openjdk.java.net/browse/JDK-8025238 > > test case for jdk8 repository: > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk > > Thanks, > Coleen From daniel.daugherty at oracle.com Thu Oct 3 13:07:25 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 03 Oct 2013 14:07:25 -0600 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DB145.5030109@oracle.com> References: <524DB145.5030109@oracle.com> Message-ID: <524DCE7D.7020703@oracle.com> > 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 something? A caller may not be expecting those to be NULL. Also, holder->method_with_idnum(method_id) should be able to search the previous class version list and find the obsolete Method* that matches the 'method_id' value. src/share/vm/prims/jvmtiRedefineClasses.cpp Better comment than the original. Dan On 10/3/13 12:02 PM, Coleen Phillimore wrote: > Summary: Redefined class in stack trace may not be found by > method_idnum so handle null. > > This is a simple change. I had another change to save the method name > (as u2) in the backtrace, but it's not worth the extra footprint in > backtraces for this rare case. > > The root problem was that we save method_idnum in the backtrace (u2) > instead of Method* to avoid Method* from being redefined and > deallocated. I made a change to InstanceKlass::method_from_idnum() to > return null rather than the last method in the list, which causes this > crash. Dan and I went down the long rabbit-hole of why method_idnum > is changed for obsolete methods and we think there's some cleanup and > potential bugs in this area. But this is not that change. I'll file > another bug to continue this investigation for jdk9 (or 8uN). > > Staffan created a test - am including core-libs for the review > request. Also tested with all of the vm testbase tests, mlvm tests, > and java/lang/instrument tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ > bug link https://bugs.openjdk.java.net/browse/JDK-8025238 > > test case for jdk8 repository: > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk > > Thanks, > Coleen From roger.riggs at oracle.com Thu Oct 3 13:20:21 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Thu, 03 Oct 2013 20:20:21 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131003202235.747C262D32@hg.openjdk.java.net> Changeset: 01b8604e8268 Author: rriggs Date: 2013-08-22 10:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01b8604e8268 8024896: Refactor java.time serialization tests into separate subpackage Summary: Move serialization tests to .serial subpackage Reviewed-by: sherman Contributed-by: paul.rank at oracle.com ! test/java/time/tck/java/time/TCKDuration.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKMonthDay.java ! test/java/time/tck/java/time/TCKOffsetDateTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKPeriod.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZoneId.java ! test/java/time/tck/java/time/TCKZoneOffset.java ! test/java/time/tck/java/time/TCKZonedDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDate.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java + test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDate.java + test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateTime.java + test/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java + test/java/time/tck/java/time/serial/TCKDuration.java + test/java/time/tck/java/time/serial/TCKInstant.java + test/java/time/tck/java/time/serial/TCKLocalDate.java + test/java/time/tck/java/time/serial/TCKLocalDateTime.java + test/java/time/tck/java/time/serial/TCKLocalTime.java + test/java/time/tck/java/time/serial/TCKMonthDay.java + test/java/time/tck/java/time/serial/TCKOffsetDateTime.java + test/java/time/tck/java/time/serial/TCKOffsetTime.java + test/java/time/tck/java/time/serial/TCKPeriod.java + test/java/time/tck/java/time/serial/TCKYear.java + test/java/time/tck/java/time/serial/TCKYearMonth.java + test/java/time/tck/java/time/serial/TCKZoneId.java + test/java/time/tck/java/time/serial/TCKZoneOffset.java + test/java/time/tck/java/time/serial/TCKZonedDateTime.java ! test/java/time/tck/java/time/temporal/TCKWeekFields.java + test/java/time/tck/java/time/temporal/serial/TCKWeekFields.java ! test/java/time/tck/java/time/zone/TCKFixedZoneRules.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java ! test/java/time/tck/java/time/zone/TCKZoneRules.java + test/java/time/tck/java/time/zone/serial/TCKFixedZoneRules.java + test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransition.java + test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRule.java + test/java/time/tck/java/time/zone/serial/TCKZoneRules.java Changeset: e813b58bd6db Author: rriggs Date: 2013-10-03 15:16 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e813b58bd6db 8024427: Missing java.time.chrono serialization tests Summary: Add tests and cleanup existing serialization tests Reviewed-by: sherman ! src/share/classes/java/time/temporal/ValueRange.java ! test/java/time/tck/java/time/AbstractTCKTest.java ! test/java/time/tck/java/time/TCKClock_Fixed.java ! test/java/time/tck/java/time/TCKClock_Offset.java ! test/java/time/tck/java/time/TCKClock_System.java ! test/java/time/tck/java/time/TCKClock_Tick.java ! test/java/time/tck/java/time/chrono/CopticDate.java ! test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronology.java ! test/java/time/tck/java/time/chrono/TCKTestServiceLoader.java ! test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateSerialization.java < test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDate.java ! test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateTimeSerialization.java < test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateTime.java + test/java/time/tck/java/time/chrono/serial/TCKChronoZonedDateTimeSerialization.java ! test/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java + test/java/time/tck/java/time/chrono/serial/TCKCopticSerialization.java + test/java/time/tck/java/time/chrono/serial/TCKEraSerialization.java + test/java/time/tck/java/time/serial/TCKClockSerialization.java ! test/java/time/tck/java/time/serial/TCKDurationSerialization.java < test/java/time/tck/java/time/serial/TCKDuration.java ! test/java/time/tck/java/time/serial/TCKInstantSerialization.java < test/java/time/tck/java/time/serial/TCKInstant.java ! test/java/time/tck/java/time/serial/TCKLocalDateSerialization.java < test/java/time/tck/java/time/serial/TCKLocalDate.java ! test/java/time/tck/java/time/serial/TCKLocalDateTimeSerialization.java < test/java/time/tck/java/time/serial/TCKLocalDateTime.java ! test/java/time/tck/java/time/serial/TCKLocalTimeSerialization.java < test/java/time/tck/java/time/serial/TCKLocalTime.java ! test/java/time/tck/java/time/serial/TCKMonthDaySerialization.java < test/java/time/tck/java/time/serial/TCKMonthDay.java ! test/java/time/tck/java/time/serial/TCKOffsetDateTimeSerialization.java < test/java/time/tck/java/time/serial/TCKOffsetDateTime.java ! test/java/time/tck/java/time/serial/TCKOffsetTimeSerialization.java < test/java/time/tck/java/time/serial/TCKOffsetTime.java ! test/java/time/tck/java/time/serial/TCKPeriodSerialization.java < test/java/time/tck/java/time/serial/TCKPeriod.java ! test/java/time/tck/java/time/serial/TCKYearMonthSerialization.java < test/java/time/tck/java/time/serial/TCKYearMonth.java ! test/java/time/tck/java/time/serial/TCKYearSerialization.java < test/java/time/tck/java/time/serial/TCKYear.java ! test/java/time/tck/java/time/serial/TCKZoneIdSerialization.java < test/java/time/tck/java/time/serial/TCKZoneId.java ! test/java/time/tck/java/time/serial/TCKZoneOffsetSerialization.java < test/java/time/tck/java/time/serial/TCKZoneOffset.java ! test/java/time/tck/java/time/serial/TCKZonedDateTimeSerialization.java < test/java/time/tck/java/time/serial/TCKZonedDateTime.java ! test/java/time/tck/java/time/temporal/TCKJulianFields.java + test/java/time/tck/java/time/temporal/serial/TCKChronoFieldSerialization.java + test/java/time/tck/java/time/temporal/serial/TCKChronoUnitSerialization.java + test/java/time/tck/java/time/temporal/serial/TCKJulianFieldsSerialization.java + test/java/time/tck/java/time/temporal/serial/TCKValueRangeSerialization.java ! test/java/time/tck/java/time/temporal/serial/TCKWeekFieldsSerialization.java < test/java/time/tck/java/time/temporal/serial/TCKWeekFields.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java ! test/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java ! test/java/time/tck/java/time/zone/serial/TCKFixedZoneRulesSerialization.java < test/java/time/tck/java/time/zone/serial/TCKFixedZoneRules.java ! test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRuleSerialization.java < test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRule.java ! test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionSerialization.java < test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransition.java ! test/java/time/tck/java/time/zone/serial/TCKZoneRulesSerialization.java < test/java/time/tck/java/time/zone/serial/TCKZoneRules.java ! test/java/time/test/java/time/AbstractTest.java ! test/java/time/test/java/time/TestDuration.java ! test/java/time/test/java/time/temporal/TestDateTimeValueRange.java From daniel.daugherty at oracle.com Thu Oct 3 13:28:56 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 03 Oct 2013 14:28:56 -0600 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DB145.5030109@oracle.com> References: <524DB145.5030109@oracle.com> Message-ID: <524DD388.8060706@oracle.com> > open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk test/java/lang/instrument/RedefineMethodInBacktrace.sh No comments. test/java/lang/instrument/RedefineMethodInBacktraceApp.java line 78: t.setDaemon(true); Why make the target thread a daemon? Wouldn't it be a more complete test to do Thread.join() of that thread just to be sure that the target thread has finished (and is not stuck)? test/java/lang/instrument/RedefineMethodInBacktraceTargetB.java test/java/lang/instrument/RedefineMethodInBacktraceTargetB_2.java Nice sync logic with the test driver. Thumbs up. Dan On 10/3/13 12:02 PM, Coleen Phillimore wrote: > Summary: Redefined class in stack trace may not be found by > method_idnum so handle null. > > This is a simple change. I had another change to save the method name > (as u2) in the backtrace, but it's not worth the extra footprint in > backtraces for this rare case. > > The root problem was that we save method_idnum in the backtrace (u2) > instead of Method* to avoid Method* from being redefined and > deallocated. I made a change to InstanceKlass::method_from_idnum() to > return null rather than the last method in the list, which causes this > crash. Dan and I went down the long rabbit-hole of why method_idnum > is changed for obsolete methods and we think there's some cleanup and > potential bugs in this area. But this is not that change. I'll file > another bug to continue this investigation for jdk9 (or 8uN). > > Staffan created a test - am including core-libs for the review > request. Also tested with all of the vm testbase tests, mlvm tests, > and java/lang/instrument tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ > bug link https://bugs.openjdk.java.net/browse/JDK-8025238 > > test case for jdk8 repository: > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk > > Thanks, > Coleen > > From john.coomes at oracle.com Thu Oct 3 13:56:58 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 20:56:58 +0000 Subject: hg: hsx/hotspot-rt: 5 new changesets Message-ID: <20131003205659.19BAD62D3C@hg.openjdk.java.net> Changeset: 5ec3c4948863 Author: ksrini Date: 2013-09-27 16:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/5ec3c4948863 8023495: [infra] create 64-bit solaris bits with symlinks Reviewed-by: ihse, tbell, erikj ! common/makefiles/Jprt.gmk ! common/makefiles/Main.gmk Changeset: 72c2495c86c9 Author: katleman Date: 2013-10-01 12:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/72c2495c86c9 Merge Changeset: 0f704e36bc5d Author: ihse Date: 2013-10-01 10:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/0f704e36bc5d 8006661: Use LC_ALL=C instead of LANG=C compare.sh Reviewed-by: tbell ! common/bin/compare.sh Changeset: 4faa09c7fe55 Author: erikj Date: 2013-10-02 15:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/4faa09c7fe55 Merge Changeset: 669e3e3d4459 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/669e3e3d4459 Added tag jdk8-b110 for changeset 4faa09c7fe55 ! .hgtags From john.coomes at oracle.com Thu Oct 3 13:57:44 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 20:57:44 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b110 for changeset cc682329886b Message-ID: <20131003205749.5DD3962D3F@hg.openjdk.java.net> Changeset: 32edc7a2c866 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/32edc7a2c866 Added tag jdk8-b110 for changeset cc682329886b ! .hgtags From john.coomes at oracle.com Thu Oct 3 13:57:10 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 20:57:10 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b110 for changeset 3d2b7ce93c5c Message-ID: <20131003205711.EB38662D3D@hg.openjdk.java.net> Changeset: 85c1c94e7235 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/85c1c94e7235 Added tag jdk8-b110 for changeset 3d2b7ce93c5c ! .hgtags From john.coomes at oracle.com Thu Oct 3 13:57:25 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 20:57:25 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b110 for changeset 4c84c5b447b0 Message-ID: <20131003205730.5D3B362D3E@hg.openjdk.java.net> Changeset: 17ee0d3e97fd Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/17ee0d3e97fd Added tag jdk8-b110 for changeset 4c84c5b447b0 ! .hgtags From john.coomes at oracle.com Thu Oct 3 14:32:00 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 21:32:00 +0000 Subject: hg: hsx/hotspot-rt/langtools: 35 new changesets Message-ID: <20131003213358.CA6DB62D43@hg.openjdk.java.net> Changeset: fdfbc5f0c4ed Author: jjg Date: 2013-09-17 14:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/fdfbc5f0c4ed 8024538: -Xdoclint + -Xprefer:source + incremental compilation == FAIL Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java + test/tools/javac/doclint/implicitSource/ImplicitSourceTest.java + test/tools/javac/doclint/implicitSource/Other.java Changeset: ac6ec071c2b2 Author: alundblad Date: 2013-09-18 14:39 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/ac6ec071c2b2 8024127: javac, Code_attribute.exception_table_langth should be Code_attribute.exception_table_length Summary: exception_table_langth renamed to exception_table_length Reviewed-by: jfranck, jjg ! src/share/classes/com/sun/tools/classfile/Code_attribute.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! test/tools/javac/T7093325.java ! test/tools/javac/T8024039/NoDeadCodeGenerationOnTrySmtTest.java ! test/tools/javac/multicatch/Pos05.java Changeset: a2a5ad0853ed Author: bpatel Date: 2013-09-18 17:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/a2a5ad0853ed 8015249: javadoc fails to document static final fields in annotation types Reviewed-by: jjg + src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeFieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeFieldWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeRequiredMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeFieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! test/com/sun/javadoc/testAnnotationTypes/TestAnnotationTypes.java + test/com/sun/javadoc/testAnnotationTypes/pkg/AnnotationTypeField.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java Changeset: 8df12c315ea3 Author: bpatel Date: 2013-09-18 22:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/8df12c315ea3 8024096: some javadoc tests may contain false positive results Reviewed-by: jjg ! test/com/sun/javadoc/lib/JavadocTester.java ! test/com/sun/javadoc/testDocFileDir/TestDocFileDir.java ! test/com/sun/javadoc/testEncoding/EncodeTest.java ! test/com/sun/javadoc/testEncoding/TestEncoding.java ! test/com/sun/javadoc/testMethodTypes/TestMethodTypes.java ! test/com/sun/javadoc/testProfiles/TestProfiles.java Changeset: 36e342dd57e2 Author: kizune Date: 2013-09-19 17:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/36e342dd57e2 8017248: Compiler Diacritics Issue Reviewed-by: naoto ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java Changeset: 8d1c48de706d Author: jlahoda Date: 2013-09-19 17:05 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/8d1c48de706d 8022567: Javac Should Generate Warnings For Raw Array Type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/warnings/6747671/T6747671.java ! test/tools/javac/warnings/6747671/T6747671.out Changeset: 0cfd5baa7154 Author: ohrstrom Date: 2013-09-19 08:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/0cfd5baa7154 8024609: sjavac assertion fails during call to BuildState.collectArtifacts Reviewed-by: jjg ! src/share/classes/com/sun/tools/sjavac/BuildState.java ! src/share/classes/com/sun/tools/sjavac/Main.java ! src/share/classes/com/sun/tools/sjavac/server/JavacServer.java Changeset: 2375ce96e80d Author: vromero Date: 2013-09-19 20:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/2375ce96e80d 8024437: Inferring the exception thrown: sometimes fails to compile Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/T8024437/ExceptionInferenceFromClassFileTest.java Changeset: 9a75bdb249a2 Author: jjg Date: 2013-09-19 19:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/9a75bdb249a2 8025110: TreeCopier does not correctly copy LabeledStatementTree Reviewed-by: jjg Contributed-by: Werner Dietl ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java Changeset: 41599b57d262 Author: jlahoda Date: 2013-09-20 16:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/41599b57d262 8023835: TreeMaker.QualIdent() too leafy Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java + test/tools/javac/tree/MakeQualIdent.java + test/tools/javac/tree/ScopeTest.java Changeset: 571f8ebc2d51 Author: vromero Date: 2013-09-22 12:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/571f8ebc2d51 8024696: Missing null check in bound method reference capture Reviewed-by: jjg, briangoetz ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! test/tools/javac/lambda/8023558/T8023558a.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceNullCheckTest.java Changeset: 86dd72166267 Author: lana Date: 2013-09-20 19:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/86dd72166267 Merge Changeset: 20b72bae83d7 Author: lana Date: 2013-09-22 20:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/20b72bae83d7 Merge Changeset: 1fe358ea75ff Author: alundblad Date: 2013-09-23 10:10 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/1fe358ea75ff 8024988: javac, LVT test harness should generate tests .class files in the scratch folder Summary: Set the CLASS_OUTPUT location to the scratch directory. Changed the argument to checkClassFile accordingly. Reviewed-by: jjg, vromero ! test/tools/javac/flow/LVTHarness.java Changeset: 5f915a0c9615 Author: alundblad Date: 2013-09-23 10:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/5f915a0c9615 6386236: Please rename com.sun.tools.javac.util.ListBuffer.lb() Summary: Static factory method ListBuffer.lb removed. Replaced by constructor calls. Reviewed-by: jfranck, jjg ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/util/GraphUtils.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/ListBuffer.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java ! test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java ! test/tools/javac/scope/7017664/CompoundScopeTest.java ! test/tools/javac/types/TypeHarness.java Changeset: 809a50f24d6f Author: kizune Date: 2013-09-23 17:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/809a50f24d6f 7154966: CRs found to be in Fixed state with no test and no noreg- keyword. Reviewed-by: ksrini + test/tools/javac/T7090499.java + test/tools/javac/T7090499.out + test/tools/javac/T7120463.java + test/tools/javac/T7120463.out + test/tools/javac/T7126754.java Changeset: 64e79d38bd07 Author: kizune Date: 2013-09-23 18:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/64e79d38bd07 4881267: improve diagnostic for "instanceof T" for type parameter T Reviewed-by: vromero, jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/T4881267.java + test/tools/javac/T4881267.out Changeset: 09301757bb32 Author: emc Date: 2013-09-23 15:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/09301757bb32 6499673: Assertion check for TypeVariable.getUpperBound() fails. Summary: Fix TypeVariable.getUpperBound to return results as specified Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! test/tools/javac/cast/intersection/model/Model01.java ! test/tools/javac/cast/intersection/model/ModelChecker.java + test/tools/javac/processing/model/type/BoundsTest.java + test/tools/javac/processing/model/type/IntersectionPropertiesTest.java Changeset: 96dcb66e6b0a Author: jjg Date: 2013-09-24 10:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/96dcb66e6b0a 8025050: Doclint doesn't recognize tag Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclint/HtmlTag.java ! test/tools/doclint/html/InlineTagsTest.java Changeset: 503338f16d2b Author: jjg Date: 2013-09-24 10:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/503338f16d2b 8025246: [doclint] doclint is showing error on anchor already defined when it's not Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclint/Checker.java + test/tools/doclint/anchorTests/p/Test.java + test/tools/doclint/anchorTests/p/Test.javac.out + test/tools/doclint/anchorTests/p/Test.out + test/tools/doclint/anchorTests/p/package-info.java + test/tools/doclint/anchorTests/p/package-info.javac.out + test/tools/doclint/anchorTests/p/package-info.out Changeset: 6a05a713450d Author: jjg Date: 2013-09-24 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/6a05a713450d 8025272: doclint needs to check for valid usage of @value tag Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties + test/tools/doclint/ValueTest.java + test/tools/doclint/ValueTest.out Changeset: 3ae62331a56f Author: jjg Date: 2013-09-24 13:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/3ae62331a56f 8002154: [doclint] doclint should check for issues which are errors in javadoc Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! test/tools/doclint/ReferenceTest.java ! test/tools/doclint/ReferenceTest.out Changeset: 184c0d6698c3 Author: bpatel Date: 2013-09-24 16:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/184c0d6698c3 8016328: Regression : Javadoc i18n regression caused by fix for 8012375 Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! test/com/sun/javadoc/testHref/TestHref.java ! test/com/sun/javadoc/testJavascript/TestJavascript.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testUseOption/TestUseOption.java Changeset: 5043e7056be8 Author: jjg Date: 2013-09-25 11:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/5043e7056be8 8025407: TypeAnnotations does not use Context Reviewed-by: jfranck ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java Changeset: 1332a99572c5 Author: mfang Date: 2013-09-24 14:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/1332a99572c5 8025215: jdk8 l10n resource file translation update 4 Reviewed-by: naoto, yhuang ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties ! src/share/classes/com/sun/tools/doclint/resources/doclint_ja.properties ! src/share/classes/com/sun/tools/doclint/resources/doclint_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_zh_CN.properties ! src/share/classes/com/sun/tools/javap/resources/javap_ja.properties ! src/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties Changeset: daa3bfb82e58 Author: mfang Date: 2013-09-24 14:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/daa3bfb82e58 Merge Changeset: 6b702ace3e45 Author: mfang Date: 2013-09-25 07:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/6b702ace3e45 Merge Changeset: 68292726000e Author: mfang Date: 2013-09-25 14:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/68292726000e Merge Changeset: 3d61984b077c Author: jjg Date: 2013-09-25 14:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/3d61984b077c 8025412: Add legal header and comments to test/tools/doclint/tidy/util/Main.java Reviewed-by: bpatel ! test/tools/doclint/tidy/util/Main.java ! test/tools/doclint/tidy/util/tidy.sh Changeset: 9e884d3ddb0b Author: bpatel Date: 2013-09-25 22:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/9e884d3ddb0b 8004825: javadoc crash DocletAbortException Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! test/com/sun/javadoc/testValueTag/TestValueTag.java ! test/com/sun/javadoc/testValueTag/pkg1/Class1.java Changeset: 9235ae08a449 Author: jlahoda Date: 2013-09-26 20:07 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/9235ae08a449 8025491: Javac regression test tools/javac/T8003967/DetectMutableStaticFields.java failing Summary: Making HtmlTree.NONENCODING_CHARS final Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java Changeset: 13eba2e322e6 Author: vromero Date: 2013-09-26 19:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/13eba2e322e6 8025139: javac patch for using bootstrap compiler for debugging is not working properly Reviewed-by: jjg ! make/netbeans/langtools/build.xml ! make/tools/anttasks/SelectToolTask.java Changeset: 17653c4c22ec Author: sogoel Date: 2013-09-26 15:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/17653c4c22ec 8011738: Write test to check for bootstrap attributes for lambda expressions in class file Reviewed-by: mcimadamore + test/tools/javac/lambda/ByteCodeTest.java Changeset: 41541097533a Author: lana Date: 2013-09-26 17:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/41541097533a Merge Changeset: af6244ba81b6 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/af6244ba81b6 Added tag jdk8-b110 for changeset 41541097533a ! .hgtags From john.coomes at oracle.com Thu Oct 3 14:34:22 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 21:34:22 +0000 Subject: hg: hsx/hotspot-rt/nashorn: 21 new changesets Message-ID: <20131003213443.725DE62D44@hg.openjdk.java.net> Changeset: 1971c2d770ae Author: sundar Date: 2013-09-18 13:06 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/1971c2d770ae 8024972: for (LeftHandSideExpression in Expression) crashes the compiler Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8024972.js + test/script/basic/JDK-8024972.js.EXPECTED Changeset: a62172fe5bae Author: sundar Date: 2013-09-18 16:36 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/a62172fe5bae 8024973: Using a different ScriptContext with a CompiledScript results in ScriptException Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/runtime/Source.java ! test/script/trusted/JDK-8008305.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: f954d3f4d192 Author: sundar Date: 2013-09-19 13:34 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/f954d3f4d192 8025048: true as case label results in ClassCastException Reviewed-by: lagergren ! src/jdk/nashorn/internal/codegen/Attr.java + test/script/basic/JDK-8025048-2.js + test/script/basic/JDK-8025048.js Changeset: 740b1133f1b6 Author: hannesw Date: 2013-09-19 15:39 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/740b1133f1b6 8023154: compileAllTests fails with: 2 tests failed to compile Reviewed-by: sundar, jlaskey ! make/build-benchmark.xml ! make/build.xml ! make/project.properties Changeset: 821b0b610861 Author: sundar Date: 2013-09-19 21:20 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/821b0b610861 8025080: Object literal getter, setter function with number format property name results in ClassFormatError Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8025080.js + test/script/basic/JDK-8025080.js.EXPECTED ! test/script/basic/parser/objectLitExpr.js.EXPECTED Changeset: 18d64bc4937d Author: sundar Date: 2013-09-19 23:48 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/18d64bc4937d 8025090: 'while' statement with 'test' using var before being declared in body results in VerifyError Reviewed-by: jlaskey ! src/jdk/nashorn/internal/ir/WhileNode.java + test/script/basic/JDK-8025090.js Changeset: 195be8ca5c97 Author: sundar Date: 2013-09-20 12:56 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/195be8ca5c97 8025111: undefined or null 'with' expression in empty with block should throw TypeError Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8025111.js Changeset: fa491b75d3e4 Author: hannesw Date: 2013-09-20 12:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/fa491b75d3e4 8022587: ClassCache is not optimal and leaks Source instances Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java Changeset: 13210550765c Author: lana Date: 2013-09-20 19:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/13210550765c Merge Changeset: 279f47b353f3 Author: sundar Date: 2013-09-20 20:55 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/279f47b353f3 8025147: Trailing comma is not allowed in JSONArray and JSONObject Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8025147.js + test/script/basic/JDK-8025147.js.EXPECTED Changeset: 16b6db9f7225 Author: sundar Date: 2013-09-20 22:37 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/16b6db9f7225 8025149: JSON.stringify does not handle 'space' argument as per the spec. Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/objects/NativeJSON.java + test/script/basic/JDK-8025149.js + test/script/basic/JDK-8025149.js.EXPECTED Changeset: b8d9a63578e2 Author: hannesw Date: 2013-09-21 10:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/b8d9a63578e2 8025163: Date methods should not return -0 Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/NativeDate.java + test/script/basic/JDK-8025163.js + test/script/basic/JDK-8025163.js.EXPECTED Changeset: 8f6304373671 Author: sundar Date: 2013-09-23 14:20 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/8f6304373671 Merge Changeset: c5475f5d4647 Author: sundar Date: 2013-09-24 20:43 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/c5475f5d4647 8025312: parseInt should convert 'radix' argument to ToInt32 even if empty string is parsed Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java + test/script/basic/JDK-8025312.js + test/script/basic/JDK-8025312.js.EXPECTED Changeset: 754ecd62bde3 Author: sundar Date: 2013-09-25 08:17 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/754ecd62bde3 8025325: parseFloat does not handle '.' in exponent part Reviewed-by: hannesw ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java + test/script/basic/JDK-8025325.js + test/script/basic/JDK-8025325.js.EXPECTED Changeset: 2f8f99e5ed76 Author: hannesw Date: 2013-09-25 16:37 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/2f8f99e5ed76 8025434: RegExp lastIndex can exceed int range Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/objects/NativeRegExp.java + test/script/basic/JDK-8025434.js Changeset: 712f5e31739b Author: hannesw Date: 2013-09-26 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/712f5e31739b 8025197: String replace method fails with regexp /$/gi Reviewed-by: sundar ! src/jdk/nashorn/internal/objects/NativeRegExp.java + test/script/basic/JDK-8025197.js + test/script/basic/JDK-8025197.js.EXPECTED Changeset: 23958764f866 Author: hannesw Date: 2013-09-26 11:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/23958764f866 8025486: RegExp constructor arguments are not evaluated in right order Reviewed-by: sundar ! src/jdk/nashorn/internal/objects/NativeRegExp.java + test/script/basic/JDK-8025486.js + test/script/basic/JDK-8025486.js.EXPECTED Changeset: f1f027907a69 Author: sundar Date: 2013-09-26 16:37 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/f1f027907a69 Merge Changeset: d49a8c2173f5 Author: lana Date: 2013-09-26 17:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/d49a8c2173f5 Merge Changeset: 75fd3486e584 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/75fd3486e584 Added tag jdk8-b110 for changeset d49a8c2173f5 ! .hgtags From john.coomes at oracle.com Thu Oct 3 14:01:00 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 21:01:00 +0000 Subject: hg: hsx/hotspot-rt/jdk: 115 new changesets Message-ID: <20131003212704.C0CF162D41@hg.openjdk.java.net> Changeset: 529cd4de1823 Author: prr Date: 2013-09-26 15:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/529cd4de1823 7092764: java.awt.font.TransformAttribute.equals(null) throws NPE Reviewed-by: jgodinez, jchen ! src/share/classes/java/awt/font/TransformAttribute.java + test/java/awt/font/TransformAttribute/TransformEqualityTest.java Changeset: 1bcd48cfb7be Author: ceisserer Date: 2013-09-26 16:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1bcd48cfb7be 8024895: xrender MaskImage cache isn't accounting for change in alpha Reviewed-by: prr, jchen ! src/solaris/classes/sun/java2d/xr/XRMaskImage.java + test/java/awt/image/DrawImage/EABlitTest.java Changeset: dae020405903 Author: lana Date: 2013-09-26 17:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/dae020405903 Merge Changeset: 0151f12bd392 Author: malenkov Date: 2013-08-22 17:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0151f12bd392 8023536: Some regression tests have a wrong header Reviewed-by: alexsch ! test/java/beans/Performance/Test7122740.java ! test/java/beans/Performance/Test7184799.java ! test/javax/swing/JTree/8013571/Test8013571.java Changeset: b71f112dab2a Author: malenkov Date: 2013-08-22 21:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b71f112dab2a 7057769: JScrollBar spec should specify that unit increment & decrement functionality may not be present Reviewed-by: alexsch ! src/share/classes/javax/swing/JScrollBar.java Changeset: f983fd18dd81 Author: malenkov Date: 2013-08-23 19:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f983fd18dd81 7080613: java.beans.DefaultPersistenceDelegate.instantiate(..) doesn't throw NPE Reviewed-by: alexsch ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/PersistenceDelegate.java Changeset: 22ef5187a3e6 Author: dmarkov Date: 2013-08-26 17:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/22ef5187a3e6 8023474: First mousepress doesn't start editing in JTree Reviewed-by: alexp, anthony ! src/share/classes/java/awt/Component.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/sun/awt/AWTAccessor.java + test/javax/swing/plaf/basic/BasicTreeUI/8023474/bug8023474.java Changeset: abd068530590 Author: malenkov Date: 2013-08-27 12:53 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/abd068530590 7195179: ClassCastException for null values in JComboBox Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java + test/javax/swing/JComboBox/7195179/Test7195179.java Changeset: 92adff44c841 Author: malenkov Date: 2013-08-27 13:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/92adff44c841 8021379: JFileChooser Create New Folder button enabled in write proteced directory Reviewed-by: alexsch ! src/share/classes/sun/swing/FilePane.java Changeset: 4bfcf9c5ced3 Author: malenkov Date: 2013-08-27 13:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4bfcf9c5ced3 8022398: javax/swing/JFileChooser/8013442/Test8013442.java fails Reviewed-by: alexsch ! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java + src/share/classes/sun/swing/AbstractFilterComboBoxModel.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java Changeset: e11ed7187b0c Author: lana Date: 2013-08-27 21:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e11ed7187b0c Merge - src/share/classes/com/sun/security/auth/PolicyParser.java - src/share/classes/com/sun/security/auth/SubjectCodeSource.java - src/share/classes/java/util/jar/UnsupportedProfileException.java - src/share/classes/sun/security/provider/ConfigSpiFile.java - test/java/net/URLClassLoader/profiles/Basic.java - test/java/net/URLClassLoader/profiles/Lib.java - test/java/net/URLClassLoader/profiles/basic.sh - test/tools/jar/AddAndUpdateProfile.java - test/tools/launcher/profiles/Basic.java - test/tools/launcher/profiles/Logging.java - test/tools/launcher/profiles/Main.java - test/tools/launcher/profiles/VersionCheck.java Changeset: 43de418f1345 Author: ptbrunet Date: 2013-08-28 17:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/43de418f1345 8011955: Lunar screen reader crashes intermittently in WindowsAccessBridge-32.DLL 6995891: JAWS will occasionally stop speaking focused objects as user TABs -> problem with message queue 8014738: Combobox menu items are not announced with JAWS 8011938: Java Ferret example corrupts JCombobox of the running application 8012011: JAB 2.0.2 incompletely shows kbd accelerator in menus 8022966: Java Access Bridge no longer usable with screen magnifiers Reviewed-by: raginip, tbell, erikj, art ! make/bridge/AccessBridgeJava/Makefile ! makefiles/CompileJavaClasses.gmk ! makefiles/GensrcMisc.gmk Changeset: 35644adc3269 Author: malenkov Date: 2013-08-28 17:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/35644adc3269 6968363: ClassCastException while entering HINDI characters with CustomDocument Reviewed-by: alexsch ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/GlyphPainter2.java ! src/share/classes/javax/swing/text/ParagraphView.java + test/javax/swing/text/AbstractDocument/6968363/Test6968363.java Changeset: 6432f8749e1d Author: pchelko Date: 2013-08-30 11:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6432f8749e1d 8023966: JViewPort.BLIT_SCROLL_MODE does not work in JLightweightFrame Reviewed-by: anthony, ant ! src/share/classes/javax/swing/JViewport.java Changeset: 7151f08eeadf Author: alexsch Date: 2013-08-30 13:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7151f08eeadf 8022401: [macosx] javax/swing/text/JTextComponent/5074573/bug5074573.java fails Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTEvent.m + test/java/awt/event/KeyEvent/KeyChar/KeyCharTest.java Changeset: f2f614e31522 Author: malenkov Date: 2013-09-02 14:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f2f614e31522 7156658: JTextComponent.setFocusAccelerator() spec does not state that focus accelerator is L&F dependent Reviewed-by: alexsch ! src/share/classes/javax/swing/text/JTextComponent.java Changeset: 6ffa2680e139 Author: art Date: 2013-09-02 16:48 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6ffa2680e139 8022184: Fix static , Raw warnings in classes belonging to java.awt Reviewed-by: art, anthony Contributed-by: Srikalyan Chandrashekar ! src/share/classes/java/awt/AWTKeyStroke.java ! src/share/classes/java/awt/CardLayout.java ! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/GradientPaintContext.java ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/SequencedEvent.java ! src/share/classes/java/awt/TexturePaintContext.java ! src/share/classes/java/awt/WaitDispatchSupport.java Changeset: b5ed8686cc01 Author: malenkov Date: 2013-09-03 11:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b5ed8686cc01 6943780: JTabbedPane throws ArrayIndexOutOfBoundsException sometimes Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java + test/javax/swing/plaf/basic/BasicTabbedPaneUI/Test6943780.java Changeset: 80a8c4ff3b51 Author: alexsch Date: 2013-09-03 17:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/80a8c4ff3b51 8007156: [macosx] Wrong events in processKeyBinding of JTable Submit Date Reviewed-by: leonidr ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java + test/java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java Changeset: 2ad01ecbaf90 Author: malenkov Date: 2013-09-03 21:53 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2ad01ecbaf90 7172865: PropertyDescriptor fails to work with setter method name if setter is non-void Reviewed-by: art, alexsch ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/MethodDescriptor.java + src/share/classes/java/beans/MethodRef.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test7172865.java Changeset: ba711056009f Author: pchelko Date: 2013-09-04 14:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ba711056009f 8021943: FileDialog getFile returns corrupted string after previous setFile Reviewed-by: anthony, serb Contributed-by: alexander.zvegintsev at oracle.com ! src/windows/native/sun/windows/awt_FileDialog.cpp Changeset: ba041df8a554 Author: mcherkas Date: 2013-09-04 18:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ba041df8a554 8023565: JPG causes javax.imageio.IIOException: ICC APP2 encoutered without prior JFIF Reviewed-by: bae, vadim ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java Changeset: e4ba3d9ea041 Author: mcherkas Date: 2013-09-05 15:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e4ba3d9ea041 8023392: Swing text components printed with spaces between chars Reviewed-by: alexsch, alexp Contributed-by: anton.nashatyrev at oracle.com ! src/share/classes/sun/swing/SwingUtilities2.java + test/java/awt/print/bug8023392/bug8023392.html + test/java/awt/print/bug8023392/bug8023392.java Changeset: d267c066b006 Author: lana Date: 2013-09-06 15:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d267c066b006 Merge - src/share/classes/sun/misc/Compare.java - src/share/classes/sun/misc/Sort.java Changeset: fbb6f976d780 Author: alexsch Date: 2013-09-09 17:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fbb6f976d780 8024413: Add tests for issues JDK-8002077 and JDK-7199708 Reviewed-by: malenkov, leonidr + test/javax/swing/JFileChooser/7199708/bug7199708.java + test/javax/swing/JFileChooser/8002077/bug8002077.java Changeset: 3ea08767fc0d Author: alexsch Date: 2013-09-09 18:34 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3ea08767fc0d 8020060: MoleculeViewerTest demo doesn't work due to SecurityPermissions Reviewed-by: malenkov, erikj ! makefiles/CompileDemos.gmk ! src/share/demo/applets/MoleculeViewer/XYZApp.java ! src/share/demo/applets/MoleculeViewer/example1.html ! src/share/demo/applets/MoleculeViewer/example2.html ! src/share/demo/applets/MoleculeViewer/example3.html ! src/share/demo/applets/WireFrame/ThreeD.java ! src/share/demo/applets/WireFrame/example1.html ! src/share/demo/applets/WireFrame/example2.html ! src/share/demo/applets/WireFrame/example3.html ! src/share/demo/applets/WireFrame/example4.html Changeset: fc5d16fec25f Author: serb Date: 2013-09-09 21:03 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/fc5d16fec25f 8023042: Inaccuracy in documentation in a sound area Reviewed-by: prr ! src/share/classes/javax/sound/sampled/AudioFileFormat.java ! src/share/classes/javax/sound/sampled/AudioFormat.java Changeset: 9d0d961fb1cd Author: pchelko Date: 2013-09-10 11:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9d0d961fb1cd 8024381: The test for 8020210 does not have @bug tag Reviewed-by: anthony, serb ! test/java/awt/Window/MaximizeOffscreen/MaximizeOffscreenTest.java Changeset: 8b6dace81d6c Author: alexsch Date: 2013-09-10 14:33 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8b6dace81d6c 8021253: JFileChooser does not react on pressing enter since java 7 Reviewed-by: malenkov ! src/share/classes/javax/swing/JFileChooser.java + test/javax/swing/JFileChooser/8021253/bug8021253.java Changeset: 1daffcf035c4 Author: malenkov Date: 2013-09-10 17:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1daffcf035c4 7057770: (spec)Scrollbar spec should specify that unit increment & decrement functionality may not be present Reviewed-by: alexsch ! src/share/classes/java/awt/Scrollbar.java Changeset: eedb2b6d93ec Author: malenkov Date: 2013-09-10 17:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/eedb2b6d93ec 8024407: [macosx] javax/swing/JScrollBar/7163696/Test7163696.java failed intermittently on macos Reviewed-by: alexsch ! test/javax/swing/JScrollBar/7163696/Test7163696.java Changeset: 0cc00c11e17e Author: leonidr Date: 2013-09-10 20:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0cc00c11e17e 8003901: [macosx] Need test for JDK-8002114 Reviewed-by: anthony, serb ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: 04fbd34fda7b Author: bagiras Date: 2013-09-12 14:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/04fbd34fda7b 8003965: Toolkit.beep() documentation is ambiguous Reviewed-by: anthony ! src/share/classes/java/awt/Toolkit.java Changeset: def1fa9854f7 Author: bagiras Date: 2013-09-12 15:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/def1fa9854f7 7064312: Cleanup: avoid using unsafe string function Reviewed-by: serb, pchelko ! src/windows/native/sun/windows/awt_FileDialog.cpp ! src/windows/native/sun/windows/awt_Font.cpp ! src/windows/native/sun/windows/awt_PrintControl.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_ole.cpp Changeset: 6321e4429a38 Author: serb Date: 2013-09-12 18:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6321e4429a38 7124537: [macosx] Menu shortcuts for all menu items should be disabled if a menu itself is disabled Reviewed-by: anthony, leonidr ! src/macosx/classes/sun/lwawt/macosx/CMenu.java ! src/macosx/classes/sun/lwawt/macosx/CMenuItem.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java Changeset: 3213c388740a Author: dmarkov Date: 2013-09-12 18:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3213c388740a 8024395: Improve fix for line break calculations Reviewed-by: alexp, alexsch ! src/share/classes/javax/swing/text/FlowView.java ! src/share/classes/javax/swing/text/View.java ! test/javax/swing/text/View/8014863/bug8014863.java Changeset: ef2f0c15b332 Author: pchelko Date: 2013-09-13 11:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ef2f0c15b332 8024170: [SwingNode] Implement cursor change Reviewed-by: anthony, ant ! src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java ! src/share/classes/sun/swing/JLightweightFrame.java ! src/share/classes/sun/swing/LightweightContent.java ! src/share/classes/sun/swing/SwingAccessor.java ! src/solaris/classes/sun/awt/X11/XLightweightFramePeer.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WLightweightFramePeer.java Changeset: 12788c245d67 Author: pchelko Date: 2013-09-13 17:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/12788c245d67 8015453: java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java failed on windows with jdk8 since b86 Reviewed-by: art, serb ! src/share/classes/sun/awt/datatransfer/DataTransferer.java Changeset: df107b1f2f2e Author: pchelko Date: 2013-09-13 17:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/df107b1f2f2e 8015371: The HTML text without tags does not appear inside the WordPad application, and we try to click the button, but the case exits. Reviewed-by: anthony, serb ! src/windows/classes/sun/awt/windows/WDataTransferer.java Changeset: 40fdf56c09a9 Author: pchelko Date: 2013-09-13 17:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/40fdf56c09a9 8015455: java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java hangs on windows Reviewed-by: serb, anthony ! src/share/classes/java/awt/dnd/DropTarget.java ! src/share/classes/javax/swing/TransferHandler.java Changeset: 915d13946f18 Author: mcherkas Date: 2013-09-13 17:48 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/915d13946f18 8015601: [macosx] Test javax/swing/JInternalFrame/InternalFrameIsNotCollectedTest.java fails on MacOS X Reviewed-by: alexp, alexsch ! test/javax/swing/JInternalFrame/InternalFrameIsNotCollectedTest.java Changeset: ad52e924c55a Author: kshefov Date: 2013-09-13 17:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ad52e924c55a 8006087: [TEST_BUG] The BACKSPACE key doesn't work and after pressing 'cancel' and 'DONE' button, the case pass automatically. Reviewed-by: alexsch, serb ! test/javax/swing/JFileChooser/4150029/bug4150029.html ! test/javax/swing/JFileChooser/4150029/bug4150029.java Changeset: c8a85165b725 Author: kshefov Date: 2013-09-13 17:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c8a85165b725 8015597: [TEST_BUG] [macosx] Test closed/javax/swing/JMenuBar/4750590/bug4750590.java fails since JDK 8 b75 on MacOSX Reviewed-by: alexsch, serb + test/javax/swing/JMenuBar/4750590/bug4750590.java Changeset: 17cc8f13e4e7 Author: pchelko Date: 2013-09-13 18:02 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/17cc8f13e4e7 8012026: [macosx] Component.getMousePosition() does not work in an applet on MacOS Reviewed-by: anthony, serb ! make/sun/lwawt/FILES_export_macosx.gmk - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTView.m + test/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java + test/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java Changeset: a46d22ee4d4b Author: alexsch Date: 2013-09-16 17:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a46d22ee4d4b 8008728: [macosx] Swing. JDialog. Modal dialog goes to background Reviewed-by: serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Modal/ModalDialogOrderingTest/ModalDialogOrderingTest.java Changeset: 8f5b4e7623cf Author: ant Date: 2013-09-16 18:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8f5b4e7623cf 8022512: JLightweightFrame: the content pane should be transparent Reviewed-by: anthony ! src/share/classes/sun/swing/JLightweightFrame.java Changeset: 49c7d299a504 Author: kshefov Date: 2013-09-16 19:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/49c7d299a504 7020060: [TEST_BUG] java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java failed Reviewed-by: anthony, serb ! test/java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java Changeset: 98080e9367be Author: kshefov Date: 2013-09-16 19:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/98080e9367be 8015588: [TEST_BUG] [macosx] Test java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java fails on MacOSX Reviewed-by: anthony, serb ! test/java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java Changeset: 04612a52e7bd Author: pchelko Date: 2013-09-16 19:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/04612a52e7bd 8024779: [macosx] SwingNode crashes on exit Reviewed-by: anthony, ant ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 4e88bf592830 Author: pchelko Date: 2013-09-16 19:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4e88bf592830 8024485: For 5-1 step: if input something into the 'File:' and 'Dir:', the dir output isn't empty in the output window after showing and canceling the file dialog Reviewed-by: serb, anthony ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java Changeset: 8530456e0091 Author: omajid Date: 2013-09-16 15:43 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8530456e0091 8024863: X11: Support GNOME Shell as mutter Reviewed-by: anthony ! src/solaris/classes/sun/awt/X11/XWM.java Changeset: 4899f6734a14 Author: ant Date: 2013-09-18 12:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/4899f6734a14 8024839: [Unified Swing/Fx threading] don't schedule an event dispatching from the event dispatch thread Reviewed-by: anthony, pchelko ! src/share/classes/java/awt/EventQueue.java Changeset: cc7a15f4c735 Author: mcherkas Date: 2013-09-18 15:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cc7a15f4c735 8016746: Test javax/swing/JTable/7068740/bug7068740.java fails Reviewed-by: serb, alexsch ! test/javax/swing/JTable/7068740/bug7068740.java Changeset: 2c240454c192 Author: leonidr Date: 2013-09-18 18:36 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2c240454c192 7188071: closed/java/awt/TrayIcon/TrayIconSecurity/GrantedTrayIconTest fails Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java Changeset: 20b1135647fa Author: lana Date: 2013-09-18 16:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/20b1135647fa Merge ! src/share/classes/java/awt/Toolkit.java - src/share/classes/java/util/stream/CloseableStream.java - src/share/classes/java/util/stream/DelegatingStream.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/windows/native/sun/windows/awt_PrintControl.cpp - test/java/util/Collection/ListDefaults.java - test/java/util/Map/CheckRandomHashSeed.java - test/java/util/Map/TreeBinSplitBackToEntries.java - test/java/util/concurrent/ConcurrentHashMap/toArray.java - test/sun/tools/jconsole/ImmutableResourceTest.java - test/sun/tools/jconsole/ImmutableResourceTest.sh Changeset: e292d504ad68 Author: leonidr Date: 2013-09-19 22:33 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e292d504ad68 7144065: [macosx] Orphaned Choice popup window Reviewed-by: anthony, serb Contributed-by: alexander.potochkin at oracle.com ! src/macosx/classes/sun/lwawt/LWChoicePeer.java Changeset: 602e5d0141d3 Author: leonidr Date: 2013-09-19 23:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/602e5d0141d3 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol Reviewed-by: anthony, serb ! makefiles/GensrcProperties.gmk + src/macosx/classes/sun/awt/resources/awtosx.properties ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/sun/awt/AWTAccessor.java + test/java/awt/Toolkit/ToolkitPropertyTest/bug7129133.java Changeset: c04e55e17066 Author: kshefov Date: 2013-09-20 17:07 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c04e55e17066 7124314: [TEST_BUG] [macosx] Aqua LAF: JTree doesn't select element by keyboards left and right keys Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JTree/4927934/bug4927934.java Changeset: 6c1f9468f3de Author: kshefov Date: 2013-09-20 17:16 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6c1f9468f3de 8017180: [macosx] [TEST_BUG] alt-key doesn't work on macos for menu Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/java/awt/Focus/KeyEventForBadFocusOwnerTest/KeyEventForBadFocusOwnerTest.java + test/javax/swing/JMenuItem/4171437/bug4171437.java + test/javax/swing/JPopupMenu/4458079/bug4458079.java Changeset: f139aef966fd Author: kshefov Date: 2013-09-20 17:35 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f139aef966fd 7124232: [TEST_BUG] [macosx] JSplitPane has wrong divider location Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JSplitPane/4816114/bug4816114.java Changeset: abebe03818f6 Author: malenkov Date: 2013-09-20 18:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/abebe03818f6 7024235: Nimbus L&F: wrong "packing" of a frame containing tabbed pane Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java + test/javax/swing/JTabbedPane/7024235/Test7024235.java Changeset: 2ac59698de38 Author: kshefov Date: 2013-09-23 16:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2ac59698de38 8015600: [TEST_BUG] [macosx] Test closed/javax/swing/plaf/basic/BasicMenuUI/4983388/bug4983388.java fails since JDK 8 b75 on MacOSX Reviewed-by: alexsch, serb + test/javax/swing/plaf/basic/BasicMenuUI/4983388/bug4983388.java Changeset: eac52fe3990c Author: serb Date: 2013-09-23 16:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/eac52fe3990c 8005255: [macosx] Cleanup warnings in sun.lwawt Reviewed-by: alexsch, anthony ! make/sun/lwawt/FILES_export_macosx.gmk ! src/macosx/classes/sun/lwawt/LWButtonPeer.java ! src/macosx/classes/sun/lwawt/LWCanvasPeer.java ! src/macosx/classes/sun/lwawt/LWCheckboxPeer.java ! src/macosx/classes/sun/lwawt/LWChoicePeer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWContainerPeer.java ! src/macosx/classes/sun/lwawt/LWCursorManager.java ! src/macosx/classes/sun/lwawt/LWLabelPeer.java ! src/macosx/classes/sun/lwawt/LWListPeer.java ! src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java ! src/macosx/classes/sun/lwawt/LWPanelPeer.java ! src/macosx/classes/sun/lwawt/LWRepaintArea.java ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java ! src/macosx/classes/sun/lwawt/LWScrollPanePeer.java ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java - src/macosx/classes/sun/lwawt/SelectionClearListener.java Changeset: 2684fd4e9f3b Author: serb Date: 2013-09-23 17:55 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2684fd4e9f3b 7172833: For default java.awt.Toolkit impl methods java.awt.Toolkit.is/setDynamicLayout() are not consistent Reviewed-by: alexsch, anthony ! src/share/classes/java/awt/Toolkit.java + test/java/awt/Toolkit/DynamicLayout/bug7172833.java Changeset: d73d3a29065c Author: serb Date: 2013-09-23 21:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d73d3a29065c 8019282: keyRelesed is reached even though key was NOT released Reviewed-by: serb, anthony Contributed-by: alexander.zvegintsev at oracle.com ! make/sun/xawt/mapfile-vers ! makefiles/mapfiles/libawt_xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: 8c0b943a0090 Author: yan Date: 2013-09-24 12:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8c0b943a0090 8025114: Eliminate doclint errors in java.awt.dnd package javadoc Reviewed-by: serb, alexsch ! src/share/classes/java/awt/dnd/DragGestureRecognizer.java ! src/share/classes/java/awt/dnd/DragSource.java ! src/share/classes/java/awt/dnd/DragSourceContext.java ! src/share/classes/java/awt/dnd/DragSourceDragEvent.java ! src/share/classes/java/awt/dnd/DragSourceDropEvent.java ! src/share/classes/java/awt/dnd/DragSourceEvent.java ! src/share/classes/java/awt/dnd/DropTarget.java ! src/share/classes/java/awt/dnd/DropTargetDragEvent.java ! src/share/classes/java/awt/dnd/DropTargetDropEvent.java Changeset: 1303823e89da Author: yan Date: 2013-09-24 16:36 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/1303823e89da 8025230: [cleanup] some more javadoc formatting fixes for swing Reviewed-by: alexsch ! src/share/classes/javax/swing/JPanel.java ! src/share/classes/javax/swing/JPasswordField.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/javax/swing/JRadioButton.java ! src/share/classes/javax/swing/JRadioButtonMenuItem.java ! src/share/classes/javax/swing/JRootPane.java ! src/share/classes/javax/swing/JScrollPane.java ! src/share/classes/javax/swing/JSeparator.java ! src/share/classes/javax/swing/JSlider.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JTextArea.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JToolBar.java ! src/share/classes/javax/swing/JToolTip.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JViewport.java ! src/share/classes/javax/swing/KeyStroke.java ! src/share/classes/javax/swing/OverlayLayout.java ! src/share/classes/javax/swing/ProgressMonitor.java ! src/share/classes/javax/swing/SizeRequirements.java ! src/share/classes/javax/swing/SizeSequence.java Changeset: d580e0bc85d9 Author: yan Date: 2013-09-24 17:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d580e0bc85d9 8025117: [cleanup] Eliminate doclint errors in javax/swing/text classes Reviewed-by: alexsch ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/RowFilter.java ! src/share/classes/javax/swing/plaf/TextUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/share/classes/javax/swing/text/AttributeSet.java ! src/share/classes/javax/swing/text/BadLocationException.java ! src/share/classes/javax/swing/text/BoxView.java ! src/share/classes/javax/swing/text/Caret.java ! src/share/classes/javax/swing/text/ComponentView.java ! src/share/classes/javax/swing/text/CompositeView.java ! src/share/classes/javax/swing/text/DefaultEditorKit.java ! src/share/classes/javax/swing/text/DefaultHighlighter.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/Document.java ! src/share/classes/javax/swing/text/DocumentFilter.java ! src/share/classes/javax/swing/text/EditorKit.java ! src/share/classes/javax/swing/text/FieldView.java ! src/share/classes/javax/swing/text/FlowView.java ! src/share/classes/javax/swing/text/GapContent.java ! src/share/classes/javax/swing/text/GlyphView.java ! src/share/classes/javax/swing/text/Highlighter.java ! src/share/classes/javax/swing/text/IconView.java ! src/share/classes/javax/swing/text/NavigationFilter.java ! src/share/classes/javax/swing/text/ParagraphView.java ! src/share/classes/javax/swing/text/PasswordView.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/PlainView.java ! src/share/classes/javax/swing/text/Position.java ! src/share/classes/javax/swing/text/StringContent.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/StyledDocument.java ! src/share/classes/javax/swing/text/StyledEditorKit.java ! src/share/classes/javax/swing/text/TabExpander.java ! src/share/classes/javax/swing/text/TabableView.java ! src/share/classes/javax/swing/text/TableView.java ! src/share/classes/javax/swing/text/Utilities.java ! src/share/classes/javax/swing/text/View.java ! src/share/classes/javax/swing/text/WrappedPlainView.java ! src/share/classes/javax/swing/text/ZoneView.java ! src/share/classes/javax/swing/text/html/BlockView.java ! src/share/classes/javax/swing/text/html/CSS.java ! src/share/classes/javax/swing/text/html/FormView.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java Changeset: 58178aec7e81 Author: kshefov Date: 2013-09-24 17:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/58178aec7e81 7124320: [TEST_BUG] [macosx] JComboBox doesn't change selection on mouse over Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JComboBox/6236162/bug6236162.java Changeset: f500844c2253 Author: kshefov Date: 2013-09-24 17:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f500844c2253 7133154: [TEST_BUG] [macosx] closed/javax/swing/JInternalFrame/4251301/bug4251301.java fails on MacOS Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JInternalFrame/4251301/bug4251301.java Changeset: 967557d5b90a Author: kshefov Date: 2013-09-24 18:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/967557d5b90a 7133146: [macosx] closed/javax/swing/JInternalFrame/4193219/IconCoord fails on MacOS Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JInternalFrame/4193219/IconCoord.java Changeset: 3982dd1210ba Author: kshefov Date: 2013-09-24 18:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3982dd1210ba 8015599: [TEST_BUG] [macosx] Test closed/javax/swing/Popup/TaskbarPositionTest.java fails since JDK 8 b75 on MacOSX Reviewed-by: alexsch, serb + test/javax/swing/Popup/TaskbarPositionTest.java Changeset: 2ed1584d62c5 Author: leonidr Date: 2013-09-24 18:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2ed1584d62c5 8022555: [macosx] AppleScriptEngine.jar MUST call java.awt.Toolkit.getDefaultToolkit() lazily Reviewed-by: anthony, serb ! src/macosx/classes/apple/applescript/AppleScriptEngineFactory.java Changeset: a284da808700 Author: malenkov Date: 2013-09-25 14:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a284da808700 8023310: Thread contention in the method Beans.IsDesignTime() Reviewed-by: art, sfriberg ! src/share/classes/java/beans/ThreadGroupContext.java ! src/share/classes/java/beans/WeakIdentityMap.java Changeset: 10e66428ddb0 Author: alexsch Date: 2013-09-25 16:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/10e66428ddb0 8007155: [macosx] Disabled panel takes mouse input in JLayeredPane Reviewed-by: serb, anthony ! src/macosx/classes/sun/lwawt/LWCursorManager.java ! src/share/classes/java/awt/Container.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/GlobalCursorManager.java ! src/solaris/classes/sun/awt/X11/XGlobalCursorManager.java ! src/windows/classes/sun/awt/windows/WGlobalCursorManager.java ! src/windows/native/sun/windows/awt_Container.cpp ! src/windows/native/sun/windows/awt_Container.h ! src/windows/native/sun/windows/awt_Cursor.cpp + test/java/awt/Cursor/CursorOverlappedPanelsTest/CursorOverlappedPanelsTest.html + test/java/awt/Cursor/CursorOverlappedPanelsTest/CursorOverlappedPanelsTest.java Changeset: 7cad8ef127a9 Author: pchelko Date: 2013-09-25 16:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7cad8ef127a9 8024987: Copy/paste regression since JDK8 b86 Reviewed-by: serb, anthony ! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java Changeset: cff4f079fa3f Author: kshefov Date: 2013-09-25 16:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/cff4f079fa3f 8004032: [TEST_BUG] [macosx] There is no effect when double clicking on the Icon, after right clicking on the Icon and the Icon disappear Reviewed-by: anthony, serb + test/java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html + test/java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.java Changeset: 681ac9f9c452 Author: alexsch Date: 2013-09-25 17:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/681ac9f9c452 8025070: [javadoc] fix some javadoc errors in javax/swing/plaf/synth Reviewed-by: serb, alexsch Contributed-by: Alexander Stepanov ! src/share/classes/javax/swing/plaf/synth/SynthButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthCheckBoxMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthCheckBoxUI.java ! src/share/classes/javax/swing/plaf/synth/SynthColorChooserUI.java ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java ! src/share/classes/javax/swing/plaf/synth/SynthDesktopIconUI.java ! src/share/classes/javax/swing/plaf/synth/SynthDesktopPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthEditorPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthFormattedTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameUI.java ! src/share/classes/javax/swing/plaf/synth/SynthLabelUI.java ! src/share/classes/javax/swing/plaf/synth/SynthListUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuLayout.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuUI.java ! src/share/classes/javax/swing/plaf/synth/SynthOptionPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPainter.java ! src/share/classes/javax/swing/plaf/synth/SynthPanelUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPasswordFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPopupMenuUI.java ! src/share/classes/javax/swing/plaf/synth/SynthProgressBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRadioButtonMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRadioButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRootPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthScrollPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSeparatorUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSpinnerUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTableHeaderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToggleButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToolTipUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java ! src/share/classes/javax/swing/plaf/synth/SynthViewportUI.java Changeset: 2f8803ebd98c Author: yan Date: 2013-09-25 17:35 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2f8803ebd98c 8025085: [javadoc] some errors in javax/swing Reviewed-by: alexsch Contributed-by: Dmitry Zinkevich ! src/share/classes/javax/swing/JButton.java ! src/share/classes/javax/swing/JCheckBox.java ! src/share/classes/javax/swing/JCheckBoxMenuItem.java ! src/share/classes/javax/swing/JColorChooser.java ! src/share/classes/javax/swing/JComboBox.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JDesktopPane.java ! src/share/classes/javax/swing/JMenuItem.java ! src/share/classes/javax/swing/JToggleButton.java ! src/share/classes/javax/swing/SpinnerDateModel.java ! src/share/classes/javax/swing/SpinnerListModel.java ! src/share/classes/javax/swing/SpinnerNumberModel.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/UnsupportedLookAndFeelException.java ! src/share/classes/javax/swing/ViewportLayout.java ! src/share/classes/javax/swing/plaf/LayerUI.java ! src/share/classes/javax/swing/plaf/basic/BasicBorders.java ! src/share/classes/javax/swing/plaf/basic/BasicDesktopIconUI.java ! src/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicGraphicsUtils.java ! src/share/classes/javax/swing/plaf/basic/BasicIconFactory.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLabelUI.java ! src/share/classes/javax/swing/plaf/basic/BasicListUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolBarSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolTipUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/javax/swing/plaf/basic/DefaultMenuLayout.java ! src/share/classes/javax/swing/plaf/metal/MetalBorders.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalLabelUI.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalPopupMenuSeparatorUI.java ! src/share/classes/javax/swing/plaf/metal/MetalScrollPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSeparatorUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java ! src/share/classes/javax/swing/plaf/metal/MetalTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToolTipUI.java ! src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java ! src/share/classes/javax/swing/plaf/synth/Region.java ! src/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/share/classes/javax/swing/text/html/ImageView.java ! src/share/classes/javax/swing/text/html/InlineView.java ! src/share/classes/javax/swing/text/html/StyleSheet.java ! src/share/classes/javax/swing/text/html/parser/ContentModel.java ! src/share/classes/javax/swing/text/html/parser/DocumentParser.java ! src/share/classes/javax/swing/text/html/parser/Parser.java ! src/share/classes/javax/swing/tree/AbstractLayoutCache.java ! src/share/classes/javax/swing/tree/DefaultTreeCellEditor.java ! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java ! src/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/share/classes/javax/swing/tree/TreeCellRenderer.java ! src/share/classes/javax/swing/tree/TreeModel.java ! src/share/classes/javax/swing/undo/UndoManager.java Changeset: c40ed21f2939 Author: alexsch Date: 2013-09-25 17:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c40ed21f2939 7083457: Incomplete specification for javax/swing/text/DefaultCaret.html#setVisible(boolean) Reviewed-by: malenkov, serb ! src/share/classes/javax/swing/text/DefaultCaret.java + test/javax/swing/text/DefaultCaret/7083457/bug7083457.java Changeset: 09fb25645717 Author: ptbrunet Date: 2013-09-26 10:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/09fb25645717 8025160: Recent Java Accessibility Bridge push has make failures Reviewed-by: tbell, erikj ! make/bridge/AccessBridgeJava/Makefile ! makefiles/CreateJars.gmk ! makefiles/GensrcMisc.gmk Changeset: 0270e9b0891b Author: yan Date: 2013-09-26 16:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0270e9b0891b 8025218: [javadoc] some errors in java/awt classes Reviewed-by: yan Contributed-by: Dmitry Zinkevich ! src/share/classes/java/awt/AWTKeyStroke.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/Event.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/GridBagConstraints.java ! src/share/classes/java/awt/GridBagLayout.java ! src/share/classes/java/awt/GridLayout.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/MenuBar.java ! src/share/classes/java/awt/ScrollPane.java ! src/share/classes/java/awt/ScrollPaneAdjustable.java ! src/share/classes/java/awt/SystemTray.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/awt/event/MouseMotionListener.java Changeset: 3b22833f2695 Author: lana Date: 2013-09-26 17:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/3b22833f2695 Merge - src/macosx/classes/sun/lwawt/SelectionClearListener.java - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java Changeset: 8708569b5524 Author: sjiang Date: 2013-09-18 08:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8708569b5524 8023954: MBean*Info.equals: throw NPE Reviewed-by: dfuchs, dholmes ! src/share/classes/javax/management/MBeanAttributeInfo.java ! src/share/classes/javax/management/MBeanConstructorInfo.java ! src/share/classes/javax/management/MBeanFeatureInfo.java ! src/share/classes/javax/management/MBeanNotificationInfo.java ! src/share/classes/javax/management/MBeanOperationInfo.java ! src/share/classes/javax/management/MBeanParameterInfo.java + test/javax/management/MBeanInfo/MBeanInfoEqualsNPETest.java Changeset: ee8b292ee568 Author: weijun Date: 2013-09-18 18:22 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/ee8b292ee568 8012615: Realm.getRealmsList returns realms list in wrong Reviewed-by: valeriep, xuelei ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! test/sun/security/krb5/ParseCAPaths.java ! test/sun/security/krb5/krb5-capaths.conf Changeset: e92635d6834c Author: alanb Date: 2013-09-18 14:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/e92635d6834c 8024883: (se) SelectableChannel.register throws NPE if fd >= 64k (lnx) Reviewed-by: alanb, coffeys Contributed-by: nmaurer at redhat.com, alan.bateman at oracle.com ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EventPortWrapper.java ! test/java/nio/channels/Selector/LotsOfChannels.java ! test/java/nio/channels/Selector/SelectorLimit.java Changeset: 07d73060e0da Author: weijun Date: 2013-09-18 21:37 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/07d73060e0da 8011402: Move blacklisting certificate logic from hard code to data Reviewed-by: erikj, mullan ! make/java/security/Makefile ! makefiles/CopyFiles.gmk ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/sun/security/util/UntrustedCertificates.java ! src/share/classes/sun/security/x509/X509CertImpl.java + src/share/lib/security/BlacklistedCertsConverter.java + src/share/lib/security/blacklisted.certs + src/share/lib/security/blacklisted.certs.pem + test/lib/security/CheckBlacklistedCerts.java Changeset: b3a506a30fda Author: ewang Date: 2013-09-18 15:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b3a506a30fda 8015762: TEST_BUG: java/nio/channels/DatagramChannel/AdaptDatagramSocket.java failing intermittently [win] Reviewed-by: chegar, alanb ! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java Changeset: 22e9f0067b5a Author: kizune Date: 2013-09-19 17:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/22e9f0067b5a 8017248: Compiler Diacritics Issue Reviewed-by: naoto ! src/share/classes/sun/launcher/LauncherHelper.java + test/tools/launcher/8017248/ClassA??.java + test/tools/launcher/8017248/test.sh Changeset: 7557062d2dd2 Author: plevart Date: 2013-09-19 16:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7557062d2dd2 8011940: java.lang.Class.getAnnotations() always enters synchronized method Reviewed-by: jfranck, chegar, psandoz, shade ! src/share/classes/java/lang/Class.java + test/java/lang/annotation/AnnotationsInheritanceOrderRedefinitionTest.java Changeset: 278873b2b3f8 Author: sherman Date: 2013-09-19 10:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/278873b2b3f8 8023113: tools/jar/ChangeDir.java fails if /tmp/a exists Summary: updated the test case Reviewed-by: alanb ! test/tools/jar/ChangeDir.java Changeset: f36714707c38 Author: psandoz Date: 2013-09-18 10:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f36714707c38 8025002: "".codePoints().sorted().iterator().hasNext() causes NegativeArraySizeException Reviewed-by: henryjen, alanb ! src/share/classes/java/lang/CharSequence.java ! test/java/lang/CharSequence/DefaultTest.java Changeset: 0ef7ddef9de0 Author: psandoz Date: 2013-09-19 20:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/0ef7ddef9de0 8024405: Spliterators.spliterator should support CONCURRENT characteristic Reviewed-by: martin ! src/share/classes/java/util/Spliterator.java ! src/share/classes/java/util/Spliterators.java ! test/java/util/Spliterator/SpliteratorCharacteristics.java ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java Changeset: 58fd427b454d Author: sla Date: 2013-09-20 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/58fd427b454d 8024985: com/sun/jdi/StepTest.java failed since jdk8b107 Reviewed-by: dcubed ! test/com/sun/jdi/ExceptionEvents.java ! test/com/sun/jdi/FilterNoMatch.java ! test/com/sun/jdi/JDIScaffold.java ! test/com/sun/jdi/PopAndStepTest.java ! test/com/sun/jdi/RepStep.java ! test/com/sun/jdi/TestScaffold.java Changeset: 6a1c70e191d4 Author: sla Date: 2013-09-20 10:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/6a1c70e191d4 8024416: TESTBUG: com/sun/jdi/MethodEntryExitEvents.java: method entry count mismatch Reviewed-by: dcubed ! test/com/sun/jdi/MethodEntryExitEvents.java Changeset: afe857b13b62 Author: kizune Date: 2013-09-20 17:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/afe857b13b62 8025076: Fix for JDK-8017248 breaks jprt submission for non-unicode locales Reviewed-by: naoto, ksrini - test/tools/launcher/8017248/ClassA??.java - test/tools/launcher/8017248/test.sh + test/tools/launcher/DiacriticTest.java Changeset: 94cc251d0c45 Author: sla Date: 2013-09-20 16:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/94cc251d0c45 7200277: [parfait] potential buffer overflow in npt/utf.c Reviewed-by: dsamersoff, dcubed ! src/share/npt/utf.c Changeset: 7913855ff66c Author: psandoz Date: 2013-09-20 11:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7913855ff66c 8024253: ThreadLocal random can use SecureRandom for the initial seed Reviewed-by: psandoz, chegar, alanb Contributed-by: Doug Lea
, Peter Levart , Guy Steele ! src/share/classes/java/util/SplittableRandom.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java ! test/java/util/concurrent/ThreadLocalRandom/ThreadLocalRandomTest.java Changeset: 2552cd270350 Author: bpb Date: 2013-09-20 15:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2552cd270350 8024331: j.u.Map.computeIfPresent() default/nondefault implementations don't throw NPE if the remappingFunction is null and the key is absent Summary: Explicitly check for null remappingFunction parameter. Reviewed-by: mduigou, forax, psandoz Contributed-by: Brian Burkhalter ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Map.java ! test/java/util/Map/Defaults.java Changeset: c30dc8e7744e Author: psandoz Date: 2013-09-20 17:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/c30dc8e7744e 8024341: j.u.regex.Pattern.splitAsStream() doesn't correspond to split() method if using an example from the spec Reviewed-by: alanb ! src/share/classes/java/util/regex/Pattern.java + test/java/util/regex/PatternStreamTest.java - test/java/util/regex/PatternTest.java Changeset: 56d247821694 Author: alanb Date: 2013-09-23 04:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/56d247821694 8023130: (process) ProcessBuilder#inheritIO does not work on Windows Reviewed-by: alanb, martin Contributed-by: ivan.gerasimov at oracle.com ! src/windows/native/java/lang/ProcessImpl_md.c ! test/java/lang/ProcessBuilder/Basic.java + test/java/lang/ProcessBuilder/InheritIO/InheritIO.java + test/java/lang/ProcessBuilder/InheritIO/InheritIO.sh Changeset: a3b17b91127d Author: lana Date: 2013-09-20 19:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/a3b17b91127d Merge Changeset: f1b251affc6a Author: lana Date: 2013-09-22 20:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/f1b251affc6a Merge Changeset: b606775fd1a3 Author: stefank Date: 2013-08-29 11:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/b606775fd1a3 8014659: NPG: performance counters for compressed klass space Reviewed-by: jmasa, sla Contributed-by: erik.helin at oracle.com ! src/share/classes/sun/tools/jstat/resources/jstat_options ! test/sun/tools/jstat/gcCapacityOutput1.awk ! test/sun/tools/jstat/gcCauseOutput1.awk ! test/sun/tools/jstat/gcMetaCapacityOutput1.awk ! test/sun/tools/jstat/gcOldOutput1.awk ! test/sun/tools/jstat/gcOutput1.awk ! test/sun/tools/jstat/lineCounts1.awk ! test/sun/tools/jstat/lineCounts2.awk ! test/sun/tools/jstat/lineCounts3.awk ! test/sun/tools/jstat/lineCounts4.awk ! test/sun/tools/jstat/timeStamp1.awk ! test/sun/tools/jstatd/jstatGcutilOutput1.awk Changeset: 76619d71a7c5 Author: dfuchs Date: 2013-09-25 09:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/76619d71a7c5 8025140: TEST_BUG: java/util/logging/Logger/getGlobal tests fail due to timeout Summary: Arbitrary timeouts in the tests @run lines where too agressive for some configurations. The tests will now run with default timeout. Reviewed-by: alanb, mchung ! test/java/util/logging/Logger/getGlobal/TestGetGlobal.java ! test/java/util/logging/Logger/getGlobal/TestGetGlobalByName.java ! test/java/util/logging/Logger/getGlobal/TestGetGlobalConcurrent.java Changeset: 2b928330970a Author: mfang Date: 2013-09-24 14:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2b928330970a 8025215: jdk8 l10n resource file translation update 4 Reviewed-by: naoto, yhuang ! src/macosx/classes/com/apple/laf/resources/aqua_ko.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_de.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_es.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_fr.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_it.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_sv.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_de.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ko.properties + src/share/classes/com/sun/java/util/jar/pack/DriverResource_ja.java + src/share/classes/com/sun/java/util/jar/pack/DriverResource_zh_CN.java ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_sv.properties ! src/share/classes/sun/applet/resources/MsgAppletViewer_de.java ! src/share/classes/sun/launcher/resources/launcher_de.properties ! src/share/classes/sun/launcher/resources/launcher_es.properties ! src/share/classes/sun/launcher/resources/launcher_fr.properties ! src/share/classes/sun/launcher/resources/launcher_it.properties ! src/share/classes/sun/launcher/resources/launcher_ja.properties ! src/share/classes/sun/launcher/resources/launcher_ko.properties ! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties ! src/share/classes/sun/launcher/resources/launcher_sv.properties ! src/share/classes/sun/launcher/resources/launcher_zh_CN.properties ! src/share/classes/sun/launcher/resources/launcher_zh_TW.properties ! src/share/classes/sun/print/resources/serviceui_de.properties ! src/share/classes/sun/print/resources/serviceui_es.properties ! src/share/classes/sun/print/resources/serviceui_fr.properties ! src/share/classes/sun/print/resources/serviceui_it.properties ! src/share/classes/sun/print/resources/serviceui_pt_BR.properties ! src/share/classes/sun/print/resources/serviceui_sv.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_de.properties ! src/share/classes/sun/rmi/server/resources/rmid_ko.properties ! src/share/classes/sun/security/tools/jarsigner/Resources_ja.java ! src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java ! src/share/classes/sun/security/tools/keytool/Resources_de.java ! src/share/classes/sun/security/tools/keytool/Resources_es.java ! src/share/classes/sun/security/tools/keytool/Resources_fr.java ! src/share/classes/sun/security/tools/keytool/Resources_it.java ! src/share/classes/sun/security/tools/keytool/Resources_ja.java ! src/share/classes/sun/security/tools/keytool/Resources_ko.java ! src/share/classes/sun/security/tools/keytool/Resources_pt_BR.java ! src/share/classes/sun/security/tools/keytool/Resources_sv.java ! src/share/classes/sun/security/tools/keytool/Resources_zh_CN.java ! src/share/classes/sun/security/tools/keytool/Resources_zh_TW.java ! src/share/classes/sun/security/tools/policytool/Resources_de.java ! src/share/classes/sun/security/tools/policytool/Resources_es.java ! src/share/classes/sun/security/tools/policytool/Resources_fr.java ! src/share/classes/sun/security/tools/policytool/Resources_it.java ! src/share/classes/sun/security/tools/policytool/Resources_ja.java ! src/share/classes/sun/security/tools/policytool/Resources_ko.java ! src/share/classes/sun/security/tools/policytool/Resources_pt_BR.java ! src/share/classes/sun/security/tools/policytool/Resources_sv.java ! src/share/classes/sun/security/tools/policytool/Resources_zh_CN.java ! src/share/classes/sun/security/tools/policytool/Resources_zh_TW.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/tools/jar/resources/jar_de.properties ! src/share/classes/sun/tools/jar/resources/jar_es.properties ! src/share/classes/sun/tools/jar/resources/jar_fr.properties ! src/share/classes/sun/tools/jar/resources/jar_it.properties ! src/share/classes/sun/tools/jar/resources/jar_ja.properties ! src/share/classes/sun/tools/jar/resources/jar_ko.properties ! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties ! src/share/classes/sun/tools/jar/resources/jar_sv.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties ! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties ! src/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties Changeset: 9765801f209f Author: mfang Date: 2013-09-24 14:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9765801f209f Merge - test/java/util/regex/PatternTest.java Changeset: d16a53d1762f Author: mfang Date: 2013-09-25 07:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/d16a53d1762f Merge Changeset: 8f27030686a6 Author: bchristi Date: 2013-09-26 11:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8f27030686a6 8025173: HashMap.put() replacing an existing key can trigger a resize() Summary: Ensure that HashMap is not resized if we're just replacing a value Reviewed-by: alanb, martin ! src/share/classes/java/util/HashMap.java + test/java/util/HashMap/ReplaceExisting.java Changeset: 8edd604bf960 Author: lana Date: 2013-09-26 17:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/8edd604bf960 Merge - test/java/util/regex/PatternTest.java Changeset: 9684ed81cd21 Author: ksrini Date: 2013-09-27 16:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9684ed81cd21 8020552: [launcher] changes to support removal of Solaris 32-bit distribution 8023495: [infra] create 64-bit solaris bits with symlinks Reviewed-by: ihse, tbell, dholmes, darcy, alanb, erikj, sla, martin ! makefiles/Images.gmk ! src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/solaris/bin/java_md_solinux.c ! test/com/sun/jdi/BadHandshakeTest.java ! test/com/sun/jdi/DoubleAgentTest.java ! test/com/sun/jdi/ExclusiveBind.java ! test/com/sun/jdi/PrivateTransportTest.sh ! test/com/sun/jdi/RunToExit.java - test/com/sun/jdi/Solaris32AndSolaris64Test.sh ! test/com/sun/jdi/connect/spi/SimpleLaunchingConnector.java ! test/demo/jvmti/DemoRun.java ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/Makefile + test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh ! test/sun/security/tools/keytool/autotest.sh ! test/sun/tools/jhat/HatRun.java ! test/tools/launcher/6842838/Test6842838.sh ! test/tools/launcher/ChangeDataModel.java ! test/tools/launcher/ExecutionEnvironment.java ! test/tools/launcher/FXLauncherTest.java ! test/tools/launcher/RunpathTest.java ! test/tools/launcher/Test7029048.java ! test/tools/launcher/TestHelper.java Changeset: 2c7c7b813eb3 Author: katleman Date: 2013-10-01 12:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/2c7c7b813eb3 Merge - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so Changeset: dd43ccb3bac9 Author: ihse Date: 2013-10-01 11:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/dd43ccb3bac9 8019219: Fix typo in jdk/makefiles "default" targets Reviewed-by: erikj ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk Changeset: 54e099776f08 Author: erikj Date: 2013-10-02 15:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/54e099776f08 Merge Changeset: 9f57d2774603 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/9f57d2774603 Added tag jdk8-b110 for changeset 54e099776f08 ! .hgtags From coleen.phillimore at oracle.com Thu Oct 3 15:49:52 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 03 Oct 2013 18:49:52 -0400 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DD388.8060706@oracle.com> References: <524DB145.5030109@oracle.com> <524DD388.8060706@oracle.com> Message-ID: <524DF490.3000005@oracle.com> Thanks Dan - On 10/3/2013 4:28 PM, Daniel D. Daugherty wrote: > > open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk > > test/java/lang/instrument/RedefineMethodInBacktrace.sh > No comments. > > test/java/lang/instrument/RedefineMethodInBacktraceApp.java > line 78: t.setDaemon(true); > Why make the target thread a daemon? Wouldn't it be a more > complete test to do Thread.join() of that thread just to > be sure that the target thread has finished (and is not > stuck)? Staffan, can you answer this? Coleen > > test/java/lang/instrument/RedefineMethodInBacktraceTargetB.java > test/java/lang/instrument/RedefineMethodInBacktraceTargetB_2.java > Nice sync logic with the test driver. > > Thumbs up. > > Dan > > > On 10/3/13 12:02 PM, Coleen Phillimore wrote: >> Summary: Redefined class in stack trace may not be found by >> method_idnum so handle null. >> >> This is a simple change. I had another change to save the method >> name (as u2) in the backtrace, but it's not worth the extra footprint >> in backtraces for this rare case. >> >> The root problem was that we save method_idnum in the backtrace (u2) >> instead of Method* to avoid Method* from being redefined and >> deallocated. I made a change to InstanceKlass::method_from_idnum() >> to return null rather than the last method in the list, which causes >> this crash. Dan and I went down the long rabbit-hole of why >> method_idnum is changed for obsolete methods and we think there's >> some cleanup and potential bugs in this area. But this is not that >> change. I'll file another bug to continue this investigation for >> jdk9 (or 8uN). >> >> Staffan created a test - am including core-libs for the review >> request. Also tested with all of the vm testbase tests, mlvm tests, >> and java/lang/instrument tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8025238 >> >> test case for jdk8 repository: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk >> >> Thanks, >> Coleen >> >> > From coleen.phillimore at oracle.com Thu Oct 3 15:56:21 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 03 Oct 2013 18:56:21 -0400 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DCE7D.7020703@oracle.com> References: <524DB145.5030109@oracle.com> <524DCE7D.7020703@oracle.com> Message-ID: <524DF615.4000808@oracle.com> Thanks Dan - On 10/3/2013 4:07 PM, Daniel D. Daugherty wrote: > > 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 something? > A caller may not be expecting those to be NULL. > > Also, holder->method_with_idnum(method_id) should be able to > search the previous class version list and find the obsolete > Method* that matches the 'method_id' value. > We don't save the obsolete versions on the previous version list, only the emcp versions. I just looked at the old code and that's always been the case. So the method that has the method_idnum that isn't supposed to be found is an obsolete method. Coleen > src/share/vm/prims/jvmtiRedefineClasses.cpp > Better comment than the original. > > Dan > > > On 10/3/13 12:02 PM, Coleen Phillimore wrote: >> Summary: Redefined class in stack trace may not be found by >> method_idnum so handle null. >> >> This is a simple change. I had another change to save the method >> name (as u2) in the backtrace, but it's not worth the extra footprint >> in backtraces for this rare case. >> >> The root problem was that we save method_idnum in the backtrace (u2) >> instead of Method* to avoid Method* from being redefined and >> deallocated. I made a change to InstanceKlass::method_from_idnum() >> to return null rather than the last method in the list, which causes >> this crash. Dan and I went down the long rabbit-hole of why >> method_idnum is changed for obsolete methods and we think there's >> some cleanup and potential bugs in this area. But this is not that >> change. I'll file another bug to continue this investigation for >> jdk9 (or 8uN). >> >> Staffan created a test - am including core-libs for the review >> request. Also tested with all of the vm testbase tests, mlvm tests, >> and java/lang/instrument tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8025238 >> >> test case for jdk8 repository: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk >> >> Thanks, >> Coleen > From daniel.daugherty at oracle.com Thu Oct 3 16:01:34 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 03 Oct 2013 17:01:34 -0600 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DF615.4000808@oracle.com> References: <524DB145.5030109@oracle.com> <524DCE7D.7020703@oracle.com> <524DF615.4000808@oracle.com> Message-ID: <524DF74E.9090205@oracle.com> On 10/3/13 4:56 PM, Coleen Phillmore wrote: > > Thanks Dan - > > On 10/3/2013 4:07 PM, Daniel D. Daugherty wrote: >> > 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 something? >> A caller may not be expecting those to be NULL. >> >> Also, holder->method_with_idnum(method_id) should be able to >> search the previous class version list and find the obsolete >> Method* that matches the 'method_id' value. >> > > We don't save the obsolete versions on the previous version list, only > the emcp versions. I just looked at the old code and that's always > been the case. So the method that has the method_idnum that isn't > supposed to be found is an obsolete method. Clearly I've forgotten... thumbs up! Dan > > Coleen > >> src/share/vm/prims/jvmtiRedefineClasses.cpp >> Better comment than the original. >> >> Dan >> >> >> On 10/3/13 12:02 PM, Coleen Phillimore wrote: >>> Summary: Redefined class in stack trace may not be found by >>> method_idnum so handle null. >>> >>> This is a simple change. I had another change to save the method >>> name (as u2) in the backtrace, but it's not worth the extra >>> footprint in backtraces for this rare case. >>> >>> The root problem was that we save method_idnum in the backtrace (u2) >>> instead of Method* to avoid Method* from being redefined and >>> deallocated. I made a change to InstanceKlass::method_from_idnum() >>> to return null rather than the last method in the list, which causes >>> this crash. Dan and I went down the long rabbit-hole of why >>> method_idnum is changed for obsolete methods and we think there's >>> some cleanup and potential bugs in this area. But this is not that >>> change. I'll file another bug to continue this investigation for >>> jdk9 (or 8uN). >>> >>> Staffan created a test - am including core-libs for the review >>> request. Also tested with all of the vm testbase tests, mlvm tests, >>> and java/lang/instrument tests. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8025238 >>> >>> test case for jdk8 repository: >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk >>> >>> Thanks, >>> Coleen >> > From coleen.phillimore at oracle.com Thu Oct 3 16:01:39 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 03 Oct 2013 19:01:39 -0400 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DCAA2.7050305@oracle.com> References: <524DB145.5030109@oracle.com> <524DCAA2.7050305@oracle.com> Message-ID: <524DF753.6070601@oracle.com> Thanks Serguei! Coleen On 10/3/2013 3:50 PM, serguei.spitsyn at oracle.com wrote: > Coleen, > > The fix looks good. > It is nice you've come up with this. > > Thanks, > Serguei > > On 10/3/13 11:02 AM, Coleen Phillimore wrote: >> Summary: Redefined class in stack trace may not be found by >> method_idnum so handle null. >> >> This is a simple change. I had another change to save the method >> name (as u2) in the backtrace, but it's not worth the extra footprint >> in backtraces for this rare case. >> >> The root problem was that we save method_idnum in the backtrace (u2) >> instead of Method* to avoid Method* from being redefined and >> deallocated. I made a change to InstanceKlass::method_from_idnum() >> to return null rather than the last method in the list, which causes >> this crash. Dan and I went down the long rabbit-hole of why >> method_idnum is changed for obsolete methods and we think there's >> some cleanup and potential bugs in this area. But this is not that >> change. I'll file another bug to continue this investigation for >> jdk9 (or 8uN). >> >> Staffan created a test - am including core-libs for the review >> request. Also tested with all of the vm testbase tests, mlvm tests, >> and java/lang/instrument tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8025238 >> >> test case for jdk8 repository: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk >> >> Thanks, >> Coleen > From coleen.phillimore at oracle.com Thu Oct 3 16:02:01 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 03 Oct 2013 19:02:01 -0400 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: References: <524DB145.5030109@oracle.com> Message-ID: <524DF769.5020509@oracle.com> On 10/3/2013 3:29 PM, Staffan Larsen wrote: > Looks good! (Obviously I would think so for the testcase :-) ) Thanks for the testcase! Coleen > > Thanks for fixing, > /Staffan > > On 3 okt 2013, at 20:02, Coleen Phillimore wrote: > >> Summary: Redefined class in stack trace may not be found by method_idnum so handle null. >> >> This is a simple change. I had another change to save the method name (as u2) in the backtrace, but it's not worth the extra footprint in backtraces for this rare case. >> >> The root problem was that we save method_idnum in the backtrace (u2) instead of Method* to avoid Method* from being redefined and deallocated. I made a change to InstanceKlass::method_from_idnum() to return null rather than the last method in the list, which causes this crash. Dan and I went down the long rabbit-hole of why method_idnum is changed for obsolete methods and we think there's some cleanup and potential bugs in this area. But this is not that change. I'll file another bug to continue this investigation for jdk9 (or 8uN). >> >> Staffan created a test - am including core-libs for the review request. Also tested with all of the vm testbase tests, mlvm tests, and java/lang/instrument tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8025238 >> >> test case for jdk8 repository: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Thu Oct 3 16:02:44 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 03 Oct 2013 19:02:44 -0400 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DF74E.9090205@oracle.com> References: <524DB145.5030109@oracle.com> <524DCE7D.7020703@oracle.com> <524DF615.4000808@oracle.com> <524DF74E.9090205@oracle.com> Message-ID: <524DF794.4000909@oracle.com> On 10/3/2013 7:01 PM, Daniel D. Daugherty wrote: > On 10/3/13 4:56 PM, Coleen Phillmore wrote: >> >> Thanks Dan - >> >> On 10/3/2013 4:07 PM, Daniel D. Daugherty wrote: >>> > 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 something? >>> A caller may not be expecting those to be NULL. >>> >>> Also, holder->method_with_idnum(method_id) should be able to >>> search the previous class version list and find the obsolete >>> Method* that matches the 'method_id' value. >>> >> >> We don't save the obsolete versions on the previous version list, >> only the emcp versions. I just looked at the old code and that's >> always been the case. So the method that has the method_idnum that >> isn't supposed to be found is an obsolete method. > > Clearly I've forgotten... thumbs up! :) Thanks, Coleen > > Dan > > >> >> Coleen >> >>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>> Better comment than the original. >>> >>> Dan >>> >>> >>> On 10/3/13 12:02 PM, Coleen Phillimore wrote: >>>> Summary: Redefined class in stack trace may not be found by >>>> method_idnum so handle null. >>>> >>>> This is a simple change. I had another change to save the method >>>> name (as u2) in the backtrace, but it's not worth the extra >>>> footprint in backtraces for this rare case. >>>> >>>> The root problem was that we save method_idnum in the backtrace >>>> (u2) instead of Method* to avoid Method* from being redefined and >>>> deallocated. I made a change to InstanceKlass::method_from_idnum() >>>> to return null rather than the last method in the list, which >>>> causes this crash. Dan and I went down the long rabbit-hole of why >>>> method_idnum is changed for obsolete methods and we think there's >>>> some cleanup and potential bugs in this area. But this is not that >>>> change. I'll file another bug to continue this investigation for >>>> jdk9 (or 8uN). >>>> >>>> Staffan created a test - am including core-libs for the review >>>> request. Also tested with all of the vm testbase tests, mlvm >>>> tests, and java/lang/instrument tests. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8025238 >>>> >>>> test case for jdk8 repository: >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk >>>> >>>> Thanks, >>>> Coleen >>> >> > From david.holmes at oracle.com Thu Oct 3 17:14:28 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 04 Oct 2013 10:14:28 +1000 Subject: JDK-6989981: jstack causes "fatal error: ExceptionMark destructor expects no pending exceptions" In-Reply-To: <524AD80F.2020308@ysfactory.dip.jp> References: <523C264E.7060704@ysfactory.dip.jp> <97D9FB54-FFF1-4337-942A-E7FE2196A354@oracle.com> <523C534C.7060908@ysfactory.dip.jp> <9367FE2B-C709-4273-BEAE-745841846560@oracle.com> <523C5A8A.8060000@ysfactory.dip.jp> <523C606B.5060204@ysfactory.dip.jp> <952F096A-69D2-4E7C-B979-91E95AFE37F8@oracle.com> <523D786C.5090605@ysfactory.dip.jp> <523EAF7C.3050000@oracle.com> <3FE7CB8E-39F4-4915-B82E-AC2F88715189@oracle.com> <524ACADB.3060600@oracle.com> <524AD80F.2020308@ysfactory.dip.jp> Message-ID: <524E0864.4020505@oracle.com> On 2/10/2013 12:11 AM, Yasumasa Suenaga wrote: > Hi David, > >> Other than printing a message on the console it pretends that the init >> has succeeded! > > No. > > signal_thread_entry() @ hotspot/src/share/vm/runtime/os.cpp > -------- > 250 case SIGBREAK: { > 251 // Check if the signal is a trigger to start the > Attach Listener - in that > 252 // case don't print stack traces. > 253 if (!DisableAttachMechanism && > AttachListener::is_init_trigger()) { > 254 continue; > 255 } > -------- > > AttachListener::init() is called through is_init_trigger() (line 505). > > AttachListener::is_init_trigger() @ > hotspot/src/share/vm/services/attachListener.cpp > -------- > 501 if (ret == 0) { > 502 // simple check to avoid starting the attach mechanism when > 503 // a bogus user creates the file > 504 if (st.st_uid == geteuid()) { > 505 init(); > 506 return true; > 507 } > 508 } > -------- > > If exception occurs in AttachListner::init(), > AttachListner::is_init_trigger() returns "true" . > Process of SIGBREAK handler will be stopped (caused by continue > statement) and signal_thread_entry() > will return top of loop. > > In my patch, pending exception which occurs in AttachListener > initialization is cleared. > Thus Signal Dispatcher has no damage. But as I said the init() fails and we pretend it succeeded with respect to the caller. Now for the signal case if the init fails we can simply do nothing - the VM is running, this particular action failed, so the VM continues - that's okay. So I'm okay with the fix in that regard. In general I think AttachListener::init should return a boolean to indicate success or failure so that the caller can decide what needs to be done eg at VM startup it seems reasonable to call vm_exit_during_initialization because we can't pre-start the listener as we are required to do. Though as Staffan pointed out init() incorrectly calls vm_exit_during_initialization in other places. :( >> What are the consequences of doing this? > > If AttachListener::init() cannot work due to exception, it cannot create > UNIX domain socket to accept from java tools (e.g. jstack) . > Target VM which tried to invoke AttachListner continues to run. > (However, runtime exception such as OOME occurs, target VM will be > stopped immediately :-) > > On the other hand, java tools which tried to attach target VM will fail > because it cannot connect UNIX domain socket. Will the tool fail differently now compared to the VM aborting? Purely from a testing perspective we tend to notice VM aborts but the console print about the exception may well go unnoticed. Thanks, David > > Please run my testcase. It's actual behavior. > > > Thanks, > > Yasumasa > > > On 2013/10/01 22:15, David Holmes wrote: >> On 23/09/2013 2:41 AM, Staffan Larsen wrote: >>> Dmitry: Thanks for the review. >>> >>> Yasumasa: Thanks for your contribution! I have pushed the changes >>> into HS25 and will push them to 7u60 as well. >> >> I've been on vacation so could not respond in time. I am concerned >> about this fix. Other than printing a message on the console it >> pretends that the init has succeeded! That seems wrong to me. What are >> the consequences of doing this? >> >> David >> ----- >> >>> /Staffan >>> >>> On 22 sep 2013, at 01:51, Dmitry Samersoff >>> wrote: >>> >>>> Yasumasa, >>>> >>>> Looks good for me. >>>> >>>> -Dmitry >>>> >>>> On 2013-09-21 14:43, Yasumasa Suenaga wrote: >>>>> Hi Staffan, >>>>> >>>>>> Can you update your patch, please? >>>>> >>>>> Of course! >>>>> I've attached new patch in this email. >>>>> >>>>> Could you check this? >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> On 2013/09/21 15:36, Staffan Larsen wrote: >>>>>> >>>>>> >>>>>>> On 20 sep 2013, at 16:49, Yasumasa Suenaga >>>>>>> wrote: >>>>>>> >>>>>>>> On 2013/09/20 23:34, Staffan Larsen wrote: >>>>>>>> >>>>>>>>> On 20 sep 2013, at 16:24, Yasumasa Suenaga >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I thought your code too. However... >>>>>>>>> >>>>>>>>> - These code is different from other code (rule?). >>>>>>>> >>>>>>>> Well, you are introducing a new macro that is also different from >>>>>>>> other code, so I'm not sure how valid that argument is. >>>>>>> >>>>>>> My macro is modified from "CATCH" in exceptions.hpp: >>>>>>> >>>>>>> #define CATCH \ >>>>>>> THREAD); if (HAS_PENDING_EXCEPTION) { \ >>>>>>> oop ex = PENDING_EXCEPTION; \ >>>>>>> CLEAR_PENDING_EXCEPTION; \ >>>>>>> ex->print(); \ >>>>>>> ShouldNotReachHere(); \ >>>>>>> } (void)(0 >>>>>>> >>>>>>> So I think that my macro is not big difference fromother code. >>>>>>> >>>>>>> >>>>>>>>> - Similar crash cases exist. e.g. 6425580 and 7142442. >>>>>>>>> These crashes are different from 6989981. However, I guess that >>>>>>>>> crashed >>>>>>>>> thread had pending exception and we need to fix with similar >>>>>>>>> patch. >>>>>>>>> >>>>>>>>> So I think that new macro is useful later. >>>>>>>> >>>>>>>> Yes, similar problems may come up in other cases as well. >>>>>>>> >>>>>>>> Generally, I don't think it's a good idea to have logging calls >>>>>>>> hidden away in general macros. What we really should do here is >>>>>>>> print some context around the stack trace as well. Something like: >>>>>>>> >>>>>>>> Initializing the attach listener failed with the following >>>>>>>> exception in AttachListener::init when initializing the thread_oop: >>>>>>>> >>>>>>>> This would be possible with the code I suggested, but very hard >>>>>>>> in a >>>>>>>> general macro. >>>>>>> >>>>>>> Agree. >>>>>>> Should we write code as following? >>>>>>> >>>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>>> tty->print_cr("Exception in VM (AttachListener::init) : "); >>>>>>> java_lang_Throwable::print(PENDING_EXCEPTION, tty); >>>>>>> CLEAR_PENDING_EXCEPTION; >>>>>>> return; >>>>>>> } >>>>>>> >>>>>>> I like this way :-) >>>>>> >>>>>> Yes, this is what I'd like to see! Can you update your patch, please? >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> /Staffan >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>>> On 2013/09/20 23:05, Staffan Larsen wrote: >>>>>>>>>> I see. CHECK_AND_CLEAR_AND_PRINT? Just kidding... :-) >>>>>>>>>> >>>>>>>>>> Maybe in this case we should not have this as a macro, but >>>>>>>>>> actually add the code after the two calls to call_special? >>>>>>>>>> Something like the code below. I personally think this is more >>>>>>>>>> readable than obscure macros that I have to go look up to >>>>>>>>>> understand what they do. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> /Staffan >>>>>>>>>> >>>>>>>>>> JavaCalls::call_special(&result, thread_oop, >>>>>>>>>> klass, >>>>>>>>>> vmSymbols::object_initializer_name(), >>>>>>>>>> >>>>>>>>>> vmSymbols::threadgroup_string_void_signature(), >>>>>>>>>> thread_group, >>>>>>>>>> string, >>>>>>>>>> THREAD); >>>>>>>>>> >>>>>>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>>>>>> java_lang_Throwable::print(PENDING_EXCEPTION, tty); >>>>>>>>>> CLEAR_PENDING_EXCEPTION; >>>>>>>>>> return; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> KlassHandle group(THREAD, SystemDictionary::ThreadGroup_klass()); >>>>>>>>>> JavaCalls::call_special(&result, >>>>>>>>>> thread_group, >>>>>>>>>> group, >>>>>>>>>> vmSymbols::add_method_name(), >>>>>>>>>> vmSymbols::thread_void_signature(), >>>>>>>>>> thread_oop, // ARG 1 >>>>>>>>>> THREAD); >>>>>>>>>> >>>>>>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>>>>>> java_lang_Throwable::print(PENDING_EXCEPTION, tty); >>>>>>>>>> CLEAR_PENDING_EXCEPTION; >>>>>>>>>> return; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 20 sep 2013, at 15:53, Yasumasa >>>>>>>>>>> Suenaga wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Staffan, >>>>>>>>>>> >>>>>>>>>>> Thank you for your sponsoring! >>>>>>>>>>> >>>>>>>>>>> "CHECK_AND_CLEAR" is already defined in exceptions.hpp: >>>>>>>>>>> ****************** >>>>>>>>>>> #define CHECK_AND_CLEAR THREAD); if >>>>>>>>>>> (HAS_PENDING_EXCEPTION) { CLEAR_PENDING_EXCEPTION; return; >>>>>>>>>>> } (void)(0 >>>>>>>>>>> ****************** >>>>>>>>>>> >>>>>>>>>>> I think that user wants why serviceability tools are failed. >>>>>>>>>>> So I defined "CHECK_AND_CLEAR" + java_lang_Throwable::print() as >>>>>>>>>>> "CATCH_AND_RETURN" . >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I agree rename this macro. >>>>>>>>>>> Do you have any idea? I don't have a good name :-) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>>> On 2013/09/20 20:10, Staffan Larsen wrote: >>>>>>>>>>>> Yasuma, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for finding and fixing this! I have re-opened the bug. >>>>>>>>>>>> Your patch looks good to me, but perhaps CATCH_AND_RETURN >>>>>>>>>>>> should >>>>>>>>>>>> be renamed CHECK_AND_CLEAR? >>>>>>>>>>>> >>>>>>>>>>>> I can sponsor the fix. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> /Staffan >>>>>>>>>>>> >>>>>>>>>>>>> On 20 sep 2013, at 12:41, Yasumasa >>>>>>>>>>>>> Suenaga wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I encountered this bug: >>>>>>>>>>>>> JDK-6989981: jstack causes "fatal error: ExceptionMark >>>>>>>>>>>>> destructor expects no pending exceptions" >>>>>>>>>>>>> >>>>>>>>>>>>> I read hs_err and attachListener.cpp, Java heap usage is very >>>>>>>>>>>>> high and >>>>>>>>>>>>> it could be OutOfMemoryError in AttachListener::init() . >>>>>>>>>>>>> >>>>>>>>>>>>> If JavaCalls::call_special() in AttachListener::init() fail >>>>>>>>>>>>> which is >>>>>>>>>>>>> caused by OOME, d'tor of EXCEPTION_MARK (~ExceptionMark) will >>>>>>>>>>>>> generate >>>>>>>>>>>>> internal error. >>>>>>>>>>>>> >>>>>>>>>>>>> So I make a patch for avoiding crash and attached in this >>>>>>>>>>>>> email >>>>>>>>>>>>> (6989981.patch) . >>>>>>>>>>>>> I'd like to re-open this bug and contribute my patch. >>>>>>>>>>>>> Could you help me? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --- DETAILS --- >>>>>>>>>>>>> CHECK macro is used in JavaCalls::call_special() . >>>>>>>>>>>>> >>>>>>>>>>>>> ****************** >>>>>>>>>>>>> void AttachListener::init() { >>>>>>>>>>>>> EXCEPTION_MARK; >>>>>>>>>>>>> >>>>>>>>>>>>> : >>>>>>>>>>>>> >>>>>>>>>>>>> // Initialize thread_oop to put it into the system threadGroup >>>>>>>>>>>>> Handle thread_group (THREAD, Universe::system_thread_group()); >>>>>>>>>>>>> JavaValue result(T_VOID); >>>>>>>>>>>>> JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>>> klass, >>>>>>>>>>>>> vmSymbols::object_initializer_name(), >>>>>>>>>>>>> >>>>>>>>>>>>> vmSymbols::threadgroup_string_void_signature(), >>>>>>>>>>>>> thread_group, >>>>>>>>>>>>> string, >>>>>>>>>>>>> CHECK); >>>>>>>>>>>>> >>>>>>>>>>>>> KlassHandle group(THREAD, >>>>>>>>>>>>> SystemDictionary::ThreadGroup_klass()); >>>>>>>>>>>>> JavaCalls::call_special(&result, >>>>>>>>>>>>> thread_group, >>>>>>>>>>>>> group, >>>>>>>>>>>>> vmSymbols::add_method_name(), >>>>>>>>>>>>> vmSymbols::thread_void_signature(), >>>>>>>>>>>>> thread_oop, // ARG 1 >>>>>>>>>>>>> CHECK); >>>>>>>>>>>>> ****************** >>>>>>>>>>>>> >>>>>>>>>>>>> CHECK macro does not clear pending exception of current >>>>>>>>>>>>> thread. >>>>>>>>>>>>> So call_special() fails with runtime exception, d'tor of >>>>>>>>>>>>> ExceptionMark >>>>>>>>>>>>> generates fatal error. >>>>>>>>>>>>> >>>>>>>>>>>>> ****************** >>>>>>>>>>>>> ExceptionMark::~ExceptionMark() { >>>>>>>>>>>>> if (_thread->has_pending_exception()) { >>>>>>>>>>>>> Handle exception(_thread, _thread->pending_exception()); >>>>>>>>>>>>> _thread->clear_pending_exception(); // Needed to avoid >>>>>>>>>>>>> infinite recursion >>>>>>>>>>>>> if (is_init_completed()) { >>>>>>>>>>>>> exception->print(); >>>>>>>>>>>>> fatal("ExceptionMark destructor expects no pending >>>>>>>>>>>>> exceptions"); >>>>>>>>>>>>> } else { >>>>>>>>>>>>> vm_exit_during_initialization(exception); >>>>>>>>>>>>> } >>>>>>>>>>>>> } >>>>>>>>>>>>> } >>>>>>>>>>>>> ****************** >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --- HOW TO REPRODUCE --- >>>>>>>>>>>>> I also crate testcase of this issue (testcase.tar.gz) . This >>>>>>>>>>>>> testcase contains >>>>>>>>>>>>> two modules. >>>>>>>>>>>>> >>>>>>>>>>>>> - jvmti: JVMTI agent for this issue. This agent traps >>>>>>>>>>>>> SIGQUIT and >>>>>>>>>>>>> calls original (in HotSpot) SIGQUIT handler. >>>>>>>>>>>>> This signal handler is invoked, MethodEntry event >>>>>>>>>>>>> callback is >>>>>>>>>>>>> enabled. MethodEntry generates OutOfMemoryError. >>>>>>>>>>>>> >>>>>>>>>>>>> - java : Simple long sleep program. >>>>>>>>>>>>> >>>>>>>>>>>>> I can run this testcase in Fedora18 x86_64. See below. >>>>>>>>>>>>> >>>>>>>>>>>>> ------- >>>>>>>>>>>>> $ javac java/LongSleep.java >>>>>>>>>>>>> $ make -C jvmti >>>>>>>>>>>>> make: Entering directory >>>>>>>>>>>>> `/data/share/patch/ExceptionMark/testcase/jvmti' >>>>>>>>>>>>> gcc -I/usr/lib/jvm/java-openjdk/include >>>>>>>>>>>>> -I/usr/lib/jvm/java-openjdk/include/linux -fPIC -c oome.c >>>>>>>>>>>>> gcc -shared -o liboome.so oome.o >>>>>>>>>>>>> make: Leaving directory >>>>>>>>>>>>> `/data/share/patch/ExceptionMark/testcase/jvmti' >>>>>>>>>>>>> $ export JAVA_HOME= >>>>>>>>>>>>> $ ./test.sh >>>>>>>>>>>>> ------- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> <6989981.patch> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the >>>> source code. >>> >> > From david.holmes at oracle.com Thu Oct 3 19:10:37 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 04 Oct 2013 12:10:37 +1000 Subject: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <524C3CA7.5070705@oracle.com> References: <523D144E.4000002@oracle.com> <524B8A78.9040807@oracle.com> <524C3CA7.5070705@oracle.com> Message-ID: <524E239D.4080503@oracle.com> On 3/10/2013 1:32 AM, Daniel D. Daugherty wrote: > David, > > Thanks for the thorough review (as always)! > > It will take me a while to process all the comments, but another > reply will be forthcoming. Don't bother with the minimal VM build attempt, you won't even get started. The files don't exist for BSD. David > Dan > > > On 10/1/13 8:52 PM, David Holmes wrote: >> Hi Dan, >> >> Overall thumbs up. A couple of minor issues that need fixing. A few >> meta-comments (I hate seeing all this stuff duplicated again and again. >> >> David >> ----- >> >> - common/autoconf/hotspot-spec.gmk.in >> >> Seems a good simplification. >> >> ---- >> >> - common/autoconf/jdk-options.m4 >> >> No comment. >> >> --- >> >> - common/makefiles/NativeCompilation.gmk >> >> So JDK .diz support is phase 2? :) >> >> The Windows changes here seem okay given that on windows a .debuginfo >> file should never be in the target list. >> >> --- >> >> - hotspot/make/Makefile >> >> + $(EXPORT_CLIENT_DIR)/%.dSYM: $(MINIMAL1_BUILD_DIR)/%.dSYM >> >> EXPORT_CLIENT_DIR should be EXPORT_MINIMAL_DIR. >> >> For fun you can try building minimal on OSX, but I don't know how far >> you will get: >> >> --with-jvm-variants=client,server,minimal1 >> >> I'll point out obvious issues with minimal VM support anyway. >> >> --- >> >> - hotspot/make/bsd/Makefile >> >> No comment. >> >> - hotspot/make/bsd/makefiles/buildtree.make >> >> No comment. >> >> - make/bsd/makefiles/defs.make >> >> Note that the whole jdk6_or_earlier logic is defunct as this will >> never be used for jdk6 or earlier. But best to clean all that up at >> the one time. >> >> Sadly I never found a satisfactory solution to the multiplicity and >> verbosity of the FDS messages, so OSX builds will now be afflicted by >> them too. >> >> 328 else >> 329 EXPORT_LIST += $(EXPORT_MINIMAL_DIR)/libjvm.debuginfo >> 330 endif >> >> This pre-existing minimal VM code needs to be modified to reference >> the dSYM directory on OSX as per the client/server cases. >> >> --- >> >> - hotspot/make/bsd/makefiles/dtrace.make >> >> Note related to your changes but I don't think any of the "64" >> directory stuff has any meaning outside of Solaris. >> >> 102 dsymutil $@ >> >> I think dsymutil should be assigned to a variable in the platform >> defs.make as with other tools. >> >> Would be nice if objcopy/dsymutil could be hidden behind a single >> SYM_TOOL variables as well so there wasn't so much duplication of the >> process. You could have a single set of instructions to invoke >> SYM_TOOL, STRIP and ZIP (strip would be skipped of course because >> STRIP_POLICY would never be set on osx). Just wishful thinking ... >> >> --- >> >> - hotspot/make/bsd/makefiles/gcc.make >> >> + FASTDEBUG_CFLAGS += $(DEBUG_CFLAGS/$(BUILDARCH)) >> >> should be >> >> + FASTDEBUG_CFLAGS += $(FASTDEBUG_CFLAGS/$(BUILDARCH)) >> >> Don't we need the USE_CLANG variations here as for linux? >> >> --- >> >> - hotspot/make/bsd/makefiles/jsig.make >> - hotspot/make/bsd/makefiles/saproc.make >> >> Similar comments to dtrace.make >> >> --- >> >> - make/bsd/makefiles/universal.gmk >> >> I did not understand the additional logic here: >> >> 63 # Copy built non-universal binaries in place >> 64 $(UNIVERSAL_COPY_LIST): >> 65 BUILT_COPY_FILES="`find >> $(EXPORT_JRE_LIB_DIR)/{i386,amd64}/$(subst $(EXPORT_JRE_LIB_DIR)/,,$@) >> 2>/dev/null`"; \ >> 66 if [ -n "$${BUILT_COPY_FILES}" ]; then \ >> 67 for i in $${BUILT_COPY_FILES}; do \ >> 68 if [ -f $${i} ]; then \ >> 69 $(MKDIR) -p $(shell dirname $@); \ >> 70 $(CP) -R $${i} $@; \ >> 71 fi; \ >> 72 if [ -d $${i} ]; then \ >> 73 $(MKDIR) -p $@; \ >> 74 fi; \ >> 75 done; \ >> 76 fi >> >> until I realized that foo.dSYM is a directory not a file! Even so >> don't you want to copy the contents of the directory across ? >> >> BTW: UNIVERSAL_COPY_LIST doesn't handle minimal VM. >> >> --- >> >> - make/bsd/makefiles/vm.make >> >> Similar comments to dtrace.make ref dsymutil. >> >> --- >> >> - hotspot/make/defs.make >> >> No comment. >> >> --- >> >> - jdk/make/common/Defs-macosx.gmk >> >> No comment >> >> - jdk/makefiles/Tools.gmk >> >> Not sure about this one. Logically is seems correct but up to now this >> has been defined for everything without it seeming to cause a problem. >> So why do we need to change it and what impact will it have? >> >> David >> ----- >> >> On 21/09/2013 1:36 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have the initial support for Full Debug Symbols (FDS) on MacOS X done >>> and ready for review: >>> >>> 7165611 implement Full Debug Symbols on MacOS X hotspot >>> https://bugs.openjdk.java.net/browse/JDK-7165611 >>> >>> Here is the JDK8/HSX-25 webrev URL: >>> >>> OpenJDK: >>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >>> Internal: >>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >>> >>> This webrev includes changes for the follow repos: >>> >>> jdk8 >>> jdk8/hotspot >>> jdk8/jdk >>> jdk8/jdk/make/closed >>> >>> Once these changes are approved, I'm planning to push them to >>> RT_Baseline. From there, they can follow the normal path to >>> Main_Baseline and eventually JDK8. >>> >>> This work enables FDS on MacOS X for the 'hotspot' repo; the changes in >>> the other repos are necessary to support importing the .diz files from >>> the MacOS X 'hotspot' build into the forest build. I also fixed a few >>> FDS related errors in the magic incantations for the new build. This is >>> mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported >>> from Solaris. In other words, this is Frankenstein's monster... >>> >>> Thanks to Staffan Larsen for providing an initial set of changes >>> which I morphed into what you see here. >>> >>> Testing: >>> - JPRT HSX build and test on all platforms; verification of .diz >>> files in the MacOS X JPRT bundles >>> - JPRT JDK8 forest build and test on all platforms; verification of >>> .diz files in the MacOS X JPRT bundles >>> Note: In previous FDS changesets, I also did a standalone 'jdk' >>> repo build and test, but that no longer seems to work. >>> >>> As always, comments, questions and suggestions are welcome. >>> >>> Dan > From jan.lahoda at oracle.com Thu Oct 3 23:32:03 2013 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Fri, 04 Oct 2013 06:32:03 +0000 Subject: hg: jdk8/tl/langtools: 8025118: Annotation processing api returns default modifier for interface without default methods Message-ID: <20131004063211.3E5F362D4D@hg.openjdk.java.net> Changeset: c13305cf8528 Author: jlahoda Date: 2013-10-04 08:29 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c13305cf8528 8025118: Annotation processing api returns default modifier for interface without default methods Summary: TypeElement.getModifiers() should not contain Modifier.DEFAULT Reviewed-by: darcy, jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java + test/tools/javac/processing/model/element/TestTypeElement.java From staffan.larsen at oracle.com Fri Oct 4 00:11:09 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 4 Oct 2013 09:11:09 +0200 Subject: RFR (S) 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV In-Reply-To: <524DF490.3000005@oracle.com> References: <524DB145.5030109@oracle.com> <524DD388.8060706@oracle.com> <524DF490.3000005@oracle.com> Message-ID: On 4 okt 2013, at 00:49, Coleen Phillmore wrote: > > Thanks Dan - > > On 10/3/2013 4:28 PM, Daniel D. Daugherty wrote: >> > open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk >> >> test/java/lang/instrument/RedefineMethodInBacktrace.sh >> No comments. >> >> test/java/lang/instrument/RedefineMethodInBacktraceApp.java >> line 78: t.setDaemon(true); >> Why make the target thread a daemon? Wouldn't it be a more >> complete test to do Thread.join() of that thread just to >> be sure that the target thread has finished (and is not >> stuck)? > > Staffan, can you answer this? You could do it either way. I don't have a strong opinion. It's possible that the deamonization is a leftover from one of my iterations of the test. /Staffan > > Coleen > >> >> test/java/lang/instrument/RedefineMethodInBacktraceTargetB.java >> test/java/lang/instrument/RedefineMethodInBacktraceTargetB_2.java >> Nice sync logic with the test driver. >> >> Thumbs up. >> >> Dan >> >> >> On 10/3/13 12:02 PM, Coleen Phillimore wrote: >>> Summary: Redefined class in stack trace may not be found by method_idnum so handle null. >>> >>> This is a simple change. I had another change to save the method name (as u2) in the backtrace, but it's not worth the extra footprint in backtraces for this rare case. >>> >>> The root problem was that we save method_idnum in the backtrace (u2) instead of Method* to avoid Method* from being redefined and deallocated. I made a change to InstanceKlass::method_from_idnum() to return null rather than the last method in the list, which causes this crash. Dan and I went down the long rabbit-hole of why method_idnum is changed for obsolete methods and we think there's some cleanup and potential bugs in this area. But this is not that change. I'll file another bug to continue this investigation for jdk9 (or 8uN). >>> >>> Staffan created a test - am including core-libs for the review request. Also tested with all of the vm testbase tests, mlvm tests, and java/lang/instrument tests. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8025238/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8025238 >>> >>> test case for jdk8 repository: >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8025238_jdk >>> >>> Thanks, >>> Coleen >>> >>> >> > From coleen.phillimore at oracle.com Fri Oct 4 00:51:20 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 04 Oct 2013 07:51:20 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV Message-ID: <20131004075130.9687C62D54@hg.openjdk.java.net> Changeset: 07f8c2a453f8 Author: coleenp Date: 2013-10-03 18:53 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/07f8c2a453f8 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV Summary: Redefined class in stack trace may not be found by method_idnum so handle null. Reviewed-by: sla, dcubed, sspitsyn ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp From jaroslav.bachorik at oracle.com Fri Oct 4 02:15:47 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 04 Oct 2013 11:15:47 +0200 Subject: jmx-dev RFR: 8022220 Intermittent test failures in javax/management/remote/mandatory/connection/RMIConnectionIdTest.java In-Reply-To: <524D9098.6030701@oracle.com> References: <52308389.6060001@oracle.com> <524C2976.8020109@oracle.com> <524D870D.2080804@oracle.com> <524D8D6C.9050907@oracle.com> <524D8F1E.9050904@oracle.com> <524D9098.6030701@oracle.com> Message-ID: <524E8743.3070901@oracle.com> On 3.10.2013 17:43, Chris Hegarty wrote: > On 10/03/2013 04:37 PM, Jaroslav Bachorik wrote: >> On 3.10.2013 17:29, Chris Hegarty wrote: >>> >>> >>> On 10/03/2013 04:02 PM, Jaroslav Bachorik wrote: >>>> ....... >>>> But it might hardly matter - it seems that the main culprit for this >>>> test to fail on this particular configuration was the fact that >>>> 127.0.0.1 was *NOT* detected as a loopback IP. This is pretty weird and >>> >>> I have not looked at the specifics, but if you have an InetAddress >>> instance you can invoke the isLoopbackAddress() [1][2] method to >>> correctly determine if the instance is a valid loopback address. >> >> Yes, and exactly this method seems to have failed to determine 127.0.0.1 >> being a loopback - according to the test output. >> >> I really can't see how because it basically compares the left-most byte >> of the IP to 127 ... > > Hmm... if this method fails to make the correct determination then we > have problems ;-) We use isLoopbackAddress in may other networking, and > similar, tests in the jdk. > > Sorry, I don't know what to say, there must be some other kind of issue > on your machine, or address is not truly 127.0.0.1. Well, it turns out that this issue was reported roughly 7 months after it actually appeared in the test stabilization run. When digging around for more info in the logs it became obvious that this problem has been covered by a separate issue and fixed for b84. Additionaly, there was some fiddling with /etc/hosts during the test run. So, as usual, no black magic here ... just a lot of communication noise :/ Thanks everybody for taking your time and reviewing this unnecessary change. -JB- > > -Chris. > > >> >> -JB- >> >>> >>> -Chris. >>> >>> [1] >>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/54e099776f08/src/share/classes/java/net/Inet4Address.java >>> >>> >>> >>> [2] >>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/54e099776f08/src/share/classes/java/net/Inet6Address.java >>> >>> >>> >>> >>>> makes one question the sanity of the test setup... >>>> >>>> -JB- >>>> >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2013-09-11 18:51, Jaroslav Bachorik wrote: >>>>>> Please, review this simple patch for an intermittently failing test. >>>>>> >>>>>> The test fails in cases when the connection loopback is resolved >>>>>> to be >>>>>> 127.0.1.1 - it may happen under certain circumstances in eg. Ubuntu. >>>>>> The >>>>>> test does not anticipate this possibility and requires the loopback >>>>>> address to be exactly 127.0.0.1 >>>>>> >>>>>> The test will end comparing 127.0.0.1 against 127.0.1.1 and will >>>>>> consider them non equal even though they are both the same loopback. >>>>>> The >>>>>> patch adds a bit of flexibility to the test allowing for any two >>>>>> valid >>>>>> loopback addresses (127.0.0.0/8) to be equal. >>>>>> >>>>>> Issue : JDK-8022220 >>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8022220/webrev.00 >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>>>> >>>>> >>>>> >>>> >> From peter.allwin at oracle.com Fri Oct 4 04:13:46 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Fri, 4 Oct 2013 04:13:46 -0700 (PDT) Subject: RFR: 8014446: JT_JDK: Wrong detection of test result for test com/sun/jdi/NoLaunchOptionTest.java Message-ID: Hello! Looking for reviews for this very simple fix to a JDK test, where warnings in stderr could cause the test to fail. Bug: https://bugs.openjdk.java.net/browse/JDK-8014446 CR: http://cr.openjdk.java.net/~allwin/8014446/webrev.00/ Thanks! /peter From staffan.larsen at oracle.com Fri Oct 4 04:29:18 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 4 Oct 2013 13:29:18 +0200 Subject: RFR: 8014446: JT_JDK: Wrong detection of test result for test com/sun/jdi/NoLaunchOptionTest.java In-Reply-To: References: Message-ID: Looks good! Thanks, /Staffan On 4 okt 2013, at 13:13, Peter Allwin wrote: > Hello! > > Looking for reviews for this very simple fix to a JDK test, where warnings in stderr could cause the test to fail. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8014446 > CR: http://cr.openjdk.java.net/~allwin/8014446/webrev.00/ > > > Thanks! > /peter From dmitry.samersoff at oracle.com Fri Oct 4 04:34:41 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 04 Oct 2013 15:34:41 +0400 Subject: RFR [8025886] typo in shell regtest == instead of = In-Reply-To: <524D7AF6.2000705@oracle.com> References: <524D7AF6.2000705@oracle.com> Message-ID: <524EA7D1.7030908@oracle.com> Ivan, If you need shell pattern match CYGWIN_NT* it's better to use case but not if -Dmitry On 2013-10-03 18:11, Ivan Gerasimov wrote: > Hello! > > May I please have a review for a simple fix of the shell regtest? > Bash seems to accept both = and == comparisons, but sh accepts only =. > > http://bugs.sun.com/view_bug.do?bug_id=8025886 (not yet visible.) > > Sincerely yours, > Ivan > > > --- a/test/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh > +++ b/test/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh > @@ -34,7 +34,7 @@ > OS=`uname -s` > UMASK=`umask` > > -if [[ $OS == CYGWIN_NT* ]] ; then > +if [[ $OS = CYGWIN_NT* ]] ; then > OS="Windows_NT" > if [ -z "$SystemRoot" ] ; then > SystemRoot=$SYSTEMROOT > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Fri Oct 4 04:41:56 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 04 Oct 2013 13:41:56 +0200 Subject: RFR: 8014446: JT_JDK: Wrong detection of test result for test com/sun/jdi/NoLaunchOptionTest.java In-Reply-To: References: Message-ID: <524EA984.4030509@oracle.com> Looks fine. Just a thought - wouldn't it make sense to check for the error message disregarding the case? -JB- On 4.10.2013 13:29, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > > On 4 okt 2013, at 13:13, Peter Allwin wrote: > >> Hello! >> >> Looking for reviews for this very simple fix to a JDK test, where warnings in stderr could cause the test to fail. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8014446 >> CR: http://cr.openjdk.java.net/~allwin/8014446/webrev.00/ >> >> >> Thanks! >> /peter > From markus.gronlund at oracle.com Fri Oct 4 04:49:16 2013 From: markus.gronlund at oracle.com (=?utf-8?B?TWFya3VzIEdyw7ZubHVuZA==?=) Date: Fri, 4 Oct 2013 04:49:16 -0700 (PDT) Subject: RFR: 8014446: JT_JDK: Wrong detection of test result for test com/sun/jdi/NoLaunchOptionTest.java In-Reply-To: References: Message-ID: <82727e04-9775-4d39-8127-9fe5e6e472e9@default> Looks good. /Markus -----Original Message----- From: Peter Allwin Sent: den 4 oktober 2013 13:14 To: serviceability-dev at openjdk.java.net Subject: RFR: 8014446: JT_JDK: Wrong detection of test result for test com/sun/jdi/NoLaunchOptionTest.java Hello! Looking for reviews for this very simple fix to a JDK test, where warnings in stderr could cause the test to fail. Bug: https://bugs.openjdk.java.net/browse/JDK-8014446 CR: http://cr.openjdk.java.net/~allwin/8014446/webrev.00/ Thanks! /peter From david.holmes at oracle.com Fri Oct 4 04:49:26 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 04 Oct 2013 21:49:26 +1000 Subject: RFR: 8014446: JT_JDK: Wrong detection of test result for test com/sun/jdi/NoLaunchOptionTest.java In-Reply-To: References: Message-ID: <524EAB46.40401@oracle.com> On 4/10/2013 9:13 PM, Peter Allwin wrote: > Hello! > > Looking for reviews for this very simple fix to a JDK test, where warnings in stderr could cause the test to fail. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8014446 > CR: http://cr.openjdk.java.net/~allwin/8014446/webrev.00/ Sorry I don't get it. This change will match (in theory) more lines with Error in them. But how does that help when the problem was an unexpected warning ? David > > Thanks! > /peter > From david.holmes at oracle.com Fri Oct 4 05:00:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 04 Oct 2013 22:00:32 +1000 Subject: RFR: 8014446: JT_JDK: Wrong detection of test result for test com/sun/jdi/NoLaunchOptionTest.java In-Reply-To: <524EAB46.40401@oracle.com> References: <524EAB46.40401@oracle.com> Message-ID: <524EADE0.80701@oracle.com> On 4/10/2013 9:49 PM, David Holmes wrote: > On 4/10/2013 9:13 PM, Peter Allwin wrote: >> Hello! >> >> Looking for reviews for this very simple fix to a JDK test, where >> warnings in stderr could cause the test to fail. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8014446 >> CR: http://cr.openjdk.java.net/~allwin/8014446/webrev.00/ > > Sorry I don't get it. This change will match (in theory) more lines with > Error in them. But how does that help when the problem was an unexpected > warning ? Never mind I get it. The output is a multi-line value that would normally only have the Error but when the warning is present it comes first with the Error following. David > David > >> >> Thanks! >> /peter >> From peter.allwin at oracle.com Fri Oct 4 05:12:03 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Fri, 4 Oct 2013 05:12:03 -0700 (PDT) Subject: RFR: 8025829: Add java/lang/instrument/RetransformBigClass.sh to problemlist Message-ID: Hello! This change adds java/lang/instrument/RetransformBigClass.sh and java/lang/instrument/RedefineBigClass.sh to problemlist, due to bug [0]. CR: http://cr.openjdk.java.net/~allwin/8025829/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8023201 Thanks! /peter [0] https://bugs.openjdk.java.net/browse/JDK-8023201 From chris.hegarty at oracle.com Fri Oct 4 05:13:13 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 4 Oct 2013 13:13:13 +0100 Subject: RFR: 8014446: JT_JDK: Wrong detection of test result for test com/sun/jdi/NoLaunchOptionTest.java In-Reply-To: References: Message-ID: <10C0BCFB-5E52-4059-8919-35074F4403F2@oracle.com> Look ok to me Peter. -Chris > On 4 Oct 2013, at 12:13, Peter Allwin wrote: > > Hello! > > Looking for reviews for this very simple fix to a JDK test, where warnings in stderr could cause the test to fail. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8014446 > CR: http://cr.openjdk.java.net/~allwin/8014446/webrev.00/ > > > Thanks! > /peter From staffan.larsen at oracle.com Fri Oct 4 05:40:46 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 4 Oct 2013 14:40:46 +0200 Subject: RFR: 8025829: Add java/lang/instrument/RetransformBigClass.sh to problemlist In-Reply-To: References: Message-ID: Looks good! Thanks, /Staffan On 4 okt 2013, at 14:12, Peter Allwin wrote: > Hello! > > This change adds java/lang/instrument/RetransformBigClass.sh and java/lang/instrument/RedefineBigClass.sh to problemlist, due to bug [0]. > > CR: http://cr.openjdk.java.net/~allwin/8025829/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8023201 > > > > Thanks! > /peter > > [0] https://bugs.openjdk.java.net/browse/JDK-8023201 > From jaroslav.bachorik at oracle.com Fri Oct 4 05:41:52 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 04 Oct 2013 14:41:52 +0200 Subject: RFR: 8025829: Add java/lang/instrument/RetransformBigClass.sh to problemlist In-Reply-To: References: Message-ID: <524EB790.4040702@oracle.com> Looks ok. -JB- On 4.10.2013 14:12, Peter Allwin wrote: > Hello! > > This change adds java/lang/instrument/RetransformBigClass.sh and java/lang/instrument/RedefineBigClass.sh to problemlist, due to bug [0]. > > CR: http://cr.openjdk.java.net/~allwin/8025829/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8023201 > > > > Thanks! > /peter > > [0] https://bugs.openjdk.java.net/browse/JDK-8023201 > From sundararajan.athijegannathan at oracle.com Fri Oct 4 06:05:39 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 04 Oct 2013 13:05:39 +0000 Subject: hg: jdk8/tl/nashorn: 8025771: Enhance Nashorn Contexts Message-ID: <20131004130547.E8AB662D72@hg.openjdk.java.net> Changeset: 3470bc26128f Author: sundar Date: 2013-10-04 16:21 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3470bc26128f 8025771: Enhance Nashorn Contexts Reviewed-by: jlaskey, hannesw - make/java.security.override ! make/project.properties ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! test/script/basic/JDK-8023026.js + test/script/sandbox/arrayclass.js + test/script/sandbox/arrayclass.js.EXPECTED From Alan.Bateman at oracle.com Fri Oct 4 06:17:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Oct 2013 06:17:28 -0700 Subject: RFR: 8025829: Add java/lang/instrument/RetransformBigClass.sh to problemlist In-Reply-To: References: Message-ID: <524EBFE8.1090605@oracle.com> On 04/10/2013 05:12, Peter Allwin wrote: > Hello! > > This change adds java/lang/instrument/RetransformBigClass.sh and java/lang/instrument/RedefineBigClass.sh to problemlist, due to bug [0]. > > CR: http://cr.openjdk.java.net/~allwin/8025829/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8023201 > Looks good, I see these two failing on a regular basis so excluding them (temporarily) until the underlying issue is understood and fixed is fine. -Alan. From staffan.larsen at oracle.com Fri Oct 4 06:19:00 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Fri, 04 Oct 2013 13:19:00 +0000 Subject: hg: jdk8/tl/jdk: 8025829: Add java/lang/instrument/RetransformBigClass.sh to problemlist Message-ID: <20131004131913.076C062D74@hg.openjdk.java.net> Changeset: 77ba1e67707c Author: allwin Date: 2013-10-04 15:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77ba1e67707c 8025829: Add java/lang/instrument/RetransformBigClass.sh to problemlist Reviewed-by: sla, jbachorik ! test/ProblemList.txt From vincent.x.ryan at oracle.com Fri Oct 4 08:06:58 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Fri, 04 Oct 2013 15:06:58 +0000 Subject: hg: jdk8/tl/jdk: 8008296: keytool utility doesn't support '-importpassword' command Message-ID: <20131004150846.CCBE862D79@hg.openjdk.java.net> Changeset: b5aad88cbf12 Author: vinnie Date: 2013-10-04 16:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b5aad88cbf12 8008296: keytool utility doesn't support '-importpassword' command Reviewed-by: weijun ! src/share/classes/sun/security/tools/keytool/Main.java ! src/share/classes/sun/security/tools/keytool/Resources.java + test/sun/security/tools/keytool/StorePasswords.java + test/sun/security/tools/keytool/StorePasswordsByShell.sh From alexander.zuev at oracle.com Fri Oct 4 08:39:23 2013 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Fri, 04 Oct 2013 15:39:23 +0000 Subject: hg: jdk8/tl/langtools: 7096170: should remove unused support for enabling javac logging Message-ID: <20131004153931.CB4C862D7A@hg.openjdk.java.net> Changeset: c0d44b1e6b6a Author: kizune Date: 2013-10-04 19:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c0d44b1e6b6a 7096170: should remove unused support for enabling javac logging Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java From roger.riggs at oracle.com Fri Oct 4 09:53:10 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Fri, 04 Oct 2013 16:53:10 +0000 Subject: hg: jdk8/tl/jdk: 7 new changesets Message-ID: <20131004165456.3C0CA62D87@hg.openjdk.java.net> Changeset: 1de0fac9b962 Author: rriggs Date: 2013-08-29 20:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1de0fac9b962 8023764: Optimize Period addition Summary: Optimise plus/minus for common cases Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/ZonedDateTime.java Changeset: 356df1b99976 Author: rriggs Date: 2013-08-30 11:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/356df1b99976 8023763: Rename ChronoDateImpl Summary: Rename ChronoDateImpl to ChronoLocalDateImpl Reviewed-by: sherman Contributed-by: scolebourne at joda.org - src/share/classes/java/time/chrono/ChronoDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java + src/share/classes/java/time/chrono/ChronoLocalDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java Changeset: 5d73f7a2db51 Author: rriggs Date: 2013-09-04 15:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d73f7a2db51 8023762: Add ChronoPeriod interface and bind period to Chronology Summary: Make Period ISO-only, adding a Chronology-specific period concept Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java + src/share/classes/java/time/chrono/ChronoPeriod.java + src/share/classes/java/time/chrono/ChronoPeriodImpl.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/Ser.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! src/share/classes/java/time/temporal/Temporal.java ! test/java/time/tck/java/time/TCKPeriod.java + test/java/time/tck/java/time/chrono/TCKChronoPeriod.java ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java ! test/java/time/tck/java/time/chrono/TCKMinguoChronology.java ! test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java ! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java Changeset: 79077f1641cc Author: rriggs Date: 2013-09-14 22:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79077f1641cc 8024835: Change until() to accept any compatible temporal Summary: Method until(Temporal,TemporalUnit) now uses from() to convert; Enhance from() methods where necessary Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/java/time/temporal/ChronoUnit.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/Temporal.java ! src/share/classes/java/time/temporal/TemporalUnit.java ! test/java/time/tck/java/time/TCKDuration.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKOffsetDateTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZonedDateTime.java ! test/java/time/tck/java/time/chrono/CopticDate.java ! test/java/time/tck/java/time/temporal/TCKIsoFields.java Changeset: 14a187dc4ffe Author: rriggs Date: 2013-10-04 12:01 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/14a187dc4ffe 8024999: Instant.Parse typo in example Summary: javadoc only fix to correct example to use "." and "Z" Reviewed-by: sherman ! src/share/classes/java/time/Instant.java Changeset: f9c701ba04e7 Author: rriggs Date: 2013-09-14 22:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f9c701ba04e7 8024807: Add getChronlogy() to CLDT/CZDT Summary: Alternative to method is clunky and hard to find Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java Changeset: e12b912ab98e Author: rriggs Date: 2013-09-14 22:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e12b912ab98e 8024834: Better return type for TemporalField resolve Summary: Allow resolve method to return more than just ChronoLocalDate Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/format/Parsed.java ! src/share/classes/java/time/temporal/TemporalField.java ! test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java From robert.field at oracle.com Fri Oct 4 09:55:18 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Fri, 04 Oct 2013 16:55:18 +0000 Subject: hg: jdk8/tl/jdk: 8021186: jdk/lambda/vm/DefaultMethodsTest.java fails Message-ID: <20131004165529.DFDB862D88@hg.openjdk.java.net> Changeset: 7736abdf0805 Author: rfield Date: 2013-10-04 09:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7736abdf0805 8021186: jdk/lambda/vm/DefaultMethodsTest.java fails Summary: remove DefaultMethodsTest from jdk/test/problemList.txt Reviewed-by: mduigou ! test/ProblemList.txt From joe.darcy at oracle.com Fri Oct 4 10:00:53 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 04 Oct 2013 17:00:53 +0000 Subject: hg: jdk8/tl/langtools: 8025913: Rename jdk.Supported to jdk.Exported Message-ID: <20131004170100.617D762D89@hg.openjdk.java.net> Changeset: 379c04c090cf Author: darcy Date: 2013-10-04 10:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/379c04c090cf 8025913: Rename jdk.Supported to jdk.Exported Reviewed-by: psandoz, forax, lancea, alanb, mchung, jjg ! src/share/classes/com/sun/source/doctree/AttributeTree.java ! src/share/classes/com/sun/source/doctree/AuthorTree.java ! src/share/classes/com/sun/source/doctree/BlockTagTree.java ! src/share/classes/com/sun/source/doctree/CommentTree.java ! src/share/classes/com/sun/source/doctree/DeprecatedTree.java ! src/share/classes/com/sun/source/doctree/DocCommentTree.java ! src/share/classes/com/sun/source/doctree/DocRootTree.java ! src/share/classes/com/sun/source/doctree/DocTree.java ! src/share/classes/com/sun/source/doctree/DocTreeVisitor.java ! src/share/classes/com/sun/source/doctree/EndElementTree.java ! src/share/classes/com/sun/source/doctree/EntityTree.java ! src/share/classes/com/sun/source/doctree/ErroneousTree.java ! src/share/classes/com/sun/source/doctree/IdentifierTree.java ! src/share/classes/com/sun/source/doctree/InheritDocTree.java ! src/share/classes/com/sun/source/doctree/InlineTagTree.java ! src/share/classes/com/sun/source/doctree/LinkTree.java ! src/share/classes/com/sun/source/doctree/LiteralTree.java ! src/share/classes/com/sun/source/doctree/ParamTree.java ! src/share/classes/com/sun/source/doctree/ReferenceTree.java ! src/share/classes/com/sun/source/doctree/ReturnTree.java ! src/share/classes/com/sun/source/doctree/SeeTree.java ! src/share/classes/com/sun/source/doctree/SerialDataTree.java ! src/share/classes/com/sun/source/doctree/SerialFieldTree.java ! src/share/classes/com/sun/source/doctree/SerialTree.java ! src/share/classes/com/sun/source/doctree/SinceTree.java ! src/share/classes/com/sun/source/doctree/StartElementTree.java ! src/share/classes/com/sun/source/doctree/TextTree.java ! src/share/classes/com/sun/source/doctree/ThrowsTree.java ! src/share/classes/com/sun/source/doctree/UnknownBlockTagTree.java ! src/share/classes/com/sun/source/doctree/UnknownInlineTagTree.java ! src/share/classes/com/sun/source/doctree/ValueTree.java ! src/share/classes/com/sun/source/doctree/VersionTree.java ! src/share/classes/com/sun/source/doctree/package-info.java ! src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java ! src/share/classes/com/sun/source/tree/AnnotationTree.java ! src/share/classes/com/sun/source/tree/ArrayAccessTree.java ! src/share/classes/com/sun/source/tree/ArrayTypeTree.java ! src/share/classes/com/sun/source/tree/AssertTree.java ! src/share/classes/com/sun/source/tree/AssignmentTree.java ! src/share/classes/com/sun/source/tree/BinaryTree.java ! src/share/classes/com/sun/source/tree/BlockTree.java ! src/share/classes/com/sun/source/tree/BreakTree.java ! src/share/classes/com/sun/source/tree/CaseTree.java ! src/share/classes/com/sun/source/tree/CatchTree.java ! src/share/classes/com/sun/source/tree/ClassTree.java ! src/share/classes/com/sun/source/tree/CompilationUnitTree.java ! src/share/classes/com/sun/source/tree/CompoundAssignmentTree.java ! src/share/classes/com/sun/source/tree/ConditionalExpressionTree.java ! src/share/classes/com/sun/source/tree/ContinueTree.java ! src/share/classes/com/sun/source/tree/DoWhileLoopTree.java ! src/share/classes/com/sun/source/tree/EmptyStatementTree.java ! src/share/classes/com/sun/source/tree/EnhancedForLoopTree.java ! src/share/classes/com/sun/source/tree/ErroneousTree.java ! src/share/classes/com/sun/source/tree/ExpressionStatementTree.java ! src/share/classes/com/sun/source/tree/ExpressionTree.java ! src/share/classes/com/sun/source/tree/ForLoopTree.java ! src/share/classes/com/sun/source/tree/IdentifierTree.java ! src/share/classes/com/sun/source/tree/IfTree.java ! src/share/classes/com/sun/source/tree/ImportTree.java ! src/share/classes/com/sun/source/tree/InstanceOfTree.java ! src/share/classes/com/sun/source/tree/IntersectionTypeTree.java ! src/share/classes/com/sun/source/tree/LabeledStatementTree.java ! src/share/classes/com/sun/source/tree/LambdaExpressionTree.java ! src/share/classes/com/sun/source/tree/LineMap.java ! src/share/classes/com/sun/source/tree/LiteralTree.java ! src/share/classes/com/sun/source/tree/MemberReferenceTree.java ! src/share/classes/com/sun/source/tree/MemberSelectTree.java ! src/share/classes/com/sun/source/tree/MethodInvocationTree.java ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/ModifiersTree.java ! src/share/classes/com/sun/source/tree/NewArrayTree.java ! src/share/classes/com/sun/source/tree/NewClassTree.java ! src/share/classes/com/sun/source/tree/ParameterizedTypeTree.java ! src/share/classes/com/sun/source/tree/ParenthesizedTree.java ! src/share/classes/com/sun/source/tree/PrimitiveTypeTree.java ! src/share/classes/com/sun/source/tree/ReturnTree.java ! src/share/classes/com/sun/source/tree/Scope.java ! src/share/classes/com/sun/source/tree/StatementTree.java ! src/share/classes/com/sun/source/tree/SwitchTree.java ! src/share/classes/com/sun/source/tree/SynchronizedTree.java ! src/share/classes/com/sun/source/tree/ThrowTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/tree/TryTree.java ! src/share/classes/com/sun/source/tree/TypeCastTree.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/source/tree/UnaryTree.java ! src/share/classes/com/sun/source/tree/UnionTypeTree.java ! src/share/classes/com/sun/source/tree/VariableTree.java ! src/share/classes/com/sun/source/tree/WhileLoopTree.java ! src/share/classes/com/sun/source/tree/WildcardTree.java ! src/share/classes/com/sun/source/tree/package-info.java ! src/share/classes/com/sun/source/util/DocSourcePositions.java ! src/share/classes/com/sun/source/util/DocTreePath.java ! src/share/classes/com/sun/source/util/DocTreePathScanner.java ! src/share/classes/com/sun/source/util/DocTreeScanner.java ! src/share/classes/com/sun/source/util/DocTrees.java ! src/share/classes/com/sun/source/util/JavacTask.java ! src/share/classes/com/sun/source/util/Plugin.java ! src/share/classes/com/sun/source/util/SimpleDocTreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/SourcePositions.java ! src/share/classes/com/sun/source/util/TaskEvent.java ! src/share/classes/com/sun/source/util/TaskListener.java ! src/share/classes/com/sun/source/util/TreePath.java ! src/share/classes/com/sun/source/util/TreePathScanner.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/source/util/package-info.java ! src/share/classes/com/sun/tools/javac/Main.java + src/share/classes/jdk/Exported.java - src/share/classes/jdk/Supported.java From daniel.fuchs at oracle.com Fri Oct 4 11:41:28 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Fri, 04 Oct 2013 18:41:28 +0000 Subject: hg: jdk8/tl/jaxp: 8025745: Clarify API documentation of JAXP factories. Message-ID: <20131004184134.9F52C62D8E@hg.openjdk.java.net> Changeset: f031b2fe21cd Author: dfuchs Date: 2013-10-04 19:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f031b2fe21cd 8025745: Clarify API documentation of JAXP factories. Summary: Clarifies usage of ServiceLoader in JAXP factories. Reviewed-by: alanb, joehw, psandoz ! src/javax/xml/datatype/DatatypeFactory.java ! src/javax/xml/parsers/DocumentBuilderFactory.java ! src/javax/xml/parsers/SAXParserFactory.java ! src/javax/xml/stream/XMLEventFactory.java ! src/javax/xml/stream/XMLInputFactory.java ! src/javax/xml/stream/XMLOutputFactory.java ! src/javax/xml/transform/TransformerFactory.java ! src/javax/xml/validation/SchemaFactory.java ! src/javax/xml/xpath/XPathFactory.java From bhavesh.x.patel at oracle.com Fri Oct 4 13:32:59 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Fri, 04 Oct 2013 20:32:59 +0000 Subject: hg: jdk8/tl/langtools: 8008164: Invisible table captions in javadoc-generated html Message-ID: <20131004203309.BA4EA62D95@hg.openjdk.java.net> Changeset: 6e186ca11ec0 Author: bpatel Date: 2013-10-04 13:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6e186ca11ec0 8008164: Invisible table captions in javadoc-generated html Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css + test/com/sun/javadoc/testHtmlTableStyles/TestHtmlTableStyles.java + test/com/sun/javadoc/testHtmlTableStyles/pkg1/TestTable.java + test/com/sun/javadoc/testHtmlTableStyles/pkg2/TestUse.java ! test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java ! test/com/sun/javadoc/testProfiles/TestProfiles.java ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java From bhavesh.x.patel at oracle.com Fri Oct 4 13:41:46 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Fri, 04 Oct 2013 20:41:46 +0000 Subject: hg: jdk8/tl/langtools: 8024756: method grouping tabs are not selectable Message-ID: <20131004204149.F270A62D96@hg.openjdk.java.net> Changeset: 3344ea7404b1 Author: bpatel Date: 2013-10-04 13:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3344ea7404b1 8024756: method grouping tabs are not selectable Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! test/com/sun/javadoc/JavascriptWinTitle/JavascriptWinTitle.java ! test/com/sun/javadoc/testJavascript/TestJavascript.java From jonathan.gibbons at oracle.com Fri Oct 4 14:00:16 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 04 Oct 2013 21:00:16 +0000 Subject: hg: jdk8/tl/langtools: 8022163: javac exits with 0 status and no messages on error to construct an ann-procesor Message-ID: <20131004210020.038FF62D97@hg.openjdk.java.net> Changeset: 2fa6ced325cc Author: jjg Date: 2013-10-04 13:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2fa6ced325cc 8022163: javac exits with 0 status and no messages on error to construct an ann-procesor Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/processing/errors/TestBadProcessor.java From jonathan.gibbons at oracle.com Fri Oct 4 14:47:36 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 04 Oct 2013 21:47:36 +0000 Subject: hg: jdk8/tl/langtools: 6525408: DiagnosticListener should receive MANDATORY_WARNING in standard compiler mode Message-ID: <20131004214739.29BA162D99@hg.openjdk.java.net> Changeset: 515d54c1b063 Author: jjg Date: 2013-10-04 14:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/515d54c1b063 6525408: DiagnosticListener should receive MANDATORY_WARNING in standard compiler mode Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/javax/tools/Diagnostic.java From jonathan.gibbons at oracle.com Fri Oct 4 15:25:52 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 04 Oct 2013 22:25:52 +0000 Subject: hg: jdk8/tl/langtools: 8025970: Spurious characters in JavaCompiler Message-ID: <20131004222556.7299862D9B@hg.openjdk.java.net> Changeset: 3e3c321710be Author: jjg Date: 2013-10-04 15:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3e3c321710be 8025970: Spurious characters in JavaCompiler Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java From bhavesh.x.patel at oracle.com Fri Oct 4 15:37:32 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Fri, 04 Oct 2013 22:37:32 +0000 Subject: hg: jdk8/tl: 8025741: Fix jdk/make/docs/Makefile to point to correct docs URL for JDK 8. Message-ID: <20131004223732.E1E0562D9C@hg.openjdk.java.net> Changeset: 6b8f5030e5ad Author: bpatel Date: 2013-10-04 15:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6b8f5030e5ad 8025741: Fix jdk/make/docs/Makefile to point to correct docs URL for JDK 8. Reviewed-by: tbell ! common/makefiles/javadoc/Javadoc.gmk From bhavesh.x.patel at oracle.com Fri Oct 4 15:38:54 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Fri, 04 Oct 2013 22:38:54 +0000 Subject: hg: jdk8/tl/jdk: 8025741: Fix jdk/make/docs/Makefile to point to correct docs URL for JDK 8. Message-ID: <20131004223906.38C9362D9D@hg.openjdk.java.net> Changeset: 66181f7991bd Author: bpatel Date: 2013-10-04 15:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/66181f7991bd 8025741: Fix jdk/make/docs/Makefile to point to correct docs URL for JDK 8. Reviewed-by: tbell ! make/docs/Makefile From kumar.x.srinivasan at oracle.com Fri Oct 4 16:16:11 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 04 Oct 2013 23:16:11 +0000 Subject: hg: jdk8/tl/langtools: 8003537: javap use internal class name when printing bound of type variable Message-ID: <20131004231614.DD5DE62D9E@hg.openjdk.java.net> Changeset: bb87db832b31 Author: ksrini Date: 2013-10-04 16:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bb87db832b31 8003537: javap use internal class name when printing bound of type variable Reviewed-by: jjg ! src/share/classes/com/sun/tools/javap/ClassWriter.java + test/tools/javap/BoundsTypeVariableTest.java From kumar.x.srinivasan at oracle.com Fri Oct 4 16:45:49 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 04 Oct 2013 23:45:49 +0000 Subject: hg: jdk8/tl/langtools: 8005542: jtreg test OverrideBridge.java contains @ignore Message-ID: <20131004234552.5B5A562DA0@hg.openjdk.java.net> Changeset: 15651a673358 Author: ksrini Date: 2013-10-04 16:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/15651a673358 8005542: jtreg test OverrideBridge.java contains @ignore Reviewed-by: jjg Contributed-by: steve.sides at oracle.com - test/tools/javac/generics/OverrideBridge.java From yasu at ysfactory.dip.jp Fri Oct 4 17:32:05 2013 From: yasu at ysfactory.dip.jp (Yasumasa Suenaga) Date: Sat, 05 Oct 2013 09:32:05 +0900 Subject: JDK-6989981: jstack causes "fatal error: ExceptionMark destructor expects no pending exceptions" In-Reply-To: <524E0864.4020505@oracle.com> References: <523C264E.7060704@ysfactory.dip.jp> <97D9FB54-FFF1-4337-942A-E7FE2196A354@oracle.com> <523C534C.7060908@ysfactory.dip.jp> <9367FE2B-C709-4273-BEAE-745841846560@oracle.com> <523C5A8A.8060000@ysfactory.dip.jp> <523C606B.5060204@ysfactory.dip.jp> <952F096A-69D2-4E7C-B979-91E95AFE37F8@oracle.com> <523D786C.5090605@ysfactory.dip.jp> <523EAF7C.3050000@oracle.com> <3FE7CB8E-39F4-4915-B82E-AC2F88715189@oracle.com> <524ACADB.3060600@oracle.com> <524AD80F.2020308@ysfactory.dip.jp> <524E0864.4020505@oracle.com> Message-ID: <524F5E05.2000501@ysfactory.dip.jp> Hi David, > Will the tool fail differently now compared to the VM aborting? With or without a patch, we will get same result from serviceability tools. In tools side, they cannot connect to UNIX domain socket. So we wiil get messages in TTY of tools as following: ----------- 1418: Unable to open socket file: target process not responding or HotSpot VM not loaded The -F option can be used when the target process is not responding ----------- Thanks, Yasumasa On 2013/10/04 9:14, David Holmes wrote: > On 2/10/2013 12:11 AM, Yasumasa Suenaga wrote: >> Hi David, >> >>> Other than printing a message on the console it pretends that the init >>> has succeeded! >> >> No. >> >> signal_thread_entry() @ hotspot/src/share/vm/runtime/os.cpp >> -------- >> 250 case SIGBREAK: { >> 251 // Check if the signal is a trigger to start the >> Attach Listener - in that >> 252 // case don't print stack traces. >> 253 if (!DisableAttachMechanism && >> AttachListener::is_init_trigger()) { >> 254 continue; >> 255 } >> -------- >> >> AttachListener::init() is called through is_init_trigger() (line 505). >> >> AttachListener::is_init_trigger() @ >> hotspot/src/share/vm/services/attachListener.cpp >> -------- >> 501 if (ret == 0) { >> 502 // simple check to avoid starting the attach mechanism when >> 503 // a bogus user creates the file >> 504 if (st.st_uid == geteuid()) { >> 505 init(); >> 506 return true; >> 507 } >> 508 } >> -------- >> >> If exception occurs in AttachListner::init(), >> AttachListner::is_init_trigger() returns "true" . >> Process of SIGBREAK handler will be stopped (caused by continue >> statement) and signal_thread_entry() >> will return top of loop. >> >> In my patch, pending exception which occurs in AttachListener >> initialization is cleared. >> Thus Signal Dispatcher has no damage. > > But as I said the init() fails and we pretend it succeeded with respect to the caller. Now for the signal case if the init fails we can simply do nothing - the VM is running, this particular action failed, so the VM continues - that's okay. So I'm okay with the fix in that regard. > > In general I think AttachListener::init should return a boolean to indicate success or failure so that the caller can decide what needs to be done eg at VM startup it seems reasonable to call vm_exit_during_initialization because we can't pre-start the listener as we are required to do. > > Though as Staffan pointed out init() incorrectly calls vm_exit_during_initialization in other places. :( > >>> What are the consequences of doing this? >> >> If AttachListener::init() cannot work due to exception, it cannot create >> UNIX domain socket to accept from java tools (e.g. jstack) . >> Target VM which tried to invoke AttachListner continues to run. >> (However, runtime exception such as OOME occurs, target VM will be >> stopped immediately :-) >> >> On the other hand, java tools which tried to attach target VM will fail >> because it cannot connect UNIX domain socket. > > Will the tool fail differently now compared to the VM aborting? Purely from a testing perspective we tend to notice VM aborts but the console print about the exception may well go unnoticed. > > Thanks, > David > >> >> Please run my testcase. It's actual behavior. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2013/10/01 22:15, David Holmes wrote: >>> On 23/09/2013 2:41 AM, Staffan Larsen wrote: >>>> Dmitry: Thanks for the review. >>>> >>>> Yasumasa: Thanks for your contribution! I have pushed the changes >>>> into HS25 and will push them to 7u60 as well. >>> >>> I've been on vacation so could not respond in time. I am concerned >>> about this fix. Other than printing a message on the console it >>> pretends that the init has succeeded! That seems wrong to me. What are >>> the consequences of doing this? >>> >>> David >>> ----- >>> >>>> /Staffan >>>> >>>> On 22 sep 2013, at 01:51, Dmitry Samersoff >>>> wrote: >>>> >>>>> Yasumasa, >>>>> >>>>> Looks good for me. >>>>> >>>>> -Dmitry >>>>> >>>>> On 2013-09-21 14:43, Yasumasa Suenaga wrote: >>>>>> Hi Staffan, >>>>>> >>>>>>> Can you update your patch, please? >>>>>> >>>>>> Of course! >>>>>> I've attached new patch in this email. >>>>>> >>>>>> Could you check this? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> On 2013/09/21 15:36, Staffan Larsen wrote: >>>>>>> >>>>>>> >>>>>>>> On 20 sep 2013, at 16:49, Yasumasa Suenaga >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 2013/09/20 23:34, Staffan Larsen wrote: >>>>>>>>> >>>>>>>>>> On 20 sep 2013, at 16:24, Yasumasa Suenaga >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> I thought your code too. However... >>>>>>>>>> >>>>>>>>>> - These code is different from other code (rule?). >>>>>>>>> >>>>>>>>> Well, you are introducing a new macro that is also different from >>>>>>>>> other code, so I'm not sure how valid that argument is. >>>>>>>> >>>>>>>> My macro is modified from "CATCH" in exceptions.hpp: >>>>>>>> >>>>>>>> #define CATCH \ >>>>>>>> THREAD); if (HAS_PENDING_EXCEPTION) { \ >>>>>>>> oop ex = PENDING_EXCEPTION; \ >>>>>>>> CLEAR_PENDING_EXCEPTION; \ >>>>>>>> ex->print(); \ >>>>>>>> ShouldNotReachHere(); \ >>>>>>>> } (void)(0 >>>>>>>> >>>>>>>> So I think that my macro is not big difference fromother code. >>>>>>>> >>>>>>>> >>>>>>>>>> - Similar crash cases exist. e.g. 6425580 and 7142442. >>>>>>>>>> These crashes are different from 6989981. However, I guess that >>>>>>>>>> crashed >>>>>>>>>> thread had pending exception and we need to fix with similar >>>>>>>>>> patch. >>>>>>>>>> >>>>>>>>>> So I think that new macro is useful later. >>>>>>>>> >>>>>>>>> Yes, similar problems may come up in other cases as well. >>>>>>>>> >>>>>>>>> Generally, I don't think it's a good idea to have logging calls >>>>>>>>> hidden away in general macros. What we really should do here is >>>>>>>>> print some context around the stack trace as well. Something like: >>>>>>>>> >>>>>>>>> Initializing the attach listener failed with the following >>>>>>>>> exception in AttachListener::init when initializing the thread_oop: >>>>>>>>> >>>>>>>>> This would be possible with the code I suggested, but very hard >>>>>>>>> in a >>>>>>>>> general macro. >>>>>>>> >>>>>>>> Agree. >>>>>>>> Should we write code as following? >>>>>>>> >>>>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>>>> tty->print_cr("Exception in VM (AttachListener::init) : "); >>>>>>>> java_lang_Throwable::print(PENDING_EXCEPTION, tty); >>>>>>>> CLEAR_PENDING_EXCEPTION; >>>>>>>> return; >>>>>>>> } >>>>>>>> >>>>>>>> I like this way :-) >>>>>>> >>>>>>> Yes, this is what I'd like to see! Can you update your patch, please? >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>>> On 2013/09/20 23:05, Staffan Larsen wrote: >>>>>>>>>>> I see. CHECK_AND_CLEAR_AND_PRINT? Just kidding... :-) >>>>>>>>>>> >>>>>>>>>>> Maybe in this case we should not have this as a macro, but >>>>>>>>>>> actually add the code after the two calls to call_special? >>>>>>>>>>> Something like the code below. I personally think this is more >>>>>>>>>>> readable than obscure macros that I have to go look up to >>>>>>>>>>> understand what they do. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> /Staffan >>>>>>>>>>> >>>>>>>>>>> JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>> klass, >>>>>>>>>>> vmSymbols::object_initializer_name(), >>>>>>>>>>> >>>>>>>>>>> vmSymbols::threadgroup_string_void_signature(), >>>>>>>>>>> thread_group, >>>>>>>>>>> string, >>>>>>>>>>> THREAD); >>>>>>>>>>> >>>>>>>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>>>>>>> java_lang_Throwable::print(PENDING_EXCEPTION, tty); >>>>>>>>>>> CLEAR_PENDING_EXCEPTION; >>>>>>>>>>> return; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> KlassHandle group(THREAD, SystemDictionary::ThreadGroup_klass()); >>>>>>>>>>> JavaCalls::call_special(&result, >>>>>>>>>>> thread_group, >>>>>>>>>>> group, >>>>>>>>>>> vmSymbols::add_method_name(), >>>>>>>>>>> vmSymbols::thread_void_signature(), >>>>>>>>>>> thread_oop, // ARG 1 >>>>>>>>>>> THREAD); >>>>>>>>>>> >>>>>>>>>>> if (HAS_PENDING_EXCEPTION) { >>>>>>>>>>> java_lang_Throwable::print(PENDING_EXCEPTION, tty); >>>>>>>>>>> CLEAR_PENDING_EXCEPTION; >>>>>>>>>>> return; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 20 sep 2013, at 15:53, Yasumasa >>>>>>>>>>>> Suenaga wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Staffan, >>>>>>>>>>>> >>>>>>>>>>>> Thank you for your sponsoring! >>>>>>>>>>>> >>>>>>>>>>>> "CHECK_AND_CLEAR" is already defined in exceptions.hpp: >>>>>>>>>>>> ****************** >>>>>>>>>>>> #define CHECK_AND_CLEAR THREAD); if >>>>>>>>>>>> (HAS_PENDING_EXCEPTION) { CLEAR_PENDING_EXCEPTION; return; >>>>>>>>>>>> } (void)(0 >>>>>>>>>>>> ****************** >>>>>>>>>>>> >>>>>>>>>>>> I think that user wants why serviceability tools are failed. >>>>>>>>>>>> So I defined "CHECK_AND_CLEAR" + java_lang_Throwable::print() as >>>>>>>>>>>> "CATCH_AND_RETURN" . >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I agree rename this macro. >>>>>>>>>>>> Do you have any idea? I don't have a good name :-) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>>> On 2013/09/20 20:10, Staffan Larsen wrote: >>>>>>>>>>>>> Yasuma, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for finding and fixing this! I have re-opened the bug. >>>>>>>>>>>>> Your patch looks good to me, but perhaps CATCH_AND_RETURN >>>>>>>>>>>>> should >>>>>>>>>>>>> be renamed CHECK_AND_CLEAR? >>>>>>>>>>>>> >>>>>>>>>>>>> I can sponsor the fix. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> /Staffan >>>>>>>>>>>>> >>>>>>>>>>>>>> On 20 sep 2013, at 12:41, Yasumasa >>>>>>>>>>>>>> Suenaga wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I encountered this bug: >>>>>>>>>>>>>> JDK-6989981: jstack causes "fatal error: ExceptionMark >>>>>>>>>>>>>> destructor expects no pending exceptions" >>>>>>>>>>>>>> >>>>>>>>>>>>>> I read hs_err and attachListener.cpp, Java heap usage is very >>>>>>>>>>>>>> high and >>>>>>>>>>>>>> it could be OutOfMemoryError in AttachListener::init() . >>>>>>>>>>>>>> >>>>>>>>>>>>>> If JavaCalls::call_special() in AttachListener::init() fail >>>>>>>>>>>>>> which is >>>>>>>>>>>>>> caused by OOME, d'tor of EXCEPTION_MARK (~ExceptionMark) will >>>>>>>>>>>>>> generate >>>>>>>>>>>>>> internal error. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So I make a patch for avoiding crash and attached in this >>>>>>>>>>>>>> email >>>>>>>>>>>>>> (6989981.patch) . >>>>>>>>>>>>>> I'd like to re-open this bug and contribute my patch. >>>>>>>>>>>>>> Could you help me? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> --- DETAILS --- >>>>>>>>>>>>>> CHECK macro is used in JavaCalls::call_special() . >>>>>>>>>>>>>> >>>>>>>>>>>>>> ****************** >>>>>>>>>>>>>> void AttachListener::init() { >>>>>>>>>>>>>> EXCEPTION_MARK; >>>>>>>>>>>>>> >>>>>>>>>>>>>> : >>>>>>>>>>>>>> >>>>>>>>>>>>>> // Initialize thread_oop to put it into the system threadGroup >>>>>>>>>>>>>> Handle thread_group (THREAD, Universe::system_thread_group()); >>>>>>>>>>>>>> JavaValue result(T_VOID); >>>>>>>>>>>>>> JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>>>> klass, >>>>>>>>>>>>>> vmSymbols::object_initializer_name(), >>>>>>>>>>>>>> >>>>>>>>>>>>>> vmSymbols::threadgroup_string_void_signature(), >>>>>>>>>>>>>> thread_group, >>>>>>>>>>>>>> string, >>>>>>>>>>>>>> CHECK); >>>>>>>>>>>>>> >>>>>>>>>>>>>> KlassHandle group(THREAD, >>>>>>>>>>>>>> SystemDictionary::ThreadGroup_klass()); >>>>>>>>>>>>>> JavaCalls::call_special(&result, >>>>>>>>>>>>>> thread_group, >>>>>>>>>>>>>> group, >>>>>>>>>>>>>> vmSymbols::add_method_name(), >>>>>>>>>>>>>> vmSymbols::thread_void_signature(), >>>>>>>>>>>>>> thread_oop, // ARG 1 >>>>>>>>>>>>>> CHECK); >>>>>>>>>>>>>> ****************** >>>>>>>>>>>>>> >>>>>>>>>>>>>> CHECK macro does not clear pending exception of current >>>>>>>>>>>>>> thread. >>>>>>>>>>>>>> So call_special() fails with runtime exception, d'tor of >>>>>>>>>>>>>> ExceptionMark >>>>>>>>>>>>>> generates fatal error. >>>>>>>>>>>>>> >>>>>>>>>>>>>> ****************** >>>>>>>>>>>>>> ExceptionMark::~ExceptionMark() { >>>>>>>>>>>>>> if (_thread->has_pending_exception()) { >>>>>>>>>>>>>> Handle exception(_thread, _thread->pending_exception()); >>>>>>>>>>>>>> _thread->clear_pending_exception(); // Needed to avoid >>>>>>>>>>>>>> infinite recursion >>>>>>>>>>>>>> if (is_init_completed()) { >>>>>>>>>>>>>> exception->print(); >>>>>>>>>>>>>> fatal("ExceptionMark destructor expects no pending >>>>>>>>>>>>>> exceptions"); >>>>>>>>>>>>>> } else { >>>>>>>>>>>>>> vm_exit_during_initialization(exception); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> } >>>>>>>>>>>>>> } >>>>>>>>>>>>>> ****************** >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> --- HOW TO REPRODUCE --- >>>>>>>>>>>>>> I also crate testcase of this issue (testcase.tar.gz) . This >>>>>>>>>>>>>> testcase contains >>>>>>>>>>>>>> two modules. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - jvmti: JVMTI agent for this issue. This agent traps >>>>>>>>>>>>>> SIGQUIT and >>>>>>>>>>>>>> calls original (in HotSpot) SIGQUIT handler. >>>>>>>>>>>>>> This signal handler is invoked, MethodEntry event >>>>>>>>>>>>>> callback is >>>>>>>>>>>>>> enabled. MethodEntry generates OutOfMemoryError. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - java : Simple long sleep program. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I can run this testcase in Fedora18 x86_64. See below. >>>>>>>>>>>>>> >>>>>>>>>>>>>> ------- >>>>>>>>>>>>>> $ javac java/LongSleep.java >>>>>>>>>>>>>> $ make -C jvmti >>>>>>>>>>>>>> make: Entering directory >>>>>>>>>>>>>> `/data/share/patch/ExceptionMark/testcase/jvmti' >>>>>>>>>>>>>> gcc -I/usr/lib/jvm/java-openjdk/include >>>>>>>>>>>>>> -I/usr/lib/jvm/java-openjdk/include/linux -fPIC -c oome.c >>>>>>>>>>>>>> gcc -shared -o liboome.so oome.o >>>>>>>>>>>>>> make: Leaving directory >>>>>>>>>>>>>> `/data/share/patch/ExceptionMark/testcase/jvmti' >>>>>>>>>>>>>> $ export JAVA_HOME= >>>>>>>>>>>>>> $ ./test.sh >>>>>>>>>>>>>> ------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> <6989981.patch> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Dmitry Samersoff >>>>> Oracle Java development team, Saint Petersburg, Russia >>>>> * I would love to change the world, but they won't give me the >>>>> source code. >>>> >>> >> > From coleen.phillimore at oracle.com Fri Oct 4 18:11:05 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Sat, 05 Oct 2013 01:11:05 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20131005011111.31C9562DA5@hg.openjdk.java.net> Changeset: 3374b92de2d9 Author: coleenp Date: 2013-10-03 18:50 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3374b92de2d9 8025004: -XX:+CheckUnhandledOops asserts for JDK 8 Solaris fastdebug binaries Summary: Remove unnecessary volatile keyword on stack locals within instanceKlass.cpp to work around Solaris Studio C++ compiler issue Reviewed-by: coleenp, dcubed Contributed-by: lois.foltan at oracle.com ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 3bf767171ea4 Author: coleenp Date: 2013-10-05 00:53 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3bf767171ea4 Merge From coleen.phillimore at oracle.com Fri Oct 4 19:58:44 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Sat, 05 Oct 2013 02:58:44 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets Message-ID: <20131005025851.6E9C262DAB@hg.openjdk.java.net> Changeset: 675ffabf3798 Author: mikael Date: 2013-10-02 09:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/675ffabf3798 8024087: Remove dead JVM_{Get,Set}PrimitiveFieldValues functions Summary: The two functions were used to support JDK 1.3 but are no longer in use Reviewed-by: coleenp, ctornqvi, twisti, dsamersoff ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/nativeLookup.cpp Changeset: a1fd44b003c7 Author: coleenp Date: 2013-10-05 00:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a1fd44b003c7 Merge Changeset: 4212bfb33d76 Author: coleenp Date: 2013-10-05 03:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4212bfb33d76 Merge From staffan.larsen at oracle.com Sat Oct 5 00:15:29 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Sat, 05 Oct 2013 07:15:29 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20131005071534.1381262DB4@hg.openjdk.java.net> Changeset: febab3a8f203 Author: erikj Date: 2013-10-04 12:45 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/febab3a8f203 8007446: Add /MP to cl.exe speeds up windows builds of OpenJDK. Reviewed-by: sla, ctornqvi ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make Changeset: 763705f0fec3 Author: sla Date: 2013-10-04 13:01 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/763705f0fec3 8016845: SA is unable to use hsdis on windows Summary: Added sadis.c to the build to provide missing symbols in sawindbg.dll. Added code to use the correct hsdisXXX.dll filename on different windows platforms. Reviewed-by: sla, mgerdin Contributed-by: fredrik.arvidsson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java ! make/windows/makefiles/sa.make From chris.hegarty at oracle.com Sat Oct 5 01:05:56 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sat, 05 Oct 2013 08:05:56 +0000 Subject: hg: jdk8/tl/jdk: 8016271: wsimport -clientjar does not create portable jars on Windows due to hardcoded backslash Message-ID: <20131005080617.2118262DBA@hg.openjdk.java.net> Changeset: 7d2112abbb1d Author: coffeys Date: 2013-10-04 16:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d2112abbb1d 8016271: wsimport -clientjar does not create portable jars on Windows due to hardcoded backslash Reviewed-by: mkos, chegar + test/javax/xml/ws/clientjar/TestService.java + test/javax/xml/ws/clientjar/TestWsImport.java From chris.hegarty at oracle.com Sat Oct 5 00:57:24 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sat, 05 Oct 2013 07:57:24 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20131005075733.5131162DB7@hg.openjdk.java.net> Changeset: b0610cd08440 Author: mkos Date: 2013-10-04 16:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b0610cd08440 8025054: Update JAX-WS RI integration to 2.2.9-b130926.1035 Reviewed-by: chegar ! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/ExternalMetadataFeature.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_de.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_es.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_it.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/WscompileMessages.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/resources/wscompile.properties ! src/share/jaxws_classes/com/sun/tools/internal/ws/version.properties ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/Options.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsgenTool.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportOptions.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/wsdl/parser/DOMForest.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_de.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_es.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_fr.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_it.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ja.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ko.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_pt_BR.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_CN.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/SchemaCache.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/DOMForest.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/ct/AbstractExtendedComplexTypeBuilder.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/SchemaConstraintChecker.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/SingleMapNodeProperty.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/AccessorInjector.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Injector.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/OptimizedAccessorFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/Base64Data.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/Base64Encoder.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/Base64EncoderStream.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/ByteArrayOutputStreamEx.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/NamespaceContextEx.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/StreamingDataHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/org/jvnet/staxex/XMLStreamWriterEx.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/binary/SchemaBuilderImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/DDataPattern.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/DPattern.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/DXMLPrinter.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/DataPatternBuilderImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/digested/GrammarBuilderImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/nc/AnyNameClass.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/nc/NameClassBuilderImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/nc/SimpleNameClass.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/parse/compact/UCode_UCodeESC_CharStream.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/parse/xml/SchemaParser.java ! src/share/jaxws_classes/com/sun/xml/internal/rngom/xml/sax/JAXPXMLReaderCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/addressing/WsaTubeHelper.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundOperation.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLBoundPortType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLExtensible.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLFault.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLModel.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLOperation.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLOutput.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLPort.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLPortType.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/WSDLService.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLBoundFault.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLBoundOperation.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLBoundPortType.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLFault.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLInput.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLMessage.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLModel.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLOperation.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLOutput.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLPart.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLPort.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLPortType.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/model/wsdl/editable/EditableWSDLService.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/WSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/parser/WSDLParserExtensionContext.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/binding/WebServiceFeatureList.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/MonitorRootClient.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/PortInfo.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/Stub.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/WSServiceDelegate.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/ExternalMetadataReader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/JavaMethodImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/AbstractExtensibleImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundFaultImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundOperationImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLBoundPortTypeImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLFaultImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLInputImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLMessageImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLModelImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLOperationImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLOutputImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPartImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPortImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLPortTypeImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLProperties.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/wsdl/WSDLServiceImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/jaxws/PolicyWSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/WsservletMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/wsservlet.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/EndpointFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/WSEndpointImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/ProviderImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/HttpAdapter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/transport/http/client/HttpTransportPipe.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/pipe/AbstractSchemaValidationTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/version.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XmlUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/ActionBasedOperationFinder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/PayloadQNameBasedOperationFinder.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/DelegatingParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/FoolProofParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/MemberSubmissionAddressingWSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/RuntimeWSDLParser.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/W3CAddressingMetadataWSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/W3CAddressingWSDLParserExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/WSDLParserExtensionContextImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/parser/WSDLParserExtensionFacade.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/WSDLGenerator.java ! src/share/jaxws_classes/javax/annotation/PostConstruct.java ! src/share/jaxws_classes/javax/annotation/PreDestroy.java ! src/share/jaxws_classes/javax/xml/bind/JAXBException.java ! src/share/jaxws_classes/javax/xml/bind/Marshaller.java ! src/share/jaxws_classes/javax/xml/bind/TypeConstraintException.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/package.html ! src/share/jaxws_classes/javax/xml/soap/MessageFactory.java Changeset: e56be3a2287a Author: coffeys Date: 2013-10-05 08:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/e56be3a2287a 8016271: wsimport -clientjar does not create portable jars on Windows due to hardcoded backslash Reviewed-by: mkos, chegar ! src/share/jaxws_classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java From john.r.rose at oracle.com Sat Oct 5 05:31:44 2013 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 05 Oct 2013 12:31:44 +0000 Subject: hg: jdk8/tl/jdk: 9 new changesets Message-ID: <20131005123417.A921962DBB@hg.openjdk.java.net> Changeset: 44da760eed4b Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44da760eed4b 8024761: JSR 292 improve performance of generic invocation Summary: use a per-MH one element cache for MH.asType to speed up MH.invoke; also cache enough MH constants to cache LMF.metafactory Reviewed-by: twisti ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java - src/share/classes/java/lang/invoke/InvokeGeneric.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java Changeset: 97d5cc1e7586 Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/97d5cc1e7586 8001105: findVirtual of Object[].clone produces internal error Summary: Replicate JVM logic for access control that makes Object.clone appear public when applied to an array type. Reviewed-by: twisti ! src/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: 91535ade7349 Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/91535ade7349 8019417: JSR 292 javadoc should clarify method handle arity limits Summary: clarification of erroneous reading of spec. that led to 7194534 Reviewed-by: twisti, darcy ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/BigArityTest.java Changeset: d391e062b983 Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d391e062b983 8001109: arity mismatch on a call to spreader method handle should elicit IllegalArgumentException Summary: Document error conditions that may occur when calling a "spreader" method handle. Use IAE in all cases. Reviewed-by: twisti, vlivanov ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/JavaDocExamplesTest.java Changeset: acdf5bf1a918 Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/acdf5bf1a918 8001108: an attempt to use "" as a method name should elicit NoSuchMethodException Summary: add an explicit check for leading "<", upgrade the unit tests Reviewed-by: twisti, darcy ! src/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: df6236da299d Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df6236da299d 8024599: JSR 292 direct method handles need to respect initialization rules for static members Summary: Align MH semantic with bytecode behavior of constructor and static member accesses, regarding invocation. Reviewed-by: twisti, darcy, abuckley, vlivanov ! src/share/classes/java/lang/invoke/MethodHandles.java + test/java/lang/invoke/CallStaticInitOrder.java Changeset: eb3cfc69c16e Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eb3cfc69c16e 8001110: method handles should have a collectArguments transform, generalizing asCollector Summary: promote an existing private method; make unit tests on all argument positions to arity 10 with mixed types Reviewed-by: twisti, vlivanov ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: b670477bff8f Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b670477bff8f 8025112: JSR 292 spec updates for security manager and caller sensitivity Summary: align CONSTANT_MethodHandle and Lookup.find* API calls, clarify security manager & @CallerSensitive interactions Reviewed-by: mchung, twisti ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleInfo.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/TestPrivateMember.java Changeset: 6623c675e734 Author: jrose Date: 2013-10-05 05:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6623c675e734 8024438: JSR 292 API specification maintenance for JDK 8 Summary: add wildcard to unreflectConstructor, various clarifications and minor edits Reviewed-by: mchung, darcy, twisti ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleInfo.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MutableCallSite.java ! src/share/classes/java/lang/invoke/SwitchPoint.java ! src/share/classes/sun/invoke/WrapperInstance.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/invoke/util/VerifyType.java ! test/java/lang/invoke/AccessControlTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/RevealDirectTest.java From ivan.gerasimov at oracle.com Sat Oct 5 06:04:13 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 05 Oct 2013 17:04:13 +0400 Subject: RFR [8025886] typo in shell regtest == instead of = In-Reply-To: <524EA7D1.7030908@oracle.com> References: <524D7AF6.2000705@oracle.com> <524EA7D1.7030908@oracle.com> Message-ID: <52500E4D.6020307@oracle.com> Dmitry, thanks for suggestion! Yes, == comparison isn't the only sh-incompatible thing in the script. Sh may be unhappy with [[ as well. So I replaced it with case as you suggested. Grep shows that it was the only place where [[ and == were used in regtests, so it would be good to make things consistent. Please find a new patch below. Sincerely yours, Ivan --- a/test/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh +++ b/test/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh @@ -34,12 +34,13 @@ OS=`uname -s` UMASK=`umask` -if [[ $OS == CYGWIN_NT* ]] ; then +case $OS in +CYGWIN_NT*) OS="Windows_NT" if [ -z "$SystemRoot" ] ; then - SystemRoot=$SYSTEMROOT + SystemRoot=$SYSTEMROOT fi -fi +esac case $OS in SunOS | Linux | Darwin) On 04.10.2013 15:34, Dmitry Samersoff wrote: > Ivan, > > If you need shell pattern match CYGWIN_NT* > it's better to use > > case > > but not > > if > > -Dmitry > > From staffan.larsen at oracle.com Sat Oct 5 07:54:24 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Sat, 05 Oct 2013 14:54:24 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8025922: JNI access to Strings need to check if the value field is non-null Message-ID: <20131005145429.555BC62DBC@hg.openjdk.java.net> Changeset: f9be370a7d54 Author: sla Date: 2013-10-05 15:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9be370a7d54 8025922: JNI access to Strings need to check if the value field is non-null Reviewed-by: dholmes, dcubed ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp From calvin.cheung at oracle.com Fri Oct 4 22:30:36 2013 From: calvin.cheung at oracle.com (calvin.cheung at oracle.com) Date: Sat, 05 Oct 2013 05:30:36 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 32 new changesets Message-ID: <20131005053141.82C1A62DB1@hg.openjdk.java.net> Changeset: 72b7e96c1922 Author: twisti Date: 2013-09-26 12:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/72b7e96c1922 8024545: make develop and notproduct flag values available in product builds Reviewed-by: dholmes, kvn ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/dtraceAttacher.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/memoryService.cpp Changeset: c9ccd7b85f20 Author: rbackman Date: 2013-09-27 08:39 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c9ccd7b85f20 8024924: Intrinsify java.lang.Math.addExact Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/classes.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp + src/share/vm/opto/mathexactnode.cpp + src/share/vm/opto/mathexactnode.hpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/subnode.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/intrinsics/mathexact/CondTest.java + test/compiler/intrinsics/mathexact/ConstantTest.java + test/compiler/intrinsics/mathexact/LoadTest.java + test/compiler/intrinsics/mathexact/LoopDependentTest.java + test/compiler/intrinsics/mathexact/NonConstantTest.java + test/compiler/intrinsics/mathexact/Verify.java Changeset: 510fbd28919c Author: anoll Date: 2013-09-27 10:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/510fbd28919c 8020151: PSR:PERF Large performance regressions when code cache is filled Summary: Code cache sweeping based on method hotness; removed speculatively disconnect Reviewed-by: kvn, iveresov ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/trace/trace.xml Changeset: a07c25e4f67e Author: adlertz Date: 2013-09-27 12:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a07c25e4f67e Merge ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/services/attachListener.cpp Changeset: 1c3486050433 Author: adlertz Date: 2013-09-27 15:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1c3486050433 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: e8e077292da3 Author: iignatyev Date: 2013-09-28 12:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e8e077292da3 8024678: Java source files in hotspot/test/testlibrary should not use @author tag in JavaDoc Reviewed-by: twisti ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathDirEntry.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathJarEntry.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathJarInDirEntry.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassesListInFile.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/CompileTheWorld.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Compiler.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/PathHandler.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Utils.java Changeset: 303826f477c6 Author: iignatyev Date: 2013-09-28 12:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/303826f477c6 8023452: TestCase$Helper(java.lang.Object) must be osr_compiled Reviewed-by: kvn ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java Changeset: f2512d89ad0c Author: twisti Date: 2013-09-28 12:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f2512d89ad0c 8025613: clang: remove -Wno-unused-value Reviewed-by: iveresov ! agent/src/os/linux/LinuxDebuggerLocal.c ! agent/src/os/linux/ps_proc.c ! agent/src/os/linux/salibelf.c ! agent/src/os/linux/symtab.c ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/classfile/defaultMethods.cpp Changeset: 29bdcf12457c Author: shade Date: 2013-09-27 11:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/29bdcf12457c 8014447: Object.hashCode intrinsic breaks inline caches Summary: Try to inline as normal method first, then fall back to intrinsic. Reviewed-by: kvn, twisti ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/library_call.cpp Changeset: d8d059e90ec1 Author: twisti Date: 2013-09-30 15:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d8d059e90ec1 8025599: Missing store barrier with OptimizeStringConcat Reviewed-by: kvn, twisti Contributed-by: Axel Siebenborn ! src/share/vm/opto/graphKit.cpp Changeset: dc261f466b6d Author: drchase Date: 2013-09-27 13:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/dc261f466b6d 8025260: Methodhandles/JSR292: NullPointerException (NPE) thrown instead of AbstractMethodError (AME) Summary: Copied null-checks from templateInterpreter_CPU into methodHandles_CPU Reviewed-by: jrose, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp + test/compiler/jsr292/methodHandleExceptions/ByteClassLoader.java + test/compiler/jsr292/methodHandleExceptions/C.java + test/compiler/jsr292/methodHandleExceptions/I.java + test/compiler/jsr292/methodHandleExceptions/TestAMEnotNPE.java Changeset: cacc4c6bfc80 Author: vlivanov Date: 2013-10-02 06:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cacc4c6bfc80 8025233: Move sun.invoke.Stable into java.lang.invoke package Reviewed-by: twisti, iveresov ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.hpp Changeset: 268e7a2178d7 Author: iveresov Date: 2013-10-03 16:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/268e7a2178d7 Merge ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/services/classLoadingService.cpp Changeset: d68894a09c7c Author: jiangli Date: 2013-09-27 13:49 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d68894a09c7c 8024990: JT_JDK: 11 failures with SIGSEGV on arm-sflt platforms in nightly fastdebug build. Summary: Enable patching for load_appendix_id. Reviewed-by: kvn, dlong, bdelsart ! src/share/vm/c1/c1_Runtime1.cpp Changeset: 5186dcaca431 Author: jiangli Date: 2013-09-27 13:53 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5186dcaca431 Merge ! src/share/vm/c1/c1_Runtime1.cpp - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar Changeset: d0cfa6502dfe Author: jprovino Date: 2013-10-03 10:25 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d0cfa6502dfe Merge ! src/share/vm/c1/c1_Runtime1.cpp Changeset: 100614790c1e Author: vladidan Date: 2013-10-03 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/100614790c1e Merge Changeset: c319b188c7b2 Author: tschatzl Date: 2013-09-26 12:49 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c319b188c7b2 8014078: G1: improve remembered set summary information by providing per region type information Summary: Add memory consumption breakdown on a per region type in the G1 remembered set summary statistics. This simplifies remembered set memory consumption analysis. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! test/gc/g1/TestSummarizeRSetStats.java + test/gc/g1/TestSummarizeRSetStatsPerRegion.java + test/gc/g1/TestSummarizeRSetStatsTools.java Changeset: bc918fd1e584 Author: mgerdin Date: 2013-09-27 10:23 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bc918fd1e584 8025279: metaspace/flags/maxMetaspaceSize throws OOM: out of Compressed Klass space Summary: Only put "Compressed class space" as OOM cause if actually using Compressed class space Reviewed-by: jwilhelm, stefank, ehelin, coleenp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 4fa18058548e Author: tschatzl Date: 2013-09-27 11:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4fa18058548e Merge Changeset: ccef6e165e8b Author: tschatzl Date: 2013-09-27 13:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ccef6e165e8b Merge Changeset: d55c004e1d4d Author: mgerdin Date: 2013-09-24 14:46 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d55c004e1d4d 8025305: Cleanup CardTableModRefBS usage in G1 Summary: Move some G1 specific code from CardTableModRefBS to G1SATBCardTableModRefBS. Reviewed-by: brutisso, tschatzl, ehelin ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp Changeset: 7ec10139bf37 Author: tschatzl Date: 2013-09-30 12:43 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7ec10139bf37 8025441: G1: assert "assert(thread < _num_vtimes) failed: just checking" fails when G1ConcRefinementThreads > ParallelGCThreads Summary: The initialization for the remembered set summary data structures used the wrong thread count, i.e. number of worker threads instead of number of refinement threads. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.hpp + test/gc/g1/TestSummarizeRSetStatsThreads.java Changeset: 9de9169ddde6 Author: brutisso Date: 2013-10-01 07:52 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9de9169ddde6 8025605: G1: Heap expansion logging misleading for fully expanded heap Reviewed-by: tschatzl, jwilhelm, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 9ecd6d3782b1 Author: ehelin Date: 2013-10-01 15:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9ecd6d3782b1 8025313: MetaspaceMemoryPool incorrectly reports undefined size for max Reviewed-by: stefank, tschatzl ! src/share/vm/memory/collectorPolicy.cpp Changeset: 77a774ab3cf0 Author: mgerdin Date: 2013-10-02 14:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/77a774ab3cf0 8012525: gc/metaspace/G1AddMetaspaceDependency.java Test fails a safepoint timeout assertion or hangs. Reviewed-by: brutisso, tschatzl ! test/gc/metaspace/G1AddMetaspaceDependency.java Changeset: 6e22e7042433 Author: ehelin Date: 2013-09-30 11:39 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6e22e7042433 8025226: TestPerfCountersAndMemoryPools.java fails with -Xmixed or -Xcomp Reviewed-by: brutisso, mgerdin ! test/gc/metaspace/TestPerfCountersAndMemoryPools.java Changeset: 379ef2cc19c0 Author: ehelin Date: 2013-10-02 18:24 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/379ef2cc19c0 Merge Changeset: ab68fc0101ce Author: jwilhelm Date: 2013-10-03 13:19 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ab68fc0101ce 8025855: Simplify GenRemSet code slightly Summary: Remove a few redundant switch-statements Reviewed-by: jcoomes, tschatzl ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/genRemSet.cpp Changeset: c49c7f835e8d Author: jwilhelm Date: 2013-10-03 17:16 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c49c7f835e8d 8025853: Remove unnecessary uses of GenerationSizer Summary: Removed stray includes and some minor cleanup of GenerationSizer Reviewed-by: tschatzl, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp Changeset: 798522662fcd Author: jcoomes Date: 2013-10-04 13:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/798522662fcd Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp Changeset: 2720ab7a0d70 Author: ccheung Date: 2013-10-04 21:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2720ab7a0d70 Merge ! src/share/vm/prims/jvm.cpp From staffan.larsen at oracle.com Sat Oct 5 09:51:00 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Sat, 05 Oct 2013 16:51:00 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20131005165108.D781C62DC2@hg.openjdk.java.net> Changeset: 8ef918538e22 Author: sla Date: 2013-10-04 13:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8ef918538e22 6313383: SA: Update jmap to support HPROF binary format "JAVA PROFILE 1.0.2" Summary: Adds support for large(>4G) heap dumps in hprof format. Adds tests and updates testlibrary. Reviewed-by: sla, allwin Contributed-by: fredrik.arvidsson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! test/TEST.groups + test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapProc.java + test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 9c63ad02c0a4 Author: sla Date: 2013-10-05 10:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9c63ad02c0a4 Merge From dmitry.samersoff at oracle.com Sat Oct 5 10:30:28 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 05 Oct 2013 21:30:28 +0400 Subject: RFR [8025886] typo in shell regtest == instead of = In-Reply-To: <52500E4D.6020307@oracle.com> References: <524D7AF6.2000705@oracle.com> <524EA7D1.7030908@oracle.com> <52500E4D.6020307@oracle.com> Message-ID: <52504CB4.9090103@oracle.com> Ivan, Looks good for me. -Dmitry On 2013-10-05 17:04, Ivan Gerasimov wrote: > Dmitry, thanks for suggestion! > > Yes, == comparison isn't the only sh-incompatible thing in the script. > Sh may be unhappy with [[ as well. > So I replaced it with case as you suggested. > Grep shows that it was the only place where [[ and == were used in > regtests, so it would be good to make things consistent. > > Please find a new patch below. > > Sincerely yours, > Ivan > > --- a/test/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh > +++ b/test/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh > @@ -34,12 +34,13 @@ > OS=`uname -s` > UMASK=`umask` > > -if [[ $OS == CYGWIN_NT* ]] ; then > +case $OS in > +CYGWIN_NT*) > OS="Windows_NT" > if [ -z "$SystemRoot" ] ; then > - SystemRoot=$SYSTEMROOT > + SystemRoot=$SYSTEMROOT > fi > -fi > +esac > > case $OS in > SunOS | Linux | Darwin) > > > > On 04.10.2013 15:34, Dmitry Samersoff wrote: >> Ivan, >> >> If you need shell pattern match CYGWIN_NT* >> it's better to use >> >> case >> >> but not >> >> if >> >> -Dmitry >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From christian.tornqvist at oracle.com Sun Oct 6 08:49:44 2013 From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com) Date: Sun, 06 Oct 2013 15:49:44 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8023796: [TESTBUG] Add -XX:-TransmitErrorReport to runtime/6888954/vmerrors.sh Message-ID: <20131006154949.B99FD62DCE@hg.openjdk.java.net> Changeset: cc4f5f8d885e Author: mseledtsov Date: 2013-10-06 16:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cc4f5f8d885e 8023796: [TESTBUG] Add -XX:-TransmitErrorReport to runtime/6888954/vmerrors.sh Summary: added -XX:-TransmitErrorReport to the test Reviewed-by: stefank, ctornqvi ! test/runtime/6888954/vmerrors.sh ! test/runtime/memory/ReserveMemory.java From Alan.Bateman at oracle.com Sun Oct 6 13:03:34 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 06 Oct 2013 21:03:34 +0100 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs Message-ID: <5251C216.105@oracle.com> As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported, I'd like to have another attempt at adding the annotation to a number of JDK specific APIs that are long standing exported, documented and supported APIs. Specifically, the following APIs: - Java Debug Interface (com.sun.jdi) - Attach API (com.sun.tools.attach) - SCTP API (com.sun.nio.sctp) - HTTP server API (com.sun.net.httpserver) - Management extensions (com.sun.management) - JConsole Plugin API (com.sun.tools.jconsole) - JDK-specific API to JAAS (com.sun.security.auth) - JDK-specific JGSS API (com.sun.security.jgss) (The javadoc for each of these APIs is currently generated in the build) The webrev with the proposed update is here: http://cr.openjdk.java.net/~alanb/8008662/webrev.02/ As per the original webrev, I've added package-info.java to a number of packages that didn't have any description. In a few cases, I've had to rename the legacy package.html to package-info.java. For the review then the intention is that @jdk.Exported be added to the package-info and all public/protected types in these APIs. The only exceptions are two cases where I've added @jdk.Exported(false), specifically: - com.sun.management.OSMBeanFactory as it clearly documents to stay away - com.sun.security.auth.callback.DialogCallbackHandler as it for the chop (see JEP 162) Thanks, Alan. From chris.hegarty at oracle.com Mon Oct 7 01:23:08 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 07 Oct 2013 09:23:08 +0100 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <5251C216.105@oracle.com> References: <5251C216.105@oracle.com> Message-ID: <52526F6C.8020202@oracle.com> Alan, I checked the httpsever and sctp changes. All look good to me. -Chris. On 10/06/2013 09:03 PM, Alan Bateman wrote: > > As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported, > I'd like to have another attempt at adding the annotation to a number of > JDK specific APIs that are long standing exported, documented and > supported APIs. Specifically, the following APIs: > > - Java Debug Interface (com.sun.jdi) > - Attach API (com.sun.tools.attach) > - SCTP API (com.sun.nio.sctp) > - HTTP server API (com.sun.net.httpserver) > - Management extensions (com.sun.management) > - JConsole Plugin API (com.sun.tools.jconsole) > - JDK-specific API to JAAS (com.sun.security.auth) > - JDK-specific JGSS API (com.sun.security.jgss) > > (The javadoc for each of these APIs is currently generated in the build) > > The webrev with the proposed update is here: > http://cr.openjdk.java.net/~alanb/8008662/webrev.02/ > > As per the original webrev, I've added package-info.java to a number of > packages that didn't have any description. In a few cases, I've had to > rename the legacy package.html to package-info.java. > > For the review then the intention is that @jdk.Exported be added to the > package-info and all public/protected types in these APIs. The only > exceptions are two cases where I've added @jdk.Exported(false), > specifically: > > - com.sun.management.OSMBeanFactory as it clearly documents to stay away > - com.sun.security.auth.callback.DialogCallbackHandler as it for the > chop (see JEP 162) > > Thanks, > > Alan. From vincent.x.ryan at oracle.com Mon Oct 7 01:33:06 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 7 Oct 2013 09:33:06 +0100 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <52526F6C.8020202@oracle.com> References: <5251C216.105@oracle.com> <52526F6C.8020202@oracle.com> Message-ID: The JAAS and JGSS changes look fine too. On 7 Oct 2013, at 09:23, Chris Hegarty wrote: > Alan, > > I checked the httpsever and sctp changes. All look good to me. > > -Chris. > > On 10/06/2013 09:03 PM, Alan Bateman wrote: >> >> As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported, >> I'd like to have another attempt at adding the annotation to a number of >> JDK specific APIs that are long standing exported, documented and >> supported APIs. Specifically, the following APIs: >> >> - Java Debug Interface (com.sun.jdi) >> - Attach API (com.sun.tools.attach) >> - SCTP API (com.sun.nio.sctp) >> - HTTP server API (com.sun.net.httpserver) >> - Management extensions (com.sun.management) >> - JConsole Plugin API (com.sun.tools.jconsole) >> - JDK-specific API to JAAS (com.sun.security.auth) >> - JDK-specific JGSS API (com.sun.security.jgss) >> >> (The javadoc for each of these APIs is currently generated in the build) >> >> The webrev with the proposed update is here: >> http://cr.openjdk.java.net/~alanb/8008662/webrev.02/ >> >> As per the original webrev, I've added package-info.java to a number of >> packages that didn't have any description. In a few cases, I've had to >> rename the legacy package.html to package-info.java. >> >> For the review then the intention is that @jdk.Exported be added to the >> package-info and all public/protected types in these APIs. The only >> exceptions are two cases where I've added @jdk.Exported(false), >> specifically: >> >> - com.sun.management.OSMBeanFactory as it clearly documents to stay away >> - com.sun.security.auth.callback.DialogCallbackHandler as it for the >> chop (see JEP 162) >> >> Thanks, >> >> Alan. From daniel.fuchs at oracle.com Mon Oct 7 02:44:04 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 07 Oct 2013 11:44:04 +0200 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <5251C216.105@oracle.com> References: <5251C216.105@oracle.com> Message-ID: <52528264.4040205@oracle.com> Hi Alan, The com.sun.management changes look good. -- daniel On 10/6/13 10:03 PM, Alan Bateman wrote: > > As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported, > I'd like to have another attempt at adding the annotation to a number of > JDK specific APIs that are long standing exported, documented and > supported APIs. Specifically, the following APIs: > > - Java Debug Interface (com.sun.jdi) > - Attach API (com.sun.tools.attach) > - SCTP API (com.sun.nio.sctp) > - HTTP server API (com.sun.net.httpserver) > - Management extensions (com.sun.management) > - JConsole Plugin API (com.sun.tools.jconsole) > - JDK-specific API to JAAS (com.sun.security.auth) > - JDK-specific JGSS API (com.sun.security.jgss) > > (The javadoc for each of these APIs is currently generated in the build) > > The webrev with the proposed update is here: > http://cr.openjdk.java.net/~alanb/8008662/webrev.02/ > > As per the original webrev, I've added package-info.java to a number of > packages that didn't have any description. In a few cases, I've had to > rename the legacy package.html to package-info.java. > > For the review then the intention is that @jdk.Exported be added to the > package-info and all public/protected types in these APIs. The only > exceptions are two cases where I've added @jdk.Exported(false), > specifically: > > - com.sun.management.OSMBeanFactory as it clearly documents to stay away > - com.sun.security.auth.callback.DialogCallbackHandler as it for the > chop (see JEP 162) > > Thanks, > > Alan. From mandy.chung at oracle.com Mon Oct 7 03:31:08 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 07 Oct 2013 03:31:08 -0700 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <5251C216.105@oracle.com> References: <5251C216.105@oracle.com> Message-ID: <52528D6C.5000705@oracle.com> On 10/6/2013 1:03 PM, Alan Bateman wrote: > > The webrev with the proposed update is here: > http://cr.openjdk.java.net/~alanb/8008662/webrev.02/ > I went through the entire webrev and the change looks good. > > For the review then the intention is that @jdk.Exported be added to > the package-info and all public/protected types in these APIs. The > only exceptions are two cases where I've added @jdk.Exported(false), > specifically: > > - com.sun.management.OSMBeanFactory as it clearly documents to stay away It's a bug. We should fix it and remove this public class (I have filed JDK-8025985 for it). > - com.sun.security.auth.callback.DialogCallbackHandler as it for the > chop (see JEP 162) Good and this will be gone in jdk9. Mandy From alan.bateman at oracle.com Mon Oct 7 03:51:55 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 07 Oct 2013 10:51:55 +0000 Subject: hg: jdk8/tl/jdk: 8025983: Typo in Javadoc of Files.isRegularFile() Message-ID: <20131007105234.A1F8362DF3@hg.openjdk.java.net> Changeset: 0ac9dc315071 Author: alanb Date: 2013-10-07 11:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ac9dc315071 8025983: Typo in Javadoc of Files.isRegularFile() Reviewed-by: mchung, chegar ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/Path.java From Alan.Bateman at oracle.com Mon Oct 7 03:56:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 Oct 2013 11:56:26 +0100 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <52528D6C.5000705@oracle.com> References: <5251C216.105@oracle.com> <52528D6C.5000705@oracle.com> Message-ID: <5252935A.8070005@oracle.com> On 07/10/2013 11:31, Mandy Chung wrote: > : > >> >> For the review then the intention is that @jdk.Exported be added to >> the package-info and all public/protected types in these APIs. The >> only exceptions are two cases where I've added @jdk.Exported(false), >> specifically: >> >> - com.sun.management.OSMBeanFactory as it clearly documents to stay away > > It's a bug. We should fix it and remove this public class (I have > filed JDK-8025985 for it). Thanks for creating the bug, I agree it should be removed. For now, I'll leave @jdk.Exported(false), unless that issue is resolved before we push this (I hope that is okay with you). -Alan. From sean.mullan at oracle.com Mon Oct 7 05:26:08 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 07 Oct 2013 08:26:08 -0400 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <5251C216.105@oracle.com> References: <5251C216.105@oracle.com> Message-ID: <5252A860.4050609@oracle.com> 7 classes in com.sun.security.auth have been deprecated for several major releases now. Should they still have this annotation? --Sean On 10/06/2013 04:03 PM, Alan Bateman wrote: > > As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported, > I'd like to have another attempt at adding the annotation to a number of > JDK specific APIs that are long standing exported, documented and > supported APIs. Specifically, the following APIs: > > - Java Debug Interface (com.sun.jdi) > - Attach API (com.sun.tools.attach) > - SCTP API (com.sun.nio.sctp) > - HTTP server API (com.sun.net.httpserver) > - Management extensions (com.sun.management) > - JConsole Plugin API (com.sun.tools.jconsole) > - JDK-specific API to JAAS (com.sun.security.auth) > - JDK-specific JGSS API (com.sun.security.jgss) > > (The javadoc for each of these APIs is currently generated in the build) > > The webrev with the proposed update is here: > http://cr.openjdk.java.net/~alanb/8008662/webrev.02/ > > As per the original webrev, I've added package-info.java to a number of > packages that didn't have any description. In a few cases, I've had to > rename the legacy package.html to package-info.java. > > For the review then the intention is that @jdk.Exported be added to the > package-info and all public/protected types in these APIs. The only > exceptions are two cases where I've added @jdk.Exported(false), > specifically: > > - com.sun.management.OSMBeanFactory as it clearly documents to stay away > - com.sun.security.auth.callback.DialogCallbackHandler as it for the > chop (see JEP 162) > > Thanks, > > Alan. From Alan.Bateman at oracle.com Mon Oct 7 05:28:52 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 Oct 2013 13:28:52 +0100 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <5252A860.4050609@oracle.com> References: <5251C216.105@oracle.com> <5252A860.4050609@oracle.com> Message-ID: <5252A904.1070808@oracle.com> On 07/10/2013 13:26, Sean Mullan wrote: > 7 classes in com.sun.security.auth have been deprecated for several > major releases now. Should they still have this annotation? > > --Sean I know but aren't they still exported and supported? DialogCallbackHandler is the only one with its name on a bullet. -Alan. From sean.mullan at oracle.com Mon Oct 7 05:36:53 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 07 Oct 2013 08:36:53 -0400 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <5252A904.1070808@oracle.com> References: <5251C216.105@oracle.com> <5252A860.4050609@oracle.com> <5252A904.1070808@oracle.com> Message-ID: <5252AAE5.4020806@oracle.com> On 10/07/2013 08:28 AM, Alan Bateman wrote: > On 07/10/2013 13:26, Sean Mullan wrote: >> 7 classes in com.sun.security.auth have been deprecated for several >> major releases now. Should they still have this annotation? >> >> --Sean > I know but aren't they still exported and supported? They have all had API replacements since JDK 1.4 or 1.5. There has been plenty of time to transition. > DialogCallbackHandler is the only one with its name on a bullet. We have only started removing some deprecated things in JDK, so it just was never thought about until now. Marking these as supported going forward strikes me as a bit strange, since we don't really want anyone using these anymore. --Sean From Alan.Bateman at oracle.com Mon Oct 7 05:58:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 Oct 2013 13:58:17 +0100 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <5252AAE5.4020806@oracle.com> References: <5251C216.105@oracle.com> <5252A860.4050609@oracle.com> <5252A904.1070808@oracle.com> <5252AAE5.4020806@oracle.com> Message-ID: <5252AFE9.2040205@oracle.com> On 07/10/2013 13:36, Sean Mullan wrote: > > We have only started removing some deprecated things in JDK, so it > just was never thought about until now. Marking these as supported > going forward strikes me as a bit strange, since we don't really want > anyone using these anymore. As a guide, I think we should plan to address these anomalies for 9 so that we can export APIs on a per API package basis. I'm okay to change these to @jdk.Exported(false) if we can flag them for removal (like we did for DialogCallbackHandler). -Alan. From sean.mullan at oracle.com Mon Oct 7 06:02:35 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 07 Oct 2013 09:02:35 -0400 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <5252AFE9.2040205@oracle.com> References: <5251C216.105@oracle.com> <5252A860.4050609@oracle.com> <5252A904.1070808@oracle.com> <5252AAE5.4020806@oracle.com> <5252AFE9.2040205@oracle.com> Message-ID: <5252B0EB.2040803@oracle.com> On 10/07/2013 08:58 AM, Alan Bateman wrote: > On 07/10/2013 13:36, Sean Mullan wrote: >> >> We have only started removing some deprecated things in JDK, so it >> just was never thought about until now. Marking these as supported >> going forward strikes me as a bit strange, since we don't really want >> anyone using these anymore. > As a guide, I think we should plan to address these anomalies for 9 so > that we can export APIs on a per API package basis. I'm okay to change > these to @jdk.Exported(false) if we can flag them for removal (like we > did for DialogCallbackHandler). Sure. I'll file a bug to have these deprecated classes removed in 9. --Sean From jaroslav.bachorik at oracle.com Mon Oct 7 06:59:23 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 07 Oct 2013 15:59:23 +0200 Subject: RFR 7144200: java/lang/management/ClassLoadingMXBean/LoadCounts.java failed with JFR enabled Message-ID: <5252BE3B.5020607@oracle.com> The test captures the number of loaded classes right at the start and then checks the diffs when it's finished. However, it seems that there might by some async class loading still going on, initiated by JFR. The patch simply adds a loop to wait for the number of loaded classes to settle before continuing. This should prevent the test failing with JFR intermittently. Issue: https://bugs.openjdk.java.net/browse/JDK-7144200 Webrev: http://cr.openjdk.java.net/~jbachorik/7144200/webrev.00/ Cheers, -JB- From jaroslav.bachorik at oracle.com Mon Oct 7 07:14:14 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 07 Oct 2013 16:14:14 +0200 Subject: [ping][ping] Re: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <523B0B30.4020003@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> <5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com> <5231DE69.7090309@oracle.com> <523B0B30.4020003@oracle.com> Message-ID: <5252C1B6.2060904@oracle.com> On 19.9.2013 16:33, Jaroslav Bachorik wrote: > The updated webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.03 > > I've moved some of the functionality to the testlibrary. > > -JB - > > On 12.9.2013 17:31, Jaroslav Bachorik wrote: >> On 09/12/2013 05:13 PM, Dmitry Samersoff wrote: >>> Jaroslav, >>> >>> CustomLauncherTest.java: >>> >>> 102: this check could be moved to switch at ll. 108 >>> otherwise test fails on "sunos" and "linux" because PLATFORM remains >>> unset. >> Good idea. Thanks. >> >>> 129: I would prefer don't have pattern like this one ever in shell >>> script. Could you prepare a list of VM's to check and just loop over it? >>> It makes test better readable. Also I think nowdays we can always use >>> server VM. >> I tried to mirror the original shell test as closely as possible. It >> would be nice if we could rely on the "server" vm only. Definitely more >> readable. >> >> -JB- >> >>> -Dmitry >>> >>> >>> On 2013-09-12 18:17, Jaroslav Bachorik wrote: >>>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: >>>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote: >>>>>> On 09/12/2013 04:45 AM, David Holmes wrote: >>>>>>> Hi Jaroslav, >>>>>>> >>>>>>> You need a copyright notice in the new file. >>>>>>> >>>>>>> As written this test can only run on a full JDK - so please add >>>>>>> it to >>>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to come >>>>>>> from the test-jdk? And use the VMOPTS passed to the test?) >>>>>>> >>>>>>> Is there a reason this test can't run on OSX? I know it would need >>>>>>> further modification but was wondering if there is something >>>>>>> inherent in >>>>>>> the test that makes it inapplicable to OSX. >>>>>>> >>>>>>> I think the test would be a lot simpler if the jdk tests had the >>>>>>> hotspot >>>>>>> test library's process tools available. :( >>>>>> We have some, is there an obvious gap? >>>>>> >>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ >>>>>> >>>>> Hm, thanks for the info. I should have used this library instead. >>>>> >>>>> Please, stand by for the updated webrev. >>>> I was able to get rid off the JCMD. Using the testlibrary the target >>>> application can recognize its own PID and print it to its stdout. The >>>> main application then just reads the stdout to parse the PID. No need >>>> for JCMD any more. >>>> >>>> I could not find a way to remove the dependency on "test.jdk" system >>>> property. According to the jtreg web documentation >>>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a >>>> "test.java" >>>> system property should be available but in fact is not. But it seems >>>> that the testlibrary uses "test.jdk" system property too. >>>> >>>> The test does not run on OSX because nobody built the launcher >>>> binary :) >>>> I think it is a kind of DIY so I took the liberty of adding a >>>> linux-amd64 launcher while working on the test. >>>> >>>> While working with the test library I realized I was missing a crucial >>>> feature (at least for my purposes) - waiting for a certain message to >>>> appear in the stdout/stderr of the launched process. Very often I need >>>> to wait for the target process to get to certain point before the test >>>> can be allowed to continue - and the point is indicated by a message in >>>> stdout/stderr. Currently all the proc tools are designed to work in >>>> "batch" mode - the whole stdout/stderr is captured in strings and >>>> analyzed after the target process died - and are not suitable for this >>>> kind of usage. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 >>>> >>>>> -JB- >>>>> >>>>>> >>>>>> -Chris. >>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>>>>>> Please, review the patch for an intermittently failing test. >>>>>>>> >>>>>>>> The test is a shell test, using files for the interprocess >>>>>>>> synchronization. This leads to intermittent failures. >>>>>>>> >>>>>>>> In order to fix this the test is rewritten in Java - the original >>>>>>>> functionality and outputs should be 100% preserved. The patch is >>>>>>>> unfortunately a bit difficult to follow since there is no >>>>>>>> similarity >>>>>>>> between the *.sh and *.java file so one needs to go through the new >>>>>>>> source in whole. >>>>>>>> >>>>>>>> The changes in "launcher" files are all about adding permissions to >>>>>>>> execute (0755) and as such the webrev shows no differences. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Issue : JDK-8004926 >>>>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>>>>>> >>>>>>>> -JB- >>>>>>>> >>> > From daniel.fuchs at oracle.com Mon Oct 7 07:22:10 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 07 Oct 2013 16:22:10 +0200 Subject: jmx-dev RFR 7144200: java/lang/management/ClassLoadingMXBean/LoadCounts.java failed with JFR enabled In-Reply-To: <5252BE3B.5020607@oracle.com> References: <5252BE3B.5020607@oracle.com> Message-ID: <5252C392.5010909@oracle.com> Hi Jaroslav, I am not an expert in classloading but I don't see any obvious issue with what you propose. I wonder whether making the test always run in /othervm mode might make it more stable. best regards, -- daniel On 10/7/13 3:59 PM, Jaroslav Bachorik wrote: > The test captures the number of loaded classes right at the start and > then checks the diffs when it's finished. However, it seems that there > might by some async class loading still going on, initiated by JFR. > > The patch simply adds a loop to wait for the number of loaded classes to > settle before continuing. This should prevent the test failing with JFR > intermittently. > > Issue: https://bugs.openjdk.java.net/browse/JDK-7144200 > Webrev: http://cr.openjdk.java.net/~jbachorik/7144200/webrev.00/ > > Cheers, > > -JB- From dmitry.samersoff at oracle.com Mon Oct 7 07:31:27 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 07 Oct 2013 18:31:27 +0400 Subject: jmx-dev [ping][ping] Re: RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <5252C1B6.2060904@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> <5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com> <5231DE69.7090309@oracle.com> <523B0B30.4020003@oracle.com> <5252C1B6.2060904@oracle.com> Message-ID: <5252C5BF.4060406@oracle.com> Jarsolav, Looks good for me, comments below is just a nits - so fill free to ignore it. 1. As FS.getPath(TEST_JDK, "jre", "lib", LIBARCH) is the only value for findLibjvm parameter, It's better to create an overload function findLibjvm(). 2. it's better to check for File.isFile() - readable (e.g. device) is not always what you whant here. 3. It's good to try ARCH/libjvm.so, ARCH/server/libjvm.so, ARCH/client/libjvm.so in order for the possible platforms with the only vm -Dmitry On 2013-10-07 18:14, Jaroslav Bachorik wrote: > On 19.9.2013 16:33, Jaroslav Bachorik wrote: >> The updated webrev: >> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.03 >> >> I've moved some of the functionality to the testlibrary. >> >> -JB - >> >> On 12.9.2013 17:31, Jaroslav Bachorik wrote: >>> On 09/12/2013 05:13 PM, Dmitry Samersoff wrote: >>>> Jaroslav, >>>> >>>> CustomLauncherTest.java: >>>> >>>> 102: this check could be moved to switch at ll. 108 >>>> otherwise test fails on "sunos" and "linux" because PLATFORM remains >>>> unset. >>> Good idea. Thanks. >>> >>>> 129: I would prefer don't have pattern like this one ever in shell >>>> script. Could you prepare a list of VM's to check and just loop over >>>> it? >>>> It makes test better readable. Also I think nowdays we can always use >>>> server VM. >>> I tried to mirror the original shell test as closely as possible. It >>> would be nice if we could rely on the "server" vm only. Definitely more >>> readable. >>> >>> -JB- >>> >>>> -Dmitry >>>> >>>> >>>> On 2013-09-12 18:17, Jaroslav Bachorik wrote: >>>>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: >>>>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote: >>>>>>> On 09/12/2013 04:45 AM, David Holmes wrote: >>>>>>>> Hi Jaroslav, >>>>>>>> >>>>>>>> You need a copyright notice in the new file. >>>>>>>> >>>>>>>> As written this test can only run on a full JDK - so please add >>>>>>>> it to >>>>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to >>>>>>>> come >>>>>>>> from the test-jdk? And use the VMOPTS passed to the test?) >>>>>>>> >>>>>>>> Is there a reason this test can't run on OSX? I know it would need >>>>>>>> further modification but was wondering if there is something >>>>>>>> inherent in >>>>>>>> the test that makes it inapplicable to OSX. >>>>>>>> >>>>>>>> I think the test would be a lot simpler if the jdk tests had the >>>>>>>> hotspot >>>>>>>> test library's process tools available. :( >>>>>>> We have some, is there an obvious gap? >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ >>>>>>> >>>>>>> >>>>>> Hm, thanks for the info. I should have used this library instead. >>>>>> >>>>>> Please, stand by for the updated webrev. >>>>> I was able to get rid off the JCMD. Using the testlibrary the target >>>>> application can recognize its own PID and print it to its stdout. The >>>>> main application then just reads the stdout to parse the PID. No need >>>>> for JCMD any more. >>>>> >>>>> I could not find a way to remove the dependency on "test.jdk" system >>>>> property. According to the jtreg web documentation >>>>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a >>>>> "test.java" >>>>> system property should be available but in fact is not. But it seems >>>>> that the testlibrary uses "test.jdk" system property too. >>>>> >>>>> The test does not run on OSX because nobody built the launcher >>>>> binary :) >>>>> I think it is a kind of DIY so I took the liberty of adding a >>>>> linux-amd64 launcher while working on the test. >>>>> >>>>> While working with the test library I realized I was missing a crucial >>>>> feature (at least for my purposes) - waiting for a certain message to >>>>> appear in the stdout/stderr of the launched process. Very often I need >>>>> to wait for the target process to get to certain point before the test >>>>> can be allowed to continue - and the point is indicated by a >>>>> message in >>>>> stdout/stderr. Currently all the proc tools are designed to work in >>>>> "batch" mode - the whole stdout/stderr is captured in strings and >>>>> analyzed after the target process died - and are not suitable for this >>>>> kind of usage. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 >>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>>>>>>> Please, review the patch for an intermittently failing test. >>>>>>>>> >>>>>>>>> The test is a shell test, using files for the interprocess >>>>>>>>> synchronization. This leads to intermittent failures. >>>>>>>>> >>>>>>>>> In order to fix this the test is rewritten in Java - the original >>>>>>>>> functionality and outputs should be 100% preserved. The patch is >>>>>>>>> unfortunately a bit difficult to follow since there is no >>>>>>>>> similarity >>>>>>>>> between the *.sh and *.java file so one needs to go through the >>>>>>>>> new >>>>>>>>> source in whole. >>>>>>>>> >>>>>>>>> The changes in "launcher" files are all about adding >>>>>>>>> permissions to >>>>>>>>> execute (0755) and as such the webrev shows no differences. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Issue : JDK-8004926 >>>>>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Mon Oct 7 07:34:52 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 07 Oct 2013 16:34:52 +0200 Subject: jmx-dev RFR 7144200: java/lang/management/ClassLoadingMXBean/LoadCounts.java failed with JFR enabled In-Reply-To: <5252C392.5010909@oracle.com> References: <5252BE3B.5020607@oracle.com> <5252C392.5010909@oracle.com> Message-ID: <5252C68C.4050608@oracle.com> On 7.10.2013 16:22, Daniel Fuchs wrote: > Hi Jaroslav, > > I am not an expert in classloading but I don't see any obvious > issue with what you propose. I hope there is none :) If the number of loaded classes is not changing the test should continue immediately. The only problem could be loading the classes veeery slowly - not increasing the number of the loaded classes in 300ms interval. We could get a false positive and end up with the same failure as now :( > > I wonder whether making the test always run in /othervm mode > might make it more stable. I don't know. I was not able to reproduce the problem but from the description it sounds like it is spotted only with JFR enabled. So, I suppose, running it in othervm would not help at all. -JB- > > best regards, > > -- daniel > > On 10/7/13 3:59 PM, Jaroslav Bachorik wrote: >> The test captures the number of loaded classes right at the start and >> then checks the diffs when it's finished. However, it seems that there >> might by some async class loading still going on, initiated by JFR. >> >> The patch simply adds a loop to wait for the number of loaded classes to >> settle before continuing. This should prevent the test failing with JFR >> intermittently. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-7144200 >> Webrev: http://cr.openjdk.java.net/~jbachorik/7144200/webrev.00/ >> >> Cheers, >> >> -JB- > From staffan.larsen at oracle.com Mon Oct 7 07:35:47 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 7 Oct 2013 16:35:47 +0200 Subject: RFR 7144200: java/lang/management/ClassLoadingMXBean/LoadCounts.java failed with JFR enabled In-Reply-To: <5252BE3B.5020607@oracle.com> References: <5252BE3B.5020607@oracle.com> Message-ID: This will make it less likely for the test to fail, but does not guarantee it since there is nothing that says classloading will be done in 300 ms. Any failures will unfortunately be harder to reproduce. (And the test is now 300 ms slower to run.) A different solution is to only allow the number of classes to increase, but not be strict about the increase being exactly 4. That would of course make the test less stringent, but very stable. In any case, I think the test has to be marked as /othervm since running other tests simultaneously will impact this test. S/taffan On 7 okt 2013, at 15:59, Jaroslav Bachorik wrote: > The test captures the number of loaded classes right at the start and then checks the diffs when it's finished. However, it seems that there might by some async class loading still going on, initiated by JFR. > > The patch simply adds a loop to wait for the number of loaded classes to settle before continuing. This should prevent the test failing with JFR intermittently. > > Issue: https://bugs.openjdk.java.net/browse/JDK-7144200 > Webrev: http://cr.openjdk.java.net/~jbachorik/7144200/webrev.00/ > > Cheers, > > -JB- From erik.gahlin at oracle.com Mon Oct 7 09:01:40 2013 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Mon, 07 Oct 2013 18:01:40 +0200 Subject: RFR 7144200: java/lang/management/ClassLoadingMXBean/LoadCounts.java failed with JFR enabled In-Reply-To: <5252BE3B.5020607@oracle.com> References: <5252BE3B.5020607@oracle.com> Message-ID: <5252DAE4.6030406@oracle.com> I don't think the test should run with JFR enabled. I would ask SQE not to run unit tests with JFR and only add /othervm. Erik Jaroslav Bachorik skrev 10/7/13 3:59 PM: > The test captures the number of loaded classes right at the start and > then checks the diffs when it's finished. However, it seems that there > might by some async class loading still going on, initiated by JFR. > > The patch simply adds a loop to wait for the number of loaded classes > to settle before continuing. This should prevent the test failing with > JFR intermittently. > > Issue: https://bugs.openjdk.java.net/browse/JDK-7144200 > Webrev: http://cr.openjdk.java.net/~jbachorik/7144200/webrev.00/ > > Cheers, > > -JB- From jaroslav.bachorik at oracle.com Mon Oct 7 09:39:06 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 07 Oct 2013 18:39:06 +0200 Subject: jmx-dev [ping][ping] Re: RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <5252C5BF.4060406@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> <5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com> <5231DE69.7090309@oracle.com> <523B0B30.4020003@oracle.com> <5252C1B6.2060904@oracle.com> <5252C5BF.4060406@oracle.com> Message-ID: <5252E3AA.5010702@oracle.com> On 7.10.2013 16:31, Dmitry Samersoff wrote: > Jarsolav, > > Looks good for me, comments below is just a nits - so fill free to > ignore it. > > 1. > As FS.getPath(TEST_JDK, "jre", "lib", LIBARCH) is the only value for > findLibjvm parameter, It's better to create an overload function > findLibjvm(). Ok. It will make the code a further bit readable. > > 2. > it's better to check for File.isFile() - readable (e.g. device) is not > always what you whant here. Can you elaborate why checking for the current user being able to read the actual library file might be wrong? > > 3. It's good to try > ARCH/libjvm.so, ARCH/server/libjvm.so, ARCH/client/libjvm.so > in order for the possible platforms with the only vm Ok. -JB- > > -Dmitry > > > On 2013-10-07 18:14, Jaroslav Bachorik wrote: >> On 19.9.2013 16:33, Jaroslav Bachorik wrote: >>> The updated webrev: >>> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.03 >>> >>> I've moved some of the functionality to the testlibrary. >>> >>> -JB - >>> >>> On 12.9.2013 17:31, Jaroslav Bachorik wrote: >>>> On 09/12/2013 05:13 PM, Dmitry Samersoff wrote: >>>>> Jaroslav, >>>>> >>>>> CustomLauncherTest.java: >>>>> >>>>> 102: this check could be moved to switch at ll. 108 >>>>> otherwise test fails on "sunos" and "linux" because PLATFORM remains >>>>> unset. >>>> Good idea. Thanks. >>>> >>>>> 129: I would prefer don't have pattern like this one ever in shell >>>>> script. Could you prepare a list of VM's to check and just loop over >>>>> it? >>>>> It makes test better readable. Also I think nowdays we can always use >>>>> server VM. >>>> I tried to mirror the original shell test as closely as possible. It >>>> would be nice if we could rely on the "server" vm only. Definitely more >>>> readable. >>>> >>>> -JB- >>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2013-09-12 18:17, Jaroslav Bachorik wrote: >>>>>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: >>>>>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote: >>>>>>>> On 09/12/2013 04:45 AM, David Holmes wrote: >>>>>>>>> Hi Jaroslav, >>>>>>>>> >>>>>>>>> You need a copyright notice in the new file. >>>>>>>>> >>>>>>>>> As written this test can only run on a full JDK - so please add >>>>>>>>> it to >>>>>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to >>>>>>>>> come >>>>>>>>> from the test-jdk? And use the VMOPTS passed to the test?) >>>>>>>>> >>>>>>>>> Is there a reason this test can't run on OSX? I know it would need >>>>>>>>> further modification but was wondering if there is something >>>>>>>>> inherent in >>>>>>>>> the test that makes it inapplicable to OSX. >>>>>>>>> >>>>>>>>> I think the test would be a lot simpler if the jdk tests had the >>>>>>>>> hotspot >>>>>>>>> test library's process tools available. :( >>>>>>>> We have some, is there an obvious gap? >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ >>>>>>>> >>>>>>>> >>>>>>> Hm, thanks for the info. I should have used this library instead. >>>>>>> >>>>>>> Please, stand by for the updated webrev. >>>>>> I was able to get rid off the JCMD. Using the testlibrary the target >>>>>> application can recognize its own PID and print it to its stdout. The >>>>>> main application then just reads the stdout to parse the PID. No need >>>>>> for JCMD any more. >>>>>> >>>>>> I could not find a way to remove the dependency on "test.jdk" system >>>>>> property. According to the jtreg web documentation >>>>>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a >>>>>> "test.java" >>>>>> system property should be available but in fact is not. But it seems >>>>>> that the testlibrary uses "test.jdk" system property too. >>>>>> >>>>>> The test does not run on OSX because nobody built the launcher >>>>>> binary :) >>>>>> I think it is a kind of DIY so I took the liberty of adding a >>>>>> linux-amd64 launcher while working on the test. >>>>>> >>>>>> While working with the test library I realized I was missing a crucial >>>>>> feature (at least for my purposes) - waiting for a certain message to >>>>>> appear in the stdout/stderr of the launched process. Very often I need >>>>>> to wait for the target process to get to certain point before the test >>>>>> can be allowed to continue - and the point is indicated by a >>>>>> message in >>>>>> stdout/stderr. Currently all the proc tools are designed to work in >>>>>> "batch" mode - the whole stdout/stderr is captured in strings and >>>>>> analyzed after the target process died - and are not suitable for this >>>>>> kind of usage. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 >>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> >>>>>>>> -Chris. >>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>>>>>>>> Please, review the patch for an intermittently failing test. >>>>>>>>>> >>>>>>>>>> The test is a shell test, using files for the interprocess >>>>>>>>>> synchronization. This leads to intermittent failures. >>>>>>>>>> >>>>>>>>>> In order to fix this the test is rewritten in Java - the original >>>>>>>>>> functionality and outputs should be 100% preserved. The patch is >>>>>>>>>> unfortunately a bit difficult to follow since there is no >>>>>>>>>> similarity >>>>>>>>>> between the *.sh and *.java file so one needs to go through the >>>>>>>>>> new >>>>>>>>>> source in whole. >>>>>>>>>> >>>>>>>>>> The changes in "launcher" files are all about adding >>>>>>>>>> permissions to >>>>>>>>>> execute (0755) and as such the webrev shows no differences. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Issue : JDK-8004926 >>>>>>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>>> >>>>> >>> >> > > From dmitry.samersoff at oracle.com Mon Oct 7 09:47:25 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 07 Oct 2013 20:47:25 +0400 Subject: jmx-dev [ping][ping] Re: RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <5252E3AA.5010702@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> <5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com> <5231DE69.7090309@oracle.com> <523B0B30.4020003@oracle.com> <5252C1B6.2060904@oracle.com> <5252C5BF.4060406@oracle.com> <5252E3AA.5010702@oracle.com> Message-ID: <5252E59D.30200@oracle.com> Jaroslav, > Can you elaborate why checking for the current user being able to read > the actual library file might be wrong? It's not applicable to this particular testcase (so I'd marked it as a nit) but a generic security rule is to always check that we deal with a regular file. Try to link any block device to libjvm.so and see what happens. -Dmitry On 2013-10-07 20:39, Jaroslav Bachorik wrote: > On 7.10.2013 16:31, Dmitry Samersoff wrote: >> Jarsolav, >> >> Looks good for me, comments below is just a nits - so fill free to >> ignore it. >> >> 1. >> As FS.getPath(TEST_JDK, "jre", "lib", LIBARCH) is the only value for >> findLibjvm parameter, It's better to create an overload function >> findLibjvm(). > > Ok. It will make the code a further bit readable. > >> >> 2. >> it's better to check for File.isFile() - readable (e.g. device) is not >> always what you whant here. > > Can you elaborate why checking for the current user being able to read > the actual library file might be wrong? > >> >> 3. It's good to try >> ARCH/libjvm.so, ARCH/server/libjvm.so, ARCH/client/libjvm.so >> in order for the possible platforms with the only vm > > Ok. > > -JB- > >> >> -Dmitry >> >> >> On 2013-10-07 18:14, Jaroslav Bachorik wrote: >>> On 19.9.2013 16:33, Jaroslav Bachorik wrote: >>>> The updated webrev: >>>> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.03 >>>> >>>> I've moved some of the functionality to the testlibrary. >>>> >>>> -JB - >>>> >>>> On 12.9.2013 17:31, Jaroslav Bachorik wrote: >>>>> On 09/12/2013 05:13 PM, Dmitry Samersoff wrote: >>>>>> Jaroslav, >>>>>> >>>>>> CustomLauncherTest.java: >>>>>> >>>>>> 102: this check could be moved to switch at ll. 108 >>>>>> otherwise test fails on "sunos" and "linux" because PLATFORM remains >>>>>> unset. >>>>> Good idea. Thanks. >>>>> >>>>>> 129: I would prefer don't have pattern like this one ever in shell >>>>>> script. Could you prepare a list of VM's to check and just loop over >>>>>> it? >>>>>> It makes test better readable. Also I think nowdays we can always use >>>>>> server VM. >>>>> I tried to mirror the original shell test as closely as possible. It >>>>> would be nice if we could rely on the "server" vm only. Definitely >>>>> more >>>>> readable. >>>>> >>>>> -JB- >>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2013-09-12 18:17, Jaroslav Bachorik wrote: >>>>>>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: >>>>>>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote: >>>>>>>>> On 09/12/2013 04:45 AM, David Holmes wrote: >>>>>>>>>> Hi Jaroslav, >>>>>>>>>> >>>>>>>>>> You need a copyright notice in the new file. >>>>>>>>>> >>>>>>>>>> As written this test can only run on a full JDK - so please add >>>>>>>>>> it to >>>>>>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to >>>>>>>>>> come >>>>>>>>>> from the test-jdk? And use the VMOPTS passed to the test?) >>>>>>>>>> >>>>>>>>>> Is there a reason this test can't run on OSX? I know it would >>>>>>>>>> need >>>>>>>>>> further modification but was wondering if there is something >>>>>>>>>> inherent in >>>>>>>>>> the test that makes it inapplicable to OSX. >>>>>>>>>> >>>>>>>>>> I think the test would be a lot simpler if the jdk tests had the >>>>>>>>>> hotspot >>>>>>>>>> test library's process tools available. :( >>>>>>>>> We have some, is there an obvious gap? >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Hm, thanks for the info. I should have used this library instead. >>>>>>>> >>>>>>>> Please, stand by for the updated webrev. >>>>>>> I was able to get rid off the JCMD. Using the testlibrary the target >>>>>>> application can recognize its own PID and print it to its stdout. >>>>>>> The >>>>>>> main application then just reads the stdout to parse the PID. No >>>>>>> need >>>>>>> for JCMD any more. >>>>>>> >>>>>>> I could not find a way to remove the dependency on "test.jdk" system >>>>>>> property. According to the jtreg web documentation >>>>>>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a >>>>>>> "test.java" >>>>>>> system property should be available but in fact is not. But it seems >>>>>>> that the testlibrary uses "test.jdk" system property too. >>>>>>> >>>>>>> The test does not run on OSX because nobody built the launcher >>>>>>> binary :) >>>>>>> I think it is a kind of DIY so I took the liberty of adding a >>>>>>> linux-amd64 launcher while working on the test. >>>>>>> >>>>>>> While working with the test library I realized I was missing a >>>>>>> crucial >>>>>>> feature (at least for my purposes) - waiting for a certain >>>>>>> message to >>>>>>> appear in the stdout/stderr of the launched process. Very often I >>>>>>> need >>>>>>> to wait for the target process to get to certain point before the >>>>>>> test >>>>>>> can be allowed to continue - and the point is indicated by a >>>>>>> message in >>>>>>> stdout/stderr. Currently all the proc tools are designed to work in >>>>>>> "batch" mode - the whole stdout/stderr is captured in strings and >>>>>>> analyzed after the target process died - and are not suitable for >>>>>>> this >>>>>>> kind of usage. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 >>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>>> >>>>>>>>> -Chris. >>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>>>>>>>>> Please, review the patch for an intermittently failing test. >>>>>>>>>>> >>>>>>>>>>> The test is a shell test, using files for the interprocess >>>>>>>>>>> synchronization. This leads to intermittent failures. >>>>>>>>>>> >>>>>>>>>>> In order to fix this the test is rewritten in Java - the >>>>>>>>>>> original >>>>>>>>>>> functionality and outputs should be 100% preserved. The patch is >>>>>>>>>>> unfortunately a bit difficult to follow since there is no >>>>>>>>>>> similarity >>>>>>>>>>> between the *.sh and *.java file so one needs to go through the >>>>>>>>>>> new >>>>>>>>>>> source in whole. >>>>>>>>>>> >>>>>>>>>>> The changes in "launcher" files are all about adding >>>>>>>>>>> permissions to >>>>>>>>>>> execute (0755) and as such the webrev shows no differences. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Issue : JDK-8004926 >>>>>>>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>> >>>> >>> >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Mon Oct 7 09:55:53 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 07 Oct 2013 18:55:53 +0200 Subject: jmx-dev [ping][ping] Re: RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <5252E59D.30200@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> <5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com> <5231DE69.7090309@oracle.com> <523B0B30.4020003@oracle.com> <5252C1B6.2060904@oracle.com> <5252C5BF.4060406@oracle.com> <5252E3AA.5010702@oracle.com> <5252E59D.30200@oracle.com> Message-ID: <5252E799.4090402@oracle.com> On 7.10.2013 18:47, Dmitry Samersoff wrote: > Jaroslav, > >> Can you elaborate why checking for the current user being able to read >> the actual library file might be wrong? > > It's not applicable to this particular testcase (so I'd marked it as a > nit) but a generic security rule is to always check that we deal with a > regular file. > > Try to link any block device to libjvm.so and see what happens. Ok. I see - in that case it would probably be good to check either for regular file and it being readable. -JB- > > -Dmitry > > > > On 2013-10-07 20:39, Jaroslav Bachorik wrote: >> On 7.10.2013 16:31, Dmitry Samersoff wrote: >>> Jarsolav, >>> >>> Looks good for me, comments below is just a nits - so fill free to >>> ignore it. >>> >>> 1. >>> As FS.getPath(TEST_JDK, "jre", "lib", LIBARCH) is the only value for >>> findLibjvm parameter, It's better to create an overload function >>> findLibjvm(). >> >> Ok. It will make the code a further bit readable. >> >>> >>> 2. >>> it's better to check for File.isFile() - readable (e.g. device) is not >>> always what you whant here. >> >> Can you elaborate why checking for the current user being able to read >> the actual library file might be wrong? >> >>> >>> 3. It's good to try >>> ARCH/libjvm.so, ARCH/server/libjvm.so, ARCH/client/libjvm.so >>> in order for the possible platforms with the only vm >> >> Ok. >> >> -JB- >> >>> >>> -Dmitry >>> >>> >>> On 2013-10-07 18:14, Jaroslav Bachorik wrote: >>>> On 19.9.2013 16:33, Jaroslav Bachorik wrote: >>>>> The updated webrev: >>>>> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.03 >>>>> >>>>> I've moved some of the functionality to the testlibrary. >>>>> >>>>> -JB - >>>>> >>>>> On 12.9.2013 17:31, Jaroslav Bachorik wrote: >>>>>> On 09/12/2013 05:13 PM, Dmitry Samersoff wrote: >>>>>>> Jaroslav, >>>>>>> >>>>>>> CustomLauncherTest.java: >>>>>>> >>>>>>> 102: this check could be moved to switch at ll. 108 >>>>>>> otherwise test fails on "sunos" and "linux" because PLATFORM remains >>>>>>> unset. >>>>>> Good idea. Thanks. >>>>>> >>>>>>> 129: I would prefer don't have pattern like this one ever in shell >>>>>>> script. Could you prepare a list of VM's to check and just loop over >>>>>>> it? >>>>>>> It makes test better readable. Also I think nowdays we can always use >>>>>>> server VM. >>>>>> I tried to mirror the original shell test as closely as possible. It >>>>>> would be nice if we could rely on the "server" vm only. Definitely >>>>>> more >>>>>> readable. >>>>>> >>>>>> -JB- >>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> On 2013-09-12 18:17, Jaroslav Bachorik wrote: >>>>>>>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: >>>>>>>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote: >>>>>>>>>> On 09/12/2013 04:45 AM, David Holmes wrote: >>>>>>>>>>> Hi Jaroslav, >>>>>>>>>>> >>>>>>>>>>> You need a copyright notice in the new file. >>>>>>>>>>> >>>>>>>>>>> As written this test can only run on a full JDK - so please add >>>>>>>>>>> it to >>>>>>>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to >>>>>>>>>>> come >>>>>>>>>>> from the test-jdk? And use the VMOPTS passed to the test?) >>>>>>>>>>> >>>>>>>>>>> Is there a reason this test can't run on OSX? I know it would >>>>>>>>>>> need >>>>>>>>>>> further modification but was wondering if there is something >>>>>>>>>>> inherent in >>>>>>>>>>> the test that makes it inapplicable to OSX. >>>>>>>>>>> >>>>>>>>>>> I think the test would be a lot simpler if the jdk tests had the >>>>>>>>>>> hotspot >>>>>>>>>>> test library's process tools available. :( >>>>>>>>>> We have some, is there an obvious gap? >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Hm, thanks for the info. I should have used this library instead. >>>>>>>>> >>>>>>>>> Please, stand by for the updated webrev. >>>>>>>> I was able to get rid off the JCMD. Using the testlibrary the target >>>>>>>> application can recognize its own PID and print it to its stdout. >>>>>>>> The >>>>>>>> main application then just reads the stdout to parse the PID. No >>>>>>>> need >>>>>>>> for JCMD any more. >>>>>>>> >>>>>>>> I could not find a way to remove the dependency on "test.jdk" system >>>>>>>> property. According to the jtreg web documentation >>>>>>>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a >>>>>>>> "test.java" >>>>>>>> system property should be available but in fact is not. But it seems >>>>>>>> that the testlibrary uses "test.jdk" system property too. >>>>>>>> >>>>>>>> The test does not run on OSX because nobody built the launcher >>>>>>>> binary :) >>>>>>>> I think it is a kind of DIY so I took the liberty of adding a >>>>>>>> linux-amd64 launcher while working on the test. >>>>>>>> >>>>>>>> While working with the test library I realized I was missing a >>>>>>>> crucial >>>>>>>> feature (at least for my purposes) - waiting for a certain >>>>>>>> message to >>>>>>>> appear in the stdout/stderr of the launched process. Very often I >>>>>>>> need >>>>>>>> to wait for the target process to get to certain point before the >>>>>>>> test >>>>>>>> can be allowed to continue - and the point is indicated by a >>>>>>>> message in >>>>>>>> stdout/stderr. Currently all the proc tools are designed to work in >>>>>>>> "batch" mode - the whole stdout/stderr is captured in strings and >>>>>>>> analyzed after the target process died - and are not suitable for >>>>>>>> this >>>>>>>> kind of usage. >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 >>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Chris. >>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>>>>>>>>>> Please, review the patch for an intermittently failing test. >>>>>>>>>>>> >>>>>>>>>>>> The test is a shell test, using files for the interprocess >>>>>>>>>>>> synchronization. This leads to intermittent failures. >>>>>>>>>>>> >>>>>>>>>>>> In order to fix this the test is rewritten in Java - the >>>>>>>>>>>> original >>>>>>>>>>>> functionality and outputs should be 100% preserved. The patch is >>>>>>>>>>>> unfortunately a bit difficult to follow since there is no >>>>>>>>>>>> similarity >>>>>>>>>>>> between the *.sh and *.java file so one needs to go through the >>>>>>>>>>>> new >>>>>>>>>>>> source in whole. >>>>>>>>>>>> >>>>>>>>>>>> The changes in "launcher" files are all about adding >>>>>>>>>>>> permissions to >>>>>>>>>>>> execute (0755) and as such the webrev shows no differences. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Issue : JDK-8004926 >>>>>>>>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>>>>>>>>>> >>>>>>>>>>>> -JB- >>>>>>>>>>>> >>>>>>> >>>>> >>>> >>> >>> >> > > From serguei.spitsyn at oracle.com Mon Oct 7 10:06:15 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 07 Oct 2013 10:06:15 -0700 Subject: RFR 7144200: java/lang/management/ClassLoadingMXBean/LoadCounts.java failed with JFR enabled In-Reply-To: <5252DAE4.6030406@oracle.com> References: <5252BE3B.5020607@oracle.com> <5252DAE4.6030406@oracle.com> Message-ID: <5252EA07.4060305@oracle.com> I agree with Erik. It is better to just exclude this test from run with JFR enabled. Adding /othervm should probably solve the problem. Thanks, Serguei On 10/7/13 9:01 AM, Erik Gahlin wrote: > I don't think the test should run with JFR enabled. I would ask SQE > not to run unit tests with JFR and only add /othervm. > > Erik > > Jaroslav Bachorik skrev 10/7/13 3:59 PM: >> The test captures the number of loaded classes right at the start and >> then checks the diffs when it's finished. However, it seems that >> there might by some async class loading still going on, initiated by >> JFR. >> >> The patch simply adds a loop to wait for the number of loaded classes >> to settle before continuing. This should prevent the test failing >> with JFR intermittently. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-7144200 >> Webrev: http://cr.openjdk.java.net/~jbachorik/7144200/webrev.00/ >> >> Cheers, >> >> -JB- > From jaroslav.bachorik at oracle.com Mon Oct 7 10:10:33 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 07 Oct 2013 19:10:33 +0200 Subject: jmx-dev [ping][ping] Re: RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <5252C5BF.4060406@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> <5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com> <5231DE69.7090309@oracle.com> <523B0B30.4020003@oracle.com> <5252C1B6.2060904@oracle.com> <5252C5BF.4060406@oracle.com> Message-ID: <5252EB09.2090103@oracle.com> On 7.10.2013 16:31, Dmitry Samersoff wrote: > Jarsolav, > > Looks good for me, comments below is just a nits - so fill free to > ignore it. > > 1. > As FS.getPath(TEST_JDK, "jre", "lib", LIBARCH) is the only value for > findLibjvm parameter, It's better to create an overload function > findLibjvm(). > > 2. > it's better to check for File.isFile() - readable (e.g. device) is not > always what you whant here. > > 3. It's good to try > ARCH/libjvm.so, ARCH/server/libjvm.so, ARCH/client/libjvm.so > in order for the possible platforms with the only vm Nits not ignored - http://cr.openjdk.java.net/~jbachorik/8004926/webrev.04/ :) -JB- > > -Dmitry > > > On 2013-10-07 18:14, Jaroslav Bachorik wrote: >> On 19.9.2013 16:33, Jaroslav Bachorik wrote: >>> The updated webrev: >>> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.03 >>> >>> I've moved some of the functionality to the testlibrary. >>> >>> -JB - >>> >>> On 12.9.2013 17:31, Jaroslav Bachorik wrote: >>>> On 09/12/2013 05:13 PM, Dmitry Samersoff wrote: >>>>> Jaroslav, >>>>> >>>>> CustomLauncherTest.java: >>>>> >>>>> 102: this check could be moved to switch at ll. 108 >>>>> otherwise test fails on "sunos" and "linux" because PLATFORM remains >>>>> unset. >>>> Good idea. Thanks. >>>> >>>>> 129: I would prefer don't have pattern like this one ever in shell >>>>> script. Could you prepare a list of VM's to check and just loop over >>>>> it? >>>>> It makes test better readable. Also I think nowdays we can always use >>>>> server VM. >>>> I tried to mirror the original shell test as closely as possible. It >>>> would be nice if we could rely on the "server" vm only. Definitely more >>>> readable. >>>> >>>> -JB- >>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2013-09-12 18:17, Jaroslav Bachorik wrote: >>>>>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: >>>>>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote: >>>>>>>> On 09/12/2013 04:45 AM, David Holmes wrote: >>>>>>>>> Hi Jaroslav, >>>>>>>>> >>>>>>>>> You need a copyright notice in the new file. >>>>>>>>> >>>>>>>>> As written this test can only run on a full JDK - so please add >>>>>>>>> it to >>>>>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to >>>>>>>>> come >>>>>>>>> from the test-jdk? And use the VMOPTS passed to the test?) >>>>>>>>> >>>>>>>>> Is there a reason this test can't run on OSX? I know it would need >>>>>>>>> further modification but was wondering if there is something >>>>>>>>> inherent in >>>>>>>>> the test that makes it inapplicable to OSX. >>>>>>>>> >>>>>>>>> I think the test would be a lot simpler if the jdk tests had the >>>>>>>>> hotspot >>>>>>>>> test library's process tools available. :( >>>>>>>> We have some, is there an obvious gap? >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ >>>>>>>> >>>>>>>> >>>>>>> Hm, thanks for the info. I should have used this library instead. >>>>>>> >>>>>>> Please, stand by for the updated webrev. >>>>>> I was able to get rid off the JCMD. Using the testlibrary the target >>>>>> application can recognize its own PID and print it to its stdout. The >>>>>> main application then just reads the stdout to parse the PID. No need >>>>>> for JCMD any more. >>>>>> >>>>>> I could not find a way to remove the dependency on "test.jdk" system >>>>>> property. According to the jtreg web documentation >>>>>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a >>>>>> "test.java" >>>>>> system property should be available but in fact is not. But it seems >>>>>> that the testlibrary uses "test.jdk" system property too. >>>>>> >>>>>> The test does not run on OSX because nobody built the launcher >>>>>> binary :) >>>>>> I think it is a kind of DIY so I took the liberty of adding a >>>>>> linux-amd64 launcher while working on the test. >>>>>> >>>>>> While working with the test library I realized I was missing a crucial >>>>>> feature (at least for my purposes) - waiting for a certain message to >>>>>> appear in the stdout/stderr of the launched process. Very often I need >>>>>> to wait for the target process to get to certain point before the test >>>>>> can be allowed to continue - and the point is indicated by a >>>>>> message in >>>>>> stdout/stderr. Currently all the proc tools are designed to work in >>>>>> "batch" mode - the whole stdout/stderr is captured in strings and >>>>>> analyzed after the target process died - and are not suitable for this >>>>>> kind of usage. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 >>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> >>>>>>>> -Chris. >>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>>>>>>>> Please, review the patch for an intermittently failing test. >>>>>>>>>> >>>>>>>>>> The test is a shell test, using files for the interprocess >>>>>>>>>> synchronization. This leads to intermittent failures. >>>>>>>>>> >>>>>>>>>> In order to fix this the test is rewritten in Java - the original >>>>>>>>>> functionality and outputs should be 100% preserved. The patch is >>>>>>>>>> unfortunately a bit difficult to follow since there is no >>>>>>>>>> similarity >>>>>>>>>> between the *.sh and *.java file so one needs to go through the >>>>>>>>>> new >>>>>>>>>> source in whole. >>>>>>>>>> >>>>>>>>>> The changes in "launcher" files are all about adding >>>>>>>>>> permissions to >>>>>>>>>> execute (0755) and as such the webrev shows no differences. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Issue : JDK-8004926 >>>>>>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>>> >>>>> >>> >> > > From dmitry.samersoff at oracle.com Mon Oct 7 10:12:23 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 07 Oct 2013 21:12:23 +0400 Subject: jmx-dev [ping][ping] Re: RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <5252EB09.2090103@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> <5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com> <5231DE69.7090309@oracle.com> <523B0B30.4020003@oracle.com> <5252C1B6.2060904@oracle.com> <5252C5BF.4060406@oracle.com> <5252EB09.2090103@oracle.com> Message-ID: <5252EB77.8090702@oracle.com> Jaroslav, Thumbs up! Thank you for addressing my comments. -Dmitry On 2013-10-07 21:10, Jaroslav Bachorik wrote: > On 7.10.2013 16:31, Dmitry Samersoff wrote: >> Jarsolav, >> >> Looks good for me, comments below is just a nits - so fill free to >> ignore it. >> >> 1. >> As FS.getPath(TEST_JDK, "jre", "lib", LIBARCH) is the only value for >> findLibjvm parameter, It's better to create an overload function >> findLibjvm(). >> >> 2. >> it's better to check for File.isFile() - readable (e.g. device) is not >> always what you whant here. >> >> 3. It's good to try >> ARCH/libjvm.so, ARCH/server/libjvm.so, ARCH/client/libjvm.so >> in order for the possible platforms with the only vm > > Nits not ignored - > http://cr.openjdk.java.net/~jbachorik/8004926/webrev.04/ :) > > -JB- > >> >> -Dmitry >> >> >> On 2013-10-07 18:14, Jaroslav Bachorik wrote: >>> On 19.9.2013 16:33, Jaroslav Bachorik wrote: >>>> The updated webrev: >>>> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.03 >>>> >>>> I've moved some of the functionality to the testlibrary. >>>> >>>> -JB - >>>> >>>> On 12.9.2013 17:31, Jaroslav Bachorik wrote: >>>>> On 09/12/2013 05:13 PM, Dmitry Samersoff wrote: >>>>>> Jaroslav, >>>>>> >>>>>> CustomLauncherTest.java: >>>>>> >>>>>> 102: this check could be moved to switch at ll. 108 >>>>>> otherwise test fails on "sunos" and "linux" because PLATFORM remains >>>>>> unset. >>>>> Good idea. Thanks. >>>>> >>>>>> 129: I would prefer don't have pattern like this one ever in shell >>>>>> script. Could you prepare a list of VM's to check and just loop over >>>>>> it? >>>>>> It makes test better readable. Also I think nowdays we can always use >>>>>> server VM. >>>>> I tried to mirror the original shell test as closely as possible. It >>>>> would be nice if we could rely on the "server" vm only. Definitely >>>>> more >>>>> readable. >>>>> >>>>> -JB- >>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2013-09-12 18:17, Jaroslav Bachorik wrote: >>>>>>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: >>>>>>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote: >>>>>>>>> On 09/12/2013 04:45 AM, David Holmes wrote: >>>>>>>>>> Hi Jaroslav, >>>>>>>>>> >>>>>>>>>> You need a copyright notice in the new file. >>>>>>>>>> >>>>>>>>>> As written this test can only run on a full JDK - so please add >>>>>>>>>> it to >>>>>>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to >>>>>>>>>> come >>>>>>>>>> from the test-jdk? And use the VMOPTS passed to the test?) >>>>>>>>>> >>>>>>>>>> Is there a reason this test can't run on OSX? I know it would >>>>>>>>>> need >>>>>>>>>> further modification but was wondering if there is something >>>>>>>>>> inherent in >>>>>>>>>> the test that makes it inapplicable to OSX. >>>>>>>>>> >>>>>>>>>> I think the test would be a lot simpler if the jdk tests had the >>>>>>>>>> hotspot >>>>>>>>>> test library's process tools available. :( >>>>>>>>> We have some, is there an obvious gap? >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Hm, thanks for the info. I should have used this library instead. >>>>>>>> >>>>>>>> Please, stand by for the updated webrev. >>>>>>> I was able to get rid off the JCMD. Using the testlibrary the target >>>>>>> application can recognize its own PID and print it to its stdout. >>>>>>> The >>>>>>> main application then just reads the stdout to parse the PID. No >>>>>>> need >>>>>>> for JCMD any more. >>>>>>> >>>>>>> I could not find a way to remove the dependency on "test.jdk" system >>>>>>> property. According to the jtreg web documentation >>>>>>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a >>>>>>> "test.java" >>>>>>> system property should be available but in fact is not. But it seems >>>>>>> that the testlibrary uses "test.jdk" system property too. >>>>>>> >>>>>>> The test does not run on OSX because nobody built the launcher >>>>>>> binary :) >>>>>>> I think it is a kind of DIY so I took the liberty of adding a >>>>>>> linux-amd64 launcher while working on the test. >>>>>>> >>>>>>> While working with the test library I realized I was missing a >>>>>>> crucial >>>>>>> feature (at least for my purposes) - waiting for a certain >>>>>>> message to >>>>>>> appear in the stdout/stderr of the launched process. Very often I >>>>>>> need >>>>>>> to wait for the target process to get to certain point before the >>>>>>> test >>>>>>> can be allowed to continue - and the point is indicated by a >>>>>>> message in >>>>>>> stdout/stderr. Currently all the proc tools are designed to work in >>>>>>> "batch" mode - the whole stdout/stderr is captured in strings and >>>>>>> analyzed after the target process died - and are not suitable for >>>>>>> this >>>>>>> kind of usage. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 >>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>>> >>>>>>>>> -Chris. >>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>>>>>>>>> Please, review the patch for an intermittently failing test. >>>>>>>>>>> >>>>>>>>>>> The test is a shell test, using files for the interprocess >>>>>>>>>>> synchronization. This leads to intermittent failures. >>>>>>>>>>> >>>>>>>>>>> In order to fix this the test is rewritten in Java - the >>>>>>>>>>> original >>>>>>>>>>> functionality and outputs should be 100% preserved. The patch is >>>>>>>>>>> unfortunately a bit difficult to follow since there is no >>>>>>>>>>> similarity >>>>>>>>>>> between the *.sh and *.java file so one needs to go through the >>>>>>>>>>> new >>>>>>>>>>> source in whole. >>>>>>>>>>> >>>>>>>>>>> The changes in "launcher" files are all about adding >>>>>>>>>>> permissions to >>>>>>>>>>> execute (0755) and as such the webrev shows no differences. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Issue : JDK-8004926 >>>>>>>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>> >>>> >>> >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From henry.jen at oracle.com Mon Oct 7 11:32:58 2013 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Mon, 07 Oct 2013 18:32:58 +0000 Subject: hg: jdk8/tl/jdk: 8025968: Integrate test improvements made in lambda repo Message-ID: <20131007183325.BD04D62E0B@hg.openjdk.java.net> Changeset: f0ad3e2918b4 Author: henryjen Date: 2013-10-07 11:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f0ad3e2918b4 8025968: Integrate test improvements made in lambda repo Reviewed-by: psandoz ! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ExplodeOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java From karen.kinnear at oracle.com Mon Oct 7 13:33:37 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Mon, 07 Oct 2013 20:33:37 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8009130: Lambda: Fix access controls, loader constraints. Message-ID: <20131007203343.879CA62E15@hg.openjdk.java.net> Changeset: ac9cb1d5a202 Author: acorn Date: 2013-10-07 12:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ac9cb1d5a202 8009130: Lambda: Fix access controls, loader constraints. Summary: New default methods list with inherited superinterface methods Reviewed-by: minqi, sspitsyn, coleenp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/reflectionUtils.cpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/vmStructs.cpp From joe.darcy at oracle.com Mon Oct 7 15:02:15 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Mon, 07 Oct 2013 15:02:15 -0700 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <5251C216.105@oracle.com> References: <5251C216.105@oracle.com> Message-ID: <52532F67.4070408@oracle.com> Hello, I skimmed the patch and it looked fine. More generally, we want every package and top-level class in the com.sun.* namespace to be either explicitly exported or not. Cheers, -Joe On 10/6/2013 1:03 PM, Alan Bateman wrote: > > As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported, > I'd like to have another attempt at adding the annotation to a number > of JDK specific APIs that are long standing exported, documented and > supported APIs. Specifically, the following APIs: > > - Java Debug Interface (com.sun.jdi) > - Attach API (com.sun.tools.attach) > - SCTP API (com.sun.nio.sctp) > - HTTP server API (com.sun.net.httpserver) > - Management extensions (com.sun.management) > - JConsole Plugin API (com.sun.tools.jconsole) > - JDK-specific API to JAAS (com.sun.security.auth) > - JDK-specific JGSS API (com.sun.security.jgss) > > (The javadoc for each of these APIs is currently generated in the build) > > The webrev with the proposed update is here: > http://cr.openjdk.java.net/~alanb/8008662/webrev.02/ > > As per the original webrev, I've added package-info.java to a number > of packages that didn't have any description. In a few cases, I've had > to rename the legacy package.html to package-info.java. > > For the review then the intention is that @jdk.Exported be added to > the package-info and all public/protected types in these APIs. The > only exceptions are two cases where I've added @jdk.Exported(false), > specifically: > > - com.sun.management.OSMBeanFactory as it clearly documents to stay away > - com.sun.security.auth.callback.DialogCallbackHandler as it for the > chop (see JEP 162) > > Thanks, > > Alan. From henry.jen at oracle.com Mon Oct 7 16:50:27 2013 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Mon, 07 Oct 2013 23:50:27 +0000 Subject: hg: jdk8/tl/jdk: 8026009: Changes for 8025968 break all stream tests Message-ID: <20131007235048.ABE8762E19@hg.openjdk.java.net> Changeset: 0cffe1dab0bf Author: henryjen Date: 2013-10-07 15:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0cffe1dab0bf 8026009: Changes for 8025968 break all stream tests Reviewed-by: mduigou ! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java From joe.darcy at oracle.com Mon Oct 7 16:52:13 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 07 Oct 2013 23:52:13 +0000 Subject: hg: jdk8/tl/langtools: 8026017: Make history of AnnotatedConstruct methods in jx.l.m.e.Element clearer Message-ID: <20131007235219.1698962E1A@hg.openjdk.java.net> Changeset: 4dd7ffbf01fb Author: darcy Date: 2013-10-07 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4dd7ffbf01fb 8026017: Make history of AnnotatedConstruct methods in jx.l.m.e.Element clearer Reviewed-by: jjg ! src/share/classes/javax/lang/model/element/Element.java From xuelei.fan at oracle.com Mon Oct 7 18:47:30 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Tue, 08 Oct 2013 01:47:30 +0000 Subject: hg: jdk8/tl/jdk: 6956398: make ephemeral DH key match the length of the certificate key Message-ID: <20131008014817.94FEF62E1D@hg.openjdk.java.net> Changeset: 0d5f4f1782e8 Author: xuelei Date: 2013-10-07 18:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0d5f4f1782e8 6956398: make ephemeral DH key match the length of the certificate key Reviewed-by: weijun ! src/share/classes/sun/security/ssl/ServerHandshaker.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/DHKeyExchange/DHEKeySizing.java From david.holmes at oracle.com Mon Oct 7 20:42:46 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 Oct 2013 13:42:46 +1000 Subject: [ping][ping] Re: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <5252C1B6.2060904@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> <5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com> <5231DE69.7090309@oracle.com> <523B0B30.4020003@oracle.com> <5252C1B6.2060904@oracle.com> Message-ID: <52537F36.8020001@oracle.com> Jaroslav, Can you summarise the changes please? With the conversion to Java and the infrastructure additions I can't tell what is actually fixing the original timeout issue :) Thanks, David On 8/10/2013 12:14 AM, Jaroslav Bachorik wrote: > On 19.9.2013 16:33, Jaroslav Bachorik wrote: >> The updated webrev: >> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.03 >> >> I've moved some of the functionality to the testlibrary. >> >> -JB - >> >> On 12.9.2013 17:31, Jaroslav Bachorik wrote: >>> On 09/12/2013 05:13 PM, Dmitry Samersoff wrote: >>>> Jaroslav, >>>> >>>> CustomLauncherTest.java: >>>> >>>> 102: this check could be moved to switch at ll. 108 >>>> otherwise test fails on "sunos" and "linux" because PLATFORM remains >>>> unset. >>> Good idea. Thanks. >>> >>>> 129: I would prefer don't have pattern like this one ever in shell >>>> script. Could you prepare a list of VM's to check and just loop over >>>> it? >>>> It makes test better readable. Also I think nowdays we can always use >>>> server VM. >>> I tried to mirror the original shell test as closely as possible. It >>> would be nice if we could rely on the "server" vm only. Definitely more >>> readable. >>> >>> -JB- >>> >>>> -Dmitry >>>> >>>> >>>> On 2013-09-12 18:17, Jaroslav Bachorik wrote: >>>>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: >>>>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote: >>>>>>> On 09/12/2013 04:45 AM, David Holmes wrote: >>>>>>>> Hi Jaroslav, >>>>>>>> >>>>>>>> You need a copyright notice in the new file. >>>>>>>> >>>>>>>> As written this test can only run on a full JDK - so please add >>>>>>>> it to >>>>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to >>>>>>>> come >>>>>>>> from the test-jdk? And use the VMOPTS passed to the test?) >>>>>>>> >>>>>>>> Is there a reason this test can't run on OSX? I know it would need >>>>>>>> further modification but was wondering if there is something >>>>>>>> inherent in >>>>>>>> the test that makes it inapplicable to OSX. >>>>>>>> >>>>>>>> I think the test would be a lot simpler if the jdk tests had the >>>>>>>> hotspot >>>>>>>> test library's process tools available. :( >>>>>>> We have some, is there an obvious gap? >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ >>>>>>> >>>>>>> >>>>>> Hm, thanks for the info. I should have used this library instead. >>>>>> >>>>>> Please, stand by for the updated webrev. >>>>> I was able to get rid off the JCMD. Using the testlibrary the target >>>>> application can recognize its own PID and print it to its stdout. The >>>>> main application then just reads the stdout to parse the PID. No need >>>>> for JCMD any more. >>>>> >>>>> I could not find a way to remove the dependency on "test.jdk" system >>>>> property. According to the jtreg web documentation >>>>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a >>>>> "test.java" >>>>> system property should be available but in fact is not. But it seems >>>>> that the testlibrary uses "test.jdk" system property too. >>>>> >>>>> The test does not run on OSX because nobody built the launcher >>>>> binary :) >>>>> I think it is a kind of DIY so I took the liberty of adding a >>>>> linux-amd64 launcher while working on the test. >>>>> >>>>> While working with the test library I realized I was missing a crucial >>>>> feature (at least for my purposes) - waiting for a certain message to >>>>> appear in the stdout/stderr of the launched process. Very often I need >>>>> to wait for the target process to get to certain point before the test >>>>> can be allowed to continue - and the point is indicated by a >>>>> message in >>>>> stdout/stderr. Currently all the proc tools are designed to work in >>>>> "batch" mode - the whole stdout/stderr is captured in strings and >>>>> analyzed after the target process died - and are not suitable for this >>>>> kind of usage. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 >>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>>>>>>> Please, review the patch for an intermittently failing test. >>>>>>>>> >>>>>>>>> The test is a shell test, using files for the interprocess >>>>>>>>> synchronization. This leads to intermittent failures. >>>>>>>>> >>>>>>>>> In order to fix this the test is rewritten in Java - the original >>>>>>>>> functionality and outputs should be 100% preserved. The patch is >>>>>>>>> unfortunately a bit difficult to follow since there is no >>>>>>>>> similarity >>>>>>>>> between the *.sh and *.java file so one needs to go through the >>>>>>>>> new >>>>>>>>> source in whole. >>>>>>>>> >>>>>>>>> The changes in "launcher" files are all about adding >>>>>>>>> permissions to >>>>>>>>> execute (0755) and as such the webrev shows no differences. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Issue : JDK-8004926 >>>>>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>> >> > From david.holmes at oracle.com Mon Oct 7 23:16:13 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 Oct 2013 16:16:13 +1000 Subject: RFR (S) JDK-8025700: RuntimeMXBean.getInputArguments() should include -server/-client/-d32/-d64 In-Reply-To: <524D73C4.7060004@oracle.com> References: <524D73C4.7060004@oracle.com> Message-ID: <5253A32D.40502@oracle.com> As I wrote in the bug report I have reservations about this as these are launcher options not VM options. Plus with the dropping of 32-bit Solaris the -d32/-d64 part will be moot. That leaves the VM "mode" - client, server, minimal or whatever might happened to be defined via jvm.cfg (-server might actually run client VM). David On 3/10/2013 11:40 PM, Aleksey Shipilev wrote: > Hi, > > Please take a look at the potential fix for: > https://bugs.openjdk.java.net/browse/JDK-8025700 > > The webrev is here: > http://cr.openjdk.java.net/~shade/8025700/webrev.01/ > > Rationale: when doing the Java tools which need to replicate the VM > launch, e.g. fork the JVM with the same set of command line options, we > need the exact command line. Otherwise we miss the significant part of > configuration, which confuses people. So far we miss "-server", > "-client", "-d32", and "-d64" options from there. I have seen troubles > with jmh and jcstress stemming from this very issue. > > Testing: > - new jtreg test, works fine on Linux x86_64; (I can run other > platforms as long as the fix approach is sound) > - jdk/test/tools/launcher jtreg tests on Linux x86_64 > > Thanks, > -Aleksey > From david.holmes at oracle.com Tue Oct 8 00:34:46 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 Oct 2013 17:34:46 +1000 Subject: RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <524BDD9E.1050100@oracle.com> References: <524BDD9E.1050100@oracle.com> Message-ID: <5253B596.1000206@oracle.com> Jaroslav, On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: > Hello, > > currently the JVM uptime reported by the RuntimeMXBean is based on > System.currentTimeMillis() which makes it susceptible to changes of the > OS time (eg. changing timezone, NTP synchronization etc.). The uptime > should not depend on the system time and should be calculated using a > monotonic clock source. > > There is already the way to get the actual JVM uptime in ticks. It is > accessible as Management::timestamp() and the ticks are convertible to > milliseconds using Management::ticks_to_ms(ts_ticks) thus making it very > easy to switch to the monotonic clock based uptime. Maybe I'm missing something but TiumeStamp updates using os::elapsed_counter() which on Linux uses gettimeofday so is not a monotonic clock source. David ----- > The patch consists of the hotspot and jdk parts. > > For the hotspot a new constant needs to be introduced in > src/share/vm/services/jmm.h and the actual logic to obtain the uptime in > milliseconds is added in src/share/vm/services/management.cpp. > > For the jdk the changes comprise of adding the necessary JNI bridging > methods in order to get the new uptime, introducing the same constant > that is used in hotspot and changes to mapfile-vers files in order to > properly build the native library. > > Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 > Webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 > > Thanks, > > -JB- From stefan.karlsson at oracle.com Tue Oct 8 01:58:19 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 08 Oct 2013 10:58:19 +0200 Subject: Review request: 8025996: Track metaspace usage when metaspace is expanded Message-ID: <5253C92B.1030404@oracle.com> http://cr.openjdk.java.net/~stefank/8025996/webrev.00 Previously, the Metaspace memory usage was only tracked at the end of the GCs. This causes the MemoryPoolMXBean.getUsageThreshold(?) functionality to fail for the Metaspace memory pools. This patch adds tracking of Metaspace usage when a new Metachunk is fetched. This patch builds upon the patch in: http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-October/011166.html Review request: 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces This patch has been tested with the fix for: https://bugs.openjdk.java.net/browse/JDK-7196801 NPG: Fix java/lang/management/MemoryMXBean/LowMemoryTest2 The fix for 7196801 will be done in a separate review request since the test is located in jdk repository and the fix for 8025996 is done in the hotspot repository. thanks, StefanK From david.holmes at oracle.com Tue Oct 8 02:34:52 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 08 Oct 2013 09:34:52 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8026025: JVM_GetCallerClass allows Reflection.getCallerClass(int depth) to use Message-ID: <20131008093543.CF38762E22@hg.openjdk.java.net> Changeset: 615d83933195 Author: dholmes Date: 2013-10-08 02:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/615d83933195 8026025: JVM_GetCallerClass allows Reflection.getCallerClass(int depth) to use Reviewed-by: alanb, dholmes, twisti Contributed-by: mandy.chung at oracle.com ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h From paul.sandoz at oracle.com Tue Oct 8 02:49:05 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 08 Oct 2013 09:49:05 +0000 Subject: hg: jdk8/tl/jdk: 8025136: SplittableRandom enchancements Message-ID: <20131008095033.9061F62E23@hg.openjdk.java.net> Changeset: b90dcd1a71bf Author: psandoz Date: 2013-10-08 11:17 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b90dcd1a71bf 8025136: SplittableRandom enchancements Reviewed-by: psandoz, martin Contributed-by: Doug Lea
, Guy Steele ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/SplittableRandom.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java From alan.bateman at oracle.com Tue Oct 8 04:13:29 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 08 Oct 2013 11:13:29 +0000 Subject: hg: jdk8/tl/jdk: 8024788: (fs) Files.readAllBytes uses FileChannel which may not be supported by all providers Message-ID: <20131008111357.0B8C962E2C@hg.openjdk.java.net> Changeset: 95bb56c61276 Author: alanb Date: 2013-10-08 10:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/95bb56c61276 8024788: (fs) Files.readAllBytes uses FileChannel which may not be supported by all providers Reviewed-by: chegar ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/BytesAndLines.java From jaroslav.bachorik at oracle.com Tue Oct 8 04:33:41 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 08 Oct 2013 13:33:41 +0200 Subject: [ping][ping] Re: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <52537F36.8020001@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> <5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com> <5231DE69.7090309@oracle.com> <523B0B30.4020003@oracle.com> <5252C1B6.2060904@oracle.com> <52537F36.8020001@oracle.com> Message-ID: <5253ED95.20706@oracle.com> On 8.10.2013 05:42, David Holmes wrote: > Jaroslav, > > Can you summarise the changes please? With the conversion to Java and > the infrastructure additions I can't tell what is actually fixing the > original timeout issue :) The timeout was most caused by using the same file for communication between java processes in more test cases. When those test cases were run in parallel the file got rewritten silently and some of the tests could end up trying to connect to incorrect port in the target application. I was able to reproduce the timeout by interleaving the test runs for CustomLauncherTest.sh and LocalManagementTest.sh and adding an artificial delay to CusteomLauncherTest.sh to allow LocalManagementTest.sh to change the port in the file. While it could be fixed by using a different file for each test case I took the liberty of converting the shell tests to java tests. This allows me to remove the communication file and, in the end, make the tests more robust. CustomLauncherTest.java and LocalManagementTest.java are the tests converted from shell to java. I decided to convert LocalManagementTest.sh as well because it has the same problems as the CustomLauncherTest.sh. The changes in the testlibrary are about introducing new methods allowing the tests easily start a process and wait for a certain text appearing in its stdout/stderr. Using these methods the caller can wait till the callee is fully initialized and eg. ready to accept connections. The changes in launchers make the launchers actually executable + I am adding a linux-amd64 launcher (I needed that one to work on the changes locally and thought it might be nice to have one more platform covered by the test). I've update the webrev to include changes to LocalManagementTest and TEST.groups (both of those tests require JDK) - http://cr.openjdk.java.net/~jbachorik/8004926/webrev.05 -JB- > > Thanks, > David > > On 8/10/2013 12:14 AM, Jaroslav Bachorik wrote: >> On 19.9.2013 16:33, Jaroslav Bachorik wrote: >>> The updated webrev: >>> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.03 >>> >>> I've moved some of the functionality to the testlibrary. >>> >>> -JB - >>> >>> On 12.9.2013 17:31, Jaroslav Bachorik wrote: >>>> On 09/12/2013 05:13 PM, Dmitry Samersoff wrote: >>>>> Jaroslav, >>>>> >>>>> CustomLauncherTest.java: >>>>> >>>>> 102: this check could be moved to switch at ll. 108 >>>>> otherwise test fails on "sunos" and "linux" because PLATFORM remains >>>>> unset. >>>> Good idea. Thanks. >>>> >>>>> 129: I would prefer don't have pattern like this one ever in shell >>>>> script. Could you prepare a list of VM's to check and just loop over >>>>> it? >>>>> It makes test better readable. Also I think nowdays we can always use >>>>> server VM. >>>> I tried to mirror the original shell test as closely as possible. It >>>> would be nice if we could rely on the "server" vm only. Definitely more >>>> readable. >>>> >>>> -JB- >>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2013-09-12 18:17, Jaroslav Bachorik wrote: >>>>>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: >>>>>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote: >>>>>>>> On 09/12/2013 04:45 AM, David Holmes wrote: >>>>>>>>> Hi Jaroslav, >>>>>>>>> >>>>>>>>> You need a copyright notice in the new file. >>>>>>>>> >>>>>>>>> As written this test can only run on a full JDK - so please add >>>>>>>>> it to >>>>>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to >>>>>>>>> come >>>>>>>>> from the test-jdk? And use the VMOPTS passed to the test?) >>>>>>>>> >>>>>>>>> Is there a reason this test can't run on OSX? I know it would need >>>>>>>>> further modification but was wondering if there is something >>>>>>>>> inherent in >>>>>>>>> the test that makes it inapplicable to OSX. >>>>>>>>> >>>>>>>>> I think the test would be a lot simpler if the jdk tests had the >>>>>>>>> hotspot >>>>>>>>> test library's process tools available. :( >>>>>>>> We have some, is there an obvious gap? >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Hm, thanks for the info. I should have used this library instead. >>>>>>> >>>>>>> Please, stand by for the updated webrev. >>>>>> I was able to get rid off the JCMD. Using the testlibrary the target >>>>>> application can recognize its own PID and print it to its stdout. The >>>>>> main application then just reads the stdout to parse the PID. No need >>>>>> for JCMD any more. >>>>>> >>>>>> I could not find a way to remove the dependency on "test.jdk" system >>>>>> property. According to the jtreg web documentation >>>>>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a >>>>>> "test.java" >>>>>> system property should be available but in fact is not. But it seems >>>>>> that the testlibrary uses "test.jdk" system property too. >>>>>> >>>>>> The test does not run on OSX because nobody built the launcher >>>>>> binary :) >>>>>> I think it is a kind of DIY so I took the liberty of adding a >>>>>> linux-amd64 launcher while working on the test. >>>>>> >>>>>> While working with the test library I realized I was missing a >>>>>> crucial >>>>>> feature (at least for my purposes) - waiting for a certain message to >>>>>> appear in the stdout/stderr of the launched process. Very often I >>>>>> need >>>>>> to wait for the target process to get to certain point before the >>>>>> test >>>>>> can be allowed to continue - and the point is indicated by a >>>>>> message in >>>>>> stdout/stderr. Currently all the proc tools are designed to work in >>>>>> "batch" mode - the whole stdout/stderr is captured in strings and >>>>>> analyzed after the target process died - and are not suitable for >>>>>> this >>>>>> kind of usage. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 >>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> >>>>>>>> -Chris. >>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>>>>>>>> Please, review the patch for an intermittently failing test. >>>>>>>>>> >>>>>>>>>> The test is a shell test, using files for the interprocess >>>>>>>>>> synchronization. This leads to intermittent failures. >>>>>>>>>> >>>>>>>>>> In order to fix this the test is rewritten in Java - the original >>>>>>>>>> functionality and outputs should be 100% preserved. The patch is >>>>>>>>>> unfortunately a bit difficult to follow since there is no >>>>>>>>>> similarity >>>>>>>>>> between the *.sh and *.java file so one needs to go through the >>>>>>>>>> new >>>>>>>>>> source in whole. >>>>>>>>>> >>>>>>>>>> The changes in "launcher" files are all about adding >>>>>>>>>> permissions to >>>>>>>>>> execute (0755) and as such the webrev shows no differences. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Issue : JDK-8004926 >>>>>>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>>> >>>>> >>> >> From kevin.walls at oracle.com Tue Oct 8 04:23:51 2013 From: kevin.walls at oracle.com (kevin.walls at oracle.com) Date: Tue, 08 Oct 2013 11:23:51 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20131008112359.C9EF862E30@hg.openjdk.java.net> Changeset: c90e76575b03 Author: kevinw Date: 2013-10-08 09:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c90e76575b03 8019375: Internal symbol table size should be tunable. Reviewed-by: coleenp, kamg ! agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: ced68a57cdbd Author: kevinw Date: 2013-10-08 11:37 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ced68a57cdbd Merge From staffan.larsen at oracle.com Tue Oct 8 05:06:53 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 8 Oct 2013 14:06:53 +0200 Subject: RFR (S): 8025427 jstat tests fails on 32-bit platforms In-Reply-To: References: <7483E09E-5283-412F-BEA3-F7CC015A67DC@oracle.com> Message-ID: Pinging again: Please, pretty please? :) /Staffan On 1 okt 2013, at 20:46, Staffan Larsen wrote: > Any Reviewer who can take a look? > > Thanks, > /Staffan > > On 27 sep 2013, at 23:59, Staffan Larsen wrote: > >> This change makes jstat output '-' instead of '\ufffd' when the result of a calculation is NaN. '\ufffd' is typically not displayable in a terminal. >> >> This change also updates the tests to allow '-' as the output int the CCS (Compressed Class Space Space - Percent Used) column from -gcutil and -gccause. It can be hard to see from the diff but what I have done is change the regexp for that column from: >> >> [0-9]+\.[0-9]+ >> >> to: >> >> ([0-9]+\.[0-9]+)|- >> >> Testing: Passes tests locally, currently running JPRT. >> >> webrev: http://cr.openjdk.java.net/~sla/8025427/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8025427 >> >> Thanks, >> /Staffan > From jaroslav.bachorik at oracle.com Tue Oct 8 05:36:36 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 08 Oct 2013 14:36:36 +0200 Subject: RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <5253B596.1000206@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> Message-ID: <5253FC54.4010407@oracle.com> On 8.10.2013 09:34, David Holmes wrote: > Jaroslav, > > On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >> Hello, >> >> currently the JVM uptime reported by the RuntimeMXBean is based on >> System.currentTimeMillis() which makes it susceptible to changes of the >> OS time (eg. changing timezone, NTP synchronization etc.). The uptime >> should not depend on the system time and should be calculated using a >> monotonic clock source. >> >> There is already the way to get the actual JVM uptime in ticks. It is >> accessible as Management::timestamp() and the ticks are convertible to >> milliseconds using Management::ticks_to_ms(ts_ticks) thus making it very >> easy to switch to the monotonic clock based uptime. > > Maybe I'm missing something but TiumeStamp updates using > os::elapsed_counter() which on Linux uses gettimeofday so is not a > monotonic clock source. Hm, yes. I wasn't aware of this linux/bsd specific. Is there any reason why a non monotonic clock source is used for timestamping except of the historical one? os::javaTimeNanos() uses montonic clock when available - why can't be the same used for os::elapsed_counter() especially when a counter based on "gettimeofday" is not really a counter? -JB- > > David > ----- > > > >> The patch consists of the hotspot and jdk parts. >> >> For the hotspot a new constant needs to be introduced in >> src/share/vm/services/jmm.h and the actual logic to obtain the uptime in >> milliseconds is added in src/share/vm/services/management.cpp. >> >> For the jdk the changes comprise of adding the necessary JNI bridging >> methods in order to get the new uptime, introducing the same constant >> that is used in hotspot and changes to mapfile-vers files in order to >> properly build the native library. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >> Webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >> >> Thanks, >> >> -JB- From aleksey.shipilev at oracle.com Tue Oct 8 07:39:33 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 08 Oct 2013 18:39:33 +0400 Subject: RFR (S) JDK-8025700: RuntimeMXBean.getInputArguments() should include -server/-client/-d32/-d64 In-Reply-To: <5253A32D.40502@oracle.com> References: <524D73C4.7060004@oracle.com> <5253A32D.40502@oracle.com> Message-ID: <52541925.5030907@oracle.com> Yes, I can see that reasoning. I have the opposite perspective though: I think it is the matter of user experience, RuntimeMXBean should not care about the launcher/VM distinction, since what user "perceives" is the JVM launched via "java". Segregating the launcher and "pure" VM options seems to be exposing the implementation detail. Thus, this fix actually covers up that glitch. -Aleksey. On 10/08/2013 10:16 AM, David Holmes wrote: > As I wrote in the bug report I have reservations about this as these are > launcher options not VM options. Plus with the dropping of 32-bit > Solaris the -d32/-d64 part will be moot. That leaves the VM "mode" - > client, server, minimal or whatever might happened to be defined via > jvm.cfg (-server might actually run client VM). > > David > > On 3/10/2013 11:40 PM, Aleksey Shipilev wrote: >> Hi, >> >> Please take a look at the potential fix for: >> https://bugs.openjdk.java.net/browse/JDK-8025700 >> >> The webrev is here: >> http://cr.openjdk.java.net/~shade/8025700/webrev.01/ >> >> Rationale: when doing the Java tools which need to replicate the VM >> launch, e.g. fork the JVM with the same set of command line options, we >> need the exact command line. Otherwise we miss the significant part of >> configuration, which confuses people. So far we miss "-server", >> "-client", "-d32", and "-d64" options from there. I have seen troubles >> with jmh and jcstress stemming from this very issue. >> >> Testing: >> - new jtreg test, works fine on Linux x86_64; (I can run other >> platforms as long as the fix approach is sound) >> - jdk/test/tools/launcher jtreg tests on Linux x86_64 >> >> Thanks, >> -Aleksey >> From serguei.spitsyn at oracle.com Tue Oct 8 08:24:31 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 08 Oct 2013 08:24:31 -0700 Subject: RFR (S): 8025427 jstat tests fails on 32-bit platforms In-Reply-To: References: <7483E09E-5283-412F-BEA3-F7CC015A67DC@oracle.com> Message-ID: <525423AF.8030008@oracle.com> Looks good. Thanks, Serguei On 10/8/13 5:06 AM, Staffan Larsen wrote: > Pinging again: Please, pretty please? :) > > /Staffan > > On 1 okt 2013, at 20:46, Staffan Larsen wrote: > >> Any Reviewer who can take a look? >> >> Thanks, >> /Staffan >> >> On 27 sep 2013, at 23:59, Staffan Larsen wrote: >> >>> This change makes jstat output '-' instead of '\ufffd' when the result of a calculation is NaN. '\ufffd' is typically not displayable in a terminal. >>> >>> This change also updates the tests to allow '-' as the output int the CCS (Compressed Class Space Space - Percent Used) column from -gcutil and -gccause. It can be hard to see from the diff but what I have done is change the regexp for that column from: >>> >>> [0-9]+\.[0-9]+ >>> >>> to: >>> >>> ([0-9]+\.[0-9]+)|- >>> >>> Testing: Passes tests locally, currently running JPRT. >>> >>> webrev: http://cr.openjdk.java.net/~sla/8025427/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8025427 >>> >>> Thanks, >>> /Staffan From sundararajan.athijegannathan at oracle.com Tue Oct 8 08:26:34 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 08 Oct 2013 15:26:34 +0000 Subject: hg: jdk8/tl/nashorn: 6 new changesets Message-ID: <20131008152640.B367362E44@hg.openjdk.java.net> Changeset: 6345d08fd5de Author: hannesw Date: 2013-10-08 11:55 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/6345d08fd5de 8025213: Assignment marks variable as defined too early Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/nashorn/internal/codegen/Attr.java + test/script/basic/JDK-8025213.js + test/script/basic/JDK-8025213.js.EXPECTED Changeset: 8c326f8c6799 Author: sundar Date: 2013-10-08 13:02 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8c326f8c6799 8026033: Switch should load expression even when there are no cases in it Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8026033.js + test/script/basic/JDK-8026033.js.EXPECTED Changeset: 025e2ff9e91b Author: hannesw Date: 2013-10-08 13:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/025e2ff9e91b 8025965: Specialized functions with same weight replace each other in TreeSet Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/CompiledFunction.java Changeset: 19dba6637f20 Author: sundar Date: 2013-10-08 14:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/19dba6637f20 8026039: future strict names are allowed as function name and argument name of a strict function Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/error/JDK-8026039.js + test/script/error/JDK-8026039.js.EXPECTED Changeset: c9921761903b Author: hannesw Date: 2013-10-08 15:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c9921761903b 8026042: FoldConstants need to guard against ArrayLiteralNode Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/ir/LiteralNode.java + test/script/basic/JDK-8026042.js + test/script/basic/JDK-8026042.js.EXPECTED Changeset: 346ba5b8a488 Author: sundar Date: 2013-10-08 16:46 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/346ba5b8a488 8026048: Function constructor should convert arguments to String before performing any syntax checks Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/objects/NativeFunction.java + test/script/basic/JDK-8026048.js From michael.fang at oracle.com Tue Oct 8 09:44:00 2013 From: michael.fang at oracle.com (michael.fang at oracle.com) Date: Tue, 08 Oct 2013 16:44:00 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20131008164405.D673462E49@hg.openjdk.java.net> Changeset: dbecbb685503 Author: mfang Date: 2013-10-08 09:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/dbecbb685503 8025215: jdk8 l10n resource file translation update 4 Reviewed-by: joehw, yhuang ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_fr.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_it.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_pt_BR.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_TW.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_es.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_fr.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_it.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ko.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_pt_BR.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sv.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_TW.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_pt_BR.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sv.java ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_TW.properties ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_de.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_es.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_fr.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_it.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ja.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ko.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_pt_BR.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_sv.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_CN.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_TW.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_de.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_es.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_fr.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_it.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ja.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ko.java + src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_pt_BR.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_sv.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_zh_CN.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_zh_TW.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_es.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ja.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_pt_BR.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_sv.java Changeset: 1c074a0c2b97 Author: mfang Date: 2013-10-08 09:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/1c074a0c2b97 Merge From staffan.larsen at oracle.com Tue Oct 8 10:04:50 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 8 Oct 2013 19:04:50 +0200 Subject: RFR (S): 8025427 jstat tests fails on 32-bit platforms In-Reply-To: <525423AF.8030008@oracle.com> References: <7483E09E-5283-412F-BEA3-F7CC015A67DC@oracle.com> <525423AF.8030008@oracle.com> Message-ID: <35223AD7-3203-4308-B6C7-7D2258FE31CB@oracle.com> Thanks Serguei! Still need an official Reviewer. Thanks, /Staffan On 8 okt 2013, at 17:24, serguei.spitsyn at oracle.com wrote: > Looks good. > > Thanks, > Serguei > > On 10/8/13 5:06 AM, Staffan Larsen wrote: >> Pinging again: Please, pretty please? :) >> >> /Staffan >> >> On 1 okt 2013, at 20:46, Staffan Larsen wrote: >> >>> Any Reviewer who can take a look? >>> >>> Thanks, >>> /Staffan >>> >>> On 27 sep 2013, at 23:59, Staffan Larsen wrote: >>> >>>> This change makes jstat output '-' instead of '\ufffd' when the result of a calculation is NaN. '\ufffd' is typically not displayable in a terminal. >>>> >>>> This change also updates the tests to allow '-' as the output int the CCS (Compressed Class Space Space - Percent Used) column from -gcutil and -gccause. It can be hard to see from the diff but what I have done is change the regexp for that column from: >>>> >>>> [0-9]+\.[0-9]+ >>>> >>>> to: >>>> >>>> ([0-9]+\.[0-9]+)|- >>>> >>>> Testing: Passes tests locally, currently running JPRT. >>>> >>>> webrev: http://cr.openjdk.java.net/~sla/8025427/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8025427 >>>> >>>> Thanks, >>>> /Staffan > From aleksey.timofeev at oracle.com Tue Oct 8 15:14:56 2013 From: aleksey.timofeev at oracle.com (aleksey.timofeev at oracle.com) Date: Wed, 09 Oct 2013 02:14:56 +0400 Subject: Fix to 8025925 In-Reply-To: <92711177-AFA2-4719-8834-EEE40FA20B92@oracle.com> References: <5252C9DE.8030402@oracle.com> <5252D10E.7070405@oracle.com> <92711177-AFA2-4719-8834-EEE40FA20B92@oracle.com> Message-ID: <525483E0.7040506@oracle.com> Hello. I prepared a little fix to JDK-8025925 . Find webrev here please: http://cr.openjdk.java.net/~iignatyev/atimofeev/8025925/webrev.00/index.html (now it's on open server). Staffan Larsen generously agreed to sponsor this commit if we conclude everything is OK. Please your provide feedback. -- Best regards, Aleksey Timofeev. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131009/347deb58/attachment.html From coleen.phillimore at oracle.com Tue Oct 8 11:27:04 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 08 Oct 2013 14:27:04 -0400 Subject: RFR 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::,compare_entry_to and copy_entry_to Message-ID: <52544E78.9090103@oracle.com> Summary: Add missing cases. I verified this with the test for https://bugs.openjdk.java.net/browse/JDK-8022701 but don't want to copy the test into with modifications the hotspot repository, still working on refactoring the test for the JDK repository for after this gets pushed. open webrev at http://cr.openjdk.java.net/~coleenp/8025185/ bug link https://bugs.openjdk.java.net/browse/JDK-8025185 Thanks, Coleen From ivan.gerasimov at oracle.com Tue Oct 8 13:34:47 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 09 Oct 2013 00:34:47 +0400 Subject: RFR [8025886] typo in shell regtest == instead of = In-Reply-To: <52504CB4.9090103@oracle.com> References: <524D7AF6.2000705@oracle.com> <524EA7D1.7030908@oracle.com> <52500E4D.6020307@oracle.com> <52504CB4.9090103@oracle.com> Message-ID: <52546C67.7090904@oracle.com> Thanks, Dmitry! I assume I still need an approval from the Reviewer. Sincerely yours, Ivan On 05.10.2013 21:30, Dmitry Samersoff wrote: > Ivan, > > Looks good for me. > > -Dmitry > > On 2013-10-05 17:04, Ivan Gerasimov wrote: >> Dmitry, thanks for suggestion! >> >> Yes, == comparison isn't the only sh-incompatible thing in the script. >> Sh may be unhappy with [[ as well. >> So I replaced it with case as you suggested. >> Grep shows that it was the only place where [[ and == were used in >> regtests, so it would be good to make things consistent. >> >> Please find a new patch below. >> >> Sincerely yours, >> Ivan >> >> --- a/test/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh >> +++ b/test/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh >> @@ -34,12 +34,13 @@ >> OS=`uname -s` >> UMASK=`umask` >> >> -if [[ $OS == CYGWIN_NT* ]] ; then >> +case $OS in >> +CYGWIN_NT*) >> OS="Windows_NT" >> if [ -z "$SystemRoot" ] ; then >> - SystemRoot=$SYSTEMROOT >> + SystemRoot=$SYSTEMROOT >> fi >> -fi >> +esac >> >> case $OS in >> SunOS | Linux | Darwin) >> >> >> >> On 04.10.2013 15:34, Dmitry Samersoff wrote: >>> Ivan, >>> >>> If you need shell pattern match CYGWIN_NT* >>> it's better to use >>> >>> case >>> >>> but not >>> >>> if >>> >>> -Dmitry >>> >>> > From serguei.spitsyn at oracle.com Tue Oct 8 13:56:30 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 08 Oct 2013 13:56:30 -0700 Subject: RFR 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::,compare_entry_to and copy_entry_to In-Reply-To: <52544E78.9090103@oracle.com> References: <52544E78.9090103@oracle.com> Message-ID: <5254717E.7000502@oracle.com> It looks good. A question: 1011 case JVM_CONSTANT_MethodType: 1012 { 1013 int k1 = method_type_index_at_error_ok(index1); 1014 int k2 = cp2->method_type_index_at_error_ok(index2); . . . 1021 case JVM_CONSTANT_MethodHandle: 1022 { 1023 int k1 = method_handle_ref_kind_at_error_ok(index1); 1024 int k2 = cp2->method_handle_ref_kind_at_error_ok(index2); Should the above include InError variants ?: 1011 case JVM_CONSTANT_MethodType: case JVM_CONSTANT_MethodTypeInError: 1012 { 1013 int k1 = method_type_index_at_error_ok(index1); 1014 int k2 = cp2->method_type_index_at_error_ok(index2); . . . 1021 case JVM_CONSTANT_MethodHandle: case JVM_CONSTANT_MethodHandleInError: 1022 { 1023 int k1 = method_handle_ref_kind_at_error_ok(index1); 1024 int k2 = cp2->method_handle_ref_kind_at_error_ok(index2); Thanks, Serguei On 10/8/13 11:27 AM, Coleen Phillimore wrote: > Summary: Add missing cases. > > I verified this with the test for > https://bugs.openjdk.java.net/browse/JDK-8022701 but don't want to > copy the test into with modifications the hotspot repository, still > working on refactoring the test for the JDK repository for after this > gets pushed. > > open webrev at http://cr.openjdk.java.net/~coleenp/8025185/ > bug link https://bugs.openjdk.java.net/browse/JDK-8025185 > > Thanks, > Coleen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131008/2b83cd73/attachment.html From david.holmes at oracle.com Tue Oct 8 14:46:12 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 09 Oct 2013 07:46:12 +1000 Subject: RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <5253FC54.4010407@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> Message-ID: <52547D24.9060806@oracle.com> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: > On 8.10.2013 09:34, David Holmes wrote: >> Jaroslav, >> >> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>> Hello, >>> >>> currently the JVM uptime reported by the RuntimeMXBean is based on >>> System.currentTimeMillis() which makes it susceptible to changes of the >>> OS time (eg. changing timezone, NTP synchronization etc.). The uptime >>> should not depend on the system time and should be calculated using a >>> monotonic clock source. >>> >>> There is already the way to get the actual JVM uptime in ticks. It is >>> accessible as Management::timestamp() and the ticks are convertible to >>> milliseconds using Management::ticks_to_ms(ts_ticks) thus making it very >>> easy to switch to the monotonic clock based uptime. >> >> Maybe I'm missing something but TiumeStamp updates using >> os::elapsed_counter() which on Linux uses gettimeofday so is not a >> monotonic clock source. > > Hm, yes. I wasn't aware of this linux/bsd specific. > > Is there any reason why a non monotonic clock source is used for > timestamping except of the historical one? os::javaTimeNanos() uses > montonic clock when available - why can't be the same used for > os::elapsed_counter() especially when a counter based on "gettimeofday" > is not really a counter? It is all historical. These elapsed_counters and elapsed_timers make me cringe. But changing it has a lot of potential consequences because of the way these are used in logging etc. Certainly not something to be contemplated at this stage of JDK 8. Perhaps a simpler fix here is to expose a startUpTimeNanos that can then be used for the uptime. David > -JB- > >> >> David >> ----- >> >> >> >>> The patch consists of the hotspot and jdk parts. >>> >>> For the hotspot a new constant needs to be introduced in >>> src/share/vm/services/jmm.h and the actual logic to obtain the uptime in >>> milliseconds is added in src/share/vm/services/management.cpp. >>> >>> For the jdk the changes comprise of adding the necessary JNI bridging >>> methods in order to get the new uptime, introducing the same constant >>> that is used in hotspot and changes to mapfile-vers files in order to >>> properly build the native library. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>> >>> Thanks, >>> >>> -JB- > From karen.kinnear at oracle.com Tue Oct 8 15:23:51 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Tue, 08 Oct 2013 22:23:51 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8026022: Verifier: allow anon classes to invokespecial host class/intf methods. Message-ID: <20131008222357.8FF6862E68@hg.openjdk.java.net> Changeset: c72075c2883e Author: acorn Date: 2013-10-08 16:58 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c72075c2883e 8026022: Verifier: allow anon classes to invokespecial host class/intf methods. Reviewed-by: coleenp, bharadwaj ! src/share/vm/classfile/verifier.cpp From daniel.daugherty at oracle.com Tue Oct 8 15:59:57 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 08 Oct 2013 16:59:57 -0600 Subject: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <524B8A78.9040807@oracle.com> References: <523D144E.4000002@oracle.com> <524B8A78.9040807@oracle.com> Message-ID: <52548E6D.80701@oracle.com> Sorry for the delay in getting back to this. I've been side tracked by other tasks. I've made all the changes needed to address most of the comments below, but I still have to double check and test... On 10/1/13 8:52 PM, David Holmes wrote: > Hi Dan, > > Overall thumbs up. Thanks! > A couple of minor issues that need fixing. Will address those below... > A few meta-comments (I hate seeing all this stuff duplicated again and > again. Agreed that the duplication is bad (as before), but there is some hope that this stuff will get refactored... > > David > ----- > > - common/autoconf/hotspot-spec.gmk.in > > Seems a good simplification. > > ---- > > - common/autoconf/jdk-options.m4 > > No comment. > > --- > > - common/makefiles/NativeCompilation.gmk > > So JDK .diz support is phase 2? :) Yes, phase 2 if someone gets to it (probably me again). > The Windows changes here seem okay given that on windows a .debuginfo > file should never be in the target list. Right, I happened to notice that the .debuginfo file logic was not being excluded on Windows. Yes, this is the MacOS X bug, but I figured I would clean it up while I was there. > --- > > - hotspot/make/Makefile > > + $(EXPORT_CLIENT_DIR)/%.dSYM: $(MINIMAL1_BUILD_DIR)/%.dSYM > > EXPORT_CLIENT_DIR should be EXPORT_MINIMAL_DIR. > > For fun you can try building minimal on OSX, but I don't know how far > you will get: > > --with-jvm-variants=client,server,minimal1 > > I'll point out obvious issues with minimal VM support anyway. Since you pointed out in a later email that minimal1 isn't supported on MacOS X, I'm going to drop those changes. I'm going to leave the Client VM support since there are folks out in OpenJDK trying to get the Client VM working on MacOS X. It does look like someone added minimal1 support for other non-Linux platforms, but I'm not planning to clean that up. > --- > > - hotspot/make/bsd/Makefile > > No comment. > > - hotspot/make/bsd/makefiles/buildtree.make > > No comment. > > - make/bsd/makefiles/defs.make > > Note that the whole jdk6_or_earlier logic is defunct as this will > never be used for jdk6 or earlier. But best to clean all that up at > the one time. Agreed that we (Oracle) currently don't have plans to drop HSX-25 into JDK6 or OpenJDK6, but I don't want to rule out future insanity. Also agreed that cleaning up that logic should all be done at the same time using a different bug ID. > Sadly I never found a satisfactory solution to the multiplicity and > verbosity of the FDS messages, so OSX builds will now be afflicted by > them too. Also agreed, I've read your emails on that topic a few times, but nothing springs to mind... > > 328 else > 329 EXPORT_LIST += $(EXPORT_MINIMAL_DIR)/libjvm.debuginfo > 330 endif > > This pre-existing minimal VM code needs to be modified to reference > the dSYM directory on OSX as per the client/server cases. Since MacOS X doesn't support the minimal1 config, I've dropped that block of logic. Perhaps another bug should be used to remove all mention of minimal1 config from the MacOS X/BSD makefiles. > --- > > - hotspot/make/bsd/makefiles/dtrace.make > > Note related to your changes but I don't think any of the "64" > directory stuff has any meaning outside of Solaris. And now that 32-bit Solaris support is being dropped, this whole '64' subdir stuff might become obsolete/moot. > 102 dsymutil $@ > > I think dsymutil should be assigned to a variable in the platform > defs.make as with other tools. Good idea. It surprised me when the original Makefiles had this non-macro'ized call to dsymutil, but I went ahead and simply refactored the existing call (and copied it). I'll figure out how/where to fix it. > Would be nice if objcopy/dsymutil could be hidden behind a single > SYM_TOOL variables as well so there wasn't so much duplication of the > process. You could have a single set of instructions to invoke > SYM_TOOL, STRIP and ZIP (strip would be skipped of course because > STRIP_POLICY would never be set on osx). Just wishful thinking ... Could/should be done when the other refactoring is done to remove duplication. > > --- > > - hotspot/make/bsd/makefiles/gcc.make > > + FASTDEBUG_CFLAGS += $(DEBUG_CFLAGS/$(BUILDARCH)) > > should be > > + FASTDEBUG_CFLAGS += $(FASTDEBUG_CFLAGS/$(BUILDARCH)) Thanks for catching the cut-n-paste typo... > > Don't we need the USE_CLANG variations here as for linux? I suppose. I was trying to ignore CLANG, but I'll go ahead and drop in the changes (untested). > --- > > - hotspot/make/bsd/makefiles/jsig.make > - hotspot/make/bsd/makefiles/saproc.make > > Similar comments to dtrace.make Fixed the literal 'dsymutil' usages. > > --- > > - make/bsd/makefiles/universal.gmk > > I did not understand the additional logic here: > > 63 # Copy built non-universal binaries in place > 64 $(UNIVERSAL_COPY_LIST): > 65 BUILT_COPY_FILES="`find > $(EXPORT_JRE_LIB_DIR)/{i386,amd64}/$(subst $(EXPORT_JRE_LIB_DIR)/,,$@) > 2>/dev/null`"; \ > 66 if [ -n "$${BUILT_COPY_FILES}" ]; then \ > 67 for i in $${BUILT_COPY_FILES}; do \ > 68 if [ -f $${i} ]; then \ > 69 $(MKDIR) -p $(shell dirname $@); \ > 70 $(CP) -R $${i} $@; \ > 71 fi; \ > 72 if [ -d $${i} ]; then \ > 73 $(MKDIR) -p $@; \ > 74 fi; \ > 75 done; \ > 76 fi > > until I realized that foo.dSYM is a directory not a file! Even so > don't you want to copy the contents of the directory across ? BUILT_COPY_FILES includes both files and directories so everything should get copied across. I've added some commments to the rule header and reorganized the logic a bit to hopefully be more clear. > BTW: UNIVERSAL_COPY_LIST doesn't handle minimal VM. That's a good thing. :-) > > --- > > - make/bsd/makefiles/vm.make > > Similar comments to dtrace.make ref dsymutil. Fixed the literal 'dsymutil' usages. > > --- > > - hotspot/make/defs.make > > No comment. > > --- > > - jdk/make/common/Defs-macosx.gmk > > No comment > > - jdk/makefiles/Tools.gmk > > Not sure about this one. Logically is seems correct but up to now this > has been defined for everything without it seeming to cause a problem. > So why do we need to change it and what impact will it have? It just seemed wrong to define something that should never be used on non-Solaris platforms. My control build of the entire forest didn't have an issue with this change so I'm planning to keep it. Dan > > David > ----- > > On 21/09/2013 1:36 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have the initial support for Full Debug Symbols (FDS) on MacOS X done >> and ready for review: >> >> 7165611 implement Full Debug Symbols on MacOS X hotspot >> https://bugs.openjdk.java.net/browse/JDK-7165611 >> >> Here is the JDK8/HSX-25 webrev URL: >> >> OpenJDK: >> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >> Internal: >> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >> >> This webrev includes changes for the follow repos: >> >> jdk8 >> jdk8/hotspot >> jdk8/jdk >> jdk8/jdk/make/closed >> >> Once these changes are approved, I'm planning to push them to >> RT_Baseline. From there, they can follow the normal path to >> Main_Baseline and eventually JDK8. >> >> This work enables FDS on MacOS X for the 'hotspot' repo; the changes in >> the other repos are necessary to support importing the .diz files from >> the MacOS X 'hotspot' build into the forest build. I also fixed a few >> FDS related errors in the magic incantations for the new build. This is >> mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported >> from Solaris. In other words, this is Frankenstein's monster... >> >> Thanks to Staffan Larsen for providing an initial set of changes >> which I morphed into what you see here. >> >> Testing: >> - JPRT HSX build and test on all platforms; verification of .diz >> files in the MacOS X JPRT bundles >> - JPRT JDK8 forest build and test on all platforms; verification of >> .diz files in the MacOS X JPRT bundles >> Note: In previous FDS changesets, I also did a standalone 'jdk' >> repo build and test, but that no longer seems to work. >> >> As always, comments, questions and suggestions are welcome. >> >> Dan From coleen.phillimore at oracle.com Tue Oct 8 15:54:45 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 08 Oct 2013 18:54:45 -0400 Subject: RFR 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::,compare_entry_to and copy_entry_to In-Reply-To: <5254717E.7000502@oracle.com> References: <52544E78.9090103@oracle.com> <5254717E.7000502@oracle.com> Message-ID: <52548D35.50105@oracle.com> Hi Serguei, Thanks again for the prompt code review. On 10/08/2013 04:56 PM, serguei.spitsyn at oracle.com wrote: > It looks good. > A question: > > 1011 case JVM_CONSTANT_MethodType: > 1012 { > 1013 int k1 = method_type_index_at_error_ok(index1); > 1014 int k2 = cp2->method_type_index_at_error_ok(index2); > . . . > 1021 case JVM_CONSTANT_MethodHandle: > 1022 { > 1023 int k1 = method_handle_ref_kind_at_error_ok(index1); > 1024 int k2 = cp2->method_handle_ref_kind_at_error_ok(index2); > Should the above include InError variants ?: > 1011 case JVM_CONSTANT_MethodType: > case JVM_CONSTANT_MethodTypeInError: > 1012 { > 1013 int k1 = method_type_index_at_error_ok(index1); > 1014 int k2 = cp2->method_type_index_at_error_ok(index2); > . . . > 1021 case JVM_CONSTANT_MethodHandle: > case JVM_CONSTANT_MethodHandleInError: > 1022 { > 1023 int k1 = method_handle_ref_kind_at_error_ok(index1); > 1024 int k2 = cp2->method_handle_ref_kind_at_error_ok(index2); No, because I normalize these InError constant pool entries above, so they won't be found. thanks, Coleen > > Thanks, > Serguei > > > > On 10/8/13 11:27 AM, Coleen Phillimore wrote: >> Summary: Add missing cases. >> >> I verified this with the test for >> https://bugs.openjdk.java.net/browse/JDK-8022701 but don't want to >> copy the test into with modifications the hotspot repository, still >> working on refactoring the test for the JDK repository for after this >> gets pushed. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025185/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8025185 >> >> Thanks, >> Coleen > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131008/9a657a02/attachment-0001.html From serguei.spitsyn at oracle.com Tue Oct 8 16:09:56 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 08 Oct 2013 16:09:56 -0700 Subject: RFR 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::,compare_entry_to and copy_entry_to In-Reply-To: <52548D35.50105@oracle.com> References: <52544E78.9090103@oracle.com> <5254717E.7000502@oracle.com> <52548D35.50105@oracle.com> Message-ID: <525490C4.9050402@oracle.com> On 10/8/13 3:54 PM, Coleen Phillimore wrote: > > Hi Serguei, Thanks again for the prompt code review. > > On 10/08/2013 04:56 PM, serguei.spitsyn at oracle.com wrote: >> It looks good. >> A question: >> >> 1011 case JVM_CONSTANT_MethodType: >> 1012 { >> 1013 int k1 = method_type_index_at_error_ok(index1); >> 1014 int k2 = cp2->method_type_index_at_error_ok(index2); >> . . . >> 1021 case JVM_CONSTANT_MethodHandle: >> 1022 { >> 1023 int k1 = method_handle_ref_kind_at_error_ok(index1); >> 1024 int k2 = cp2->method_handle_ref_kind_at_error_ok(index2); >> Should the above include InError variants ?: >> 1011 case JVM_CONSTANT_MethodType: >> case JVM_CONSTANT_MethodTypeInError: >> 1012 { >> 1013 int k1 = method_type_index_at_error_ok(index1); >> 1014 int k2 = cp2->method_type_index_at_error_ok(index2); >> . . . >> 1021 case JVM_CONSTANT_MethodHandle: >> case JVM_CONSTANT_MethodHandleInError: >> 1022 { >> 1023 int k1 = method_handle_ref_kind_at_error_ok(index1); >> 1024 int k2 = cp2->method_handle_ref_kind_at_error_ok(index2); > > No, because I normalize these InError constant pool entries above, so > they won't be found. Right. Thanks! Serguei > thanks, > Coleen >> >> Thanks, >> Serguei >> >> >> >> On 10/8/13 11:27 AM, Coleen Phillimore wrote: >>> Summary: Add missing cases. >>> >>> I verified this with the test for >>> https://bugs.openjdk.java.net/browse/JDK-8022701 but don't want to >>> copy the test into with modifications the hotspot repository, still >>> working on refactoring the test for the JDK repository for after >>> this gets pushed. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8025185/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8025185 >>> >>> Thanks, >>> Coleen >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131008/3cc51bfe/attachment.html From rob.mckenna at oracle.com Tue Oct 8 16:12:59 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Tue, 08 Oct 2013 23:12:59 +0000 Subject: hg: jdk8/tl/jdk: 7180557: InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX webbugs Message-ID: <20131008231322.E3E2662E6A@hg.openjdk.java.net> Changeset: f1e31376f419 Author: robm Date: 2013-10-09 00:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1e31376f419 7180557: InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX webbugs Reviewed-by: chegar, dsamersoff ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c From david.holmes at oracle.com Tue Oct 8 18:04:41 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 09 Oct 2013 11:04:41 +1000 Subject: jmx-dev Codereview request: 8025207 Intermittent test failure: javax/management/monitor/CounterMonitorThresholdTest.java References: 52415BE3.1030803@oracle.com Message-ID: <5254ABA9.6010405@oracle.com> shanliang wrote: > Daniel Fuchs wrote: >> On 9/23/13 8:27 PM, shanliang wrote: >>> Hi, >>> >>> Please review this test fix, if the test continues failing, then we need >>> to investigate the Monitor implementation. >>> >>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025207/00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8025207 >>> >>> Thanks, >>> Shanliang >>> >> >> Hi Shanliang, >> >> There seems to an issue in the exit condition of the loop in the >> new code. >> >> The old code had: >> >> 150 if (derivedGaugeValue.intValue() != derivedGauge[i]) >> >> the new code has: >> >> 155 } while (derivedGaugeValue.intValue() != counter[i]); > Good catch, I changed the code, even they are same today: > Here is the new version: > http://cr.openjdk.java.net/~sjiang/JDK-8025207/01/ My concern here is that if the test times out and is killed by the test harness, there is absolutely nothing to indicate where the test got stuck. So I would suggest at least adding a println before entering the loop and again after. David ----- From david.holmes at oracle.com Tue Oct 8 18:15:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 09 Oct 2013 11:15:19 +1000 Subject: jmx-dev Codereview request: 8025206 IIntermittent test failure: javax/management/monitor/NullAttributeValueTest.java References: 52493592.1030504@oracle.com Message-ID: <5254AE27.4060303@oracle.com> Shanliang writes: > Daniel Fuchs wrote: >> Hi Shanliang, >> >> Shouldn't 'messageReceived' be at least declared as volatile? >> It looks as if this test is a multi-thread test which >> is not MT-safe. > OK I am convinced: > http://cr.openjdk.java.net/~sjiang/JDK-8025206/02/ The volatile is definitely needed if the field is written/read by different threads. I think the rule is to not use @author tags in OpenJDK code. This comment is not needed: 288 // See 8025206 but I think the bug number should be added to the @bug line. Otherwise seems reasonable. Reviewed. David From david.holmes at oracle.com Tue Oct 8 18:20:36 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 09 Oct 2013 11:20:36 +1000 Subject: Codereview request: 8025205 Intermittent test failure: javax/management/remote/mandatory/connection/BrokenConnectionTest.java References: 5240881E.4060204@oracle.com Message-ID: <5254AF64.3020702@oracle.com> Shanliang writes: > Hi, > > Simply wait longer time for a broken notif. > > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025205/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8025205 The new loop seems okay - and there is a println to aid in the timeout case. Not sure about the extra Thread.sleep(1000), seems somewhat ad-hoc, but I'm unclear about where these extra notifications might come from or how long is a reasonable time to wait to see that there are none. Let's just see how this plays out in testing. (I assume you will be keeping a close eye on all new results :) ). Reviewed. David From david.holmes at oracle.com Tue Oct 8 18:28:22 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 09 Oct 2013 11:28:22 +1000 Subject: Codereview request: 8025204 Intermittent test failure: javax/management/remote/mandatory/connection/IdleTimeoutTest.java Message-ID: <5254B136.5070705@oracle.com> Shanliang writes: > Hi, > > Simply wait longer time for a broken notif. > > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025205/00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8025205 ! // no deadline here, let's wait till either the connId is removed ! // or the test timeout (jprt kills the test)! ! // see 8025204 The comment loses context if you don't know what the code previously did. I suggest using the simpler form you used in other tests eg: // pass or timed out by test harness - see XXXX Note it isn't JPRT that normally kills these but the jtreg harness. Style nit: } while(ids space needed after 'while' } while (ids David ----- From staffan.larsen at oracle.com Wed Oct 9 00:04:20 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 9 Oct 2013 09:04:20 +0200 Subject: Fix to 8025925 In-Reply-To: <525483E0.7040506@oracle.com> References: <5252C9DE.8030402@oracle.com> <5252D10E.7070405@oracle.com> <92711177-AFA2-4719-8834-EEE40FA20B92@oracle.com> <525483E0.7040506@oracle.com> Message-ID: Looks good to me, but I'd like Thomas' opinion as well. Thanks, /Staffan On 9 okt 2013, at 00:14, aleksey.timofeev at oracle.com wrote: > Hello. > > I prepared a little fix to JDK-8025925. Find webrev here please: http://cr.openjdk.java.net/~iignatyev/atimofeev/8025925/webrev.00/index.html (now it's on open server). Staffan Larsen generously agreed to sponsor this commit if we conclude everything is OK. Please your provide feedback. > > -- > Best regards, Aleksey Timofeev. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131009/d908b55a/attachment.html From joel.franck at oracle.com Wed Oct 9 00:08:53 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Wed, 09 Oct 2013 07:08:53 +0000 Subject: hg: jdk8/tl/langtools: 8024415: Bug in javac Pretty: Wrong precedence in JCConditional trees Message-ID: <20131009070900.731AD62E73@hg.openjdk.java.net> Changeset: ea000904db62 Author: alundblad Date: 2013-10-08 15:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ea000904db62 8024415: Bug in javac Pretty: Wrong precedence in JCConditional trees Summary: Fixed precedence and associativity issues with pretty printing of JCConditional expressions. Reviewed-by: jfranck Contributed-by: Andreas Lundblad , Matthew Dempsky ! src/share/classes/com/sun/tools/javac/tree/Pretty.java + test/tools/javac/tree/T8024415.java From shanliang.jiang at oracle.com Wed Oct 9 00:42:21 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 09 Oct 2013 09:42:21 +0200 Subject: jmx-dev Codereview request: 8025207 Intermittent test failure: javax/management/monitor/CounterMonitorThresholdTest.java In-Reply-To: <5254ABA9.6010405@oracle.com> References: 52415BE3.1030803@oracle.com <5254ABA9.6010405@oracle.com> Message-ID: <525508DD.6070108@oracle.com> David Holmes wrote: > shanliang wrote: >> Daniel Fuchs wrote: >>> On 9/23/13 8:27 PM, shanliang wrote: >>>> Hi, >>>> >>>> Please review this test fix, if the test continues failing, then we >>>> need >>>> to investigate the Monitor implementation. >>>> >>>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025207/00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8025207 >>>> >>>> Thanks, >>>> Shanliang >>>> >>> >>> Hi Shanliang, >>> >>> There seems to an issue in the exit condition of the loop in the >>> new code. >>> >>> The old code had: >>> >>> 150 if (derivedGaugeValue.intValue() != derivedGauge[i]) >>> >>> the new code has: >>> >>> 155 } while (derivedGaugeValue.intValue() != counter[i]); >> Good catch, I changed the code, even they are same today: >> Here is the new version: >> http://cr.openjdk.java.net/~sjiang/JDK-8025207/01/ > > My concern here is that if the test times out and is killed by the > test harness, there is absolutely nothing to indicate where the test > got stuck. So I would suggest at least adding a println before > entering the loop and again after. I think today the test gives info about each test step: Line 139: System.out.println("\nStart monitoring..."); tells the looping entry Line 146: System.out.println("\nCounter = " + mbean.getCounter()); within the loop tells which counter value is being tested. Line 156: System.out.println("Threshold = " + thresholdValue); within the loop tells the test end of a count value. Line 168: System.out.println("\nStop monitoring..."); tells the looping end. and the class Listener prints out notification info allowing to know where is testing too. Thanks, Shanliang > > David > ----- From mandy.chung at oracle.com Wed Oct 9 00:46:19 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 09 Oct 2013 00:46:19 -0700 Subject: RFR (S) JDK-8025700: RuntimeMXBean.getInputArguments() should include -server/-client/-d32/-d64 In-Reply-To: <52541925.5030907@oracle.com> References: <524D73C4.7060004@oracle.com> <5253A32D.40502@oracle.com> <52541925.5030907@oracle.com> Message-ID: <525509CB.1050301@oracle.com> Hi Aleksey, Like David said, -client/-server and -d32/-d64 are launcher option but not VM options. RuntimeMXBean.getInputArguments() returns the arguments passed to the VM which is created via the JNI_CreateJavaVM API. -client/-server is the java launcher option that determines which VM to load and initialize and it's not an option passed to the JVM. In addition, -client/-server is actually not a valid option to the hotspot VM. Instead, you can find out if it's a server/client/minimal VM from getVmName(). > Moving forward, I can foresee different VMs being requested which can > not be guessed that easily. Think -XXaltjvm= or some other black magic > in launcher. Because of that, I think more generic solution (like the > variant being proposed) is more viable. A different VM should have a name that can easily differentiate from other implementation. The only thing I can imagine missing for such a future launcher is the pathname if specified in the command-line. I would suggest to revisit this when such a launcher option is added and determine what API is needed. Mandy On 10/8/2013 7:39 AM, Aleksey Shipilev wrote: > Yes, I can see that reasoning. > > I have the opposite perspective though: I think it is the matter of user > experience, RuntimeMXBean should not care about the launcher/VM > distinction, since what user "perceives" is the JVM launched via "java". > Segregating the launcher and "pure" VM options seems to be exposing the > implementation detail. Thus, this fix actually covers up that glitch. > > -Aleksey. > > On 10/08/2013 10:16 AM, David Holmes wrote: >> As I wrote in the bug report I have reservations about this as these are >> launcher options not VM options. Plus with the dropping of 32-bit >> Solaris the -d32/-d64 part will be moot. That leaves the VM "mode" - >> client, server, minimal or whatever might happened to be defined via >> jvm.cfg (-server might actually run client VM). >> >> David >> >> On 3/10/2013 11:40 PM, Aleksey Shipilev wrote: >>> Hi, >>> >>> Please take a look at the potential fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8025700 >>> >>> The webrev is here: >>> http://cr.openjdk.java.net/~shade/8025700/webrev.01/ >>> >>> Rationale: when doing the Java tools which need to replicate the VM >>> launch, e.g. fork the JVM with the same set of command line options, we >>> need the exact command line. Otherwise we miss the significant part of >>> configuration, which confuses people. So far we miss "-server", >>> "-client", "-d32", and "-d64" options from there. I have seen troubles >>> with jmh and jcstress stemming from this very issue. >>> >>> Testing: >>> - new jtreg test, works fine on Linux x86_64; (I can run other >>> platforms as long as the fix approach is sound) >>> - jdk/test/tools/launcher jtreg tests on Linux x86_64 >>> >>> Thanks, >>> -Aleksey >>> From shanliang.jiang at oracle.com Wed Oct 9 00:56:18 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 09 Oct 2013 09:56:18 +0200 Subject: Codereview request: 8025204 Intermittent test failure: javax/management/remote/mandatory/connection/IdleTimeoutTest.java In-Reply-To: <5254B136.5070705@oracle.com> References: <5254B136.5070705@oracle.com> Message-ID: <52550C22.2080201@oracle.com> David Holmes wrote: > ! // no deadline here, let's wait till either the > connId is removed > ! // or the test timeout (jprt kills the test)! > ! // see 8025204 > > The comment loses context if you don't know what the code previously > did. I suggest using the simpler form you used in other tests eg: > > // pass or timed out by test harness - see XXXX > > Note it isn't JPRT that normally kills these but the jtreg harness. > > Style nit: > > } while(ids > > space needed after 'while' > > } while (ids Here is the new version integrated your comments: web: http://cr.openjdk.java.net/~sjiang/8025204jdk/01/ bug: https://bugs.openjdk.java.net/browse/JDK-8025204 Thanks, Shanliang > > David > ----- From aleksey.shipilev at oracle.com Wed Oct 9 01:19:17 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 09 Oct 2013 12:19:17 +0400 Subject: RFR (S) JDK-8025700: RuntimeMXBean.getInputArguments() should include -server/-client/-d32/-d64 In-Reply-To: <525509CB.1050301@oracle.com> References: <524D73C4.7060004@oracle.com> <5253A32D.40502@oracle.com> <52541925.5030907@oracle.com> <525509CB.1050301@oracle.com> Message-ID: <52551185.8070209@oracle.com> Hi Mandy, On 10/09/2013 11:46 AM, Mandy Chung wrote: > Like David said, -client/-server and -d32/-d64 are launcher option but > not VM options. RuntimeMXBean.getInputArguments() returns the arguments > passed to the VM which is created via the JNI_CreateJavaVM API. Hm, this is the first time I hear about this contract, is it really specified somewhere? Or, is it the informal status quo? Because it feels remarkably as the implementation detail. I don't think users should be exposed to the distinction between launcher and VM anyway. > -client/-server is the java launcher option that determines which VM to > load and initialize and it's not an option passed to the JVM. In > addition, -client/-server is actually not a valid option to the hotspot > VM. Instead, you can find out if it's a server/client/minimal VM from > getVmName(). Okay, let me state the intent cleaner. The tools I maintain (jmh and jcstress are notable examples) need to start exactly the same VM with exactly the same "java" options. How would you propose to do this? Recovering the command line by parsing getVmName() uses (unstable) stringly conventions to detect the running VM, and also pushes me to maintain the list of all possible VMs in the detection code. RuntimeMXBean.getInputArguments() omits some launcher options, but it is fixable to expose these options to the user, no stringly parsing is required on user side. Do you see any better option? -Aleksey. From alan.bateman at oracle.com Wed Oct 9 01:23:36 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 09 Oct 2013 08:23:36 +0000 Subject: hg: jdk8/tl/jdk: 8008662: Add @jdk.Exported to JDK-specific/exported APIs Message-ID: <20131009082348.AE9D462E76@hg.openjdk.java.net> Changeset: 2ea162b2ff55 Author: alanb Date: 2013-10-09 09:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ea162b2ff55 8008662: Add @jdk.Exported to JDK-specific/exported APIs Reviewed-by: chegar, vinnie, dfuchs, mchung, mullan, darcy ! src/share/classes/com/sun/jdi/AbsentInformationException.java ! src/share/classes/com/sun/jdi/Accessible.java ! src/share/classes/com/sun/jdi/ArrayReference.java ! src/share/classes/com/sun/jdi/ArrayType.java ! src/share/classes/com/sun/jdi/BooleanType.java ! src/share/classes/com/sun/jdi/BooleanValue.java ! src/share/classes/com/sun/jdi/Bootstrap.java ! src/share/classes/com/sun/jdi/ByteType.java ! src/share/classes/com/sun/jdi/ByteValue.java ! src/share/classes/com/sun/jdi/CharType.java ! src/share/classes/com/sun/jdi/CharValue.java ! src/share/classes/com/sun/jdi/ClassLoaderReference.java ! src/share/classes/com/sun/jdi/ClassNotLoadedException.java ! src/share/classes/com/sun/jdi/ClassNotPreparedException.java ! src/share/classes/com/sun/jdi/ClassObjectReference.java ! src/share/classes/com/sun/jdi/ClassType.java ! src/share/classes/com/sun/jdi/DoubleType.java ! src/share/classes/com/sun/jdi/DoubleValue.java ! src/share/classes/com/sun/jdi/Field.java ! src/share/classes/com/sun/jdi/FloatType.java ! src/share/classes/com/sun/jdi/FloatValue.java ! src/share/classes/com/sun/jdi/IncompatibleThreadStateException.java ! src/share/classes/com/sun/jdi/InconsistentDebugInfoException.java ! src/share/classes/com/sun/jdi/IntegerType.java ! src/share/classes/com/sun/jdi/IntegerValue.java ! src/share/classes/com/sun/jdi/InterfaceType.java ! src/share/classes/com/sun/jdi/InternalException.java ! src/share/classes/com/sun/jdi/InvalidCodeIndexException.java ! src/share/classes/com/sun/jdi/InvalidLineNumberException.java ! src/share/classes/com/sun/jdi/InvalidStackFrameException.java ! src/share/classes/com/sun/jdi/InvalidTypeException.java ! src/share/classes/com/sun/jdi/InvocationException.java ! src/share/classes/com/sun/jdi/JDIPermission.java ! src/share/classes/com/sun/jdi/LocalVariable.java ! src/share/classes/com/sun/jdi/Locatable.java ! src/share/classes/com/sun/jdi/Location.java ! src/share/classes/com/sun/jdi/LongType.java ! src/share/classes/com/sun/jdi/LongValue.java ! src/share/classes/com/sun/jdi/Method.java ! src/share/classes/com/sun/jdi/Mirror.java ! src/share/classes/com/sun/jdi/MonitorInfo.java ! src/share/classes/com/sun/jdi/NativeMethodException.java ! src/share/classes/com/sun/jdi/ObjectCollectedException.java ! src/share/classes/com/sun/jdi/ObjectReference.java ! src/share/classes/com/sun/jdi/PathSearchingVirtualMachine.java ! src/share/classes/com/sun/jdi/PrimitiveType.java ! src/share/classes/com/sun/jdi/PrimitiveValue.java ! src/share/classes/com/sun/jdi/ReferenceType.java ! src/share/classes/com/sun/jdi/ShortType.java ! src/share/classes/com/sun/jdi/ShortValue.java ! src/share/classes/com/sun/jdi/StackFrame.java ! src/share/classes/com/sun/jdi/StringReference.java ! src/share/classes/com/sun/jdi/ThreadGroupReference.java ! src/share/classes/com/sun/jdi/ThreadReference.java ! src/share/classes/com/sun/jdi/Type.java ! src/share/classes/com/sun/jdi/TypeComponent.java ! src/share/classes/com/sun/jdi/VMCannotBeModifiedException.java ! src/share/classes/com/sun/jdi/VMDisconnectedException.java ! src/share/classes/com/sun/jdi/VMMismatchException.java ! src/share/classes/com/sun/jdi/VMOutOfMemoryException.java ! src/share/classes/com/sun/jdi/Value.java ! src/share/classes/com/sun/jdi/VirtualMachine.java ! src/share/classes/com/sun/jdi/VirtualMachineManager.java ! src/share/classes/com/sun/jdi/VoidType.java ! src/share/classes/com/sun/jdi/VoidValue.java ! src/share/classes/com/sun/jdi/connect/AttachingConnector.java ! src/share/classes/com/sun/jdi/connect/Connector.java ! src/share/classes/com/sun/jdi/connect/IllegalConnectorArgumentsException.java ! src/share/classes/com/sun/jdi/connect/LaunchingConnector.java ! src/share/classes/com/sun/jdi/connect/ListeningConnector.java ! src/share/classes/com/sun/jdi/connect/Transport.java ! src/share/classes/com/sun/jdi/connect/TransportTimeoutException.java ! src/share/classes/com/sun/jdi/connect/VMStartException.java + src/share/classes/com/sun/jdi/connect/package-info.java - src/share/classes/com/sun/jdi/connect/package.html ! src/share/classes/com/sun/jdi/connect/spi/ClosedConnectionException.java ! src/share/classes/com/sun/jdi/connect/spi/Connection.java ! src/share/classes/com/sun/jdi/connect/spi/TransportService.java + src/share/classes/com/sun/jdi/connect/spi/package-info.java - src/share/classes/com/sun/jdi/connect/spi/package.html ! src/share/classes/com/sun/jdi/event/AccessWatchpointEvent.java ! src/share/classes/com/sun/jdi/event/BreakpointEvent.java ! src/share/classes/com/sun/jdi/event/ClassPrepareEvent.java ! src/share/classes/com/sun/jdi/event/ClassUnloadEvent.java ! src/share/classes/com/sun/jdi/event/Event.java ! src/share/classes/com/sun/jdi/event/EventIterator.java ! src/share/classes/com/sun/jdi/event/EventQueue.java ! src/share/classes/com/sun/jdi/event/EventSet.java ! src/share/classes/com/sun/jdi/event/ExceptionEvent.java ! src/share/classes/com/sun/jdi/event/LocatableEvent.java ! src/share/classes/com/sun/jdi/event/MethodEntryEvent.java ! src/share/classes/com/sun/jdi/event/MethodExitEvent.java ! src/share/classes/com/sun/jdi/event/ModificationWatchpointEvent.java ! src/share/classes/com/sun/jdi/event/MonitorContendedEnterEvent.java ! src/share/classes/com/sun/jdi/event/MonitorContendedEnteredEvent.java ! src/share/classes/com/sun/jdi/event/MonitorWaitEvent.java ! src/share/classes/com/sun/jdi/event/MonitorWaitedEvent.java ! src/share/classes/com/sun/jdi/event/StepEvent.java ! src/share/classes/com/sun/jdi/event/ThreadDeathEvent.java ! src/share/classes/com/sun/jdi/event/ThreadStartEvent.java ! src/share/classes/com/sun/jdi/event/VMDeathEvent.java ! src/share/classes/com/sun/jdi/event/VMDisconnectEvent.java ! src/share/classes/com/sun/jdi/event/VMStartEvent.java ! src/share/classes/com/sun/jdi/event/WatchpointEvent.java + src/share/classes/com/sun/jdi/event/package-info.java - src/share/classes/com/sun/jdi/event/package.html + src/share/classes/com/sun/jdi/package-info.java - src/share/classes/com/sun/jdi/package.html ! src/share/classes/com/sun/jdi/request/AccessWatchpointRequest.java ! src/share/classes/com/sun/jdi/request/BreakpointRequest.java ! src/share/classes/com/sun/jdi/request/ClassPrepareRequest.java ! src/share/classes/com/sun/jdi/request/ClassUnloadRequest.java ! src/share/classes/com/sun/jdi/request/DuplicateRequestException.java ! src/share/classes/com/sun/jdi/request/EventRequest.java ! src/share/classes/com/sun/jdi/request/EventRequestManager.java ! src/share/classes/com/sun/jdi/request/ExceptionRequest.java ! src/share/classes/com/sun/jdi/request/InvalidRequestStateException.java ! src/share/classes/com/sun/jdi/request/MethodEntryRequest.java ! src/share/classes/com/sun/jdi/request/MethodExitRequest.java ! src/share/classes/com/sun/jdi/request/ModificationWatchpointRequest.java ! src/share/classes/com/sun/jdi/request/MonitorContendedEnterRequest.java ! src/share/classes/com/sun/jdi/request/MonitorContendedEnteredRequest.java ! src/share/classes/com/sun/jdi/request/MonitorWaitRequest.java ! src/share/classes/com/sun/jdi/request/MonitorWaitedRequest.java ! src/share/classes/com/sun/jdi/request/StepRequest.java ! src/share/classes/com/sun/jdi/request/ThreadDeathRequest.java ! src/share/classes/com/sun/jdi/request/ThreadStartRequest.java ! src/share/classes/com/sun/jdi/request/VMDeathRequest.java ! src/share/classes/com/sun/jdi/request/WatchpointRequest.java + src/share/classes/com/sun/jdi/request/package-info.java - src/share/classes/com/sun/jdi/request/package.html ! src/share/classes/com/sun/management/GarbageCollectionNotificationInfo.java ! src/share/classes/com/sun/management/GarbageCollectorMXBean.java ! src/share/classes/com/sun/management/GcInfo.java ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/com/sun/management/OperatingSystemMXBean.java ! src/share/classes/com/sun/management/ThreadMXBean.java ! src/share/classes/com/sun/management/UnixOperatingSystemMXBean.java ! src/share/classes/com/sun/management/VMOption.java + src/share/classes/com/sun/management/package-info.java - src/share/classes/com/sun/management/package.html ! src/share/classes/com/sun/net/httpserver/Authenticator.java ! src/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/share/classes/com/sun/net/httpserver/Filter.java ! src/share/classes/com/sun/net/httpserver/Headers.java ! src/share/classes/com/sun/net/httpserver/HttpContext.java ! src/share/classes/com/sun/net/httpserver/HttpExchange.java ! src/share/classes/com/sun/net/httpserver/HttpHandler.java ! src/share/classes/com/sun/net/httpserver/HttpPrincipal.java ! src/share/classes/com/sun/net/httpserver/HttpServer.java ! src/share/classes/com/sun/net/httpserver/HttpsConfigurator.java ! src/share/classes/com/sun/net/httpserver/HttpsExchange.java ! src/share/classes/com/sun/net/httpserver/HttpsParameters.java ! src/share/classes/com/sun/net/httpserver/HttpsServer.java ! src/share/classes/com/sun/net/httpserver/package-info.java ! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/share/classes/com/sun/net/httpserver/spi/package-info.java ! src/share/classes/com/sun/nio/sctp/AbstractNotificationHandler.java ! src/share/classes/com/sun/nio/sctp/Association.java ! src/share/classes/com/sun/nio/sctp/AssociationChangeNotification.java ! src/share/classes/com/sun/nio/sctp/HandlerResult.java ! src/share/classes/com/sun/nio/sctp/IllegalReceiveException.java ! src/share/classes/com/sun/nio/sctp/IllegalUnbindException.java ! src/share/classes/com/sun/nio/sctp/InvalidStreamException.java ! src/share/classes/com/sun/nio/sctp/MessageInfo.java ! src/share/classes/com/sun/nio/sctp/Notification.java ! src/share/classes/com/sun/nio/sctp/NotificationHandler.java ! src/share/classes/com/sun/nio/sctp/PeerAddressChangeNotification.java ! src/share/classes/com/sun/nio/sctp/SctpChannel.java ! src/share/classes/com/sun/nio/sctp/SctpMultiChannel.java ! src/share/classes/com/sun/nio/sctp/SctpServerChannel.java ! src/share/classes/com/sun/nio/sctp/SctpSocketOption.java ! src/share/classes/com/sun/nio/sctp/SctpStandardSocketOptions.java ! src/share/classes/com/sun/nio/sctp/SendFailedNotification.java ! src/share/classes/com/sun/nio/sctp/ShutdownNotification.java ! src/share/classes/com/sun/nio/sctp/package-info.java ! src/share/classes/com/sun/security/auth/LdapPrincipal.java ! src/share/classes/com/sun/security/auth/NTDomainPrincipal.java ! src/share/classes/com/sun/security/auth/NTNumericCredential.java ! src/share/classes/com/sun/security/auth/NTSid.java ! src/share/classes/com/sun/security/auth/NTSidDomainPrincipal.java ! src/share/classes/com/sun/security/auth/NTSidGroupPrincipal.java ! src/share/classes/com/sun/security/auth/NTSidPrimaryGroupPrincipal.java ! src/share/classes/com/sun/security/auth/NTSidUserPrincipal.java ! src/share/classes/com/sun/security/auth/NTUserPrincipal.java ! src/share/classes/com/sun/security/auth/PolicyFile.java ! src/share/classes/com/sun/security/auth/PrincipalComparator.java ! src/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java ! src/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java ! src/share/classes/com/sun/security/auth/SolarisPrincipal.java ! src/share/classes/com/sun/security/auth/UnixNumericGroupPrincipal.java ! src/share/classes/com/sun/security/auth/UnixNumericUserPrincipal.java ! src/share/classes/com/sun/security/auth/UnixPrincipal.java ! src/share/classes/com/sun/security/auth/UserPrincipal.java ! src/share/classes/com/sun/security/auth/X500Principal.java ! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java ! src/share/classes/com/sun/security/auth/callback/TextCallbackHandler.java + src/share/classes/com/sun/security/auth/callback/package-info.java ! src/share/classes/com/sun/security/auth/login/ConfigFile.java + src/share/classes/com/sun/security/auth/login/package-info.java ! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/com/sun/security/auth/module/LdapLoginModule.java ! src/share/classes/com/sun/security/auth/module/NTLoginModule.java ! src/share/classes/com/sun/security/auth/module/NTSystem.java ! src/share/classes/com/sun/security/auth/module/SolarisLoginModule.java ! src/share/classes/com/sun/security/auth/module/SolarisSystem.java ! src/share/classes/com/sun/security/auth/module/UnixLoginModule.java ! src/share/classes/com/sun/security/auth/module/UnixSystem.java + src/share/classes/com/sun/security/auth/module/package-info.java + src/share/classes/com/sun/security/auth/package-info.java ! src/share/classes/com/sun/security/jgss/AuthorizationDataEntry.java ! src/share/classes/com/sun/security/jgss/ExtendedGSSContext.java ! src/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java ! src/share/classes/com/sun/security/jgss/GSSUtil.java ! src/share/classes/com/sun/security/jgss/InquireSecContextPermission.java ! src/share/classes/com/sun/security/jgss/InquireType.java + src/share/classes/com/sun/security/jgss/package-info.java ! src/share/classes/com/sun/tools/attach/AgentInitializationException.java ! src/share/classes/com/sun/tools/attach/AgentLoadException.java ! src/share/classes/com/sun/tools/attach/AttachNotSupportedException.java ! src/share/classes/com/sun/tools/attach/AttachPermission.java ! src/share/classes/com/sun/tools/attach/VirtualMachine.java ! src/share/classes/com/sun/tools/attach/VirtualMachineDescriptor.java + src/share/classes/com/sun/tools/attach/package-info.java - src/share/classes/com/sun/tools/attach/package.html ! src/share/classes/com/sun/tools/attach/spi/AttachProvider.java + src/share/classes/com/sun/tools/attach/spi/package-info.java - src/share/classes/com/sun/tools/attach/spi/package.html ! src/share/classes/com/sun/tools/jconsole/JConsoleContext.java ! src/share/classes/com/sun/tools/jconsole/JConsolePlugin.java + src/share/classes/com/sun/tools/jconsole/package-info.java - src/share/classes/com/sun/tools/jconsole/package.html ! src/solaris/classes/com/sun/management/OSMBeanFactory.java From mandy.chung at oracle.com Wed Oct 9 02:03:55 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 09 Oct 2013 02:03:55 -0700 Subject: RFR (S) JDK-8025700: RuntimeMXBean.getInputArguments() should include -server/-client/-d32/-d64 In-Reply-To: <52551185.8070209@oracle.com> References: <524D73C4.7060004@oracle.com> <5253A32D.40502@oracle.com> <52541925.5030907@oracle.com> <525509CB.1050301@oracle.com> <52551185.8070209@oracle.com> Message-ID: <52551BFB.5040309@oracle.com> On 10/9/2013 1:19 AM, Aleksey Shipilev wrote: > Hi Mandy, > > On 10/09/2013 11:46 AM, Mandy Chung wrote: >> Like David said, -client/-server and -d32/-d64 are launcher option but >> not VM options. RuntimeMXBean.getInputArguments() returns the arguments >> passed to the VM which is created via the JNI_CreateJavaVM API. > Hm, this is the first time I hear about this contract, is it really > specified somewhere? Or, is it the informal status quo? Because it feels > remarkably as the implementation detail. I don't think users should be > exposed to the distinction between launcher and VM anyway. The spec of RuntimeMXBean.getInputArguments says: Returns the input arguments passed to the Java virtual machine which does not include the arguments to the main method. It didn't say it can't include invalid VM options but they are just not VM options and the hotspot implementation will exit if they were passed to the VM. Our java launcher is one implementation that loads and initialize the hotspot VM but there are other custom launchers out there that can call JNI_CreateJavaVM to load and initialize a JVM. > >> -client/-server is the java launcher option that determines which VM to >> load and initialize and it's not an option passed to the JVM. In >> addition, -client/-server is actually not a valid option to the hotspot >> VM. Instead, you can find out if it's a server/client/minimal VM from >> getVmName(). > Okay, let me state the intent cleaner. The tools I maintain (jmh and > jcstress are notable examples) need to start exactly the same VM with > exactly the same "java" options. How would you propose to do this? You want to exec another process with the same command-line options to the java launcher (or augmenting with additional ones). Your proposed fix will only work with this implementation and the application is launched by the java launcher. In other words, your tools wouldn't support any other launcher implementation that may launch different VMs. Maybe you are only interested in our JDK implementation. > Recovering the command line by parsing getVmName() uses (unstable) > stringly conventions to detect the running VM, and also pushes me to > maintain the list of all possible VMs in the detection code. > > RuntimeMXBean.getInputArguments() omits some launcher options, but it is > fixable to expose these options to the user, no stringly parsing is > required on user side. > > Do you see any better option? I no longer work in this area and don't have any suggestion at the moment. Although parsing of VM name is not ideal, I suggest it as a workaround for now and give the serviceability team time to look into this to address your request. Mandy > > -Aleksey. From aleksey.shipilev at oracle.com Wed Oct 9 02:21:21 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 09 Oct 2013 13:21:21 +0400 Subject: RFR (S) JDK-8025700: RuntimeMXBean.getInputArguments() should include -server/-client/-d32/-d64 In-Reply-To: <52551BFB.5040309@oracle.com> References: <524D73C4.7060004@oracle.com> <5253A32D.40502@oracle.com> <52541925.5030907@oracle.com> <525509CB.1050301@oracle.com> <52551185.8070209@oracle.com> <52551BFB.5040309@oracle.com> Message-ID: <52552011.6020904@oracle.com> On 10/09/2013 01:03 PM, Mandy Chung wrote: >> Do you see any better option? > > I no longer work in this area and don't have any suggestion at the > moment. Although parsing of VM name is not ideal, I suggest it as a > workaround for now and give the serviceability team time to look into > this to address your request. Ok, I'll leave the ticket open meanwhile. Thanks, -Aleksey. From shanliang.jiang at oracle.com Wed Oct 9 02:43:46 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 09 Oct 2013 11:43:46 +0200 Subject: jmx-dev Codereview request: 8025206 IIntermittent test failure: javax/management/monitor/NullAttributeValueTest.java In-Reply-To: <5254AE27.4060303@oracle.com> References: 52493592.1030504@oracle.com <5254AE27.4060303@oracle.com> Message-ID: <52552552.9070708@oracle.com> David Holmes wrote: > Shanliang writes: >> Daniel Fuchs wrote: >>> Hi Shanliang, >>> >>> Shouldn't 'messageReceived' be at least declared as volatile? >>> It looks as if this test is a multi-thread test which >>> is not MT-safe. >> OK I am convinced: >> http://cr.openjdk.java.net/~sjiang/JDK-8025206/02/ > > The volatile is definitely needed if the field is written/read by > different threads. > > I think the rule is to not use @author tags in OpenJDK code. > > This comment is not needed: > > 288 // See 8025206 > > but I think the bug number should be added to the @bug line. > > Otherwise seems reasonable. > > Reviewed. Thanks for the review, I will remove Line 288 // See 8025206 but add the bug id to @bug Shanliang > > David From david.holmes at oracle.com Wed Oct 9 03:23:54 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 09 Oct 2013 20:23:54 +1000 Subject: [ping][ping] Re: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <5253ED95.20706@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> <5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com> <5231DE69.7090309@oracle.com> <523B0B30.4020003@oracle.com> <5252C1B6.2060904@oracle.com> <52537F36.8020001@oracle.com> <5253ED95.20706@oracle.com> Message-ID: <52552EBA.4060308@oracle.com> Jaroslav, Thanks for the details description of changes - much appreciated. There is a lot to digest in there. :) It isn't obvious to me why these tests require a full JDK? I don't quite follow the libjvm lookup logic - I would expect that you would always want to test the libjvm that is currently running - though it is hard to determine that. Thanks, David On 8/10/2013 9:33 PM, Jaroslav Bachorik wrote: > On 8.10.2013 05:42, David Holmes wrote: >> Jaroslav, >> >> Can you summarise the changes please? With the conversion to Java and >> the infrastructure additions I can't tell what is actually fixing the >> original timeout issue :) > > The timeout was most caused by using the same file for communication > between java processes in more test cases. When those test cases were > run in parallel the file got rewritten silently and some of the tests > could end up trying to connect to incorrect port in the target > application. I was able to reproduce the timeout by interleaving the > test runs for CustomLauncherTest.sh and LocalManagementTest.sh and > adding an artificial delay to CusteomLauncherTest.sh to allow > LocalManagementTest.sh to change the port in the file. > > While it could be fixed by using a different file for each test case I > took the liberty of converting the shell tests to java tests. This > allows me to remove the communication file and, in the end, make the > tests more robust. > > CustomLauncherTest.java and LocalManagementTest.java are the tests > converted from shell to java. I decided to convert > LocalManagementTest.sh as well because it has the same problems as the > CustomLauncherTest.sh. > > The changes in the testlibrary are about introducing new methods > allowing the tests easily start a process and wait for a certain text > appearing in its stdout/stderr. Using these methods the caller can wait > till the callee is fully initialized and eg. ready to accept connections. > > The changes in launchers make the launchers actually executable + I am > adding a linux-amd64 launcher (I needed that one to work on the changes > locally and thought it might be nice to have one more platform covered > by the test). > > I've update the webrev to include changes to LocalManagementTest and > TEST.groups (both of those tests require JDK) - > http://cr.openjdk.java.net/~jbachorik/8004926/webrev.05 > > -JB- > >> >> Thanks, >> David >> >> On 8/10/2013 12:14 AM, Jaroslav Bachorik wrote: >>> On 19.9.2013 16:33, Jaroslav Bachorik wrote: >>>> The updated webrev: >>>> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.03 >>>> >>>> I've moved some of the functionality to the testlibrary. >>>> >>>> -JB - >>>> >>>> On 12.9.2013 17:31, Jaroslav Bachorik wrote: >>>>> On 09/12/2013 05:13 PM, Dmitry Samersoff wrote: >>>>>> Jaroslav, >>>>>> >>>>>> CustomLauncherTest.java: >>>>>> >>>>>> 102: this check could be moved to switch at ll. 108 >>>>>> otherwise test fails on "sunos" and "linux" because PLATFORM remains >>>>>> unset. >>>>> Good idea. Thanks. >>>>> >>>>>> 129: I would prefer don't have pattern like this one ever in shell >>>>>> script. Could you prepare a list of VM's to check and just loop over >>>>>> it? >>>>>> It makes test better readable. Also I think nowdays we can always use >>>>>> server VM. >>>>> I tried to mirror the original shell test as closely as possible. It >>>>> would be nice if we could rely on the "server" vm only. Definitely >>>>> more >>>>> readable. >>>>> >>>>> -JB- >>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2013-09-12 18:17, Jaroslav Bachorik wrote: >>>>>>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: >>>>>>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote: >>>>>>>>> On 09/12/2013 04:45 AM, David Holmes wrote: >>>>>>>>>> Hi Jaroslav, >>>>>>>>>> >>>>>>>>>> You need a copyright notice in the new file. >>>>>>>>>> >>>>>>>>>> As written this test can only run on a full JDK - so please add >>>>>>>>>> it to >>>>>>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to >>>>>>>>>> come >>>>>>>>>> from the test-jdk? And use the VMOPTS passed to the test?) >>>>>>>>>> >>>>>>>>>> Is there a reason this test can't run on OSX? I know it would >>>>>>>>>> need >>>>>>>>>> further modification but was wondering if there is something >>>>>>>>>> inherent in >>>>>>>>>> the test that makes it inapplicable to OSX. >>>>>>>>>> >>>>>>>>>> I think the test would be a lot simpler if the jdk tests had the >>>>>>>>>> hotspot >>>>>>>>>> test library's process tools available. :( >>>>>>>>> We have some, is there an obvious gap? >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Hm, thanks for the info. I should have used this library instead. >>>>>>>> >>>>>>>> Please, stand by for the updated webrev. >>>>>>> I was able to get rid off the JCMD. Using the testlibrary the target >>>>>>> application can recognize its own PID and print it to its stdout. >>>>>>> The >>>>>>> main application then just reads the stdout to parse the PID. No >>>>>>> need >>>>>>> for JCMD any more. >>>>>>> >>>>>>> I could not find a way to remove the dependency on "test.jdk" system >>>>>>> property. According to the jtreg web documentation >>>>>>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a >>>>>>> "test.java" >>>>>>> system property should be available but in fact is not. But it seems >>>>>>> that the testlibrary uses "test.jdk" system property too. >>>>>>> >>>>>>> The test does not run on OSX because nobody built the launcher >>>>>>> binary :) >>>>>>> I think it is a kind of DIY so I took the liberty of adding a >>>>>>> linux-amd64 launcher while working on the test. >>>>>>> >>>>>>> While working with the test library I realized I was missing a >>>>>>> crucial >>>>>>> feature (at least for my purposes) - waiting for a certain >>>>>>> message to >>>>>>> appear in the stdout/stderr of the launched process. Very often I >>>>>>> need >>>>>>> to wait for the target process to get to certain point before the >>>>>>> test >>>>>>> can be allowed to continue - and the point is indicated by a >>>>>>> message in >>>>>>> stdout/stderr. Currently all the proc tools are designed to work in >>>>>>> "batch" mode - the whole stdout/stderr is captured in strings and >>>>>>> analyzed after the target process died - and are not suitable for >>>>>>> this >>>>>>> kind of usage. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 >>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>>> >>>>>>>>> -Chris. >>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>>>>>>>>> Please, review the patch for an intermittently failing test. >>>>>>>>>>> >>>>>>>>>>> The test is a shell test, using files for the interprocess >>>>>>>>>>> synchronization. This leads to intermittent failures. >>>>>>>>>>> >>>>>>>>>>> In order to fix this the test is rewritten in Java - the >>>>>>>>>>> original >>>>>>>>>>> functionality and outputs should be 100% preserved. The patch is >>>>>>>>>>> unfortunately a bit difficult to follow since there is no >>>>>>>>>>> similarity >>>>>>>>>>> between the *.sh and *.java file so one needs to go through the >>>>>>>>>>> new >>>>>>>>>>> source in whole. >>>>>>>>>>> >>>>>>>>>>> The changes in "launcher" files are all about adding >>>>>>>>>>> permissions to >>>>>>>>>>> execute (0755) and as such the webrev shows no differences. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Issue : JDK-8004926 >>>>>>>>>>> Webrev : http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>> >>>> >>> > From vincent.x.ryan at oracle.com Wed Oct 9 03:50:46 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Wed, 09 Oct 2013 10:50:46 +0000 Subject: hg: jdk8/tl/jdk: 8008171: Refactor KeyStore.DomainLoadStoreParameter as a standalone class Message-ID: <20131009105101.6D73A62E7F@hg.openjdk.java.net> Changeset: 91a752e3d50b Author: vinnie Date: 2013-10-09 10:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/91a752e3d50b 8008171: Refactor KeyStore.DomainLoadStoreParameter as a standalone class Reviewed-by: mullan, weijun + src/share/classes/java/security/DomainLoadStoreParameter.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/sun/security/provider/DomainKeyStore.java ! test/sun/security/provider/KeyStore/DKSTest.java From jan.lahoda at oracle.com Wed Oct 9 04:13:15 2013 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Wed, 09 Oct 2013 11:13:15 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20131009111321.C1A1D62E81@hg.openjdk.java.net> Changeset: 0be3f1820e8b Author: jlahoda Date: 2013-10-09 13:06 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0be3f1820e8b 8025141: java.lang.ClassFormatError: Illegal field modifiers in class (...) Summary: Should not generate non-public $assertionsDisabled field into interfaces Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/defaultMethods/Assertions.java + test/tools/javac/defaultMethods/CannotChangeAssertionsStateAfterInitialized.java Changeset: 1b469fd31e35 Author: jlahoda Date: 2013-10-09 13:09 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1b469fd31e35 8025087: Annotation processing api returns default modifier for interface static method Summary: ClassReader must not set Flags.DEFAULT for interface static methods Reviewed-by: vromero, jjg ! make/build.xml ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/defaultMethods/BadClassfile.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/InvalidDefaultInterface/InvalidDefaultInterface.java + test/tools/javac/diags/examples/InvalidDefaultInterface/processors/CreateBadClassFile.java + test/tools/javac/diags/examples/InvalidStaticInterface/InvalidStaticInterface.java + test/tools/javac/diags/examples/InvalidStaticInterface/processors/CreateBadClassFile.java ! test/tools/javac/processing/model/element/TestExecutableElement.java From jaroslav.bachorik at oracle.com Wed Oct 9 04:26:27 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 09 Oct 2013 13:26:27 +0200 Subject: RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <52547D24.9060806@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> Message-ID: <52553D63.5000508@oracle.com> On 8.10.2013 23:46, David Holmes wrote: > On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >> On 8.10.2013 09:34, David Holmes wrote: >>> Jaroslav, >>> >>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>> Hello, >>>> >>>> currently the JVM uptime reported by the RuntimeMXBean is based on >>>> System.currentTimeMillis() which makes it susceptible to changes of the >>>> OS time (eg. changing timezone, NTP synchronization etc.). The uptime >>>> should not depend on the system time and should be calculated using a >>>> monotonic clock source. >>>> >>>> There is already the way to get the actual JVM uptime in ticks. It is >>>> accessible as Management::timestamp() and the ticks are convertible to >>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus making it >>>> very >>>> easy to switch to the monotonic clock based uptime. >>> >>> Maybe I'm missing something but TiumeStamp updates using >>> os::elapsed_counter() which on Linux uses gettimeofday so is not a >>> monotonic clock source. >> >> Hm, yes. I wasn't aware of this linux/bsd specific. >> >> Is there any reason why a non monotonic clock source is used for >> timestamping except of the historical one? os::javaTimeNanos() uses >> montonic clock when available - why can't be the same used for >> os::elapsed_counter() especially when a counter based on "gettimeofday" >> is not really a counter? > > It is all historical. These elapsed_counters and elapsed_timers make me > cringe. But changing it has a lot of potential consequences because of > the way these are used in logging etc. Certainly not something to be > contemplated at this stage of JDK 8. > > Perhaps a simpler fix here is to expose a startUpTimeNanos that can then > be used for the uptime. My attempt at this is at http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot I am using os::javaTimeNanos() to get the monotonic ticks where possible. The JDK part stays the same as for webrev.00 -JB- > > David > >> -JB- >> >>> >>> David >>> ----- >>> >>> >>> >>>> The patch consists of the hotspot and jdk parts. >>>> >>>> For the hotspot a new constant needs to be introduced in >>>> src/share/vm/services/jmm.h and the actual logic to obtain the >>>> uptime in >>>> milliseconds is added in src/share/vm/services/management.cpp. >>>> >>>> For the jdk the changes comprise of adding the necessary JNI bridging >>>> methods in order to get the new uptime, introducing the same constant >>>> that is used in hotspot and changes to mapfile-vers files in order to >>>> properly build the native library. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>> >>>> Thanks, >>>> >>>> -JB- >> From jaroslav.bachorik at oracle.com Wed Oct 9 04:31:57 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 09 Oct 2013 13:31:57 +0200 Subject: [ping][ping] Re: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <52552EBA.4060308@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> <5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com> <5231DE69.7090309@oracle.com> <523B0B30.4020003@oracle.com> <5252C1B6.2060904@oracle.com> <52537F36.8020001@oracle.com> <5253ED95.20706@oracle.com> <52552EBA.4060308@oracle.com> Message-ID: <52553EAD.4040506@oracle.com> On 9.10.2013 12:23, David Holmes wrote: > Jaroslav, > > Thanks for the details description of changes - much appreciated. > > There is a lot to digest in there. :) Yep, it started as a simple fix :/ > > It isn't obvious to me why these tests require a full JDK? IDK, LocalManagementTest.sh was listed as one requiring full JDK. Its requirements are the same as the ones of CustomLauncherTest.sh (now *.java) so it seemed logical to list it there too. > > I don't quite follow the libjvm lookup logic - I would expect that you > would always want to test the libjvm that is currently running - though > it is hard to determine that. I'm afraid I can't be of much assistance here - I just took what was in the *.sh version and converted it to *.java. -JB- > > Thanks, > David > > On 8/10/2013 9:33 PM, Jaroslav Bachorik wrote: >> On 8.10.2013 05:42, David Holmes wrote: >>> Jaroslav, >>> >>> Can you summarise the changes please? With the conversion to Java and >>> the infrastructure additions I can't tell what is actually fixing the >>> original timeout issue :) >> >> The timeout was most caused by using the same file for communication >> between java processes in more test cases. When those test cases were >> run in parallel the file got rewritten silently and some of the tests >> could end up trying to connect to incorrect port in the target >> application. I was able to reproduce the timeout by interleaving the >> test runs for CustomLauncherTest.sh and LocalManagementTest.sh and >> adding an artificial delay to CusteomLauncherTest.sh to allow >> LocalManagementTest.sh to change the port in the file. >> >> While it could be fixed by using a different file for each test case I >> took the liberty of converting the shell tests to java tests. This >> allows me to remove the communication file and, in the end, make the >> tests more robust. >> >> CustomLauncherTest.java and LocalManagementTest.java are the tests >> converted from shell to java. I decided to convert >> LocalManagementTest.sh as well because it has the same problems as the >> CustomLauncherTest.sh. >> >> The changes in the testlibrary are about introducing new methods >> allowing the tests easily start a process and wait for a certain text >> appearing in its stdout/stderr. Using these methods the caller can wait >> till the callee is fully initialized and eg. ready to accept connections. >> >> The changes in launchers make the launchers actually executable + I am >> adding a linux-amd64 launcher (I needed that one to work on the changes >> locally and thought it might be nice to have one more platform covered >> by the test). >> >> I've update the webrev to include changes to LocalManagementTest and >> TEST.groups (both of those tests require JDK) - >> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.05 >> >> -JB- >> >>> >>> Thanks, >>> David >>> >>> On 8/10/2013 12:14 AM, Jaroslav Bachorik wrote: >>>> On 19.9.2013 16:33, Jaroslav Bachorik wrote: >>>>> The updated webrev: >>>>> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.03 >>>>> >>>>> I've moved some of the functionality to the testlibrary. >>>>> >>>>> -JB - >>>>> >>>>> On 12.9.2013 17:31, Jaroslav Bachorik wrote: >>>>>> On 09/12/2013 05:13 PM, Dmitry Samersoff wrote: >>>>>>> Jaroslav, >>>>>>> >>>>>>> CustomLauncherTest.java: >>>>>>> >>>>>>> 102: this check could be moved to switch at ll. 108 >>>>>>> otherwise test fails on "sunos" and "linux" because PLATFORM remains >>>>>>> unset. >>>>>> Good idea. Thanks. >>>>>> >>>>>>> 129: I would prefer don't have pattern like this one ever in shell >>>>>>> script. Could you prepare a list of VM's to check and just loop over >>>>>>> it? >>>>>>> It makes test better readable. Also I think nowdays we can always >>>>>>> use >>>>>>> server VM. >>>>>> I tried to mirror the original shell test as closely as possible. It >>>>>> would be nice if we could rely on the "server" vm only. Definitely >>>>>> more >>>>>> readable. >>>>>> >>>>>> -JB- >>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> On 2013-09-12 18:17, Jaroslav Bachorik wrote: >>>>>>>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: >>>>>>>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote: >>>>>>>>>> On 09/12/2013 04:45 AM, David Holmes wrote: >>>>>>>>>>> Hi Jaroslav, >>>>>>>>>>> >>>>>>>>>>> You need a copyright notice in the new file. >>>>>>>>>>> >>>>>>>>>>> As written this test can only run on a full JDK - so please add >>>>>>>>>>> it to >>>>>>>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to >>>>>>>>>>> come >>>>>>>>>>> from the test-jdk? And use the VMOPTS passed to the test?) >>>>>>>>>>> >>>>>>>>>>> Is there a reason this test can't run on OSX? I know it would >>>>>>>>>>> need >>>>>>>>>>> further modification but was wondering if there is something >>>>>>>>>>> inherent in >>>>>>>>>>> the test that makes it inapplicable to OSX. >>>>>>>>>>> >>>>>>>>>>> I think the test would be a lot simpler if the jdk tests had the >>>>>>>>>>> hotspot >>>>>>>>>>> test library's process tools available. :( >>>>>>>>>> We have some, is there an obvious gap? >>>>>>>>>> >>>>>>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Hm, thanks for the info. I should have used this library instead. >>>>>>>>> >>>>>>>>> Please, stand by for the updated webrev. >>>>>>>> I was able to get rid off the JCMD. Using the testlibrary the >>>>>>>> target >>>>>>>> application can recognize its own PID and print it to its stdout. >>>>>>>> The >>>>>>>> main application then just reads the stdout to parse the PID. No >>>>>>>> need >>>>>>>> for JCMD any more. >>>>>>>> >>>>>>>> I could not find a way to remove the dependency on "test.jdk" >>>>>>>> system >>>>>>>> property. According to the jtreg web documentation >>>>>>>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a >>>>>>>> "test.java" >>>>>>>> system property should be available but in fact is not. But it >>>>>>>> seems >>>>>>>> that the testlibrary uses "test.jdk" system property too. >>>>>>>> >>>>>>>> The test does not run on OSX because nobody built the launcher >>>>>>>> binary :) >>>>>>>> I think it is a kind of DIY so I took the liberty of adding a >>>>>>>> linux-amd64 launcher while working on the test. >>>>>>>> >>>>>>>> While working with the test library I realized I was missing a >>>>>>>> crucial >>>>>>>> feature (at least for my purposes) - waiting for a certain >>>>>>>> message to >>>>>>>> appear in the stdout/stderr of the launched process. Very often I >>>>>>>> need >>>>>>>> to wait for the target process to get to certain point before the >>>>>>>> test >>>>>>>> can be allowed to continue - and the point is indicated by a >>>>>>>> message in >>>>>>>> stdout/stderr. Currently all the proc tools are designed to work in >>>>>>>> "batch" mode - the whole stdout/stderr is captured in strings and >>>>>>>> analyzed after the target process died - and are not suitable for >>>>>>>> this >>>>>>>> kind of usage. >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 >>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Chris. >>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>>>>>>>>>> Please, review the patch for an intermittently failing test. >>>>>>>>>>>> >>>>>>>>>>>> The test is a shell test, using files for the interprocess >>>>>>>>>>>> synchronization. This leads to intermittent failures. >>>>>>>>>>>> >>>>>>>>>>>> In order to fix this the test is rewritten in Java - the >>>>>>>>>>>> original >>>>>>>>>>>> functionality and outputs should be 100% preserved. The >>>>>>>>>>>> patch is >>>>>>>>>>>> unfortunately a bit difficult to follow since there is no >>>>>>>>>>>> similarity >>>>>>>>>>>> between the *.sh and *.java file so one needs to go through the >>>>>>>>>>>> new >>>>>>>>>>>> source in whole. >>>>>>>>>>>> >>>>>>>>>>>> The changes in "launcher" files are all about adding >>>>>>>>>>>> permissions to >>>>>>>>>>>> execute (0755) and as such the webrev shows no differences. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Issue : JDK-8004926 >>>>>>>>>>>> Webrev : >>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>>>>>>>>>> >>>>>>>>>>>> -JB- >>>>>>>>>>>> >>>>>>> >>>>> >>>> >> From david.holmes at oracle.com Wed Oct 9 05:02:43 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 09 Oct 2013 22:02:43 +1000 Subject: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <52548E6D.80701@oracle.com> References: <523D144E.4000002@oracle.com> <524B8A78.9040807@oracle.com> <52548E6D.80701@oracle.com> Message-ID: <525545E3.3060504@oracle.com> inline ... On 9/10/2013 8:59 AM, Daniel D. Daugherty wrote: > On 10/1/13 8:52 PM, David Holmes wrote: >> - hotspot/make/Makefile >> >> + $(EXPORT_CLIENT_DIR)/%.dSYM: $(MINIMAL1_BUILD_DIR)/%.dSYM >> >> EXPORT_CLIENT_DIR should be EXPORT_MINIMAL_DIR. >> >> For fun you can try building minimal on OSX, but I don't know how far >> you will get: >> >> --with-jvm-variants=client,server,minimal1 >> >> I'll point out obvious issues with minimal VM support anyway. > > Since you pointed out in a later email that minimal1 isn't > supported on MacOS X, I'm going to drop those changes. I'm > going to leave the Client VM support since there are folks > out in OpenJDK trying to get the Client VM working on MacOS X. > > It does look like someone added minimal1 support for other > non-Linux platforms, but I'm not planning to clean that up. Yes I did that when adding minimal support. Seemed better than leaving someone to have to rediscover what needed to be implemented if/when minimal support was expanded. Someday I hope to remove all the duplicated EXPORT_* stuff and generate it based on the requested JDK_VARIANT_* values. And do it in a platform indpendent way - once! :) >> Note that the whole jdk6_or_earlier logic is defunct as this will >> never be used for jdk6 or earlier. But best to clean all that up at >> the one time. > > Agreed that we (Oracle) currently don't have plans to drop HSX-25 into > JDK6 or OpenJDK6, but I don't want to rule out future insanity. I do! We need to cut ties with historical baggage. >> - make/bsd/makefiles/universal.gmk >> >> I did not understand the additional logic here: >> >> 63 # Copy built non-universal binaries in place >> 64 $(UNIVERSAL_COPY_LIST): >> 65 BUILT_COPY_FILES="`find >> $(EXPORT_JRE_LIB_DIR)/{i386,amd64}/$(subst $(EXPORT_JRE_LIB_DIR)/,,$@) >> 2>/dev/null`"; \ >> 66 if [ -n "$${BUILT_COPY_FILES}" ]; then \ >> 67 for i in $${BUILT_COPY_FILES}; do \ >> 68 if [ -f $${i} ]; then \ >> 69 $(MKDIR) -p $(shell dirname $@); \ >> 70 $(CP) -R $${i} $@; \ >> 71 fi; \ >> 72 if [ -d $${i} ]; then \ >> 73 $(MKDIR) -p $@; \ >> 74 fi; \ >> 75 done; \ >> 76 fi >> >> until I realized that foo.dSYM is a directory not a file! Even so >> don't you want to copy the contents of the directory across ? > > BUILT_COPY_FILES includes both files and directories so everything > should get copied across. I've added some commments to the rule > header and reorganized the logic a bit to hopefully be more clear. Doesn't this assume that the directory will appear before the files within it? Is that guaranteed? Which leads me to ask why we have cp -R for copying files? >> - jdk/makefiles/Tools.gmk >> >> Not sure about this one. Logically is seems correct but up to now this >> has been defined for everything without it seeming to cause a problem. >> So why do we need to change it and what impact will it have? > > It just seemed wrong to define something that should never be used > on non-Solaris platforms. My control build of the entire forest > didn't have an issue with this change so I'm planning to keep it. Ok. Thanks, David > Dan > > > >> >> David >> ----- >> >> On 21/09/2013 1:36 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have the initial support for Full Debug Symbols (FDS) on MacOS X done >>> and ready for review: >>> >>> 7165611 implement Full Debug Symbols on MacOS X hotspot >>> https://bugs.openjdk.java.net/browse/JDK-7165611 >>> >>> Here is the JDK8/HSX-25 webrev URL: >>> >>> OpenJDK: >>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >>> Internal: >>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >>> >>> This webrev includes changes for the follow repos: >>> >>> jdk8 >>> jdk8/hotspot >>> jdk8/jdk >>> jdk8/jdk/make/closed >>> >>> Once these changes are approved, I'm planning to push them to >>> RT_Baseline. From there, they can follow the normal path to >>> Main_Baseline and eventually JDK8. >>> >>> This work enables FDS on MacOS X for the 'hotspot' repo; the changes in >>> the other repos are necessary to support importing the .diz files from >>> the MacOS X 'hotspot' build into the forest build. I also fixed a few >>> FDS related errors in the magic incantations for the new build. This is >>> mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported >>> from Solaris. In other words, this is Frankenstein's monster... >>> >>> Thanks to Staffan Larsen for providing an initial set of changes >>> which I morphed into what you see here. >>> >>> Testing: >>> - JPRT HSX build and test on all platforms; verification of .diz >>> files in the MacOS X JPRT bundles >>> - JPRT JDK8 forest build and test on all platforms; verification of >>> .diz files in the MacOS X JPRT bundles >>> Note: In previous FDS changesets, I also did a standalone 'jdk' >>> repo build and test, but that no longer seems to work. >>> >>> As always, comments, questions and suggestions are welcome. >>> >>> Dan > From sundararajan.athijegannathan at oracle.com Wed Oct 9 06:08:35 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 09 Oct 2013 13:08:35 +0000 Subject: hg: jdk8/tl/nashorn: 3 new changesets Message-ID: <20131009130838.EBB9962E8A@hg.openjdk.java.net> Changeset: 8d29733ad609 Author: sundar Date: 2013-10-09 10:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8d29733ad609 8026112: Function("with(x ? 1e81 : (x2.constructor = 0.1)){}") throws AssertionError: double is not compatible with object Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8026112.js Changeset: 1e03d7caa68b Author: sundar Date: 2013-10-09 13:26 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1e03d7caa68b 8026125: Array.prototype.slice.call(Java.type("java.util.HashMap")) throws ClassCastException: jdk.internal.dynalink.beans.StaticClass cannot be cast to jdk.nashorn.internal.runtime.ScriptObject Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8026125.js Changeset: ec3094d9d5d5 Author: hannesw Date: 2013-10-09 14:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ec3094d9d5d5 8026008: Constant folding removes var statement Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/FoldConstants.java + test/script/basic/JDK-8026008.js + test/script/basic/JDK-8026008.js.EXPECTED From paul.sandoz at oracle.com Wed Oct 9 06:20:46 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 09 Oct 2013 13:20:46 +0000 Subject: hg: jdk8/tl/jdk: 8020061: Clarify reporting characteristics between splits Message-ID: <20131009132111.4767F62E8D@hg.openjdk.java.net> Changeset: 1cd20806fd5c Author: psandoz Date: 2013-10-09 15:19 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1cd20806fd5c 8020061: Clarify reporting characteristics between splits Reviewed-by: alanb, chegar ! src/share/classes/java/util/Spliterator.java From mandy.chung at oracle.com Wed Oct 9 06:27:21 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 09 Oct 2013 13:27:21 +0000 Subject: hg: jdk8/tl/jdk: 8026027: Level.parse should return the custom Level instance instead of the mirrored Level Message-ID: <20131009132733.D27DC62E8E@hg.openjdk.java.net> Changeset: cf6e39cfdf50 Author: mchung Date: 2013-10-09 06:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf6e39cfdf50 8026027: Level.parse should return the custom Level instance instead of the mirrored Level Reviewed-by: dfuchs, chegar ! src/share/classes/java/util/logging/Level.java + test/java/util/logging/Level/CustomLevel.java + test/java/util/logging/Level/myresource.properties From staffan.larsen at oracle.com Wed Oct 9 07:10:45 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 9 Oct 2013 16:10:45 +0200 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <52553D63.5000508@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> Message-ID: <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> There is now an awful amount of different timestamps in the Management class. Can they be consolidated somehow? At least _begin_vm_creation_time and the new _begin_vm_creation_ns. This discussion also implies that the "elapsed time" we print in the hs_err file is also wrong. It uses os::elapsedTime() which uses os::elapsed_counter(). And I guess the same thing for the VM.uptime Diagnostic Command (class VMUptimeDCmd) which also relies on os::elapsed_counter(). /Staffan On 9 okt 2013, at 13:26, Jaroslav Bachorik wrote: > On 8.10.2013 23:46, David Holmes wrote: >> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>> On 8.10.2013 09:34, David Holmes wrote: >>>> Jaroslav, >>>> >>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>> Hello, >>>>> >>>>> currently the JVM uptime reported by the RuntimeMXBean is based on >>>>> System.currentTimeMillis() which makes it susceptible to changes of the >>>>> OS time (eg. changing timezone, NTP synchronization etc.). The uptime >>>>> should not depend on the system time and should be calculated using a >>>>> monotonic clock source. >>>>> >>>>> There is already the way to get the actual JVM uptime in ticks. It is >>>>> accessible as Management::timestamp() and the ticks are convertible to >>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus making it >>>>> very >>>>> easy to switch to the monotonic clock based uptime. >>>> >>>> Maybe I'm missing something but TiumeStamp updates using >>>> os::elapsed_counter() which on Linux uses gettimeofday so is not a >>>> monotonic clock source. >>> >>> Hm, yes. I wasn't aware of this linux/bsd specific. >>> >>> Is there any reason why a non monotonic clock source is used for >>> timestamping except of the historical one? os::javaTimeNanos() uses >>> montonic clock when available - why can't be the same used for >>> os::elapsed_counter() especially when a counter based on "gettimeofday" >>> is not really a counter? >> >> It is all historical. These elapsed_counters and elapsed_timers make me >> cringe. But changing it has a lot of potential consequences because of >> the way these are used in logging etc. Certainly not something to be >> contemplated at this stage of JDK 8. >> >> Perhaps a simpler fix here is to expose a startUpTimeNanos that can then >> be used for the uptime. > > My attempt at this is at http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot > I am using os::javaTimeNanos() to get the monotonic ticks where possible. > > The JDK part stays the same as for webrev.00 > > -JB- > >> >> David >> >>> -JB- >>> >>>> >>>> David >>>> ----- >>>> >>>> >>>> >>>>> The patch consists of the hotspot and jdk parts. >>>>> >>>>> For the hotspot a new constant needs to be introduced in >>>>> src/share/vm/services/jmm.h and the actual logic to obtain the >>>>> uptime in >>>>> milliseconds is added in src/share/vm/services/management.cpp. >>>>> >>>>> For the jdk the changes comprise of adding the necessary JNI bridging >>>>> methods in order to get the new uptime, introducing the same constant >>>>> that is used in hotspot and changes to mapfile-vers files in order to >>>>> properly build the native library. >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>> > From jaroslav.bachorik at oracle.com Wed Oct 9 07:19:48 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 09 Oct 2013 16:19:48 +0200 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> Message-ID: <52556604.3080900@oracle.com> On 9.10.2013 16:10, Staffan Larsen wrote: > There is now an awful amount of different timestamps in the Management class. Can they be consolidated somehow? At least _begin_vm_creation_time and the new _begin_vm_creation_ns. > > This discussion also implies that the "elapsed time" we print in the hs_err file is also wrong. It uses os::elapsedTime() which uses os::elapsed_counter(). > > And I guess the same thing for the VM.uptime Diagnostic Command (class VMUptimeDCmd) which also relies on os::elapsed_counter(). Also the reported GC pauses duration might be wrong since it uses Management::timestamp(). On the first sight the change looks rather trivial. But, honestly, I'm not sure which other parts could for whatever reason break once the time-of-day timestamp is replaced with a monotonic equivalent. One would think that it shouldn't matter but one never knows ... Staffan, do you think this kind of change is suitable for the current phase of JDK release cycle? I think I could improve the patch in few days and then it should probably be able to pass the review before ZBB. But, it's only P3 ... -JB- > > /Staffan > > > On 9 okt 2013, at 13:26, Jaroslav Bachorik wrote: > >> On 8.10.2013 23:46, David Holmes wrote: >>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>> On 8.10.2013 09:34, David Holmes wrote: >>>>> Jaroslav, >>>>> >>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>> Hello, >>>>>> >>>>>> currently the JVM uptime reported by the RuntimeMXBean is based on >>>>>> System.currentTimeMillis() which makes it susceptible to changes of the >>>>>> OS time (eg. changing timezone, NTP synchronization etc.). The uptime >>>>>> should not depend on the system time and should be calculated using a >>>>>> monotonic clock source. >>>>>> >>>>>> There is already the way to get the actual JVM uptime in ticks. It is >>>>>> accessible as Management::timestamp() and the ticks are convertible to >>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus making it >>>>>> very >>>>>> easy to switch to the monotonic clock based uptime. >>>>> >>>>> Maybe I'm missing something but TiumeStamp updates using >>>>> os::elapsed_counter() which on Linux uses gettimeofday so is not a >>>>> monotonic clock source. >>>> >>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>> >>>> Is there any reason why a non monotonic clock source is used for >>>> timestamping except of the historical one? os::javaTimeNanos() uses >>>> montonic clock when available - why can't be the same used for >>>> os::elapsed_counter() especially when a counter based on "gettimeofday" >>>> is not really a counter? >>> >>> It is all historical. These elapsed_counters and elapsed_timers make me >>> cringe. But changing it has a lot of potential consequences because of >>> the way these are used in logging etc. Certainly not something to be >>> contemplated at this stage of JDK 8. >>> >>> Perhaps a simpler fix here is to expose a startUpTimeNanos that can then >>> be used for the uptime. >> >> My attempt at this is at http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >> I am using os::javaTimeNanos() to get the monotonic ticks where possible. >> >> The JDK part stays the same as for webrev.00 >> >> -JB- >> >>> >>> David >>> >>>> -JB- >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>> >>>>>> The patch consists of the hotspot and jdk parts. >>>>>> >>>>>> For the hotspot a new constant needs to be introduced in >>>>>> src/share/vm/services/jmm.h and the actual logic to obtain the >>>>>> uptime in >>>>>> milliseconds is added in src/share/vm/services/management.cpp. >>>>>> >>>>>> For the jdk the changes comprise of adding the necessary JNI bridging >>>>>> methods in order to get the new uptime, introducing the same constant >>>>>> that is used in hotspot and changes to mapfile-vers files in order to >>>>>> properly build the native library. >>>>>> >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>> >> > From daniel.daugherty at oracle.com Wed Oct 9 08:03:01 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 09 Oct 2013 09:03:01 -0600 Subject: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <525545E3.3060504@oracle.com> References: <523D144E.4000002@oracle.com> <524B8A78.9040807@oracle.com> <52548E6D.80701@oracle.com> <525545E3.3060504@oracle.com> Message-ID: <52557025.7060706@oracle.com> Replies also inline... On 10/9/13 6:02 AM, David Holmes wrote: > inline ... > > On 9/10/2013 8:59 AM, Daniel D. Daugherty wrote: >> On 10/1/13 8:52 PM, David Holmes wrote: >>> - hotspot/make/Makefile >>> >>> + $(EXPORT_CLIENT_DIR)/%.dSYM: $(MINIMAL1_BUILD_DIR)/%.dSYM >>> >>> EXPORT_CLIENT_DIR should be EXPORT_MINIMAL_DIR. >>> >>> For fun you can try building minimal on OSX, but I don't know how far >>> you will get: >>> >>> --with-jvm-variants=client,server,minimal1 >>> >>> I'll point out obvious issues with minimal VM support anyway. >> >> Since you pointed out in a later email that minimal1 isn't >> supported on MacOS X, I'm going to drop those changes. I'm >> going to leave the Client VM support since there are folks >> out in OpenJDK trying to get the Client VM working on MacOS X. >> >> It does look like someone added minimal1 support for other >> non-Linux platforms, but I'm not planning to clean that up. > > Yes I did that when adding minimal support. Seemed better than leaving > someone to have to rediscover what needed to be implemented if/when > minimal support was expanded. Thanks for the history. Are you still OK if I leave out the FDS Minimal1 support? > Someday I hope to remove all the duplicated EXPORT_* stuff and > generate it based on the requested JDK_VARIANT_* values. And do it in > a platform indpendent way - once! :) Well it can be mostly platform independent, but there will be minor differences in what is exported by the different platforms. > >>> Note that the whole jdk6_or_earlier logic is defunct as this will >>> never be used for jdk6 or earlier. But best to clean all that up at >>> the one time. >> >> Agreed that we (Oracle) currently don't have plans to drop HSX-25 into >> JDK6 or OpenJDK6, but I don't want to rule out future insanity. > > I do! We need to cut ties with historical baggage. Good sentiment, but not for this changeset. I'll file a bug to track your idea of "best to clean all that up at one time". > >>> - make/bsd/makefiles/universal.gmk >>> >>> I did not understand the additional logic here: >>> >>> 63 # Copy built non-universal binaries in place >>> 64 $(UNIVERSAL_COPY_LIST): >>> 65 BUILT_COPY_FILES="`find >>> $(EXPORT_JRE_LIB_DIR)/{i386,amd64}/$(subst $(EXPORT_JRE_LIB_DIR)/,,$@) >>> 2>/dev/null`"; \ >>> 66 if [ -n "$${BUILT_COPY_FILES}" ]; then \ >>> 67 for i in $${BUILT_COPY_FILES}; do \ >>> 68 if [ -f $${i} ]; then \ >>> 69 $(MKDIR) -p $(shell dirname $@); \ >>> 70 $(CP) -R $${i} $@; \ >>> 71 fi; \ >>> 72 if [ -d $${i} ]; then \ >>> 73 $(MKDIR) -p $@; \ >>> 74 fi; \ >>> 75 done; \ >>> 76 fi >>> >>> until I realized that foo.dSYM is a directory not a file! Even so >>> don't you want to copy the contents of the directory across ? >> >> BUILT_COPY_FILES includes both files and directories so everything >> should get copied across. I've added some commments to the rule >> header and reorganized the logic a bit to hopefully be more clear. > > Doesn't this assume that the directory will appear before the files > within it? Is that guaranteed? The way find works is that it lists the directory prior to listing the files within the directory. However, even if find didn't, the containing directory would be created via line 69 above. The one non-obvious feature of lines 72-74 is that an empty directory named in the BUILD_COPY_FILES list would get 'copied' to the destination. Please check out the latest version when I get it out for review. > Which leads me to ask why we have cp -R for copying files? MacOS X strongly discourages use of 'cp -r' and recommends 'cp -R' instead because 'cp -R' properly copies non-directory and non-file file system objects, e.g., symlinks. So if BUILD_COPY_FILES happens to contain a symlink, then the symlink is copied to the destination. > >>> - jdk/makefiles/Tools.gmk >>> >>> Not sure about this one. Logically is seems correct but up to now this >>> has been defined for everything without it seeming to cause a problem. >>> So why do we need to change it and what impact will it have? >> >> It just seemed wrong to define something that should never be used >> on non-Solaris platforms. My control build of the entire forest >> didn't have an issue with this change so I'm planning to keep it. > > Ok. > > Thanks, > David Again, thanks for the thorough reviews. Dan > >> Dan >> >> >> >>> >>> David >>> ----- >>> >>> On 21/09/2013 1:36 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have the initial support for Full Debug Symbols (FDS) on MacOS X >>>> done >>>> and ready for review: >>>> >>>> 7165611 implement Full Debug Symbols on MacOS X hotspot >>>> https://bugs.openjdk.java.net/browse/JDK-7165611 >>>> >>>> Here is the JDK8/HSX-25 webrev URL: >>>> >>>> OpenJDK: >>>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >>>> Internal: >>>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >>>> >>>> >>>> This webrev includes changes for the follow repos: >>>> >>>> jdk8 >>>> jdk8/hotspot >>>> jdk8/jdk >>>> jdk8/jdk/make/closed >>>> >>>> Once these changes are approved, I'm planning to push them to >>>> RT_Baseline. From there, they can follow the normal path to >>>> Main_Baseline and eventually JDK8. >>>> >>>> This work enables FDS on MacOS X for the 'hotspot' repo; the >>>> changes in >>>> the other repos are necessary to support importing the .diz files from >>>> the MacOS X 'hotspot' build into the forest build. I also fixed a few >>>> FDS related errors in the magic incantations for the new build. >>>> This is >>>> mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported >>>> from Solaris. In other words, this is Frankenstein's monster... >>>> >>>> Thanks to Staffan Larsen for providing an initial set of changes >>>> which I morphed into what you see here. >>>> >>>> Testing: >>>> - JPRT HSX build and test on all platforms; verification of .diz >>>> files in the MacOS X JPRT bundles >>>> - JPRT JDK8 forest build and test on all platforms; verification of >>>> .diz files in the MacOS X JPRT bundles >>>> Note: In previous FDS changesets, I also did a standalone 'jdk' >>>> repo build and test, but that no longer seems to work. >>>> >>>> As always, comments, questions and suggestions are welcome. >>>> >>>> Dan >> From roger.riggs at oracle.com Wed Oct 9 08:07:08 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Wed, 09 Oct 2013 15:07:08 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131009150735.2783B62E95@hg.openjdk.java.net> Changeset: e3b70e601c1c Author: rriggs Date: 2013-10-09 11:02 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e3b70e601c1c 8024612: java/time/tck/java/time/format/TCKDateTimeFormatters.java failed Summary: The test should be using the Locale.Category.FORMAT to verify the test data Reviewed-by: lancea ! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java Changeset: 09e2a73aa1dc Author: rriggs Date: 2013-09-26 15:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/09e2a73aa1dc 8025718: Enhance error messages for parsing Summary: Add values and types to exception messages Reviewed-by: lancea Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/DayOfWeek.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/Month.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/format/Parsed.java ! test/java/time/test/java/time/format/TestDateTimeFormatter.java From dmitry.samersoff at oracle.com Wed Oct 9 08:35:31 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 09 Oct 2013 19:35:31 +0400 Subject: RR(S): JDK-8005810: SA: Update Hotspot Serviceability Agent for Method Parameter Reflection and Generic Type Signature Data Message-ID: <525577C3.6020101@oracle.com> Hi Everybody, Please, review the changes for: JDK-8005810: Update Hotspot Serviceability Agent for Method Parameter Reflection and Generic Type Signature Data The fix contributed by Eric McCorkle. http://cr.openjdk.java.net/~dsamersoff/JDK-8005810/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8005810 -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From peter.allwin at oracle.com Wed Oct 9 08:56:55 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Wed, 9 Oct 2013 17:56:55 +0200 Subject: RFR: 8014446: JT_JDK: Wrong detection of test result for test com/sun/jdi/NoLaunchOptionTest.java In-Reply-To: <524EA984.4030509@oracle.com> References: <524EA984.4030509@oracle.com> Message-ID: <1934FDE5-6289-4BBF-9A59-0B4BB054121E@oracle.com> Hi Jaroslav, The "ERROR:" prefix is hard-coded in error_messages.c and is not subject to localisation etc. so I think performing a case-sensitive compare seems reasonable - although if you feel strongly about it I can definitely change it. Thanks for the review! /peter On Oct 4, 2013, at 1:41 PM, Jaroslav Bachorik wrote: > Looks fine. Just a thought - wouldn't it make sense to check for the error message disregarding the case? > > -JB- > > On 4.10.2013 13:29, Staffan Larsen wrote: >> Looks good! >> >> Thanks, >> /Staffan >> >> On 4 okt 2013, at 13:13, Peter Allwin wrote: >> >>> Hello! >>> >>> Looking for reviews for this very simple fix to a JDK test, where warnings in stderr could cause the test to fail. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8014446 >>> CR: http://cr.openjdk.java.net/~allwin/8014446/webrev.00/ >>> >>> >>> Thanks! >>> /peter >> > From jaroslav.bachorik at oracle.com Wed Oct 9 09:06:28 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 09 Oct 2013 18:06:28 +0200 Subject: RFR: 8014446: JT_JDK: Wrong detection of test result for test com/sun/jdi/NoLaunchOptionTest.java In-Reply-To: <1934FDE5-6289-4BBF-9A59-0B4BB054121E@oracle.com> References: <524EA984.4030509@oracle.com> <1934FDE5-6289-4BBF-9A59-0B4BB054121E@oracle.com> Message-ID: <52557F04.3020000@oracle.com> Hi, On 9.10.2013 17:56, Peter Allwin wrote: > Hi Jaroslav, > > The "ERROR:" prefix is hard-coded in error_messages.c and is not subject to localisation etc. so I think performing a case-sensitive compare seems reasonable - although if you feel strongly about it I can definitely change it. In that case I'm fine with the case-sensitive comparison. -JB- > > Thanks for the review! > /peter > > On Oct 4, 2013, at 1:41 PM, Jaroslav Bachorik wrote: > >> Looks fine. Just a thought - wouldn't it make sense to check for the error message disregarding the case? >> >> -JB- >> >> On 4.10.2013 13:29, Staffan Larsen wrote: >>> Looks good! >>> >>> Thanks, >>> /Staffan >>> >>> On 4 okt 2013, at 13:13, Peter Allwin wrote: >>> >>>> Hello! >>>> >>>> Looking for reviews for this very simple fix to a JDK test, where warnings in stderr could cause the test to fail. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8014446 >>>> CR: http://cr.openjdk.java.net/~allwin/8014446/webrev.00/ >>>> >>>> >>>> Thanks! >>>> /peter >>> >> > From daniel.daugherty at oracle.com Wed Oct 9 09:06:59 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 09 Oct 2013 10:06:59 -0600 Subject: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <52557025.7060706@oracle.com> References: <523D144E.4000002@oracle.com> <524B8A78.9040807@oracle.com> <52548E6D.80701@oracle.com> <525545E3.3060504@oracle.com> <52557025.7060706@oracle.com> Message-ID: <52557F23.7080109@oracle.com> On 10/9/13 9:03 AM, Daniel D. Daugherty wrote: > Replies also inline... > > > On 10/9/13 6:02 AM, David Holmes wrote: >> inline ... >> >> On 9/10/2013 8:59 AM, Daniel D. Daugherty wrote: >>> On 10/1/13 8:52 PM, David Holmes wrote: >> >>>> - make/bsd/makefiles/universal.gmk >>>> >>>> I did not understand the additional logic here: >>>> >>>> 63 # Copy built non-universal binaries in place >>>> 64 $(UNIVERSAL_COPY_LIST): >>>> 65 BUILT_COPY_FILES="`find >>>> $(EXPORT_JRE_LIB_DIR)/{i386,amd64}/$(subst $(EXPORT_JRE_LIB_DIR)/,,$@) >>>> 2>/dev/null`"; \ >>>> 66 if [ -n "$${BUILT_COPY_FILES}" ]; then \ >>>> 67 for i in $${BUILT_COPY_FILES}; do \ >>>> 68 if [ -f $${i} ]; then \ >>>> 69 $(MKDIR) -p $(shell dirname $@); \ >>>> 70 $(CP) -R $${i} $@; \ >>>> 71 fi; \ >>>> 72 if [ -d $${i} ]; then \ >>>> 73 $(MKDIR) -p $@; \ >>>> 74 fi; \ >>>> 75 done; \ >>>> 76 fi >>>> >>>> until I realized that foo.dSYM is a directory not a file! Even so >>>> don't you want to copy the contents of the directory across ? >>> >>> BUILT_COPY_FILES includes both files and directories so everything >>> should get copied across. I've added some commments to the rule >>> header and reorganized the logic a bit to hopefully be more clear. >> >> Doesn't this assume that the directory will appear before the files >> within it? Is that guaranteed? > > The way find works is that it lists the directory prior to listing > the files within the directory. However, even if find didn't, the > containing directory would be created via line 69 above. The one > non-obvious feature of lines 72-74 is that an empty directory named > in the BUILD_COPY_FILES list would get 'copied' to the destination. > > Please check out the latest version when I get it out for review. It turns out that the above block was the reason for the flat hierarchy reported by Staffan when: ZIP_DEBUGINFO_FILES=0 a.k.a. '--disable-zip-debug-info' is used. I've redone this block again in a much simpler fashion and that seems to be working. Dan From henry.jen at oracle.com Wed Oct 9 10:00:42 2013 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Wed, 09 Oct 2013 17:00:42 +0000 Subject: hg: jdk8/tl/jdk: 8023524: Mechanism to dump generated lambda classes / log lambda code generation Message-ID: <20131009170105.2E54462E9D@hg.openjdk.java.net> Changeset: c070001c4f60 Author: henryjen Date: 2013-10-09 09:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c070001c4f60 8023524: Mechanism to dump generated lambda classes / log lambda code generation Reviewed-by: plevart, mchung, forax, jjb Contributed-by: brian.goetz at oracle.com, henry.jen at oracle.com ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + src/share/classes/java/lang/invoke/ProxyClassesDumper.java + test/java/lang/invoke/lambda/LogGeneratedClassesTest.java From staffan.larsen at oracle.com Wed Oct 9 11:02:18 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 9 Oct 2013 20:02:18 +0200 Subject: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <52557F23.7080109@oracle.com> References: <523D144E.4000002@oracle.com> <524B8A78.9040807@oracle.com> <52548E6D.80701@oracle.com> <525545E3.3060504@oracle.com> <52557025.7060706@oracle.com> <52557F23.7080109@oracle.com> Message-ID: <04CF60AF-0859-42FE-9883-641027ED6352@oracle.com> On 9 okt 2013, at 18:06, Daniel D. Daugherty wrote: > > On 10/9/13 9:03 AM, Daniel D. Daugherty wrote: >> Replies also inline... >> >> >> On 10/9/13 6:02 AM, David Holmes wrote: >>> inline ... >>> >>> On 9/10/2013 8:59 AM, Daniel D. Daugherty wrote: >>>> On 10/1/13 8:52 PM, David Holmes wrote: >>> >>>>> - make/bsd/makefiles/universal.gmk >>>>> >>>>> I did not understand the additional logic here: >>>>> >>>>> 63 # Copy built non-universal binaries in place >>>>> 64 $(UNIVERSAL_COPY_LIST): >>>>> 65 BUILT_COPY_FILES="`find >>>>> $(EXPORT_JRE_LIB_DIR)/{i386,amd64}/$(subst $(EXPORT_JRE_LIB_DIR)/,,$@) >>>>> 2>/dev/null`"; \ >>>>> 66 if [ -n "$${BUILT_COPY_FILES}" ]; then \ >>>>> 67 for i in $${BUILT_COPY_FILES}; do \ >>>>> 68 if [ -f $${i} ]; then \ >>>>> 69 $(MKDIR) -p $(shell dirname $@); \ >>>>> 70 $(CP) -R $${i} $@; \ >>>>> 71 fi; \ >>>>> 72 if [ -d $${i} ]; then \ >>>>> 73 $(MKDIR) -p $@; \ >>>>> 74 fi; \ >>>>> 75 done; \ >>>>> 76 fi >>>>> >>>>> until I realized that foo.dSYM is a directory not a file! Even so >>>>> don't you want to copy the contents of the directory across ? >>>> >>>> BUILT_COPY_FILES includes both files and directories so everything >>>> should get copied across. I've added some commments to the rule >>>> header and reorganized the logic a bit to hopefully be more clear. >>> >>> Doesn't this assume that the directory will appear before the files within it? Is that guaranteed? >> >> The way find works is that it lists the directory prior to listing >> the files within the directory. However, even if find didn't, the >> containing directory would be created via line 69 above. The one >> non-obvious feature of lines 72-74 is that an empty directory named >> in the BUILD_COPY_FILES list would get 'copied' to the destination. >> >> Please check out the latest version when I get it out for review. > > It turns out that the above block was the reason for the flat hierarchy > reported by Staffan when: > > ZIP_DEBUGINFO_FILES=0 a.k.a. '--disable-zip-debug-info' > > is used. I've redone this block again in a much simpler fashion > and that seems to be working. Very good! I look forward to testing it. /Staffan From staffan.larsen at oracle.com Wed Oct 9 11:04:03 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 9 Oct 2013 20:04:03 +0200 Subject: RR(S): JDK-8005810: SA: Update Hotspot Serviceability Agent for Method Parameter Reflection and Generic Type Signature Data In-Reply-To: <525577C3.6020101@oracle.com> References: <525577C3.6020101@oracle.com> Message-ID: <4B22AD89-66CD-4CDE-9DA8-40934E04A31D@oracle.com> Dmitry, Are there any tests that exercise this functionality? /Staffan On 9 okt 2013, at 17:35, Dmitry Samersoff wrote: > Hi Everybody, > > Please, review the changes for: > > JDK-8005810: Update Hotspot Serviceability Agent for Method Parameter > Reflection and Generic Type Signature Data > > The fix contributed by Eric McCorkle. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8005810/webrev.01/ > > https://bugs.openjdk.java.net/browse/JDK-8005810 > > -Dmitry > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Wed Oct 9 11:12:47 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 9 Oct 2013 20:12:47 +0200 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <52556604.3080900@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> <52556604.3080900@oracle.com> Message-ID: <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> On 9 okt 2013, at 16:19, Jaroslav Bachorik wrote: > On 9.10.2013 16:10, Staffan Larsen wrote: >> There is now an awful amount of different timestamps in the Management class. Can they be consolidated somehow? At least _begin_vm_creation_time and the new _begin_vm_creation_ns. >> >> This discussion also implies that the "elapsed time" we print in the hs_err file is also wrong. It uses os::elapsedTime() which uses os::elapsed_counter(). >> >> And I guess the same thing for the VM.uptime Diagnostic Command (class VMUptimeDCmd) which also relies on os::elapsed_counter(). > > Also the reported GC pauses duration might be wrong since it uses Management::timestamp(). > > On the first sight the change looks rather trivial. But, honestly, I'm not sure which other parts could for whatever reason break once the time-of-day timestamp is replaced with a monotonic equivalent. One would think that it shouldn't matter but one never knows ... > > Staffan, do you think this kind of change is suitable for the current phase of JDK release cycle? I think I could improve the patch in few days and then it should probably be able to pass the review before ZBB. But, it's only P3 ... I think it is a bit late in the release cycle to clean this up in the way it should be cleaned up. I think we should wait until the first 8 update release and do a more thorough job than we have time for right now. /Staffan > > -JB- > >> >> /Staffan >> >> >> On 9 okt 2013, at 13:26, Jaroslav Bachorik wrote: >> >>> On 8.10.2013 23:46, David Holmes wrote: >>>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>>> On 8.10.2013 09:34, David Holmes wrote: >>>>>> Jaroslav, >>>>>> >>>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>>> Hello, >>>>>>> >>>>>>> currently the JVM uptime reported by the RuntimeMXBean is based on >>>>>>> System.currentTimeMillis() which makes it susceptible to changes of the >>>>>>> OS time (eg. changing timezone, NTP synchronization etc.). The uptime >>>>>>> should not depend on the system time and should be calculated using a >>>>>>> monotonic clock source. >>>>>>> >>>>>>> There is already the way to get the actual JVM uptime in ticks. It is >>>>>>> accessible as Management::timestamp() and the ticks are convertible to >>>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus making it >>>>>>> very >>>>>>> easy to switch to the monotonic clock based uptime. >>>>>> >>>>>> Maybe I'm missing something but TiumeStamp updates using >>>>>> os::elapsed_counter() which on Linux uses gettimeofday so is not a >>>>>> monotonic clock source. >>>>> >>>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>>> >>>>> Is there any reason why a non monotonic clock source is used for >>>>> timestamping except of the historical one? os::javaTimeNanos() uses >>>>> montonic clock when available - why can't be the same used for >>>>> os::elapsed_counter() especially when a counter based on "gettimeofday" >>>>> is not really a counter? >>>> >>>> It is all historical. These elapsed_counters and elapsed_timers make me >>>> cringe. But changing it has a lot of potential consequences because of >>>> the way these are used in logging etc. Certainly not something to be >>>> contemplated at this stage of JDK 8. >>>> >>>> Perhaps a simpler fix here is to expose a startUpTimeNanos that can then >>>> be used for the uptime. >>> >>> My attempt at this is at http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >>> I am using os::javaTimeNanos() to get the monotonic ticks where possible. >>> >>> The JDK part stays the same as for webrev.00 >>> >>> -JB- >>> >>>> >>>> David >>>> >>>>> -JB- >>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>> >>>>>>> The patch consists of the hotspot and jdk parts. >>>>>>> >>>>>>> For the hotspot a new constant needs to be introduced in >>>>>>> src/share/vm/services/jmm.h and the actual logic to obtain the >>>>>>> uptime in >>>>>>> milliseconds is added in src/share/vm/services/management.cpp. >>>>>>> >>>>>>> For the jdk the changes comprise of adding the necessary JNI bridging >>>>>>> methods in order to get the new uptime, introducing the same constant >>>>>>> that is used in hotspot and changes to mapfile-vers files in order to >>>>>>> properly build the native library. >>>>>>> >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>> >>> >> > From roger.riggs at oracle.com Wed Oct 9 11:42:06 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Wed, 09 Oct 2013 18:42:06 +0000 Subject: hg: jdk8/tl/jdk: 8024076: Incorrect 2 -> 4 year parsing and resolution in DateTimeFormatter Message-ID: <20131009184222.ABF3E62EA7@hg.openjdk.java.net> Changeset: d42fe440bda8 Author: rriggs Date: 2013-10-09 13:34 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d42fe440bda8 8024076: Incorrect 2 -> 4 year parsing and resolution in DateTimeFormatter Summary: Add appendValueReduced method based on a ChronoLocalDate to provide context for the value Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java ! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java ! test/java/time/test/java/time/format/TestReducedParser.java ! test/java/time/test/java/time/format/TestReducedPrinter.java From brian.burkhalter at oracle.com Wed Oct 9 11:50:05 2013 From: brian.burkhalter at oracle.com (brian.burkhalter at oracle.com) Date: Wed, 09 Oct 2013 18:50:05 +0000 Subject: hg: jdk8/tl/jdk: 8016252: More defensive HashSet.readObject Message-ID: <20131009185018.E91C762EA8@hg.openjdk.java.net> Changeset: b86e6700266e Author: bpb Date: 2013-10-09 11:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b86e6700266e 8016252: More defensive HashSet.readObject Summary: Add data validation checks in readObject(). Reviewed-by: alanb, mduigou, chegar Contributed-by: Brian Burkhalter ! src/share/classes/java/util/HashSet.java + test/java/util/HashSet/Serialization.java From staffan.larsen at oracle.com Wed Oct 9 11:53:52 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 9 Oct 2013 20:53:52 +0200 Subject: RFR (S) JDK-8025700: RuntimeMXBean.getInputArguments() should include -server/-client/-d32/-d64 In-Reply-To: <52552011.6020904@oracle.com> References: <524D73C4.7060004@oracle.com> <5253A32D.40502@oracle.com> <52541925.5030907@oracle.com> <525509CB.1050301@oracle.com> <52551185.8070209@oracle.com> <52551BFB.5040309@oracle.com> <52552011.6020904@oracle.com> Message-ID: I can absolutely see where Aleksey (and 99% of the Java users) is coming from. From a user perspective there is no difference between the launcher arguments and the JVM arguments. Unfortunately the implementation does make a difference between them and it's not easy to hide this difference. A similar problem is that the actual main-class is not known by the JVM. We work around this with the sun.java.command property, but when a custom launcher is used that property is not set and so we lack information about this in the JVM (and in the management APIs). The typical example of this for me is running eclipse. Perhaps we could extend the JNI invocation API to allow these things to be passed through? A problem is of course to define what a "launcher argument" is. For example, sometimes Java is launched from inside another application (web browser, anyone?) and then the arguments to that host process makes little sense to pass on. Regards, /Staffan On 9 okt 2013, at 11:21, Aleksey Shipilev wrote: > On 10/09/2013 01:03 PM, Mandy Chung wrote: >>> Do you see any better option? >> >> I no longer work in this area and don't have any suggestion at the >> moment. Although parsing of VM name is not ideal, I suggest it as a >> workaround for now and give the serviceability team time to look into >> this to address your request. > > Ok, I'll leave the ticket open meanwhile. > > Thanks, > -Aleksey. > From valerie.peng at oracle.com Wed Oct 9 13:26:29 2013 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Wed, 09 Oct 2013 20:26:29 +0000 Subject: hg: jdk8/tl/jdk: 5 new changesets Message-ID: <20131009202801.65D1362EB0@hg.openjdk.java.net> Changeset: 1597066b58ee Author: valeriep Date: 2013-10-08 11:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1597066b58ee 7196382: PKCS11 provider should support 2048-bit DH Summary: Query and enforce range checking using the values from native PKCS11 library. Reviewed-by: xuelei ! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java ! src/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java + test/sun/security/pkcs11/KeyPairGenerator/TestDH2048.java Changeset: 3da8be8d13bf Author: valeriep Date: 2013-10-08 11:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3da8be8d13bf 8012900: CICO ignores AAD in GCM mode Summary: Change GCM decryption to not return result until tag verification passed Reviewed-by: xuelei ! src/share/classes/com/sun/crypto/provider/CipherBlockChaining.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/CipherFeedback.java ! src/share/classes/com/sun/crypto/provider/CounterMode.java ! src/share/classes/com/sun/crypto/provider/ElectronicCodeBook.java ! src/share/classes/com/sun/crypto/provider/FeedbackCipher.java ! src/share/classes/com/sun/crypto/provider/GCTR.java ! src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java ! src/share/classes/com/sun/crypto/provider/OutputFeedback.java ! src/share/classes/com/sun/crypto/provider/PCBC.java ! src/share/classes/javax/crypto/CipherSpi.java + test/com/sun/crypto/provider/Cipher/AES/TestCICOWithGCMAndAAD.java Changeset: f4305254f92f Author: valeriep Date: 2013-10-08 11:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4305254f92f 8014374: Cannot initialize "AES/GCM/NoPadding" on wrap/unseal on solaris with OracleUcrypto Summary: Removed OracleUcrypto provider regression tests from OpenJDK Reviewed-by: xuelei - test/com/oracle/security/ucrypto/TestAES.java - test/com/oracle/security/ucrypto/TestDigest.java - test/com/oracle/security/ucrypto/TestRSA.java - test/com/oracle/security/ucrypto/UcryptoTest.java Changeset: e044b0151858 Author: valeriep Date: 2013-10-08 14:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e044b0151858 8025967: addition of -Werror broke the old build Summary: Fixed and suppressed compiler warnings on rawtypes Reviewed-by: vinnie ! src/share/classes/com/sun/jndi/ldap/LdapCtxFactory.java ! src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnectionOldImpl.java ! src/share/classes/java/lang/instrument/Instrumentation.java ! src/share/classes/java/net/ContentHandler.java ! src/share/classes/javax/crypto/JceSecurityManager.java ! src/share/classes/sun/instrument/InstrumentationImpl.java ! src/share/classes/sun/net/www/content/image/gif.java ! src/share/classes/sun/net/www/content/image/jpeg.java ! src/share/classes/sun/net/www/content/image/png.java ! src/share/classes/sun/net/www/content/image/x_xbitmap.java ! src/share/classes/sun/net/www/content/image/x_xpixmap.java ! src/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java ! src/share/classes/sun/reflect/misc/MethodUtil.java ! src/share/classes/sun/security/provider/AuthPolicyFile.java ! src/share/classes/sun/security/provider/SubjectCodeSource.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/keytool/Main.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java Changeset: 7a7b73a40bb1 Author: valeriep Date: 2013-10-09 13:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a7b73a40bb1 Merge - src/share/classes/com/sun/jdi/connect/package.html - src/share/classes/com/sun/jdi/connect/spi/package.html - src/share/classes/com/sun/jdi/event/package.html - src/share/classes/com/sun/jdi/package.html - src/share/classes/com/sun/jdi/request/package.html - src/share/classes/com/sun/management/package.html - src/share/classes/com/sun/tools/attach/package.html - src/share/classes/com/sun/tools/attach/spi/package.html - src/share/classes/com/sun/tools/jconsole/package.html From dmitry.samersoff at oracle.com Wed Oct 9 13:59:42 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 10 Oct 2013 00:59:42 +0400 Subject: RR(S): JDK-8005810: SA: Update Hotspot Serviceability Agent for Method Parameter Reflection and Generic Type Signature Data In-Reply-To: <4B22AD89-66CD-4CDE-9DA8-40934E04A31D@oracle.com> References: <525577C3.6020101@oracle.com> <4B22AD89-66CD-4CDE-9DA8-40934E04A31D@oracle.com> Message-ID: <5255C3BE.2020601@oracle.com> Staffan, I don't have specific test, but I rebuild vm testbase with -parameters and then run nsk.sajdi. -Dmitry On 2013-10-09 22:04, Staffan Larsen wrote: > Dmitry, > > Are there any tests that exercise this functionality? > > /Staffan > > On 9 okt 2013, at 17:35, Dmitry Samersoff wrote: > >> Hi Everybody, >> >> Please, review the changes for: >> >> JDK-8005810: Update Hotspot Serviceability Agent for Method Parameter >> Reflection and Generic Type Signature Data >> >> The fix contributed by Eric McCorkle. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8005810/webrev.01/ >> >> https://bugs.openjdk.java.net/browse/JDK-8005810 >> >> -Dmitry >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yumin.qi at oracle.com Wed Oct 9 14:35:53 2013 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Wed, 09 Oct 2013 14:35:53 -0700 Subject: RR(S): JDK-8005810: SA: Update Hotspot Serviceability Agent for Method Parameter Reflection and Generic Type Signature Data In-Reply-To: <5255C3BE.2020601@oracle.com> References: <525577C3.6020101@oracle.com> <4B22AD89-66CD-4CDE-9DA8-40934E04A31D@oracle.com> <5255C3BE.2020601@oracle.com> Message-ID: <5255CC39.8050001@oracle.com> I think in SA, the command 'vmstructsdump' will trigger your code? Thanks Yumin On 10/9/2013 1:59 PM, Dmitry Samersoff wrote: > Staffan, > > I don't have specific test, but I rebuild vm testbase with -parameters > and then run nsk.sajdi. > > -Dmitry > > On 2013-10-09 22:04, Staffan Larsen wrote: >> Dmitry, >> >> Are there any tests that exercise this functionality? >> >> /Staffan >> >> On 9 okt 2013, at 17:35, Dmitry Samersoff wrote: >> >>> Hi Everybody, >>> >>> Please, review the changes for: >>> >>> JDK-8005810: Update Hotspot Serviceability Agent for Method Parameter >>> Reflection and Generic Type Signature Data >>> >>> The fix contributed by Eric McCorkle. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8005810/webrev.01/ >>> >>> https://bugs.openjdk.java.net/browse/JDK-8005810 >>> >>> -Dmitry >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. > From daniel.daugherty at oracle.com Wed Oct 9 15:39:38 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 09 Oct 2013 16:39:38 -0600 Subject: RFR 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::,compare_entry_to and copy_entry_to In-Reply-To: <52544E78.9090103@oracle.com> References: <52544E78.9090103@oracle.com> Message-ID: <5255DB2A.5080209@oracle.com> On 10/8/13 12:27 PM, Coleen Phillimore wrote: > Summary: Add missing cases. > > I verified this with the test for > https://bugs.openjdk.java.net/browse/JDK-8022701 but don't want to > copy the test into with modifications the hotspot repository, still > working on refactoring the test for the JDK repository for after this > gets pushed. > > open webrev at http://cr.openjdk.java.net/~coleenp/8025185/ src/share/vm/oops/constantPool.cpp No comments. Thumbs up. Dan > bug link https://bugs.openjdk.java.net/browse/JDK-8025185 > > Thanks, > Coleen > > From karen.kinnear at oracle.com Wed Oct 9 16:26:52 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Wed, 09 Oct 2013 23:26:52 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8026185: nsk/jvmit/GetMethodDeclaringClass/declcls001 failed Message-ID: <20131009232700.3E4DB62EB5@hg.openjdk.java.net> Changeset: d25557d03ec0 Author: acorn Date: 2013-10-09 17:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d25557d03ec0 8026185: nsk/jvmit/GetMethodDeclaringClass/declcls001 failed Summary: Missed initialization. Thanks Coleen. Reviewed-by: coleenp, minqi ! src/share/vm/oops/instanceKlass.cpp From brian.burkhalter at oracle.com Wed Oct 9 17:29:26 2013 From: brian.burkhalter at oracle.com (brian.burkhalter at oracle.com) Date: Thu, 10 Oct 2013 00:29:26 +0000 Subject: hg: jdk8/tl/jdk: 7189139: BigInteger's staticRandom field can be a source of bottlenecks. Message-ID: <20131010002949.8ACA162EB7@hg.openjdk.java.net> Changeset: 673f8045311e Author: bpb Date: 2013-10-09 17:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/673f8045311e 7189139: BigInteger's staticRandom field can be a source of bottlenecks. Summary: Use ThreadLocalRandom instead of SecureRandom. Reviewed-by: shade, psandoz Contributed-by: Brian Burkhalter ! src/share/classes/java/math/BigInteger.java From mike.duigou at oracle.com Wed Oct 9 18:25:58 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 10 Oct 2013 01:25:58 +0000 Subject: hg: jdk8/tl/jdk: 8024709: TreeMap.DescendingKeyIterator 'remove' confuses iterator position Message-ID: <20131010012639.85AE162EB8@hg.openjdk.java.net> Changeset: eab3c09745b6 Author: bchristi Date: 2013-10-09 12:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eab3c09745b6 8024709: TreeMap.DescendingKeyIterator 'remove' confuses iterator position Summary: Override remove() method in DescendingKeyIterator Reviewed-by: alanb, mduigou, psandoz ! src/share/classes/java/util/TreeMap.java ! test/java/util/Collection/MOAT.java From joe.darcy at oracle.com Wed Oct 9 18:32:23 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 10 Oct 2013 01:32:23 +0000 Subject: hg: jdk8/tl/jdk: 8024354: Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation Message-ID: <20131010013235.BE03562EBB@hg.openjdk.java.net> Changeset: c13309f658e1 Author: darcy Date: 2013-10-09 18:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c13309f658e1 8024354: Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation Reviewed-by: mduigou, briangoetz ! src/share/classes/java/util/DoubleSummaryStatistics.java ! src/share/classes/java/util/stream/DoubleStream.java From coleen.phillimore at oracle.com Wed Oct 9 19:04:45 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 09 Oct 2013 22:04:45 -0400 Subject: RFR 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::,compare_entry_to and copy_entry_to In-Reply-To: <5255DB2A.5080209@oracle.com> References: <52544E78.9090103@oracle.com> <5255DB2A.5080209@oracle.com> Message-ID: <52560B3D.1090009@oracle.com> Thanks Dan! Coleen On 10/9/2013 6:39 PM, Daniel D. Daugherty wrote: > On 10/8/13 12:27 PM, Coleen Phillimore wrote: >> Summary: Add missing cases. >> >> I verified this with the test for >> https://bugs.openjdk.java.net/browse/JDK-8022701 but don't want to >> copy the test into with modifications the hotspot repository, still >> working on refactoring the test for the JDK repository for after this >> gets pushed. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8025185/ > > src/share/vm/oops/constantPool.cpp > No comments. > > Thumbs up. > > Dan > > >> bug link https://bugs.openjdk.java.net/browse/JDK-8025185 >> >> Thanks, >> Coleen >> >> > From david.holmes at oracle.com Wed Oct 9 20:39:00 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Oct 2013 13:39:00 +1000 Subject: jmx-dev Codereview request: 8025207 Intermittent test failure: javax/management/monitor/CounterMonitorThresholdTest.java In-Reply-To: <525508DD.6070108@oracle.com> References: 52415BE3.1030803@oracle.com <5254ABA9.6010405@oracle.com> <525508DD.6070108@oracle.com> Message-ID: <52562154.2050807@oracle.com> I missed the earlier println. Reviewed. Thanks, David On 9/10/2013 5:42 PM, shanliang wrote: > David Holmes wrote: >> shanliang wrote: >>> Daniel Fuchs wrote: >>>> On 9/23/13 8:27 PM, shanliang wrote: >>>>> Hi, >>>>> >>>>> Please review this test fix, if the test continues failing, then we >>>>> need >>>>> to investigate the Monitor implementation. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8025207/00/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8025207 >>>>> >>>>> Thanks, >>>>> Shanliang >>>>> >>>> >>>> Hi Shanliang, >>>> >>>> There seems to an issue in the exit condition of the loop in the >>>> new code. >>>> >>>> The old code had: >>>> >>>> 150 if (derivedGaugeValue.intValue() != derivedGauge[i]) >>>> >>>> the new code has: >>>> >>>> 155 } while (derivedGaugeValue.intValue() != counter[i]); >>> Good catch, I changed the code, even they are same today: >>> Here is the new version: >>> http://cr.openjdk.java.net/~sjiang/JDK-8025207/01/ >> >> My concern here is that if the test times out and is killed by the >> test harness, there is absolutely nothing to indicate where the test >> got stuck. So I would suggest at least adding a println before >> entering the loop and again after. > I think today the test gives info about each test step: > Line 139: > System.out.println("\nStart monitoring..."); > tells the looping entry > > Line 146: > System.out.println("\nCounter = " + mbean.getCounter()); > within the loop tells which counter value is being tested. > > Line 156: > System.out.println("Threshold = " + thresholdValue); > within the loop tells the test end of a count value. > > Line 168: > System.out.println("\nStop monitoring..."); > tells the looping end. > > and the class Listener prints out notification info allowing to know > where is testing too. > > Thanks, > Shanliang >> >> David >> ----- > From david.holmes at oracle.com Wed Oct 9 20:44:52 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Oct 2013 13:44:52 +1000 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> <52556604.3080900@oracle.com> <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> Message-ID: <525622B4.5020606@oracle.com> On 10/10/2013 4:12 AM, Staffan Larsen wrote: > > On 9 okt 2013, at 16:19, Jaroslav Bachorik wrote: > >> On 9.10.2013 16:10, Staffan Larsen wrote: >>> There is now an awful amount of different timestamps in the Management class. Can they be consolidated somehow? At least _begin_vm_creation_time and the new _begin_vm_creation_ns. >>> >>> This discussion also implies that the "elapsed time" we print in the hs_err file is also wrong. It uses os::elapsedTime() which uses os::elapsed_counter(). >>> >>> And I guess the same thing for the VM.uptime Diagnostic Command (class VMUptimeDCmd) which also relies on os::elapsed_counter(). >> >> Also the reported GC pauses duration might be wrong since it uses Management::timestamp(). >> >> On the first sight the change looks rather trivial. But, honestly, I'm not sure which other parts could for whatever reason break once the time-of-day timestamp is replaced with a monotonic equivalent. One would think that it shouldn't matter but one never knows ... >> >> Staffan, do you think this kind of change is suitable for the current phase of JDK release cycle? I think I could improve the patch in few days and then it should probably be able to pass the review before ZBB. But, it's only P3 ... > > I think it is a bit late in the release cycle to clean this up in the way it should be cleaned up. I think we should wait until the first 8 update release and do a more thorough job than we have time for right now. I second that. The elapsed_counter/elpased_timer APIs and implementations are a tangled mess. But part of the problem has been that people want/expect monotonic time-of-day based timestamps (yes a contradiction - though some people make sure TOD does not get modified on their production systems). The use of timestamps in logging has to be examined carefully - mainly GC logging. I recall a "simple" attempted change in the past that resulted in trying to compare a nanoTime based timestamp with the TOD. :( David ----- > /Staffan > > >> >> -JB- >> >>> >>> /Staffan >>> >>> >>> On 9 okt 2013, at 13:26, Jaroslav Bachorik wrote: >>> >>>> On 8.10.2013 23:46, David Holmes wrote: >>>>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>>>> On 8.10.2013 09:34, David Holmes wrote: >>>>>>> Jaroslav, >>>>>>> >>>>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> currently the JVM uptime reported by the RuntimeMXBean is based on >>>>>>>> System.currentTimeMillis() which makes it susceptible to changes of the >>>>>>>> OS time (eg. changing timezone, NTP synchronization etc.). The uptime >>>>>>>> should not depend on the system time and should be calculated using a >>>>>>>> monotonic clock source. >>>>>>>> >>>>>>>> There is already the way to get the actual JVM uptime in ticks. It is >>>>>>>> accessible as Management::timestamp() and the ticks are convertible to >>>>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus making it >>>>>>>> very >>>>>>>> easy to switch to the monotonic clock based uptime. >>>>>>> >>>>>>> Maybe I'm missing something but TiumeStamp updates using >>>>>>> os::elapsed_counter() which on Linux uses gettimeofday so is not a >>>>>>> monotonic clock source. >>>>>> >>>>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>>>> >>>>>> Is there any reason why a non monotonic clock source is used for >>>>>> timestamping except of the historical one? os::javaTimeNanos() uses >>>>>> montonic clock when available - why can't be the same used for >>>>>> os::elapsed_counter() especially when a counter based on "gettimeofday" >>>>>> is not really a counter? >>>>> >>>>> It is all historical. These elapsed_counters and elapsed_timers make me >>>>> cringe. But changing it has a lot of potential consequences because of >>>>> the way these are used in logging etc. Certainly not something to be >>>>> contemplated at this stage of JDK 8. >>>>> >>>>> Perhaps a simpler fix here is to expose a startUpTimeNanos that can then >>>>> be used for the uptime. >>>> >>>> My attempt at this is at http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >>>> I am using os::javaTimeNanos() to get the monotonic ticks where possible. >>>> >>>> The JDK part stays the same as for webrev.00 >>>> >>>> -JB- >>>> >>>>> >>>>> David >>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> >>>>>>> >>>>>>>> The patch consists of the hotspot and jdk parts. >>>>>>>> >>>>>>>> For the hotspot a new constant needs to be introduced in >>>>>>>> src/share/vm/services/jmm.h and the actual logic to obtain the >>>>>>>> uptime in >>>>>>>> milliseconds is added in src/share/vm/services/management.cpp. >>>>>>>> >>>>>>>> For the jdk the changes comprise of adding the necessary JNI bridging >>>>>>>> methods in order to get the new uptime, introducing the same constant >>>>>>>> that is used in hotspot and changes to mapfile-vers files in order to >>>>>>>> properly build the native library. >>>>>>>> >>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -JB- >>>>>> >>>> >>> >> > From david.holmes at oracle.com Wed Oct 9 21:03:16 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Oct 2013 14:03:16 +1000 Subject: RFR (S): 8025427 jstat tests fails on 32-bit platforms In-Reply-To: <35223AD7-3203-4308-B6C7-7D2258FE31CB@oracle.com> References: <7483E09E-5283-412F-BEA3-F7CC015A67DC@oracle.com> <525423AF.8030008@oracle.com> <35223AD7-3203-4308-B6C7-7D2258FE31CB@oracle.com> Message-ID: <52562704.8020203@oracle.com> On 9/10/2013 3:04 AM, Staffan Larsen wrote: > Thanks Serguei! > > Still need an official Reviewer. Reviewed! Thanks for explaining the diff to the regex :) Hard to spot. David ----- > Thanks, > /Staffan > > On 8 okt 2013, at 17:24, serguei.spitsyn at oracle.com wrote: > >> Looks good. >> >> Thanks, >> Serguei >> >> On 10/8/13 5:06 AM, Staffan Larsen wrote: >>> Pinging again: Please, pretty please? :) >>> >>> /Staffan >>> >>> On 1 okt 2013, at 20:46, Staffan Larsen wrote: >>> >>>> Any Reviewer who can take a look? >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 27 sep 2013, at 23:59, Staffan Larsen wrote: >>>> >>>>> This change makes jstat output '-' instead of '\ufffd' when the result of a calculation is NaN. '\ufffd' is typically not displayable in a terminal. >>>>> >>>>> This change also updates the tests to allow '-' as the output int the CCS (Compressed Class Space Space - Percent Used) column from -gcutil and -gccause. It can be hard to see from the diff but what I have done is change the regexp for that column from: >>>>> >>>>> [0-9]+\.[0-9]+ >>>>> >>>>> to: >>>>> >>>>> ([0-9]+\.[0-9]+)|- >>>>> >>>>> Testing: Passes tests locally, currently running JPRT. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~sla/8025427/webrev.00/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8025427 >>>>> >>>>> Thanks, >>>>> /Staffan >> > From john.r.rose at oracle.com Wed Oct 9 21:15:37 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 9 Oct 2013 21:15:37 -0700 Subject: RFR 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::, compare_entry_to and copy_entry_to In-Reply-To: <52560B3D.1090009@oracle.com> References: <52544E78.9090103@oracle.com> <5255DB2A.5080209@oracle.com> <52560B3D.1090009@oracle.com> Message-ID: Looks good. Suggestion: Make normalize_error_tag be static, for namespace cleanliness. Even better, move it into constantTag, as (say) constantTag::non_error_value(). ? John On Oct 9, 2013, at 7:04 PM, Coleen Phillimore wrote: > > Thanks Dan! > Coleen > > On 10/9/2013 6:39 PM, Daniel D. Daugherty wrote: >> On 10/8/13 12:27 PM, Coleen Phillimore wrote: >>> Summary: Add missing cases. >>> >>> I verified this with the test for https://bugs.openjdk.java.net/browse/JDK-8022701 but don't want to copy the test into with modifications the hotspot repository, still working on refactoring the test for the JDK repository for after this gets pushed. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8025185/ >> >> src/share/vm/oops/constantPool.cpp >> No comments. >> >> Thumbs up. >> >> Dan >> >> >>> bug link https://bugs.openjdk.java.net/browse/JDK-8025185 >>> >>> Thanks, >>> Coleen >>> >>> >> > From david.holmes at oracle.com Wed Oct 9 21:19:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Oct 2013 14:19:19 +1000 Subject: RFR (S) JDK-8025700: RuntimeMXBean.getInputArguments() should include -server/-client/-d32/-d64 In-Reply-To: <52551185.8070209@oracle.com> References: <524D73C4.7060004@oracle.com> <5253A32D.40502@oracle.com> <52541925.5030907@oracle.com> <525509CB.1050301@oracle.com> <52551185.8070209@oracle.com> Message-ID: <52562AC7.3020100@oracle.com> On 9/10/2013 6:19 PM, Aleksey Shipilev wrote: > Hi Mandy, > > On 10/09/2013 11:46 AM, Mandy Chung wrote: >> Like David said, -client/-server and -d32/-d64 are launcher option but >> not VM options. RuntimeMXBean.getInputArguments() returns the arguments >> passed to the VM which is created via the JNI_CreateJavaVM API. > > Hm, this is the first time I hear about this contract, is it really > specified somewhere? Or, is it the informal status quo? Because it feels > remarkably as the implementation detail. I don't think users should be > exposed to the distinction between launcher and VM anyway. It is our launcher and the use of -client/-server/-d32/-d64 which is the implementation detail! So if you want the launcher args (which you do because you intend to execute the same launcher) then the launcher has to make them available. To that end I think the best long term solution is to have a well-defined property that the launcher can set (if it chooses) to hold launcher arguments that the launcher wishes to show the VM. A public variation of the sun.java.command property. The implementation should be quite simple and the CCC request would not be that involved. It is definitely unfortunate that there is no easy way to determine which VM you are running, in a manner that allows you to launch a similar one. This impacts a lot of our testing as well - many tests will launch the default VM (based on jvm.cfg and ergonomics) instead of the VM intended to be tested! David ----- >> -client/-server is the java launcher option that determines which VM to >> load and initialize and it's not an option passed to the JVM. In >> addition, -client/-server is actually not a valid option to the hotspot >> VM. Instead, you can find out if it's a server/client/minimal VM from >> getVmName(). > > Okay, let me state the intent cleaner. The tools I maintain (jmh and > jcstress are notable examples) need to start exactly the same VM with > exactly the same "java" options. How would you propose to do this? > > Recovering the command line by parsing getVmName() uses (unstable) > stringly conventions to detect the running VM, and also pushes me to > maintain the list of all possible VMs in the detection code. > > RuntimeMXBean.getInputArguments() omits some launcher options, but it is > fixable to expose these options to the user, no stringly parsing is > required on user side. > > Do you see any better option? > > -Aleksey. > From david.holmes at oracle.com Wed Oct 9 21:33:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Oct 2013 14:33:19 +1000 Subject: RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <52553D63.5000508@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> Message-ID: <52562E0F.7020108@oracle.com> On 9/10/2013 9:26 PM, Jaroslav Bachorik wrote: > On 8.10.2013 23:46, David Holmes wrote: >> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>> On 8.10.2013 09:34, David Holmes wrote: >>>> Jaroslav, >>>> >>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>> Hello, >>>>> >>>>> currently the JVM uptime reported by the RuntimeMXBean is based on >>>>> System.currentTimeMillis() which makes it susceptible to changes of >>>>> the >>>>> OS time (eg. changing timezone, NTP synchronization etc.). The uptime >>>>> should not depend on the system time and should be calculated using a >>>>> monotonic clock source. >>>>> >>>>> There is already the way to get the actual JVM uptime in ticks. It is >>>>> accessible as Management::timestamp() and the ticks are convertible to >>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus making it >>>>> very >>>>> easy to switch to the monotonic clock based uptime. >>>> >>>> Maybe I'm missing something but TiumeStamp updates using >>>> os::elapsed_counter() which on Linux uses gettimeofday so is not a >>>> monotonic clock source. >>> >>> Hm, yes. I wasn't aware of this linux/bsd specific. >>> >>> Is there any reason why a non monotonic clock source is used for >>> timestamping except of the historical one? os::javaTimeNanos() uses >>> montonic clock when available - why can't be the same used for >>> os::elapsed_counter() especially when a counter based on "gettimeofday" >>> is not really a counter? >> >> It is all historical. These elapsed_counters and elapsed_timers make me >> cringe. But changing it has a lot of potential consequences because of >> the way these are used in logging etc. Certainly not something to be >> contemplated at this stage of JDK 8. >> >> Perhaps a simpler fix here is to expose a startUpTimeNanos that can then >> be used for the uptime. > > My attempt at this is at > http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot > I am using os::javaTimeNanos() to get the monotonic ticks where possible. Only nit with this is that you initialize _begin_vm_creation_ns very early compared to the other timestamps. Plus I'm not even certain when this global initializer will execute relative to the VM initialization sequence! Best to move it into Management::init() to where _begin_vm_creation_time is initialized. David ----- > The JDK part stays the same as for webrev.00 > > -JB- > >> >> David >> >>> -JB- >>> >>>> >>>> David >>>> ----- >>>> >>>> >>>> >>>>> The patch consists of the hotspot and jdk parts. >>>>> >>>>> For the hotspot a new constant needs to be introduced in >>>>> src/share/vm/services/jmm.h and the actual logic to obtain the >>>>> uptime in >>>>> milliseconds is added in src/share/vm/services/management.cpp. >>>>> >>>>> For the jdk the changes comprise of adding the necessary JNI bridging >>>>> methods in order to get the new uptime, introducing the same constant >>>>> that is used in hotspot and changes to mapfile-vers files in order to >>>>> properly build the native library. >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>> > From david.holmes at oracle.com Wed Oct 9 21:41:25 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Oct 2013 14:41:25 +1000 Subject: [ping][ping] Re: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <52553EAD.4040506@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> <5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com> <5231DE69.7090309@oracle.com> <523B0B30.4020003@oracle.com> <5252C1B6.2060904@oracle.com> <52537F36.8020001@oracle.com> <5253ED95.20706@oracle.com> <52552EBA.4060308@oracle.com> <52553EAD.4040506@oracle.com> Message-ID: <52562FF5.5060304@oracle.com> On 9/10/2013 9:31 PM, Jaroslav Bachorik wrote: > On 9.10.2013 12:23, David Holmes wrote: >> Jaroslav, >> >> Thanks for the details description of changes - much appreciated. >> >> There is a lot to digest in there. :) > > Yep, it started as a simple fix :/ > >> >> It isn't obvious to me why these tests require a full JDK? > > IDK, LocalManagementTest.sh was listed as one requiring full JDK. Its > requirements are the same as the ones of CustomLauncherTest.sh (now > *.java) so it seemed logical to list it there too. Ah! Now I see it - it uses tools.jar which implies a full JDK. >> >> I don't quite follow the libjvm lookup logic - I would expect that you >> would always want to test the libjvm that is currently running - though >> it is hard to determine that. > > I'm afraid I can't be of much assistance here - I just took what was in > the *.sh version and converted it to *.java. Okay. I expect this will need revisiting at some point. Thanks, David ----- > -JB- > >> >> Thanks, >> David >> >> On 8/10/2013 9:33 PM, Jaroslav Bachorik wrote: >>> On 8.10.2013 05:42, David Holmes wrote: >>>> Jaroslav, >>>> >>>> Can you summarise the changes please? With the conversion to Java and >>>> the infrastructure additions I can't tell what is actually fixing the >>>> original timeout issue :) >>> >>> The timeout was most caused by using the same file for communication >>> between java processes in more test cases. When those test cases were >>> run in parallel the file got rewritten silently and some of the tests >>> could end up trying to connect to incorrect port in the target >>> application. I was able to reproduce the timeout by interleaving the >>> test runs for CustomLauncherTest.sh and LocalManagementTest.sh and >>> adding an artificial delay to CusteomLauncherTest.sh to allow >>> LocalManagementTest.sh to change the port in the file. >>> >>> While it could be fixed by using a different file for each test case I >>> took the liberty of converting the shell tests to java tests. This >>> allows me to remove the communication file and, in the end, make the >>> tests more robust. >>> >>> CustomLauncherTest.java and LocalManagementTest.java are the tests >>> converted from shell to java. I decided to convert >>> LocalManagementTest.sh as well because it has the same problems as the >>> CustomLauncherTest.sh. >>> >>> The changes in the testlibrary are about introducing new methods >>> allowing the tests easily start a process and wait for a certain text >>> appearing in its stdout/stderr. Using these methods the caller can wait >>> till the callee is fully initialized and eg. ready to accept >>> connections. >>> >>> The changes in launchers make the launchers actually executable + I am >>> adding a linux-amd64 launcher (I needed that one to work on the changes >>> locally and thought it might be nice to have one more platform covered >>> by the test). >>> >>> I've update the webrev to include changes to LocalManagementTest and >>> TEST.groups (both of those tests require JDK) - >>> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.05 >>> >>> -JB- >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 8/10/2013 12:14 AM, Jaroslav Bachorik wrote: >>>>> On 19.9.2013 16:33, Jaroslav Bachorik wrote: >>>>>> The updated webrev: >>>>>> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.03 >>>>>> >>>>>> I've moved some of the functionality to the testlibrary. >>>>>> >>>>>> -JB - >>>>>> >>>>>> On 12.9.2013 17:31, Jaroslav Bachorik wrote: >>>>>>> On 09/12/2013 05:13 PM, Dmitry Samersoff wrote: >>>>>>>> Jaroslav, >>>>>>>> >>>>>>>> CustomLauncherTest.java: >>>>>>>> >>>>>>>> 102: this check could be moved to switch at ll. 108 >>>>>>>> otherwise test fails on "sunos" and "linux" because PLATFORM >>>>>>>> remains >>>>>>>> unset. >>>>>>> Good idea. Thanks. >>>>>>> >>>>>>>> 129: I would prefer don't have pattern like this one ever in shell >>>>>>>> script. Could you prepare a list of VM's to check and just loop >>>>>>>> over >>>>>>>> it? >>>>>>>> It makes test better readable. Also I think nowdays we can always >>>>>>>> use >>>>>>>> server VM. >>>>>>> I tried to mirror the original shell test as closely as possible. It >>>>>>> would be nice if we could rely on the "server" vm only. Definitely >>>>>>> more >>>>>>> readable. >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2013-09-12 18:17, Jaroslav Bachorik wrote: >>>>>>>>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: >>>>>>>>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote: >>>>>>>>>>> On 09/12/2013 04:45 AM, David Holmes wrote: >>>>>>>>>>>> Hi Jaroslav, >>>>>>>>>>>> >>>>>>>>>>>> You need a copyright notice in the new file. >>>>>>>>>>>> >>>>>>>>>>>> As written this test can only run on a full JDK - so please add >>>>>>>>>>>> it to >>>>>>>>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really needs to >>>>>>>>>>>> come >>>>>>>>>>>> from the test-jdk? And use the VMOPTS passed to the test?) >>>>>>>>>>>> >>>>>>>>>>>> Is there a reason this test can't run on OSX? I know it would >>>>>>>>>>>> need >>>>>>>>>>>> further modification but was wondering if there is something >>>>>>>>>>>> inherent in >>>>>>>>>>>> the test that makes it inapplicable to OSX. >>>>>>>>>>>> >>>>>>>>>>>> I think the test would be a lot simpler if the jdk tests had >>>>>>>>>>>> the >>>>>>>>>>>> hotspot >>>>>>>>>>>> test library's process tools available. :( >>>>>>>>>>> We have some, is there an obvious gap? >>>>>>>>>>> >>>>>>>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Hm, thanks for the info. I should have used this library instead. >>>>>>>>>> >>>>>>>>>> Please, stand by for the updated webrev. >>>>>>>>> I was able to get rid off the JCMD. Using the testlibrary the >>>>>>>>> target >>>>>>>>> application can recognize its own PID and print it to its stdout. >>>>>>>>> The >>>>>>>>> main application then just reads the stdout to parse the PID. No >>>>>>>>> need >>>>>>>>> for JCMD any more. >>>>>>>>> >>>>>>>>> I could not find a way to remove the dependency on "test.jdk" >>>>>>>>> system >>>>>>>>> property. According to the jtreg web documentation >>>>>>>>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a >>>>>>>>> "test.java" >>>>>>>>> system property should be available but in fact is not. But it >>>>>>>>> seems >>>>>>>>> that the testlibrary uses "test.jdk" system property too. >>>>>>>>> >>>>>>>>> The test does not run on OSX because nobody built the launcher >>>>>>>>> binary :) >>>>>>>>> I think it is a kind of DIY so I took the liberty of adding a >>>>>>>>> linux-amd64 launcher while working on the test. >>>>>>>>> >>>>>>>>> While working with the test library I realized I was missing a >>>>>>>>> crucial >>>>>>>>> feature (at least for my purposes) - waiting for a certain >>>>>>>>> message to >>>>>>>>> appear in the stdout/stderr of the launched process. Very often I >>>>>>>>> need >>>>>>>>> to wait for the target process to get to certain point before the >>>>>>>>> test >>>>>>>>> can be allowed to continue - and the point is indicated by a >>>>>>>>> message in >>>>>>>>> stdout/stderr. Currently all the proc tools are designed to >>>>>>>>> work in >>>>>>>>> "batch" mode - the whole stdout/stderr is captured in strings and >>>>>>>>> analyzed after the target process died - and are not suitable for >>>>>>>>> this >>>>>>>>> kind of usage. >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 >>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -Chris. >>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>>>>>>>>>>> Please, review the patch for an intermittently failing test. >>>>>>>>>>>>> >>>>>>>>>>>>> The test is a shell test, using files for the interprocess >>>>>>>>>>>>> synchronization. This leads to intermittent failures. >>>>>>>>>>>>> >>>>>>>>>>>>> In order to fix this the test is rewritten in Java - the >>>>>>>>>>>>> original >>>>>>>>>>>>> functionality and outputs should be 100% preserved. The >>>>>>>>>>>>> patch is >>>>>>>>>>>>> unfortunately a bit difficult to follow since there is no >>>>>>>>>>>>> similarity >>>>>>>>>>>>> between the *.sh and *.java file so one needs to go through >>>>>>>>>>>>> the >>>>>>>>>>>>> new >>>>>>>>>>>>> source in whole. >>>>>>>>>>>>> >>>>>>>>>>>>> The changes in "launcher" files are all about adding >>>>>>>>>>>>> permissions to >>>>>>>>>>>>> execute (0755) and as such the webrev shows no differences. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Issue : JDK-8004926 >>>>>>>>>>>>> Webrev : >>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>>>>>>>>>>> >>>>>>>>>>>>> -JB- >>>>>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> > From ioi.lam at oracle.com Wed Oct 9 22:30:19 2013 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 09 Oct 2013 22:30:19 -0700 Subject: RFR 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::,compare_entry_to and copy_entry_to In-Reply-To: <52560B3D.1090009@oracle.com> References: <52544E78.9090103@oracle.com> <5255DB2A.5080209@oracle.com> <52560B3D.1090009@oracle.com> Message-ID: <52563B6B.4050003@oracle.com> Coleen, I would suggest adding these sanity checks: 1063 } break; 1064 case JVM_CONSTANT_UnresolvedClassInError: case JVM_CONSTANT_MethodHandleInError: case JVM_CONSTANT_MethodTypeInError: assert(0, "should have been eliminated by normalize_error_tag"); // fall through 1065 // Invalid is used as the tag for the second constant pool entry 1066 // occupied by JVM_CONSTANT_Double or JVM_CONSTANT_Long. It should 1067 // not be seen by itself. 1068 case JVM_CONSTANT_Invalid: // fall through 1069 1070 default: 1071 ShouldNotReachHere(); 1072 break; 1073 } Thanks - Ioi On 10/09/2013 07:04 PM, Coleen Phillimore wrote: > > Thanks Dan! > Coleen > > On 10/9/2013 6:39 PM, Daniel D. Daugherty wrote: >> On 10/8/13 12:27 PM, Coleen Phillimore wrote: >>> Summary: Add missing cases. >>> >>> I verified this with the test for >>> https://bugs.openjdk.java.net/browse/JDK-8022701 but don't want to >>> copy the test into with modifications the hotspot repository, still >>> working on refactoring the test for the JDK repository for after >>> this gets pushed. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8025185/ >> >> src/share/vm/oops/constantPool.cpp >> No comments. >> >> Thumbs up. >> >> Dan >> >> >>> bug link https://bugs.openjdk.java.net/browse/JDK-8025185 >>> >>> Thanks, >>> Coleen >>> >>> >> > From coleen.phillimore at oracle.com Wed Oct 9 23:26:32 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 10 Oct 2013 06:26:32 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20131010062639.0FC2262EC0@hg.openjdk.java.net> Changeset: b4a4fdc1f464 Author: coleenp Date: 2013-10-09 21:45 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b4a4fdc1f464 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::compare_entry_to and copy_entry_to Summary: Add missing cases. Reviewed-by: sspitsyn, dcubed ! src/share/vm/oops/constantPool.cpp Changeset: e831448418ac Author: coleenp Date: 2013-10-09 22:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e831448418ac Merge From shanliang.jiang at oracle.com Wed Oct 9 23:49:33 2013 From: shanliang.jiang at oracle.com (shanliang.jiang at oracle.com) Date: Thu, 10 Oct 2013 06:49:33 +0000 Subject: hg: jdk8/tl/jdk: 8025206: Intermittent test failure: javax/management/monitor/NullAttributeValueTest.java Message-ID: <20131010064945.52B3A62EC3@hg.openjdk.java.net> Changeset: e8097e1e18a7 Author: sjiang Date: 2013-10-10 08:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8097e1e18a7 8025206: Intermittent test failure: javax/management/monitor/NullAttributeValueTest.java Reviewed-by: dholmes, dfuchs, jbachorik ! test/javax/management/monitor/NullAttributeValueTest.java From shanliang.jiang at oracle.com Wed Oct 9 23:38:38 2013 From: shanliang.jiang at oracle.com (shanliang.jiang at oracle.com) Date: Thu, 10 Oct 2013 06:38:38 +0000 Subject: hg: jdk8/tl/jdk: 8025207: Intermittent test failure: javax/management/monitor/CounterMonitorThresholdTest.java Message-ID: <20131010063900.29E1C62EC1@hg.openjdk.java.net> Changeset: e901a618dcff Author: sjiang Date: 2013-10-10 08:37 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e901a618dcff 8025207: Intermittent test failure: javax/management/monitor/CounterMonitorThresholdTest.java Reviewed-by: dfuchs, dholmes ! test/javax/management/monitor/CounterMonitorThresholdTest.java From shanliang.jiang at oracle.com Thu Oct 10 00:04:02 2013 From: shanliang.jiang at oracle.com (shanliang.jiang at oracle.com) Date: Thu, 10 Oct 2013 07:04:02 +0000 Subject: hg: jdk8/tl/jdk: 8025205: Intermittent test failure: javax/management/remote/mandatory/connection/BrokenConnectionTest.java Message-ID: <20131010070414.34A2A62EC4@hg.openjdk.java.net> Changeset: a30f6fd581b3 Author: sjiang Date: 2013-10-10 09:01 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a30f6fd581b3 8025205: Intermittent test failure: javax/management/remote/mandatory/connection/BrokenConnectionTest.java Reviewed-by: dholmes, dfuchs, jbachorik ! test/javax/management/remote/mandatory/connection/BrokenConnectionTest.java From staffan.larsen at oracle.com Thu Oct 10 00:38:46 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 10 Oct 2013 07:38:46 +0000 Subject: hg: jdk8/tl/jdk: 8025427: jstat tests fails on 32-bit platforms Message-ID: <20131010073859.3EABA62EC9@hg.openjdk.java.net> Changeset: 6aa637dde16e Author: sla Date: 2013-10-10 09:38 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6aa637dde16e 8025427: jstat tests fails on 32-bit platforms Reviewed-by: ehelin, dsamersoff, dholmes, sspitsyn ! src/share/classes/sun/tools/jstat/RowClosure.java ! test/ProblemList.txt ! test/sun/tools/jstat/gcCauseOutput1.awk ! test/sun/tools/jstat/lineCounts1.awk ! test/sun/tools/jstat/lineCounts2.awk ! test/sun/tools/jstat/lineCounts3.awk ! test/sun/tools/jstat/lineCounts4.awk ! test/sun/tools/jstat/timeStamp1.awk ! test/sun/tools/jstatd/jstatGcutilOutput1.awk From mandy.chung at oracle.com Thu Oct 10 00:45:02 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 10 Oct 2013 00:45:02 -0700 Subject: RFR (S) JDK-8025700: RuntimeMXBean.getInputArguments() should include -server/-client/-d32/-d64 In-Reply-To: References: <524D73C4.7060004@oracle.com> <5253A32D.40502@oracle.com> <52541925.5030907@oracle.com> <525509CB.1050301@oracle.com> <52551185.8070209@oracle.com> <52551BFB.5040309@oracle.com> <52552011.6020904@oracle.com> Message-ID: <52565AFE.1000209@oracle.com> On 10/9/2013 11:53 AM, Staffan Larsen wrote: > I can absolutely see where Aleksey (and 99% of the Java users) is coming from. From a user perspective there is no difference between the launcher arguments and the JVM arguments. Unfortunately the implementation does make a difference between them and it's not easy to hide this difference. > > A similar problem is that the actual main-class is not known by the JVM. We work around this with the sun.java.command property, but when a custom launcher is used that property is not set and so we lack information about this in the JVM (and in the management APIs). The typical example of this for me is running eclipse. I also think that this is a good enhancement to obtain the information required to relaunch the VM besides JVM arguments as well as the entry point. BTW main-class is one kind of entry point and it would be useful to monitoring the entry point for use by other agents. > Perhaps we could extend the JNI invocation API to allow these things to be passed through? That's probably the appropriate API to take additional non-VM information to pass through. > A problem is of course to define what a "launcher argument" is. For example, sometimes Java is launched from inside another application (web browser, anyone?) and then the arguments to that host process makes little sense to pass on. Maybe just not to define what the value to the VM is - simply some String passed from the one who creates the VM and publish that via a supported API. Mandy > Regards, > /Staffan > > On 9 okt 2013, at 11:21, Aleksey Shipilev wrote: > >> On 10/09/2013 01:03 PM, Mandy Chung wrote: >>>> Do you see any better option? >>> I no longer work in this area and don't have any suggestion at the >>> moment. Although parsing of VM name is not ideal, I suggest it as a >>> workaround for now and give the serviceability team time to look into >>> this to address your request. >> Ok, I'll leave the ticket open meanwhile. >> >> Thanks, >> -Aleksey. >> From weijun.wang at oracle.com Thu Oct 10 00:26:37 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 10 Oct 2013 07:26:37 +0000 Subject: hg: jdk8/tl/jdk: 8026235: keytool NSS test should use 64 bit lib on Solaris Message-ID: <20131010072652.AE4E062EC5@hg.openjdk.java.net> Changeset: 74b4d20769fd Author: weijun Date: 2013-10-10 15:24 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74b4d20769fd 8026235: keytool NSS test should use 64 bit lib on Solaris Reviewed-by: vinnie ! test/sun/security/tools/keytool/autotest.sh From staffan.larsen at oracle.com Thu Oct 10 01:02:39 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 10 Oct 2013 10:02:39 +0200 Subject: RR(S): JDK-8005810: SA: Update Hotspot Serviceability Agent for Method Parameter Reflection and Generic Type Signature Data In-Reply-To: <5255C3BE.2020601@oracle.com> References: <525577C3.6020101@oracle.com> <4B22AD89-66CD-4CDE-9DA8-40934E04A31D@oracle.com> <5255C3BE.2020601@oracle.com> Message-ID: Ok. I would have preferred an explicit test, but this seems to cover it. Reviewed! /Staffan On 9 okt 2013, at 22:59, Dmitry Samersoff wrote: > Staffan, > > I don't have specific test, but I rebuild vm testbase with -parameters > and then run nsk.sajdi. > > -Dmitry > > On 2013-10-09 22:04, Staffan Larsen wrote: >> Dmitry, >> >> Are there any tests that exercise this functionality? >> >> /Staffan >> >> On 9 okt 2013, at 17:35, Dmitry Samersoff wrote: >> >>> Hi Everybody, >>> >>> Please, review the changes for: >>> >>> JDK-8005810: Update Hotspot Serviceability Agent for Method Parameter >>> Reflection and Generic Type Signature Data >>> >>> The fix contributed by Eric McCorkle. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8005810/webrev.01/ >>> >>> https://bugs.openjdk.java.net/browse/JDK-8005810 >>> >>> -Dmitry >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Thu Oct 10 01:43:56 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 10 Oct 2013 08:43:56 +0000 Subject: hg: jdk8/tl/jdk: 8014446: JT_JDK: Wrong detection of test result for test com/sun/jdi/NoLaunchOptionTest.java Message-ID: <20131010084446.2952162ED0@hg.openjdk.java.net> Changeset: 998560cccefc Author: allwin Date: 2013-10-10 10:14 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/998560cccefc 8014446: JT_JDK: Wrong detection of test result for test com/sun/jdi/NoLaunchOptionTest.java Reviewed-by: sla, mgronlun, dholmes, jbachorik, chegar ! test/com/sun/jdi/NoLaunchOptionTest.java From alan.bateman at oracle.com Thu Oct 10 02:01:24 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 10 Oct 2013 09:01:24 +0000 Subject: hg: jdk8/tl/jdk: 7011859: java/util/concurrent/Semaphore/RacingReleases.java failing Message-ID: <20131010090153.05EAF62ED4@hg.openjdk.java.net> Changeset: 99b7bbe0474f Author: dl Date: 2013-10-10 09:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/99b7bbe0474f 7011859: java/util/concurrent/Semaphore/RacingReleases.java failing Reviewed-by: alanb, dholmes ! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java From david.holmes at oracle.com Thu Oct 10 01:59:24 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 10 Oct 2013 08:59:24 +0000 Subject: hg: jdk8/tl/jdk: 8026232: Move libnpt from profile compact1 to compact3 Message-ID: <20131010085955.5711062ED3@hg.openjdk.java.net> Changeset: 254173b48dcb Author: dholmes Date: 2013-10-10 04:57 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/254173b48dcb 8026232: Move libnpt from profile compact1 to compact3 Reviewed-by: mchung, alanb ! makefiles/profile-includes.txt From david.holmes at oracle.com Thu Oct 10 02:09:20 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Oct 2013 19:09:20 +1000 Subject: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <52557025.7060706@oracle.com> References: <523D144E.4000002@oracle.com> <524B8A78.9040807@oracle.com> <52548E6D.80701@oracle.com> <525545E3.3060504@oracle.com> <52557025.7060706@oracle.com> Message-ID: <52566EC0.4090405@oracle.com> I'm fine with not adding untestable minimal VM support. Thanks, David On 10/10/2013 1:03 AM, Daniel D. Daugherty wrote: > Replies also inline... > > > On 10/9/13 6:02 AM, David Holmes wrote: >> inline ... >> >> On 9/10/2013 8:59 AM, Daniel D. Daugherty wrote: >>> On 10/1/13 8:52 PM, David Holmes wrote: >>>> - hotspot/make/Makefile >>>> >>>> + $(EXPORT_CLIENT_DIR)/%.dSYM: $(MINIMAL1_BUILD_DIR)/%.dSYM >>>> >>>> EXPORT_CLIENT_DIR should be EXPORT_MINIMAL_DIR. >>>> >>>> For fun you can try building minimal on OSX, but I don't know how far >>>> you will get: >>>> >>>> --with-jvm-variants=client,server,minimal1 >>>> >>>> I'll point out obvious issues with minimal VM support anyway. >>> >>> Since you pointed out in a later email that minimal1 isn't >>> supported on MacOS X, I'm going to drop those changes. I'm >>> going to leave the Client VM support since there are folks >>> out in OpenJDK trying to get the Client VM working on MacOS X. >>> >>> It does look like someone added minimal1 support for other >>> non-Linux platforms, but I'm not planning to clean that up. >> >> Yes I did that when adding minimal support. Seemed better than leaving >> someone to have to rediscover what needed to be implemented if/when >> minimal support was expanded. > > Thanks for the history. Are you still OK if I leave out the > FDS Minimal1 support? > > >> Someday I hope to remove all the duplicated EXPORT_* stuff and >> generate it based on the requested JDK_VARIANT_* values. And do it in >> a platform indpendent way - once! :) > > Well it can be mostly platform independent, but there will be > minor differences in what is exported by the different platforms. > > >> >>>> Note that the whole jdk6_or_earlier logic is defunct as this will >>>> never be used for jdk6 or earlier. But best to clean all that up at >>>> the one time. >>> >>> Agreed that we (Oracle) currently don't have plans to drop HSX-25 into >>> JDK6 or OpenJDK6, but I don't want to rule out future insanity. >> >> I do! We need to cut ties with historical baggage. > > Good sentiment, but not for this changeset. I'll file a bug to track > your idea of "best to clean all that up at one time". > > >> >>>> - make/bsd/makefiles/universal.gmk >>>> >>>> I did not understand the additional logic here: >>>> >>>> 63 # Copy built non-universal binaries in place >>>> 64 $(UNIVERSAL_COPY_LIST): >>>> 65 BUILT_COPY_FILES="`find >>>> $(EXPORT_JRE_LIB_DIR)/{i386,amd64}/$(subst $(EXPORT_JRE_LIB_DIR)/,,$@) >>>> 2>/dev/null`"; \ >>>> 66 if [ -n "$${BUILT_COPY_FILES}" ]; then \ >>>> 67 for i in $${BUILT_COPY_FILES}; do \ >>>> 68 if [ -f $${i} ]; then \ >>>> 69 $(MKDIR) -p $(shell dirname $@); \ >>>> 70 $(CP) -R $${i} $@; \ >>>> 71 fi; \ >>>> 72 if [ -d $${i} ]; then \ >>>> 73 $(MKDIR) -p $@; \ >>>> 74 fi; \ >>>> 75 done; \ >>>> 76 fi >>>> >>>> until I realized that foo.dSYM is a directory not a file! Even so >>>> don't you want to copy the contents of the directory across ? >>> >>> BUILT_COPY_FILES includes both files and directories so everything >>> should get copied across. I've added some commments to the rule >>> header and reorganized the logic a bit to hopefully be more clear. >> >> Doesn't this assume that the directory will appear before the files >> within it? Is that guaranteed? > > The way find works is that it lists the directory prior to listing > the files within the directory. However, even if find didn't, the > containing directory would be created via line 69 above. The one > non-obvious feature of lines 72-74 is that an empty directory named > in the BUILD_COPY_FILES list would get 'copied' to the destination. > > Please check out the latest version when I get it out for review. > > >> Which leads me to ask why we have cp -R for copying files? > > MacOS X strongly discourages use of 'cp -r' and recommends 'cp -R' > instead because 'cp -R' properly copies non-directory and non-file > file system objects, e.g., symlinks. So if BUILD_COPY_FILES happens > to contain a symlink, then the symlink is copied to the destination. > > >> >>>> - jdk/makefiles/Tools.gmk >>>> >>>> Not sure about this one. Logically is seems correct but up to now this >>>> has been defined for everything without it seeming to cause a problem. >>>> So why do we need to change it and what impact will it have? >>> >>> It just seemed wrong to define something that should never be used >>> on non-Solaris platforms. My control build of the entire forest >>> didn't have an issue with this change so I'm planning to keep it. >> >> Ok. >> >> Thanks, >> David > > Again, thanks for the thorough reviews. > > Dan > > >> >>> Dan >>> >>> >>> >>>> >>>> David >>>> ----- >>>> >>>> On 21/09/2013 1:36 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I have the initial support for Full Debug Symbols (FDS) on MacOS X >>>>> done >>>>> and ready for review: >>>>> >>>>> 7165611 implement Full Debug Symbols on MacOS X hotspot >>>>> https://bugs.openjdk.java.net/browse/JDK-7165611 >>>>> >>>>> Here is the JDK8/HSX-25 webrev URL: >>>>> >>>>> OpenJDK: >>>>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >>>>> Internal: >>>>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >>>>> >>>>> >>>>> This webrev includes changes for the follow repos: >>>>> >>>>> jdk8 >>>>> jdk8/hotspot >>>>> jdk8/jdk >>>>> jdk8/jdk/make/closed >>>>> >>>>> Once these changes are approved, I'm planning to push them to >>>>> RT_Baseline. From there, they can follow the normal path to >>>>> Main_Baseline and eventually JDK8. >>>>> >>>>> This work enables FDS on MacOS X for the 'hotspot' repo; the >>>>> changes in >>>>> the other repos are necessary to support importing the .diz files from >>>>> the MacOS X 'hotspot' build into the forest build. I also fixed a few >>>>> FDS related errors in the magic incantations for the new build. >>>>> This is >>>>> mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported >>>>> from Solaris. In other words, this is Frankenstein's monster... >>>>> >>>>> Thanks to Staffan Larsen for providing an initial set of changes >>>>> which I morphed into what you see here. >>>>> >>>>> Testing: >>>>> - JPRT HSX build and test on all platforms; verification of .diz >>>>> files in the MacOS X JPRT bundles >>>>> - JPRT JDK8 forest build and test on all platforms; verification of >>>>> .diz files in the MacOS X JPRT bundles >>>>> Note: In previous FDS changesets, I also did a standalone 'jdk' >>>>> repo build and test, but that no longer seems to work. >>>>> >>>>> As always, comments, questions and suggestions are welcome. >>>>> >>>>> Dan >>> > From fredrik.arvidsson at oracle.com Thu Oct 10 03:24:08 2013 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Thu, 10 Oct 2013 12:24:08 +0200 Subject: RFR (XS) 8024425: VM_HeapDumper doesn't put anonymous classes in the heap dump Message-ID: <52568048.5050109@oracle.com> Hi Please help me to review the changes below: Jira case: https://bugs.openjdk.java.net/browse/JDK-8024425 Webrev: http://cr.openjdk.java.net/~allwin/farvidss/8024425/webrev.00/ About this change. I switched from using the SystemDictionary to use ClassLoaderDataGraph instead since the SystemDictionary lack information about the 'anonymous' classes related to this bug. Previously failed Aurora tests have been run using UTE and verified to PASS. The heap dump file have been successfully opened and parsed using jhat and eclipse MAT. Cheers /Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131010/99a48e73/attachment.html From fredrik.arvidsson at oracle.com Thu Oct 10 03:42:05 2013 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Thu, 10 Oct 2013 12:42:05 +0200 Subject: RFR (S) 8025638: jmap returns 0 instead of 1 when it fails. Message-ID: <5256847D.6060103@oracle.com> Hi Please help me to review the changes below: Jira case: https://bugs.openjdk.java.net/browse/JDK-8025638 Webrev: http://cr.openjdk.java.net/~allwin/farvidss/8025638/webrev.00/ About this change. A previous change (https://bugs.openjdk.java.net/browse/JDK-8010278) in the Tool.java class caused any tool deriving from this base class return the wrong value to the caller when failing. Changes were made to the Tool.java class and to the derived tool implementation classes to handle errors/exceptions during execution and ensure that the tool returns 1 to the caller if it fails, and 0 if it succeeds. Previously failed Aurora tests have been run using UTE and verified to PASS. Cheers /Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131010/d60a0c05/attachment.html From jaroslav.bachorik at oracle.com Thu Oct 10 04:02:24 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 10 Oct 2013 13:02:24 +0200 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <525622B4.5020606@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> <52556604.3080900@oracle.com> <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> <525622B4.5020606@oracle.com> Message-ID: <52568940.4000704@oracle.com> On 10.10.2013 05:44, David Holmes wrote: > On 10/10/2013 4:12 AM, Staffan Larsen wrote: >> >> On 9 okt 2013, at 16:19, Jaroslav Bachorik >> wrote: >> >>> On 9.10.2013 16:10, Staffan Larsen wrote: >>>> There is now an awful amount of different timestamps in the >>>> Management class. Can they be consolidated somehow? At least >>>> _begin_vm_creation_time and the new _begin_vm_creation_ns. >>>> >>>> This discussion also implies that the "elapsed time" we print in the >>>> hs_err file is also wrong. It uses os::elapsedTime() which uses >>>> os::elapsed_counter(). >>>> >>>> And I guess the same thing for the VM.uptime Diagnostic Command >>>> (class VMUptimeDCmd) which also relies on os::elapsed_counter(). >>> >>> Also the reported GC pauses duration might be wrong since it uses >>> Management::timestamp(). >>> >>> On the first sight the change looks rather trivial. But, honestly, >>> I'm not sure which other parts could for whatever reason break once >>> the time-of-day timestamp is replaced with a monotonic equivalent. >>> One would think that it shouldn't matter but one never knows ... >>> >>> Staffan, do you think this kind of change is suitable for the current >>> phase of JDK release cycle? I think I could improve the patch in few >>> days and then it should probably be able to pass the review before >>> ZBB. But, it's only P3 ... >> >> I think it is a bit late in the release cycle to clean this up in the >> way it should be cleaned up. I think we should wait until the first 8 >> update release and do a more thorough job than we have time for right >> now. > > I second that. The elapsed_counter/elpased_timer APIs and > implementations are a tangled mess. But part of the problem has been > that people want/expect monotonic time-of-day based timestamps (yes a > contradiction - though some people make sure TOD does not get modified > on their production systems). The use of timestamps in logging has to be > examined carefully - mainly GC logging. I recall a "simple" attempted > change in the past that resulted in trying to compare a nanoTime based > timestamp with the TOD. :( Actually, if I'm reading the sources right for Solaris and Win the monotonic clock source is used to provide elapsed_counter() value. It falls back to TOD when the monotonic clock source is not available. For Linux/BSD the TOD is used directly. This makes me wonder if changing the linux/bsd implementation to follow the same logic would be really that disruptive. -JB- > > David > ----- > >> /Staffan >> >> >>> >>> -JB- >>> >>>> >>>> /Staffan >>>> >>>> >>>> On 9 okt 2013, at 13:26, Jaroslav Bachorik >>>> wrote: >>>> >>>>> On 8.10.2013 23:46, David Holmes wrote: >>>>>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>>>>> On 8.10.2013 09:34, David Holmes wrote: >>>>>>>> Jaroslav, >>>>>>>> >>>>>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> currently the JVM uptime reported by the RuntimeMXBean is based on >>>>>>>>> System.currentTimeMillis() which makes it susceptible to >>>>>>>>> changes of the >>>>>>>>> OS time (eg. changing timezone, NTP synchronization etc.). The >>>>>>>>> uptime >>>>>>>>> should not depend on the system time and should be calculated >>>>>>>>> using a >>>>>>>>> monotonic clock source. >>>>>>>>> >>>>>>>>> There is already the way to get the actual JVM uptime in ticks. >>>>>>>>> It is >>>>>>>>> accessible as Management::timestamp() and the ticks are >>>>>>>>> convertible to >>>>>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus >>>>>>>>> making it >>>>>>>>> very >>>>>>>>> easy to switch to the monotonic clock based uptime. >>>>>>>> >>>>>>>> Maybe I'm missing something but TiumeStamp updates using >>>>>>>> os::elapsed_counter() which on Linux uses gettimeofday so is not a >>>>>>>> monotonic clock source. >>>>>>> >>>>>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>>>>> >>>>>>> Is there any reason why a non monotonic clock source is used for >>>>>>> timestamping except of the historical one? os::javaTimeNanos() uses >>>>>>> montonic clock when available - why can't be the same used for >>>>>>> os::elapsed_counter() especially when a counter based on >>>>>>> "gettimeofday" >>>>>>> is not really a counter? >>>>>> >>>>>> It is all historical. These elapsed_counters and elapsed_timers >>>>>> make me >>>>>> cringe. But changing it has a lot of potential consequences >>>>>> because of >>>>>> the way these are used in logging etc. Certainly not something to be >>>>>> contemplated at this stage of JDK 8. >>>>>> >>>>>> Perhaps a simpler fix here is to expose a startUpTimeNanos that >>>>>> can then >>>>>> be used for the uptime. >>>>> >>>>> My attempt at this is at >>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >>>>> I am using os::javaTimeNanos() to get the monotonic ticks where >>>>> possible. >>>>> >>>>> The JDK part stays the same as for webrev.00 >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> David >>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> The patch consists of the hotspot and jdk parts. >>>>>>>>> >>>>>>>>> For the hotspot a new constant needs to be introduced in >>>>>>>>> src/share/vm/services/jmm.h and the actual logic to obtain the >>>>>>>>> uptime in >>>>>>>>> milliseconds is added in src/share/vm/services/management.cpp. >>>>>>>>> >>>>>>>>> For the jdk the changes comprise of adding the necessary JNI >>>>>>>>> bridging >>>>>>>>> methods in order to get the new uptime, introducing the same >>>>>>>>> constant >>>>>>>>> that is used in hotspot and changes to mapfile-vers files in >>>>>>>>> order to >>>>>>>>> properly build the native library. >>>>>>>>> >>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -JB- >>>>>>> >>>>> >>>> >>> >> From staffan.larsen at oracle.com Thu Oct 10 04:15:49 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 10 Oct 2013 13:15:49 +0200 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <52568940.4000704@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> <52556604.3080900@oracle.com> <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> <525622B4.5020606@oracle.com> <52568940.4000704@oracle.com> Message-ID: <23435103-156B-434F-994C-B6F913EE0364@oracle.com> On 10 okt 2013, at 13:02, Jaroslav Bachorik wrote: > On 10.10.2013 05:44, David Holmes wrote: >> On 10/10/2013 4:12 AM, Staffan Larsen wrote: >>> >>> On 9 okt 2013, at 16:19, Jaroslav Bachorik >>> wrote: >>> >>>> On 9.10.2013 16:10, Staffan Larsen wrote: >>>>> There is now an awful amount of different timestamps in the >>>>> Management class. Can they be consolidated somehow? At least >>>>> _begin_vm_creation_time and the new _begin_vm_creation_ns. >>>>> >>>>> This discussion also implies that the "elapsed time" we print in the >>>>> hs_err file is also wrong. It uses os::elapsedTime() which uses >>>>> os::elapsed_counter(). >>>>> >>>>> And I guess the same thing for the VM.uptime Diagnostic Command >>>>> (class VMUptimeDCmd) which also relies on os::elapsed_counter(). >>>> >>>> Also the reported GC pauses duration might be wrong since it uses >>>> Management::timestamp(). >>>> >>>> On the first sight the change looks rather trivial. But, honestly, >>>> I'm not sure which other parts could for whatever reason break once >>>> the time-of-day timestamp is replaced with a monotonic equivalent. >>>> One would think that it shouldn't matter but one never knows ... >>>> >>>> Staffan, do you think this kind of change is suitable for the current >>>> phase of JDK release cycle? I think I could improve the patch in few >>>> days and then it should probably be able to pass the review before >>>> ZBB. But, it's only P3 ... >>> >>> I think it is a bit late in the release cycle to clean this up in the >>> way it should be cleaned up. I think we should wait until the first 8 >>> update release and do a more thorough job than we have time for right >>> now. >> >> I second that. The elapsed_counter/elpased_timer APIs and >> implementations are a tangled mess. But part of the problem has been >> that people want/expect monotonic time-of-day based timestamps (yes a >> contradiction - though some people make sure TOD does not get modified >> on their production systems). The use of timestamps in logging has to be >> examined carefully - mainly GC logging. I recall a "simple" attempted >> change in the past that resulted in trying to compare a nanoTime based >> timestamp with the TOD. :( > > Actually, if I'm reading the sources right for Solaris and Win the monotonic clock source is used to provide elapsed_counter() value. It falls back to TOD when the monotonic clock source is not available. > For Linux/BSD the TOD is used directly. > > This makes me wonder if changing the linux/bsd implementation to follow the same logic would be really that disruptive. Good point. I would like a world where elapsed_counter is monotonic (where possible). Still a bit scary this late in the release, but an interesting experiment. /Staffan > > -JB- >> >> David >> ----- >> >>> /Staffan >>> >>> >>>> >>>> -JB- >>>> >>>>> >>>>> /Staffan >>>>> >>>>> >>>>> On 9 okt 2013, at 13:26, Jaroslav Bachorik >>>>> wrote: >>>>> >>>>>> On 8.10.2013 23:46, David Holmes wrote: >>>>>>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>>>>>> On 8.10.2013 09:34, David Holmes wrote: >>>>>>>>> Jaroslav, >>>>>>>>> >>>>>>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> currently the JVM uptime reported by the RuntimeMXBean is based on >>>>>>>>>> System.currentTimeMillis() which makes it susceptible to >>>>>>>>>> changes of the >>>>>>>>>> OS time (eg. changing timezone, NTP synchronization etc.). The >>>>>>>>>> uptime >>>>>>>>>> should not depend on the system time and should be calculated >>>>>>>>>> using a >>>>>>>>>> monotonic clock source. >>>>>>>>>> >>>>>>>>>> There is already the way to get the actual JVM uptime in ticks. >>>>>>>>>> It is >>>>>>>>>> accessible as Management::timestamp() and the ticks are >>>>>>>>>> convertible to >>>>>>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus >>>>>>>>>> making it >>>>>>>>>> very >>>>>>>>>> easy to switch to the monotonic clock based uptime. >>>>>>>>> >>>>>>>>> Maybe I'm missing something but TiumeStamp updates using >>>>>>>>> os::elapsed_counter() which on Linux uses gettimeofday so is not a >>>>>>>>> monotonic clock source. >>>>>>>> >>>>>>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>>>>>> >>>>>>>> Is there any reason why a non monotonic clock source is used for >>>>>>>> timestamping except of the historical one? os::javaTimeNanos() uses >>>>>>>> montonic clock when available - why can't be the same used for >>>>>>>> os::elapsed_counter() especially when a counter based on >>>>>>>> "gettimeofday" >>>>>>>> is not really a counter? >>>>>>> >>>>>>> It is all historical. These elapsed_counters and elapsed_timers >>>>>>> make me >>>>>>> cringe. But changing it has a lot of potential consequences >>>>>>> because of >>>>>>> the way these are used in logging etc. Certainly not something to be >>>>>>> contemplated at this stage of JDK 8. >>>>>>> >>>>>>> Perhaps a simpler fix here is to expose a startUpTimeNanos that >>>>>>> can then >>>>>>> be used for the uptime. >>>>>> >>>>>> My attempt at this is at >>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >>>>>> I am using os::javaTimeNanos() to get the monotonic ticks where >>>>>> possible. >>>>>> >>>>>> The JDK part stays the same as for webrev.00 >>>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> The patch consists of the hotspot and jdk parts. >>>>>>>>>> >>>>>>>>>> For the hotspot a new constant needs to be introduced in >>>>>>>>>> src/share/vm/services/jmm.h and the actual logic to obtain the >>>>>>>>>> uptime in >>>>>>>>>> milliseconds is added in src/share/vm/services/management.cpp. >>>>>>>>>> >>>>>>>>>> For the jdk the changes comprise of adding the necessary JNI >>>>>>>>>> bridging >>>>>>>>>> methods in order to get the new uptime, introducing the same >>>>>>>>>> constant >>>>>>>>>> that is used in hotspot and changes to mapfile-vers files in >>>>>>>>>> order to >>>>>>>>>> properly build the native library. >>>>>>>>>> >>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -JB- >>>>>>>> >>>>>> >>>>> >>>> >>> > From staffan.larsen at oracle.com Thu Oct 10 04:36:04 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 10 Oct 2013 13:36:04 +0200 Subject: RFR (XS) 8024425: VM_HeapDumper doesn't put anonymous classes in the heap dump In-Reply-To: <52568048.5050109@oracle.com> References: <52568048.5050109@oracle.com> Message-ID: <455C88F2-D232-4458-B2B9-160B613AEAF9@oracle.com> instanceKlass.cpp:2318 - should use jio_snprintf() instead of sprintf() I'm also wondering if this method should be re-written to use jio_snprintf() as the method for concatenating the strings? /Staffan On 10 okt 2013, at 12:24, Fredrik Arvidsson wrote: > Hi > > Please help me to review the changes below: > > Jira case: https://bugs.openjdk.java.net/browse/JDK-8024425 > Webrev: http://cr.openjdk.java.net/~allwin/farvidss/8024425/webrev.00/ > > About this change. > I switched from using the SystemDictionary to use ClassLoaderDataGraph instead since the SystemDictionary lack information about the 'anonymous' classes related to this bug. > > Previously failed Aurora tests have been run using UTE and verified to PASS. The heap dump file have been successfully opened and parsed using jhat and eclipse MAT. > > Cheers > /Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131010/aa9e420f/attachment.html From staffan.larsen at oracle.com Thu Oct 10 04:38:09 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 10 Oct 2013 13:38:09 +0200 Subject: RFR (S) 8025638: jmap returns 0 instead of 1 when it fails. In-Reply-To: <5256847D.6060103@oracle.com> References: <5256847D.6060103@oracle.com> Message-ID: <918A0955-6236-4916-BD54-F344EC9AADEA@oracle.com> Clicking on the link in this email takes me to the wrong webrev. The correct URL is in the text: http://cr.openjdk.java.net/~allwin/farvidss/8025638/webrev.00/ /Staffan On 10 okt 2013, at 12:42, Fredrik Arvidsson wrote: > Hi > > Please help me to review the changes below: > > Jira case: https://bugs.openjdk.java.net/browse/JDK-8025638 > Webrev: http://cr.openjdk.java.net/~allwin/farvidss/8025638/webrev.00/ > > About this change. > A previous change (https://bugs.openjdk.java.net/browse/JDK-8010278) in the Tool.java class caused any tool deriving from this base class return the wrong value to the caller when failing. > Changes were made to the Tool.java class and to the derived tool implementation classes to handle errors/exceptions during execution and ensure that the tool returns 1 to the caller if it fails, and 0 if it succeeds. > > Previously failed Aurora tests have been run using UTE and verified to PASS. > > Cheers > /Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131010/9567ee01/attachment.html From michael.x.mcmahon at oracle.com Thu Oct 10 04:38:41 2013 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 10 Oct 2013 11:38:41 +0000 Subject: hg: jdk8/tl/jdk: 7076487: (sctp) SCTP API classes does not exist in JDK for Mac Message-ID: <20131010113908.54B3C62EEB@hg.openjdk.java.net> Changeset: 8294c49d23b3 Author: michaelm Date: 2013-10-10 12:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8294c49d23b3 7076487: (sctp) SCTP API classes does not exist in JDK for Mac Reviewed-by: alanb, chegar ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk + src/macosx/classes/sun/nio/ch/sctp/SctpChannelImpl.java + src/macosx/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java + src/macosx/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java From staffan.larsen at oracle.com Thu Oct 10 04:49:12 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 10 Oct 2013 13:49:12 +0200 Subject: RFR (S) 8025638: jmap returns 0 instead of 1 when it fails. In-Reply-To: <918A0955-6236-4916-BD54-F344EC9AADEA@oracle.com> References: <5256847D.6060103@oracle.com> <918A0955-6236-4916-BD54-F344EC9AADEA@oracle.com> Message-ID: <423EB291-3E36-41F7-86F6-6362D0B49839@oracle.com> Thanks for doing this! Tool.java:116 - shouldn't the default return value be 1? In case start() throws an exception for some reason. Tool.java: I find the start(String[] args), start(), startInternal() methods confusing in naming and usage. Not directly related to your change of course, just a comment on the code. /Staffan On 10 okt 2013, at 13:38, Staffan Larsen wrote: > Clicking on the link in this email takes me to the wrong webrev. The correct URL is in the text: http://cr.openjdk.java.net/~allwin/farvidss/8025638/webrev.00/ > > /Staffan > > On 10 okt 2013, at 12:42, Fredrik Arvidsson wrote: > >> Hi >> >> Please help me to review the changes below: >> >> Jira case: https://bugs.openjdk.java.net/browse/JDK-8025638 >> Webrev: http://cr.openjdk.java.net/~allwin/farvidss/8025638/webrev.00/ >> >> About this change. >> A previous change (https://bugs.openjdk.java.net/browse/JDK-8010278) in the Tool.java class caused any tool deriving from this base class return the wrong value to the caller when failing. >> Changes were made to the Tool.java class and to the derived tool implementation classes to handle errors/exceptions during execution and ensure that the tool returns 1 to the caller if it fails, and 0 if it succeeds. >> >> Previously failed Aurora tests have been run using UTE and verified to PASS. >> >> Cheers >> /Fredrik > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131010/e39bc652/attachment.html From sundararajan.athijegannathan at oracle.com Thu Oct 10 05:07:16 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 10 Oct 2013 12:07:16 +0000 Subject: hg: jdk8/tl/nashorn: 3 new changesets Message-ID: <20131010120727.9160A62EEC@hg.openjdk.java.net> Changeset: 03a68e7ca1d5 Author: lagergren Date: 2013-10-09 17:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/03a68e7ca1d5 8026137: Fix Issues with Binary Evaluation Order Reviewed-by: hannesw, jlaskey Contributed-by: marcus.lagergren at oracle.com, attila.szegedi at oracle.com ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/codegen/types/BooleanType.java ! src/jdk/nashorn/internal/codegen/types/ObjectType.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java - src/jdk/nashorn/internal/ir/TypeOverride.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/arrays/JavaArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseJavaArrayIterator.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java + test/script/basic/JDK-8026137.js + test/script/basic/JDK-8026137.js.EXPECTED Changeset: 7cc5ff16380f Author: sundar Date: 2013-10-10 11:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7cc5ff16380f 8026167: Class cache/reuse of 'eval' scripts results in ClassCastException in some cases. Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! test/script/assert.js ! test/script/basic/JDK-8019508.js ! test/script/basic/JDK-8019508.js.EXPECTED ! test/script/basic/JDK-8019553.js ! test/script/basic/JDK-8019553.js.EXPECTED ! test/script/basic/JDK-8019791.js ! test/script/basic/JDK-8019791.js.EXPECTED ! test/script/basic/JDK-8019805.js ! test/script/basic/JDK-8019805.js.EXPECTED + test/script/basic/JDK-8026167.js ! test/script/basic/NASHORN-100.js ! test/script/basic/NASHORN-100.js.EXPECTED ! test/script/basic/NASHORN-293.js ! test/script/basic/NASHORN-293.js.EXPECTED ! test/script/basic/NASHORN-40.js ! test/script/basic/NASHORN-40.js.EXPECTED ! test/script/basic/NASHORN-51.js ! test/script/basic/NASHORN-51.js.EXPECTED ! test/script/basic/NASHORN-98.js ! test/script/basic/NASHORN-98.js.EXPECTED ! test/script/basic/eval.js ! test/script/basic/eval.js.EXPECTED Changeset: e60bbcf2f6b6 Author: sundar Date: 2013-10-10 13:17 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e60bbcf2f6b6 8026248: importClass has to be a varargs function Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + test/script/basic/JDK-8026248.js + test/script/basic/JDK-8026248.js.EXPECTED From david.holmes at oracle.com Thu Oct 10 05:15:53 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Oct 2013 22:15:53 +1000 Subject: RFR (XS) 8024425: VM_HeapDumper doesn't put anonymous classes in the heap dump In-Reply-To: <52568048.5050109@oracle.com> References: <52568048.5050109@oracle.com> Message-ID: <52569A79.5020405@oracle.com> Fredrik, On 10/10/2013 8:24 PM, Fredrik Arvidsson wrote: > Hi > > Please help me to review the changes below: > > Jira case: https://bugs.openjdk.java.net/browse/JDK-8024425 > > Webrev: http://cr.openjdk.java.net/~allwin/farvidss/8024425/webrev.00/ > Please make sure what you have in your html email is consistent. Your visible text refers to a different bug id to the actual link - and the links are different to the subject. Can you please re-send this email with corrected links and subject - thanks. Style issues: - ensure spaces are after keywords ie if(x) should be if (x) - two-space indent not four David ----- > About this change. > I switched from using the SystemDictionary to use ClassLoaderDataGraph > instead since the SystemDictionary lack information about the > 'anonymous' classes related to this bug. > > Previously failed Aurora tests have been run using UTE and verified to > PASS. The heap dump file have been successfully opened and parsed using > jhat and eclipse MAT. > > Cheers > /Fredrik From david.holmes at oracle.com Thu Oct 10 05:17:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Oct 2013 22:17:07 +1000 Subject: Codereview request: 8025204 Intermittent test failure: javax/management/remote/mandatory/connection/IdleTimeoutTest.java In-Reply-To: <52550C22.2080201@oracle.com> References: <5254B136.5070705@oracle.com> <52550C22.2080201@oracle.com> Message-ID: <52569AC3.6020300@oracle.com> Ship it! Thanks, David On 9/10/2013 5:56 PM, shanliang wrote: > David Holmes wrote: >> ! // no deadline here, let's wait till either the >> connId is removed >> ! // or the test timeout (jprt kills the test)! >> ! // see 8025204 >> >> The comment loses context if you don't know what the code previously >> did. I suggest using the simpler form you used in other tests eg: >> >> // pass or timed out by test harness - see XXXX >> >> Note it isn't JPRT that normally kills these but the jtreg harness. >> >> Style nit: >> >> } while(ids >> >> space needed after 'while' >> >> } while (ids > Here is the new version integrated your comments: > > web: http://cr.openjdk.java.net/~sjiang/8025204jdk/01/ > bug: https://bugs.openjdk.java.net/browse/JDK-8025204 > > Thanks, > Shanliang >> >> David >> ----- > From joel.franck at oracle.com Thu Oct 10 01:56:35 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Thu, 10 Oct 2013 08:56:35 +0000 Subject: hg: jdk8/tl/langtools: 8021237: clean up JavacAnnotatedConstruct Message-ID: <20131010085713.4CF4062ED1@hg.openjdk.java.net> Changeset: 1e7ad879f15e Author: alundblad Date: 2013-10-10 08:51 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1e7ad879f15e 8021237: clean up JavacAnnotatedConstruct Summary: Refactored the static helper methods in JavacAnnoConstructs into ordinary methods and put them in a common superclass (AnnoConstruct) of Symbol and Type. Reviewed-by: jjg, vromero, jfranck + src/share/classes/com/sun/tools/javac/code/AnnoConstruct.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Type.java - src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java From fredrik.arvidsson at oracle.com Thu Oct 10 05:28:20 2013 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Thu, 10 Oct 2013 14:28:20 +0200 Subject: RFR (XS) 8024425: VM_HeapDumper doesn't put anonymous classes in the heap dump - Corrected links In-Reply-To: <52568048.5050109@oracle.com> References: <52568048.5050109@oracle.com> Message-ID: <52569D64.6030709@oracle.com> Hi again... Please forgive me for messing up the links in the previous mail. This should be ok I hope. Please help me to review the changes below: Jira case: https://bugs.openjdk.java.net/browse/JDK-8024425 Webrev: http://cr.openjdk.java.net/~allwin/farvidss/8024425/webrev.00/ About this change. I switched from using the SystemDictionary to use ClassLoaderDataGraph instead since the SystemDictionary lack information about the 'anonymous' classes related to this bug. Previously failed Aurora tests have been run using UTE and verified to PASS. The heap dump file have been successfully opened and parsed using jhat and eclipse MAT. Cheers /Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131010/3f92b34e/attachment.html From fredrik.arvidsson at oracle.com Thu Oct 10 05:31:17 2013 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Thu, 10 Oct 2013 14:31:17 +0200 Subject: RFR (S) 8025638: jmap returns 0 instead of 1 when it fails. In-Reply-To: <918A0955-6236-4916-BD54-F344EC9AADEA@oracle.com> References: <5256847D.6060103@oracle.com> <918A0955-6236-4916-BD54-F344EC9AADEA@oracle.com> Message-ID: <52569E15.90204@oracle.com> Ooh, how embarrassing. Thanks Staffan for adding the correct link. /F On 2013-10-10 13:38, Staffan Larsen wrote: > Clicking on the link in this email takes me to the wrong webrev. The > correct URL is in the text: > http://cr.openjdk.java.net/~allwin/farvidss/8025638/webrev.00/ > > > /Staffan > > On 10 okt 2013, at 12:42, Fredrik Arvidsson > > > wrote: > >> Hi >> >> Please help me to review the changes below: >> >> Jira case: https://bugs.openjdk.java.net/browse/JDK-8025638 >> >> Webrev: >> http://cr.openjdk.java.net/~allwin/farvidss/8025638/webrev.00/ >> >> >> About this change. >> A previous change (https://bugs.openjdk.java.net/browse/JDK-8010278) >> in the Tool.java class caused any tool deriving from this base class >> return the wrong value to the caller when failing. >> Changes were made to the Tool.java class and to the derived tool >> implementation classes to handle errors/exceptions during execution >> and ensure that the tool returns 1 to the caller if it fails, and 0 >> if it succeeds. >> >> Previously failed Aurora tests have been run using UTE and verified >> to PASS. >> >> Cheers >> /Fredrik > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131010/aaa06c68/attachment.html From fredrik.arvidsson at oracle.com Thu Oct 10 05:57:15 2013 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Thu, 10 Oct 2013 14:57:15 +0200 Subject: RFR (S) 8025638: jmap returns 0 instead of 1 when it fails. In-Reply-To: <423EB291-3E36-41F7-86F6-6362D0B49839@oracle.com> References: <5256847D.6060103@oracle.com> <918A0955-6236-4916-BD54-F344EC9AADEA@oracle.com> <423EB291-3E36-41F7-86F6-6362D0B49839@oracle.com> Message-ID: <5256A42B.3080700@oracle.com> Thanks for reviewing. Regarding default value of returnstatus. If start() throws an unhandled exception, would not the Java runtime return 1 for us? The try {} clause does not catch anything, it just calls stop() on finally. /F On 2013-10-10 13:49, Staffan Larsen wrote: > Thanks for doing this! > > Tool.java:116 - shouldn't the default return value be 1? In case > start() throws an exception for some reason. > > Tool.java: I find the start(String[] args), start(), startInternal() > methods confusing in naming and usage. Not directly related to your > change of course, just a comment on the code. > > /Staffan > > > On 10 okt 2013, at 13:38, Staffan Larsen > wrote: > >> Clicking on the link in this email takes me to the wrong webrev. The >> correct URL is in the text: >> http://cr.openjdk.java.net/~allwin/farvidss/8025638/webrev.00/ >> >> >> /Staffan >> >> On 10 okt 2013, at 12:42, Fredrik Arvidsson >> > >> wrote: >> >>> Hi >>> >>> Please help me to review the changes below: >>> >>> Jira case: https://bugs.openjdk.java.net/browse/JDK-8025638 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~allwin/farvidss/8025638/webrev.00/ >>> >>> >>> About this change. >>> A previous change (https://bugs.openjdk.java.net/browse/JDK-8010278) >>> in the Tool.java class caused any tool deriving from this base class >>> return the wrong value to the caller when failing. >>> Changes were made to the Tool.java class and to the derived tool >>> implementation classes to handle errors/exceptions during execution >>> and ensure that the tool returns 1 to the caller if it fails, and 0 >>> if it succeeds. >>> >>> Previously failed Aurora tests have been run using UTE and verified >>> to PASS. >>> >>> Cheers >>> /Fredrik >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131010/c9eac8d5/attachment.html From staffan.larsen at oracle.com Thu Oct 10 06:00:32 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 10 Oct 2013 15:00:32 +0200 Subject: RFR (S) 8025638: jmap returns 0 instead of 1 when it fails. In-Reply-To: <5256A42B.3080700@oracle.com> References: <5256847D.6060103@oracle.com> <918A0955-6236-4916-BD54-F344EC9AADEA@oracle.com> <423EB291-3E36-41F7-86F6-6362D0B49839@oracle.com> <5256A42B.3080700@oracle.com> Message-ID: Yes, you are right. Still, a default value of 1 would make the code more obvious. Reviewed. /Staffan On 10 okt 2013, at 14:57, Fredrik Arvidsson wrote: > Thanks for reviewing. > > Regarding default value of returnstatus. If start() throws an unhandled exception, would not the Java runtime return 1 for us? > The try {} clause does not catch anything, it just calls stop() on finally. > > /F > > On 2013-10-10 13:49, Staffan Larsen wrote: >> Thanks for doing this! >> >> Tool.java:116 - shouldn't the default return value be 1? In case start() throws an exception for some reason. >> >> Tool.java: I find the start(String[] args), start(), startInternal() methods confusing in naming and usage. Not directly related to your change of course, just a comment on the code. >> >> /Staffan >> >> >> On 10 okt 2013, at 13:38, Staffan Larsen wrote: >> >>> Clicking on the link in this email takes me to the wrong webrev. The correct URL is in the text: http://cr.openjdk.java.net/~allwin/farvidss/8025638/webrev.00/ >>> >>> /Staffan >>> >>> On 10 okt 2013, at 12:42, Fredrik Arvidsson wrote: >>> >>>> Hi >>>> >>>> Please help me to review the changes below: >>>> >>>> Jira case: https://bugs.openjdk.java.net/browse/JDK-8025638 >>>> Webrev: http://cr.openjdk.java.net/~allwin/farvidss/8025638/webrev.00/ >>>> >>>> About this change. >>>> A previous change (https://bugs.openjdk.java.net/browse/JDK-8010278) in the Tool.java class caused any tool deriving from this base class return the wrong value to the caller when failing. >>>> Changes were made to the Tool.java class and to the derived tool implementation classes to handle errors/exceptions during execution and ensure that the tool returns 1 to the caller if it fails, and 0 if it succeeds. >>>> >>>> Previously failed Aurora tests have been run using UTE and verified to PASS. >>>> >>>> Cheers >>>> /Fredrik >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131010/5de4e6f2/attachment-0001.html From daniel.daugherty at oracle.com Thu Oct 10 06:03:06 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 10 Oct 2013 07:03:06 -0600 Subject: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <52566EC0.4090405@oracle.com> References: <523D144E.4000002@oracle.com> <524B8A78.9040807@oracle.com> <52548E6D.80701@oracle.com> <525545E3.3060504@oracle.com> <52557025.7060706@oracle.com> <52566EC0.4090405@oracle.com> Message-ID: <5256A58A.3030507@oracle.com> Thanks for confirmation. Dan On 10/10/13 3:09 AM, David Holmes wrote: > I'm fine with not adding untestable minimal VM support. > > Thanks, > David > > On 10/10/2013 1:03 AM, Daniel D. Daugherty wrote: >> Replies also inline... >> >> >> On 10/9/13 6:02 AM, David Holmes wrote: >>> inline ... >>> >>> On 9/10/2013 8:59 AM, Daniel D. Daugherty wrote: >>>> On 10/1/13 8:52 PM, David Holmes wrote: >>>>> - hotspot/make/Makefile >>>>> >>>>> + $(EXPORT_CLIENT_DIR)/%.dSYM: $(MINIMAL1_BUILD_DIR)/%.dSYM >>>>> >>>>> EXPORT_CLIENT_DIR should be EXPORT_MINIMAL_DIR. >>>>> >>>>> For fun you can try building minimal on OSX, but I don't know how far >>>>> you will get: >>>>> >>>>> --with-jvm-variants=client,server,minimal1 >>>>> >>>>> I'll point out obvious issues with minimal VM support anyway. >>>> >>>> Since you pointed out in a later email that minimal1 isn't >>>> supported on MacOS X, I'm going to drop those changes. I'm >>>> going to leave the Client VM support since there are folks >>>> out in OpenJDK trying to get the Client VM working on MacOS X. >>>> >>>> It does look like someone added minimal1 support for other >>>> non-Linux platforms, but I'm not planning to clean that up. >>> >>> Yes I did that when adding minimal support. Seemed better than leaving >>> someone to have to rediscover what needed to be implemented if/when >>> minimal support was expanded. >> >> Thanks for the history. Are you still OK if I leave out the >> FDS Minimal1 support? >> >> >>> Someday I hope to remove all the duplicated EXPORT_* stuff and >>> generate it based on the requested JDK_VARIANT_* values. And do it in >>> a platform indpendent way - once! :) >> >> Well it can be mostly platform independent, but there will be >> minor differences in what is exported by the different platforms. >> >> >>> >>>>> Note that the whole jdk6_or_earlier logic is defunct as this will >>>>> never be used for jdk6 or earlier. But best to clean all that up at >>>>> the one time. >>>> >>>> Agreed that we (Oracle) currently don't have plans to drop HSX-25 into >>>> JDK6 or OpenJDK6, but I don't want to rule out future insanity. >>> >>> I do! We need to cut ties with historical baggage. >> >> Good sentiment, but not for this changeset. I'll file a bug to track >> your idea of "best to clean all that up at one time". >> >> >>> >>>>> - make/bsd/makefiles/universal.gmk >>>>> >>>>> I did not understand the additional logic here: >>>>> >>>>> 63 # Copy built non-universal binaries in place >>>>> 64 $(UNIVERSAL_COPY_LIST): >>>>> 65 BUILT_COPY_FILES="`find >>>>> $(EXPORT_JRE_LIB_DIR)/{i386,amd64}/$(subst >>>>> $(EXPORT_JRE_LIB_DIR)/,,$@) >>>>> 2>/dev/null`"; \ >>>>> 66 if [ -n "$${BUILT_COPY_FILES}" ]; then \ >>>>> 67 for i in $${BUILT_COPY_FILES}; do \ >>>>> 68 if [ -f $${i} ]; then \ >>>>> 69 $(MKDIR) -p $(shell dirname $@); \ >>>>> 70 $(CP) -R $${i} $@; \ >>>>> 71 fi; \ >>>>> 72 if [ -d $${i} ]; then \ >>>>> 73 $(MKDIR) -p $@; \ >>>>> 74 fi; \ >>>>> 75 done; \ >>>>> 76 fi >>>>> >>>>> until I realized that foo.dSYM is a directory not a file! Even so >>>>> don't you want to copy the contents of the directory across ? >>>> >>>> BUILT_COPY_FILES includes both files and directories so everything >>>> should get copied across. I've added some commments to the rule >>>> header and reorganized the logic a bit to hopefully be more clear. >>> >>> Doesn't this assume that the directory will appear before the files >>> within it? Is that guaranteed? >> >> The way find works is that it lists the directory prior to listing >> the files within the directory. However, even if find didn't, the >> containing directory would be created via line 69 above. The one >> non-obvious feature of lines 72-74 is that an empty directory named >> in the BUILD_COPY_FILES list would get 'copied' to the destination. >> >> Please check out the latest version when I get it out for review. >> >> >>> Which leads me to ask why we have cp -R for copying files? >> >> MacOS X strongly discourages use of 'cp -r' and recommends 'cp -R' >> instead because 'cp -R' properly copies non-directory and non-file >> file system objects, e.g., symlinks. So if BUILD_COPY_FILES happens >> to contain a symlink, then the symlink is copied to the destination. >> >> >>> >>>>> - jdk/makefiles/Tools.gmk >>>>> >>>>> Not sure about this one. Logically is seems correct but up to now >>>>> this >>>>> has been defined for everything without it seeming to cause a >>>>> problem. >>>>> So why do we need to change it and what impact will it have? >>>> >>>> It just seemed wrong to define something that should never be used >>>> on non-Solaris platforms. My control build of the entire forest >>>> didn't have an issue with this change so I'm planning to keep it. >>> >>> Ok. >>> >>> Thanks, >>> David >> >> Again, thanks for the thorough reviews. >> >> Dan >> >> >>> >>>> Dan >>>> >>>> >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> On 21/09/2013 1:36 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I have the initial support for Full Debug Symbols (FDS) on MacOS X >>>>>> done >>>>>> and ready for review: >>>>>> >>>>>> 7165611 implement Full Debug Symbols on MacOS X hotspot >>>>>> https://bugs.openjdk.java.net/browse/JDK-7165611 >>>>>> >>>>>> Here is the JDK8/HSX-25 webrev URL: >>>>>> >>>>>> OpenJDK: >>>>>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >>>>>> Internal: >>>>>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >>>>>> >>>>>> >>>>>> >>>>>> This webrev includes changes for the follow repos: >>>>>> >>>>>> jdk8 >>>>>> jdk8/hotspot >>>>>> jdk8/jdk >>>>>> jdk8/jdk/make/closed >>>>>> >>>>>> Once these changes are approved, I'm planning to push them to >>>>>> RT_Baseline. From there, they can follow the normal path to >>>>>> Main_Baseline and eventually JDK8. >>>>>> >>>>>> This work enables FDS on MacOS X for the 'hotspot' repo; the >>>>>> changes in >>>>>> the other repos are necessary to support importing the .diz files >>>>>> from >>>>>> the MacOS X 'hotspot' build into the forest build. I also fixed a >>>>>> few >>>>>> FDS related errors in the magic incantations for the new build. >>>>>> This is >>>>>> mostly a port from Linux -> MacOS X/BSD with the dtrace changes >>>>>> ported >>>>>> from Solaris. In other words, this is Frankenstein's monster... >>>>>> >>>>>> Thanks to Staffan Larsen for providing an initial set of changes >>>>>> which I morphed into what you see here. >>>>>> >>>>>> Testing: >>>>>> - JPRT HSX build and test on all platforms; verification of .diz >>>>>> files in the MacOS X JPRT bundles >>>>>> - JPRT JDK8 forest build and test on all platforms; verification of >>>>>> .diz files in the MacOS X JPRT bundles >>>>>> Note: In previous FDS changesets, I also did a standalone 'jdk' >>>>>> repo build and test, but that no longer seems to work. >>>>>> >>>>>> As always, comments, questions and suggestions are welcome. >>>>>> >>>>>> Dan >>>> >> From coleen.phillimore at oracle.com Thu Oct 10 07:28:07 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 10 Oct 2013 10:28:07 -0400 Subject: RFR 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::,compare_entry_to and copy_entry_to In-Reply-To: References: <52544E78.9090103@oracle.com> <5255DB2A.5080209@oracle.com> <52560B3D.1090009@oracle.com> Message-ID: <5256B977.6000602@oracle.com> Thanks John, I didn't realize that I forgot static keyword on the normalize function and I like the suggestion to move it to constantTag even better. Unfortunately, I've already checked it in. I'll make this cleanup with my next (related) bug fix. Thanks, Coleen On 10/10/2013 12:15 AM, John Rose wrote: > Looks good. > > Suggestion: Make normalize_error_tag be static, for namespace cleanliness. Even better, move it into constantTag, as (say) constantTag::non_error_value(). > > ? John > > On Oct 9, 2013, at 7:04 PM, Coleen Phillimore wrote: > >> Thanks Dan! >> Coleen >> >> On 10/9/2013 6:39 PM, Daniel D. Daugherty wrote: >>> On 10/8/13 12:27 PM, Coleen Phillimore wrote: >>>> Summary: Add missing cases. >>>> >>>> I verified this with the test for https://bugs.openjdk.java.net/browse/JDK-8022701 but don't want to copy the test into with modifications the hotspot repository, still working on refactoring the test for the JDK repository for after this gets pushed. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8025185/ >>> src/share/vm/oops/constantPool.cpp >>> No comments. >>> >>> Thumbs up. >>> >>> Dan >>> >>> >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8025185 >>>> >>>> Thanks, >>>> Coleen >>>> >>>> From kevin.walls at oracle.com Thu Oct 10 07:49:00 2013 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 10 Oct 2013 15:49:00 +0100 Subject: RFR (S) 8025638: jmap returns 0 instead of 1 when it fails. In-Reply-To: <423EB291-3E36-41F7-86F6-6362D0B49839@oracle.com> References: <5256847D.6060103@oracle.com> <918A0955-6236-4916-BD54-F344EC9AADEA@oracle.com> <423EB291-3E36-41F7-86F6-6362D0B49839@oracle.com> Message-ID: <5256BE5C.4070406@oracle.com> Hi, Yes the removal of System.exit didn't take the error value into account. 8010278 removed the System.exit so these Tool classes were usable by other tools. I suppose we can use it in main() as if we're there we should be running as a standalone app. The execute method seems like a nice simplification for the Tools. An external app that wants to call one of the Tools can't use it, as it may call System.exit (and you don't want to make execute return an int as then every Tool class has to have more logic in its main() ). nits in Tool.java 115 { should be on the same line as execute definition begins. 120 } finally { on one line I don't think stop() should become private, an existing app that used "public void start()" would expect to call a public stop(). There are a few other files that might want looking at to get them returning an error code: CLHSDB and HSDB (CommandProcessor looks OK, it only had System.exit(0) removed.) That could be a separate bug... Thanks! Kevin On 10/10/13 12:49, Staffan Larsen wrote: > Thanks for doing this! > > Tool.java:116 - shouldn't the default return value be 1? In case > start() throws an exception for some reason. > > Tool.java: I find the start(String[] args), start(), startInternal() > methods confusing in naming and usage. Not directly related to your > change of course, just a comment on the code. > > /Staffan > > > On 10 okt 2013, at 13:38, Staffan Larsen > wrote: > >> Clicking on the link in this email takes me to the wrong webrev. The >> correct URL is in the text: >> http://cr.openjdk.java.net/~allwin/farvidss/8025638/webrev.00/ >> >> >> /Staffan >> >> On 10 okt 2013, at 12:42, Fredrik Arvidsson >> > >> wrote: >> >>> Hi >>> >>> Please help me to review the changes below: >>> >>> Jira case: https://bugs.openjdk.java.net/browse/JDK-8025638 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~allwin/farvidss/8025638/webrev.00/ >>> >>> >>> About this change. >>> A previous change (https://bugs.openjdk.java.net/browse/JDK-8010278) >>> in the Tool.java class caused any tool deriving from this base class >>> return the wrong value to the caller when failing. >>> Changes were made to the Tool.java class and to the derived tool >>> implementation classes to handle errors/exceptions during execution >>> and ensure that the tool returns 1 to the caller if it fails, and 0 >>> if it succeeds. >>> >>> Previously failed Aurora tests have been run using UTE and verified >>> to PASS. >>> >>> Cheers >>> /Fredrik >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131010/6e6a0c65/attachment.html From fredrik.arvidsson at oracle.com Thu Oct 10 07:58:23 2013 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Thu, 10 Oct 2013 16:58:23 +0200 Subject: RFR (XXS) 8026199: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Compilation failed Message-ID: <5256C08F.4000908@oracle.com> Hi Jira: https://bugs.openjdk.java.net/browse/JDK-8026199 Webrev : http://cr.openjdk.java.net/~allwin/farvidss/8026199/webrev.00/ About this fix: This fixes a compilation error in a JTReg test. This issue was a result of some more or less concurrent changes in the same files in the Java testlibrary code. Cheers /Fredrik From staffan.larsen at oracle.com Thu Oct 10 09:01:07 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 10 Oct 2013 09:01:07 -0700 (PDT) Subject: RFR (XXS) 8026199: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Compilation failed Message-ID: <396e6fcf-6dc7-4ee6-ba20-31ce734d345b@default> Looks good to me. Thanks, /Staffan ----- Original Message ----- From: fredrik.arvidsson at oracle.com To: serviceability-dev at openjdk.java.net Sent: Thursday, October 10, 2013 4:58:58 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: RFR (XXS) 8026199: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Compilation failed Hi Jira: https://bugs.openjdk.java.net/browse/JDK-8026199 Webrev : http://cr.openjdk.java.net/~allwin/farvidss/8026199/webrev.00/ About this fix: This fixes a compilation error in a JTReg test. This issue was a result of some more or less concurrent changes in the same files in the Java testlibrary code. Cheers /Fredrik From jaroslav.bachorik at oracle.com Thu Oct 10 09:05:05 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 10 Oct 2013 18:05:05 +0200 Subject: RFR (XXS) 8026199: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Compilation failed In-Reply-To: <5256C08F.4000908@oracle.com> References: <5256C08F.4000908@oracle.com> Message-ID: <5256D031.8020701@oracle.com> Looks good. -JB- On 10.10.2013 16:58, Fredrik Arvidsson wrote: > Hi > > Jira: https://bugs.openjdk.java.net/browse/JDK-8026199 > Webrev : http://cr.openjdk.java.net/~allwin/farvidss/8026199/webrev.00/ > > > About this fix: > This fixes a compilation error in a JTReg test. This issue was a result > of some more or less concurrent changes in the same files in the Java > testlibrary code. > > Cheers > /Fredrik > > From shanliang.jiang at oracle.com Thu Oct 10 08:48:09 2013 From: shanliang.jiang at oracle.com (shanliang.jiang at oracle.com) Date: Thu, 10 Oct 2013 15:48:09 +0000 Subject: hg: jdk8/tl/jdk: 8025204: Intermittent test failure: javax/management/remote/mandatory/connection/IdleTimeoutTest.java Message-ID: <20131010154859.B08D062F01@hg.openjdk.java.net> Changeset: cab80088c671 Author: sjiang Date: 2013-10-10 17:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cab80088c671 8025204: Intermittent test failure: javax/management/remote/mandatory/connection/IdleTimeoutTest.java Reviewed-by: dholmes, jbachorik ! test/javax/management/remote/mandatory/connection/IdleTimeoutTest.java From joel.franck at oracle.com Thu Oct 10 09:19:01 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Thu, 10 Oct 2013 16:19:01 +0000 Subject: hg: jdk8/tl/jdk: 7044282: (reflect) Class.forName and Array.newInstance are inconsistent regarding multidimensional arrays Message-ID: <20131010161931.9663E62F04@hg.openjdk.java.net> Changeset: f25d9d8811ca Author: jfranck Date: 2013-10-10 18:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f25d9d8811ca 7044282: (reflect) Class.forName and Array.newInstance are inconsistent regarding multidimensional arrays Reviewed-by: darcy, psandoz ! src/share/classes/java/lang/reflect/Array.java + test/java/lang/Class/forName/arrayClass/Class1.java + test/java/lang/Class/forName/arrayClass/Class2.java + test/java/lang/Class/forName/arrayClass/Class3.java + test/java/lang/Class/forName/arrayClass/Class4.java + test/java/lang/Class/forName/arrayClass/ExceedMaxDim.java ! test/java/lang/reflect/Array/ExceedMaxDim.java From bhavesh.x.patel at oracle.com Thu Oct 10 10:52:29 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Thu, 10 Oct 2013 17:52:29 +0000 Subject: hg: jdk8/tl/langtools: 8025633: Fix javadoc to generate valid anchor names Message-ID: <20131010175322.BB19962F20@hg.openjdk.java.net> Changeset: 933ba3f81a87 Author: bpatel Date: 2013-10-10 10:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/933ba3f81a87 8025633: Fix javadoc to generate valid anchor names Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeFieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java + src/share/classes/com/sun/tools/doclets/formats/html/SectionName.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletConstants.java ! test/com/sun/javadoc/AccessSkipNav/AccessSkipNav.java + test/com/sun/javadoc/testAnchorNames/TestAnchorNames.java + test/com/sun/javadoc/testAnchorNames/pkg1/DeprMemClass.java + test/com/sun/javadoc/testAnchorNames/pkg1/RegClass.java ! test/com/sun/javadoc/testAnnotationOptional/TestAnnotationOptional.java ! test/com/sun/javadoc/testAnnotationTypes/TestAnnotationTypes.java ! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java ! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/com/sun/javadoc/testHref/TestHref.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java ! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java ! test/com/sun/javadoc/testNavigation/TestNavigation.java ! test/com/sun/javadoc/testNestedGenerics/TestNestedGenerics.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenMethodDocCopy.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/com/sun/javadoc/testTaglets/TestTaglets.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/com/sun/javadoc/testTypeParams/TestTypeParameters.java ! test/com/sun/javadoc/testWarnings/TestWarnings.java From eric.mccorkle at oracle.com Thu Oct 10 10:56:29 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Thu, 10 Oct 2013 17:56:29 +0000 Subject: hg: jdk8/tl/langtools: 8019461: Clean up javac diagnostics; ... Message-ID: <20131010175642.9149F62F23@hg.openjdk.java.net> Changeset: 6dcf94e32a3a Author: emc Date: 2013-10-10 13:55 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6dcf94e32a3a 8019461: Clean up javac diagnostics 7196553: Review error messages for repeating annotations Summary: Changes to the diagnostic messages to improve clarity and JLS coherence Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties - test/tools/javac/diags/examples/DuplicateAnnotation.java + test/tools/javac/diags/examples/InterfaceOrArrayExpected.java + test/tools/javac/diags/examples/RepeatableAnnotationsNotSupported.java From john.coomes at oracle.com Thu Oct 10 11:19:19 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 18:19:19 +0000 Subject: hg: hsx/hotspot-rt: 5 new changesets Message-ID: <20131010181920.3020462F32@hg.openjdk.java.net> Changeset: feb4f2d97042 Author: ihse Date: 2013-10-03 11:26 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/feb4f2d97042 8008944: Correct typos Reviewed-by: tbell, erikj ! NewMakefile.gmk ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/makefiles/JavaCompilation.gmk Changeset: d23177734b28 Author: thurka Date: 2013-10-07 13:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/d23177734b28 8025920: webrev.ksh does not provide any details about changes in zip files Summary: Add support for diffs for zip files Reviewed-by: ksrini, chegar ! make/scripts/webrev.ksh Changeset: 9b102ab97693 Author: erikj Date: 2013-10-07 18:19 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/9b102ab97693 8005924: Make it possible to set both --with-user-release-suffix and --with-build-number Reviewed-by: ihse, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in Changeset: d086227bfc45 Author: katleman Date: 2013-10-08 13:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/d086227bfc45 Merge Changeset: 82a36c5c4eaf Author: cl Date: 2013-10-10 10:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/82a36c5c4eaf Added tag jdk8-b111 for changeset d086227bfc45 ! .hgtags From john.coomes at oracle.com Thu Oct 10 11:19:50 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 18:19:50 +0000 Subject: hg: hsx/hotspot-rt/corba: Added tag jdk8-b111 for changeset 85c1c94e7235 Message-ID: <20131010181954.B290262F33@hg.openjdk.java.net> Changeset: d7e478820c56 Author: cl Date: 2013-10-10 10:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/corba/rev/d7e478820c56 Added tag jdk8-b111 for changeset 85c1c94e7235 ! .hgtags From john.coomes at oracle.com Thu Oct 10 11:20:24 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 18:20:24 +0000 Subject: hg: hsx/hotspot-rt/jaxp: Added tag jdk8-b111 for changeset 17ee0d3e97fd Message-ID: <20131010182039.1A7B162F34@hg.openjdk.java.net> Changeset: a4622ff1462b Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxp/rev/a4622ff1462b Added tag jdk8-b111 for changeset 17ee0d3e97fd ! .hgtags From john.coomes at oracle.com Thu Oct 10 11:21:12 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 18:21:12 +0000 Subject: hg: hsx/hotspot-rt/jaxws: Added tag jdk8-b111 for changeset 32edc7a2c866 Message-ID: <20131010182121.26F4C62F36@hg.openjdk.java.net> Changeset: fc94ce4b899e Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jaxws/rev/fc94ce4b899e Added tag jdk8-b111 for changeset 32edc7a2c866 ! .hgtags From john.coomes at oracle.com Thu Oct 10 11:21:55 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 18:21:55 +0000 Subject: hg: hsx/hotspot-rt/jdk: 4 new changesets Message-ID: <20131010182420.4BFBC62F37@hg.openjdk.java.net> Changeset: 88597d465e48 Author: ihse Date: 2013-10-01 15:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/88597d465e48 8016024: Remove solaris path from FillCacheFind Reviewed-by: erikj ! makefiles/Tools.gmk Changeset: 760af86b3f3f Author: erikj Date: 2013-10-03 11:27 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/760af86b3f3f 8024522: java.time packages missing from src.zip Reviewed-by: tbell ! makefiles/CreateJars.gmk Changeset: 719befd87c7b Author: katleman Date: 2013-10-08 13:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/719befd87c7b Merge Changeset: 7af04d2d2139 Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/7af04d2d2139 Added tag jdk8-b111 for changeset 719befd87c7b ! .hgtags From john.coomes at oracle.com Thu Oct 10 11:25:59 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 18:25:59 +0000 Subject: hg: hsx/hotspot-rt/langtools: Added tag jdk8-b111 for changeset af6244ba81b6 Message-ID: <20131010182631.AEB6362F38@hg.openjdk.java.net> Changeset: a0e8fd2464d6 Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/langtools/rev/a0e8fd2464d6 Added tag jdk8-b111 for changeset af6244ba81b6 ! .hgtags From john.coomes at oracle.com Thu Oct 10 11:27:32 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 18:27:32 +0000 Subject: hg: hsx/hotspot-rt/nashorn: Added tag jdk8-b111 for changeset 75fd3486e584 Message-ID: <20131010182736.DA39862F39@hg.openjdk.java.net> Changeset: fc2b6885e60e Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/nashorn/rev/fc2b6885e60e Added tag jdk8-b111 for changeset 75fd3486e584 ! .hgtags From dmitry.samersoff at oracle.com Thu Oct 10 11:33:34 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 10 Oct 2013 22:33:34 +0400 Subject: RR(S): JDK-8004213 jdp packet need pid, broadcast interval and rmi server hostname fields. Message-ID: <5256F2FE.4090202@oracle.com> Hi Everyone, This fix covers JDK JDK-8004213 JDP packets should contain PID JDK-8004215 JDP packets should contain the configured broadcast interval JDK-8007071 JDP does not work well with java.rmi.server.hostname overrides. and add three extra fields to JDP packet: PID, rmi server name, broadcast interval. PID gathering code mostly borrowed from hotspot testlibrary. http://cr.openjdk.java.net/~dsamersoff/JDK-8004213/webrev.01/ -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From eric.mccorkle at oracle.com Thu Oct 10 15:56:46 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Thu, 10 Oct 2013 22:56:46 +0000 Subject: hg: jdk8/tl/jdk: 8026011: java.lang.reflect.MalformedParametersException introduces doclint warnings Message-ID: <20131010225701.3187A62F46@hg.openjdk.java.net> Changeset: 4abfcbac1cb6 Author: emc Date: 2013-10-10 18:56 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4abfcbac1cb6 8026011: java.lang.reflect.MalformedParametersException introduces doclint warnings Summary: Add javadoc comments to members of MalformedParametersException Reviewed-by: darcy ! src/share/classes/java/lang/reflect/MalformedParametersException.java From eric.mccorkle at oracle.com Thu Oct 10 17:12:41 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Fri, 11 Oct 2013 00:12:41 +0000 Subject: hg: jdk8/tl/langtools: 8008762: Type annotation on inner class in anonymous class show up as regular type annotations; ... Message-ID: <20131011001244.DCEAB62F49@hg.openjdk.java.net> Changeset: b1b4a6dcc282 Author: emc Date: 2013-10-10 20:12 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b1b4a6dcc282 8008762: Type annotation on inner class in anonymous class show up as regular type annotations 8015257: type annotation with TYPE_USE and FIELD attributed differently if repeated. 8013409: test failures for type annotations Summary: Fixes to address some problems in type annotations Reviewed-by: jfranck, jjg ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/annotations/typeAnnotations/classfile/TestAnonInnerClasses.java + test/tools/javac/annotations/typeAnnotations/classfile/testanoninner.template ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.out ! test/tools/javac/annotations/typeAnnotations/newlocations/MultiCatch.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java From jonathan.gibbons at oracle.com Thu Oct 10 17:14:53 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 11 Oct 2013 00:14:53 +0000 Subject: hg: jdk8/tl/langtools: 8026294: 8025633 breaks langtools/test/com/sun/javadoc/testRepeatedAnnotations/TestRepeatedAnnotations.java Message-ID: <20131011001456.7B35062F4A@hg.openjdk.java.net> Changeset: f068d235c4f7 Author: jjg Date: 2013-10-10 17:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f068d235c4f7 8026294: 8025633 breaks langtools/test/com/sun/javadoc/testRepeatedAnnotations/TestRepeatedAnnotations.java Reviewed-by: darcy ! test/com/sun/javadoc/testRepeatedAnnotations/TestRepeatedAnnotations.java From huizhe.wang at oracle.com Thu Oct 10 17:01:50 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Fri, 11 Oct 2013 00:01:50 +0000 Subject: hg: jdk8/tl/jaxp: 8003262: reverse translation required changes in xalan resource bundles Message-ID: <20131011000152.91BCF62F47@hg.openjdk.java.net> Changeset: b76629725522 Author: joehw Date: 2013-10-10 17:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b76629725522 8003262: reverse translation required changes in xalan resource bundles Reviewed-by: lancea, dfuchs ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_fr.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_it.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_pt_BR.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_TW.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ca.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_cs.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_es.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_fr.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_it.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ko.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_pt_BR.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sk.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sv.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_TW.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ca.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_cs.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_de.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_es.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_fr.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_it.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ja.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ko.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_pt_BR.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sk.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sv.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_CN.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_TW.java From lana.steuck at oracle.com Thu Oct 10 21:33:10 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 Oct 2013 04:33:10 +0000 Subject: hg: jdk8/tl/jaxp: 5 new changesets Message-ID: <20131011043340.3400362F56@hg.openjdk.java.net> Changeset: 17ee0d3e97fd Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/17ee0d3e97fd Added tag jdk8-b110 for changeset 4c84c5b447b0 ! .hgtags Changeset: 2107c9baa457 Author: lana Date: 2013-10-10 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2107c9baa457 Merge Changeset: cff4e3bf530a Author: lana Date: 2013-10-10 20:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/cff4e3bf530a Merge Changeset: a4622ff1462b Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a4622ff1462b Added tag jdk8-b111 for changeset 17ee0d3e97fd ! .hgtags Changeset: 46ccc5fbc523 Author: lana Date: 2013-10-10 21:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/46ccc5fbc523 Merge From lana.steuck at oracle.com Thu Oct 10 21:33:03 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 Oct 2013 04:33:03 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20131011043309.5879962F53@hg.openjdk.java.net> Changeset: 85c1c94e7235 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/85c1c94e7235 Added tag jdk8-b110 for changeset 3d2b7ce93c5c ! .hgtags Changeset: d7e478820c56 Author: cl Date: 2013-10-10 10:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/d7e478820c56 Added tag jdk8-b111 for changeset 85c1c94e7235 ! .hgtags From lana.steuck at oracle.com Thu Oct 10 21:33:12 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 Oct 2013 04:33:12 +0000 Subject: hg: jdk8/tl/nashorn: 4 new changesets Message-ID: <20131011043325.F1F5C62F54@hg.openjdk.java.net> Changeset: d49a8c2173f5 Author: lana Date: 2013-09-26 17:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d49a8c2173f5 Merge Changeset: 75fd3486e584 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/75fd3486e584 Added tag jdk8-b110 for changeset d49a8c2173f5 ! .hgtags Changeset: fc2b6885e60e Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fc2b6885e60e Added tag jdk8-b111 for changeset 75fd3486e584 ! .hgtags Changeset: f6263ae511c2 Author: lana Date: 2013-10-10 13:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f6263ae511c2 Merge From lana.steuck at oracle.com Thu Oct 10 21:33:00 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 Oct 2013 04:33:00 +0000 Subject: hg: jdk8/tl: 12 new changesets Message-ID: <20131011043303.7C9E462F52@hg.openjdk.java.net> Changeset: 5ec3c4948863 Author: ksrini Date: 2013-09-27 16:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/5ec3c4948863 8023495: [infra] create 64-bit solaris bits with symlinks Reviewed-by: ihse, tbell, erikj ! common/makefiles/Jprt.gmk ! common/makefiles/Main.gmk Changeset: 72c2495c86c9 Author: katleman Date: 2013-10-01 12:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/72c2495c86c9 Merge Changeset: 0f704e36bc5d Author: ihse Date: 2013-10-01 10:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0f704e36bc5d 8006661: Use LC_ALL=C instead of LANG=C compare.sh Reviewed-by: tbell ! common/bin/compare.sh Changeset: 4faa09c7fe55 Author: erikj Date: 2013-10-02 15:08 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4faa09c7fe55 Merge Changeset: 669e3e3d4459 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/669e3e3d4459 Added tag jdk8-b110 for changeset 4faa09c7fe55 ! .hgtags Changeset: feb4f2d97042 Author: ihse Date: 2013-10-03 11:26 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/feb4f2d97042 8008944: Correct typos Reviewed-by: tbell, erikj ! NewMakefile.gmk ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/makefiles/JavaCompilation.gmk Changeset: d23177734b28 Author: thurka Date: 2013-10-07 13:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d23177734b28 8025920: webrev.ksh does not provide any details about changes in zip files Summary: Add support for diffs for zip files Reviewed-by: ksrini, chegar ! make/scripts/webrev.ksh Changeset: 9b102ab97693 Author: erikj Date: 2013-10-07 18:19 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/9b102ab97693 8005924: Make it possible to set both --with-user-release-suffix and --with-build-number Reviewed-by: ihse, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in Changeset: d086227bfc45 Author: katleman Date: 2013-10-08 13:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d086227bfc45 Merge Changeset: 4d23143c676a Author: lana Date: 2013-10-10 08:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4d23143c676a Merge Changeset: 82a36c5c4eaf Author: cl Date: 2013-10-10 10:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/82a36c5c4eaf Added tag jdk8-b111 for changeset d086227bfc45 ! .hgtags Changeset: fd3b32cc4b6e Author: lana Date: 2013-10-10 21:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/fd3b32cc4b6e Merge From lana.steuck at oracle.com Thu Oct 10 21:33:07 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 Oct 2013 04:33:07 +0000 Subject: hg: jdk8/tl/jaxws: 4 new changesets Message-ID: <20131011043336.B9FD962F55@hg.openjdk.java.net> Changeset: 32edc7a2c866 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/32edc7a2c866 Added tag jdk8-b110 for changeset cc682329886b ! .hgtags Changeset: da77e343f458 Author: lana Date: 2013-10-10 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/da77e343f458 Merge Changeset: fc94ce4b899e Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/fc94ce4b899e Added tag jdk8-b111 for changeset 32edc7a2c866 ! .hgtags Changeset: 66a12ce67d3a Author: lana Date: 2013-10-10 21:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/66a12ce67d3a Merge From lana.steuck at oracle.com Thu Oct 10 21:33:32 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 Oct 2013 04:33:32 +0000 Subject: hg: jdk8/tl/langtools: 5 new changesets Message-ID: <20131011043353.0A54662F57@hg.openjdk.java.net> Changeset: 41541097533a Author: lana Date: 2013-09-26 17:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/41541097533a Merge Changeset: af6244ba81b6 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/af6244ba81b6 Added tag jdk8-b110 for changeset 41541097533a ! .hgtags Changeset: a0e8fd2464d6 Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a0e8fd2464d6 Added tag jdk8-b111 for changeset af6244ba81b6 ! .hgtags Changeset: 8f293c710369 Author: lana Date: 2013-10-10 13:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8f293c710369 Merge Changeset: bf33f4f81b40 Author: lana Date: 2013-10-10 20:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bf33f4f81b40 Merge - test/tools/javac/diags/examples/DuplicateAnnotation.java From lana.steuck at oracle.com Thu Oct 10 21:34:22 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 Oct 2013 04:34:22 +0000 Subject: hg: jdk8/tl/hotspot: 82 new changesets Message-ID: <20131011043729.093EC62F58@hg.openjdk.java.net> Changeset: 8a6a85321d3a Author: amurillo Date: 2013-09-20 11:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8a6a85321d3a 8025127: new hotspot build - hs25-b52 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 63147986a428 Author: dcubed Date: 2013-09-18 07:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/63147986a428 8019835: Strings interned in different threads equal but does not == Summary: Add -XX:+VerifyStringTableAtExit option and code to verify StringTable invariants. Reviewed-by: rdurbin, sspitsyn, coleenp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp Changeset: dfae98867ee8 Author: dholmes Date: 2013-09-18 20:08 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dfae98867ee8 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps Reviewed-by: alanb, chegar, dholmes, ksrini Contributed-by: Mike Duigou ! src/share/vm/runtime/arguments.cpp Changeset: c1d7040a1183 Author: sgabdura Date: 2013-09-18 16:48 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c1d7040a1183 8022836: JVM crashes in JVMTIENVBASE::GET_CURRENT_CONTENDED_MONITOR and GET_OWNED_MONITOR Summary: Check that the _java_thread parameter is valid when it is possible that the JavaThread has exited after the initial checks were made in generated/jvmtifiles/jvmtiEnter.cpp: jvmti_GetCurrentContendedMonitor() Reviewed-by: dcubed, dsamersoff ! src/share/vm/prims/jvmtiEnvBase.hpp Changeset: 8c84f04ff977 Author: kevinw Date: 2013-09-18 19:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8c84f04ff977 Merge Changeset: 6eb908998b32 Author: kevinw Date: 2013-09-19 08:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6eb908998b32 Merge Changeset: 9ed97b511b26 Author: hseigel Date: 2013-09-19 11:04 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9ed97b511b26 8024517: runtime/CDSCompressedKPtrs/XShareAuto.java failed with RuntimeException Summary: Make sure CDS is off by default when running server compiler. Reviewed-by: dholmes, coleenp ! src/share/vm/runtime/arguments.cpp ! test/runtime/CDSCompressedKPtrs/XShareAuto.java Changeset: 4f9a42c33738 Author: coleenp Date: 2013-09-20 09:30 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4f9a42c33738 8022887: Assertion hit while using class and redefining it with RedefineClasses simultaneously Summary: Need to refetch each method from InstanceKlass after all safepoints. Removed leaky PreviousVersionInfo code. Reviewed-by: dcubed, sspitsyn ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/handles.inline.hpp Changeset: f201713502e0 Author: coleenp Date: 2013-09-20 09:44 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f201713502e0 Merge Changeset: 1b03bed31241 Author: allwin Date: 2013-09-17 17:16 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1b03bed31241 7196151: ParserTest SEGv on solaris Reviewed-by: sla, coleenp, ctornqvi, dsamersoff ! src/share/vm/services/diagnosticArgument.cpp Changeset: e5a25e4ae509 Author: mgerdin Date: 2013-09-20 10:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e5a25e4ae509 Merge Changeset: 7c29904fdfa2 Author: coleenp Date: 2013-09-20 18:34 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7c29904fdfa2 8014956: nashorn/api/javaaccess/MethodAccessTest.java test fails on sparc-solaris 64 Summary: reference_map[] array had uninitialized junk that was causing a bogus bootstrap method to be found. Reviewed-by: hseigel, dcubed, sspitsyn ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp Changeset: df03413ad1a9 Author: coleenp Date: 2013-09-21 01:45 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/df03413ad1a9 Merge Changeset: 0f37d1badced Author: dcubed Date: 2013-09-20 12:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0f37d1badced Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: a7609ec351d6 Author: dcubed Date: 2013-09-20 18:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a7609ec351d6 Merge ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java Changeset: 8ddc26f62476 Author: sla Date: 2013-09-22 06:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8ddc26f62476 6989981: jstack causes "fatal error: ExceptionMark destructor expects no pending exceptions" Reviewed-by: sla, dsamersoff Contributed-by: Yasumasa Suenaga ! src/share/vm/services/attachListener.cpp Changeset: 1f42d3ec1759 Author: dsamersoff Date: 2013-09-22 18:49 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1f42d3ec1759 7133122: SA throws sun.jvm.hotspot.debugger.UnmappedAddressException when it should not Summary: replace PT_LOAD segment with library segment when necessary Reviewed-by: dholmes, sla ! agent/src/os/linux/ps_core.c Changeset: ae2edb3df7fb Author: dsamersoff Date: 2013-09-22 18:07 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ae2edb3df7fb Merge Changeset: 084b21cd0228 Author: iklam Date: 2013-09-23 08:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/084b21cd0228 8025088: Missing cases for JVM_CONSTANT_MethodHandleInError cause crash if debugger steps into error-tagged method handle Summary: Need to refetch each method from InstanceKlass after all safepoints. Removed leaky PreviousVersionInfo code. Reviewed-by: coleenp, sspitsyn ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp Changeset: e8a0010ba69e Author: zgu Date: 2013-09-25 13:03 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e8a0010ba69e Merge Changeset: 891687731b59 Author: anoll Date: 2013-09-24 15:56 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/891687731b59 7009641: Don't fail VM when CodeCache is full Summary: Allocation in the code cache returns NULL instead of failing the entire VM Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 1b64d46620a3 Author: kvn Date: 2013-09-24 16:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1b64d46620a3 8022585: VM crashes when ran with -XX:+PrintInlining Summary: use adr_at() to access inline info structures in growableArray. Add ability to specify print inlining per method. Reviewed-by: twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/library_call.cpp + test/compiler/print/PrintInlining.java Changeset: f637d4dc21bb Author: adlertz Date: 2013-09-26 08:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f637d4dc21bb Merge Changeset: 586fa1919a89 Author: bpittore Date: 2013-09-20 15:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/586fa1919a89 8014911: Should use SUPPORTS_NATIVE_CX8 define to help C/C++ compiler elide blocks of code Summary: If SUPPORTS_NATIVE_CX8 true then supports_cx8() function hard coded to return 'true' Reviewed-by: kvn, twisti, dholmes ! src/share/vm/runtime/vm_version.hpp Changeset: 504d8f519adf Author: jiangli Date: 2013-09-20 20:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/504d8f519adf Merge Changeset: d682c6e24fe3 Author: bdelsart Date: 2013-09-26 01:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d682c6e24fe3 Merge Changeset: 60a2d625db36 Author: bdelsart Date: 2013-09-26 04:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/60a2d625db36 Merge Changeset: 2c022e432e10 Author: stefank Date: 2013-09-20 10:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c022e432e10 8024974: Incorrect use of GC_locker::is_active() Summary: SymbolTable and StringTable can make calls to GC_locker::is_active() outside a safepoint. This isn't safe because the GC_locker active state (lock count) is only updated at a safepoint and only remains valid as long as _needs_gc is true. However, outside a safepoint_needs_gc can change to false at any time, which makes it impossible to do a correct call to is_active() in that context. In this case these calls can just be removed since the input argument to basic_add() should never be on the heap and so there's no need to check the GC_locker state. This change also adjusts the assert() in is_active() to makes sure all calls to this function are always done under a safepoint. Reviewed-by: brutisso, dcubed Contributed-by: per.liden at oracle.com ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp Changeset: 9361de86a50f Author: stefank Date: 2013-09-20 11:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9361de86a50f 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize Reviewed-by: coleenp, brutisso, mgerdin, jmasa ! src/share/vm/memory/metaspace.cpp Changeset: b960c9df4f11 Author: stefank Date: 2013-09-21 10:09 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b960c9df4f11 8025096: Move the ChunkManager instances out of the VirtualSpaceLists Reviewed-by: coleenp, mgerdin, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 10cc3b624f8f Author: tschatzl Date: 2013-09-24 10:14 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/10cc3b624f8f Merge - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar Changeset: a19bea467577 Author: tschatzl Date: 2013-09-25 13:25 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a19bea467577 7163191: G1: introduce a "heap spanning table" abstraction Summary: Add G1BiasedArray that is an array where each element represents a fixed-sized subdivision of the heap. Use this abstraction to refactor the HeapRegionSeq class. Reviewed-by: brutisso ! make/excludeSrc.make + src/share/vm/gc_implementation/g1/g1BiasedArray.cpp + src/share/vm/gc_implementation/g1/g1BiasedArray.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/prims/jni.cpp Changeset: 03f493ce3a71 Author: brutisso Date: 2013-09-25 17:23 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/03f493ce3a71 8025228: assert(new_entry->reserved_words() == vs_word_size) fails in nightly Reviewed-by: mgerdin, tschatzl, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/prims/jni.cpp Changeset: 461159cd7a91 Author: tschatzl Date: 2013-09-26 12:18 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/461159cd7a91 Merge ! src/share/vm/classfile/symbolTable.cpp Changeset: 3da9fad1391e Author: tschatzl Date: 2013-09-26 06:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3da9fad1391e Merge Changeset: 58043478c26d Author: amurillo Date: 2013-09-26 13:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/58043478c26d Merge Changeset: 6209b0ed51c0 Author: amurillo Date: 2013-09-26 13:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6209b0ed51c0 Added tag hs25-b52 for changeset 58043478c26d ! .hgtags Changeset: ebfa5793d349 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ebfa5793d349 Added tag jdk8-b110 for changeset 6209b0ed51c0 ! .hgtags Changeset: 24250c363d7f Author: amurillo Date: 2013-09-26 13:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/24250c363d7f 8025536: new hotspot build - hs25-b53 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 899ecf76b570 Author: dsimms Date: 2013-09-25 13:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/899ecf76b570 8023956: Provide a work-around to broken Linux 32 bit "Exec Shield" using CS for NX emulation (crashing with SI_KERNEL) Summary: Execute some code at a high virtual address value, and keep mapped Reviewed-by: coleenp, zgu ! src/os/linux/vm/os_linux.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp Changeset: 5b1191bf0b4b Author: ctornqvi Date: 2013-09-25 17:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5b1191bf0b4b 8024677: [TESTBUG] Move tests for classes in /testlibrary Summary: Moved the tests to /testlibrary_tests and updated TEST.groups Reviewed-by: dholmes, sla ! test/TEST.groups - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java + test/testlibrary_tests/AssertsTest.java + test/testlibrary_tests/OutputAnalyzerReportingTest.java + test/testlibrary_tests/OutputAnalyzerTest.java Changeset: c1fbf21c7397 Author: ctornqvi Date: 2013-09-25 17:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c1fbf21c7397 8024492: [TESTBUG] Test library class Platform.java needs to include methods for missing OS's and architectures Summary: Added methods for 32bit, arm, ppc, x64 and x86 Reviewed-by: zgu, hseigel, mseledtsov ! test/testlibrary/com/oracle/java/testlibrary/Platform.java Changeset: 190899198332 Author: hseigel Date: 2013-09-26 10:25 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/190899198332 7195622: CheckUnhandledOops has limited usefulness now Summary: Enable CHECK_UNHANDLED_OOPS in fastdebug builds across all supported platforms. Reviewed-by: coleenp, hseigel, dholmes, stefank, twisti, ihse, rdurbin Contributed-by: lois.foltan at oracle.com ! make/bsd/makefiles/fastdebug.make ! make/linux/makefiles/fastdebug.make ! make/windows/makefiles/fastdebug.make ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parOopClosures.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: a5ac0873476c Author: zgu Date: 2013-09-27 10:08 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a5ac0873476c Merge ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 36b97be47bde Author: acorn Date: 2013-10-01 08:10 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/36b97be47bde 8011311: Private interface methods. Default conflicts:ICCE. no erased_super_default. Reviewed-by: coleenp, bharadwaj, minqi ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/defaultMethods.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klassVtable.cpp Changeset: de059a14e159 Author: zgu Date: 2013-10-01 08:54 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de059a14e159 8022187: Missing ResourceMark crash when assertion using FormatBufferResource fails Summary: Uses stack for the format buffer instead of resource memory Reviewed-by: kvn, coleenp ! src/share/vm/utilities/array.hpp Changeset: 90b27e931639 Author: zgu Date: 2013-10-01 09:21 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/90b27e931639 Merge Changeset: 31f0118ea584 Author: zgu Date: 2013-10-01 11:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/31f0118ea584 Merge Changeset: 72b7e96c1922 Author: twisti Date: 2013-09-26 12:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/72b7e96c1922 8024545: make develop and notproduct flag values available in product builds Reviewed-by: dholmes, kvn ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/dtraceAttacher.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/memoryService.cpp Changeset: c9ccd7b85f20 Author: rbackman Date: 2013-09-27 08:39 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c9ccd7b85f20 8024924: Intrinsify java.lang.Math.addExact Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/classes.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp + src/share/vm/opto/mathexactnode.cpp + src/share/vm/opto/mathexactnode.hpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/subnode.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/intrinsics/mathexact/CondTest.java + test/compiler/intrinsics/mathexact/ConstantTest.java + test/compiler/intrinsics/mathexact/LoadTest.java + test/compiler/intrinsics/mathexact/LoopDependentTest.java + test/compiler/intrinsics/mathexact/NonConstantTest.java + test/compiler/intrinsics/mathexact/Verify.java Changeset: 510fbd28919c Author: anoll Date: 2013-09-27 10:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/510fbd28919c 8020151: PSR:PERF Large performance regressions when code cache is filled Summary: Code cache sweeping based on method hotness; removed speculatively disconnect Reviewed-by: kvn, iveresov ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/trace/trace.xml Changeset: a07c25e4f67e Author: adlertz Date: 2013-09-27 12:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a07c25e4f67e Merge ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/services/attachListener.cpp Changeset: 1c3486050433 Author: adlertz Date: 2013-09-27 15:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1c3486050433 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: e8e077292da3 Author: iignatyev Date: 2013-09-28 12:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e8e077292da3 8024678: Java source files in hotspot/test/testlibrary should not use @author tag in JavaDoc Reviewed-by: twisti ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathDirEntry.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathJarEntry.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassPathJarInDirEntry.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/ClassesListInFile.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/CompileTheWorld.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Compiler.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/PathHandler.java ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Utils.java Changeset: 303826f477c6 Author: iignatyev Date: 2013-09-28 12:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/303826f477c6 8023452: TestCase$Helper(java.lang.Object) must be osr_compiled Reviewed-by: kvn ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java Changeset: f2512d89ad0c Author: twisti Date: 2013-09-28 12:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f2512d89ad0c 8025613: clang: remove -Wno-unused-value Reviewed-by: iveresov ! agent/src/os/linux/LinuxDebuggerLocal.c ! agent/src/os/linux/ps_proc.c ! agent/src/os/linux/salibelf.c ! agent/src/os/linux/symtab.c ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/classfile/defaultMethods.cpp Changeset: 29bdcf12457c Author: shade Date: 2013-09-27 11:52 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/29bdcf12457c 8014447: Object.hashCode intrinsic breaks inline caches Summary: Try to inline as normal method first, then fall back to intrinsic. Reviewed-by: kvn, twisti ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/library_call.cpp Changeset: d8d059e90ec1 Author: twisti Date: 2013-09-30 15:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d8d059e90ec1 8025599: Missing store barrier with OptimizeStringConcat Reviewed-by: kvn, twisti Contributed-by: Axel Siebenborn ! src/share/vm/opto/graphKit.cpp Changeset: dc261f466b6d Author: drchase Date: 2013-09-27 13:36 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dc261f466b6d 8025260: Methodhandles/JSR292: NullPointerException (NPE) thrown instead of AbstractMethodError (AME) Summary: Copied null-checks from templateInterpreter_CPU into methodHandles_CPU Reviewed-by: jrose, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp + test/compiler/jsr292/methodHandleExceptions/ByteClassLoader.java + test/compiler/jsr292/methodHandleExceptions/C.java + test/compiler/jsr292/methodHandleExceptions/I.java + test/compiler/jsr292/methodHandleExceptions/TestAMEnotNPE.java Changeset: cacc4c6bfc80 Author: vlivanov Date: 2013-10-02 06:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cacc4c6bfc80 8025233: Move sun.invoke.Stable into java.lang.invoke package Reviewed-by: twisti, iveresov ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.hpp Changeset: 268e7a2178d7 Author: iveresov Date: 2013-10-03 16:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/268e7a2178d7 Merge ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/services/classLoadingService.cpp Changeset: d68894a09c7c Author: jiangli Date: 2013-09-27 13:49 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d68894a09c7c 8024990: JT_JDK: 11 failures with SIGSEGV on arm-sflt platforms in nightly fastdebug build. Summary: Enable patching for load_appendix_id. Reviewed-by: kvn, dlong, bdelsart ! src/share/vm/c1/c1_Runtime1.cpp Changeset: 5186dcaca431 Author: jiangli Date: 2013-09-27 13:53 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5186dcaca431 Merge ! src/share/vm/c1/c1_Runtime1.cpp - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar Changeset: d0cfa6502dfe Author: jprovino Date: 2013-10-03 10:25 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d0cfa6502dfe Merge ! src/share/vm/c1/c1_Runtime1.cpp Changeset: 100614790c1e Author: vladidan Date: 2013-10-03 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/100614790c1e Merge Changeset: c319b188c7b2 Author: tschatzl Date: 2013-09-26 12:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c319b188c7b2 8014078: G1: improve remembered set summary information by providing per region type information Summary: Add memory consumption breakdown on a per region type in the G1 remembered set summary statistics. This simplifies remembered set memory consumption analysis. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! test/gc/g1/TestSummarizeRSetStats.java + test/gc/g1/TestSummarizeRSetStatsPerRegion.java + test/gc/g1/TestSummarizeRSetStatsTools.java Changeset: bc918fd1e584 Author: mgerdin Date: 2013-09-27 10:23 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bc918fd1e584 8025279: metaspace/flags/maxMetaspaceSize throws OOM: out of Compressed Klass space Summary: Only put "Compressed class space" as OOM cause if actually using Compressed class space Reviewed-by: jwilhelm, stefank, ehelin, coleenp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 4fa18058548e Author: tschatzl Date: 2013-09-27 11:18 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4fa18058548e Merge Changeset: ccef6e165e8b Author: tschatzl Date: 2013-09-27 13:41 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ccef6e165e8b Merge Changeset: d55c004e1d4d Author: mgerdin Date: 2013-09-24 14:46 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d55c004e1d4d 8025305: Cleanup CardTableModRefBS usage in G1 Summary: Move some G1 specific code from CardTableModRefBS to G1SATBCardTableModRefBS. Reviewed-by: brutisso, tschatzl, ehelin ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp Changeset: 7ec10139bf37 Author: tschatzl Date: 2013-09-30 12:43 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ec10139bf37 8025441: G1: assert "assert(thread < _num_vtimes) failed: just checking" fails when G1ConcRefinementThreads > ParallelGCThreads Summary: The initialization for the remembered set summary data structures used the wrong thread count, i.e. number of worker threads instead of number of refinement threads. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.hpp + test/gc/g1/TestSummarizeRSetStatsThreads.java Changeset: 9de9169ddde6 Author: brutisso Date: 2013-10-01 07:52 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9de9169ddde6 8025605: G1: Heap expansion logging misleading for fully expanded heap Reviewed-by: tschatzl, jwilhelm, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 9ecd6d3782b1 Author: ehelin Date: 2013-10-01 15:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9ecd6d3782b1 8025313: MetaspaceMemoryPool incorrectly reports undefined size for max Reviewed-by: stefank, tschatzl ! src/share/vm/memory/collectorPolicy.cpp Changeset: 77a774ab3cf0 Author: mgerdin Date: 2013-10-02 14:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/77a774ab3cf0 8012525: gc/metaspace/G1AddMetaspaceDependency.java Test fails a safepoint timeout assertion or hangs. Reviewed-by: brutisso, tschatzl ! test/gc/metaspace/G1AddMetaspaceDependency.java Changeset: 6e22e7042433 Author: ehelin Date: 2013-09-30 11:39 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6e22e7042433 8025226: TestPerfCountersAndMemoryPools.java fails with -Xmixed or -Xcomp Reviewed-by: brutisso, mgerdin ! test/gc/metaspace/TestPerfCountersAndMemoryPools.java Changeset: 379ef2cc19c0 Author: ehelin Date: 2013-10-02 18:24 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/379ef2cc19c0 Merge Changeset: ab68fc0101ce Author: jwilhelm Date: 2013-10-03 13:19 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ab68fc0101ce 8025855: Simplify GenRemSet code slightly Summary: Remove a few redundant switch-statements Reviewed-by: jcoomes, tschatzl ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/genRemSet.cpp Changeset: c49c7f835e8d Author: jwilhelm Date: 2013-10-03 17:16 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c49c7f835e8d 8025853: Remove unnecessary uses of GenerationSizer Summary: Removed stray includes and some minor cleanup of GenerationSizer Reviewed-by: tschatzl, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp Changeset: 798522662fcd Author: jcoomes Date: 2013-10-04 13:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/798522662fcd Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp Changeset: 562a3d356de6 Author: amurillo Date: 2013-10-04 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/562a3d356de6 Merge - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java Changeset: f6962730bbde Author: amurillo Date: 2013-10-04 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f6962730bbde Added tag hs25-b53 for changeset 562a3d356de6 ! .hgtags Changeset: 02d171a3b5d1 Author: cl Date: 2013-10-10 10:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/02d171a3b5d1 Added tag jdk8-b111 for changeset f6962730bbde ! .hgtags From robert.field at oracle.com Thu Oct 10 23:27:37 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Fri, 11 Oct 2013 06:27:37 +0000 Subject: hg: jdk8/tl/langtools: 8012557: Implement lambda methods on interfaces as private; ... Message-ID: <20131011062740.CD92362F5F@hg.openjdk.java.net> Changeset: 1ce8405af5fe Author: rfield Date: 2013-10-10 23:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1ce8405af5fe 8012557: Implement lambda methods on interfaces as private 8016320: Method reference in subinterface of type I.super::foo produces exception at runtime Summary: Now that the VM supports interface instance private methods, lambda methods and lambda bridges are always private. Access is now through invokespecial. Reviewed-by: vromero, jlahoda ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java + test/tools/javac/lambda/8012557/A.java + test/tools/javac/lambda/8012557/B.java + test/tools/javac/lambda/8012557/C.java + test/tools/javac/lambda/8012557/PrivateLambdas.java + test/tools/javac/lambda/8012557/SAM.java + test/tools/javac/lambda/8016320/IllegalBridgeModifier.java From staffan.larsen at oracle.com Thu Oct 10 23:32:27 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 11 Oct 2013 08:32:27 +0200 Subject: RR(S): JDK-8004213 jdp packet need pid, broadcast interval and rmi server hostname fields. In-Reply-To: <5256F2FE.4090202@oracle.com> References: <5256F2FE.4090202@oracle.com> Message-ID: Dmitry, This looks good, just two small nits: test/sun/management/jdp/JdpClient.java: 56: "Packet error fileld " -> "Packet error: field " test/sun/management/jdp/JdpClient.java: 68-74: missing space after the comma Thanks, /Staffan On 10 okt 2013, at 20:33, Dmitry Samersoff wrote: > Hi Everyone, > > This fix covers > > JDK JDK-8004213 JDP packets should contain PID > JDK-8004215 JDP packets should contain the configured broadcast interval > JDK-8007071 JDP does not work well with java.rmi.server.hostname overrides. > > and add three extra fields to JDP packet: PID, rmi server name, > broadcast interval. > > PID gathering code mostly borrowed from hotspot testlibrary. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8004213/webrev.01/ > > -Dmitry > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From lana.steuck at oracle.com Thu Oct 10 21:36:19 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 11 Oct 2013 04:36:19 +0000 Subject: hg: jdk8/tl/jdk: 96 new changesets Message-ID: <20131011045629.B3ECD62F5A@hg.openjdk.java.net> Changeset: 529cd4de1823 Author: prr Date: 2013-09-26 15:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/529cd4de1823 7092764: java.awt.font.TransformAttribute.equals(null) throws NPE Reviewed-by: jgodinez, jchen ! src/share/classes/java/awt/font/TransformAttribute.java + test/java/awt/font/TransformAttribute/TransformEqualityTest.java Changeset: 1bcd48cfb7be Author: ceisserer Date: 2013-09-26 16:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1bcd48cfb7be 8024895: xrender MaskImage cache isn't accounting for change in alpha Reviewed-by: prr, jchen ! src/solaris/classes/sun/java2d/xr/XRMaskImage.java + test/java/awt/image/DrawImage/EABlitTest.java Changeset: dae020405903 Author: lana Date: 2013-09-26 17:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dae020405903 Merge Changeset: 0151f12bd392 Author: malenkov Date: 2013-08-22 17:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0151f12bd392 8023536: Some regression tests have a wrong header Reviewed-by: alexsch ! test/java/beans/Performance/Test7122740.java ! test/java/beans/Performance/Test7184799.java ! test/javax/swing/JTree/8013571/Test8013571.java Changeset: b71f112dab2a Author: malenkov Date: 2013-08-22 21:05 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b71f112dab2a 7057769: JScrollBar spec should specify that unit increment & decrement functionality may not be present Reviewed-by: alexsch ! src/share/classes/javax/swing/JScrollBar.java Changeset: f983fd18dd81 Author: malenkov Date: 2013-08-23 19:29 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f983fd18dd81 7080613: java.beans.DefaultPersistenceDelegate.instantiate(..) doesn't throw NPE Reviewed-by: alexsch ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/PersistenceDelegate.java Changeset: 22ef5187a3e6 Author: dmarkov Date: 2013-08-26 17:21 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/22ef5187a3e6 8023474: First mousepress doesn't start editing in JTree Reviewed-by: alexp, anthony ! src/share/classes/java/awt/Component.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/sun/awt/AWTAccessor.java + test/javax/swing/plaf/basic/BasicTreeUI/8023474/bug8023474.java Changeset: abd068530590 Author: malenkov Date: 2013-08-27 12:53 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/abd068530590 7195179: ClassCastException for null values in JComboBox Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java + test/javax/swing/JComboBox/7195179/Test7195179.java Changeset: 92adff44c841 Author: malenkov Date: 2013-08-27 13:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92adff44c841 8021379: JFileChooser Create New Folder button enabled in write proteced directory Reviewed-by: alexsch ! src/share/classes/sun/swing/FilePane.java Changeset: 4bfcf9c5ced3 Author: malenkov Date: 2013-08-27 13:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bfcf9c5ced3 8022398: javax/swing/JFileChooser/8013442/Test8013442.java fails Reviewed-by: alexsch ! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java + src/share/classes/sun/swing/AbstractFilterComboBoxModel.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java Changeset: e11ed7187b0c Author: lana Date: 2013-08-27 21:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e11ed7187b0c Merge - src/share/classes/com/sun/security/auth/PolicyParser.java - src/share/classes/com/sun/security/auth/SubjectCodeSource.java - src/share/classes/java/util/jar/UnsupportedProfileException.java - src/share/classes/sun/security/provider/ConfigSpiFile.java - test/java/net/URLClassLoader/profiles/Basic.java - test/java/net/URLClassLoader/profiles/Lib.java - test/java/net/URLClassLoader/profiles/basic.sh - test/tools/jar/AddAndUpdateProfile.java - test/tools/launcher/profiles/Basic.java - test/tools/launcher/profiles/Logging.java - test/tools/launcher/profiles/Main.java - test/tools/launcher/profiles/VersionCheck.java Changeset: 43de418f1345 Author: ptbrunet Date: 2013-08-28 17:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43de418f1345 8011955: Lunar screen reader crashes intermittently in WindowsAccessBridge-32.DLL 6995891: JAWS will occasionally stop speaking focused objects as user TABs -> problem with message queue 8014738: Combobox menu items are not announced with JAWS 8011938: Java Ferret example corrupts JCombobox of the running application 8012011: JAB 2.0.2 incompletely shows kbd accelerator in menus 8022966: Java Access Bridge no longer usable with screen magnifiers Reviewed-by: raginip, tbell, erikj, art ! make/bridge/AccessBridgeJava/Makefile ! makefiles/CompileJavaClasses.gmk ! makefiles/GensrcMisc.gmk Changeset: 35644adc3269 Author: malenkov Date: 2013-08-28 17:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/35644adc3269 6968363: ClassCastException while entering HINDI characters with CustomDocument Reviewed-by: alexsch ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/GlyphPainter2.java ! src/share/classes/javax/swing/text/ParagraphView.java + test/javax/swing/text/AbstractDocument/6968363/Test6968363.java Changeset: 6432f8749e1d Author: pchelko Date: 2013-08-30 11:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6432f8749e1d 8023966: JViewPort.BLIT_SCROLL_MODE does not work in JLightweightFrame Reviewed-by: anthony, ant ! src/share/classes/javax/swing/JViewport.java Changeset: 7151f08eeadf Author: alexsch Date: 2013-08-30 13:28 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7151f08eeadf 8022401: [macosx] javax/swing/text/JTextComponent/5074573/bug5074573.java fails Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTEvent.m + test/java/awt/event/KeyEvent/KeyChar/KeyCharTest.java Changeset: f2f614e31522 Author: malenkov Date: 2013-09-02 14:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f2f614e31522 7156658: JTextComponent.setFocusAccelerator() spec does not state that focus accelerator is L&F dependent Reviewed-by: alexsch ! src/share/classes/javax/swing/text/JTextComponent.java Changeset: 6ffa2680e139 Author: art Date: 2013-09-02 16:48 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ffa2680e139 8022184: Fix static , Raw warnings in classes belonging to java.awt Reviewed-by: art, anthony Contributed-by: Srikalyan Chandrashekar ! src/share/classes/java/awt/AWTKeyStroke.java ! src/share/classes/java/awt/CardLayout.java ! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/GradientPaintContext.java ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/SequencedEvent.java ! src/share/classes/java/awt/TexturePaintContext.java ! src/share/classes/java/awt/WaitDispatchSupport.java Changeset: b5ed8686cc01 Author: malenkov Date: 2013-09-03 11:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b5ed8686cc01 6943780: JTabbedPane throws ArrayIndexOutOfBoundsException sometimes Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java + test/javax/swing/plaf/basic/BasicTabbedPaneUI/Test6943780.java Changeset: 80a8c4ff3b51 Author: alexsch Date: 2013-09-03 17:27 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80a8c4ff3b51 8007156: [macosx] Wrong events in processKeyBinding of JTable Submit Date Reviewed-by: leonidr ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java + test/java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java Changeset: 2ad01ecbaf90 Author: malenkov Date: 2013-09-03 21:53 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ad01ecbaf90 7172865: PropertyDescriptor fails to work with setter method name if setter is non-void Reviewed-by: art, alexsch ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/MethodDescriptor.java + src/share/classes/java/beans/MethodRef.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test7172865.java Changeset: ba711056009f Author: pchelko Date: 2013-09-04 14:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ba711056009f 8021943: FileDialog getFile returns corrupted string after previous setFile Reviewed-by: anthony, serb Contributed-by: alexander.zvegintsev at oracle.com ! src/windows/native/sun/windows/awt_FileDialog.cpp Changeset: ba041df8a554 Author: mcherkas Date: 2013-09-04 18:12 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ba041df8a554 8023565: JPG causes javax.imageio.IIOException: ICC APP2 encoutered without prior JFIF Reviewed-by: bae, vadim ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java Changeset: e4ba3d9ea041 Author: mcherkas Date: 2013-09-05 15:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4ba3d9ea041 8023392: Swing text components printed with spaces between chars Reviewed-by: alexsch, alexp Contributed-by: anton.nashatyrev at oracle.com ! src/share/classes/sun/swing/SwingUtilities2.java + test/java/awt/print/bug8023392/bug8023392.html + test/java/awt/print/bug8023392/bug8023392.java Changeset: d267c066b006 Author: lana Date: 2013-09-06 15:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d267c066b006 Merge - src/share/classes/sun/misc/Compare.java - src/share/classes/sun/misc/Sort.java Changeset: fbb6f976d780 Author: alexsch Date: 2013-09-09 17:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fbb6f976d780 8024413: Add tests for issues JDK-8002077 and JDK-7199708 Reviewed-by: malenkov, leonidr + test/javax/swing/JFileChooser/7199708/bug7199708.java + test/javax/swing/JFileChooser/8002077/bug8002077.java Changeset: 3ea08767fc0d Author: alexsch Date: 2013-09-09 18:34 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3ea08767fc0d 8020060: MoleculeViewerTest demo doesn't work due to SecurityPermissions Reviewed-by: malenkov, erikj ! makefiles/CompileDemos.gmk ! src/share/demo/applets/MoleculeViewer/XYZApp.java ! src/share/demo/applets/MoleculeViewer/example1.html ! src/share/demo/applets/MoleculeViewer/example2.html ! src/share/demo/applets/MoleculeViewer/example3.html ! src/share/demo/applets/WireFrame/ThreeD.java ! src/share/demo/applets/WireFrame/example1.html ! src/share/demo/applets/WireFrame/example2.html ! src/share/demo/applets/WireFrame/example3.html ! src/share/demo/applets/WireFrame/example4.html Changeset: fc5d16fec25f Author: serb Date: 2013-09-09 21:03 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc5d16fec25f 8023042: Inaccuracy in documentation in a sound area Reviewed-by: prr ! src/share/classes/javax/sound/sampled/AudioFileFormat.java ! src/share/classes/javax/sound/sampled/AudioFormat.java Changeset: 9d0d961fb1cd Author: pchelko Date: 2013-09-10 11:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9d0d961fb1cd 8024381: The test for 8020210 does not have @bug tag Reviewed-by: anthony, serb ! test/java/awt/Window/MaximizeOffscreen/MaximizeOffscreenTest.java Changeset: 8b6dace81d6c Author: alexsch Date: 2013-09-10 14:33 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b6dace81d6c 8021253: JFileChooser does not react on pressing enter since java 7 Reviewed-by: malenkov ! src/share/classes/javax/swing/JFileChooser.java + test/javax/swing/JFileChooser/8021253/bug8021253.java Changeset: 1daffcf035c4 Author: malenkov Date: 2013-09-10 17:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1daffcf035c4 7057770: (spec)Scrollbar spec should specify that unit increment & decrement functionality may not be present Reviewed-by: alexsch ! src/share/classes/java/awt/Scrollbar.java Changeset: eedb2b6d93ec Author: malenkov Date: 2013-09-10 17:12 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eedb2b6d93ec 8024407: [macosx] javax/swing/JScrollBar/7163696/Test7163696.java failed intermittently on macos Reviewed-by: alexsch ! test/javax/swing/JScrollBar/7163696/Test7163696.java Changeset: 0cc00c11e17e Author: leonidr Date: 2013-09-10 20:42 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0cc00c11e17e 8003901: [macosx] Need test for JDK-8002114 Reviewed-by: anthony, serb ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: 04fbd34fda7b Author: bagiras Date: 2013-09-12 14:56 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/04fbd34fda7b 8003965: Toolkit.beep() documentation is ambiguous Reviewed-by: anthony ! src/share/classes/java/awt/Toolkit.java Changeset: def1fa9854f7 Author: bagiras Date: 2013-09-12 15:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/def1fa9854f7 7064312: Cleanup: avoid using unsafe string function Reviewed-by: serb, pchelko ! src/windows/native/sun/windows/awt_FileDialog.cpp ! src/windows/native/sun/windows/awt_Font.cpp ! src/windows/native/sun/windows/awt_PrintControl.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_ole.cpp Changeset: 6321e4429a38 Author: serb Date: 2013-09-12 18:21 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6321e4429a38 7124537: [macosx] Menu shortcuts for all menu items should be disabled if a menu itself is disabled Reviewed-by: anthony, leonidr ! src/macosx/classes/sun/lwawt/macosx/CMenu.java ! src/macosx/classes/sun/lwawt/macosx/CMenuItem.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java Changeset: 3213c388740a Author: dmarkov Date: 2013-09-12 18:44 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3213c388740a 8024395: Improve fix for line break calculations Reviewed-by: alexp, alexsch ! src/share/classes/javax/swing/text/FlowView.java ! src/share/classes/javax/swing/text/View.java ! test/javax/swing/text/View/8014863/bug8014863.java Changeset: ef2f0c15b332 Author: pchelko Date: 2013-09-13 11:58 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef2f0c15b332 8024170: [SwingNode] Implement cursor change Reviewed-by: anthony, ant ! src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java ! src/share/classes/sun/swing/JLightweightFrame.java ! src/share/classes/sun/swing/LightweightContent.java ! src/share/classes/sun/swing/SwingAccessor.java ! src/solaris/classes/sun/awt/X11/XLightweightFramePeer.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WLightweightFramePeer.java Changeset: 12788c245d67 Author: pchelko Date: 2013-09-13 17:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/12788c245d67 8015453: java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java failed on windows with jdk8 since b86 Reviewed-by: art, serb ! src/share/classes/sun/awt/datatransfer/DataTransferer.java Changeset: df107b1f2f2e Author: pchelko Date: 2013-09-13 17:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df107b1f2f2e 8015371: The HTML text without tags does not appear inside the WordPad application, and we try to click the button, but the case exits. Reviewed-by: anthony, serb ! src/windows/classes/sun/awt/windows/WDataTransferer.java Changeset: 40fdf56c09a9 Author: pchelko Date: 2013-09-13 17:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40fdf56c09a9 8015455: java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java hangs on windows Reviewed-by: serb, anthony ! src/share/classes/java/awt/dnd/DropTarget.java ! src/share/classes/javax/swing/TransferHandler.java Changeset: 915d13946f18 Author: mcherkas Date: 2013-09-13 17:48 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/915d13946f18 8015601: [macosx] Test javax/swing/JInternalFrame/InternalFrameIsNotCollectedTest.java fails on MacOS X Reviewed-by: alexp, alexsch ! test/javax/swing/JInternalFrame/InternalFrameIsNotCollectedTest.java Changeset: ad52e924c55a Author: kshefov Date: 2013-09-13 17:54 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad52e924c55a 8006087: [TEST_BUG] The BACKSPACE key doesn't work and after pressing 'cancel' and 'DONE' button, the case pass automatically. Reviewed-by: alexsch, serb ! test/javax/swing/JFileChooser/4150029/bug4150029.html ! test/javax/swing/JFileChooser/4150029/bug4150029.java Changeset: c8a85165b725 Author: kshefov Date: 2013-09-13 17:58 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c8a85165b725 8015597: [TEST_BUG] [macosx] Test closed/javax/swing/JMenuBar/4750590/bug4750590.java fails since JDK 8 b75 on MacOSX Reviewed-by: alexsch, serb + test/javax/swing/JMenuBar/4750590/bug4750590.java Changeset: 17cc8f13e4e7 Author: pchelko Date: 2013-09-13 18:02 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/17cc8f13e4e7 8012026: [macosx] Component.getMousePosition() does not work in an applet on MacOS Reviewed-by: anthony, serb ! make/sun/lwawt/FILES_export_macosx.gmk - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTView.m + test/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java + test/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java Changeset: a46d22ee4d4b Author: alexsch Date: 2013-09-16 17:45 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a46d22ee4d4b 8008728: [macosx] Swing. JDialog. Modal dialog goes to background Reviewed-by: serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Modal/ModalDialogOrderingTest/ModalDialogOrderingTest.java Changeset: 8f5b4e7623cf Author: ant Date: 2013-09-16 18:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8f5b4e7623cf 8022512: JLightweightFrame: the content pane should be transparent Reviewed-by: anthony ! src/share/classes/sun/swing/JLightweightFrame.java Changeset: 49c7d299a504 Author: kshefov Date: 2013-09-16 19:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/49c7d299a504 7020060: [TEST_BUG] java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java failed Reviewed-by: anthony, serb ! test/java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java Changeset: 98080e9367be Author: kshefov Date: 2013-09-16 19:21 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98080e9367be 8015588: [TEST_BUG] [macosx] Test java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java fails on MacOSX Reviewed-by: anthony, serb ! test/java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java Changeset: 04612a52e7bd Author: pchelko Date: 2013-09-16 19:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/04612a52e7bd 8024779: [macosx] SwingNode crashes on exit Reviewed-by: anthony, ant ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 4e88bf592830 Author: pchelko Date: 2013-09-16 19:44 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4e88bf592830 8024485: For 5-1 step: if input something into the 'File:' and 'Dir:', the dir output isn't empty in the output window after showing and canceling the file dialog Reviewed-by: serb, anthony ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java Changeset: 8530456e0091 Author: omajid Date: 2013-09-16 15:43 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8530456e0091 8024863: X11: Support GNOME Shell as mutter Reviewed-by: anthony ! src/solaris/classes/sun/awt/X11/XWM.java Changeset: 4899f6734a14 Author: ant Date: 2013-09-18 12:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4899f6734a14 8024839: [Unified Swing/Fx threading] don't schedule an event dispatching from the event dispatch thread Reviewed-by: anthony, pchelko ! src/share/classes/java/awt/EventQueue.java Changeset: cc7a15f4c735 Author: mcherkas Date: 2013-09-18 15:12 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc7a15f4c735 8016746: Test javax/swing/JTable/7068740/bug7068740.java fails Reviewed-by: serb, alexsch ! test/javax/swing/JTable/7068740/bug7068740.java Changeset: 2c240454c192 Author: leonidr Date: 2013-09-18 18:36 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c240454c192 7188071: closed/java/awt/TrayIcon/TrayIconSecurity/GrantedTrayIconTest fails Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java Changeset: 20b1135647fa Author: lana Date: 2013-09-18 16:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/20b1135647fa Merge ! src/share/classes/java/awt/Toolkit.java - src/share/classes/java/util/stream/CloseableStream.java - src/share/classes/java/util/stream/DelegatingStream.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/windows/native/sun/windows/awt_PrintControl.cpp - test/java/util/Collection/ListDefaults.java - test/java/util/Map/CheckRandomHashSeed.java - test/java/util/Map/TreeBinSplitBackToEntries.java - test/java/util/concurrent/ConcurrentHashMap/toArray.java - test/sun/tools/jconsole/ImmutableResourceTest.java - test/sun/tools/jconsole/ImmutableResourceTest.sh Changeset: e292d504ad68 Author: leonidr Date: 2013-09-19 22:33 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e292d504ad68 7144065: [macosx] Orphaned Choice popup window Reviewed-by: anthony, serb Contributed-by: alexander.potochkin at oracle.com ! src/macosx/classes/sun/lwawt/LWChoicePeer.java Changeset: 602e5d0141d3 Author: leonidr Date: 2013-09-19 23:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/602e5d0141d3 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol Reviewed-by: anthony, serb ! makefiles/GensrcProperties.gmk + src/macosx/classes/sun/awt/resources/awtosx.properties ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/sun/awt/AWTAccessor.java + test/java/awt/Toolkit/ToolkitPropertyTest/bug7129133.java Changeset: c04e55e17066 Author: kshefov Date: 2013-09-20 17:07 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c04e55e17066 7124314: [TEST_BUG] [macosx] Aqua LAF: JTree doesn't select element by keyboards left and right keys Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JTree/4927934/bug4927934.java Changeset: 6c1f9468f3de Author: kshefov Date: 2013-09-20 17:16 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6c1f9468f3de 8017180: [macosx] [TEST_BUG] alt-key doesn't work on macos for menu Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/java/awt/Focus/KeyEventForBadFocusOwnerTest/KeyEventForBadFocusOwnerTest.java + test/javax/swing/JMenuItem/4171437/bug4171437.java + test/javax/swing/JPopupMenu/4458079/bug4458079.java Changeset: f139aef966fd Author: kshefov Date: 2013-09-20 17:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f139aef966fd 7124232: [TEST_BUG] [macosx] JSplitPane has wrong divider location Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JSplitPane/4816114/bug4816114.java Changeset: abebe03818f6 Author: malenkov Date: 2013-09-20 18:56 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/abebe03818f6 7024235: Nimbus L&F: wrong "packing" of a frame containing tabbed pane Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java + test/javax/swing/JTabbedPane/7024235/Test7024235.java Changeset: 2ac59698de38 Author: kshefov Date: 2013-09-23 16:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ac59698de38 8015600: [TEST_BUG] [macosx] Test closed/javax/swing/plaf/basic/BasicMenuUI/4983388/bug4983388.java fails since JDK 8 b75 on MacOSX Reviewed-by: alexsch, serb + test/javax/swing/plaf/basic/BasicMenuUI/4983388/bug4983388.java Changeset: eac52fe3990c Author: serb Date: 2013-09-23 16:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eac52fe3990c 8005255: [macosx] Cleanup warnings in sun.lwawt Reviewed-by: alexsch, anthony ! make/sun/lwawt/FILES_export_macosx.gmk ! src/macosx/classes/sun/lwawt/LWButtonPeer.java ! src/macosx/classes/sun/lwawt/LWCanvasPeer.java ! src/macosx/classes/sun/lwawt/LWCheckboxPeer.java ! src/macosx/classes/sun/lwawt/LWChoicePeer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWContainerPeer.java ! src/macosx/classes/sun/lwawt/LWCursorManager.java ! src/macosx/classes/sun/lwawt/LWLabelPeer.java ! src/macosx/classes/sun/lwawt/LWListPeer.java ! src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java ! src/macosx/classes/sun/lwawt/LWPanelPeer.java ! src/macosx/classes/sun/lwawt/LWRepaintArea.java ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java ! src/macosx/classes/sun/lwawt/LWScrollPanePeer.java ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java - src/macosx/classes/sun/lwawt/SelectionClearListener.java Changeset: 2684fd4e9f3b Author: serb Date: 2013-09-23 17:55 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2684fd4e9f3b 7172833: For default java.awt.Toolkit impl methods java.awt.Toolkit.is/setDynamicLayout() are not consistent Reviewed-by: alexsch, anthony ! src/share/classes/java/awt/Toolkit.java + test/java/awt/Toolkit/DynamicLayout/bug7172833.java Changeset: d73d3a29065c Author: serb Date: 2013-09-23 21:24 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d73d3a29065c 8019282: keyRelesed is reached even though key was NOT released Reviewed-by: serb, anthony Contributed-by: alexander.zvegintsev at oracle.com ! make/sun/xawt/mapfile-vers ! makefiles/mapfiles/libawt_xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: 8c0b943a0090 Author: yan Date: 2013-09-24 12:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8c0b943a0090 8025114: Eliminate doclint errors in java.awt.dnd package javadoc Reviewed-by: serb, alexsch ! src/share/classes/java/awt/dnd/DragGestureRecognizer.java ! src/share/classes/java/awt/dnd/DragSource.java ! src/share/classes/java/awt/dnd/DragSourceContext.java ! src/share/classes/java/awt/dnd/DragSourceDragEvent.java ! src/share/classes/java/awt/dnd/DragSourceDropEvent.java ! src/share/classes/java/awt/dnd/DragSourceEvent.java ! src/share/classes/java/awt/dnd/DropTarget.java ! src/share/classes/java/awt/dnd/DropTargetDragEvent.java ! src/share/classes/java/awt/dnd/DropTargetDropEvent.java Changeset: 1303823e89da Author: yan Date: 2013-09-24 16:36 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1303823e89da 8025230: [cleanup] some more javadoc formatting fixes for swing Reviewed-by: alexsch ! src/share/classes/javax/swing/JPanel.java ! src/share/classes/javax/swing/JPasswordField.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/javax/swing/JRadioButton.java ! src/share/classes/javax/swing/JRadioButtonMenuItem.java ! src/share/classes/javax/swing/JRootPane.java ! src/share/classes/javax/swing/JScrollPane.java ! src/share/classes/javax/swing/JSeparator.java ! src/share/classes/javax/swing/JSlider.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JTextArea.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JToolBar.java ! src/share/classes/javax/swing/JToolTip.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JViewport.java ! src/share/classes/javax/swing/KeyStroke.java ! src/share/classes/javax/swing/OverlayLayout.java ! src/share/classes/javax/swing/ProgressMonitor.java ! src/share/classes/javax/swing/SizeRequirements.java ! src/share/classes/javax/swing/SizeSequence.java Changeset: d580e0bc85d9 Author: yan Date: 2013-09-24 17:04 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d580e0bc85d9 8025117: [cleanup] Eliminate doclint errors in javax/swing/text classes Reviewed-by: alexsch ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/RowFilter.java ! src/share/classes/javax/swing/plaf/TextUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/share/classes/javax/swing/text/AttributeSet.java ! src/share/classes/javax/swing/text/BadLocationException.java ! src/share/classes/javax/swing/text/BoxView.java ! src/share/classes/javax/swing/text/Caret.java ! src/share/classes/javax/swing/text/ComponentView.java ! src/share/classes/javax/swing/text/CompositeView.java ! src/share/classes/javax/swing/text/DefaultEditorKit.java ! src/share/classes/javax/swing/text/DefaultHighlighter.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/Document.java ! src/share/classes/javax/swing/text/DocumentFilter.java ! src/share/classes/javax/swing/text/EditorKit.java ! src/share/classes/javax/swing/text/FieldView.java ! src/share/classes/javax/swing/text/FlowView.java ! src/share/classes/javax/swing/text/GapContent.java ! src/share/classes/javax/swing/text/GlyphView.java ! src/share/classes/javax/swing/text/Highlighter.java ! src/share/classes/javax/swing/text/IconView.java ! src/share/classes/javax/swing/text/NavigationFilter.java ! src/share/classes/javax/swing/text/ParagraphView.java ! src/share/classes/javax/swing/text/PasswordView.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/PlainView.java ! src/share/classes/javax/swing/text/Position.java ! src/share/classes/javax/swing/text/StringContent.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/StyledDocument.java ! src/share/classes/javax/swing/text/StyledEditorKit.java ! src/share/classes/javax/swing/text/TabExpander.java ! src/share/classes/javax/swing/text/TabableView.java ! src/share/classes/javax/swing/text/TableView.java ! src/share/classes/javax/swing/text/Utilities.java ! src/share/classes/javax/swing/text/View.java ! src/share/classes/javax/swing/text/WrappedPlainView.java ! src/share/classes/javax/swing/text/ZoneView.java ! src/share/classes/javax/swing/text/html/BlockView.java ! src/share/classes/javax/swing/text/html/CSS.java ! src/share/classes/javax/swing/text/html/FormView.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java Changeset: 58178aec7e81 Author: kshefov Date: 2013-09-24 17:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/58178aec7e81 7124320: [TEST_BUG] [macosx] JComboBox doesn't change selection on mouse over Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JComboBox/6236162/bug6236162.java Changeset: f500844c2253 Author: kshefov Date: 2013-09-24 17:56 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f500844c2253 7133154: [TEST_BUG] [macosx] closed/javax/swing/JInternalFrame/4251301/bug4251301.java fails on MacOS Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JInternalFrame/4251301/bug4251301.java Changeset: 967557d5b90a Author: kshefov Date: 2013-09-24 18:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/967557d5b90a 7133146: [macosx] closed/javax/swing/JInternalFrame/4193219/IconCoord fails on MacOS Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JInternalFrame/4193219/IconCoord.java Changeset: 3982dd1210ba Author: kshefov Date: 2013-09-24 18:20 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3982dd1210ba 8015599: [TEST_BUG] [macosx] Test closed/javax/swing/Popup/TaskbarPositionTest.java fails since JDK 8 b75 on MacOSX Reviewed-by: alexsch, serb + test/javax/swing/Popup/TaskbarPositionTest.java Changeset: 2ed1584d62c5 Author: leonidr Date: 2013-09-24 18:24 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ed1584d62c5 8022555: [macosx] AppleScriptEngine.jar MUST call java.awt.Toolkit.getDefaultToolkit() lazily Reviewed-by: anthony, serb ! src/macosx/classes/apple/applescript/AppleScriptEngineFactory.java Changeset: a284da808700 Author: malenkov Date: 2013-09-25 14:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a284da808700 8023310: Thread contention in the method Beans.IsDesignTime() Reviewed-by: art, sfriberg ! src/share/classes/java/beans/ThreadGroupContext.java ! src/share/classes/java/beans/WeakIdentityMap.java Changeset: 10e66428ddb0 Author: alexsch Date: 2013-09-25 16:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/10e66428ddb0 8007155: [macosx] Disabled panel takes mouse input in JLayeredPane Reviewed-by: serb, anthony ! src/macosx/classes/sun/lwawt/LWCursorManager.java ! src/share/classes/java/awt/Container.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/GlobalCursorManager.java ! src/solaris/classes/sun/awt/X11/XGlobalCursorManager.java ! src/windows/classes/sun/awt/windows/WGlobalCursorManager.java ! src/windows/native/sun/windows/awt_Container.cpp ! src/windows/native/sun/windows/awt_Container.h ! src/windows/native/sun/windows/awt_Cursor.cpp + test/java/awt/Cursor/CursorOverlappedPanelsTest/CursorOverlappedPanelsTest.html + test/java/awt/Cursor/CursorOverlappedPanelsTest/CursorOverlappedPanelsTest.java Changeset: 7cad8ef127a9 Author: pchelko Date: 2013-09-25 16:12 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7cad8ef127a9 8024987: Copy/paste regression since JDK8 b86 Reviewed-by: serb, anthony ! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java Changeset: cff4f079fa3f Author: kshefov Date: 2013-09-25 16:52 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cff4f079fa3f 8004032: [TEST_BUG] [macosx] There is no effect when double clicking on the Icon, after right clicking on the Icon and the Icon disappear Reviewed-by: anthony, serb + test/java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html + test/java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.java Changeset: 681ac9f9c452 Author: alexsch Date: 2013-09-25 17:08 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/681ac9f9c452 8025070: [javadoc] fix some javadoc errors in javax/swing/plaf/synth Reviewed-by: serb, alexsch Contributed-by: Alexander Stepanov ! src/share/classes/javax/swing/plaf/synth/SynthButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthCheckBoxMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthCheckBoxUI.java ! src/share/classes/javax/swing/plaf/synth/SynthColorChooserUI.java ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java ! src/share/classes/javax/swing/plaf/synth/SynthDesktopIconUI.java ! src/share/classes/javax/swing/plaf/synth/SynthDesktopPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthEditorPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthFormattedTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameUI.java ! src/share/classes/javax/swing/plaf/synth/SynthLabelUI.java ! src/share/classes/javax/swing/plaf/synth/SynthListUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuLayout.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuUI.java ! src/share/classes/javax/swing/plaf/synth/SynthOptionPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPainter.java ! src/share/classes/javax/swing/plaf/synth/SynthPanelUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPasswordFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPopupMenuUI.java ! src/share/classes/javax/swing/plaf/synth/SynthProgressBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRadioButtonMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRadioButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRootPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthScrollPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSeparatorUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSpinnerUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTableHeaderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToggleButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToolTipUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java ! src/share/classes/javax/swing/plaf/synth/SynthViewportUI.java Changeset: 2f8803ebd98c Author: yan Date: 2013-09-25 17:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2f8803ebd98c 8025085: [javadoc] some errors in javax/swing Reviewed-by: alexsch Contributed-by: Dmitry Zinkevich ! src/share/classes/javax/swing/JButton.java ! src/share/classes/javax/swing/JCheckBox.java ! src/share/classes/javax/swing/JCheckBoxMenuItem.java ! src/share/classes/javax/swing/JColorChooser.java ! src/share/classes/javax/swing/JComboBox.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JDesktopPane.java ! src/share/classes/javax/swing/JMenuItem.java ! src/share/classes/javax/swing/JToggleButton.java ! src/share/classes/javax/swing/SpinnerDateModel.java ! src/share/classes/javax/swing/SpinnerListModel.java ! src/share/classes/javax/swing/SpinnerNumberModel.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/UnsupportedLookAndFeelException.java ! src/share/classes/javax/swing/ViewportLayout.java ! src/share/classes/javax/swing/plaf/LayerUI.java ! src/share/classes/javax/swing/plaf/basic/BasicBorders.java ! src/share/classes/javax/swing/plaf/basic/BasicDesktopIconUI.java ! src/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicGraphicsUtils.java ! src/share/classes/javax/swing/plaf/basic/BasicIconFactory.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLabelUI.java ! src/share/classes/javax/swing/plaf/basic/BasicListUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolBarSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolTipUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/javax/swing/plaf/basic/DefaultMenuLayout.java ! src/share/classes/javax/swing/plaf/metal/MetalBorders.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalLabelUI.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalPopupMenuSeparatorUI.java ! src/share/classes/javax/swing/plaf/metal/MetalScrollPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSeparatorUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java ! src/share/classes/javax/swing/plaf/metal/MetalTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToolTipUI.java ! src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java ! src/share/classes/javax/swing/plaf/synth/Region.java ! src/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/share/classes/javax/swing/text/html/ImageView.java ! src/share/classes/javax/swing/text/html/InlineView.java ! src/share/classes/javax/swing/text/html/StyleSheet.java ! src/share/classes/javax/swing/text/html/parser/ContentModel.java ! src/share/classes/javax/swing/text/html/parser/DocumentParser.java ! src/share/classes/javax/swing/text/html/parser/Parser.java ! src/share/classes/javax/swing/tree/AbstractLayoutCache.java ! src/share/classes/javax/swing/tree/DefaultTreeCellEditor.java ! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java ! src/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/share/classes/javax/swing/tree/TreeCellRenderer.java ! src/share/classes/javax/swing/tree/TreeModel.java ! src/share/classes/javax/swing/undo/UndoManager.java Changeset: c40ed21f2939 Author: alexsch Date: 2013-09-25 17:42 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c40ed21f2939 7083457: Incomplete specification for javax/swing/text/DefaultCaret.html#setVisible(boolean) Reviewed-by: malenkov, serb ! src/share/classes/javax/swing/text/DefaultCaret.java + test/javax/swing/text/DefaultCaret/7083457/bug7083457.java Changeset: 09fb25645717 Author: ptbrunet Date: 2013-09-26 10:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/09fb25645717 8025160: Recent Java Accessibility Bridge push has make failures Reviewed-by: tbell, erikj ! make/bridge/AccessBridgeJava/Makefile ! makefiles/CreateJars.gmk ! makefiles/GensrcMisc.gmk Changeset: 0270e9b0891b Author: yan Date: 2013-09-26 16:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0270e9b0891b 8025218: [javadoc] some errors in java/awt classes Reviewed-by: yan Contributed-by: Dmitry Zinkevich ! src/share/classes/java/awt/AWTKeyStroke.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/Event.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/GridBagConstraints.java ! src/share/classes/java/awt/GridBagLayout.java ! src/share/classes/java/awt/GridLayout.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/MenuBar.java ! src/share/classes/java/awt/ScrollPane.java ! src/share/classes/java/awt/ScrollPaneAdjustable.java ! src/share/classes/java/awt/SystemTray.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/awt/event/MouseMotionListener.java Changeset: 3b22833f2695 Author: lana Date: 2013-09-26 17:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b22833f2695 Merge - src/macosx/classes/sun/lwawt/SelectionClearListener.java - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java Changeset: 8edd604bf960 Author: lana Date: 2013-09-26 17:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8edd604bf960 Merge - test/java/util/regex/PatternTest.java Changeset: 9684ed81cd21 Author: ksrini Date: 2013-09-27 16:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9684ed81cd21 8020552: [launcher] changes to support removal of Solaris 32-bit distribution 8023495: [infra] create 64-bit solaris bits with symlinks Reviewed-by: ihse, tbell, dholmes, darcy, alanb, erikj, sla, martin ! makefiles/Images.gmk ! src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/solaris/bin/java_md_solinux.c ! test/com/sun/jdi/BadHandshakeTest.java ! test/com/sun/jdi/DoubleAgentTest.java ! test/com/sun/jdi/ExclusiveBind.java ! test/com/sun/jdi/PrivateTransportTest.sh ! test/com/sun/jdi/RunToExit.java - test/com/sun/jdi/Solaris32AndSolaris64Test.sh ! test/com/sun/jdi/connect/spi/SimpleLaunchingConnector.java ! test/demo/jvmti/DemoRun.java ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/Makefile + test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh ! test/sun/security/tools/keytool/autotest.sh ! test/sun/tools/jhat/HatRun.java ! test/tools/launcher/6842838/Test6842838.sh ! test/tools/launcher/ChangeDataModel.java ! test/tools/launcher/ExecutionEnvironment.java ! test/tools/launcher/FXLauncherTest.java ! test/tools/launcher/RunpathTest.java ! test/tools/launcher/Test7029048.java ! test/tools/launcher/TestHelper.java Changeset: 2c7c7b813eb3 Author: katleman Date: 2013-10-01 12:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c7c7b813eb3 Merge - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so Changeset: dd43ccb3bac9 Author: ihse Date: 2013-10-01 11:08 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd43ccb3bac9 8019219: Fix typo in jdk/makefiles "default" targets Reviewed-by: erikj ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk Changeset: 54e099776f08 Author: erikj Date: 2013-10-02 15:08 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/54e099776f08 Merge Changeset: 9f57d2774603 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f57d2774603 Added tag jdk8-b110 for changeset 54e099776f08 ! .hgtags Changeset: 88597d465e48 Author: ihse Date: 2013-10-01 15:13 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/88597d465e48 8016024: Remove solaris path from FillCacheFind Reviewed-by: erikj ! makefiles/Tools.gmk Changeset: 760af86b3f3f Author: erikj Date: 2013-10-03 11:27 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/760af86b3f3f 8024522: java.time packages missing from src.zip Reviewed-by: tbell ! makefiles/CreateJars.gmk Changeset: 719befd87c7b Author: katleman Date: 2013-10-08 13:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/719befd87c7b Merge Changeset: a1d91e198ddf Author: lana Date: 2013-10-10 13:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a1d91e198ddf Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk - src/macosx/classes/sun/lwawt/SelectionClearListener.java - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so ! test/sun/security/tools/keytool/autotest.sh Changeset: 1863a7e3a1c9 Author: lana Date: 2013-10-10 20:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1863a7e3a1c9 Merge Changeset: 7af04d2d2139 Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7af04d2d2139 Added tag jdk8-b111 for changeset 719befd87c7b ! .hgtags Changeset: 1a067bc31098 Author: lana Date: 2013-10-10 21:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1a067bc31098 Merge From fredrik.arvidsson at oracle.com Fri Oct 11 00:45:59 2013 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Fri, 11 Oct 2013 09:45:59 +0200 Subject: RFR (XS) 8024425: VM_HeapDumper doesn't put anonymous classes in the heap dump In-Reply-To: <52569A79.5020405@oracle.com> References: <52568048.5050109@oracle.com> <52569A79.5020405@oracle.com> Message-ID: <5257ACB7.3010109@oracle.com> Hi I made a small change and added a new review: http://cr.openjdk.java.net/~allwin/farvidss/8024425/webrev.01/ About this change: Space added after if statement. Regarding the comment about indentation. It seems like webrev have some problems with my change. Looking in the Raw code reveals that the indentation in this case is in fact correct, 2 spaces. /F On 2013-10-10 14:15, David Holmes wrote: > Fredrik, > > On 10/10/2013 8:24 PM, Fredrik Arvidsson wrote: >> Hi >> >> Please help me to review the changes below: >> >> Jira case: https://bugs.openjdk.java.net/browse/JDK-8024425 >> >> Webrev: http://cr.openjdk.java.net/~allwin/farvidss/8024425/webrev.00/ >> > > Please make sure what you have in your html email is consistent. Your > visible text refers to a different bug id to the actual link - and the > links are different to the subject. Can you please re-send this email > with corrected links and subject - thanks. > > Style issues: > - ensure spaces are after keywords ie if(x) should be if (x) > - two-space indent not four > > David > ----- > >> About this change. >> I switched from using the SystemDictionary to use ClassLoaderDataGraph >> instead since the SystemDictionary lack information about the >> 'anonymous' classes related to this bug. >> >> Previously failed Aurora tests have been run using UTE and verified to >> PASS. The heap dump file have been successfully opened and parsed using >> jhat and eclipse MAT. >> >> Cheers >> /Fredrik From peter.allwin at oracle.com Fri Oct 11 00:52:46 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Fri, 11 Oct 2013 09:52:46 +0200 Subject: RR(S): JDK-8004213 jdp packet need pid, broadcast interval and rmi server hostname fields. In-Reply-To: <5256F2FE.4090202@oracle.com> References: <5256F2FE.4090202@oracle.com> Message-ID: <9AC43B86-B2BD-4118-96F9-0A986311C693@oracle.com> Hi Dmitry, Looks good, thanks for fixing this! Regards, /peter On Oct 10, 2013, at 8:33 PM, Dmitry Samersoff wrote: > Hi Everyone, > > This fix covers > > JDK JDK-8004213 JDP packets should contain PID > JDK-8004215 JDP packets should contain the configured broadcast interval > JDK-8007071 JDP does not work well with java.rmi.server.hostname overrides. > > and add three extra fields to JDP packet: PID, rmi server name, > broadcast interval. > > PID gathering code mostly borrowed from hotspot testlibrary. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8004213/webrev.01/ > > -Dmitry > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From sundararajan.athijegannathan at oracle.com Fri Oct 11 01:20:24 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 11 Oct 2013 08:20:24 +0000 Subject: hg: jdk8/tl/nashorn: 5 new changesets Message-ID: <20131011082034.ECA2662F63@hg.openjdk.java.net> Changeset: 34f7a699cdef Author: sundar Date: 2013-10-10 14:43 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/34f7a699cdef 8026162: "this" in SAM adapter functions is wrong Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java + test/script/basic/JDK-8026162.js Changeset: ed3da7a574a0 Author: lagergren Date: 2013-10-10 16:16 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ed3da7a574a0 8026250: Logging nullpointer bugfix and javadoc warnings Reviewed-by: hannesw, jlaskey, sundar ! src/jdk/nashorn/api/scripting/JSObject.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/ListAdapter.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/WithObject.java Changeset: a781ea074521 Author: sundar Date: 2013-10-10 21:43 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a781ea074521 8026264: Getter, setter function name mangling issues Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java + test/script/basic/JDK-8026264.js Changeset: 375c2f2d41c8 Author: sundar Date: 2013-10-11 06:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/375c2f2d41c8 8026263: [NASHORN] Test test/script/basic/JDK-8025488.js fails in nightly builds Reviewed-by: jlaskey ! test/script/basic/JDK-8025488.js Changeset: 56be5161f0d2 Author: sundar Date: 2013-10-11 09:09 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/56be5161f0d2 Merge From david.holmes at oracle.com Fri Oct 11 02:07:51 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Oct 2013 19:07:51 +1000 Subject: RFR (XS) 8024425: VM_HeapDumper doesn't put anonymous classes in the heap dump In-Reply-To: <5257ACB7.3010109@oracle.com> References: <52568048.5050109@oracle.com> <52569A79.5020405@oracle.com> <5257ACB7.3010109@oracle.com> Message-ID: <5257BFE7.4000605@oracle.com> On 11/10/2013 5:45 PM, Fredrik Arvidsson wrote: > Hi > > I made a small change and added a new review: > http://cr.openjdk.java.net/~allwin/farvidss/8024425/webrev.01/ > > > About this change: > Space added after if statement. Thanks. > Regarding the comment about indentation. It seems like webrev have some > problems with my change. Looking in the Raw code reveals that the > indentation in this case is in fact correct, 2 spaces. I think the indentation issue was in the "wrong" webrev that I saw. David > /F > > On 2013-10-10 14:15, David Holmes wrote: >> Fredrik, >> >> On 10/10/2013 8:24 PM, Fredrik Arvidsson wrote: >>> Hi >>> >>> Please help me to review the changes below: >>> >>> Jira case: https://bugs.openjdk.java.net/browse/JDK-8024425 >>> >>> Webrev: http://cr.openjdk.java.net/~allwin/farvidss/8024425/webrev.00/ >>> >> >> Please make sure what you have in your html email is consistent. Your >> visible text refers to a different bug id to the actual link - and the >> links are different to the subject. Can you please re-send this email >> with corrected links and subject - thanks. >> >> Style issues: >> - ensure spaces are after keywords ie if(x) should be if (x) >> - two-space indent not four >> >> David >> ----- >> >>> About this change. >>> I switched from using the SystemDictionary to use ClassLoaderDataGraph >>> instead since the SystemDictionary lack information about the >>> 'anonymous' classes related to this bug. >>> >>> Previously failed Aurora tests have been run using UTE and verified to >>> PASS. The heap dump file have been successfully opened and parsed using >>> jhat and eclipse MAT. >>> >>> Cheers >>> /Fredrik > From peter.allwin at oracle.com Fri Oct 11 02:36:31 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Fri, 11 Oct 2013 11:36:31 +0200 Subject: RFR: 8004183: test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java doesn't clean-up Message-ID: <19DA6A49-4316-4626-9C3D-E1D342F92CB4@oracle.com> Hello! Looking for reviews of this fix where a jmxremote test left a worker thread running after completion. Fix is to flag the thread to finish and join before test method exit. bug: https://bugs.openjdk.java.net/browse/JDK-8004183 cr: http://cr.openjdk.java.net/~allwin/8004183/webrev.00 Thanks! /peter From shanliang.jiang at oracle.com Fri Oct 11 02:53:59 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 11 Oct 2013 11:53:59 +0200 Subject: RFR: 8004183: test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java doesn't clean-up In-Reply-To: <19DA6A49-4316-4626-9C3D-E1D342F92CB4@oracle.com> References: <19DA6A49-4316-4626-9C3D-E1D342F92CB4@oracle.com> Message-ID: <5257CAB7.4060303@oracle.com> Looks good to me. Shanliang Peter Allwin wrote: > Hello! > > Looking for reviews of this fix where a jmxremote test left a worker thread running after completion. Fix is to flag the thread to finish and join before test method exit. > > bug: https://bugs.openjdk.java.net/browse/JDK-8004183 > cr: http://cr.openjdk.java.net/~allwin/8004183/webrev.00 > > Thanks! > /peter From serguei.spitsyn at oracle.com Fri Oct 11 03:06:28 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 11 Oct 2013 03:06:28 -0700 Subject: RFR (XS) 8024425: VM_HeapDumper doesn't put anonymous classes in the heap dump In-Reply-To: <5257ACB7.3010109@oracle.com> References: <52568048.5050109@oracle.com> <52569A79.5020405@oracle.com> <5257ACB7.3010109@oracle.com> Message-ID: <5257CDA4.4080906@oracle.com> Frederik, It looks good. Thanks, Serguei On 10/11/13 12:45 AM, Fredrik Arvidsson wrote: > Hi > > I made a small change and added a new review: > http://cr.openjdk.java.net/~allwin/farvidss/8024425/webrev.01/ > > > About this change: > Space added after if statement. > > Regarding the comment about indentation. It seems like webrev have > some problems with my change. Looking in the Raw code reveals that the > indentation in this case is in fact correct, 2 spaces. > > /F > > On 2013-10-10 14:15, David Holmes wrote: >> Fredrik, >> >> On 10/10/2013 8:24 PM, Fredrik Arvidsson wrote: >>> Hi >>> >>> Please help me to review the changes below: >>> >>> Jira case: https://bugs.openjdk.java.net/browse/JDK-8024425 >>> >>> Webrev: http://cr.openjdk.java.net/~allwin/farvidss/8024425/webrev.00/ >>> >> >> Please make sure what you have in your html email is consistent. Your >> visible text refers to a different bug id to the actual link - and >> the links are different to the subject. Can you please re-send this >> email with corrected links and subject - thanks. >> >> Style issues: >> - ensure spaces are after keywords ie if(x) should be if (x) >> - two-space indent not four >> >> David >> ----- >> >>> About this change. >>> I switched from using the SystemDictionary to use ClassLoaderDataGraph >>> instead since the SystemDictionary lack information about the >>> 'anonymous' classes related to this bug. >>> >>> Previously failed Aurora tests have been run using UTE and verified to >>> PASS. The heap dump file have been successfully opened and parsed using >>> jhat and eclipse MAT. >>> >>> Cheers >>> /Fredrik > From daniel.fuchs at oracle.com Fri Oct 11 03:18:29 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 11 Oct 2013 12:18:29 +0200 Subject: RFR: 8004183: test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java doesn't clean-up In-Reply-To: <5257CAB7.4060303@oracle.com> References: <19DA6A49-4316-4626-9C3D-E1D342F92CB4@oracle.com> <5257CAB7.4060303@oracle.com> Message-ID: <5257D075.1040104@oracle.com> Hi Peter, Looks good to me - but you might want to use 'boolean' for isRunning rather than 'Boolean'. Joining on the daemon thread is probably not necessary, but there's no harm in it (the important part being isRunning=false + s.close()). best regards, -- daniel (not a reviewer) On 10/11/13 11:53 AM, shanliang wrote: > Looks good to me. > > Shanliang > > > Peter Allwin wrote: >> Hello! >> >> Looking for reviews of this fix where a jmxremote test left a worker >> thread running after completion. Fix is to flag the thread to finish >> and join before test method exit. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8004183 >> cr: http://cr.openjdk.java.net/~allwin/8004183/webrev.00 >> >> Thanks! >> /peter > From david.holmes at oracle.com Fri Oct 11 04:13:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Oct 2013 21:13:01 +1000 Subject: RFR: 8004183: test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java doesn't clean-up In-Reply-To: <5257D075.1040104@oracle.com> References: <19DA6A49-4316-4626-9C3D-E1D342F92CB4@oracle.com> <5257CAB7.4060303@oracle.com> <5257D075.1040104@oracle.com> Message-ID: <5257DD3D.4020307@oracle.com> On 11/10/2013 8:18 PM, Daniel Fuchs wrote: > Hi Peter, > > Looks good to me - but you might want to use 'boolean' for > isRunning rather than 'Boolean'. Definitely! > Joining on the daemon thread is probably not necessary, > but there's no harm in it (the important part being > isRunning=false + s.close()). It is pointless having the thread be a daemon now. If running in the same VM as anything else joining will ensure this test is cleaned up before the next test commences. David ----- > best regards, > > -- daniel (not a reviewer) > > On 10/11/13 11:53 AM, shanliang wrote: >> Looks good to me. >> >> Shanliang >> >> >> Peter Allwin wrote: >>> Hello! >>> >>> Looking for reviews of this fix where a jmxremote test left a worker >>> thread running after completion. Fix is to flag the thread to finish >>> and join before test method exit. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8004183 >>> cr: http://cr.openjdk.java.net/~allwin/8004183/webrev.00 >>> >>> Thanks! >>> /peter >> > From dmitry.samersoff at oracle.com Fri Oct 11 05:09:11 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 11 Oct 2013 16:09:11 +0400 Subject: RR(S): JDK-8024071 In ManagementAgent.start it should be possible to set the jdp.name parameter. Message-ID: <5257EA67.4080706@oracle.com> Please review the fix. Hotspot part http://cr.openjdk.java.net/~dsamersoff/JDK-8024071/webrev.01/hotspot Jdk http://cr.openjdk.java.net/~dsamersoff/JDK-8024071/webrev.01/hotspot Testing: Test for this fix is part of changes for JDK-8004213, http://cr.openjdk.java.net/~dsamersoff/JDK-8004213/webrev.01/ -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Fri Oct 11 05:12:21 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 11 Oct 2013 16:12:21 +0400 Subject: RR(S): JDK-8024071 In ManagementAgent.start it should be possible to set the jdp.name parameter. Message-ID: <5257EB25.6040500@oracle.com> Fixed typeo, please disregard previous letter. Please review the fix. Hotspot part http://cr.openjdk.java.net/~dsamersoff/JDK-8024071/webrev.01/hotspot Jdk http://cr.openjdk.java.net/~dsamersoff/JDK-8024071/webrev.01/jdk Testing: Test for this fix is part of changes for JDK-8004213, http://cr.openjdk.java.net/~dsamersoff/JDK-8004213/webrev.01/ -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From sundararajan.athijegannathan at oracle.com Fri Oct 11 05:28:37 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 11 Oct 2013 12:28:37 +0000 Subject: hg: jdk8/tl/nashorn: 4 new changesets Message-ID: <20131011122842.3823862F6C@hg.openjdk.java.net> Changeset: 1c154cee43d9 Author: hannesw Date: 2013-10-11 10:56 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1c154cee43d9 8026292: Megamorphic setter fails with boolean value Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/MethodEmitter.java + test/script/basic/JDK-8026292.js Changeset: fb091f9052a6 Author: sundar Date: 2013-10-11 11:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fb091f9052a6 8026302: source representation of getter and setter methods is wrong Reviewed-by: lagergren, hannesw, jlaskey ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8026302.js + test/script/basic/JDK-8026302.js.EXPECTED ! test/script/basic/objects.js.EXPECTED Changeset: 062579f50371 Author: sundar Date: 2013-10-11 14:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/062579f50371 8026317: $ in the function name results in wrong function being invoked Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/codegen/Namespace.java + test/script/basic/JDK-8026317.js + test/script/basic/JDK-8026317.js.EXPECTED Changeset: b35d175207f6 Author: sundar Date: 2013-10-11 14:13 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b35d175207f6 Merge From peter.allwin at oracle.com Fri Oct 11 05:32:07 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Fri, 11 Oct 2013 14:32:07 +0200 Subject: RFR: 8004183: test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java doesn't clean-up In-Reply-To: <5257DD3D.4020307@oracle.com> References: <19DA6A49-4316-4626-9C3D-E1D342F92CB4@oracle.com> <5257CAB7.4060303@oracle.com> <5257D075.1040104@oracle.com> <5257DD3D.4020307@oracle.com> Message-ID: <24313344-3E61-4FF2-BBD0-6918B0DD4C0C@oracle.com> Thanks for the feedback, good points! I've put an updated webrev here: http://cr.openjdk.java.net/~allwin/8004183/webrev.01/ Changes: boolean instead of Boolean no longer sets worker as daemon Regards, /peter On Oct 11, 2013, at 1:13 PM, David Holmes wrote: > On 11/10/2013 8:18 PM, Daniel Fuchs wrote: >> Hi Peter, >> >> Looks good to me - but you might want to use 'boolean' for >> isRunning rather than 'Boolean'. > > Definitely! > >> Joining on the daemon thread is probably not necessary, >> but there's no harm in it (the important part being >> isRunning=false + s.close()). > > It is pointless having the thread be a daemon now. If running in the same VM as anything else joining will ensure this test is cleaned up before the next test commences. > > David > ----- > >> best regards, >> >> -- daniel (not a reviewer) >> >> On 10/11/13 11:53 AM, shanliang wrote: >>> Looks good to me. >>> >>> Shanliang >>> >>> >>> Peter Allwin wrote: >>>> Hello! >>>> >>>> Looking for reviews of this fix where a jmxremote test left a worker >>>> thread running after completion. Fix is to flag the thread to finish >>>> and join before test method exit. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8004183 >>>> cr: http://cr.openjdk.java.net/~allwin/8004183/webrev.00 >>>> >>>> Thanks! >>>> /peter >>> >> From daniel.fuchs at oracle.com Fri Oct 11 05:34:42 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 11 Oct 2013 14:34:42 +0200 Subject: RFR: 8004183: test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java doesn't clean-up In-Reply-To: <24313344-3E61-4FF2-BBD0-6918B0DD4C0C@oracle.com> References: <19DA6A49-4316-4626-9C3D-E1D342F92CB4@oracle.com> <5257CAB7.4060303@oracle.com> <5257D075.1040104@oracle.com> <5257DD3D.4020307@oracle.com> <24313344-3E61-4FF2-BBD0-6918B0DD4C0C@oracle.com> Message-ID: <5257F062.4040905@oracle.com> Looks good! -- daniel On 10/11/13 2:32 PM, Peter Allwin wrote: > Thanks for the feedback, good points! > > I've put an updated webrev here: > > http://cr.openjdk.java.net/~allwin/8004183/webrev.01/ > > Changes: > boolean instead of Boolean > no longer sets worker as daemon > > Regards, > /peter > > On Oct 11, 2013, at 1:13 PM, David Holmes wrote: > >> On 11/10/2013 8:18 PM, Daniel Fuchs wrote: >>> Hi Peter, >>> >>> Looks good to me - but you might want to use 'boolean' for >>> isRunning rather than 'Boolean'. >> >> Definitely! >> >>> Joining on the daemon thread is probably not necessary, >>> but there's no harm in it (the important part being >>> isRunning=false + s.close()). >> >> It is pointless having the thread be a daemon now. If running in the same VM as anything else joining will ensure this test is cleaned up before the next test commences. >> >> David >> ----- >> >>> best regards, >>> >>> -- daniel (not a reviewer) >>> >>> On 10/11/13 11:53 AM, shanliang wrote: >>>> Looks good to me. >>>> >>>> Shanliang >>>> >>>> >>>> Peter Allwin wrote: >>>>> Hello! >>>>> >>>>> Looking for reviews of this fix where a jmxremote test left a worker >>>>> thread running after completion. Fix is to flag the thread to finish >>>>> and join before test method exit. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8004183 >>>>> cr: http://cr.openjdk.java.net/~allwin/8004183/webrev.00 >>>>> >>>>> Thanks! >>>>> /peter >>>> >>> > From jaroslav.bachorik at oracle.com Fri Oct 11 05:35:29 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 11 Oct 2013 14:35:29 +0200 Subject: RR(S): JDK-8024071 In ManagementAgent.start it should be possible to set the jdp.name parameter. In-Reply-To: <5257EB25.6040500@oracle.com> References: <5257EB25.6040500@oracle.com> Message-ID: <5257F091.3070804@oracle.com> Dmitry, what is the purpose of the change in JMXStartStopTest.sh? The rest looks fine. -JB- On 11.10.2013 14:12, Dmitry Samersoff wrote: > Fixed typeo, please disregard previous letter. > > > Please review the fix. > > Hotspot part > > http://cr.openjdk.java.net/~dsamersoff/JDK-8024071/webrev.01/hotspot > > Jdk > > http://cr.openjdk.java.net/~dsamersoff/JDK-8024071/webrev.01/jdk > > > Testing: > > Test for this fix is part of changes for JDK-8004213, > http://cr.openjdk.java.net/~dsamersoff/JDK-8004213/webrev.01/ > > From dmitry.samersoff at oracle.com Fri Oct 11 05:59:10 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 11 Oct 2013 16:59:10 +0400 Subject: RR(S): JDK-8024071 In ManagementAgent.start it should be possible to set the jdp.name parameter. In-Reply-To: <5257F091.3070804@oracle.com> References: <5257EB25.6040500@oracle.com> <5257F091.3070804@oracle.com> Message-ID: <5257F61E.2090606@oracle.com> On 2013-10-11 16:35, Jaroslav Bachorik wrote: > Dmitry, > > what is the purpose of the change in JMXStartStopTest.sh? To be able to run it without jtreg - i.e. if only TESTJAVA is set. -Dmitry > > The rest looks fine. > > -JB- > > On 11.10.2013 14:12, Dmitry Samersoff wrote: >> Fixed typeo, please disregard previous letter. >> >> >> Please review the fix. >> >> Hotspot part >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8024071/webrev.01/hotspot >> >> Jdk >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8024071/webrev.01/jdk >> >> >> Testing: >> >> Test for this fix is part of changes for JDK-8004213, >> http://cr.openjdk.java.net/~dsamersoff/JDK-8004213/webrev.01/ >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From olivier.lagneau at oracle.com Fri Oct 11 05:57:43 2013 From: olivier.lagneau at oracle.com (Olivier Lagneau) Date: Fri, 11 Oct 2013 14:57:43 +0200 Subject: RFR: 8004183: test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java doesn't clean-up In-Reply-To: <5257F062.4040905@oracle.com> References: <19DA6A49-4316-4626-9C3D-E1D342F92CB4@oracle.com> <5257CAB7.4060303@oracle.com> <5257D075.1040104@oracle.com> <5257DD3D.4020307@oracle.com> <24313344-3E61-4FF2-BBD0-6918B0DD4C0C@oracle.com> <5257F062.4040905@oracle.com> Message-ID: <5257F5C7.3040309@oracle.com> +1! Olivier. Daniel Fuchs said on date 10/11/2013 2:34 PM: > Looks good! > > -- daniel > > On 10/11/13 2:32 PM, Peter Allwin wrote: >> Thanks for the feedback, good points! >> >> I've put an updated webrev here: >> >> http://cr.openjdk.java.net/~allwin/8004183/webrev.01/ >> >> Changes: >> boolean instead of Boolean >> no longer sets worker as daemon >> >> Regards, >> /peter >> >> On Oct 11, 2013, at 1:13 PM, David Holmes >> wrote: >> >>> On 11/10/2013 8:18 PM, Daniel Fuchs wrote: >>>> Hi Peter, >>>> >>>> Looks good to me - but you might want to use 'boolean' for >>>> isRunning rather than 'Boolean'. >>> >>> Definitely! >>> >>>> Joining on the daemon thread is probably not necessary, >>>> but there's no harm in it (the important part being >>>> isRunning=false + s.close()). >>> >>> It is pointless having the thread be a daemon now. If running in the >>> same VM as anything else joining will ensure this test is cleaned up >>> before the next test commences. >>> >>> David >>> ----- >>> >>>> best regards, >>>> >>>> -- daniel (not a reviewer) >>>> >>>> On 10/11/13 11:53 AM, shanliang wrote: >>>>> Looks good to me. >>>>> >>>>> Shanliang >>>>> >>>>> >>>>> Peter Allwin wrote: >>>>>> Hello! >>>>>> >>>>>> Looking for reviews of this fix where a jmxremote test left a worker >>>>>> thread running after completion. Fix is to flag the thread to finish >>>>>> and join before test method exit. >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8004183 >>>>>> cr: http://cr.openjdk.java.net/~allwin/8004183/webrev.00 >>>>>> >>>>>> Thanks! >>>>>> /peter >>>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131011/01d96dd5/attachment-0001.html From sean.mullan at oracle.com Fri Oct 11 06:45:57 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Fri, 11 Oct 2013 13:45:57 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131011134659.CE0C062F6F@hg.openjdk.java.net> Changeset: 4ad76262bac8 Author: mullan Date: 2013-10-11 08:43 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ad76262bac8 8007292: Add JavaFX internal packages to package.access Summary: build hooks to allow closed restricted packages to be added to java.security file Reviewed-by: erikj, dholmes, tbell ! make/java/security/Makefile ! make/tools/Makefile + make/tools/addtorestrictedpkgs/Makefile + make/tools/src/build/tools/addtorestrictedpkgs/AddToRestrictedPkgs.java ! makefiles/CopyFiles.gmk ! makefiles/Tools.gmk ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 76df579c0b93 Author: mullan Date: 2013-10-11 09:17 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76df579c0b93 Merge ! makefiles/Tools.gmk - src/macosx/classes/sun/lwawt/SelectionClearListener.java - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java - src/share/classes/com/sun/jdi/connect/package.html - src/share/classes/com/sun/jdi/connect/spi/package.html - src/share/classes/com/sun/jdi/event/package.html - src/share/classes/com/sun/jdi/package.html - src/share/classes/com/sun/jdi/request/package.html - src/share/classes/com/sun/management/package.html - src/share/classes/com/sun/tools/attach/package.html - src/share/classes/com/sun/tools/attach/spi/package.html - src/share/classes/com/sun/tools/jconsole/package.html - src/share/classes/java/lang/invoke/InvokeGeneric.java - src/share/classes/java/time/chrono/ChronoDateImpl.java - test/com/oracle/security/ucrypto/TestAES.java - test/com/oracle/security/ucrypto/TestDigest.java - test/com/oracle/security/ucrypto/TestRSA.java - test/com/oracle/security/ucrypto/UcryptoTest.java - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java From jan.lahoda at oracle.com Fri Oct 11 06:59:32 2013 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Fri, 11 Oct 2013 13:59:32 +0000 Subject: hg: jdk8/tl/langtools: 6278240: Exception from AnnotationValue.getValue() should list the found type not the required type Message-ID: <20131011135935.3C31862F73@hg.openjdk.java.net> Changeset: 872c4a898b38 Author: jlahoda Date: 2013-10-11 15:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/872c4a898b38 6278240: Exception from AnnotationValue.getValue() should list the found type not the required type Reviewed-by: darcy, jfranck, jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/processing/errors/EnsureAnnotationTypeMismatchException/Processor.java + test/tools/javac/processing/errors/EnsureAnnotationTypeMismatchException/Source.java + test/tools/javac/processing/errors/EnsureAnnotationTypeMismatchException/Source.out From staffan.larsen at oracle.com Fri Oct 11 07:54:58 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Fri, 11 Oct 2013 14:54:58 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8026199: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Compilation failed Message-ID: <20131011145504.2FDFC62F80@hg.openjdk.java.net> Changeset: cd7ea1d79dac Author: sla Date: 2013-10-11 13:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cd7ea1d79dac 8026199: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Compilation failed Summary: Fixed a compilation failure due to changed method name Reviewed-by: sla, jbachorik Contributed-by: fredrik.arvidsson at oracle.com ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java From dan.xu at oracle.com Fri Oct 11 09:48:01 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Fri, 11 Oct 2013 16:48:01 +0000 Subject: hg: jdk8/tl/jdk: 8025712: (props) Possible memory leak in java_props_md.c / ParseLocale Message-ID: <20131011164853.6499F62F86@hg.openjdk.java.net> Changeset: cb373cf43294 Author: dxu Date: 2013-10-11 09:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cb373cf43294 8025712: (props) Possible memory leak in java_props_md.c / ParseLocale Reviewed-by: naoto, chegar ! src/solaris/native/java/lang/java_props_md.c From stefan.karlsson at oracle.com Fri Oct 11 10:33:04 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 11 Oct 2013 19:33:04 +0200 Subject: Review request: 7196801: NPG: Fix java/lang/management/MemoryMXBean/LowMemoryTest2 Message-ID: <52583650.6060700@oracle.com> Please, review this test fix. http://cr.openjdk.java.net/~stefank/7196801/webrev.00/ Most of the fix was implemented by Coleen, I've only done some small tweaks and updated some comments. The fix depends on these changes: JDK-8025996 Track metaspace usage when metaspace is expanded JDK-8024547 MaxMetaspaceSize should limit the committed memory used by the metaspaces Both of these changesets have been pushed to hotspot-gc and are currently undergoing testing. LowMemoryTest2 can only be removed from the test/ProblemList.txt when both JDK-8025996 and JDK-8024547 have propagated through all necessary repositories. thanks, StefanK -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131011/d736c2d7/attachment.html From coleen.phillimore at oracle.com Fri Oct 11 10:44:37 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 11 Oct 2013 13:44:37 -0400 Subject: Review request: 7196801: NPG: Fix java/lang/management/MemoryMXBean/LowMemoryTest2 In-Reply-To: <52583650.6060700@oracle.com> References: <52583650.6060700@oracle.com> Message-ID: <52583905.8090403@oracle.com> Stefan, I added a check about the count exceeding 1 000 000 because it causes the test to create an invalid class file. With the shell script changes, it won't happen but I would be happy if that check were there so no one ever has to debug this thinking it has a corrupted constant pool again. Thanks, Coleen On 10/11/2013 1:33 PM, Stefan Karlsson wrote: > Please, review this test fix. > > http://cr.openjdk.java.net/~stefank/7196801/webrev.00/ > > Most of the fix was implemented by Coleen, I've only done some small > tweaks and updated some comments. > > The fix depends on these changes: > JDK-8025996 Track metaspace usage when metaspace is expanded > JDK-8024547 MaxMetaspaceSize should limit the committed memory used > by the metaspaces > > Both of these changesets have been pushed to hotspot-gc and are > currently undergoing testing. LowMemoryTest2 can only be removed from > the test/ProblemList.txt when both JDK-8025996 and JDK-8024547 have > propagated through all necessary repositories. > > thanks, > StefanK -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131011/fe59f3b4/attachment.html From stefan.karlsson at oracle.com Fri Oct 11 11:02:47 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 11 Oct 2013 20:02:47 +0200 Subject: Review request: 7196801: NPG: Fix java/lang/management/MemoryMXBean/LowMemoryTest2 In-Reply-To: <52583905.8090403@oracle.com> References: <52583650.6060700@oracle.com> <52583905.8090403@oracle.com> Message-ID: <52583D47.4000803@oracle.com> On 10/11/13 7:44 PM, Coleen Phillimore wrote: > > Stefan, > > I added a check about the count exceeding 1 000 000 because it causes > the test to create an invalid class file. With the shell script > changes, it won't happen but I would be happy if that check were there > so no one ever has to debug this thinking it has a corrupted constant > pool again. OK. I though that was old debugging left-overs. New webrev: http://cr.openjdk.java.net/~stefank/7196801/webrev.01/ thanks, StefanK > > Thanks, > Coleen > > On 10/11/2013 1:33 PM, Stefan Karlsson wrote: >> Please, review this test fix. >> >> http://cr.openjdk.java.net/~stefank/7196801/webrev.00/ >> >> Most of the fix was implemented by Coleen, I've only done some small >> tweaks and updated some comments. >> >> The fix depends on these changes: >> JDK-8025996 Track metaspace usage when metaspace is expanded >> JDK-8024547 MaxMetaspaceSize should limit the committed memory used >> by the metaspaces >> >> Both of these changesets have been pushed to hotspot-gc and are >> currently undergoing testing. LowMemoryTest2 can only be removed from >> the test/ProblemList.txt when both JDK-8025996 and JDK-8024547 have >> propagated through all necessary repositories. >> >> thanks, >> StefanK > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131011/1444bbf9/attachment.html From coleen.phillimore at oracle.com Fri Oct 11 11:04:34 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 11 Oct 2013 14:04:34 -0400 Subject: Review request: 7196801: NPG: Fix java/lang/management/MemoryMXBean/LowMemoryTest2 In-Reply-To: <52583D47.4000803@oracle.com> References: <52583650.6060700@oracle.com> <52583905.8090403@oracle.com> <52583D47.4000803@oracle.com> Message-ID: <52583DB2.1040709@oracle.com> Looks good. Thanks! Coleen On 10/11/2013 2:02 PM, Stefan Karlsson wrote: > On 10/11/13 7:44 PM, Coleen Phillimore wrote: >> >> Stefan, >> >> I added a check about the count exceeding 1 000 000 because it causes >> the test to create an invalid class file. With the shell script >> changes, it won't happen but I would be happy if that check were >> there so no one ever has to debug this thinking it has a corrupted >> constant pool again. > > OK. I though that was old debugging left-overs. > > New webrev: > http://cr.openjdk.java.net/~stefank/7196801/webrev.01/ > > thanks, > StefanK > >> >> Thanks, >> Coleen >> >> On 10/11/2013 1:33 PM, Stefan Karlsson wrote: >>> Please, review this test fix. >>> >>> http://cr.openjdk.java.net/~stefank/7196801/webrev.00/ >>> >>> Most of the fix was implemented by Coleen, I've only done some small >>> tweaks and updated some comments. >>> >>> The fix depends on these changes: >>> JDK-8025996 Track metaspace usage when metaspace is expanded >>> JDK-8024547 MaxMetaspaceSize should limit the committed memory >>> used by the metaspaces >>> >>> Both of these changesets have been pushed to hotspot-gc and are >>> currently undergoing testing. LowMemoryTest2 can only be removed >>> from the test/ProblemList.txt when both JDK-8025996 and JDK-8024547 >>> have propagated through all necessary repositories. >>> >>> thanks, >>> StefanK >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131011/62cfa0b7/attachment-0001.html From stefan.karlsson at oracle.com Fri Oct 11 11:33:25 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 11 Oct 2013 20:33:25 +0200 Subject: Review request: 7196801: NPG: Fix java/lang/management/MemoryMXBean/LowMemoryTest2 In-Reply-To: <52583DB2.1040709@oracle.com> References: <52583650.6060700@oracle.com> <52583905.8090403@oracle.com> <52583D47.4000803@oracle.com> <52583DB2.1040709@oracle.com> Message-ID: <52584475.4060201@oracle.com> On 10/11/13 8:04 PM, Coleen Phillimore wrote: > > Looks good. Thanks, Coleen. StefanK > Thanks! > Coleen > > On 10/11/2013 2:02 PM, Stefan Karlsson wrote: >> On 10/11/13 7:44 PM, Coleen Phillimore wrote: >>> >>> Stefan, >>> >>> I added a check about the count exceeding 1 000 000 because it >>> causes the test to create an invalid class file. With the shell >>> script changes, it won't happen but I would be happy if that check >>> were there so no one ever has to debug this thinking it has a >>> corrupted constant pool again. >> >> OK. I though that was old debugging left-overs. >> >> New webrev: >> http://cr.openjdk.java.net/~stefank/7196801/webrev.01/ >> >> thanks, >> StefanK >> >>> >>> Thanks, >>> Coleen >>> >>> On 10/11/2013 1:33 PM, Stefan Karlsson wrote: >>>> Please, review this test fix. >>>> >>>> http://cr.openjdk.java.net/~stefank/7196801/webrev.00/ >>>> >>>> Most of the fix was implemented by Coleen, I've only done some >>>> small tweaks and updated some comments. >>>> >>>> The fix depends on these changes: >>>> JDK-8025996 Track metaspace usage when metaspace is expanded >>>> JDK-8024547 MaxMetaspaceSize should limit the committed memory >>>> used by the metaspaces >>>> >>>> Both of these changesets have been pushed to hotspot-gc and are >>>> currently undergoing testing. LowMemoryTest2 can only be removed >>>> from the test/ProblemList.txt when both JDK-8025996 and JDK-8024547 >>>> have propagated through all necessary repositories. >>>> >>>> thanks, >>>> StefanK >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131011/bdeb5e5d/attachment.html From staffan.larsen at oracle.com Fri Oct 11 11:32:06 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Fri, 11 Oct 2013 18:32:06 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20131011183216.C939262F94@hg.openjdk.java.net> Changeset: 539144972c1e Author: sla Date: 2013-10-11 14:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/539144972c1e 8024425: VM_HeapDumper doesn't put anonymous classes in the heap dump Summary: Switched from using SystemDictionary to using ClassLoaderDataGraph to get the anonymous classes included. Reviewed-by: sla, sspitsyn Contributed-by: fredrik.arvidsson at oracle.com ! src/share/vm/services/heapDumper.cpp Changeset: 301ece1880ad Author: sla Date: 2013-10-11 14:57 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/301ece1880ad Merge From alan.bateman at oracle.com Fri Oct 11 12:59:42 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 11 Oct 2013 19:59:42 +0000 Subject: hg: jdk8/tl/jdk: 8019526: (fs) Files.lines, etc without Charset parameter Message-ID: <20131011195954.DFDAC62FA3@hg.openjdk.java.net> Changeset: 9632de07d963 Author: alanb Date: 2013-10-11 20:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9632de07d963 8019526: (fs) Files.lines, etc without Charset parameter Reviewed-by: psandoz, henryjen ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/BytesAndLines.java ! test/java/nio/file/Files/StreamTest.java From daniel.daugherty at oracle.com Fri Oct 11 13:14:31 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 11 Oct 2013 14:14:31 -0600 Subject: code review round 0 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: References: <523D144E.4000002@oracle.com> Message-ID: <52585C27.1000505@oracle.com> Staffan, Closing the loop on this comment from code review round 0. I did this: $ sh ./configure --with-debug-level=slowdebug --disable-zip-debug-info $ make with the latest version that I'm about to send out for code review round 1. And I see this: $ find build -name '*.dSYM' -print build/macosx-x86_64-normal-server-slowdebug/hotspot/bsd_amd64_compiler2/debug/libjsig.dylib.dSYM build/macosx-x86_64-normal-server-slowdebug/hotspot/bsd_amd64_compiler2/debug/libjvm.dylib.dSYM build/macosx-x86_64-normal-server-slowdebug/hotspot/bsd_amd64_compiler2/debug/libsaproc.dylib.dSYM build/macosx-x86_64-normal-server-slowdebug/hotspot/dist/jre/lib/libjsig.dylib.dSYM build/macosx-x86_64-normal-server-slowdebug/hotspot/dist/jre/lib/libsaproc.dylib.dSYM build/macosx-x86_64-normal-server-slowdebug/hotspot/dist/jre/lib/server/libjvm.dylib.dSYM build/macosx-x86_64-normal-server-slowdebug/jdk/lib/libjsig.dylib.dSYM build/macosx-x86_64-normal-server-slowdebug/jdk/lib/libsaproc.dylib.dSYM build/macosx-x86_64-normal-server-slowdebug/jdk/lib/server/libjvm.dylib.dSYM $ find build/macosx-x86_64-normal-server-slowdebug/hotspot/bsd_amd64_compiler2/debug/libjvm.dylib.dSYM -type f -print build/macosx-x86_64-normal-server-slowdebug/hotspot/bsd_amd64_compiler2/debug/libjvm.dylib.dSYM/Contents/Info.plist build/macosx-x86_64-normal-server-slowdebug/hotspot/bsd_amd64_compiler2/debug/libjvm.dylib.dSYM/Contents/Resources/DWARF/libjvm.dylib $ find build/macosx-x86_64-normal-server-slowdebug/jdk/lib/server/libjvm.dylib.dSYM -type f -print build/macosx-x86_64-normal-server-slowdebug/jdk/lib/server/libjvm.dylib.dSYM/Contents/Resources/DWARF/libjvm.dylib so the "flattening" problem is fixed. Dan On 9/30/13 7:13 AM, Staffan Larsen wrote: > First: thanks for doing this work - it will make debugging on os x so much easier! I'm not done with the review, but here are a couple of comments so far. > > I tried running with: > > $ sh ./configure --with-debug-level=slowdebug --disable-zip-debug-info > $ make > > which results in: > > ## Starting hotspot > ... > make[5]: *** No rule to make target `/Users/staffan/mercurial/hotspot-rt-jdk/build/macosx-x86_64-normal-server-slowdebug/hotspot/dist/jre/lib/amd64/libjsig.dylib.dSYM', needed by `generic_export'. Stop. > make[4]: *** [export_debug] Error 2 > make[3]: *** [all_debug_universal] Error 2 > make[2]: *** [universal_debug] Error 2 > ... > > > Another comment: There are some makefile logic for BSD, non-darwin platforms. Have you had a chance to test this logic? (hotspot/make/bsd/makefiles/vm.make) > > > Nit: hotspot/make/bsd/makefiles/vm.make: L345, L356: wrong indentation. > > > /Staffan > > > > On 21 sep 2013, at 05:36, Daniel D. Daugherty wrote: > >> Greetings, >> >> I have the initial support for Full Debug Symbols (FDS) on MacOS X done >> and ready for review: >> >> 7165611 implement Full Debug Symbols on MacOS X hotspot >> https://bugs.openjdk.java.net/browse/JDK-7165611 >> >> Here is the JDK8/HSX-25 webrev URL: >> >> OpenJDK: http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >> Internal: http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >> >> This webrev includes changes for the follow repos: >> >> jdk8 >> jdk8/hotspot >> jdk8/jdk >> jdk8/jdk/make/closed >> >> Once these changes are approved, I'm planning to push them to >> RT_Baseline. From there, they can follow the normal path to >> Main_Baseline and eventually JDK8. >> >> This work enables FDS on MacOS X for the 'hotspot' repo; the changes in >> the other repos are necessary to support importing the .diz files from >> the MacOS X 'hotspot' build into the forest build. I also fixed a few >> FDS related errors in the magic incantations for the new build. This is >> mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported >> from Solaris. In other words, this is Frankenstein's monster... >> >> Thanks to Staffan Larsen for providing an initial set of changes >> which I morphed into what you see here. >> >> Testing: >> - JPRT HSX build and test on all platforms; verification of .diz >> files in the MacOS X JPRT bundles >> - JPRT JDK8 forest build and test on all platforms; verification of >> .diz files in the MacOS X JPRT bundles >> Note: In previous FDS changesets, I also did a standalone 'jdk' >> repo build and test, but that no longer seems to work. >> >> As always, comments, questions and suggestions are welcome. >> >> Dan > From daniel.daugherty at oracle.com Fri Oct 11 13:27:29 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 11 Oct 2013 14:27:29 -0600 Subject: code review round 1 for Full Debug Symbols on MacOS X hotspot (7165611) Message-ID: <52585F31.5040107@oracle.com> Greetings, I'm ready for code review round 1 of the FDS on MacOS X hotspot changes. Below is the original code review round 0 invite (slightly edited for clarity). Working on FDS is like pulling a thread on a sweater... so there are four additional changed files along with more changes to many of the files from round 0. Here is the code review round 1 JDK8/HSX-25 webrev URL: OpenJDK: http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/1-jdk8/ Internal: http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/1-jdk8/ Changes from code review round 0 to round 1: root repo: - add configure support for DSYMUTIL macro hotspot repo: - drop Minimal1 config support for FDS on MacOS X - use DSYMUTIL macro instead of literal 'dsymutil' - fix FASTDEBUG_CFLAGS typo and add USE_CLANG support - STRIP is not used on MacOS X - fix $(UNIVERSAL_COPY_LIST) rule - refine install-dir function jdk repo: - add prep-target-dir, install-import-dir, and install-import-debuginfo functions - support importing .dSYM directories from hotspot - create libjsig.dSYM symlink from VM specific directory to the real location Files changed from code review round 0 to round 1: common/autoconf/generated-configure.sh hotspot/make/Makefile hotspot/make/bsd/makefiles/defs.make hotspot/make/bsd/makefiles/dtrace.make hotspot/make/bsd/makefiles/gcc.make hotspot/make/bsd/makefiles/jsig.make hotspot/make/bsd/makefiles/saproc.make hotspot/make/bsd/makefiles/universal.gmk hotspot/make/bsd/makefiles/vm.make hotspot/make/defs.make New files changed in code review round 1: hotspot/make/bsd/makefiles/product.make jdk/make/common/Defs.gmk jdk/make/java/redist/Makefile jdk/makefiles/Import.gmk Additional bugs filed based on code review comments, testing and just plain looking at the Makefiles: 8026280 implement Full Debug Symbols on MacOS X jdk 8026281 hotspot 'jdk6_or_earlier logic' for FDS needs to be removed 8026282 the '64' subdir logic in Makefiles might be removable 8026283 literal 'lipo' cmd uses in HotSpot makefiles 8026284 Minimal1 references/support should be removed from BSD/MacOS X 8026285 JPRT -buildenv ZIP_DEBUGINFO_FILES=0 no longer works As always, comments, questions and suggestions are welcome. Dan > Greetings, > > I have the initial support for Full Debug Symbols (FDS) on MacOS X done > and ready for review: > > 7165611 implement Full Debug Symbols on MacOS X hotspot > https://bugs.openjdk.java.net/browse/JDK-7165611 > > Here is the JDK8/HSX-25 webrev URL: > > OpenJDK: http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ > Internal: http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ > > This webrev includes changes for the follow repos: > > jdk8 > jdk8/hotspot > jdk8/jdk > > Once these changes are approved, I'm planning to push them to > RT_Baseline. From there, they can follow the normal path to > Main_Baseline and eventually JDK8. > > This work enables FDS on MacOS X for the 'hotspot' repo; the changes in > the other repos are necessary to support importing the .diz files from > the MacOS X 'hotspot' build into the forest build. I also fixed a few > FDS related errors in the magic incantations for the new build. This is > mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported > from Solaris. In other words, this is Frankenstein's monster... > > Thanks to Staffan Larsen for providing an initial set of changes > which I morphed into what you see here. > > Testing: > - JPRT HSX build and test on all platforms; verification of .diz > files in the MacOS X JPRT bundles > - JPRT JDK8 forest build and test on all platforms; verification of > .diz files in the MacOS X JPRT bundles > Note: In previous FDS changesets, I also did a standalone 'jdk' > repo build and test, but that no longer seems to work. > > As always, comments, questions and suggestions are welcome. > > Dan From coleen.phillimore at oracle.com Fri Oct 11 13:58:39 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 11 Oct 2013 20:58:39 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20131011205849.E701862FA7@hg.openjdk.java.net> Changeset: 28ca974cc21a Author: coleenp Date: 2013-10-11 11:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/28ca974cc21a 8022592: assert at constantTag.cpp:57: ShouldNotReachHere() Summary: more missing cases for JVM_CONSTANT_Method{Handle,Type}InError Reviewed-by: hseigel, dcubed ! src/share/vm/oops/constantPool.cpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: 26ae62bc26c4 Author: coleenp Date: 2013-10-11 15:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/26ae62bc26c4 Merge From vincent.x.ryan at oracle.com Fri Oct 11 12:47:42 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Fri, 11 Oct 2013 19:47:42 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131011194840.ADE9462FA1@hg.openjdk.java.net> Changeset: d23247aa7462 Author: vinnie Date: 2013-10-11 20:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d23247aa7462 8026301: DomainKeyStore doesn't cleanup correctly when storing to keystore Reviewed-by: mullan ! src/share/classes/sun/security/provider/DomainKeyStore.java Changeset: 94493b5800bb Author: vinnie Date: 2013-10-11 20:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/94493b5800bb Merge From robert.field at oracle.com Fri Oct 11 15:22:03 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Fri, 11 Oct 2013 22:22:03 +0000 Subject: hg: jdk8/tl/jdk: 8026213: Reflection support for private interface methods Message-ID: <20131011222240.638D362FAB@hg.openjdk.java.net> Changeset: 4561460bf570 Author: rfield Date: 2013-10-11 15:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4561460bf570 8026213: Reflection support for private interface methods Reviewed-by: forax, psandoz, dholmes, jfranck Contributed-by: karen.kinnear at oracle.com ! src/share/classes/sun/reflect/AccessorGenerator.java ! src/share/classes/sun/reflect/MethodAccessorGenerator.java + test/java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java From mike.duigou at oracle.com Fri Oct 11 15:31:33 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 11 Oct 2013 22:31:33 +0000 Subject: hg: jdk8/tl: 8025796: hgforest.sh could trigger unbuffered output from hg without complicated machinations Message-ID: <20131011223133.8194662FAC@hg.openjdk.java.net> Changeset: 3f9873789d44 Author: mduigou Date: 2013-10-11 15:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3f9873789d44 8025796: hgforest.sh could trigger unbuffered output from hg without complicated machinations Reviewed-by: mduigou Contributed-by: Dmitry Samersoff ! common/bin/hgforest.sh From harold.seigel at oracle.com Fri Oct 11 19:18:09 2013 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Sat, 12 Oct 2013 02:18:09 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20131012021815.B564562FC8@hg.openjdk.java.net> Changeset: 0db3ba3f6870 Author: hseigel Date: 2013-10-11 15:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0db3ba3f6870 8026041: JVM crashes with assert "assert(is_updated()) failed: must not be clear" with -XX:+PrintGCApplicationConcurrentTime in -Xcomp mode Summary: Prior to printing the time interval in RuntimeService::record_safepoint_begin(), check first that VM initialization is complete. Reviewed-by: coleenp, dholmes, sla, ctornqvi Contributed-by: lois.foltan at oracle.com ! src/share/vm/services/runtimeService.cpp Changeset: df268195b0ea Author: hseigel Date: 2013-10-11 17:08 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/df268195b0ea Merge From calvin.cheung at oracle.com Fri Oct 11 21:21:47 2013 From: calvin.cheung at oracle.com (calvin.cheung at oracle.com) Date: Sat, 12 Oct 2013 04:21:47 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 18 new changesets Message-ID: <20131012042326.B749762FCD@hg.openjdk.java.net> Changeset: ebfa5793d349 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ebfa5793d349 Added tag jdk8-b110 for changeset 6209b0ed51c0 ! .hgtags Changeset: 562a3d356de6 Author: amurillo Date: 2013-10-04 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/562a3d356de6 Merge - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java Changeset: f6962730bbde Author: amurillo Date: 2013-10-04 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f6962730bbde Added tag hs25-b53 for changeset 562a3d356de6 ! .hgtags Changeset: deec468baebd Author: amurillo Date: 2013-10-04 14:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/deec468baebd 8025859: new hotspot build - hs25-b54 Reviewed-by: jcoomes ! make/hotspot_version Changeset: c01f4910f5f5 Author: ccheung Date: 2013-10-10 13:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c01f4910f5f5 Merge Changeset: 9b4d0569f2f4 Author: jwilhelm Date: 2013-10-03 21:36 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9b4d0569f2f4 8025852: Remove unnecessary setters in collector policy classes Summary: Use instance variables directly within the collector policy classes and remove unused setters. Reviewed-by: tschatzl, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp Changeset: 087f02e22fc2 Author: jwilhelm Date: 2013-10-04 22:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/087f02e22fc2 8025854: Use "young gen" instead of "eden" Summary: Changed a few descriptions and variable names to young gen. Reviewed-by: tschatzl, jcoomes ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 263f2c796d6c Author: stefank Date: 2013-10-05 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/263f2c796d6c 8024838: Significant slowdown due to transparent huge pages Summary: Don't turn on transparent huge pages (-XX:+UseTransparentHugePages) unless explicitly specified on the command line. This has the effect that large pages are never turned on Linux unless the user has explicitly enabled any of the large pages flags: -XX:+UseLargePages, -XX:+UseTransparentHugePages, -XX:+UseHugeTLBFS, and -XX:+UseSHM. Reviewed-by: jwilhelm, tschatzl, brutisso ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp + test/runtime/memory/LargePages/TestLargePagesFlags.java Changeset: 8618e0d7735b Author: stefank Date: 2013-10-05 08:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8618e0d7735b Merge Changeset: 04b18a42c2f3 Author: mgerdin Date: 2013-10-04 13:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/04b18a42c2f3 8025526: VirtualSpace should support per-instance disabling of large pages Summary: Add a new initialization function to VirtualSpace which allows the caller to override the max commit granularity. Reviewed-by: stefank, ehelin, tschatzl ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp Changeset: 69944b868a32 Author: mgerdin Date: 2013-10-08 17:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/69944b868a32 8014555: G1: Memory ordering problem with Conc refinement and card marking Summary: Add a StoreLoad barrier in the G1 post-barrier to fix a race with concurrent refinement. Also-reviewed-by: martin.doerr at sap.com Reviewed-by: iveresov, tschatzl, brutisso, roland, kvn ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/opto/graphKit.cpp Changeset: b4d8a3d4db73 Author: tamao Date: 2013-10-09 11:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b4d8a3d4db73 8010506: Typos and errors in descriptions of vm options in globals.hpp Summary: Fix typos and errors in descriptions of vm options in globals.hpp Reviewed-by: jmasa, jwilhelm ! src/share/vm/runtime/globals.hpp Changeset: 82af7d7a0128 Author: tschatzl Date: 2013-10-09 10:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/82af7d7a0128 8003420: NPG: make new GC root for pd_set Summary: Move protection domain oops from system dictionary entries into a seperate set; the system dictionary references entries in that set now. This allows fast iteration during non-classunloading garbage collection. Implementation based on initial prototype from Ioi Lam (iklam). Reviewed-by: coleenp, iklam + agent/src/share/classes/sun/jvm/hotspot/memory/ProtectionDomainCacheEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/ProtectionDomainEntry.java ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 85c1ca43713f Author: stefank Date: 2013-10-07 15:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/85c1ca43713f 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces Reviewed-by: brutisso, jmasa, coleenp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: a6414751d537 Author: stefank Date: 2013-10-07 15:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a6414751d537 8025996: Track metaspace usage when metaspace is expanded Reviewed-by: coleenp, ehelin ! src/share/vm/memory/metaspace.cpp ! src/share/vm/services/memoryService.hpp Changeset: aa6f2ea19d8f Author: jcoomes Date: 2013-10-11 08:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/aa6f2ea19d8f Merge ! src/os/linux/vm/os_linux.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 41459da469ae Author: ccheung Date: 2013-10-11 18:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/41459da469ae Merge Changeset: 83dbf427fedd Author: ccheung Date: 2013-10-11 22:22 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/83dbf427fedd Merge From dmitry.samersoff at oracle.com Sat Oct 12 04:25:58 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 12 Oct 2013 15:25:58 +0400 Subject: RR(S): JDK-8025812 tmtools/jmap/heap_config tests fail on Linux-ia32 because it 'Can't attach to the core file' Message-ID: <525931C6.8050607@oracle.com> Hi Everybody, Please review the fix http://cr.openjdk.java.net/~dsamersoff/JDK-8025812/webrev.01/ The value of p_memsz filed of elf header of LOAD section inside coredump is rounded up to page size. So round up corresponding value read from the header of library it self. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Sat Oct 12 04:40:01 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 12 Oct 2013 15:40:01 +0400 Subject: SA ps_core mixing p_filesz and p_memsz in multiple places Message-ID: <52593511.7030908@oracle.com> Hi Everybody, SA ps_proc code mixing two different fileds of Elf header p_filesz and p_memsz. Fortunately in most cases they contains the same value but simetimes not. Do you have any background ? I plan to file a bug and clean this up. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From kellyohair at gmail.com Sat Oct 12 08:43:21 2013 From: kellyohair at gmail.com (O'Hair Kelly) Date: Sat, 12 Oct 2013 08:43:21 -0700 Subject: SA ps_core mixing p_filesz and p_memsz in multiple places In-Reply-To: <52593511.7030908@oracle.com> References: <52593511.7030908@oracle.com> Message-ID: Ghosts from the past. ;^) This may help: http://www.sco.com/developers/gabi/latest/ch5.pheader.html p_memsz will always be equal to or greater than p_filesz, the extra space is usually null bytes and I think would represent uninitialized static memory, but with a core file means that part of memory is not available or something like that. These fields can not be assumed to be the same all the time. Good Luck. . ..... . . . I will now fade back into my ghostly realm ... ;^) -kto On Oct 12, 2013, at 4:40 AM, Dmitry Samersoff wrote: > Hi Everybody, > > SA ps_proc code mixing two different fileds of Elf header p_filesz and > p_memsz. > > Fortunately in most cases they contains the same value but simetimes not. > > Do you have any background ? > > > I plan to file a bug and clean this up. > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Sat Oct 12 12:08:41 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 12 Oct 2013 23:08:41 +0400 Subject: SA ps_core mixing p_filesz and p_memsz in multiple places In-Reply-To: References: <52593511.7030908@oracle.com> Message-ID: <52599E39.2070406@oracle.com> Kelly, Glad to hear your voice and thank you for the info! -Dmitry On 2013-10-12 19:43, O'Hair Kelly wrote: > Ghosts from the past. ;^) > > This may help: http://www.sco.com/developers/gabi/latest/ch5.pheader.html > > p_memsz will always be equal to or greater than p_filesz, the extra space is usually null bytes and I think would represent uninitialized static memory, > but with a core file means that part of memory is not available or something like that. > These fields can not be assumed to be the same all the time. > > Good Luck. . ..... . . . I will now fade back into my ghostly realm ... ;^) > > > -kto > > On Oct 12, 2013, at 4:40 AM, Dmitry Samersoff wrote: > >> Hi Everybody, >> >> SA ps_proc code mixing two different fileds of Elf header p_filesz and >> p_memsz. >> >> Fortunately in most cases they contains the same value but simetimes not. >> >> Do you have any background ? >> >> >> I plan to file a bug and clean this up. >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From harold.seigel at oracle.com Sat Oct 12 12:30:49 2013 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Sat, 12 Oct 2013 19:30:49 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8025942: os::Bsd::available_memory() needs implementation Message-ID: <20131012193055.85DCE62FDB@hg.openjdk.java.net> Changeset: 3e265ce4d2dd Author: hseigel Date: 2013-10-12 13:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3e265ce4d2dd 8025942: os::Bsd::available_memory() needs implementation Summary: Implement using the host_statistics64() api. Reviewed-by: dsamersoff, morris, dholmes, coleenp, hseigel, dcubed Contributed-by: gerard.ziemski at oracle.com ! src/os/bsd/vm/os_bsd.cpp From harold.seigel at oracle.com Sat Oct 12 14:02:23 2013 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Sat, 12 Oct 2013 21:02:23 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8024667: VM crashes with "assert(method() != NULL) failed: must have set method" Message-ID: <20131012210230.7E56C62FDC@hg.openjdk.java.net> Changeset: d37a0525c0fe Author: hseigel Date: 2013-10-12 15:39 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d37a0525c0fe 8024667: VM crashes with "assert(method() != NULL) failed: must have set method" Summary: Check if data is in shared spaces before deallocating it. Reviewed-by: coleenp, dcubed ! src/share/vm/memory/metadataFactory.hpp ! src/share/vm/oops/instanceKlass.cpp From david.holmes at oracle.com Sun Oct 13 18:57:53 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Oct 2013 11:57:53 +1000 Subject: code review round 1 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <52585F31.5040107@oracle.com> References: <52585F31.5040107@oracle.com> Message-ID: <525B4FA1.7020109@oracle.com> Hi Dan, Only further comment I have, and it may well be deferred for future work, is that we should be able to abstract away the actual "extension" used for the "debuginfo" file so that we don't need macosx conditionals as much eg one: if macosx DEBUGINFO_EXTENSION=dSYM else DEBUGINFO_EXTENSION=debuginfo endif then eg: JSIG_DEBUGINFO := $(strip $(wildcard $(HOTSPOT_DIST)/jre/lib$(OPENJDK_TARGET_CPU_LIBDIR)/libjsig.$DEBUGINFO_EXTENSION) \ $(wildcard $(HOTSPOT_DIST)/jre/lib$(OPENJDK_TARGET_CPU_LIBDIR)/libjsig.diz) ) Hmm second comment - I don't see a .m4 file change that corresponds to the DSYMUTIL configure change ?? Thanks, David On 12/10/2013 6:27 AM, Daniel D. Daugherty wrote: > Greetings, > > I'm ready for code review round 1 of the FDS on MacOS X hotspot changes. > Below is the original code review round 0 invite (slightly edited for > clarity). Working on FDS is like pulling a thread on a sweater... so > there are four additional changed files along with more changes to > many of the files from round 0. > > Here is the code review round 1 JDK8/HSX-25 webrev URL: > > OpenJDK: > http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/1-jdk8/ > Internal: > http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/1-jdk8/ > > Changes from code review round 0 to round 1: > > root repo: > - add configure support for DSYMUTIL macro > > hotspot repo: > - drop Minimal1 config support for FDS on MacOS X > - use DSYMUTIL macro instead of literal 'dsymutil' > - fix FASTDEBUG_CFLAGS typo and add USE_CLANG support > - STRIP is not used on MacOS X > - fix $(UNIVERSAL_COPY_LIST) rule > - refine install-dir function > > jdk repo: > - add prep-target-dir, install-import-dir, and > install-import-debuginfo > functions > - support importing .dSYM directories from hotspot > - create libjsig.dSYM symlink from VM specific directory to > the real location > > Files changed from code review round 0 to round 1: > > common/autoconf/generated-configure.sh > hotspot/make/Makefile > hotspot/make/bsd/makefiles/defs.make > hotspot/make/bsd/makefiles/dtrace.make > hotspot/make/bsd/makefiles/gcc.make > hotspot/make/bsd/makefiles/jsig.make > hotspot/make/bsd/makefiles/saproc.make > hotspot/make/bsd/makefiles/universal.gmk > hotspot/make/bsd/makefiles/vm.make > hotspot/make/defs.make > > New files changed in code review round 1: > > hotspot/make/bsd/makefiles/product.make > jdk/make/common/Defs.gmk > jdk/make/java/redist/Makefile > jdk/makefiles/Import.gmk > > Additional bugs filed based on code review comments, testing and > just plain looking at the Makefiles: > > 8026280 implement Full Debug Symbols on MacOS X jdk > 8026281 hotspot 'jdk6_or_earlier logic' for FDS needs to be removed > 8026282 the '64' subdir logic in Makefiles might be removable > 8026283 literal 'lipo' cmd uses in HotSpot makefiles > 8026284 Minimal1 references/support should be removed from BSD/MacOS X > 8026285 JPRT -buildenv ZIP_DEBUGINFO_FILES=0 no longer works > > As always, comments, questions and suggestions are welcome. > > Dan > > > Greetings, > > > > I have the initial support for Full Debug Symbols (FDS) on MacOS X done > > and ready for review: > > > > 7165611 implement Full Debug Symbols on MacOS X hotspot > > https://bugs.openjdk.java.net/browse/JDK-7165611 > > > > Here is the JDK8/HSX-25 webrev URL: > > > > OpenJDK: > http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ > > Internal: > http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ > > > > This webrev includes changes for the follow repos: > > > > jdk8 > > jdk8/hotspot > > jdk8/jdk > > > > Once these changes are approved, I'm planning to push them to > > RT_Baseline. From there, they can follow the normal path to > > Main_Baseline and eventually JDK8. > > > > This work enables FDS on MacOS X for the 'hotspot' repo; the changes in > > the other repos are necessary to support importing the .diz files from > > the MacOS X 'hotspot' build into the forest build. I also fixed a few > > FDS related errors in the magic incantations for the new build. This is > > mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported > > from Solaris. In other words, this is Frankenstein's monster... > > > > Thanks to Staffan Larsen for providing an initial set of changes > > which I morphed into what you see here. > > > > Testing: > > - JPRT HSX build and test on all platforms; verification of .diz > > files in the MacOS X JPRT bundles > > - JPRT JDK8 forest build and test on all platforms; verification of > > .diz files in the MacOS X JPRT bundles > > Note: In previous FDS changesets, I also did a standalone 'jdk' > > repo build and test, but that no longer seems to work. > > > > As always, comments, questions and suggestions are welcome. > > > > Dan From david.holmes at oracle.com Sun Oct 13 19:14:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Oct 2013 12:14:42 +1000 Subject: RFR: 8004183: test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java doesn't clean-up In-Reply-To: <24313344-3E61-4FF2-BBD0-6918B0DD4C0C@oracle.com> References: <19DA6A49-4316-4626-9C3D-E1D342F92CB4@oracle.com> <5257CAB7.4060303@oracle.com> <5257D075.1040104@oracle.com> <5257DD3D.4020307@oracle.com> <24313344-3E61-4FF2-BBD0-6918B0DD4C0C@oracle.com> Message-ID: <525B5392.1040609@oracle.com> Looks okay to me. Thanks, David On 11/10/2013 10:32 PM, Peter Allwin wrote: > Thanks for the feedback, good points! > > I've put an updated webrev here: > > http://cr.openjdk.java.net/~allwin/8004183/webrev.01/ > > Changes: > boolean instead of Boolean > no longer sets worker as daemon > > Regards, > /peter > > On Oct 11, 2013, at 1:13 PM, David Holmes wrote: > >> On 11/10/2013 8:18 PM, Daniel Fuchs wrote: >>> Hi Peter, >>> >>> Looks good to me - but you might want to use 'boolean' for >>> isRunning rather than 'Boolean'. >> >> Definitely! >> >>> Joining on the daemon thread is probably not necessary, >>> but there's no harm in it (the important part being >>> isRunning=false + s.close()). >> >> It is pointless having the thread be a daemon now. If running in the same VM as anything else joining will ensure this test is cleaned up before the next test commences. >> >> David >> ----- >> >>> best regards, >>> >>> -- daniel (not a reviewer) >>> >>> On 10/11/13 11:53 AM, shanliang wrote: >>>> Looks good to me. >>>> >>>> Shanliang >>>> >>>> >>>> Peter Allwin wrote: >>>>> Hello! >>>>> >>>>> Looking for reviews of this fix where a jmxremote test left a worker >>>>> thread running after completion. Fix is to flag the thread to finish >>>>> and join before test method exit. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8004183 >>>>> cr: http://cr.openjdk.java.net/~allwin/8004183/webrev.00 >>>>> >>>>> Thanks! >>>>> /peter >>>> >>> > From xuelei.fan at oracle.com Sun Oct 13 21:12:08 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 14 Oct 2013 04:12:08 +0000 Subject: hg: jdk8/tl/jdk: 8026119: Regression test DHEKeySizing.java failing intermittently Message-ID: <20131014041308.02D8E62FFD@hg.openjdk.java.net> Changeset: fb202a8e83c9 Author: xuelei Date: 2013-10-13 21:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fb202a8e83c9 8026119: Regression test DHEKeySizing.java failing intermittently Reviewed-by: weijun ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/DHKeyExchange/DHEKeySizing.java From staffan.larsen at oracle.com Mon Oct 14 00:42:28 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 14 Oct 2013 09:42:28 +0200 Subject: Review request: 7196801: NPG: Fix java/lang/management/MemoryMXBean/LowMemoryTest2 In-Reply-To: <52583D47.4000803@oracle.com> References: <52583650.6060700@oracle.com> <52583905.8090403@oracle.com> <52583D47.4000803@oracle.com> Message-ID: <8A5A63F3-597C-4894-9A12-83069C239426@oracle.com> Looks good! But I wonder why there is a shell script involved. Couldn't this be just a straightforward java file with several @run tags? Thanks, /Staffan On 11 okt 2013, at 20:02, Stefan Karlsson wrote: > On 10/11/13 7:44 PM, Coleen Phillimore wrote: >> >> Stefan, >> >> I added a check about the count exceeding 1 000 000 because it causes the test to create an invalid class file. With the shell script changes, it won't happen but I would be happy if that check were there so no one ever has to debug this thinking it has a corrupted constant pool again. > > OK. I though that was old debugging left-overs. > > New webrev: > http://cr.openjdk.java.net/~stefank/7196801/webrev.01/ > > thanks, > StefanK > >> >> Thanks, >> Coleen >> >> On 10/11/2013 1:33 PM, Stefan Karlsson wrote: >>> Please, review this test fix. >>> >>> http://cr.openjdk.java.net/~stefank/7196801/webrev.00/ >>> >>> Most of the fix was implemented by Coleen, I've only done some small tweaks and updated some comments. >>> >>> The fix depends on these changes: >>> JDK-8025996 Track metaspace usage when metaspace is expanded >>> JDK-8024547 MaxMetaspaceSize should limit the committed memory used by the metaspaces >>> >>> Both of these changesets have been pushed to hotspot-gc and are currently undergoing testing. LowMemoryTest2 can only be removed from the test/ProblemList.txt when both JDK-8025996 and JDK-8024547 have propagated through all necessary repositories. >>> >>> thanks, >>> StefanK >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131014/c077c336/attachment.html From staffan.larsen at oracle.com Mon Oct 14 00:49:20 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 14 Oct 2013 09:49:20 +0200 Subject: RR(S): JDK-8025812 tmtools/jmap/heap_config tests fail on Linux-ia32 because it 'Can't attach to the core file' In-Reply-To: <525931C6.8050607@oracle.com> References: <525931C6.8050607@oracle.com> Message-ID: <4D55BF19-5B5A-4DD1-BC12-E96EEC625438@oracle.com> The fix looks good, but I have a problem with the ROUNDUP_PAGE macro. First, I don't like having macros defined in the middle of a method. Second, the definition of the macro includes the value of a local variable which is a bit hairy. Can't you just ROUNDUP directly in the four places it's needed? I think it would make for more readable code. nit on line 743: filed -> field Thanks, /Staffan On 12 okt 2013, at 13:25, Dmitry Samersoff wrote: > Hi Everybody, > > Please review the fix > > http://cr.openjdk.java.net/~dsamersoff/JDK-8025812/webrev.01/ > > The value of p_memsz filed of elf header of LOAD section inside coredump > is rounded up to page size. So round up corresponding value read from > the header of library it self. > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Mon Oct 14 00:58:13 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 14 Oct 2013 09:58:13 +0200 Subject: RFR: 8004183: test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java doesn't clean-up In-Reply-To: <24313344-3E61-4FF2-BBD0-6918B0DD4C0C@oracle.com> References: <19DA6A49-4316-4626-9C3D-E1D342F92CB4@oracle.com> <5257CAB7.4060303@oracle.com> <5257D075.1040104@oracle.com> <5257DD3D.4020307@oracle.com> <24313344-3E61-4FF2-BBD0-6918B0DD4C0C@oracle.com> Message-ID: <525BA415.2000702@oracle.com> Looks fine. -JB- On 11.10.2013 14:32, Peter Allwin wrote: > Thanks for the feedback, good points! > > I've put an updated webrev here: > > http://cr.openjdk.java.net/~allwin/8004183/webrev.01/ > > Changes: > boolean instead of Boolean > no longer sets worker as daemon > > Regards, > /peter > > On Oct 11, 2013, at 1:13 PM, David Holmes wrote: > >> On 11/10/2013 8:18 PM, Daniel Fuchs wrote: >>> Hi Peter, >>> >>> Looks good to me - but you might want to use 'boolean' for >>> isRunning rather than 'Boolean'. >> >> Definitely! >> >>> Joining on the daemon thread is probably not necessary, >>> but there's no harm in it (the important part being >>> isRunning=false + s.close()). >> >> It is pointless having the thread be a daemon now. If running in the same VM as anything else joining will ensure this test is cleaned up before the next test commences. >> >> David >> ----- >> >>> best regards, >>> >>> -- daniel (not a reviewer) >>> >>> On 10/11/13 11:53 AM, shanliang wrote: >>>> Looks good to me. >>>> >>>> Shanliang >>>> >>>> >>>> Peter Allwin wrote: >>>>> Hello! >>>>> >>>>> Looking for reviews of this fix where a jmxremote test left a worker >>>>> thread running after completion. Fix is to flag the thread to finish >>>>> and join before test method exit. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8004183 >>>>> cr: http://cr.openjdk.java.net/~allwin/8004183/webrev.00 >>>>> >>>>> Thanks! >>>>> /peter >>>> >>> > From daniel.fuchs at oracle.com Mon Oct 14 01:45:52 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Mon, 14 Oct 2013 08:45:52 +0000 Subject: hg: jdk8/tl/jdk: 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources. Message-ID: <20131014084627.8B1D662361@hg.openjdk.java.net> Changeset: 9f8bfdd99129 Author: dfuchs Date: 2013-10-14 10:42 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f8bfdd99129 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources. Reviewed-by: alanb, psandoz, mchung ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/util/ServiceLoader.java From alan.bateman at oracle.com Mon Oct 14 03:22:51 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 14 Oct 2013 10:22:51 +0000 Subject: hg: jdk8/tl/jaxp: 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc Message-ID: <20131014102257.8AE596236F@hg.openjdk.java.net> Changeset: de8c803d4958 Author: aefimov Date: 2013-10-13 13:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/de8c803d4958 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc Reviewed-by: alanb, shade ! src/com/sun/org/apache/xpath/internal/XPathContext.java From chris.hegarty at oracle.com Mon Oct 14 03:49:03 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 14 Oct 2013 10:49:03 +0000 Subject: hg: jdk8/tl/jdk: 8023555: test/java/net/Socks/SocksProxyVersion.java fails when machine name is localhost Message-ID: <20131014104948.C8DD262372@hg.openjdk.java.net> Changeset: 077237e4613f Author: tyan Date: 2013-10-14 11:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/077237e4613f 8023555: test/java/net/Socks/SocksProxyVersion.java fails when machine name is localhost Reviewed-by: chegar, alanb ! test/java/net/Socks/SocksProxyVersion.java From stefan.karlsson at oracle.com Mon Oct 14 05:15:57 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 14 Oct 2013 14:15:57 +0200 Subject: Review request: 7196801: NPG: Fix java/lang/management/MemoryMXBean/LowMemoryTest2 In-Reply-To: <8A5A63F3-597C-4894-9A12-83069C239426@oracle.com> References: <52583650.6060700@oracle.com> <52583905.8090403@oracle.com> <52583D47.4000803@oracle.com> <8A5A63F3-597C-4894-9A12-83069C239426@oracle.com> Message-ID: <525BE07D.40607@oracle.com> On 2013-10-14 09:42, Staffan Larsen wrote: > Looks good! Thanks, Staffan. > But I wonder why there is a shell script involved. Couldn't this be > just a straightforward java file with several @run tags? Probably. I'd rather not change that now. thanks, StefanK > > Thanks, > /Staffan > > On 11 okt 2013, at 20:02, Stefan Karlsson > wrote: > >> On 10/11/13 7:44 PM, Coleen Phillimore wrote: >>> >>> Stefan, >>> >>> I added a check about the count exceeding 1 000 000 because it >>> causes the test to create an invalid class file. With the shell >>> script changes, it won't happen but I would be happy if that check >>> were there so no one ever has to debug this thinking it has a >>> corrupted constant pool again. >> >> OK. I though that was old debugging left-overs. >> >> New webrev: >> http://cr.openjdk.java.net/~stefank/7196801/webrev.01/ >> >> thanks, >> StefanK >> >>> >>> Thanks, >>> Coleen >>> >>> On 10/11/2013 1:33 PM, Stefan Karlsson wrote: >>>> Please, review this test fix. >>>> >>>> http://cr.openjdk.java.net/~stefank/7196801/webrev.00/ >>>> >>>> Most of the fix was implemented by Coleen, I've only done some >>>> small tweaks and updated some comments. >>>> >>>> The fix depends on these changes: >>>> JDK-8025996 Track metaspace usage when metaspace is expanded >>>> JDK-8024547 MaxMetaspaceSize should limit the committed memory >>>> used by the metaspaces >>>> >>>> Both of these changesets have been pushed to hotspot-gc and are >>>> currently undergoing testing. LowMemoryTest2 can only be removed >>>> from the test/ProblemList.txt when both JDK-8025996 and JDK-8024547 >>>> have propagated through all necessary repositories. >>>> >>>> thanks, >>>> StefanK >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131014/6a749aad/attachment.html From erik.gahlin at oracle.com Mon Oct 14 05:44:53 2013 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Mon, 14 Oct 2013 14:44:53 +0200 Subject: RFR: 7105883: JDWP: agent crash if there exists a ThreadGroup with null name Message-ID: <525BE745.3060109@oracle.com> Hi, Could I please have a review of this fix. An empty string is returned if the thread name is null. The protocol should be updated to support INVALID_STRING for the Thread Reference Command <#Error_INVALID_STRING>, but that is a larger effort and probably better to do when fixing other protocol changes. An empty string is better than a crash. Thanks Erik Webrev: http://cr.openjdk.java.net/~egahlin/7105883/ Bug: https://bugs.openjdk.java.net/browse/JDK-7105883 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131014/4c899b54/attachment.html From stefan.karlsson at oracle.com Mon Oct 14 05:40:22 2013 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Mon, 14 Oct 2013 12:40:22 +0000 Subject: hg: jdk8/tl/jdk: 7196801: NPG: Fix java/lang/management/MemoryMXBean/LowMemoryTest2 Message-ID: <20131014124112.178C06237C@hg.openjdk.java.net> Changeset: f15a0087181e Author: stefank Date: 2013-10-14 14:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f15a0087181e 7196801: NPG: Fix java/lang/management/MemoryMXBean/LowMemoryTest2 Reviewed-by: coleenp, sla Contributed-by: stefan.karlsson at oracle.com, coleen.phillimore at oracle.com ! test/java/lang/management/MemoryMXBean/LowMemoryTest2.java ! test/java/lang/management/MemoryMXBean/LowMemoryTest2.sh From jaroslav.bachorik at oracle.com Mon Oct 14 06:06:32 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 14 Oct 2013 15:06:32 +0200 Subject: RFR: 7105883: JDWP: agent crash if there exists a ThreadGroup with null name In-Reply-To: <525BE745.3060109@oracle.com> References: <525BE745.3060109@oracle.com> Message-ID: <525BEC58.3030704@oracle.com> Looks good to me. (not a reviewer) A small nit - in the test the copyright year should be only 2013 (instead of "2003, 2013") -JB- On 14.10.2013 14:44, Erik Gahlin wrote: > Hi, > > Could I please have a review of this fix. > > An empty string is returned if the thread name is null. The protocol > should be updated to support INVALID_STRING for the Thread Reference > Command <#Error_INVALID_STRING>, but that is a larger effort and > probably better to do when fixing other protocol changes. An empty > string is better than a crash. > > Thanks > Erik > > Webrev: > http://cr.openjdk.java.net/~egahlin/7105883/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-7105883 > > From aleksey.timofeev at oracle.com Mon Oct 14 06:11:08 2013 From: aleksey.timofeev at oracle.com (aleksey.timofeev at oracle.com) Date: Mon, 14 Oct 2013 17:11:08 +0400 Subject: Fwd: Re: Fix to 8025925 In-Reply-To: References: Message-ID: <525BED6C.1000507@oracle.com> Hello, Thomas. Did you see this simple diff? -------- Original Message -------- Subject: Re: Fix to 8025925 Date: Wed, 9 Oct 2013 09:04:20 +0200 From: Staffan Larsen To: aleksey.timofeev at oracle.com, Thomas Schatzl CC: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net Looks good to me, but I'd like Thomas' opinion as well. Thanks, /Staffan On 9 okt 2013, at 00:14, aleksey.timofeev at oracle.com wrote: > Hello. > > I prepared a little fix to JDK-8025925 > . Find webrev here > please: > http://cr.openjdk.java.net/~iignatyev/atimofeev/8025925/webrev.00/index.html > > (now it's on open server). Staffan Larsen generously agreed to sponsor > this commit if we conclude everything is OK. Please your provide feedback. > > -- > Best regards, Aleksey Timofeev. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131014/1bab1238/attachment-0001.html From jaroslav.bachorik at oracle.com Mon Oct 14 07:13:33 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 14 Oct 2013 16:13:33 +0200 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <23435103-156B-434F-994C-B6F913EE0364@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> <52556604.3080900@oracle.com> <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> <525622B4.5020606@oracle.com> <52568940.4000704@oracle.com> <23435103-156B-434F-994C-B6F913EE0364@oracle.com> Message-ID: <525BFC0D.8090101@oracle.com> On 10.10.2013 13:15, Staffan Larsen wrote: > > On 10 okt 2013, at 13:02, Jaroslav Bachorik wrote: > >> On 10.10.2013 05:44, David Holmes wrote: >>> On 10/10/2013 4:12 AM, Staffan Larsen wrote: >>>> >>>> On 9 okt 2013, at 16:19, Jaroslav Bachorik >>>> wrote: >>>> >>>>> On 9.10.2013 16:10, Staffan Larsen wrote: >>>>>> There is now an awful amount of different timestamps in the >>>>>> Management class. Can they be consolidated somehow? At least >>>>>> _begin_vm_creation_time and the new _begin_vm_creation_ns. >>>>>> >>>>>> This discussion also implies that the "elapsed time" we print in the >>>>>> hs_err file is also wrong. It uses os::elapsedTime() which uses >>>>>> os::elapsed_counter(). >>>>>> >>>>>> And I guess the same thing for the VM.uptime Diagnostic Command >>>>>> (class VMUptimeDCmd) which also relies on os::elapsed_counter(). >>>>> >>>>> Also the reported GC pauses duration might be wrong since it uses >>>>> Management::timestamp(). >>>>> >>>>> On the first sight the change looks rather trivial. But, honestly, >>>>> I'm not sure which other parts could for whatever reason break once >>>>> the time-of-day timestamp is replaced with a monotonic equivalent. >>>>> One would think that it shouldn't matter but one never knows ... >>>>> >>>>> Staffan, do you think this kind of change is suitable for the current >>>>> phase of JDK release cycle? I think I could improve the patch in few >>>>> days and then it should probably be able to pass the review before >>>>> ZBB. But, it's only P3 ... >>>> >>>> I think it is a bit late in the release cycle to clean this up in the >>>> way it should be cleaned up. I think we should wait until the first 8 >>>> update release and do a more thorough job than we have time for right >>>> now. >>> >>> I second that. The elapsed_counter/elpased_timer APIs and >>> implementations are a tangled mess. But part of the problem has been >>> that people want/expect monotonic time-of-day based timestamps (yes a >>> contradiction - though some people make sure TOD does not get modified >>> on their production systems). The use of timestamps in logging has to be >>> examined carefully - mainly GC logging. I recall a "simple" attempted >>> change in the past that resulted in trying to compare a nanoTime based >>> timestamp with the TOD. :( >> >> Actually, if I'm reading the sources right for Solaris and Win the monotonic clock source is used to provide elapsed_counter() value. It falls back to TOD when the monotonic clock source is not available. >> For Linux/BSD the TOD is used directly. >> >> This makes me wonder if changing the linux/bsd implementation to follow the same logic would be really that disruptive. > > Good point. I would like a world where elapsed_counter is monotonic (where possible). Still a bit scary this late in the release, but an interesting experiment. The change is rather simple and tests ok. All the means to get a monotonic timestamp are already there and proved to work. The core tests in JPRT went fine. The updated webrev is at http://cr.openjdk.java.net/~jbachorik/6523160/webrev.02 -JB- > > /Staffan > > > > >> >> -JB- >>> >>> David >>> ----- >>> >>>> /Staffan >>>> >>>> >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> /Staffan >>>>>> >>>>>> >>>>>> On 9 okt 2013, at 13:26, Jaroslav Bachorik >>>>>> wrote: >>>>>> >>>>>>> On 8.10.2013 23:46, David Holmes wrote: >>>>>>>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>>>>>>> On 8.10.2013 09:34, David Holmes wrote: >>>>>>>>>> Jaroslav, >>>>>>>>>> >>>>>>>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> currently the JVM uptime reported by the RuntimeMXBean is based on >>>>>>>>>>> System.currentTimeMillis() which makes it susceptible to >>>>>>>>>>> changes of the >>>>>>>>>>> OS time (eg. changing timezone, NTP synchronization etc.). The >>>>>>>>>>> uptime >>>>>>>>>>> should not depend on the system time and should be calculated >>>>>>>>>>> using a >>>>>>>>>>> monotonic clock source. >>>>>>>>>>> >>>>>>>>>>> There is already the way to get the actual JVM uptime in ticks. >>>>>>>>>>> It is >>>>>>>>>>> accessible as Management::timestamp() and the ticks are >>>>>>>>>>> convertible to >>>>>>>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus >>>>>>>>>>> making it >>>>>>>>>>> very >>>>>>>>>>> easy to switch to the monotonic clock based uptime. >>>>>>>>>> >>>>>>>>>> Maybe I'm missing something but TiumeStamp updates using >>>>>>>>>> os::elapsed_counter() which on Linux uses gettimeofday so is not a >>>>>>>>>> monotonic clock source. >>>>>>>>> >>>>>>>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>>>>>>> >>>>>>>>> Is there any reason why a non monotonic clock source is used for >>>>>>>>> timestamping except of the historical one? os::javaTimeNanos() uses >>>>>>>>> montonic clock when available - why can't be the same used for >>>>>>>>> os::elapsed_counter() especially when a counter based on >>>>>>>>> "gettimeofday" >>>>>>>>> is not really a counter? >>>>>>>> >>>>>>>> It is all historical. These elapsed_counters and elapsed_timers >>>>>>>> make me >>>>>>>> cringe. But changing it has a lot of potential consequences >>>>>>>> because of >>>>>>>> the way these are used in logging etc. Certainly not something to be >>>>>>>> contemplated at this stage of JDK 8. >>>>>>>> >>>>>>>> Perhaps a simpler fix here is to expose a startUpTimeNanos that >>>>>>>> can then >>>>>>>> be used for the uptime. >>>>>>> >>>>>>> My attempt at this is at >>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >>>>>>> I am using os::javaTimeNanos() to get the monotonic ticks where >>>>>>> possible. >>>>>>> >>>>>>> The JDK part stays the same as for webrev.00 >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> The patch consists of the hotspot and jdk parts. >>>>>>>>>>> >>>>>>>>>>> For the hotspot a new constant needs to be introduced in >>>>>>>>>>> src/share/vm/services/jmm.h and the actual logic to obtain the >>>>>>>>>>> uptime in >>>>>>>>>>> milliseconds is added in src/share/vm/services/management.cpp. >>>>>>>>>>> >>>>>>>>>>> For the jdk the changes comprise of adding the necessary JNI >>>>>>>>>>> bridging >>>>>>>>>>> methods in order to get the new uptime, introducing the same >>>>>>>>>>> constant >>>>>>>>>>> that is used in hotspot and changes to mapfile-vers files in >>>>>>>>>>> order to >>>>>>>>>>> properly build the native library. >>>>>>>>>>> >>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > From thomas.schatzl at oracle.com Mon Oct 14 08:18:12 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 14 Oct 2013 17:18:12 +0200 Subject: Fwd: Re: Fix to 8025925 In-Reply-To: <525BED6C.1000507@oracle.com> References: <525BED6C.1000507@oracle.com> Message-ID: <1381763892.2715.96.camel@cirrus> Hi, On Mon, 2013-10-14 at 17:11 +0400, aleksey.timofeev at oracle.com wrote: > Hello, Thomas. Did you see this simple diff? no :) I am not on servicability-dev. Thanks for making me aware of this. > Looks good to me, but I'd like Thomas' opinion as well. > > Thanks, > /Staffan > > On 9 okt 2013, at 00:14, aleksey.timofeev at oracle.com wrote: > > > Hello. > > > > I prepared a little fix to JDK-8025925. Find webrev here please: > > http://cr.openjdk.java.net/~iignatyev/atimofeev/8025925/webrev.00/index.html (now it's on open server). Staffan Larsen generously agreed to sponsor this commit if we conclude everything is OK. Please your provide feedback. I do not think that the issue is fixed by that change; while it compiles and makes it run, it will get the wrong values. In JDK-7163191 I replaced the _regions field with an inlined class. My current patch can be found at http://cr.openjdk.java.net/~tschatzl/8025925/webrev/ I am still testing it - after applying this change the test passes again - but I have never used the SA agent before so I am currently working to find out how to verify that the numbers are okay too :) Thomas From daniel.daugherty at oracle.com Mon Oct 14 08:18:24 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 14 Oct 2013 09:18:24 -0600 Subject: code review round 1 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <525B4FA1.7020109@oracle.com> References: <52585F31.5040107@oracle.com> <525B4FA1.7020109@oracle.com> Message-ID: <525C0B40.40109@oracle.com> Thanks for the re-review! On 10/13/13 7:57 PM, David Holmes wrote: > Hi Dan, > > Only further comment I have, and it may well be deferred for future > work, is that we should be able to abstract away the actual > "extension" used for the "debuginfo" file so that we don't need macosx > conditionals as much eg one: > > if macosx > DEBUGINFO_EXTENSION=dSYM > else > DEBUGINFO_EXTENSION=debuginfo > endif > > then eg: > > JSIG_DEBUGINFO := $(strip $(wildcard > $(HOTSPOT_DIST)/jre/lib$(OPENJDK_TARGET_CPU_LIBDIR)/libjsig.$DEBUGINFO_EXTENSION) > \ > $(wildcard > $(HOTSPOT_DIST)/jre/lib$(OPENJDK_TARGET_CPU_LIBDIR)/libjsig.diz) ) The biggest worry that I have about something like DEBUGINFO_EXTENSION is that on MacOS X the '.dSYM' objects are directories instead of files. This requires that different cmd options be used in many/most/all of the cases. More thought would be needed. > Hmm second comment - I don't see a .m4 file change that corresponds to > the DSYMUTIL configure change ?? Yikes! I'll check into that shortly. Not sure what happened here. Dan > > Thanks, > David > > On 12/10/2013 6:27 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I'm ready for code review round 1 of the FDS on MacOS X hotspot changes. >> Below is the original code review round 0 invite (slightly edited for >> clarity). Working on FDS is like pulling a thread on a sweater... so >> there are four additional changed files along with more changes to >> many of the files from round 0. >> >> Here is the code review round 1 JDK8/HSX-25 webrev URL: >> >> OpenJDK: >> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/1-jdk8/ >> Internal: >> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/1-jdk8/ >> >> Changes from code review round 0 to round 1: >> >> root repo: >> - add configure support for DSYMUTIL macro >> >> hotspot repo: >> - drop Minimal1 config support for FDS on MacOS X >> - use DSYMUTIL macro instead of literal 'dsymutil' >> - fix FASTDEBUG_CFLAGS typo and add USE_CLANG support >> - STRIP is not used on MacOS X >> - fix $(UNIVERSAL_COPY_LIST) rule >> - refine install-dir function >> >> jdk repo: >> - add prep-target-dir, install-import-dir, and >> install-import-debuginfo >> functions >> - support importing .dSYM directories from hotspot >> - create libjsig.dSYM symlink from VM specific directory to >> the real location >> >> Files changed from code review round 0 to round 1: >> >> common/autoconf/generated-configure.sh >> hotspot/make/Makefile >> hotspot/make/bsd/makefiles/defs.make >> hotspot/make/bsd/makefiles/dtrace.make >> hotspot/make/bsd/makefiles/gcc.make >> hotspot/make/bsd/makefiles/jsig.make >> hotspot/make/bsd/makefiles/saproc.make >> hotspot/make/bsd/makefiles/universal.gmk >> hotspot/make/bsd/makefiles/vm.make >> hotspot/make/defs.make >> >> New files changed in code review round 1: >> >> hotspot/make/bsd/makefiles/product.make >> jdk/make/common/Defs.gmk >> jdk/make/java/redist/Makefile >> jdk/makefiles/Import.gmk >> >> Additional bugs filed based on code review comments, testing and >> just plain looking at the Makefiles: >> >> 8026280 implement Full Debug Symbols on MacOS X jdk >> 8026281 hotspot 'jdk6_or_earlier logic' for FDS needs to be removed >> 8026282 the '64' subdir logic in Makefiles might be removable >> 8026283 literal 'lipo' cmd uses in HotSpot makefiles >> 8026284 Minimal1 references/support should be removed from >> BSD/MacOS X >> 8026285 JPRT -buildenv ZIP_DEBUGINFO_FILES=0 no longer works >> >> As always, comments, questions and suggestions are welcome. >> >> Dan >> >> > Greetings, >> > >> > I have the initial support for Full Debug Symbols (FDS) on MacOS X >> done >> > and ready for review: >> > >> > 7165611 implement Full Debug Symbols on MacOS X hotspot >> > https://bugs.openjdk.java.net/browse/JDK-7165611 >> > >> > Here is the JDK8/HSX-25 webrev URL: >> > >> > OpenJDK: >> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >> > Internal: >> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >> > >> > This webrev includes changes for the follow repos: >> > >> > jdk8 >> > jdk8/hotspot >> > jdk8/jdk >> > >> > Once these changes are approved, I'm planning to push them to >> > RT_Baseline. From there, they can follow the normal path to >> > Main_Baseline and eventually JDK8. >> > >> > This work enables FDS on MacOS X for the 'hotspot' repo; the >> changes in >> > the other repos are necessary to support importing the .diz files >> from >> > the MacOS X 'hotspot' build into the forest build. I also fixed a few >> > FDS related errors in the magic incantations for the new build. >> This is >> > mostly a port from Linux -> MacOS X/BSD with the dtrace changes >> ported >> > from Solaris. In other words, this is Frankenstein's monster... >> > >> > Thanks to Staffan Larsen for providing an initial set of changes >> > which I morphed into what you see here. >> > >> > Testing: >> > - JPRT HSX build and test on all platforms; verification of .diz >> > files in the MacOS X JPRT bundles >> > - JPRT JDK8 forest build and test on all platforms; verification of >> > .diz files in the MacOS X JPRT bundles >> > Note: In previous FDS changesets, I also did a standalone 'jdk' >> > repo build and test, but that no longer seems to work. >> > >> > As always, comments, questions and suggestions are welcome. >> > >> > Dan From jaroslav.bachorik at oracle.com Mon Oct 14 08:21:52 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 14 Oct 2013 17:21:52 +0200 Subject: RFR: 6804470 JvmstatCountersTest.java test times out on slower machines Message-ID: <525C0C10.7000104@oracle.com> Please, review the following simple change. The test times out on slower machines and I was able to reproduce the failure even on a normally fast machine using the fastdebug build. The timeout does not occur on every run - more like once in 10-15 runs. There is nothing really wrong with the test - it just takes rather long time to obtain the jvmstat counters. The remedy is to specify a longer timeout and see if it is enough. I am using 10 minutes for the timeout in the patch. Issue : https://bugs.openjdk.java.net/browse/JDK-6804470 Webrev: http://cr.openjdk.java.net/~jbachorik/6804470/webrev.00 Thanks, -JB- From daniel.daugherty at oracle.com Mon Oct 14 08:52:16 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 14 Oct 2013 09:52:16 -0600 Subject: code review round 1 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <525C0B40.40109@oracle.com> References: <52585F31.5040107@oracle.com> <525B4FA1.7020109@oracle.com> <525C0B40.40109@oracle.com> Message-ID: <525C1330.2000407@oracle.com> On 10/14/13 9:18 AM, Daniel D. Daugherty wrote: > On 10/13/13 7:57 PM, David Holmes wrote: > >> Hmm second comment - I don't see a .m4 file change that corresponds >> to the DSYMUTIL configure change ?? > > Yikes! I'll check into that shortly. Not sure what happened here. I somehow missed/lost two 1-liner changes: hg diff common/autoconf/basics.m4 common/autoconf/spec.gmk.in diff -r 4faa09c7fe55 common/autoconf/basics.m4 --- a/common/autoconf/basics.m4 Wed Oct 02 15:08:03 2013 +0200 +++ b/common/autoconf/basics.m4 Mon Oct 14 08:49:37 2013 -0700 @@ -644,6 +644,7 @@ fi fi if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then + BASIC_REQUIRE_PROG(DSYMUTIL, dsymutil) BASIC_REQUIRE_PROG(XATTR, xattr) AC_PATH_PROG(CODESIGN, codesign) if test "x$CODESIGN" != "x"; then diff -r 4faa09c7fe55 common/autoconf/spec.gmk.in --- a/common/autoconf/spec.gmk.in Wed Oct 02 15:08:03 2013 +0200 +++ b/common/autoconf/spec.gmk.in Mon Oct 14 08:49:37 2013 -0700 @@ -484,6 +484,7 @@ DATE:=@DATE@ DATE:=@DATE@ DIFF:=@DIFF@ DIRNAME:=@DIRNAME@ +DSYMUTIL:=@DSYMUTIL@ FIND:=@FIND@ FIND_DELETE:=@FIND_DELETE@ ECHO:=@ECHO@ I don't think that these two 1-liners are worth re-rolling the webrev. Please let me know if you don't agree. Dan > > Dan > > >> >> Thanks, >> David >> >> On 12/10/2013 6:27 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I'm ready for code review round 1 of the FDS on MacOS X hotspot >>> changes. >>> Below is the original code review round 0 invite (slightly edited for >>> clarity). Working on FDS is like pulling a thread on a sweater... so >>> there are four additional changed files along with more changes to >>> many of the files from round 0. >>> >>> Here is the code review round 1 JDK8/HSX-25 webrev URL: >>> >>> OpenJDK: >>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/1-jdk8/ >>> Internal: >>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/1-jdk8/ >>> >>> >>> Changes from code review round 0 to round 1: >>> >>> root repo: >>> - add configure support for DSYMUTIL macro >>> >>> hotspot repo: >>> - drop Minimal1 config support for FDS on MacOS X >>> - use DSYMUTIL macro instead of literal 'dsymutil' >>> - fix FASTDEBUG_CFLAGS typo and add USE_CLANG support >>> - STRIP is not used on MacOS X >>> - fix $(UNIVERSAL_COPY_LIST) rule >>> - refine install-dir function >>> >>> jdk repo: >>> - add prep-target-dir, install-import-dir, and >>> install-import-debuginfo >>> functions >>> - support importing .dSYM directories from hotspot >>> - create libjsig.dSYM symlink from VM specific directory to >>> the real location >>> >>> Files changed from code review round 0 to round 1: >>> >>> common/autoconf/generated-configure.sh >>> hotspot/make/Makefile >>> hotspot/make/bsd/makefiles/defs.make >>> hotspot/make/bsd/makefiles/dtrace.make >>> hotspot/make/bsd/makefiles/gcc.make >>> hotspot/make/bsd/makefiles/jsig.make >>> hotspot/make/bsd/makefiles/saproc.make >>> hotspot/make/bsd/makefiles/universal.gmk >>> hotspot/make/bsd/makefiles/vm.make >>> hotspot/make/defs.make >>> >>> New files changed in code review round 1: >>> >>> hotspot/make/bsd/makefiles/product.make >>> jdk/make/common/Defs.gmk >>> jdk/make/java/redist/Makefile >>> jdk/makefiles/Import.gmk >>> >>> Additional bugs filed based on code review comments, testing and >>> just plain looking at the Makefiles: >>> >>> 8026280 implement Full Debug Symbols on MacOS X jdk >>> 8026281 hotspot 'jdk6_or_earlier logic' for FDS needs to be >>> removed >>> 8026282 the '64' subdir logic in Makefiles might be removable >>> 8026283 literal 'lipo' cmd uses in HotSpot makefiles >>> 8026284 Minimal1 references/support should be removed from >>> BSD/MacOS X >>> 8026285 JPRT -buildenv ZIP_DEBUGINFO_FILES=0 no longer works >>> >>> As always, comments, questions and suggestions are welcome. >>> >>> Dan >>> >>> > Greetings, >>> > >>> > I have the initial support for Full Debug Symbols (FDS) on MacOS >>> X done >>> > and ready for review: >>> > >>> > 7165611 implement Full Debug Symbols on MacOS X hotspot >>> > https://bugs.openjdk.java.net/browse/JDK-7165611 >>> > >>> > Here is the JDK8/HSX-25 webrev URL: >>> > >>> > OpenJDK: >>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >>> > Internal: >>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >>> >>> > >>> > This webrev includes changes for the follow repos: >>> > >>> > jdk8 >>> > jdk8/hotspot >>> > jdk8/jdk >>> > >>> > Once these changes are approved, I'm planning to push them to >>> > RT_Baseline. From there, they can follow the normal path to >>> > Main_Baseline and eventually JDK8. >>> > >>> > This work enables FDS on MacOS X for the 'hotspot' repo; the >>> changes in >>> > the other repos are necessary to support importing the .diz files >>> from >>> > the MacOS X 'hotspot' build into the forest build. I also fixed a >>> few >>> > FDS related errors in the magic incantations for the new build. >>> This is >>> > mostly a port from Linux -> MacOS X/BSD with the dtrace changes >>> ported >>> > from Solaris. In other words, this is Frankenstein's monster... >>> > >>> > Thanks to Staffan Larsen for providing an initial set of changes >>> > which I morphed into what you see here. >>> > >>> > Testing: >>> > - JPRT HSX build and test on all platforms; verification of .diz >>> > files in the MacOS X JPRT bundles >>> > - JPRT JDK8 forest build and test on all platforms; verification of >>> > .diz files in the MacOS X JPRT bundles >>> > Note: In previous FDS changesets, I also did a standalone 'jdk' >>> > repo build and test, but that no longer seems to work. >>> > >>> > As always, comments, questions and suggestions are welcome. >>> > >>> > Dan > > From Alan.Bateman at oracle.com Mon Oct 14 11:11:25 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Oct 2013 19:11:25 +0100 Subject: RFR: 6804470 JvmstatCountersTest.java test times out on slower machines In-Reply-To: <525C0C10.7000104@oracle.com> References: <525C0C10.7000104@oracle.com> Message-ID: <525C33CD.4010505@oracle.com> On 14/10/2013 16:21, Jaroslav Bachorik wrote: > Please, review the following simple change. > > The test times out on slower machines and I was able to reproduce the > failure even on a normally fast machine using the fastdebug build. The > timeout does not occur on every run - more like once in 10-15 runs. > > There is nothing really wrong with the test - it just takes rather > long time to obtain the jvmstat counters. The remedy is to specify a > longer timeout and see if it is enough. I am using 10 minutes for the > timeout in the patch. > > Issue : https://bugs.openjdk.java.net/browse/JDK-6804470 > Webrev: http://cr.openjdk.java.net/~jbachorik/6804470/webrev.00 > > Thanks, > > -JB- This looks okay to me but if someone is testing a fastdebug build then they really need to specify the -timeoutFactor option to jtreg so as to scale the timeouts. -Alan. From lana.steuck at oracle.com Mon Oct 14 11:47:32 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 14 Oct 2013 18:47:32 +0000 Subject: hg: jdk8/tl/jaxp: 4 new changesets Message-ID: <20131014184751.C582862391@hg.openjdk.java.net> Changeset: d69f4ac43d64 Author: lana Date: 2013-10-08 14:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d69f4ac43d64 Merge Changeset: cdc3577cba0b Author: lana Date: 2013-10-11 00:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/cdc3577cba0b Merge Changeset: 4712979714d1 Author: lana Date: 2013-10-11 21:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/4712979714d1 Merge Changeset: 91ae0f2045bc Author: lana Date: 2013-10-14 09:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/91ae0f2045bc Merge From lana.steuck at oracle.com Mon Oct 14 11:47:44 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 14 Oct 2013 18:47:44 +0000 Subject: hg: jdk8/tl/nashorn: 3 new changesets Message-ID: <20131014184753.2CCFC62393@hg.openjdk.java.net> Changeset: 3551855c4f40 Author: lana Date: 2013-10-08 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/3551855c4f40 Merge - make/java.security.override Changeset: b48b719c5efc Author: lana Date: 2013-10-11 03:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b48b719c5efc Merge - make/java.security.override Changeset: 1b0a71a9920a Author: lana Date: 2013-10-11 23:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1b0a71a9920a Merge From lana.steuck at oracle.com Mon Oct 14 11:47:57 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 14 Oct 2013 18:47:57 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20131014184806.311CC62394@hg.openjdk.java.net> Changeset: 4dfcf3a6902f Author: lana Date: 2013-10-08 14:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4dfcf3a6902f Merge - src/share/classes/jdk/Supported.java - test/tools/javac/generics/OverrideBridge.java Changeset: 2f43529df42f Author: lana Date: 2013-10-11 03:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2f43529df42f Merge - src/share/classes/jdk/Supported.java - test/tools/javac/generics/OverrideBridge.java Changeset: f329c374da4b Author: lana Date: 2013-10-11 23:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f329c374da4b Merge From lana.steuck at oracle.com Mon Oct 14 11:47:36 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 14 Oct 2013 18:47:36 +0000 Subject: hg: jdk8/tl/jaxws: 3 new changesets Message-ID: <20131014184752.2548F62392@hg.openjdk.java.net> Changeset: 1d6c13d3b8de Author: lana Date: 2013-10-08 14:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/1d6c13d3b8de Merge Changeset: 7c0a7937f6ef Author: lana Date: 2013-10-11 00:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/7c0a7937f6ef Merge Changeset: 328b8b96773b Author: lana Date: 2013-10-11 21:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/328b8b96773b Merge From lana.steuck at oracle.com Mon Oct 14 11:47:22 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 14 Oct 2013 18:47:22 +0000 Subject: hg: jdk8/tl: 3 new changesets Message-ID: <20131014184724.A016E6238F@hg.openjdk.java.net> Changeset: 7c0e2fd8be4d Author: lana Date: 2013-10-08 14:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7c0e2fd8be4d Merge Changeset: 3ece65f23ed2 Author: lana Date: 2013-10-11 00:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3ece65f23ed2 Merge Changeset: d35943431696 Author: lana Date: 2013-10-11 21:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d35943431696 Merge From jonathan.gibbons at oracle.com Mon Oct 14 12:38:46 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 14 Oct 2013 19:38:46 +0000 Subject: hg: jdk8/tl/langtools: 8026368: doclint does not report empty tags when tag closed implicitly Message-ID: <20131014193849.5D63A6239B@hg.openjdk.java.net> Changeset: b024fe427d24 Author: jjg Date: 2013-10-14 12:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b024fe427d24 8026368: doclint does not report empty tags when tag closed implicitly Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java ! test/tools/doclint/HtmlAttrsTest.java ! test/tools/doclint/HtmlAttrsTest.out ! test/tools/doclint/tidy/BadEnd.out ! test/tools/doclint/tidy/TrimmingEmptyTag.java ! test/tools/doclint/tidy/TrimmingEmptyTag.out From lana.steuck at oracle.com Mon Oct 14 11:50:33 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 14 Oct 2013 18:50:33 +0000 Subject: hg: jdk8/tl/jdk: 63 new changesets Message-ID: <20131014190553.ABDF662395@hg.openjdk.java.net> Changeset: 8a041011b6e6 Author: jgodinez Date: 2013-09-27 13:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a041011b6e6 6870661: Setting a custom PrintService on a PrinterJob leads to a PrinterException Reviewed-by: prr, jgodinez Contributed-by: patrick at reini.net ! src/windows/classes/sun/awt/windows/WPrinterJob.java + test/java/awt/print/PrinterJob/CustomPrintService/PrintDialog.java + test/java/awt/print/PrinterJob/CustomPrintService/PrintServiceStub.java + test/java/awt/print/PrinterJob/CustomPrintService/SetPrintServiceTest.java Changeset: 31b8d4931a09 Author: prr Date: 2013-09-27 13:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31b8d4931a09 8020190: Fatal: Bug in native code: jfieldID must match object Reviewed-by: jgodinez, vadim ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/native/sun/font/freetypeScaler.c Changeset: 6ef33b4553a4 Author: vadim Date: 2013-09-30 12:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ef33b4553a4 8001119: [fingbugs] Evaluate necessity to make some arrays package protected Reviewed-by: prr, bae + src/share/classes/com/sun/imageio/plugins/bmp/BMPCompressionTypes.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPConstants.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFStreamMetadata.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEG.java ! src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java ! src/share/classes/javax/imageio/plugins/bmp/BMPImageWriteParam.java Changeset: e2604b873b36 Author: prr Date: 2013-10-01 15:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2604b873b36 8007386: On physical machine (video card is Intel Q45) the text is blank. Reviewed-by: prr, jchen ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 96ff585555f4 Author: vadim Date: 2013-10-02 10:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/96ff585555f4 8024343: Change different color with the "The XOR alternation color" combobox, the color of the image can not shown immediately. Reviewed-by: ceisserer, prr, bae ! src/solaris/classes/sun/java2d/xr/XRSurfaceData.java + test/sun/java2d/AcceleratedXORModeTest.java Changeset: 5f3d984d8207 Author: prr Date: 2013-10-02 11:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5f3d984d8207 8025837: Extraneous changes in the fix for 8007386 Reviewed-by: jgodinez, jchen ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: f53aeb3c7eed Author: prr Date: 2013-10-02 11:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f53aeb3c7eed 7179526: xrender : closed/sun/java2d/volatileImage/LineClipTest.java failed since jdk8b36 Reviewed-by: prr, jchen ! src/solaris/classes/sun/java2d/xr/GrowableRectArray.java ! src/solaris/classes/sun/java2d/xr/MaskTile.java ! src/solaris/classes/sun/java2d/xr/MaskTileManager.java + src/solaris/classes/sun/java2d/xr/XRDrawLine.java ! src/solaris/classes/sun/java2d/xr/XRRenderer.java + test/java/awt/Graphics/LineClipTest.java Changeset: a15cad0e12d3 Author: bae Date: 2013-10-03 11:28 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a15cad0e12d3 8022632: Reading a PNG file fails because of WBMPImageReaderSpi.canDecodeInput() Reviewed-by: prr, jgodinez ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java + test/javax/imageio/plugins/wbmp/StreamResetTest.java Changeset: 2f11a00279ec Author: jchen Date: 2013-10-03 13:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2f11a00279ec 8025280: [parfait] warnings from b107 for jdk.src.share.native.sun.java2d.loops: JNI exception pending, JNI critical region violation Reviewed-by: prr, jgodinez ! src/share/native/sun/java2d/loops/Blit.c ! src/share/native/sun/java2d/loops/BlitBg.c ! src/share/native/sun/java2d/loops/DrawPath.c ! src/share/native/sun/java2d/loops/DrawPolygons.c ! src/share/native/sun/java2d/loops/FillPath.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c ! src/share/native/sun/java2d/loops/MaskBlit.c ! src/share/native/sun/java2d/loops/MaskFill.c ! src/share/native/sun/java2d/loops/ScaledBlit.c ! src/share/native/sun/java2d/loops/TransformHelper.c Changeset: e88d39b110dd Author: jchen Date: 2013-10-03 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e88d39b110dd 8025480: [parfait] "JNI exception pending" warnings from b107 for jdk.src.share.native.sun.java2d Reviewed-by: prr, jgodinez ! src/share/native/sun/java2d/Disposer.c ! src/share/native/sun/java2d/SurfaceData.c Changeset: 3c1b13ad0677 Author: jchen Date: 2013-10-03 13:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c1b13ad0677 8025309: [parfait] JNI-related warnings from b107 for jdk.src.share.native.sun.java2d.pipe Reviewed-by: prr, jgodinez ! src/share/native/sun/java2d/pipe/BufferedRenderPipe.c ! src/share/native/sun/java2d/pipe/Region.c ! src/share/native/sun/java2d/pipe/ShapeSpanIterator.c ! src/share/native/sun/java2d/pipe/SpanClipRenderer.c Changeset: d37594b689ce Author: jchen Date: 2013-10-03 13:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d37594b689ce 8025664: [parfait] warnings from b62 for jdk.src.share.native.sun.font Reviewed-by: prr, jgodinez ! src/share/native/sun/font/freetypeScaler.c Changeset: 0ed939dc4230 Author: jchen Date: 2013-10-03 13:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ed939dc4230 8025294: [parfait] JNI-related warnings from b107 for jdk.src.solaris.native.sun.java2d.x11 Reviewed-by: prr, jgodinez ! src/solaris/native/sun/java2d/x11/X11Renderer.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/solaris/native/sun/java2d/x11/XRBackendNative.c ! src/solaris/native/sun/java2d/x11/XRSurfaceData.c Changeset: 8fd757f31470 Author: jchen Date: 2013-10-04 16:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8fd757f31470 8025940: Windows build fails after the fix for 8025280 Reviewed-by: prr, jgodinez ! src/share/native/sun/java2d/loops/MaskBlit.c Changeset: 727b60f9c09c Author: lana Date: 2013-10-08 14:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/727b60f9c09c Merge Changeset: e4e151f6ae50 Author: yan Date: 2013-09-27 12:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4e151f6ae50 8025249: [javadoc] fix some javadoc errors in javax/swing/ Reviewed-by: alexsch, yan Contributed-by: Taras Ledkov ! src/share/classes/javax/swing/border/CompoundBorder.java ! src/share/classes/javax/swing/colorchooser/AbstractColorChooserPanel.java ! src/share/classes/javax/swing/event/CaretEvent.java ! src/share/classes/javax/swing/event/DocumentEvent.java ! src/share/classes/javax/swing/event/EventListenerList.java ! src/share/classes/javax/swing/event/ListDataEvent.java ! src/share/classes/javax/swing/event/TreeModelEvent.java ! src/share/classes/javax/swing/filechooser/FileView.java ! src/share/classes/javax/swing/table/DefaultTableCellRenderer.java ! src/share/classes/javax/swing/table/DefaultTableModel.java ! src/share/classes/javax/swing/table/JTableHeader.java ! src/share/classes/javax/swing/table/TableCellRenderer.java ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/AbstractWriter.java ! src/share/classes/javax/swing/text/AsyncBoxView.java ! src/share/classes/javax/swing/text/AttributeSet.java ! src/share/classes/javax/swing/text/Document.java ! src/share/classes/javax/swing/text/Element.java ! src/share/classes/javax/swing/text/View.java Changeset: ca45169cb4eb Author: pchelko Date: 2013-09-27 14:29 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca45169cb4eb 8024122: [TEST] need test to cover JDK-7146572 Reviewed-by: anthony, yan Contributed-by: Alexander Stepanov + test/java/awt/InputMethods/InputMethodsTest/InputMethodsTest.html + test/java/awt/InputMethods/InputMethodsTest/InputMethodsTest.java Changeset: ad7db846c951 Author: pchelko Date: 2013-09-27 17:04 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad7db846c951 8025503: [macosx] FileDialog allows file selection with apple.awt.fileDialogForDirectories = true Reviewed-by: serb, anthony ! src/macosx/native/sun/awt/CFileDialog.m Changeset: 260bc59ca253 Author: pchelko Date: 2013-09-27 18:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/260bc59ca253 8016563: Test closed/java/awt/dnd/ImageTransferTest/ImageTransferTest.html fails Reviewed-by: anthony, serb ! src/share/classes/sun/awt/datatransfer/DataTransferer.java Changeset: bfff9e9120ec Author: malenkov Date: 2013-09-27 22:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bfff9e9120ec 8012716: java.beans.EventHandler.create method should check if the given listenerInterface is a public interface Reviewed-by: art, mchung ! src/share/classes/java/beans/EventHandler.java Changeset: 0042f54f65d0 Author: malenkov Date: 2013-09-27 22:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0042f54f65d0 7117595: ArrayIndexOutOfBoundsException in Win32GraphicsEnvironment if display is removed Reviewed-by: anthony, serb ! src/macosx/classes/sun/awt/CGraphicsEnvironment.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java Changeset: 603cd3cefbb0 Author: malenkov Date: 2013-09-30 22:08 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/603cd3cefbb0 8025652: [macos] build failed Reviewed-by: serb ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java Changeset: cdfa2301a291 Author: serb Date: 2013-10-01 04:29 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdfa2301a291 7150100: [macosx] "0123456789" is selected in the TextField Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java ! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java + test/java/awt/TextArea/SelectionVisible/SelectionVisible.html + test/java/awt/TextArea/SelectionVisible/SelectionVisible.java + test/java/awt/TextField/SelectionVisible/SelectionVisible.html + test/java/awt/TextField/SelectionVisible/SelectionVisible.java Changeset: 2d8418d68a3c Author: kshefov Date: 2013-10-01 13:19 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2d8418d68a3c 7125471: [macosx] NofocusListDblClickTest should wait between doublr clicks Reviewed-by: anthony, serb Contributed-by: vera.akulova at oracle.com + test/java/awt/List/NofocusListDblClickTest/NofocusListDblClickTest.java Changeset: 329011aad090 Author: kshefov Date: 2013-10-01 13:30 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/329011aad090 8012468: [TEST_BUG] javax/swing/PopupFactory/6276087/NonOpaquePopupMenuTest.java doesn't release mouse button Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com ! test/javax/swing/PopupFactory/6276087/NonOpaquePopupMenuTest.java Changeset: 0887aad989fb Author: kshefov Date: 2013-10-01 13:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0887aad989fb 8012466: [TEST_BUG] javax/swing/JInternalFrame/Test6505027.java doesn't release mouse button Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com ! test/javax/swing/JInternalFrame/Test6505027.java Changeset: 1043bd1f7fca Author: kshefov Date: 2013-10-01 13:40 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1043bd1f7fca 8004294: [TEST_BUG] javax/swing/JSpinner/4973721/bug4973721.java failed on win2003 Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/JSpinner/4973721/bug4973721.java Changeset: 68157255f3eb Author: kshefov Date: 2013-10-01 13:45 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68157255f3eb 8012461: [TEST_BUG] closed/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java doesn't release mouse button Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java + test/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.xml Changeset: 172405287fde Author: kshefov Date: 2013-10-01 13:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/172405287fde 7133545: [macosx] closed/javax/swing/JSplitPane/4514858/bug4514858.java fails on MacOS Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/JSplitPane/4514858/bug4514858.java Changeset: 291e66f4cb83 Author: kshefov Date: 2013-10-01 13:47 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/291e66f4cb83 7133532: [macosx] closed/javax/swing/JScrollBar/bug4202954/bug4202954.java fails on MacOS Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/JScrollBar/bug4202954/bug4202954.java Changeset: 560ede42bd2e Author: kshefov Date: 2013-10-01 14:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/560ede42bd2e 8025707: Frogot to add a file to fix for JDK-8012461 Reviewed-by: serb, alexsch Contributed-by: vera.akulova at oracle.com + test/javax/swing/plaf/synth/SynthButtonUI/6276188/red.gif Changeset: a0c28e64c049 Author: alitvinov Date: 2013-10-01 18:40 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a0c28e64c049 8025145: [macosx]: java 7 does not recognize tiff image on clipboard Reviewed-by: anthony, serb Contributed-by: anton.nashatyrev at oracle.com ! src/macosx/lib/flavormap.properties Changeset: 5e205645d990 Author: pchelko Date: 2013-10-02 11:18 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e205645d990 7124363: [macosx] ClassCastException: CFileDialog cannot be cast to LWWindowPeer Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/LWWindowPeer.java Changeset: 1189f954d52f Author: pchelko Date: 2013-10-02 11:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1189f954d52f 8024163: [macosx] NullPointerException at javax.swing.TransferHandler$DropHandler.handleDrag since jdk8b93, 7u40b28 Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/macosx/CDropTargetContextPeer.java ! src/macosx/native/sun/awt/CDropTarget.m + test/java/awt/dnd/DropTargetEnterExitTest/ExtraDragEnterTest.java + test/java/awt/dnd/DropTargetEnterExitTest/MissedDragExitTest.java Changeset: 01198c681710 Author: pchelko Date: 2013-10-02 11:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01198c681710 8024600: [macosx] code prevents use of -Xlint:auxiliaryclass,empty in jdk build Reviewed-by: anthony, serb ! src/macosx/classes/com/apple/eawt/_AppEventLegacyHandler.java + src/macosx/classes/com/apple/eawt/_OpenAppHandler.java ! src/macosx/classes/com/apple/laf/AquaComboBoxRenderer.java + src/macosx/classes/com/apple/laf/AquaComboBoxRendererInternal.java ! src/macosx/classes/com/apple/laf/AquaMenuBarUI.java Changeset: 287e0a7731ff Author: pchelko Date: 2013-10-02 16:58 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/287e0a7731ff 8024158: [macosx] java/awt/EventDispatchThread/LoopRobustness/LoopRobustness still failed after fix JDK-8022247; since jdk8b96 Reviewed-by: art, leonidr ! src/macosx/classes/sun/lwawt/LWWindowPeer.java Changeset: 244f2ee51f31 Author: leonidr Date: 2013-10-02 17:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/244f2ee51f31 8023994: Right click on the icon added to the system tray for the first time, java.lang.IllegalArgumentException thrown. Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java Changeset: f40f2421c60f Author: serb Date: 2013-10-02 21:02 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f40f2421c60f 8013563: Memory leak in JFrame on Linux Reviewed-by: anthony, art ! src/share/classes/java/awt/Window.java + test/java/awt/Window/WindowsLeak/WindowsLeak.java Changeset: 1da5d306e84b Author: cl Date: 2013-10-02 11:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1da5d306e84b 8025409: Fix javadoc comments errors and warning reported by doclint report Reviewed-by: anthony, yan ! src/share/classes/java/awt/BorderLayout.java ! src/share/classes/java/awt/Button.java ! src/share/classes/java/awt/Checkbox.java ! src/share/classes/java/awt/CheckboxGroup.java ! src/share/classes/java/awt/CheckboxMenuItem.java ! src/share/classes/java/awt/Choice.java ! src/share/classes/java/awt/Color.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/FlowLayout.java ! src/share/classes/java/awt/FontMetrics.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/GridBagLayout.java ! src/share/classes/java/awt/GridLayout.java ! src/share/classes/java/awt/Label.java ! src/share/classes/java/awt/LinearGradientPaint.java ! src/share/classes/java/awt/List.java ! src/share/classes/java/awt/MenuBar.java ! src/share/classes/java/awt/MenuItem.java ! src/share/classes/java/awt/RadialGradientPaint.java ! src/share/classes/java/awt/Scrollbar.java ! src/share/classes/java/awt/SystemTray.java ! src/share/classes/java/awt/TextArea.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/font/TextAttribute.java ! src/share/classes/java/awt/geom/AffineTransform.java ! src/share/classes/java/awt/geom/Line2D.java ! src/share/classes/java/awt/print/PrinterJob.java ! src/share/classes/javax/print/Doc.java ! src/share/classes/javax/print/DocFlavor.java ! src/share/classes/javax/print/MultiDoc.java ! src/share/classes/javax/print/attribute/standard/Finishings.java ! src/share/classes/javax/print/attribute/standard/JobStateReasons.java ! src/share/classes/javax/print/attribute/standard/MediaPrintableArea.java ! src/share/classes/javax/print/attribute/standard/MultipleDocumentHandling.java ! src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/share/classes/javax/print/attribute/standard/Sides.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JOptionPane.java ! src/share/classes/javax/swing/JScrollPane.java ! src/share/classes/javax/swing/JTabbedPane.java ! src/share/classes/javax/swing/LookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalTreeUI.java ! src/share/classes/javax/swing/text/Document.java ! src/share/classes/javax/swing/text/MaskFormatter.java ! src/share/classes/javax/swing/text/View.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java Changeset: 998578a87c0e Author: bagiras Date: 2013-10-03 16:51 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/998578a87c0e 8013553: [macosx] java.awt.FileDialog removes file extensions Reviewed-by: leonidr, serb ! src/macosx/native/sun/awt/CFileDialog.m Changeset: 1533a379deb0 Author: anthony Date: 2013-10-03 18:01 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1533a379deb0 7174704: [macosx] New issue in 7u6 b12: HeadlessPrintingTest failure Summary: Load the lwawt native library on Mac regardless of the headless/headful mode. Also, some minor cleanup. Reviewed-by: art, serb ! src/macosx/native/sun/awt/awt.m ! src/solaris/native/sun/awt/awt_LoadLibrary.c Changeset: 39b674405270 Author: alexsch Date: 2013-10-03 19:02 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39b674405270 7092283: Property Window.locationByPlatform is not cleared by calling setVisible(false) Reviewed-by: anthony, serb ! src/share/classes/java/awt/Window.java + test/java/awt/Window/LocationByPlatform/LocationByPlatformTest.java Changeset: 6ffe50fe06bd Author: mcherkas Date: 2013-10-04 20:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ffe50fe06bd 8020688: Broken links in documentation at http://docs.oracle.com/javase/6/docs/api/index. Reviewed-by: anthony, alexsch ! src/macosx/classes/apple/applescript/AppleScriptEngine.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SKI.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverDirectHTTP.java ! src/share/classes/java/applet/Applet.java ! src/share/classes/java/applet/AppletStub.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/DefaultFocusTraversalPolicy.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/DisplayMode.java ! src/share/classes/java/awt/FocusTraversalPolicy.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/GraphicsDevice.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/awt/datatransfer/Transferable.java ! src/share/classes/java/awt/event/ActionEvent.java ! src/share/classes/java/awt/event/ActionListener.java ! src/share/classes/java/awt/event/ComponentAdapter.java ! src/share/classes/java/awt/event/ComponentEvent.java ! src/share/classes/java/awt/event/ComponentListener.java ! src/share/classes/java/awt/event/ContainerAdapter.java ! src/share/classes/java/awt/event/ContainerEvent.java ! src/share/classes/java/awt/event/ContainerListener.java ! src/share/classes/java/awt/event/FocusAdapter.java ! src/share/classes/java/awt/event/FocusEvent.java ! src/share/classes/java/awt/event/FocusListener.java ! src/share/classes/java/awt/event/ItemEvent.java ! src/share/classes/java/awt/event/ItemListener.java ! src/share/classes/java/awt/event/KeyAdapter.java ! src/share/classes/java/awt/event/KeyEvent.java ! src/share/classes/java/awt/event/MouseAdapter.java ! src/share/classes/java/awt/event/MouseEvent.java ! src/share/classes/java/awt/event/MouseListener.java ! src/share/classes/java/awt/event/MouseMotionAdapter.java ! src/share/classes/java/awt/event/MouseMotionListener.java ! src/share/classes/java/awt/event/WindowAdapter.java ! src/share/classes/java/awt/event/WindowEvent.java ! src/share/classes/java/awt/event/WindowFocusListener.java ! src/share/classes/java/awt/event/WindowListener.java ! src/share/classes/java/awt/geom/Line2D.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/net/URI.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/javax/management/Descriptor.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/BorderFactory.java ! src/share/classes/javax/swing/BoundedRangeModel.java ! src/share/classes/javax/swing/Box.java ! src/share/classes/javax/swing/BoxLayout.java ! src/share/classes/javax/swing/ButtonGroup.java ! src/share/classes/javax/swing/DefaultFocusManager.java ! src/share/classes/javax/swing/FocusManager.java ! src/share/classes/javax/swing/ImageIcon.java ! src/share/classes/javax/swing/JApplet.java ! src/share/classes/javax/swing/JButton.java ! src/share/classes/javax/swing/JCheckBox.java ! src/share/classes/javax/swing/JCheckBoxMenuItem.java ! src/share/classes/javax/swing/JColorChooser.java ! src/share/classes/javax/swing/JComboBox.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JDesktopPane.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JFileChooser.java ! src/share/classes/javax/swing/JFrame.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JLabel.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JList.java ! src/share/classes/javax/swing/JMenu.java ! src/share/classes/javax/swing/JMenuBar.java ! src/share/classes/javax/swing/JMenuItem.java ! src/share/classes/javax/swing/JOptionPane.java ! src/share/classes/javax/swing/JPanel.java ! src/share/classes/javax/swing/JPasswordField.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/javax/swing/JProgressBar.java ! src/share/classes/javax/swing/JRadioButton.java ! src/share/classes/javax/swing/JRadioButtonMenuItem.java ! src/share/classes/javax/swing/JRootPane.java ! src/share/classes/javax/swing/JScrollPane.java ! src/share/classes/javax/swing/JSeparator.java ! src/share/classes/javax/swing/JSlider.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTabbedPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JTextArea.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JTextPane.java ! src/share/classes/javax/swing/JToggleButton.java ! src/share/classes/javax/swing/JToolBar.java ! src/share/classes/javax/swing/JToolTip.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/ProgressMonitor.java ! src/share/classes/javax/swing/ProgressMonitorInputStream.java ! src/share/classes/javax/swing/Spring.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/SwingWorker.java ! src/share/classes/javax/swing/Timer.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/WindowConstants.java ! src/share/classes/javax/swing/border/Border.java ! src/share/classes/javax/swing/event/InternalFrameAdapter.java ! src/share/classes/javax/swing/event/InternalFrameEvent.java ! src/share/classes/javax/swing/event/InternalFrameListener.java ! src/share/classes/javax/swing/event/TreeExpansionEvent.java ! src/share/classes/javax/swing/event/TreeExpansionListener.java ! src/share/classes/javax/swing/event/TreeModelEvent.java ! src/share/classes/javax/swing/event/TreeModelListener.java ! src/share/classes/javax/swing/event/TreeSelectionListener.java ! src/share/classes/javax/swing/event/TreeWillExpandListener.java ! src/share/classes/javax/swing/filechooser/FileFilter.java ! src/share/classes/javax/swing/filechooser/FileView.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/table/TableModel.java ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/javax/swing/tree/DefaultMutableTreeNode.java ! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java ! src/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/share/classes/javax/swing/tree/ExpandVetoException.java ! src/share/classes/javax/swing/tree/TreeCellRenderer.java ! src/share/classes/javax/swing/tree/TreeModel.java ! src/share/classes/javax/swing/tree/TreeNode.java ! src/share/classes/javax/swing/tree/TreePath.java ! src/share/classes/javax/swing/tree/TreeSelectionModel.java ! src/share/classes/sun/swing/PrintingStatus.java ! src/share/classes/sun/text/normalizer/UCharacter.java ! src/share/demo/jfc/FileChooserDemo/FileChooserDemo.java Changeset: 01b40315f872 Author: alexsch Date: 2013-10-07 16:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01b40315f872 8025438: [macosx] right JNFCall* method should be used in JDK-8008728 fix Reviewed-by: serb, anthony ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 72afa269fa3b Author: alexsch Date: 2013-10-07 16:42 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72afa269fa3b 8007219: [macosx] Frame size reverts meaning of maximized attribute if frame size close to display Reviewed-by: serb, anthony ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CWrapper.java ! src/macosx/native/sun/awt/CWrapper.m + test/java/awt/Frame/MaximizedToMaximized/MaximizedToMaximized.java Changeset: 546c0ebfbf56 Author: cl Date: 2013-10-07 11:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/546c0ebfbf56 8025840: Fix all the doclint warnings about trademark Reviewed-by: art ! src/share/classes/javax/swing/AbstractAction.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/AbstractCellEditor.java ! src/share/classes/javax/swing/AbstractListModel.java ! src/share/classes/javax/swing/Box.java ! src/share/classes/javax/swing/BoxLayout.java ! src/share/classes/javax/swing/ButtonGroup.java ! src/share/classes/javax/swing/CellRendererPane.java ! src/share/classes/javax/swing/DefaultBoundedRangeModel.java ! src/share/classes/javax/swing/DefaultButtonModel.java ! src/share/classes/javax/swing/DefaultCellEditor.java ! src/share/classes/javax/swing/DefaultListCellRenderer.java ! src/share/classes/javax/swing/DefaultListModel.java ! src/share/classes/javax/swing/DefaultListSelectionModel.java ! src/share/classes/javax/swing/DefaultSingleSelectionModel.java ! src/share/classes/javax/swing/ImageIcon.java ! src/share/classes/javax/swing/JApplet.java ! src/share/classes/javax/swing/JButton.java ! src/share/classes/javax/swing/JCheckBox.java ! src/share/classes/javax/swing/JCheckBoxMenuItem.java ! src/share/classes/javax/swing/JColorChooser.java ! src/share/classes/javax/swing/JComboBox.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JDesktopPane.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JFormattedTextField.java ! src/share/classes/javax/swing/JFrame.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JLabel.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JList.java ! src/share/classes/javax/swing/JMenu.java ! src/share/classes/javax/swing/JMenuBar.java ! src/share/classes/javax/swing/JMenuItem.java ! src/share/classes/javax/swing/JOptionPane.java ! src/share/classes/javax/swing/JPanel.java ! src/share/classes/javax/swing/JPasswordField.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/javax/swing/JProgressBar.java ! src/share/classes/javax/swing/JRadioButton.java ! src/share/classes/javax/swing/JRadioButtonMenuItem.java ! src/share/classes/javax/swing/JRootPane.java ! src/share/classes/javax/swing/JScrollBar.java ! src/share/classes/javax/swing/JScrollPane.java ! src/share/classes/javax/swing/JSeparator.java ! src/share/classes/javax/swing/JSlider.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTabbedPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JTextArea.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JTextPane.java ! src/share/classes/javax/swing/JToggleButton.java ! src/share/classes/javax/swing/JToolBar.java ! src/share/classes/javax/swing/JToolTip.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JViewport.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/KeyStroke.java ! src/share/classes/javax/swing/OverlayLayout.java ! src/share/classes/javax/swing/ScrollPaneLayout.java ! src/share/classes/javax/swing/SizeRequirements.java ! src/share/classes/javax/swing/Spring.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/Timer.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/UIManager.java ! src/share/classes/javax/swing/UnsupportedLookAndFeelException.java ! src/share/classes/javax/swing/ViewportLayout.java ! src/share/classes/javax/swing/border/AbstractBorder.java ! src/share/classes/javax/swing/border/BevelBorder.java ! src/share/classes/javax/swing/border/CompoundBorder.java ! src/share/classes/javax/swing/border/EmptyBorder.java ! src/share/classes/javax/swing/border/EtchedBorder.java ! src/share/classes/javax/swing/border/LineBorder.java ! src/share/classes/javax/swing/border/MatteBorder.java ! src/share/classes/javax/swing/border/SoftBevelBorder.java ! src/share/classes/javax/swing/border/TitledBorder.java ! src/share/classes/javax/swing/colorchooser/AbstractColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/ColorChooserComponentFactory.java ! src/share/classes/javax/swing/colorchooser/DefaultPreviewPanel.java ! src/share/classes/javax/swing/colorchooser/DefaultSwatchChooserPanel.java ! src/share/classes/javax/swing/event/AncestorEvent.java ! src/share/classes/javax/swing/event/CaretEvent.java ! src/share/classes/javax/swing/event/ChangeEvent.java ! src/share/classes/javax/swing/event/EventListenerList.java ! src/share/classes/javax/swing/event/HyperlinkEvent.java ! src/share/classes/javax/swing/event/InternalFrameEvent.java ! src/share/classes/javax/swing/event/ListDataEvent.java ! src/share/classes/javax/swing/event/ListSelectionEvent.java ! src/share/classes/javax/swing/event/MenuDragMouseEvent.java ! src/share/classes/javax/swing/event/MenuEvent.java ! src/share/classes/javax/swing/event/MenuKeyEvent.java ! src/share/classes/javax/swing/event/PopupMenuEvent.java ! src/share/classes/javax/swing/event/TableColumnModelEvent.java ! src/share/classes/javax/swing/event/TableModelEvent.java ! src/share/classes/javax/swing/event/TreeExpansionEvent.java ! src/share/classes/javax/swing/event/TreeModelEvent.java ! src/share/classes/javax/swing/event/TreeSelectionEvent.java ! src/share/classes/javax/swing/event/UndoableEditEvent.java ! src/share/classes/javax/swing/plaf/BorderUIResource.java ! src/share/classes/javax/swing/plaf/ColorUIResource.java ! src/share/classes/javax/swing/plaf/DimensionUIResource.java ! src/share/classes/javax/swing/plaf/FontUIResource.java ! src/share/classes/javax/swing/plaf/IconUIResource.java ! src/share/classes/javax/swing/plaf/InsetsUIResource.java ! src/share/classes/javax/swing/plaf/basic/BasicArrowButton.java ! src/share/classes/javax/swing/plaf/basic/BasicCheckBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxEditor.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxRenderer.java ! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java ! src/share/classes/javax/swing/plaf/basic/BasicEditorPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicIconFactory.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/basic/BasicListUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java ! src/share/classes/javax/swing/plaf/basic/BasicTextAreaUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextFieldUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/share/classes/javax/swing/plaf/basic/ComboPopup.java ! src/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java ! src/share/classes/javax/swing/plaf/metal/MetalButtonUI.java ! src/share/classes/javax/swing/plaf/metal/MetalCheckBoxIcon.java ! src/share/classes/javax/swing/plaf/metal/MetalCheckBoxUI.java ! src/share/classes/javax/swing/plaf/metal/MetalComboBoxButton.java ! src/share/classes/javax/swing/plaf/metal/MetalComboBoxEditor.java ! src/share/classes/javax/swing/plaf/metal/MetalComboBoxUI.java ! src/share/classes/javax/swing/plaf/metal/MetalIconFactory.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalProgressBarUI.java ! src/share/classes/javax/swing/plaf/metal/MetalRadioButtonUI.java ! src/share/classes/javax/swing/plaf/metal/MetalRootPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalScrollButton.java ! src/share/classes/javax/swing/plaf/metal/MetalScrollPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSeparatorUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSplitPaneDivider.java ! src/share/classes/javax/swing/plaf/metal/MetalSplitPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalTextFieldUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToggleButtonUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToolTipUI.java ! src/share/classes/javax/swing/plaf/multi/MultiLookAndFeel.java ! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextPaneUI.java ! src/share/classes/javax/swing/table/AbstractTableModel.java ! src/share/classes/javax/swing/table/DefaultTableCellRenderer.java ! src/share/classes/javax/swing/table/DefaultTableColumnModel.java ! src/share/classes/javax/swing/table/DefaultTableModel.java ! src/share/classes/javax/swing/table/JTableHeader.java ! src/share/classes/javax/swing/table/TableColumn.java ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/BadLocationException.java ! src/share/classes/javax/swing/text/DateFormatter.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/DefaultEditorKit.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/DefaultFormatterFactory.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/InternationalFormatter.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/MaskFormatter.java ! src/share/classes/javax/swing/text/NumberFormatter.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/SimpleAttributeSet.java ! src/share/classes/javax/swing/text/StringContent.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/StyledEditorKit.java ! src/share/classes/javax/swing/text/TabSet.java ! src/share/classes/javax/swing/text/TabStop.java ! src/share/classes/javax/swing/text/TextAction.java ! src/share/classes/javax/swing/text/html/Option.java ! src/share/classes/javax/swing/tree/AbstractLayoutCache.java ! src/share/classes/javax/swing/tree/DefaultMutableTreeNode.java ! src/share/classes/javax/swing/tree/DefaultTreeCellEditor.java ! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java ! src/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java ! src/share/classes/javax/swing/tree/FixedHeightLayoutCache.java ! src/share/classes/javax/swing/tree/TreePath.java ! src/share/classes/javax/swing/tree/VariableHeightLayoutCache.java ! src/share/classes/javax/swing/undo/CannotRedoException.java ! src/share/classes/javax/swing/undo/CannotUndoException.java ! src/share/classes/javax/swing/undo/UndoManager.java Changeset: bdc8abbce9c1 Author: yan Date: 2013-10-08 13:57 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bdc8abbce9c1 8025236: [javadoc] fix some errors in AWT Reviewed-by: yan, anthony Contributed-by: Dmitry Ginzburg ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/awt/event/MouseEvent.java ! src/share/classes/java/awt/im/InputContext.java ! src/share/classes/java/awt/im/InputMethodHighlight.java Changeset: 01022f461570 Author: pchelko Date: 2013-10-08 15:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01022f461570 7158311: GraphicsDevice.setDisplayMode(...) leads to hang when DISPLAY variable points to Oracle Linux 8001463: Regression : Deadlock between AWT-XAWT thread and AWT-EventQueue-0 Thread when screen resolution changes Reviewed-by: art, serb Contributed-by: alexander.zvegintsev at oracle.com ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: a5d0730342a5 Author: pchelko Date: 2013-10-08 15:54 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a5d0730342a5 8025585: Win: Popups in JFXPanel do not receive MouseWheel events Reviewed-by: anthony, art ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 85a72bb00d74 Author: bagiras Date: 2013-10-08 16:04 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85a72bb00d74 8000425: FileDialog documentation should be enhanced Reviewed-by: serb, anthony ! src/share/classes/java/awt/FileDialog.java Changeset: 01607de6265d Author: bagiras Date: 2013-10-08 16:56 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01607de6265d 7068423: Spec for java.awt.GraphicsDevice.getFullScreenWindow() needs clarification Reviewed-by: art, anthony ! src/share/classes/java/awt/GraphicsDevice.java Changeset: 184b16f4e61f Author: bagiras Date: 2013-10-08 17:00 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/184b16f4e61f 7199196: Incremental transfer is broken because of a typo Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XSelection.java Changeset: 42d3ea1c35b4 Author: malenkov Date: 2013-10-08 18:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/42d3ea1c35b4 7081584: Specification for Window.isAlwaysOnTopSupported needs to be clarified Reviewed-by: art, serb ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/macosx/CFileDialog.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/sun/awt/NullComponentPeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java Changeset: 6914b883c3bb Author: malenkov Date: 2013-10-08 18:19 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6914b883c3bb 7172597: java.awt.KeyboardFocusManager.clearFocusOwner() missed javadoc tag @since 1.8 Reviewed-by: art, anthony ! src/share/classes/java/awt/KeyboardFocusManager.java Changeset: a2dd2b411723 Author: alexsch Date: 2013-10-08 18:45 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a2dd2b411723 7081594: Windows owned by an always-on-top window DO NOT automatically become always-on-top Reviewed-by: art, anthony, serb ! src/share/classes/java/awt/Window.java + test/java/awt/Window/AlwaysOnTop/AlwaysOnTopFieldTest.java Changeset: 0c06c38dfc3e Author: serb Date: 2013-10-08 21:24 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c06c38dfc3e 8022119: test api/javax_sound/sampled/spi/MixerProvider/indexTGF_MixerProviderTests fails Reviewed-by: art, anthony ! src/share/classes/com/sun/media/sound/JSSecurityManager.java Changeset: b218a14bdc8a Author: serb Date: 2013-10-08 23:34 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b218a14bdc8a 8025603: Unused methods in the awt text peers should be removed Reviewed-by: art, anthony ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/peer/TextComponentPeer.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java ! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java ! src/windows/classes/sun/awt/windows/WButtonPeer.java ! src/windows/classes/sun/awt/windows/WCheckboxPeer.java ! src/windows/classes/sun/awt/windows/WChoicePeer.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WLabelPeer.java ! src/windows/classes/sun/awt/windows/WListPeer.java ! src/windows/classes/sun/awt/windows/WScrollbarPeer.java ! src/windows/classes/sun/awt/windows/WTextAreaPeer.java ! src/windows/classes/sun/awt/windows/WTextComponentPeer.java ! src/windows/classes/sun/awt/windows/WTextFieldPeer.java ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextField.cpp Changeset: e591ac19174f Author: leonidr Date: 2013-10-09 01:03 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e591ac19174f 8004050: [macosx] The 'ESC' key does not work with jdk8 Reviewed-by: alexsch, serb ! src/macosx/classes/com/apple/laf/AquaComboBoxUI.java ! src/macosx/classes/com/apple/laf/AquaKeyBindings.java Changeset: c1ef9ebac26a Author: lana Date: 2013-10-08 14:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1ef9ebac26a Merge ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java Changeset: 748207aa9620 Author: lana Date: 2013-10-08 14:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/748207aa9620 Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk - src/share/classes/java/lang/invoke/InvokeGeneric.java - src/share/classes/java/time/chrono/ChronoDateImpl.java - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java Changeset: 575d4bc3bcae Author: lana Date: 2013-10-11 03:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/575d4bc3bcae Merge ! makefiles/CreateJars.gmk - src/share/classes/java/lang/invoke/InvokeGeneric.java - src/share/classes/java/time/chrono/ChronoDateImpl.java - test/java/time/tck/java/time/chrono/TCKChronologySerialization.java Changeset: 96644227daed Author: lana Date: 2013-10-11 23:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/96644227daed Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk Changeset: 3a5c987ff3a0 Author: lana Date: 2013-10-14 09:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3a5c987ff3a0 Merge From jan.lahoda at oracle.com Mon Oct 14 13:14:03 2013 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Mon, 14 Oct 2013 20:14:03 +0000 Subject: hg: jdk8/tl/langtools: 8014016: javac is too late detecting invalid annotation usage Message-ID: <20131014201425.D6D7E6239E@hg.openjdk.java.net> Changeset: 87b5bfef7edb Author: jlahoda Date: 2013-10-14 22:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/87b5bfef7edb 8014016: javac is too late detecting invalid annotation usage Summary: Adding new queue to Annotate for validation tasks, performing annotation validation during enter Reviewed-by: jjg, emc, jfranck ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.out + test/tools/javac/processing/errors/StopOnInapplicableAnnotations/GenerateFunctionalInterface.java + test/tools/javac/processing/errors/StopOnInapplicableAnnotations/GenerateSuperInterfaceProcessor.java + test/tools/javac/processing/errors/StopOnInapplicableAnnotations/Processor.java + test/tools/javac/processing/errors/StopOnInapplicableAnnotations/Source.java From michael.x.mcmahon at oracle.com Mon Oct 14 14:10:22 2013 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Mon, 14 Oct 2013 21:10:22 +0000 Subject: hg: jdk8/tl/jdk: 8014719: HttpClient/ProxyTest.java failing with IAE HttpURLPermission.parseURI Message-ID: <20131014211103.07C21623A0@hg.openjdk.java.net> Changeset: dd0deeb04933 Author: michaelm Date: 2013-10-14 22:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd0deeb04933 8014719: HttpClient/ProxyTest.java failing with IAE HttpURLPermission.parseURI Reviewed-by: alanb, chegar + src/share/classes/java/net/HostPortrange.java ! src/share/classes/java/net/HttpURLConnection.java - src/share/classes/java/net/HttpURLPermission.java + src/share/classes/java/net/URLPermission.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 + test/java/net/URLPermission/URLPermissionTest.java + test/java/net/URLPermission/URLTest.java + test/java/net/URLPermission/policy.1 + test/java/net/URLPermission/policy.2 + test/java/net/URLPermission/policy.3 From henry.jen at oracle.com Mon Oct 14 17:28:00 2013 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Tue, 15 Oct 2013 00:28:00 +0000 Subject: hg: jdk8/tl/jdk: 8026362: java/lang/invoke/lambda/LogGeneratedClassesTest.java failed on windows, jtreg report Fail to org.testng.SkipException Message-ID: <20131015002828.C515B623B2@hg.openjdk.java.net> Changeset: 94d4aa2fb414 Author: henryjen Date: 2013-10-14 17:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/94d4aa2fb414 8026362: java/lang/invoke/lambda/LogGeneratedClassesTest.java failed on windows, jtreg report Fail to org.testng.SkipException Reviewed-by: chegar ! test/java/lang/invoke/lambda/LogGeneratedClassesTest.java From jonathan.gibbons at oracle.com Mon Oct 14 21:52:03 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 15 Oct 2013 04:52:03 +0000 Subject: hg: jdk8/tl/langtools: 8026371: "tidy" issues in langtools/src/**/*.html files Message-ID: <20131015045206.996DF623C5@hg.openjdk.java.net> Changeset: b9e3b55a908c Author: jjg Date: 2013-10-14 16:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b9e3b55a908c 8026371: "tidy" issues in langtools/src/**/*.html files Reviewed-by: darcy + src/share/classes/com/sun/javadoc/package-info.java - src/share/classes/com/sun/javadoc/package.html + src/share/classes/com/sun/tools/classfile/package-info.java - src/share/classes/com/sun/tools/classfile/package.html + src/share/classes/com/sun/tools/doclets/formats/html/markup/package-info.java - src/share/classes/com/sun/tools/doclets/formats/html/markup/package.html + src/share/classes/com/sun/tools/doclets/formats/html/package-info.java - src/share/classes/com/sun/tools/doclets/formats/html/package.html + src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/package-info.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/package.html + src/share/classes/com/sun/tools/doclets/internal/toolkit/package-info.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/package.html + src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/package-info.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/package.html + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/package-info.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/package.html + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/package-info.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/package.html + src/share/classes/com/sun/tools/doclets/package-info.java - src/share/classes/com/sun/tools/doclets/package.html + src/share/classes/com/sun/tools/javap/package-info.java - src/share/classes/com/sun/tools/javap/package.html ! src/share/classes/javax/lang/model/overview.html ! src/share/classes/javax/tools/overview.html From huizhe.wang at oracle.com Mon Oct 14 22:08:13 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Tue, 15 Oct 2013 05:08:13 +0000 Subject: hg: jdk8/tl/jaxp: 8015092: SchemaFactory cannot parse schema if whitespace added within patterns in Selector XPath expression Message-ID: <20131015050818.7D767623C8@hg.openjdk.java.net> Changeset: eb169222d3f2 Author: joehw Date: 2013-10-14 22:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/eb169222d3f2 8015092: SchemaFactory cannot parse schema if whitespace added within patterns in Selector XPath expression Reviewed-by: lancea, alanb ! src/com/sun/org/apache/xerces/internal/impl/xpath/XPath.java From huizhe.wang at oracle.com Mon Oct 14 22:28:24 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Tue, 15 Oct 2013 05:28:24 +0000 Subject: hg: jdk8/tl/jdk: 8015092: SchemaFactory cannot parse schema if whitespace added within patterns in Selector XPath expression Message-ID: <20131015052905.CC8A9623CA@hg.openjdk.java.net> Changeset: 50e88f25255f Author: joehw Date: 2013-10-14 22:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/50e88f25255f 8015092: SchemaFactory cannot parse schema if whitespace added within patterns in Selector XPath expression Reviewed-by: lancea, alanb + test/javax/xml/jaxp/validation/8015092/XPathWhiteSpaceTest.java + test/javax/xml/jaxp/validation/8015092/idIxpns.xsd + test/javax/xml/jaxp/validation/8015092/idIxpns1.xsd + test/javax/xml/jaxp/validation/8015092/idJ029.xsd + test/javax/xml/jaxp/validation/8015092/idJimp.xsd From jonathan.gibbons at oracle.com Mon Oct 14 22:36:29 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 15 Oct 2013 05:36:29 +0000 Subject: hg: jdk8/tl/langtools: 8025693: recent javadoc changes cause com/sun/javadoc/testLinkOption/TestLinkOption.java to fail Message-ID: <20131015053632.19853623CB@hg.openjdk.java.net> Changeset: 7d266a2b31b2 Author: jjg Date: 2013-10-14 22:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7d266a2b31b2 8025693: recent javadoc changes cause com/sun/javadoc/testLinkOption/TestLinkOption.java to fail Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java + test/tools/javadoc/8025693/Test.java From david.holmes at oracle.com Mon Oct 14 23:05:20 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Oct 2013 16:05:20 +1000 Subject: code review round 1 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <525C1330.2000407@oracle.com> References: <52585F31.5040107@oracle.com> <525B4FA1.7020109@oracle.com> <525C0B40.40109@oracle.com> <525C1330.2000407@oracle.com> Message-ID: <525CDB20.3070506@oracle.com> On 15/10/2013 1:52 AM, Daniel D. Daugherty wrote: > On 10/14/13 9:18 AM, Daniel D. Daugherty wrote: >> On 10/13/13 7:57 PM, David Holmes wrote: >> >>> Hmm second comment - I don't see a .m4 file change that corresponds >>> to the DSYMUTIL configure change ?? >> >> Yikes! I'll check into that shortly. Not sure what happened here. > > I somehow missed/lost two 1-liner changes: > > hg diff common/autoconf/basics.m4 common/autoconf/spec.gmk.in > diff -r 4faa09c7fe55 common/autoconf/basics.m4 > --- a/common/autoconf/basics.m4 Wed Oct 02 15:08:03 2013 +0200 > +++ b/common/autoconf/basics.m4 Mon Oct 14 08:49:37 2013 -0700 > @@ -644,6 +644,7 @@ fi > fi > > if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then > + BASIC_REQUIRE_PROG(DSYMUTIL, dsymutil) > BASIC_REQUIRE_PROG(XATTR, xattr) > AC_PATH_PROG(CODESIGN, codesign) > if test "x$CODESIGN" != "x"; then > diff -r 4faa09c7fe55 common/autoconf/spec.gmk.in > --- a/common/autoconf/spec.gmk.in Wed Oct 02 15:08:03 2013 +0200 > +++ b/common/autoconf/spec.gmk.in Mon Oct 14 08:49:37 2013 -0700 > @@ -484,6 +484,7 @@ DATE:=@DATE@ > DATE:=@DATE@ > DIFF:=@DIFF@ > DIRNAME:=@DIRNAME@ > +DSYMUTIL:=@DSYMUTIL@ > FIND:=@FIND@ > FIND_DELETE:=@FIND_DELETE@ > ECHO:=@ECHO@ > > > I don't think that these two 1-liners are worth re-rolling the webrev. > Please let me know if you don't agree. Look fine to me. David > Dan > > >> >> Dan >> >> >>> >>> Thanks, >>> David >>> >>> On 12/10/2013 6:27 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I'm ready for code review round 1 of the FDS on MacOS X hotspot >>>> changes. >>>> Below is the original code review round 0 invite (slightly edited for >>>> clarity). Working on FDS is like pulling a thread on a sweater... so >>>> there are four additional changed files along with more changes to >>>> many of the files from round 0. >>>> >>>> Here is the code review round 1 JDK8/HSX-25 webrev URL: >>>> >>>> OpenJDK: >>>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/1-jdk8/ >>>> Internal: >>>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/1-jdk8/ >>>> >>>> >>>> Changes from code review round 0 to round 1: >>>> >>>> root repo: >>>> - add configure support for DSYMUTIL macro >>>> >>>> hotspot repo: >>>> - drop Minimal1 config support for FDS on MacOS X >>>> - use DSYMUTIL macro instead of literal 'dsymutil' >>>> - fix FASTDEBUG_CFLAGS typo and add USE_CLANG support >>>> - STRIP is not used on MacOS X >>>> - fix $(UNIVERSAL_COPY_LIST) rule >>>> - refine install-dir function >>>> >>>> jdk repo: >>>> - add prep-target-dir, install-import-dir, and >>>> install-import-debuginfo >>>> functions >>>> - support importing .dSYM directories from hotspot >>>> - create libjsig.dSYM symlink from VM specific directory to >>>> the real location >>>> >>>> Files changed from code review round 0 to round 1: >>>> >>>> common/autoconf/generated-configure.sh >>>> hotspot/make/Makefile >>>> hotspot/make/bsd/makefiles/defs.make >>>> hotspot/make/bsd/makefiles/dtrace.make >>>> hotspot/make/bsd/makefiles/gcc.make >>>> hotspot/make/bsd/makefiles/jsig.make >>>> hotspot/make/bsd/makefiles/saproc.make >>>> hotspot/make/bsd/makefiles/universal.gmk >>>> hotspot/make/bsd/makefiles/vm.make >>>> hotspot/make/defs.make >>>> >>>> New files changed in code review round 1: >>>> >>>> hotspot/make/bsd/makefiles/product.make >>>> jdk/make/common/Defs.gmk >>>> jdk/make/java/redist/Makefile >>>> jdk/makefiles/Import.gmk >>>> >>>> Additional bugs filed based on code review comments, testing and >>>> just plain looking at the Makefiles: >>>> >>>> 8026280 implement Full Debug Symbols on MacOS X jdk >>>> 8026281 hotspot 'jdk6_or_earlier logic' for FDS needs to be >>>> removed >>>> 8026282 the '64' subdir logic in Makefiles might be removable >>>> 8026283 literal 'lipo' cmd uses in HotSpot makefiles >>>> 8026284 Minimal1 references/support should be removed from >>>> BSD/MacOS X >>>> 8026285 JPRT -buildenv ZIP_DEBUGINFO_FILES=0 no longer works >>>> >>>> As always, comments, questions and suggestions are welcome. >>>> >>>> Dan >>>> >>>> > Greetings, >>>> > >>>> > I have the initial support for Full Debug Symbols (FDS) on MacOS >>>> X done >>>> > and ready for review: >>>> > >>>> > 7165611 implement Full Debug Symbols on MacOS X hotspot >>>> > https://bugs.openjdk.java.net/browse/JDK-7165611 >>>> > >>>> > Here is the JDK8/HSX-25 webrev URL: >>>> > >>>> > OpenJDK: >>>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >>>> > Internal: >>>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >>>> >>>> > >>>> > This webrev includes changes for the follow repos: >>>> > >>>> > jdk8 >>>> > jdk8/hotspot >>>> > jdk8/jdk >>>> > >>>> > Once these changes are approved, I'm planning to push them to >>>> > RT_Baseline. From there, they can follow the normal path to >>>> > Main_Baseline and eventually JDK8. >>>> > >>>> > This work enables FDS on MacOS X for the 'hotspot' repo; the >>>> changes in >>>> > the other repos are necessary to support importing the .diz files >>>> from >>>> > the MacOS X 'hotspot' build into the forest build. I also fixed a >>>> few >>>> > FDS related errors in the magic incantations for the new build. >>>> This is >>>> > mostly a port from Linux -> MacOS X/BSD with the dtrace changes >>>> ported >>>> > from Solaris. In other words, this is Frankenstein's monster... >>>> > >>>> > Thanks to Staffan Larsen for providing an initial set of changes >>>> > which I morphed into what you see here. >>>> > >>>> > Testing: >>>> > - JPRT HSX build and test on all platforms; verification of .diz >>>> > files in the MacOS X JPRT bundles >>>> > - JPRT JDK8 forest build and test on all platforms; verification of >>>> > .diz files in the MacOS X JPRT bundles >>>> > Note: In previous FDS changesets, I also did a standalone 'jdk' >>>> > repo build and test, but that no longer seems to work. >>>> > >>>> > As always, comments, questions and suggestions are welcome. >>>> > >>>> > Dan >> >> > From david.holmes at oracle.com Mon Oct 14 23:07:36 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Oct 2013 16:07:36 +1000 Subject: code review round 1 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <525C0B40.40109@oracle.com> References: <52585F31.5040107@oracle.com> <525B4FA1.7020109@oracle.com> <525C0B40.40109@oracle.com> Message-ID: <525CDBA8.7020903@oracle.com> On 15/10/2013 1:18 AM, Daniel D. Daugherty wrote: > Thanks for the re-review! > > > On 10/13/13 7:57 PM, David Holmes wrote: >> Hi Dan, >> >> Only further comment I have, and it may well be deferred for future >> work, is that we should be able to abstract away the actual >> "extension" used for the "debuginfo" file so that we don't need macosx >> conditionals as much eg one: >> >> if macosx >> DEBUGINFO_EXTENSION=dSYM >> else >> DEBUGINFO_EXTENSION=debuginfo >> endif >> >> then eg: >> >> JSIG_DEBUGINFO := $(strip $(wildcard >> $(HOTSPOT_DIST)/jre/lib$(OPENJDK_TARGET_CPU_LIBDIR)/libjsig.$DEBUGINFO_EXTENSION) >> \ >> $(wildcard >> $(HOTSPOT_DIST)/jre/lib$(OPENJDK_TARGET_CPU_LIBDIR)/libjsig.diz) ) > > The biggest worry that I have about something like DEBUGINFO_EXTENSION > is that on MacOS X the '.dSYM' objects are directories instead of files. > This requires that different cmd options be used in many/most/all of the > cases. More thought would be needed. I agree that the main commands wouldn't benefit from this, but things like the JSIG_DEBUGINFO definition would. I must admit that I'm somewhat surprised that .dSYM being a directory hasn't caused more problems. Anyway no blockers here. Cheers, David > >> Hmm second comment - I don't see a .m4 file change that corresponds to >> the DSYMUTIL configure change ?? > > Yikes! I'll check into that shortly. Not sure what happened here. > > Dan > > >> >> Thanks, >> David >> >> On 12/10/2013 6:27 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I'm ready for code review round 1 of the FDS on MacOS X hotspot changes. >>> Below is the original code review round 0 invite (slightly edited for >>> clarity). Working on FDS is like pulling a thread on a sweater... so >>> there are four additional changed files along with more changes to >>> many of the files from round 0. >>> >>> Here is the code review round 1 JDK8/HSX-25 webrev URL: >>> >>> OpenJDK: >>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/1-jdk8/ >>> Internal: >>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/1-jdk8/ >>> >>> Changes from code review round 0 to round 1: >>> >>> root repo: >>> - add configure support for DSYMUTIL macro >>> >>> hotspot repo: >>> - drop Minimal1 config support for FDS on MacOS X >>> - use DSYMUTIL macro instead of literal 'dsymutil' >>> - fix FASTDEBUG_CFLAGS typo and add USE_CLANG support >>> - STRIP is not used on MacOS X >>> - fix $(UNIVERSAL_COPY_LIST) rule >>> - refine install-dir function >>> >>> jdk repo: >>> - add prep-target-dir, install-import-dir, and >>> install-import-debuginfo >>> functions >>> - support importing .dSYM directories from hotspot >>> - create libjsig.dSYM symlink from VM specific directory to >>> the real location >>> >>> Files changed from code review round 0 to round 1: >>> >>> common/autoconf/generated-configure.sh >>> hotspot/make/Makefile >>> hotspot/make/bsd/makefiles/defs.make >>> hotspot/make/bsd/makefiles/dtrace.make >>> hotspot/make/bsd/makefiles/gcc.make >>> hotspot/make/bsd/makefiles/jsig.make >>> hotspot/make/bsd/makefiles/saproc.make >>> hotspot/make/bsd/makefiles/universal.gmk >>> hotspot/make/bsd/makefiles/vm.make >>> hotspot/make/defs.make >>> >>> New files changed in code review round 1: >>> >>> hotspot/make/bsd/makefiles/product.make >>> jdk/make/common/Defs.gmk >>> jdk/make/java/redist/Makefile >>> jdk/makefiles/Import.gmk >>> >>> Additional bugs filed based on code review comments, testing and >>> just plain looking at the Makefiles: >>> >>> 8026280 implement Full Debug Symbols on MacOS X jdk >>> 8026281 hotspot 'jdk6_or_earlier logic' for FDS needs to be removed >>> 8026282 the '64' subdir logic in Makefiles might be removable >>> 8026283 literal 'lipo' cmd uses in HotSpot makefiles >>> 8026284 Minimal1 references/support should be removed from >>> BSD/MacOS X >>> 8026285 JPRT -buildenv ZIP_DEBUGINFO_FILES=0 no longer works >>> >>> As always, comments, questions and suggestions are welcome. >>> >>> Dan >>> >>> > Greetings, >>> > >>> > I have the initial support for Full Debug Symbols (FDS) on MacOS X >>> done >>> > and ready for review: >>> > >>> > 7165611 implement Full Debug Symbols on MacOS X hotspot >>> > https://bugs.openjdk.java.net/browse/JDK-7165611 >>> > >>> > Here is the JDK8/HSX-25 webrev URL: >>> > >>> > OpenJDK: >>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >>> > Internal: >>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >>> > >>> > This webrev includes changes for the follow repos: >>> > >>> > jdk8 >>> > jdk8/hotspot >>> > jdk8/jdk >>> > >>> > Once these changes are approved, I'm planning to push them to >>> > RT_Baseline. From there, they can follow the normal path to >>> > Main_Baseline and eventually JDK8. >>> > >>> > This work enables FDS on MacOS X for the 'hotspot' repo; the >>> changes in >>> > the other repos are necessary to support importing the .diz files >>> from >>> > the MacOS X 'hotspot' build into the forest build. I also fixed a few >>> > FDS related errors in the magic incantations for the new build. >>> This is >>> > mostly a port from Linux -> MacOS X/BSD with the dtrace changes >>> ported >>> > from Solaris. In other words, this is Frankenstein's monster... >>> > >>> > Thanks to Staffan Larsen for providing an initial set of changes >>> > which I morphed into what you see here. >>> > >>> > Testing: >>> > - JPRT HSX build and test on all platforms; verification of .diz >>> > files in the MacOS X JPRT bundles >>> > - JPRT JDK8 forest build and test on all platforms; verification of >>> > .diz files in the MacOS X JPRT bundles >>> > Note: In previous FDS changesets, I also did a standalone 'jdk' >>> > repo build and test, but that no longer seems to work. >>> > >>> > As always, comments, questions and suggestions are welcome. >>> > >>> > Dan > From staffan.larsen at oracle.com Mon Oct 14 23:09:16 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 15 Oct 2013 08:09:16 +0200 Subject: RFR: 7105883: JDWP: agent crash if there exists a ThreadGroup with null name In-Reply-To: <525BE745.3060109@oracle.com> References: <525BE745.3060109@oracle.com> Message-ID: <052ED885-DA29-4392-B07A-95F23064E342@oracle.com> Looks good! Thanks, /Staffan On 14 okt 2013, at 14:44, Erik Gahlin wrote: > Hi, > > Could I please have a review of this fix. > > An empty string is returned if the thread name is null. The protocol should be updated to support INVALID_STRING for the Thread Reference Command, but that is a larger effort and probably better to do when fixing other protocol changes. An empty string is better than a crash. > > Thanks > Erik > > Webrev: > http://cr.openjdk.java.net/~egahlin/7105883/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-7105883 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131015/95d37d1c/attachment.html From jonathan.gibbons at oracle.com Mon Oct 14 23:09:05 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 15 Oct 2013 06:09:05 +0000 Subject: hg: jdk8/tl/langtools: 8025998: Missing LV table in lambda bodies Message-ID: <20131015060908.D2808623CC@hg.openjdk.java.net> Changeset: 09a414673570 Author: jjg Date: 2013-10-14 23:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/09a414673570 8025998: Missing LV table in lambda bodies Reviewed-by: vromero ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/lambda/LocalVariableTable.java From karen.kinnear at oracle.com Mon Oct 14 21:29:00 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Tue, 15 Oct 2013 04:29:00 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8026299: invokespecial gets ICCE when it should get AME. Message-ID: <20131015042905.DE1F1623C0@hg.openjdk.java.net> Changeset: 2f8728d92483 Author: acorn Date: 2013-10-14 21:52 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2f8728d92483 8026299: invokespecial gets ICCE when it should get AME. Reviewed-by: ccheung, coleenp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp From staffan.larsen at oracle.com Mon Oct 14 23:30:24 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 15 Oct 2013 08:30:24 +0200 Subject: code review round 1 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <52585F31.5040107@oracle.com> References: <52585F31.5040107@oracle.com> Message-ID: <35F352DE-BD93-4576-AC4B-8AF125A4A78E@oracle.com> I've been using this patch while debugging other issues and I now get full symbols in the debugger without a lot of manual work. So it's a go! Thanks, /Staffan On 11 okt 2013, at 22:27, Daniel D. Daugherty wrote: > Greetings, > > I'm ready for code review round 1 of the FDS on MacOS X hotspot changes. > Below is the original code review round 0 invite (slightly edited for > clarity). Working on FDS is like pulling a thread on a sweater... so > there are four additional changed files along with more changes to > many of the files from round 0. > > Here is the code review round 1 JDK8/HSX-25 webrev URL: > > OpenJDK: http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/1-jdk8/ > Internal: http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/1-jdk8/ > > Changes from code review round 0 to round 1: > > root repo: > - add configure support for DSYMUTIL macro > > hotspot repo: > - drop Minimal1 config support for FDS on MacOS X > - use DSYMUTIL macro instead of literal 'dsymutil' > - fix FASTDEBUG_CFLAGS typo and add USE_CLANG support > - STRIP is not used on MacOS X > - fix $(UNIVERSAL_COPY_LIST) rule > - refine install-dir function > > jdk repo: > - add prep-target-dir, install-import-dir, and install-import-debuginfo > functions > - support importing .dSYM directories from hotspot > - create libjsig.dSYM symlink from VM specific directory to > the real location > > Files changed from code review round 0 to round 1: > > common/autoconf/generated-configure.sh > hotspot/make/Makefile > hotspot/make/bsd/makefiles/defs.make > hotspot/make/bsd/makefiles/dtrace.make > hotspot/make/bsd/makefiles/gcc.make > hotspot/make/bsd/makefiles/jsig.make > hotspot/make/bsd/makefiles/saproc.make > hotspot/make/bsd/makefiles/universal.gmk > hotspot/make/bsd/makefiles/vm.make > hotspot/make/defs.make > > New files changed in code review round 1: > > hotspot/make/bsd/makefiles/product.make > jdk/make/common/Defs.gmk > jdk/make/java/redist/Makefile > jdk/makefiles/Import.gmk > > Additional bugs filed based on code review comments, testing and > just plain looking at the Makefiles: > > 8026280 implement Full Debug Symbols on MacOS X jdk > 8026281 hotspot 'jdk6_or_earlier logic' for FDS needs to be removed > 8026282 the '64' subdir logic in Makefiles might be removable > 8026283 literal 'lipo' cmd uses in HotSpot makefiles > 8026284 Minimal1 references/support should be removed from BSD/MacOS X > 8026285 JPRT -buildenv ZIP_DEBUGINFO_FILES=0 no longer works > > As always, comments, questions and suggestions are welcome. > > Dan > > > Greetings, > > > > I have the initial support for Full Debug Symbols (FDS) on MacOS X done > > and ready for review: > > > > 7165611 implement Full Debug Symbols on MacOS X hotspot > > https://bugs.openjdk.java.net/browse/JDK-7165611 > > > > Here is the JDK8/HSX-25 webrev URL: > > > > OpenJDK: http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ > > Internal: http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ > > > > This webrev includes changes for the follow repos: > > > > jdk8 > > jdk8/hotspot > > jdk8/jdk > > > > Once these changes are approved, I'm planning to push them to > > RT_Baseline. From there, they can follow the normal path to > > Main_Baseline and eventually JDK8. > > > > This work enables FDS on MacOS X for the 'hotspot' repo; the changes in > > the other repos are necessary to support importing the .diz files from > > the MacOS X 'hotspot' build into the forest build. I also fixed a few > > FDS related errors in the magic incantations for the new build. This is > > mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported > > from Solaris. In other words, this is Frankenstein's monster... > > > > Thanks to Staffan Larsen for providing an initial set of changes > > which I morphed into what you see here. > > > > Testing: > > - JPRT HSX build and test on all platforms; verification of .diz > > files in the MacOS X JPRT bundles > > - JPRT JDK8 forest build and test on all platforms; verification of > > .diz files in the MacOS X JPRT bundles > > Note: In previous FDS changesets, I also did a standalone 'jdk' > > repo build and test, but that no longer seems to work. > > > > As always, comments, questions and suggestions are welcome. > > > > Dan From david.holmes at oracle.com Mon Oct 14 23:49:17 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Oct 2013 16:49:17 +1000 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <525BFC0D.8090101@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> <52556604.3080900@oracle.com> <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> <525622B4.5020606@oracle.com> <52568940.4000704@oracle.com> <23435103-156B-434F-994C-B6F913EE0364@oracle.com> <525BFC0D.8090101@oracle.com> Message-ID: <525CE56D.4000708@oracle.com> Hi Jaroslav, os_bsd.cpp / os_linux.cpp: If you don't have a monotonic clock you leave timer_frequency set to 0! (So you need to test on a system without a monotonic clock, or else force it to act as-if not present.) That aside I don't trust clock_getres to give values that actually allow the timer frequency to be determined. As per the comments in os_linux.cpp: // It's fixed in newer kernels, however clock_getres() still returns // 1/HZ. We check if clock_getres() works, but will ignore its reported // resolution for now. Hopefully as people move to new kernels, this // won't be a problem. we don't know what kernels provide real values here and which provide dummy ones. On BSD you haven't modified os::elapsed_counter. Looking at the linux changes I don't think the logic is correct even if clock_getres is accurate. In the existing code we have: elapsed_counter -> elapsed time in microseconds elapsed_frequency -> 1000 * 1000 (ie micros per second) elapsed_time -> elapsed_counter*0.000001 -> time in seconds Now we have: elapsed_counter -> elapsed time in nanoseconds elapsed_frequency -> 1x10^9 / whatever clock_getres says elapsed_time -> counter/frequency -> ??? So elapsed_time not, in general, going to give the elapsed time in seconds. And elapsed_time is not dependent on the "frequency" at all because elapsed_counter is not reporting ticks but an actual elapsed "time" in nanoseconds. Also note that we constants for: NANOSECS_PER_SEC NANOSECS_PER_MILLISEC to aid with time conversions. The linux webrev contains unrelated UseLargePages changes! David ----- On 15/10/2013 12:13 AM, Jaroslav Bachorik wrote: > On 10.10.2013 13:15, Staffan Larsen wrote: >> >> On 10 okt 2013, at 13:02, Jaroslav Bachorik >> wrote: >> >>> On 10.10.2013 05:44, David Holmes wrote: >>>> On 10/10/2013 4:12 AM, Staffan Larsen wrote: >>>>> >>>>> On 9 okt 2013, at 16:19, Jaroslav Bachorik >>>>> wrote: >>>>> >>>>>> On 9.10.2013 16:10, Staffan Larsen wrote: >>>>>>> There is now an awful amount of different timestamps in the >>>>>>> Management class. Can they be consolidated somehow? At least >>>>>>> _begin_vm_creation_time and the new _begin_vm_creation_ns. >>>>>>> >>>>>>> This discussion also implies that the "elapsed time" we print in the >>>>>>> hs_err file is also wrong. It uses os::elapsedTime() which uses >>>>>>> os::elapsed_counter(). >>>>>>> >>>>>>> And I guess the same thing for the VM.uptime Diagnostic Command >>>>>>> (class VMUptimeDCmd) which also relies on os::elapsed_counter(). >>>>>> >>>>>> Also the reported GC pauses duration might be wrong since it uses >>>>>> Management::timestamp(). >>>>>> >>>>>> On the first sight the change looks rather trivial. But, honestly, >>>>>> I'm not sure which other parts could for whatever reason break once >>>>>> the time-of-day timestamp is replaced with a monotonic equivalent. >>>>>> One would think that it shouldn't matter but one never knows ... >>>>>> >>>>>> Staffan, do you think this kind of change is suitable for the current >>>>>> phase of JDK release cycle? I think I could improve the patch in few >>>>>> days and then it should probably be able to pass the review before >>>>>> ZBB. But, it's only P3 ... >>>>> >>>>> I think it is a bit late in the release cycle to clean this up in the >>>>> way it should be cleaned up. I think we should wait until the first 8 >>>>> update release and do a more thorough job than we have time for right >>>>> now. >>>> >>>> I second that. The elapsed_counter/elpased_timer APIs and >>>> implementations are a tangled mess. But part of the problem has been >>>> that people want/expect monotonic time-of-day based timestamps (yes a >>>> contradiction - though some people make sure TOD does not get modified >>>> on their production systems). The use of timestamps in logging has >>>> to be >>>> examined carefully - mainly GC logging. I recall a "simple" attempted >>>> change in the past that resulted in trying to compare a nanoTime based >>>> timestamp with the TOD. :( >>> >>> Actually, if I'm reading the sources right for Solaris and Win the >>> monotonic clock source is used to provide elapsed_counter() value. It >>> falls back to TOD when the monotonic clock source is not available. >>> For Linux/BSD the TOD is used directly. >>> >>> This makes me wonder if changing the linux/bsd implementation to >>> follow the same logic would be really that disruptive. >> >> Good point. I would like a world where elapsed_counter is monotonic >> (where possible). Still a bit scary this late in the release, but an >> interesting experiment. > > The change is rather simple and tests ok. All the means to get a > monotonic timestamp are already there and proved to work. The core tests > in JPRT went fine. > > The updated webrev is at > http://cr.openjdk.java.net/~jbachorik/6523160/webrev.02 > > -JB- > >> >> /Staffan >> >> >> >> >>> >>> -JB- >>>> >>>> David >>>> ----- >>>> >>>>> /Staffan >>>>> >>>>> >>>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>> On 9 okt 2013, at 13:26, Jaroslav Bachorik >>>>>>> wrote: >>>>>>> >>>>>>>> On 8.10.2013 23:46, David Holmes wrote: >>>>>>>>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>>>>>>>> On 8.10.2013 09:34, David Holmes wrote: >>>>>>>>>>> Jaroslav, >>>>>>>>>>> >>>>>>>>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> currently the JVM uptime reported by the RuntimeMXBean is >>>>>>>>>>>> based on >>>>>>>>>>>> System.currentTimeMillis() which makes it susceptible to >>>>>>>>>>>> changes of the >>>>>>>>>>>> OS time (eg. changing timezone, NTP synchronization etc.). The >>>>>>>>>>>> uptime >>>>>>>>>>>> should not depend on the system time and should be calculated >>>>>>>>>>>> using a >>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>> >>>>>>>>>>>> There is already the way to get the actual JVM uptime in ticks. >>>>>>>>>>>> It is >>>>>>>>>>>> accessible as Management::timestamp() and the ticks are >>>>>>>>>>>> convertible to >>>>>>>>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus >>>>>>>>>>>> making it >>>>>>>>>>>> very >>>>>>>>>>>> easy to switch to the monotonic clock based uptime. >>>>>>>>>>> >>>>>>>>>>> Maybe I'm missing something but TiumeStamp updates using >>>>>>>>>>> os::elapsed_counter() which on Linux uses gettimeofday so is >>>>>>>>>>> not a >>>>>>>>>>> monotonic clock source. >>>>>>>>>> >>>>>>>>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>>>>>>>> >>>>>>>>>> Is there any reason why a non monotonic clock source is used for >>>>>>>>>> timestamping except of the historical one? os::javaTimeNanos() >>>>>>>>>> uses >>>>>>>>>> montonic clock when available - why can't be the same used for >>>>>>>>>> os::elapsed_counter() especially when a counter based on >>>>>>>>>> "gettimeofday" >>>>>>>>>> is not really a counter? >>>>>>>>> >>>>>>>>> It is all historical. These elapsed_counters and elapsed_timers >>>>>>>>> make me >>>>>>>>> cringe. But changing it has a lot of potential consequences >>>>>>>>> because of >>>>>>>>> the way these are used in logging etc. Certainly not something >>>>>>>>> to be >>>>>>>>> contemplated at this stage of JDK 8. >>>>>>>>> >>>>>>>>> Perhaps a simpler fix here is to expose a startUpTimeNanos that >>>>>>>>> can then >>>>>>>>> be used for the uptime. >>>>>>>> >>>>>>>> My attempt at this is at >>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >>>>>>>> I am using os::javaTimeNanos() to get the monotonic ticks where >>>>>>>> possible. >>>>>>>> >>>>>>>> The JDK part stays the same as for webrev.00 >>>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> The patch consists of the hotspot and jdk parts. >>>>>>>>>>>> >>>>>>>>>>>> For the hotspot a new constant needs to be introduced in >>>>>>>>>>>> src/share/vm/services/jmm.h and the actual logic to obtain the >>>>>>>>>>>> uptime in >>>>>>>>>>>> milliseconds is added in src/share/vm/services/management.cpp. >>>>>>>>>>>> >>>>>>>>>>>> For the jdk the changes comprise of adding the necessary JNI >>>>>>>>>>>> bridging >>>>>>>>>>>> methods in order to get the new uptime, introducing the same >>>>>>>>>>>> constant >>>>>>>>>>>> that is used in hotspot and changes to mapfile-vers files in >>>>>>>>>>>> order to >>>>>>>>>>>> properly build the native library. >>>>>>>>>>>> >>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>>>>>>>> Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> -JB- >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> > From serguei.spitsyn at oracle.com Tue Oct 15 00:42:41 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 15 Oct 2013 00:42:41 -0700 Subject: RFR (S): JDK-8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes In-Reply-To: <524BE733.2070205@oracle.com> References: <5249643F.3030209@oracle.com> <524A7B07.1000300@oracle.com> <524BE733.2070205@oracle.com> Message-ID: <525CF1F1.1010400@oracle.com> There are two questions on the list that we still need to resolve in this fix: (1) What is the best way to protect the work with CLDG from concurrent additions of CLD's to it (2) The *GetClassLoaderClasses* needs a fix as well to be consistent with the GetLoadedClasses I had some private conversations with Fredrik and John Rose and after some analysis came up with the suggestion: (1) Continue using the *SystemDictionary_lock* to protect consistency of the loaded classes data. The issue is that adding CLD's to the SLDG is not currently protected by the *SystemDictionary_lock*. I'm suggesting to add it to the *SystemDictionary::parse_stream* (please, see the webrev below). (2) There was some doubt that a similar fix for the *GetClassLoaderClasses* is needed because the CL+SD (taken from the host class) does not reference the associated anonymous classes. The question is: Can we consider the host's class CL as the initiating CL? My reading is that the answer to this question is: "Yes, we can". Even though the CL itself does not have references to its anonymous classes, there are references from the anonymous classes's CLD's to its CL. These references can be used in the *increment_with_loader* and *add_with_loader* the same way as it was before. This is a webrev that includes the Fredrik's fix as a base plus the implemented suggestion: http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/fredrik/8024423-JVMTI-ANO/ Some help from the HotSpot team is needed to estimate if this approach is Ok and does not have rat holes in it. Opinions are very welcome. Thanks, Serguei On 10/2/13 2:28 AM, Fredrik Arvidsson wrote: > Hi and thanks for all your comments. > > I have simplified the code in *instanceKlass.cpp* like suggested and > here is a new webrev: > http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.01/ > > > Regarding the need to synchronize the access to ClassLoaderDataGraph I > have come to the conclusion that it should be safe to call this > without any additional synchronization since newly loaded and added > classes are appended to the end of its 'list' of classes. This would > mean that the call could 'miss' the classes added during the > collection phase, but this is not a big issue. I hope that my > conclusion is correct. > > I believe that the JvmtiGetLoadedClasses::getClassLoaderClasses(...) > method is to be left alone this time since I got the impression that > only SystemDictionary 'knows' about initiating class loaders. > > There is plenty of room for improvement and simplification of much of > the code in this area, but I feel that it must wait until another > time. The task to re-factor and simplify would quickly grow out of > hands I'm afraid :) > > Cheers > /Fredrik > > On 2013-10-01 09:34, serguei.spitsyn at oracle.com wrote: >> Hi Frederik, >> >> >> Thank you for jumping on this issue! >> >> >> *src/share/vm/oops/instanceKlass.cpp* >> 2333 int src_index = 0; >> 2334 while (src_index < src_length) { >> 2335 dest[dest_index++] = src[src_index++]; >> 2336 } >> 2337 >> 2338 // If we have a hash, append it >> 2339 if(hash_len > 0) { >> 2340 int hash_index = 0; >> 2341 while (hash_index < hash_len) { >> 2342 dest[dest_index++] = hash_buf[hash_index++]; >> 2343 } >> 2344 } >> >> The above can be simplified a little bit: >> // Add the actual class name >> for (int src_index = 0; src_index < src_length; ) { >> dest[dest_index++] = src[src_index++]; >> } >> // If we have a hash, append it >> for (int hash_index = 0; hash_index < hash_len; ) { >> dest[dest_index++] = hash_buf[hash_index++]; >> } >> >> The conditionif(hash_len > 0) is covered by the loop itself. >> >> Style-related comments: >> -wrong indent at the lines: 2316-2319 >> - need a space after the 'if' at the lines: 2315, 2339 >> >> >> *src/share/vm/prims/jvmtiGetLoadedClasses.cpp >> >> *The copyright comment must be up-to-date. >> The comments at the lines 35-38, 258-260 are not valid anymore. >> >> >> > In this review I still have an outstanding unanswered question about >> > the need to synchronize the access to the: >> >> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >> > and >> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >> >> This kind of walking is usually done at safepoint in a VM_Operation. >> You will find many examples in the jvmtiEnv.cpp, for instance, VM_GetAllStackTraces. >> The suggestion from Mikael is good too. >> >> Should this fix include the getClassLoaderClasses() as well? >> I'm still trying to realize the impact and consistency of this fix. :( >> >> What tests are you going to run for verification? >> >> Thanks, >> Serguei >> * >> *On 9/30/13 4:45 AM, Fredrik Arvidsson wrote: >>> Hi >>> >>> Please help me to review the changes below: >>> >>> Jira case: https://bugs.openjdk.java.net/browse/JDK-8024423 >>> Webrev: >>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/ >>> >>> >>> In this review I still have an outstanding unanswered question about >>> the need to synchronize the access to the: >>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >>> and >>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >>> >>> calls in >>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/src/share/vm/prims/jvmtiGetLoadedClasses.cpp.udiff.html >>> >>> Please give me advise on this. >>> >>> There will be a review soon regarding re-enabling the tests that failed because of the above bug, see: >>> https://bugs.openjdk.java.net/browse/JDK-8025576 >>> >>> Cheers >>> /Fredrik >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131015/455a5c13/attachment-0001.html From jaroslav.bachorik at oracle.com Tue Oct 15 01:10:03 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 15 Oct 2013 10:10:03 +0200 Subject: RFR: 6804470 JvmstatCountersTest.java test times out on slower machines In-Reply-To: <525C33CD.4010505@oracle.com> References: <525C0C10.7000104@oracle.com> <525C33CD.4010505@oracle.com> Message-ID: <525CF85B.7080301@oracle.com> On 14.10.2013 20:11, Alan Bateman wrote: > On 14/10/2013 16:21, Jaroslav Bachorik wrote: >> Please, review the following simple change. >> >> The test times out on slower machines and I was able to reproduce the >> failure even on a normally fast machine using the fastdebug build. The >> timeout does not occur on every run - more like once in 10-15 runs. >> >> There is nothing really wrong with the test - it just takes rather >> long time to obtain the jvmstat counters. The remedy is to specify a >> longer timeout and see if it is enough. I am using 10 minutes for the >> timeout in the patch. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-6804470 >> Webrev: http://cr.openjdk.java.net/~jbachorik/6804470/webrev.00 >> >> Thanks, >> >> -JB- > This looks okay to me but if someone is testing a fastdebug build then > they really need to specify the -timeoutFactor option to jtreg so as to > scale the timeouts. Thanks for the review. I'm talking to QE about using the -timeoutFactor option in the automated test runs if possible. -JB- > > -Alan. From jaroslav.bachorik at oracle.com Tue Oct 15 01:37:15 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Tue, 15 Oct 2013 08:37:15 +0000 Subject: hg: jdk8/tl/jdk: 6804470: JvmstatCountersTest.java test times out on slower machines Message-ID: <20131015083748.D959C623D0@hg.openjdk.java.net> Changeset: abe8d432f714 Author: jbachorik Date: 2013-10-15 10:26 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/abe8d432f714 6804470: JvmstatCountersTest.java test times out on slower machines Summary: Increasing the default timeout to cater for the slower machines Reviewed-by: alanb ! test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java From erik.joelsson at oracle.com Tue Oct 15 02:33:18 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 15 Oct 2013 11:33:18 +0200 Subject: code review round 1 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <525C1330.2000407@oracle.com> References: <52585F31.5040107@oracle.com> <525B4FA1.7020109@oracle.com> <525C0B40.40109@oracle.com> <525C1330.2000407@oracle.com> Message-ID: <525D0BDE.90608@oracle.com> Daniel, Looks good to me. /Erik On 2013-10-14 17:52, Daniel D. Daugherty wrote: > On 10/14/13 9:18 AM, Daniel D. Daugherty wrote: >> On 10/13/13 7:57 PM, David Holmes wrote: >> >>> Hmm second comment - I don't see a .m4 file change that corresponds >>> to the DSYMUTIL configure change ?? >> >> Yikes! I'll check into that shortly. Not sure what happened here. > > I somehow missed/lost two 1-liner changes: > > hg diff common/autoconf/basics.m4 common/autoconf/spec.gmk.in > diff -r 4faa09c7fe55 common/autoconf/basics.m4 > --- a/common/autoconf/basics.m4 Wed Oct 02 15:08:03 2013 +0200 > +++ b/common/autoconf/basics.m4 Mon Oct 14 08:49:37 2013 -0700 > @@ -644,6 +644,7 @@ fi > fi > > if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then > + BASIC_REQUIRE_PROG(DSYMUTIL, dsymutil) > BASIC_REQUIRE_PROG(XATTR, xattr) > AC_PATH_PROG(CODESIGN, codesign) > if test "x$CODESIGN" != "x"; then > diff -r 4faa09c7fe55 common/autoconf/spec.gmk.in > --- a/common/autoconf/spec.gmk.in Wed Oct 02 15:08:03 2013 +0200 > +++ b/common/autoconf/spec.gmk.in Mon Oct 14 08:49:37 2013 -0700 > @@ -484,6 +484,7 @@ DATE:=@DATE@ > DATE:=@DATE@ > DIFF:=@DIFF@ > DIRNAME:=@DIRNAME@ > +DSYMUTIL:=@DSYMUTIL@ > FIND:=@FIND@ > FIND_DELETE:=@FIND_DELETE@ > ECHO:=@ECHO@ > > > I don't think that these two 1-liners are worth re-rolling the webrev. > Please let me know if you don't agree. > > Dan > > >> >> Dan >> >> >>> >>> Thanks, >>> David >>> >>> On 12/10/2013 6:27 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I'm ready for code review round 1 of the FDS on MacOS X hotspot >>>> changes. >>>> Below is the original code review round 0 invite (slightly edited for >>>> clarity). Working on FDS is like pulling a thread on a sweater... so >>>> there are four additional changed files along with more changes to >>>> many of the files from round 0. >>>> >>>> Here is the code review round 1 JDK8/HSX-25 webrev URL: >>>> >>>> OpenJDK: >>>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/1-jdk8/ >>>> Internal: >>>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/1-jdk8/ >>>> >>>> >>>> Changes from code review round 0 to round 1: >>>> >>>> root repo: >>>> - add configure support for DSYMUTIL macro >>>> >>>> hotspot repo: >>>> - drop Minimal1 config support for FDS on MacOS X >>>> - use DSYMUTIL macro instead of literal 'dsymutil' >>>> - fix FASTDEBUG_CFLAGS typo and add USE_CLANG support >>>> - STRIP is not used on MacOS X >>>> - fix $(UNIVERSAL_COPY_LIST) rule >>>> - refine install-dir function >>>> >>>> jdk repo: >>>> - add prep-target-dir, install-import-dir, and >>>> install-import-debuginfo >>>> functions >>>> - support importing .dSYM directories from hotspot >>>> - create libjsig.dSYM symlink from VM specific directory to >>>> the real location >>>> >>>> Files changed from code review round 0 to round 1: >>>> >>>> common/autoconf/generated-configure.sh >>>> hotspot/make/Makefile >>>> hotspot/make/bsd/makefiles/defs.make >>>> hotspot/make/bsd/makefiles/dtrace.make >>>> hotspot/make/bsd/makefiles/gcc.make >>>> hotspot/make/bsd/makefiles/jsig.make >>>> hotspot/make/bsd/makefiles/saproc.make >>>> hotspot/make/bsd/makefiles/universal.gmk >>>> hotspot/make/bsd/makefiles/vm.make >>>> hotspot/make/defs.make >>>> >>>> New files changed in code review round 1: >>>> >>>> hotspot/make/bsd/makefiles/product.make >>>> jdk/make/common/Defs.gmk >>>> jdk/make/java/redist/Makefile >>>> jdk/makefiles/Import.gmk >>>> >>>> Additional bugs filed based on code review comments, testing and >>>> just plain looking at the Makefiles: >>>> >>>> 8026280 implement Full Debug Symbols on MacOS X jdk >>>> 8026281 hotspot 'jdk6_or_earlier logic' for FDS needs to be >>>> removed >>>> 8026282 the '64' subdir logic in Makefiles might be removable >>>> 8026283 literal 'lipo' cmd uses in HotSpot makefiles >>>> 8026284 Minimal1 references/support should be removed from >>>> BSD/MacOS X >>>> 8026285 JPRT -buildenv ZIP_DEBUGINFO_FILES=0 no longer works >>>> >>>> As always, comments, questions and suggestions are welcome. >>>> >>>> Dan >>>> >>>> > Greetings, >>>> > >>>> > I have the initial support for Full Debug Symbols (FDS) on MacOS >>>> X done >>>> > and ready for review: >>>> > >>>> > 7165611 implement Full Debug Symbols on MacOS X hotspot >>>> > https://bugs.openjdk.java.net/browse/JDK-7165611 >>>> > >>>> > Here is the JDK8/HSX-25 webrev URL: >>>> > >>>> > OpenJDK: >>>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >>>> > Internal: >>>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >>>> >>>> > >>>> > This webrev includes changes for the follow repos: >>>> > >>>> > jdk8 >>>> > jdk8/hotspot >>>> > jdk8/jdk >>>> > >>>> > Once these changes are approved, I'm planning to push them to >>>> > RT_Baseline. From there, they can follow the normal path to >>>> > Main_Baseline and eventually JDK8. >>>> > >>>> > This work enables FDS on MacOS X for the 'hotspot' repo; the >>>> changes in >>>> > the other repos are necessary to support importing the .diz >>>> files from >>>> > the MacOS X 'hotspot' build into the forest build. I also fixed >>>> a few >>>> > FDS related errors in the magic incantations for the new build. >>>> This is >>>> > mostly a port from Linux -> MacOS X/BSD with the dtrace changes >>>> ported >>>> > from Solaris. In other words, this is Frankenstein's monster... >>>> > >>>> > Thanks to Staffan Larsen for providing an initial set of changes >>>> > which I morphed into what you see here. >>>> > >>>> > Testing: >>>> > - JPRT HSX build and test on all platforms; verification of .diz >>>> > files in the MacOS X JPRT bundles >>>> > - JPRT JDK8 forest build and test on all platforms; verification of >>>> > .diz files in the MacOS X JPRT bundles >>>> > Note: In previous FDS changesets, I also did a standalone 'jdk' >>>> > repo build and test, but that no longer seems to work. >>>> > >>>> > As always, comments, questions and suggestions are welcome. >>>> > >>>> > Dan >> >> > From alan.bateman at oracle.com Tue Oct 15 02:57:40 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 15 Oct 2013 09:57:40 +0000 Subject: hg: jdk8/tl/jdk: 8026398: Can't load jdk.Exported, ClassNotFoundException Message-ID: <20131015095854.93053623D7@hg.openjdk.java.net> Changeset: 0b6632e570b0 Author: alanb Date: 2013-10-15 10:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0b6632e570b0 8026398: Can't load jdk.Exported, ClassNotFoundException Reviewed-by: chegar, mchung ! make/tools/src/build/tools/buildmetaindex/BuildMetaIndex.java From thomas.schatzl at oracle.com Tue Oct 15 03:53:25 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 15 Oct 2013 12:53:25 +0200 Subject: RFR (S): 8025925: jmap fails with "field _length not found in type HeapRegionSeq" Message-ID: <1381834405.2686.75.camel@cirrus> Hi all, can I have reviews for the following change? It updates the SA agent that got out of date after the changes for JDK-7163191 where the HeapRegionSeq class has been refactored. The changes mirror the changes in the C++ code of that revision, adding a G1HeapRegionTable java class, and the associated modifications in the HeapRegionSeq class. There have been no interface changes to the HeapRegionSeq class to avoid breakage of any tools depending on it. Webrev: http://cr.openjdk.java.net/~tschatzl/8025925/webrev/ Testing: Connecting an SA-agent with the change on a running java program; test case in bug report (I added the serviceability-dev mailing list as additional recipients as the change also concerns this part of the VM) Thanks, Thomas From daniel.fuchs at oracle.com Tue Oct 15 04:02:03 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Tue, 15 Oct 2013 11:02:03 +0000 Subject: hg: jdk8/tl/jdk: 8026404: Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") Message-ID: <20131015110224.D7D07623E3@hg.openjdk.java.net> Changeset: 2c16140fb515 Author: dfuchs Date: 2013-10-15 13:01 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c16140fb515 8026404: Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") Summary: The test 'threadGroup.getParent() == null' can sometimes throw ACE and needs to be wrapped in doPrivileged. Reviewed-by: alanb, mchung, dholmes ! src/share/classes/sun/awt/AppContext.java ! test/TEST.groups + test/java/util/logging/TestMainAppContext.java From fredrik.arvidsson at oracle.com Tue Oct 15 05:08:58 2013 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Tue, 15 Oct 2013 14:08:58 +0200 Subject: RFR (S): JDK-8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes In-Reply-To: <525CF1F1.1010400@oracle.com> References: <5249643F.3030209@oracle.com> <524A7B07.1000300@oracle.com> <524BE733.2070205@oracle.com> <525CF1F1.1010400@oracle.com> Message-ID: <525D305A.4030907@oracle.com> I think this looks great. /Fredrik On 2013-10-15 09:42, serguei.spitsyn at oracle.com wrote: > > There are two questions on the list that we still need to resolve in > this fix: > (1) What is the best way to protect the work with CLDG from > concurrent additions of CLD's to it > (2) The *GetClassLoaderClasses* needs a fix as well to be consistent > with the GetLoadedClasses > > I had some private conversations with Fredrik and John Rose and > after some analysis came up with the suggestion: > > (1) Continue using the *SystemDictionary_lock* to protect > consistency of the loaded classes data. > The issue is that adding CLD's to the SLDG is not currently > protected by the *SystemDictionary_lock*. > I'm suggesting to add it to the > *SystemDictionary::parse_stream* (please, see the webrev below). > > (2) There was some doubt that a similar fix for the > *GetClassLoaderClasses* is needed because > the CL+SD (taken from the host class) does not reference the > associated anonymous classes. > The question is: Can we consider the host's class CL as the > initiating CL? > My reading is that the answer to this question is: "Yes, we can". > Even though the CL itself does not have references to its > anonymous classes, > there are references from the anonymous classes's CLD's to its CL. > These references can be used in the *increment_with_loader* and > *add_with_loader* > the same way as it was before. > > This is a webrev that includes the Fredrik's fix as a base plus the > implemented suggestion: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/fredrik/8024423-JVMTI-ANO/ > > Some help from the HotSpot team is needed to estimate if this approach > is Ok and does not have rat holes in it. > Opinions are very welcome. > > Thanks, > Serguei > > > On 10/2/13 2:28 AM, Fredrik Arvidsson wrote: >> Hi and thanks for all your comments. >> >> I have simplified the code in *instanceKlass.cpp* like suggested and >> here is a new webrev: >> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.01/ >> >> >> Regarding the need to synchronize the access to ClassLoaderDataGraph >> I have come to the conclusion that it should be safe to call this >> without any additional synchronization since newly loaded and added >> classes are appended to the end of its 'list' of classes. This would >> mean that the call could 'miss' the classes added during the >> collection phase, but this is not a big issue. I hope that my >> conclusion is correct. >> >> I believe that the JvmtiGetLoadedClasses::getClassLoaderClasses(...) >> method is to be left alone this time since I got the impression that >> only SystemDictionary 'knows' about initiating class loaders. >> >> There is plenty of room for improvement and simplification of much of >> the code in this area, but I feel that it must wait until another >> time. The task to re-factor and simplify would quickly grow out of >> hands I'm afraid :) >> >> Cheers >> /Fredrik >> >> On 2013-10-01 09:34, serguei.spitsyn at oracle.com wrote: >>> Hi Frederik, >>> >>> >>> Thank you for jumping on this issue! >>> >>> >>> *src/share/vm/oops/instanceKlass.cpp* >>> 2333 int src_index = 0; >>> 2334 while (src_index < src_length) { >>> 2335 dest[dest_index++] = src[src_index++]; >>> 2336 } >>> 2337 >>> 2338 // If we have a hash, append it >>> 2339 if(hash_len > 0) { >>> 2340 int hash_index = 0; >>> 2341 while (hash_index < hash_len) { >>> 2342 dest[dest_index++] = hash_buf[hash_index++]; >>> 2343 } >>> 2344 } >>> >>> The above can be simplified a little bit: >>> // Add the actual class name >>> for (int src_index = 0; src_index < src_length; ) { >>> dest[dest_index++] = src[src_index++]; >>> } >>> // If we have a hash, append it >>> for (int hash_index = 0; hash_index < hash_len; ) { >>> dest[dest_index++] = hash_buf[hash_index++]; >>> } >>> >>> The conditionif(hash_len > 0) is covered by the loop itself. >>> >>> Style-related comments: >>> -wrong indent at the lines: 2316-2319 >>> - need a space after the 'if' at the lines: 2315, 2339 >>> >>> >>> *src/share/vm/prims/jvmtiGetLoadedClasses.cpp >>> >>> *The copyright comment must be up-to-date. >>> The comments at the lines 35-38, 258-260 are not valid anymore. >>> >>> >>> > In this review I still have an outstanding unanswered question about >>> > the need to synchronize the access to the: >>> >>> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >>> > and >>> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >>> >>> This kind of walking is usually done at safepoint in a VM_Operation. >>> You will find many examples in the jvmtiEnv.cpp, for instance, VM_GetAllStackTraces. >>> The suggestion from Mikael is good too. >>> >>> Should this fix include the getClassLoaderClasses() as well? >>> I'm still trying to realize the impact and consistency of this fix. :( >>> >>> What tests are you going to run for verification? >>> >>> Thanks, >>> Serguei >>> * >>> *On 9/30/13 4:45 AM, Fredrik Arvidsson wrote: >>>> Hi >>>> >>>> Please help me to review the changes below: >>>> >>>> Jira case: https://bugs.openjdk.java.net/browse/JDK-8024423 >>>> Webrev: >>>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/ >>>> >>>> >>>> In this review I still have an outstanding unanswered question >>>> about the need to synchronize the access to the: >>>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >>>> and >>>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >>>> >>>> calls in >>>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/src/share/vm/prims/jvmtiGetLoadedClasses.cpp.udiff.html >>>> >>>> Please give me advise on this. >>>> >>>> There will be a review soon regarding re-enabling the tests that failed because of the above bug, see: >>>> https://bugs.openjdk.java.net/browse/JDK-8025576 >>>> >>>> Cheers >>>> /Fredrik >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131015/47f581dc/attachment-0001.html From magnus.ihse.bursie at oracle.com Tue Oct 15 05:21:38 2013 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 15 Oct 2013 14:21:38 +0200 Subject: code review round 1 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <52585F31.5040107@oracle.com> References: <52585F31.5040107@oracle.com> Message-ID: <525D3352.9000705@oracle.com> On 2013-10-11 22:27, Daniel D. Daugherty wrote: > Greetings, > > I'm ready for code review round 1 of the FDS on MacOS X hotspot changes. > Below is the original code review round 0 invite (slightly edited for > clarity). Working on FDS is like pulling a thread on a sweater... so > there are four additional changed files along with more changes to > many of the files from round 0. > > Here is the code review round 1 JDK8/HSX-25 webrev URL: > > OpenJDK: > http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/1-jdk8/ > Internal: > http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/1-jdk8/ New build system parts overall looks good. Just one note: Your webrev is based on the code before the whitespace/indentation cleanup. Please try to keep to the new indentation policy (see http://mail.openjdk.java.net/pipermail/build-dev/2013-October/010477.html) when merging. That means e.g. that code like: ifneq ($(OPENJDK_TARGET_OS), macosx) # OBJCOPY is not used on MacOS X ifneq ($(OPENJDK_TARGET_OS), windows) # nor on Windows shoud be properly indented and not on the same level. /Magnus From fredrik.arvidsson at oracle.com Tue Oct 15 05:48:14 2013 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Tue, 15 Oct 2013 14:48:14 +0200 Subject: RFR (S) 8025638: jmap returns 0 instead of 1 when it fails. In-Reply-To: <5256BE5C.4070406@oracle.com> References: <5256847D.6060103@oracle.com> <918A0955-6236-4916-BD54-F344EC9AADEA@oracle.com> <423EB291-3E36-41F7-86F6-6362D0B49839@oracle.com> <5256BE5C.4070406@oracle.com> Message-ID: <525D398E.3010802@oracle.com> I have created a new review of this with the changes suggested. The review can be found here: http://cr.openjdk.java.net/~allwin/farvidss/8025638/webrev.01/ /F On 2013-10-10 16:49, Kevin Walls wrote: > > Hi, > > Yes the removal of System.exit didn't take the error value into > account. 8010278 removed the System.exit so these Tool classes were > usable by other tools. I suppose we can use it in main() as if we're > there we should be running as a standalone app. > > The execute method seems like a nice simplification for the Tools. An > external app that wants to call one of the Tools can't use it, as it > may call System.exit (and you don't want to make execute return an int > as then every Tool class has to have more logic in its main() ). > > nits in Tool.java > 115 { should be on the same line as execute definition begins. > 120 } finally { on one line > > I don't think stop() should become private, an existing app that used > "public void start()" would expect to call a public stop(). > > There are a few other files that might want looking at to get them > returning an error code: CLHSDB and HSDB (CommandProcessor looks OK, > it only had System.exit(0) removed.) That could be a separate bug... > > Thanks! > Kevin > > > On 10/10/13 12:49, Staffan Larsen wrote: >> Thanks for doing this! >> >> Tool.java:116 - shouldn't the default return value be 1? In case >> start() throws an exception for some reason. >> >> Tool.java: I find the start(String[] args), start(), startInternal() >> methods confusing in naming and usage. Not directly related to your >> change of course, just a comment on the code. >> >> /Staffan >> >> >> On 10 okt 2013, at 13:38, Staffan Larsen > > wrote: >> >>> Clicking on the link in this email takes me to the wrong webrev. The >>> correct URL is in the text: >>> http://cr.openjdk.java.net/~allwin/farvidss/8025638/webrev.00/ >>> >>> >>> /Staffan >>> >>> On 10 okt 2013, at 12:42, Fredrik Arvidsson >>> > >>> wrote: >>> >>>> Hi >>>> >>>> Please help me to review the changes below: >>>> >>>> Jira case: https://bugs.openjdk.java.net/browse/JDK-8025638 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~allwin/farvidss/8025638/webrev.00/ >>>> >>>> >>>> About this change. >>>> A previous change >>>> (https://bugs.openjdk.java.net/browse/JDK-8010278) in the Tool.java >>>> class caused any tool deriving from this base class return the >>>> wrong value to the caller when failing. >>>> Changes were made to the Tool.java class and to the derived tool >>>> implementation classes to handle errors/exceptions during execution >>>> and ensure that the tool returns 1 to the caller if it fails, and 0 >>>> if it succeeds. >>>> >>>> Previously failed Aurora tests have been run using UTE and verified >>>> to PASS. >>>> >>>> Cheers >>>> /Fredrik >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131015/65026c70/attachment.html From jaroslav.bachorik at oracle.com Tue Oct 15 06:01:32 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 15 Oct 2013 15:01:32 +0200 Subject: RFR: 6804470 JvmstatCountersTest.java test times out on slower machines In-Reply-To: <525C33CD.4010505@oracle.com> References: <525C0C10.7000104@oracle.com> <525C33CD.4010505@oracle.com> Message-ID: <525D3CAC.1030905@oracle.com> On 14.10.2013 20:11, Alan Bateman wrote: > On 14/10/2013 16:21, Jaroslav Bachorik wrote: >> Please, review the following simple change. >> >> The test times out on slower machines and I was able to reproduce the >> failure even on a normally fast machine using the fastdebug build. The >> timeout does not occur on every run - more like once in 10-15 runs. >> >> There is nothing really wrong with the test - it just takes rather >> long time to obtain the jvmstat counters. The remedy is to specify a >> longer timeout and see if it is enough. I am using 10 minutes for the >> timeout in the patch. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-6804470 >> Webrev: http://cr.openjdk.java.net/~jbachorik/6804470/webrev.00 >> >> Thanks, >> >> -JB- > This looks okay to me but if someone is testing a fastdebug build then > they really need to specify the -timeoutFactor option to jtreg so as to > scale the timeouts. Just FYI - the SQE does use timeoutFactor 8x for the fastdebug runs. I hope this will be enough in combination with the extended timeout in the tests. -JB- > > -Alan. From mikael.gerdin at oracle.com Tue Oct 15 06:04:54 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 15 Oct 2013 15:04:54 +0200 Subject: RFR (S): 8025925: jmap fails with "field _length not found in type HeapRegionSeq" In-Reply-To: <1381834405.2686.75.camel@cirrus> References: <1381834405.2686.75.camel@cirrus> Message-ID: <2074018.Y459eaC083@mgerdin03> Thomas, On Tuesday 15 October 2013 12.53.25 Thomas Schatzl wrote: > Hi all, > > can I have reviews for the following change? It updates the SA agent > that got out of date after the changes for JDK-7163191 where the > HeapRegionSeq class has been refactored. > > The changes mirror the changes in the C++ code of that revision, adding > a G1HeapRegionTable java class, and the associated modifications in the > HeapRegionSeq class. > > There have been no interface changes to the HeapRegionSeq class to avoid > breakage of any tools depending on it. > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8025925/webrev/ Why did you change the copyright header format? "2011, 2013" is the format we should use, where 2011 is the first year and 2013 is the year when it was last modified. Otherwise I think the changes look good. Do you know if any part of the SA code base actually uses this class? /Mikael > > Testing: > Connecting an SA-agent with the change on a running java program; test > case in bug report > > (I added the serviceability-dev mailing list as additional recipients as > the change also concerns this part of the VM) > > Thanks, > Thomas From yekaterina.kantserova at oracle.com Tue Oct 15 06:35:12 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 15 Oct 2013 15:35:12 +0200 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd Message-ID: <525D4490.3070506@oracle.com> Hi, Could I please have a review of this fix. The purpose of this fix is to get rid of intermittent failures in sun/tools/jstatd tests and make the tests more stable, legible and maintainable. Thanks, Katja Webrev: http://cr.openjdk.java.net/~ykantser/8022229/webrev.00/ Primal bug: https://bugs.openjdk.java.net/browse/JDK-8022229 Similar bugs: https://bugs.openjdk.java.net/browse/JDK-8019630 https://bugs.openjdk.java.net/browse/JDK-6636094 https://bugs.openjdk.java.net/browse/JDK-6543979 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131015/93b0185c/attachment.html From kevin.walls at oracle.com Tue Oct 15 06:56:33 2013 From: kevin.walls at oracle.com (Kevin Walls) Date: Tue, 15 Oct 2013 14:56:33 +0100 Subject: RFR (S) 8025638: jmap returns 0 instead of 1 when it fails. In-Reply-To: <525D398E.3010802@oracle.com> References: <5256847D.6060103@oracle.com> <918A0955-6236-4916-BD54-F344EC9AADEA@oracle.com> <423EB291-3E36-41F7-86F6-6362D0B49839@oracle.com> <5256BE5C.4070406@oracle.com> <525D398E.3010802@oracle.com> Message-ID: <525D4991.4050304@oracle.com> Hi Fredrik, Yes, I think that looks good. Thanks! Kevin On 15/10/13 13:48, Fredrik Arvidsson wrote: > I have created a new review of this with the changes suggested. > > The review can be found here: > http://cr.openjdk.java.net/~allwin/farvidss/8025638/webrev.01/ > > > /F > > On 2013-10-10 16:49, Kevin Walls wrote: >> >> Hi, >> >> Yes the removal of System.exit didn't take the error value into >> account. 8010278 removed the System.exit so these Tool classes were >> usable by other tools. I suppose we can use it in main() as if we're >> there we should be running as a standalone app. >> >> The execute method seems like a nice simplification for the Tools. >> An external app that wants to call one of the Tools can't use it, as >> it may call System.exit (and you don't want to make execute return an >> int as then every Tool class has to have more logic in its main() ). >> >> nits in Tool.java >> 115 { should be on the same line as execute definition begins. >> 120 } finally { on one line >> >> I don't think stop() should become private, an existing app that used >> "public void start()" would expect to call a public stop(). >> >> There are a few other files that might want looking at to get them >> returning an error code: CLHSDB and HSDB (CommandProcessor looks OK, >> it only had System.exit(0) removed.) That could be a separate bug... >> >> Thanks! >> Kevin >> >> >> On 10/10/13 12:49, Staffan Larsen wrote: >>> Thanks for doing this! >>> >>> Tool.java:116 - shouldn't the default return value be 1? In case >>> start() throws an exception for some reason. >>> >>> Tool.java: I find the start(String[] args), start(), startInternal() >>> methods confusing in naming and usage. Not directly related to your >>> change of course, just a comment on the code. >>> >>> /Staffan >>> >>> >>> On 10 okt 2013, at 13:38, Staffan Larsen >> > wrote: >>> >>>> Clicking on the link in this email takes me to the wrong webrev. >>>> The correct URL is in the text: >>>> http://cr.openjdk.java.net/~allwin/farvidss/8025638/webrev.00/ >>>> >>>> >>>> /Staffan >>>> >>>> On 10 okt 2013, at 12:42, Fredrik Arvidsson >>>> >>> > wrote: >>>> >>>>> Hi >>>>> >>>>> Please help me to review the changes below: >>>>> >>>>> Jira case: https://bugs.openjdk.java.net/browse/JDK-8025638 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~allwin/farvidss/8025638/webrev.00/ >>>>> >>>>> >>>>> About this change. >>>>> A previous change >>>>> (https://bugs.openjdk.java.net/browse/JDK-8010278) in the >>>>> Tool.java class caused any tool deriving from this base class >>>>> return the wrong value to the caller when failing. >>>>> Changes were made to the Tool.java class and to the derived tool >>>>> implementation classes to handle errors/exceptions during >>>>> execution and ensure that the tool returns 1 to the caller if it >>>>> fails, and 0 if it succeeds. >>>>> >>>>> Previously failed Aurora tests have been run using UTE and >>>>> verified to PASS. >>>>> >>>>> Cheers >>>>> /Fredrik >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131015/7a8da349/attachment-0001.html From thomas.schatzl at oracle.com Tue Oct 15 07:08:52 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 15 Oct 2013 16:08:52 +0200 Subject: RFR (S): 8025925: jmap fails with "field _length not found in type HeapRegionSeq" In-Reply-To: <2074018.Y459eaC083@mgerdin03> References: <1381834405.2686.75.camel@cirrus> <2074018.Y459eaC083@mgerdin03> Message-ID: <1381846132.27069.14.camel@cirrus> Hi, On Tue, 2013-10-15 at 15:04 +0200, Mikael Gerdin wrote: > Thomas, > > On Tuesday 15 October 2013 12.53.25 Thomas Schatzl wrote: > > Hi all, > > > > can I have reviews for the following change? It updates the SA agent > > that got out of date after the changes for JDK-7163191 where the > > HeapRegionSeq class has been refactored. > > > > The changes mirror the changes in the C++ code of that revision, adding > > a G1HeapRegionTable java class, and the associated modifications in the > > HeapRegionSeq class. > > > > There have been no interface changes to the HeapRegionSeq class to avoid > > breakage of any tools depending on it. > > > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8025925/webrev/ > > Why did you change the copyright header format? > "2011, 2013" is the format we should use, where 2011 is the first year and > 2013 is the year when it was last modified. Okay, sorry. Fixed. Not sure what I thought when changing that. > Otherwise I think the changes look good. Do you know if any part of the SA > code base actually uses this class? Which one? HeapRegionSeq or the new G1HeapRegionTable class? HeapRegionSeq is used by the G1CollectedHeap class for the n_regions() and heap iteration during heap dump and liveness analysis it seems. In the change, the G1HeapRegionTable replaced the _regions field of HeapRegionSeq. I tried to follow what I thought was the style of the other code, i.e. try to stay close to the C++ object hierarchy. The new HeapRegionSeq mostly forwards requests to it to the new G1HeapRegionTable class. I could hide the latter (i.e. make it package private) if wanted and even move it into the HeapRegionSeq.java file (and remove the new file). I do not mind either way. Thanks, Thomas From jan.lahoda at oracle.com Tue Oct 15 07:24:33 2013 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Tue, 15 Oct 2013 14:24:33 +0000 Subject: hg: jdk8/tl/langtools: 8026180: com.sun.source.tree.NewArrayTree refers to com.sun.tools.javac.util.List Message-ID: <20131015142436.CBB89623EA@hg.openjdk.java.net> Changeset: 79649bf21a92 Author: jlahoda Date: 2013-10-15 16:23 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/79649bf21a92 8026180: com.sun.source.tree.NewArrayTree refers to com.sun.tools.javac.util.List Summary: Correcting import in NewArrayTree, adding test protecting againts improper types in API signatures Reviewed-by: jjg ! src/share/classes/com/sun/source/tree/NewArrayTree.java + test/tools/javac/tree/NoPrivateTypesExported.java From daniel.daugherty at oracle.com Tue Oct 15 07:31:25 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 15 Oct 2013 08:31:25 -0600 Subject: code review round 1 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <525CDB20.3070506@oracle.com> References: <52585F31.5040107@oracle.com> <525B4FA1.7020109@oracle.com> <525C0B40.40109@oracle.com> <525C1330.2000407@oracle.com> <525CDB20.3070506@oracle.com> Message-ID: <525D51BD.5000304@oracle.com> On 10/15/13 12:05 AM, David Holmes wrote: > On 15/10/2013 1:52 AM, Daniel D. Daugherty wrote: >> On 10/14/13 9:18 AM, Daniel D. Daugherty wrote: >>> On 10/13/13 7:57 PM, David Holmes wrote: >>> >>>> Hmm second comment - I don't see a .m4 file change that corresponds >>>> to the DSYMUTIL configure change ?? >>> >>> Yikes! I'll check into that shortly. Not sure what happened here. >> >> I somehow missed/lost two 1-liner changes: >> >> hg diff common/autoconf/basics.m4 common/autoconf/spec.gmk.in >> diff -r 4faa09c7fe55 common/autoconf/basics.m4 >> --- a/common/autoconf/basics.m4 Wed Oct 02 15:08:03 2013 +0200 >> +++ b/common/autoconf/basics.m4 Mon Oct 14 08:49:37 2013 -0700 >> @@ -644,6 +644,7 @@ fi >> fi >> >> if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then >> + BASIC_REQUIRE_PROG(DSYMUTIL, dsymutil) >> BASIC_REQUIRE_PROG(XATTR, xattr) >> AC_PATH_PROG(CODESIGN, codesign) >> if test "x$CODESIGN" != "x"; then >> diff -r 4faa09c7fe55 common/autoconf/spec.gmk.in >> --- a/common/autoconf/spec.gmk.in Wed Oct 02 15:08:03 2013 +0200 >> +++ b/common/autoconf/spec.gmk.in Mon Oct 14 08:49:37 2013 -0700 >> @@ -484,6 +484,7 @@ DATE:=@DATE@ >> DATE:=@DATE@ >> DIFF:=@DIFF@ >> DIRNAME:=@DIRNAME@ >> +DSYMUTIL:=@DSYMUTIL@ >> FIND:=@FIND@ >> FIND_DELETE:=@FIND_DELETE@ >> ECHO:=@ECHO@ >> >> >> I don't think that these two 1-liners are worth re-rolling the webrev. >> Please let me know if you don't agree. > > Look fine to me. Thanks for the review and for catching the miss/loss on my part. Dan > > David > >> Dan >> >> >>> >>> Dan >>> >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 12/10/2013 6:27 AM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I'm ready for code review round 1 of the FDS on MacOS X hotspot >>>>> changes. >>>>> Below is the original code review round 0 invite (slightly edited for >>>>> clarity). Working on FDS is like pulling a thread on a sweater... so >>>>> there are four additional changed files along with more changes to >>>>> many of the files from round 0. >>>>> >>>>> Here is the code review round 1 JDK8/HSX-25 webrev URL: >>>>> >>>>> OpenJDK: >>>>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/1-jdk8/ >>>>> Internal: >>>>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/1-jdk8/ >>>>> >>>>> >>>>> >>>>> Changes from code review round 0 to round 1: >>>>> >>>>> root repo: >>>>> - add configure support for DSYMUTIL macro >>>>> >>>>> hotspot repo: >>>>> - drop Minimal1 config support for FDS on MacOS X >>>>> - use DSYMUTIL macro instead of literal 'dsymutil' >>>>> - fix FASTDEBUG_CFLAGS typo and add USE_CLANG support >>>>> - STRIP is not used on MacOS X >>>>> - fix $(UNIVERSAL_COPY_LIST) rule >>>>> - refine install-dir function >>>>> >>>>> jdk repo: >>>>> - add prep-target-dir, install-import-dir, and >>>>> install-import-debuginfo >>>>> functions >>>>> - support importing .dSYM directories from hotspot >>>>> - create libjsig.dSYM symlink from VM specific directory to >>>>> the real location >>>>> >>>>> Files changed from code review round 0 to round 1: >>>>> >>>>> common/autoconf/generated-configure.sh >>>>> hotspot/make/Makefile >>>>> hotspot/make/bsd/makefiles/defs.make >>>>> hotspot/make/bsd/makefiles/dtrace.make >>>>> hotspot/make/bsd/makefiles/gcc.make >>>>> hotspot/make/bsd/makefiles/jsig.make >>>>> hotspot/make/bsd/makefiles/saproc.make >>>>> hotspot/make/bsd/makefiles/universal.gmk >>>>> hotspot/make/bsd/makefiles/vm.make >>>>> hotspot/make/defs.make >>>>> >>>>> New files changed in code review round 1: >>>>> >>>>> hotspot/make/bsd/makefiles/product.make >>>>> jdk/make/common/Defs.gmk >>>>> jdk/make/java/redist/Makefile >>>>> jdk/makefiles/Import.gmk >>>>> >>>>> Additional bugs filed based on code review comments, testing and >>>>> just plain looking at the Makefiles: >>>>> >>>>> 8026280 implement Full Debug Symbols on MacOS X jdk >>>>> 8026281 hotspot 'jdk6_or_earlier logic' for FDS needs to be >>>>> removed >>>>> 8026282 the '64' subdir logic in Makefiles might be removable >>>>> 8026283 literal 'lipo' cmd uses in HotSpot makefiles >>>>> 8026284 Minimal1 references/support should be removed from >>>>> BSD/MacOS X >>>>> 8026285 JPRT -buildenv ZIP_DEBUGINFO_FILES=0 no longer works >>>>> >>>>> As always, comments, questions and suggestions are welcome. >>>>> >>>>> Dan >>>>> >>>>> > Greetings, >>>>> > >>>>> > I have the initial support for Full Debug Symbols (FDS) on MacOS >>>>> X done >>>>> > and ready for review: >>>>> > >>>>> > 7165611 implement Full Debug Symbols on MacOS X hotspot >>>>> > https://bugs.openjdk.java.net/browse/JDK-7165611 >>>>> > >>>>> > Here is the JDK8/HSX-25 webrev URL: >>>>> > >>>>> > OpenJDK: >>>>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >>>>> > Internal: >>>>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >>>>> >>>>> >>>>> > >>>>> > This webrev includes changes for the follow repos: >>>>> > >>>>> > jdk8 >>>>> > jdk8/hotspot >>>>> > jdk8/jdk >>>>> > >>>>> > Once these changes are approved, I'm planning to push them to >>>>> > RT_Baseline. From there, they can follow the normal path to >>>>> > Main_Baseline and eventually JDK8. >>>>> > >>>>> > This work enables FDS on MacOS X for the 'hotspot' repo; the >>>>> changes in >>>>> > the other repos are necessary to support importing the .diz files >>>>> from >>>>> > the MacOS X 'hotspot' build into the forest build. I also fixed a >>>>> few >>>>> > FDS related errors in the magic incantations for the new build. >>>>> This is >>>>> > mostly a port from Linux -> MacOS X/BSD with the dtrace changes >>>>> ported >>>>> > from Solaris. In other words, this is Frankenstein's monster... >>>>> > >>>>> > Thanks to Staffan Larsen for providing an initial set of changes >>>>> > which I morphed into what you see here. >>>>> > >>>>> > Testing: >>>>> > - JPRT HSX build and test on all platforms; verification of .diz >>>>> > files in the MacOS X JPRT bundles >>>>> > - JPRT JDK8 forest build and test on all platforms; >>>>> verification of >>>>> > .diz files in the MacOS X JPRT bundles >>>>> > Note: In previous FDS changesets, I also did a standalone 'jdk' >>>>> > repo build and test, but that no longer seems to work. >>>>> > >>>>> > As always, comments, questions and suggestions are welcome. >>>>> > >>>>> > Dan >>> >>> >> From daniel.daugherty at oracle.com Tue Oct 15 07:38:51 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 15 Oct 2013 08:38:51 -0600 Subject: code review round 1 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <525CDBA8.7020903@oracle.com> References: <52585F31.5040107@oracle.com> <525B4FA1.7020109@oracle.com> <525C0B40.40109@oracle.com> <525CDBA8.7020903@oracle.com> Message-ID: <525D537B.1040803@oracle.com> On 10/15/13 12:07 AM, David Holmes wrote: > On 15/10/2013 1:18 AM, Daniel D. Daugherty wrote: >> Thanks for the re-review! >> >> >> On 10/13/13 7:57 PM, David Holmes wrote: >>> Hi Dan, >>> >>> Only further comment I have, and it may well be deferred for future >>> work, is that we should be able to abstract away the actual >>> "extension" used for the "debuginfo" file so that we don't need macosx >>> conditionals as much eg one: >>> >>> if macosx >>> DEBUGINFO_EXTENSION=dSYM >>> else >>> DEBUGINFO_EXTENSION=debuginfo >>> endif >>> >>> then eg: >>> >>> JSIG_DEBUGINFO := $(strip $(wildcard >>> $(HOTSPOT_DIST)/jre/lib$(OPENJDK_TARGET_CPU_LIBDIR)/libjsig.$DEBUGINFO_EXTENSION) >>> >>> \ >>> $(wildcard >>> $(HOTSPOT_DIST)/jre/lib$(OPENJDK_TARGET_CPU_LIBDIR)/libjsig.diz) ) >> >> The biggest worry that I have about something like DEBUGINFO_EXTENSION >> is that on MacOS X the '.dSYM' objects are directories instead of files. >> This requires that different cmd options be used in many/most/all of the >> cases. More thought would be needed. > > I agree that the main commands wouldn't benefit from this, but things > like the JSIG_DEBUGINFO definition would. Possibly. It would be good if I got some cycles to look at FDS again from a higher level with an eye toward overall simplification and clarification. Instead, we're again trying to get some changes done in time for another release deadline. > I must admit that I'm somewhat surprised that .dSYM being a directory > hasn't caused more problems. Hopefully, I've caught all the right places. JPRT jobs and manual builds (mine and Staffan's) indicate that things work. The proof in the pudding will be when a promoted build actually contains a proper "debuginfo" bundle from RE... > Anyway no blockers here. Thanks! And thanks for all of your help with and reviews of the dreaded FDS stuff... Most folks run screaming in the other direction from FDS changes... Dan > > Cheers, > David > >> >>> Hmm second comment - I don't see a .m4 file change that corresponds to >>> the DSYMUTIL configure change ?? >> >> Yikes! I'll check into that shortly. Not sure what happened here. >> >> Dan >> >> >>> >>> Thanks, >>> David >>> >>> On 12/10/2013 6:27 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I'm ready for code review round 1 of the FDS on MacOS X hotspot >>>> changes. >>>> Below is the original code review round 0 invite (slightly edited for >>>> clarity). Working on FDS is like pulling a thread on a sweater... so >>>> there are four additional changed files along with more changes to >>>> many of the files from round 0. >>>> >>>> Here is the code review round 1 JDK8/HSX-25 webrev URL: >>>> >>>> OpenJDK: >>>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/1-jdk8/ >>>> Internal: >>>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/1-jdk8/ >>>> >>>> >>>> Changes from code review round 0 to round 1: >>>> >>>> root repo: >>>> - add configure support for DSYMUTIL macro >>>> >>>> hotspot repo: >>>> - drop Minimal1 config support for FDS on MacOS X >>>> - use DSYMUTIL macro instead of literal 'dsymutil' >>>> - fix FASTDEBUG_CFLAGS typo and add USE_CLANG support >>>> - STRIP is not used on MacOS X >>>> - fix $(UNIVERSAL_COPY_LIST) rule >>>> - refine install-dir function >>>> >>>> jdk repo: >>>> - add prep-target-dir, install-import-dir, and >>>> install-import-debuginfo >>>> functions >>>> - support importing .dSYM directories from hotspot >>>> - create libjsig.dSYM symlink from VM specific directory to >>>> the real location >>>> >>>> Files changed from code review round 0 to round 1: >>>> >>>> common/autoconf/generated-configure.sh >>>> hotspot/make/Makefile >>>> hotspot/make/bsd/makefiles/defs.make >>>> hotspot/make/bsd/makefiles/dtrace.make >>>> hotspot/make/bsd/makefiles/gcc.make >>>> hotspot/make/bsd/makefiles/jsig.make >>>> hotspot/make/bsd/makefiles/saproc.make >>>> hotspot/make/bsd/makefiles/universal.gmk >>>> hotspot/make/bsd/makefiles/vm.make >>>> hotspot/make/defs.make >>>> >>>> New files changed in code review round 1: >>>> >>>> hotspot/make/bsd/makefiles/product.make >>>> jdk/make/common/Defs.gmk >>>> jdk/make/java/redist/Makefile >>>> jdk/makefiles/Import.gmk >>>> >>>> Additional bugs filed based on code review comments, testing and >>>> just plain looking at the Makefiles: >>>> >>>> 8026280 implement Full Debug Symbols on MacOS X jdk >>>> 8026281 hotspot 'jdk6_or_earlier logic' for FDS needs to be >>>> removed >>>> 8026282 the '64' subdir logic in Makefiles might be removable >>>> 8026283 literal 'lipo' cmd uses in HotSpot makefiles >>>> 8026284 Minimal1 references/support should be removed from >>>> BSD/MacOS X >>>> 8026285 JPRT -buildenv ZIP_DEBUGINFO_FILES=0 no longer works >>>> >>>> As always, comments, questions and suggestions are welcome. >>>> >>>> Dan >>>> >>>> > Greetings, >>>> > >>>> > I have the initial support for Full Debug Symbols (FDS) on MacOS X >>>> done >>>> > and ready for review: >>>> > >>>> > 7165611 implement Full Debug Symbols on MacOS X hotspot >>>> > https://bugs.openjdk.java.net/browse/JDK-7165611 >>>> > >>>> > Here is the JDK8/HSX-25 webrev URL: >>>> > >>>> > OpenJDK: >>>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >>>> > Internal: >>>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >>>> >>>> > >>>> > This webrev includes changes for the follow repos: >>>> > >>>> > jdk8 >>>> > jdk8/hotspot >>>> > jdk8/jdk >>>> > >>>> > Once these changes are approved, I'm planning to push them to >>>> > RT_Baseline. From there, they can follow the normal path to >>>> > Main_Baseline and eventually JDK8. >>>> > >>>> > This work enables FDS on MacOS X for the 'hotspot' repo; the >>>> changes in >>>> > the other repos are necessary to support importing the .diz files >>>> from >>>> > the MacOS X 'hotspot' build into the forest build. I also fixed >>>> a few >>>> > FDS related errors in the magic incantations for the new build. >>>> This is >>>> > mostly a port from Linux -> MacOS X/BSD with the dtrace changes >>>> ported >>>> > from Solaris. In other words, this is Frankenstein's monster... >>>> > >>>> > Thanks to Staffan Larsen for providing an initial set of changes >>>> > which I morphed into what you see here. >>>> > >>>> > Testing: >>>> > - JPRT HSX build and test on all platforms; verification of .diz >>>> > files in the MacOS X JPRT bundles >>>> > - JPRT JDK8 forest build and test on all platforms; verification of >>>> > .diz files in the MacOS X JPRT bundles >>>> > Note: In previous FDS changesets, I also did a standalone 'jdk' >>>> > repo build and test, but that no longer seems to work. >>>> > >>>> > As always, comments, questions and suggestions are welcome. >>>> > >>>> > Dan >> From daniel.daugherty at oracle.com Tue Oct 15 07:40:57 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 15 Oct 2013 08:40:57 -0600 Subject: code review round 1 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <35F352DE-BD93-4576-AC4B-8AF125A4A78E@oracle.com> References: <52585F31.5040107@oracle.com> <35F352DE-BD93-4576-AC4B-8AF125A4A78E@oracle.com> Message-ID: <525D53F9.2070900@oracle.com> Nothing like a willing victim^H^H^H^H^H^Htest user of your changes! Thanks! Dan On 10/15/13 12:30 AM, Staffan Larsen wrote: > I've been using this patch while debugging other issues and I now get full symbols in the debugger without a lot of manual work. So it's a go! > > Thanks, > /Staffan > > On 11 okt 2013, at 22:27, Daniel D. Daugherty wrote: > >> Greetings, >> >> I'm ready for code review round 1 of the FDS on MacOS X hotspot changes. >> Below is the original code review round 0 invite (slightly edited for >> clarity). Working on FDS is like pulling a thread on a sweater... so >> there are four additional changed files along with more changes to >> many of the files from round 0. >> >> Here is the code review round 1 JDK8/HSX-25 webrev URL: >> >> OpenJDK: http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/1-jdk8/ >> Internal: http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/1-jdk8/ >> >> Changes from code review round 0 to round 1: >> >> root repo: >> - add configure support for DSYMUTIL macro >> >> hotspot repo: >> - drop Minimal1 config support for FDS on MacOS X >> - use DSYMUTIL macro instead of literal 'dsymutil' >> - fix FASTDEBUG_CFLAGS typo and add USE_CLANG support >> - STRIP is not used on MacOS X >> - fix $(UNIVERSAL_COPY_LIST) rule >> - refine install-dir function >> >> jdk repo: >> - add prep-target-dir, install-import-dir, and install-import-debuginfo >> functions >> - support importing .dSYM directories from hotspot >> - create libjsig.dSYM symlink from VM specific directory to >> the real location >> >> Files changed from code review round 0 to round 1: >> >> common/autoconf/generated-configure.sh >> hotspot/make/Makefile >> hotspot/make/bsd/makefiles/defs.make >> hotspot/make/bsd/makefiles/dtrace.make >> hotspot/make/bsd/makefiles/gcc.make >> hotspot/make/bsd/makefiles/jsig.make >> hotspot/make/bsd/makefiles/saproc.make >> hotspot/make/bsd/makefiles/universal.gmk >> hotspot/make/bsd/makefiles/vm.make >> hotspot/make/defs.make >> >> New files changed in code review round 1: >> >> hotspot/make/bsd/makefiles/product.make >> jdk/make/common/Defs.gmk >> jdk/make/java/redist/Makefile >> jdk/makefiles/Import.gmk >> >> Additional bugs filed based on code review comments, testing and >> just plain looking at the Makefiles: >> >> 8026280 implement Full Debug Symbols on MacOS X jdk >> 8026281 hotspot 'jdk6_or_earlier logic' for FDS needs to be removed >> 8026282 the '64' subdir logic in Makefiles might be removable >> 8026283 literal 'lipo' cmd uses in HotSpot makefiles >> 8026284 Minimal1 references/support should be removed from BSD/MacOS X >> 8026285 JPRT -buildenv ZIP_DEBUGINFO_FILES=0 no longer works >> >> As always, comments, questions and suggestions are welcome. >> >> Dan >> >>> Greetings, >>> >>> I have the initial support for Full Debug Symbols (FDS) on MacOS X done >>> and ready for review: >>> >>> 7165611 implement Full Debug Symbols on MacOS X hotspot >>> https://bugs.openjdk.java.net/browse/JDK-7165611 >>> >>> Here is the JDK8/HSX-25 webrev URL: >>> >>> OpenJDK: http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >>> Internal: http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >>> >>> This webrev includes changes for the follow repos: >>> >>> jdk8 >>> jdk8/hotspot >>> jdk8/jdk >>> >>> Once these changes are approved, I'm planning to push them to >>> RT_Baseline. From there, they can follow the normal path to >>> Main_Baseline and eventually JDK8. >>> >>> This work enables FDS on MacOS X for the 'hotspot' repo; the changes in >>> the other repos are necessary to support importing the .diz files from >>> the MacOS X 'hotspot' build into the forest build. I also fixed a few >>> FDS related errors in the magic incantations for the new build. This is >>> mostly a port from Linux -> MacOS X/BSD with the dtrace changes ported >>> from Solaris. In other words, this is Frankenstein's monster... >>> >>> Thanks to Staffan Larsen for providing an initial set of changes >>> which I morphed into what you see here. >>> >>> Testing: >>> - JPRT HSX build and test on all platforms; verification of .diz >>> files in the MacOS X JPRT bundles >>> - JPRT JDK8 forest build and test on all platforms; verification of >>> .diz files in the MacOS X JPRT bundles >>> Note: In previous FDS changesets, I also did a standalone 'jdk' >>> repo build and test, but that no longer seems to work. >>> >>> As always, comments, questions and suggestions are welcome. >>> >>> Dan From daniel.daugherty at oracle.com Tue Oct 15 07:41:44 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 15 Oct 2013 08:41:44 -0600 Subject: code review round 1 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <525D0BDE.90608@oracle.com> References: <52585F31.5040107@oracle.com> <525B4FA1.7020109@oracle.com> <525C0B40.40109@oracle.com> <525C1330.2000407@oracle.com> <525D0BDE.90608@oracle.com> Message-ID: <525D5428.8000700@oracle.com> Thanks! Dan On 10/15/13 3:33 AM, Erik Joelsson wrote: > Daniel, > Looks good to me. > > /Erik > > On 2013-10-14 17:52, Daniel D. Daugherty wrote: >> On 10/14/13 9:18 AM, Daniel D. Daugherty wrote: >>> On 10/13/13 7:57 PM, David Holmes wrote: >>> >>>> Hmm second comment - I don't see a .m4 file change that corresponds >>>> to the DSYMUTIL configure change ?? >>> >>> Yikes! I'll check into that shortly. Not sure what happened here. >> >> I somehow missed/lost two 1-liner changes: >> >> hg diff common/autoconf/basics.m4 common/autoconf/spec.gmk.in >> diff -r 4faa09c7fe55 common/autoconf/basics.m4 >> --- a/common/autoconf/basics.m4 Wed Oct 02 15:08:03 2013 +0200 >> +++ b/common/autoconf/basics.m4 Mon Oct 14 08:49:37 2013 -0700 >> @@ -644,6 +644,7 @@ fi >> fi >> >> if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then >> + BASIC_REQUIRE_PROG(DSYMUTIL, dsymutil) >> BASIC_REQUIRE_PROG(XATTR, xattr) >> AC_PATH_PROG(CODESIGN, codesign) >> if test "x$CODESIGN" != "x"; then >> diff -r 4faa09c7fe55 common/autoconf/spec.gmk.in >> --- a/common/autoconf/spec.gmk.in Wed Oct 02 15:08:03 2013 +0200 >> +++ b/common/autoconf/spec.gmk.in Mon Oct 14 08:49:37 2013 -0700 >> @@ -484,6 +484,7 @@ DATE:=@DATE@ >> DATE:=@DATE@ >> DIFF:=@DIFF@ >> DIRNAME:=@DIRNAME@ >> +DSYMUTIL:=@DSYMUTIL@ >> FIND:=@FIND@ >> FIND_DELETE:=@FIND_DELETE@ >> ECHO:=@ECHO@ >> >> >> I don't think that these two 1-liners are worth re-rolling the webrev. >> Please let me know if you don't agree. >> >> Dan >> >> >>> >>> Dan >>> >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 12/10/2013 6:27 AM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I'm ready for code review round 1 of the FDS on MacOS X hotspot >>>>> changes. >>>>> Below is the original code review round 0 invite (slightly edited for >>>>> clarity). Working on FDS is like pulling a thread on a sweater... so >>>>> there are four additional changed files along with more changes to >>>>> many of the files from round 0. >>>>> >>>>> Here is the code review round 1 JDK8/HSX-25 webrev URL: >>>>> >>>>> OpenJDK: >>>>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/1-jdk8/ >>>>> Internal: >>>>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/1-jdk8/ >>>>> >>>>> >>>>> Changes from code review round 0 to round 1: >>>>> >>>>> root repo: >>>>> - add configure support for DSYMUTIL macro >>>>> >>>>> hotspot repo: >>>>> - drop Minimal1 config support for FDS on MacOS X >>>>> - use DSYMUTIL macro instead of literal 'dsymutil' >>>>> - fix FASTDEBUG_CFLAGS typo and add USE_CLANG support >>>>> - STRIP is not used on MacOS X >>>>> - fix $(UNIVERSAL_COPY_LIST) rule >>>>> - refine install-dir function >>>>> >>>>> jdk repo: >>>>> - add prep-target-dir, install-import-dir, and >>>>> install-import-debuginfo >>>>> functions >>>>> - support importing .dSYM directories from hotspot >>>>> - create libjsig.dSYM symlink from VM specific directory to >>>>> the real location >>>>> >>>>> Files changed from code review round 0 to round 1: >>>>> >>>>> common/autoconf/generated-configure.sh >>>>> hotspot/make/Makefile >>>>> hotspot/make/bsd/makefiles/defs.make >>>>> hotspot/make/bsd/makefiles/dtrace.make >>>>> hotspot/make/bsd/makefiles/gcc.make >>>>> hotspot/make/bsd/makefiles/jsig.make >>>>> hotspot/make/bsd/makefiles/saproc.make >>>>> hotspot/make/bsd/makefiles/universal.gmk >>>>> hotspot/make/bsd/makefiles/vm.make >>>>> hotspot/make/defs.make >>>>> >>>>> New files changed in code review round 1: >>>>> >>>>> hotspot/make/bsd/makefiles/product.make >>>>> jdk/make/common/Defs.gmk >>>>> jdk/make/java/redist/Makefile >>>>> jdk/makefiles/Import.gmk >>>>> >>>>> Additional bugs filed based on code review comments, testing and >>>>> just plain looking at the Makefiles: >>>>> >>>>> 8026280 implement Full Debug Symbols on MacOS X jdk >>>>> 8026281 hotspot 'jdk6_or_earlier logic' for FDS needs to be >>>>> removed >>>>> 8026282 the '64' subdir logic in Makefiles might be removable >>>>> 8026283 literal 'lipo' cmd uses in HotSpot makefiles >>>>> 8026284 Minimal1 references/support should be removed from >>>>> BSD/MacOS X >>>>> 8026285 JPRT -buildenv ZIP_DEBUGINFO_FILES=0 no longer works >>>>> >>>>> As always, comments, questions and suggestions are welcome. >>>>> >>>>> Dan >>>>> >>>>> > Greetings, >>>>> > >>>>> > I have the initial support for Full Debug Symbols (FDS) on >>>>> MacOS X done >>>>> > and ready for review: >>>>> > >>>>> > 7165611 implement Full Debug Symbols on MacOS X hotspot >>>>> > https://bugs.openjdk.java.net/browse/JDK-7165611 >>>>> > >>>>> > Here is the JDK8/HSX-25 webrev URL: >>>>> > >>>>> > OpenJDK: >>>>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/0-jdk8/ >>>>> > Internal: >>>>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/0-jdk8/ >>>>> >>>>> > >>>>> > This webrev includes changes for the follow repos: >>>>> > >>>>> > jdk8 >>>>> > jdk8/hotspot >>>>> > jdk8/jdk >>>>> > >>>>> > Once these changes are approved, I'm planning to push them to >>>>> > RT_Baseline. From there, they can follow the normal path to >>>>> > Main_Baseline and eventually JDK8. >>>>> > >>>>> > This work enables FDS on MacOS X for the 'hotspot' repo; the >>>>> changes in >>>>> > the other repos are necessary to support importing the .diz >>>>> files from >>>>> > the MacOS X 'hotspot' build into the forest build. I also fixed >>>>> a few >>>>> > FDS related errors in the magic incantations for the new build. >>>>> This is >>>>> > mostly a port from Linux -> MacOS X/BSD with the dtrace changes >>>>> ported >>>>> > from Solaris. In other words, this is Frankenstein's monster... >>>>> > >>>>> > Thanks to Staffan Larsen for providing an initial set of changes >>>>> > which I morphed into what you see here. >>>>> > >>>>> > Testing: >>>>> > - JPRT HSX build and test on all platforms; verification of .diz >>>>> > files in the MacOS X JPRT bundles >>>>> > - JPRT JDK8 forest build and test on all platforms; >>>>> verification of >>>>> > .diz files in the MacOS X JPRT bundles >>>>> > Note: In previous FDS changesets, I also did a standalone 'jdk' >>>>> > repo build and test, but that no longer seems to work. >>>>> > >>>>> > As always, comments, questions and suggestions are welcome. >>>>> > >>>>> > Dan >>> >>> >> > From daniel.daugherty at oracle.com Tue Oct 15 07:50:07 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 15 Oct 2013 08:50:07 -0600 Subject: code review round 1 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <525D3352.9000705@oracle.com> References: <52585F31.5040107@oracle.com> <525D3352.9000705@oracle.com> Message-ID: <525D561F.5010102@oracle.com> On 10/15/13 6:21 AM, Magnus Ihse Bursie wrote: > On 2013-10-11 22:27, Daniel D. Daugherty wrote: >> Greetings, >> >> I'm ready for code review round 1 of the FDS on MacOS X hotspot changes. >> Below is the original code review round 0 invite (slightly edited for >> clarity). Working on FDS is like pulling a thread on a sweater... so >> there are four additional changed files along with more changes to >> many of the files from round 0. >> >> Here is the code review round 1 JDK8/HSX-25 webrev URL: >> >> OpenJDK: >> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/1-jdk8/ >> Internal: >> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/1-jdk8/ > > New build system parts overall looks good. Just one note: Your webrev > is based on the code before the whitespace/indentation cleanup. Please > try to keep to the new indentation policy (see > http://mail.openjdk.java.net/pipermail/build-dev/2013-October/010477.html) > when merging. That means e.g. that code like: > > ifneq ($(OPENJDK_TARGET_OS), macosx) # OBJCOPY is not used > on MacOS X > ifneq ($(OPENJDK_TARGET_OS), windows) # nor on Windows Magnus, Thanks for the heads up on the style update. I will fix the above two lines to meet the new guidelines. > shoud be properly indented and not on the same level. I'm guessing that the logic from which I copied this style will be fixed in the upcoming Makefile push from the build-infra team. I'm in sync with JDK8-B111/HSX-25-B54 so I'm guessing that these changes haven't been pushed yet. Dan > > /Magnus From daniel.daugherty at oracle.com Tue Oct 15 08:04:59 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 15 Oct 2013 09:04:59 -0600 Subject: code review round 1 for Full Debug Symbols on MacOS X hotspot (7165611) In-Reply-To: <525D561F.5010102@oracle.com> References: <52585F31.5040107@oracle.com> <525D3352.9000705@oracle.com> <525D561F.5010102@oracle.com> Message-ID: <525D599B.7010905@oracle.com> On 10/15/13 8:50 AM, Daniel D. Daugherty wrote: > On 10/15/13 6:21 AM, Magnus Ihse Bursie wrote: >> On 2013-10-11 22:27, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I'm ready for code review round 1 of the FDS on MacOS X hotspot >>> changes. >>> Below is the original code review round 0 invite (slightly edited for >>> clarity). Working on FDS is like pulling a thread on a sweater... so >>> there are four additional changed files along with more changes to >>> many of the files from round 0. >>> >>> Here is the code review round 1 JDK8/HSX-25 webrev URL: >>> >>> OpenJDK: >>> http://cr.openjdk.java.net/~dcubed/fds_revamp/7165611-webrev/1-jdk8/ >>> Internal: >>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/7165611-webrev/1-jdk8/ >>> >> >> New build system parts overall looks good. Just one note: Your webrev >> is based on the code before the whitespace/indentation cleanup. >> Please try to keep to the new indentation policy (see >> http://mail.openjdk.java.net/pipermail/build-dev/2013-October/010477.html) >> when merging. That means e.g. that code like: >> >> ifneq ($(OPENJDK_TARGET_OS), macosx) # OBJCOPY is not used >> on MacOS X >> ifneq ($(OPENJDK_TARGET_OS), windows) # nor on Windows > > Magnus, > > Thanks for the heads up on the style update. I will fix the above > two lines to meet the new guidelines. > > >> shoud be properly indented and not on the same level. > > I'm guessing that the logic from which I copied this style will be > fixed in the upcoming Makefile push from the build-infra team. I'm > in sync with JDK8-B111/HSX-25-B54 so I'm guessing that these changes > haven't been pushed yet. > > Dan > > >> >> /Magnus Here's the diff: $ diff common/makefiles/NativeCompilation.gmk.cr1 common/makefiles/NativeCompilation.gmk 439c439 < ifneq ($(OPENJDK_TARGET_OS), windows) # nor on Windows --- > ifneq ($(OPENJDK_TARGET_OS), windows) # nor on Windows 463c463 < endif # !windows --- > endif # !windows 523c523 < ifneq ($(OPENJDK_TARGET_OS), windows) # nor on Windows --- > ifneq ($(OPENJDK_TARGET_OS), windows) # nor on Windows 547c547 < endif # !windows --- > endif # !windows I took a quick scan of the rest of patch and I didn't see anything jump out at me style-wise. If I missing something, we can follow up with another bug. Dan PS As a HotSpot guy, I'm happy to see the indent migrating from 4 spaces (or more) down to 2 space... From mikael.gerdin at oracle.com Tue Oct 15 09:15:36 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 15 Oct 2013 18:15:36 +0200 Subject: RFR (S): 8025925: jmap fails with "field _length not found in type HeapRegionSeq" In-Reply-To: <1381846132.27069.14.camel@cirrus> References: <1381834405.2686.75.camel@cirrus> <2074018.Y459eaC083@mgerdin03> <1381846132.27069.14.camel@cirrus> Message-ID: <141bce671a8.27d4.2bd8b3e304f6b680ef02ac6d3e44f07f@oracle.com> Thomas, On 15 October 2013 16:08:52 Thomas Schatzl wrote: > Hi, > > On Tue, 2013-10-15 at 15:04 +0200, Mikael Gerdin wrote: > > Thomas, > > On Tuesday 15 October 2013 12.53.25 Thomas Schatzl wrote: > > > Hi all, > > > > can I have reviews for the following change? It updates the SA agent > > > that got out of date after the changes for JDK-7163191 where the > > > HeapRegionSeq class has been refactored. > > > > The changes mirror the changes in the C++ code of that revision, adding > > > a G1HeapRegionTable java class, and the associated modifications in the > > > HeapRegionSeq class. > > > > There have been no interface changes to the HeapRegionSeq class to avoid > > > breakage of any tools depending on it. > > > > Webrev: > > > http://cr.openjdk.java.net/~tschatzl/8025925/webrev/ > > Why did you change the copyright header format? > > "2011, 2013" is the format we should use, where 2011 is the first year > and 2013 is the year when it was last modified. > > Okay, sorry. Fixed. Not sure what I thought when changing that. > > > Otherwise I think the changes look good. Do you know if any part of the > SA code base actually uses this class? > > Which one? HeapRegionSeq or the new G1HeapRegionTable class? > HeapRegionSeq is used by the G1CollectedHeap class for the n_regions() > and heap iteration during heap dump and liveness analysis it seems. In > the change, the G1HeapRegionTable replaced the _regions field of > HeapRegionSeq. I tried to follow what I thought was the style of the > other code, i.e. try to stay close to the C++ object hierarchy. > > The new HeapRegionSeq mostly forwards requests to it to the new > G1HeapRegionTable class. I could hide the latter (i.e. make it package > private) if wanted and even move it into the HeapRegionSeq.java file > (and remove the new file). Ok, in that case I'm fine with the code change as-is. I don't need to see the copyright year fix. Ship it, /Mikael > > I do not mind either way. > > Thanks, > Thomas > > From roger.riggs at oracle.com Tue Oct 15 10:41:17 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Tue, 15 Oct 2013 17:41:17 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20131015174243.6B6E7623FB@hg.openjdk.java.net> Changeset: ea422834f880 Author: rriggs Date: 2013-09-26 23:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ea422834f880 8025720: Separate temporal interface layer Summary: Remove ZoneId and Chronology from TemporalField interface Reviewed-by: sherman Contributed-by: scolebourne at joda.org ! src/share/classes/java/time/format/Parsed.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/JulianFields.java ! src/share/classes/java/time/temporal/TemporalField.java ! src/share/classes/java/time/temporal/WeekFields.java ! test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java Changeset: 110107410393 Author: scolebourne Date: 2013-07-09 21:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/110107410393 8025719: Change Chronology to an interface Summary: Split Chronology and add AbstractChronology Reviewed-by: darcy Contributed-by: scolebourne at joda.org + src/share/classes/java/time/chrono/AbstractChronology.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/HijrahChronology.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/chrono/MinguoChronology.java ! src/share/classes/java/time/chrono/Ser.java ! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! test/java/time/tck/java/time/chrono/CopticChronology.java Changeset: 087c8c1d2631 Author: rriggs Date: 2013-10-15 13:14 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/087c8c1d2631 8025722: TemporalAdjusters and TemporalQueries Summary: Move static from interfaces methods to supporting classes Reviewed-by: sherman ! src/share/classes/java/time/DayOfWeek.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/Month.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/chrono/AbstractChronology.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoPeriodImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/Era.java ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/DateTimePrintContext.java ! src/share/classes/java/time/format/Parsed.java ! src/share/classes/java/time/temporal/TemporalAccessor.java ! src/share/classes/java/time/temporal/TemporalAdjuster.java ! src/share/classes/java/time/temporal/TemporalAdjusters.java ! src/share/classes/java/time/temporal/TemporalAmount.java ! src/share/classes/java/time/temporal/TemporalQueries.java ! src/share/classes/java/time/temporal/TemporalQuery.java ! src/share/classes/java/time/temporal/package-info.java ! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/java/util/Formatter.java ! test/java/time/tck/java/time/TCKDayOfWeek.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKMonth.java ! test/java/time/tck/java/time/TCKMonthDay.java ! test/java/time/tck/java/time/TCKOffsetDateTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZoneId.java ! test/java/time/tck/java/time/TCKZoneOffset.java ! test/java/time/tck/java/time/TCKZonedDateTime.java ! test/java/time/tck/java/time/TestIsoChronology.java ! test/java/time/tck/java/time/chrono/CopticDate.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java ! test/java/time/tck/java/time/chrono/TCKIsoChronology.java ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java ! test/java/time/tck/java/time/chrono/TCKMinguoChronology.java ! test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java ! test/java/time/tck/java/time/format/TCKChronoPrinterParser.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java ! test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java ! test/java/time/tck/java/time/format/TCKLocalizedPrinterParser.java ! test/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java ! test/java/time/tck/java/time/temporal/TCKTemporalAdjusters.java ! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java ! test/java/time/test/java/time/format/TestCharLiteralParser.java ! test/java/time/test/java/time/format/TestNonIsoFormatter.java ! test/java/time/test/java/time/format/TestNumberParser.java ! test/java/time/test/java/time/format/TestStringLiteralParser.java ! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java ! test/java/time/test/java/util/TestFormatter.java From bhavesh.x.patel at oracle.com Tue Oct 15 11:21:01 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Tue, 15 Oct 2013 18:21:01 +0000 Subject: hg: jdk8/tl/langtools: 8026370: javadoc creates empty Message-ID: <20131015182106.98FF0623FE@hg.openjdk.java.net> Changeset: bf6b11347b1a Author: bpatel Date: 2013-10-15 11:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bf6b11347b1a 8026370: javadoc creates empty Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/ContentBuilder.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java + test/com/sun/javadoc/testTagOutput/TestTagOutput.java + test/com/sun/javadoc/testTagOutput/pkg1/DeprecatedTag.java From vicente.romero at oracle.com Tue Oct 15 11:38:09 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 15 Oct 2013 18:38:09 +0000 Subject: hg: jdk8/tl/langtools: 8025816: javac crash with method reference with a type variable as the site Message-ID: <20131015183812.DACE9623FF@hg.openjdk.java.net> Changeset: 70a301b35e71 Author: vromero Date: 2013-10-15 19:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/70a301b35e71 8025816: javac crash with method reference with a type variable as the site Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/lambda/T8025816/CrashMethodReferenceWithSiteTypeVarTest.java From chris.hegarty at oracle.com Tue Oct 15 13:00:51 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Oct 2013 20:00:51 +0000 Subject: hg: jdk8/tl: 3 new changesets Message-ID: <20131015200051.825F66240B@hg.openjdk.java.net> Changeset: af87dabb4263 Author: msheppar Date: 2013-06-14 15:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/af87dabb4263 8011157: Improve CORBA portablility Summary: fix also reviewed by Alexander Fomin Reviewed-by: alanb, coffeys, skoivu ! common/makefiles/RMICompilation.gmk Changeset: ce8c63017f11 Author: chegar Date: 2013-10-13 21:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ce8c63017f11 Merge Changeset: 28be3d174c92 Author: chegar Date: 2013-10-15 13:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/28be3d174c92 Merge From vicente.romero at oracle.com Tue Oct 15 13:04:14 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 15 Oct 2013 20:04:14 +0000 Subject: hg: jdk8/tl/langtools: 8024947: javac should issue the potentially ambiguous overload warning only where the problem appears Message-ID: <20131015200431.BC4DF6240C@hg.openjdk.java.net> Changeset: d8d6b58f1ebf Author: vromero Date: 2013-10-15 21:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d8d6b58f1ebf 8024947: javac should issue the potentially ambiguous overload warning only where the problem appears Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/lambda/T8024947/PotentiallyAmbiguousWarningTest.java + test/tools/javac/lambda/T8024947/PotentiallyAmbiguousWarningTest.out From chris.hegarty at oracle.com Tue Oct 15 13:04:38 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Oct 2013 20:04:38 +0000 Subject: hg: jdk8/tl/jaxp: 14 new changesets Message-ID: <20131015200522.8F7FD6240D@hg.openjdk.java.net> Changeset: ecb66dc473c1 Author: joehw Date: 2013-07-16 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/ecb66dc473c1 8012425: Transform TransformerFactory Reviewed-by: alanb, dfuchs, mullan ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java Changeset: 7a2014318343 Author: joehw Date: 2013-07-17 09:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/7a2014318343 8017298: Better XML support Reviewed-by: alanb, dfuchs, mullan, lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/com/sun/org/apache/xerces/internal/impl/xs/models/CMNodeFactory.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/SecurityConfiguration.java - src/com/sun/org/apache/xerces/internal/util/SecurityManager.java ! src/com/sun/org/apache/xerces/internal/util/SymbolTable.java + src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/com/sun/xml/internal/stream/Entity.java Changeset: a59549c3ad60 Author: dfuchs Date: 2013-07-17 18:46 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a59549c3ad60 8013502: Improve stream factories Reviewed-by: joehw, mullan, lancea ! src/javax/xml/stream/FactoryFinder.java Changeset: 4b0b2b5c4cc8 Author: chegar Date: 2013-07-22 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/4b0b2b5c4cc8 Merge Changeset: 40b8abe19642 Author: chegar Date: 2013-07-29 14:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/40b8abe19642 Merge ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java Changeset: 720db2e27962 Author: joehw Date: 2013-07-31 00:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/720db2e27962 8014530: Better digital signature processing Reviewed-by: alanb, dfuchs, mullan, lancea ! src/com/sun/org/apache/xalan/internal/XalanConstants.java + src/com/sun/org/apache/xalan/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xalan/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Import.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Include.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesHandlerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java ! src/com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl.java ! src/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/impl/XML11NSDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/com/sun/org/apache/xerces/internal/impl/xs/models/CMNodeFactory.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StAXValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/SecurityConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java + src/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java Changeset: cd9347628c7c Author: joehw Date: 2013-07-31 10:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/cd9347628c7c 8021366: java_util/Properties/PropertiesWithOtherEncodings fails during 7u45 nightly testing Reviewed-by: lancea, alanb, dfuchs, mullan ! src/com/sun/xml/internal/stream/Entity.java Changeset: ecbddaa85462 Author: chegar Date: 2013-08-02 11:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/ecbddaa85462 Merge Changeset: c5e80c1fa32f Author: chegar Date: 2013-08-09 14:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/c5e80c1fa32f Merge ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java Changeset: f952c33ebfdb Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f952c33ebfdb Merge Changeset: ce16a5aa1507 Author: joehw Date: 2013-08-20 09:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/ce16a5aa1507 8022682: Supporting XOM Reviewed-by: alanb, chegar, lancea ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/parsers/DOMParser.java ! src/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xerces/internal/parsers/XMLParser.java + src/com/sun/org/apache/xerces/internal/util/SecurityManager.java ! src/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java Changeset: cc3b64366048 Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/cc3b64366048 Merge Changeset: 2b77e12ff69d Author: chegar Date: 2013-10-11 19:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2b77e12ff69d Merge ! src/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java ! src/com/sun/org/apache/xerces/internal/util/SecurityManager.java Changeset: 6f220761f643 Author: chegar Date: 2013-10-15 14:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6f220761f643 Merge From chris.hegarty at oracle.com Tue Oct 15 13:06:26 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Oct 2013 20:06:26 +0000 Subject: hg: jdk8/tl/jaxws: 11 new changesets Message-ID: <20131015200656.D6AA46240E@hg.openjdk.java.net> Changeset: 43240b8b995b Author: mkos Date: 2013-08-01 16:09 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/43240b8b995b 8017505: Better Client Service Reviewed-by: mullan, ahgross, mgrebac ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/AbstractInstanceResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/InstanceResolver.java + src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/MethodUtil.java + src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/MethodUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/client/sei/SEIStub.java + src/share/jaxws_classes/com/sun/xml/internal/ws/policy/privateutil/MethodUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/policy/privateutil/PolicyUtils.java Changeset: 358f32260d1f Author: chegar Date: 2013-08-02 11:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/358f32260d1f Merge Changeset: 5212665bea32 Author: chegar Date: 2013-08-09 14:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/5212665bea32 Merge Changeset: d9704ab517d5 Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d9704ab517d5 Merge Changeset: fca8869ccfd0 Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/fca8869ccfd0 Merge Changeset: a6e2adde013e Author: chegar Date: 2013-08-30 10:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/a6e2adde013e Merge Changeset: f6376ba97cea Author: chegar Date: 2013-09-06 09:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/f6376ba97cea Merge Changeset: d3a65e8912c9 Author: chegar Date: 2013-09-14 20:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d3a65e8912c9 Merge Changeset: da8141b6e344 Author: chegar Date: 2013-10-03 19:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/da8141b6e344 Merge Changeset: 2dc8ae7eb53b Author: chegar Date: 2013-10-11 19:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/2dc8ae7eb53b Merge Changeset: 01facfebe17b Author: chegar Date: 2013-10-15 13:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/01facfebe17b Merge From chris.hegarty at oracle.com Tue Oct 15 13:21:42 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Oct 2013 20:21:42 +0000 Subject: hg: jdk8/tl/corba: 15 new changesets Message-ID: <20131015202154.91C4562411@hg.openjdk.java.net> Changeset: 81d694b1ab2f Author: msheppar Date: 2013-06-14 16:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/81d694b1ab2f 8011157: Improve CORBA portablility Summary: fix also reviewed by Alexander Fomin Reviewed-by: alanb, coffeys, skoivu ! src/share/classes/com/sun/corba/se/impl/transport/SelectorImpl.java ! src/share/classes/sun/rmi/rmic/iiop/StubGenerator.java Changeset: ab6eae733bce Author: chegar Date: 2013-07-15 11:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/ab6eae733bce Merge Changeset: e5ea72df9806 Author: chegar Date: 2013-07-22 13:59 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/e5ea72df9806 Merge Changeset: be4fdc568d73 Author: mchung Date: 2013-07-22 19:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/be4fdc568d73 8017196: Ensure Proxies are handled appropriately Reviewed-by: dfuchs, jrose, jdn, ahgross, chegar ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/InvocationHandlerFactoryImpl.java ! src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java Changeset: b0aeb77f0292 Author: chegar Date: 2013-07-25 17:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/b0aeb77f0292 Merge Changeset: a72f506e3058 Author: chegar Date: 2013-08-02 09:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/a72f506e3058 Merge Changeset: 0717fc6f2960 Author: chegar Date: 2013-08-09 14:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/0717fc6f2960 Merge Changeset: 6b5db99e194c Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/6b5db99e194c Merge - src/share/classes/com/sun/corba/se/impl/copyobject/JavaInputStream.sjava - src/share/classes/com/sun/corba/se/impl/copyobject/JavaOutputStream.sjava - src/share/classes/com/sun/corba/se/impl/interceptors/ThreadCurrentStack.sjava - src/share/classes/com/sun/corba/se/impl/orbutil/DefineWrapper.sjava - src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl_save.sjava - src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLTypesUtil_save.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalClientRequestImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalClientResponseImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalServerRequestImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalServerResponseImpl.sjava - src/share/classes/com/sun/corba/se/impl/transport/BufferConnectionImpl.sjava Changeset: 9c75c61d97f8 Author: msheppar Date: 2013-08-19 15:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/9c75c61d97f8 8022940: Enhance CORBA translations Reviewed-by: coffeys, alanb, skoivu ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl.java Changeset: 2caa37dfd7cd Author: chegar Date: 2013-08-23 22:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/2caa37dfd7cd Merge Changeset: a5788ab042dc Author: chegar Date: 2013-08-30 09:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/a5788ab042dc Merge Changeset: 118a211bb3ba Author: chegar Date: 2013-09-06 09:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/118a211bb3ba Merge Changeset: cc52d582df09 Author: chegar Date: 2013-09-14 19:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cc52d582df09 Merge Changeset: 396854c032bb Author: chegar Date: 2013-10-03 19:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/396854c032bb Merge Changeset: 47513cdce4ed Author: chegar Date: 2013-10-13 22:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/47513cdce4ed Merge From jan.lahoda at oracle.com Tue Oct 15 13:22:53 2013 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Tue, 15 Oct 2013 20:22:53 +0000 Subject: hg: jdk8/tl/langtools: 8026510: The name of com.sun.tools.javac.comp.Annotate.Annotator is confusing Message-ID: <20131015202256.D890D62412@hg.openjdk.java.net> Changeset: 19e8eebfbe52 Author: jlahoda Date: 2013-10-15 22:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/19e8eebfbe52 8026510: The name of com.sun.tools.javac.comp.Annotate.Annotator is confusing Summary: A mostly automated rename Annotate.Annotator->Annotate.Worker and enterAnnotation->run. Reviewed-by: emc, jjg ! src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java From chris.hegarty at oracle.com Tue Oct 15 13:23:36 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Oct 2013 20:23:36 +0000 Subject: hg: jdk8/tl/hotspot: 13 new changesets Message-ID: <20131015202413.3BED862413@hg.openjdk.java.net> Changeset: 5c599c419c1d Author: hseigel Date: 2013-07-11 12:59 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5c599c419c1d 8016256: Make finalization final Summary: Add private methods to final methods check Reviewed-by: coleenp, acorn, ahgross Contributed-by: harold.seigel at oracle.com ! src/share/vm/classfile/classFileParser.cpp Changeset: d840f02d03b4 Author: chegar Date: 2013-07-15 11:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d840f02d03b4 Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp Changeset: 7ec210434b3c Author: chegar Date: 2013-07-22 14:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ec210434b3c Merge - src/share/vm/memory/klassInfoClosure.hpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: ca9029490fce Author: chegar Date: 2013-07-25 17:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ca9029490fce Merge Changeset: 8f66130f7b5c Author: chegar Date: 2013-08-02 11:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8f66130f7b5c Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 38f9393d1847 Author: sgabdura Date: 2013-08-09 11:03 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/38f9393d1847 8020789: Disable exporting of gc.heap_dump diagnostic command Reviewed-by: fparain, ahgross ! src/share/vm/services/diagnosticCommand.cpp Changeset: ee7a7aa7c6bb Author: chegar Date: 2013-08-09 14:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ee7a7aa7c6bb Merge Changeset: 8f3c59225a5c Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8f3c59225a5c Merge - test/runtime/7196045/Test7196045.java - test/runtime/8000968/Test8000968.sh Changeset: 7638e35cabc6 Author: erikj Date: 2013-08-19 17:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7638e35cabc6 8015614: Update build settings Reviewed-by: tbell, dholmes, ahgross ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make Changeset: d4fa23d6c35b Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d4fa23d6c35b Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 07b5f47d7a18 Author: chegar Date: 2013-08-30 09:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/07b5f47d7a18 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 98a2169ed7ac Author: iklam Date: 2013-08-24 00:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/98a2169ed7ac 8023683: Enhance class file parsing Summary: Use the value returned by REALLOC_RESOURCE_ARRAY() Reviewed-by: coleenp, ahgross ! src/share/vm/classfile/classFileParser.cpp Changeset: 8321dcc18438 Author: chegar Date: 2013-10-13 21:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8321dcc18438 Merge ! src/share/vm/classfile/classFileParser.cpp From chris.hegarty at oracle.com Tue Oct 15 13:08:27 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Oct 2013 20:08:27 +0000 Subject: hg: jdk8/tl/jdk: 61 new changesets Message-ID: <20131015202435.B8C2D62414@hg.openjdk.java.net> Changeset: b3baca585b7f Author: jbachorik Date: 2013-04-23 09:37 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3baca585b7f 8011081: Improve jhat Summary: Properly escape HTML output Reviewed-by: alanb, mschoene, sundar ! src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/ClassQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/HttpReader.java ! src/share/classes/com/sun/tools/hat/internal/server/InstancesCountQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/OQLHelp.java ! src/share/classes/com/sun/tools/hat/internal/server/OQLQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/QueryHandler.java ! src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java Changeset: 37f6f4dbfc6d Author: ksrini Date: 2013-05-07 13:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/37f6f4dbfc6d 8013506: Better Pack200 data handling Reviewed-by: jrose, kizune, mschoene ! src/share/native/com/sun/java/util/jar/pack/zip.cpp Changeset: 139a01719eec Author: jchen Date: 2013-05-09 09:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/139a01719eec 8013510: Augment image writing code Reviewed-by: bae, prr ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c Changeset: f2068f4244a5 Author: bae Date: 2013-05-14 12:51 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f2068f4244a5 8014093: Improve parsing of images Reviewed-by: prr, jgodinez ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/image/awt_parseImage.h ! src/share/native/sun/awt/medialib/awt_ImagingLib.c Changeset: 65d5a6e53d12 Author: alexsch Date: 2013-05-20 14:39 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/65d5a6e53d12 8013744: Better tabling for AWT Reviewed-by: art, malenkov, skoivu ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/NumberFormatter.java ! src/share/classes/sun/swing/SwingLazyValue.java ! src/share/classes/sun/swing/SwingUtilities2.java Changeset: 52be85d5149b Author: bae Date: 2013-05-20 15:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/52be85d5149b 8014102: Improve image conversion Reviewed-by: mschoene, prr, jgodinez ! src/share/native/sun/awt/medialib/awt_ImagingLib.c Changeset: 08b88f831dd1 Author: malenkov Date: 2013-05-20 19:49 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/08b88f831dd1 8012071: Better Building of Beans Reviewed-by: art, skoivu ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/MetaData.java Changeset: 140c474ab8b9 Author: malenkov Date: 2013-05-31 21:25 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/140c474ab8b9 8012277: Improve AWT DataFlavor Reviewed-by: art, skoivu ! src/share/classes/java/awt/datatransfer/DataFlavor.java Changeset: 23fe888b698d Author: weijun Date: 2013-05-08 09:21 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23fe888b698d 8014341: Better service from Kerberos servers Summary: read incoming data safely and take care of null return value Reviewed-by: valeriep, ahgross ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/internal/NetClient.java Changeset: 532343ec60b7 Author: weijun Date: 2013-06-13 10:21 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/532343ec60b7 8013739: Better LDAP resource management Reviewed-by: ahgross, mchung, xuelei ! src/share/classes/com/sun/jndi/ldap/VersionHelper12.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/sun/misc/JavaLangAccess.java Changeset: 6d9ec6877a7f Author: weijun Date: 2013-06-13 10:31 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d9ec6877a7f 8015731: Subject java.security.auth.subject to improvements Reviewed-by: skoivu, mullan ! src/share/classes/javax/security/auth/Subject.java Changeset: ccca37ca416a Author: jchen Date: 2013-06-13 12:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ccca37ca416a 8014098: Better profile validation Reviewed-by: bae, mschoene, prr ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c Changeset: 5a14ecd30b4e Author: msheppar Date: 2013-06-14 15:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5a14ecd30b4e 8011157: Improve CORBA portablility Summary: fix also reviewed by Alexander Fomin Reviewed-by: alanb, coffeys, skoivu ! make/com/sun/jmx/Makefile ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java Changeset: 7addece3f21e Author: jbachorik Date: 2013-06-20 08:51 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7addece3f21e 8014085: Better serialization support in JMX classes Reviewed-by: alanb, dfuchs, skoivu ! src/share/classes/javax/management/MBeanNotificationInfo.java ! src/share/classes/javax/management/remote/JMXPrincipal.java ! src/share/classes/javax/management/remote/JMXServiceURL.java ! src/share/classes/javax/management/remote/NotificationResult.java ! src/share/classes/javax/management/remote/TargetedNotification.java Changeset: eb29deb3c1db Author: chegar Date: 2013-06-27 10:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eb29deb3c1db Merge Changeset: 0a06ec55aacd Author: bae Date: 2013-07-01 15:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a06ec55aacd 8017287: Better resource disposal Reviewed-by: prr, vadim, skoivu ! src/share/classes/sun/java2d/Disposer.java Changeset: 51204df822d3 Author: erikj Date: 2013-07-03 10:14 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51204df822d3 8012146: Improve tool support Reviewed-by: ksrini, dholmes, alanb, anthony ! makefiles/CompileLaunchers.gmk ! makefiles/Images.gmk ! test/Makefile Changeset: 888fd0ad7e1e Author: ascarpino Date: 2013-07-03 15:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/888fd0ad7e1e 8011071: Better crypto provider handling Reviewed-by: hawtin, valeriep ! src/share/classes/com/sun/crypto/provider/DHPrivateKey.java ! src/share/classes/sun/security/ec/ECPrivateKeyImpl.java ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/share/classes/sun/security/pkcs/PKCS8Key.java ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/provider/DSAPrivateKey.java ! src/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java ! src/share/classes/sun/security/rsa/RSAPrivateKeyImpl.java Changeset: a06b764cc2d0 Author: dsamersoff Date: 2013-07-08 16:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a06b764cc2d0 8008589: Better MBean permission validation Summary: Better MBean permission validation Reviewed-by: skoivu, dfuchs, mchung, sjiang ! src/share/classes/javax/management/MBeanTrustPermission.java Changeset: 9c6de162771c Author: smarks Date: 2013-07-11 13:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9c6de162771c 8014987: Augment serialization handling Reviewed-by: alanb, coffeys, skoivu ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/ObjectOutputStream.java Changeset: c40752886882 Author: jfranck Date: 2013-07-15 14:44 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c40752886882 8014349: (cl) Class.getDeclaredClass problematic in some class loader configurations Reviewed-by: mchung, ahgross, darcy ! src/share/classes/java/lang/Class.java ! src/share/native/java/lang/Class.c Changeset: 48548e40187a Author: mchung Date: 2013-07-15 20:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/48548e40187a 8017291: Cast Proxies Aside Reviewed-by: alanb, ahgross ! src/share/classes/java/lang/ClassLoader.java Changeset: 047c99b53994 Author: chegar Date: 2013-07-15 18:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/047c99b53994 Merge ! src/share/classes/java/lang/Thread.java - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/swing/SwingUtilities2.java - test/java/util/Comparators/BasicTest.java Changeset: 3062c96e79e0 Author: chegar Date: 2013-07-16 12:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3062c96e79e0 Merge Changeset: e1497f102a8a Author: malenkov Date: 2013-07-16 21:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e1497f102a8a 8019617: Better view of objects Reviewed-by: art, skoivu ! src/share/classes/javax/swing/text/html/ObjectView.java Changeset: 69a2dc92fefe Author: michaelm Date: 2013-07-18 18:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/69a2dc92fefe 8015743: Address internet addresses Reviewed-by: alanb, khazra, skoivu ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/InetAddress.java ! src/share/native/java/net/Inet6Address.c ! src/share/native/java/net/net_util.c ! src/share/native/java/net/net_util.h ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/net_util_md.c ! src/windows/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface_winXP.c ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c ! src/windows/native/java/net/net_util_md.c ! test/java/net/Inet6Address/serialize/Serialize.java Changeset: 5d8f1e697cd8 Author: okutsu Date: 2013-07-19 12:14 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d8f1e697cd8 8001029: Add new date/time capability Reviewed-by: mchung, hawtin ! src/share/classes/java/util/TimeZone.java + test/java/util/TimeZone/SetDefaultSecurityTest.java Changeset: fe90bd20865b Author: sjiang Date: 2013-07-19 13:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe90bd20865b 8014534: Better profiling support Summary: Validation of parameters Reviewed-by: sspitsyn, skoivu, mchung ! src/share/classes/com/sun/demo/jvmti/hprof/Tracker.java ! src/share/demo/jvmti/hprof/hprof_class.c ! src/share/demo/jvmti/hprof/hprof_event.c Changeset: 0a51ccf778b3 Author: chegar Date: 2013-07-22 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a51ccf778b3 Merge Changeset: 3725e8a70ae9 Author: mchung Date: 2013-07-22 19:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3725e8a70ae9 8017196: Ensure Proxies are handled appropriately Reviewed-by: dfuchs, jrose, jdn, ahgross, chegar ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java Changeset: 5bde952bf23c Author: sgabdura Date: 2013-07-23 09:30 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bde952bf23c 8016357: Update hotspot diagnostic class Summary: Add security check to HotSpotDiagnostic.dumpHeap Reviewed-by: fparain, sla, ahgross ! make/java/management/mapfile-vers ! makefiles/mapfiles/libmanagement/mapfile-vers ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/native/sun/management/HotSpotDiagnostic.c Changeset: 5bdc55e87cae Author: weijun Date: 2013-07-17 18:46 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bdc55e87cae 8020696: Merge problem for KdcComm.java Reviewed-by: chegar ! src/share/classes/sun/security/krb5/KdcComm.java Changeset: 490c67c5d9a2 Author: jchen Date: 2013-07-24 12:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/490c67c5d9a2 8020293: JVM crash Reviewed-by: prr, jgodinez ! src/share/classes/sun/font/GlyphLayout.java ! src/share/native/sun/font/layout/SunLayoutEngine.cpp Changeset: bcce47d9d8da Author: jbachorik Date: 2013-07-19 16:29 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bcce47d9d8da 8019584: javax/management/remote/mandatory/loading/MissingClassTest.java failed in nightly against jdk7u45: java.io.InvalidObjectException: Invalid notification: null Reviewed-by: mchung, sjiang, dfuchs, ahgross ! src/share/classes/javax/management/remote/NotificationResult.java ! src/share/classes/javax/management/remote/TargetedNotification.java ! test/javax/management/remote/mandatory/loading/MissingClassTest.java Changeset: d7a0bbf526f8 Author: jbachorik Date: 2013-07-29 04:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d7a0bbf526f8 8021577: JCK test api/javax_management/jmx_serial/modelmbean/ModelMBeanNotificationInfo/serial/index.html#Input has failed since jdk 7u45 b01 Reviewed-by: alanb, dfuchs, ahgross ! src/share/classes/javax/management/MBeanNotificationInfo.java Changeset: 1a1e42c8e988 Author: chegar Date: 2013-07-25 19:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1a1e42c8e988 Merge ! src/share/classes/com/sun/crypto/provider/DHPrivateKey.java - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/InetAddress.java - src/share/classes/java/util/stream/StreamBuilder.java ! src/share/classes/javax/security/auth/Subject.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/security/pkcs11/P11Key.java - test/java/util/Collections/EmptySortedSet.java Changeset: 446bc20447a1 Author: chegar Date: 2013-07-29 14:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/446bc20447a1 Merge Changeset: e537b7f5f39b Author: naoto Date: 2013-08-01 14:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e537b7f5f39b 8021286: Improve MacOS resourcing Reviewed-by: okutsu - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk ! make/sun/awt/Makefile ! makefiles/CompileNativeLibraries.gmk ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m Changeset: 44a063555ccd Author: chegar Date: 2013-08-02 11:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44a063555ccd Merge Changeset: 17e1675e3d1e Author: serb Date: 2013-08-04 02:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/17e1675e3d1e 8021282: Better recycling of object instances Reviewed-by: art ! src/macosx/classes/com/apple/laf/AquaUtils.java Changeset: ba7566de89c6 Author: sjiang Date: 2013-08-06 10:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ba7566de89c6 8019292: Better Attribute Value Exceptions Reviewed-by: dfuchs, dholmes, ahgross ! src/share/classes/javax/management/BadAttributeValueExpException.java Changeset: 23476862c55b Author: malenkov Date: 2013-08-07 14:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23476862c55b 8021969: The index_AccessAllowed jnlp can not load successfully with exception thrown in the log. Reviewed-by: art, skoivu ! src/share/classes/java/awt/datatransfer/DataFlavor.java Changeset: db9539b0061d Author: jbachorik Date: 2013-08-08 19:16 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db9539b0061d 8021360: object not exported" on start of JMXConnectorServer for RMI-IIOP protocol with security manager Reviewed-by: alanb, ahgross, smarks, coffeys ! src/share/classes/com/sun/jmx/remote/protocol/iiop/IIOPProxyImpl.java Changeset: 077d8c2cc5f6 Author: chegar Date: 2013-08-09 14:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/077d8c2cc5f6 Merge ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/InetAddress.java - src/share/classes/java/net/package.html ! src/share/classes/java/util/TimeZone.java ! src/share/native/java/net/net_util.c ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/awt/medialib/awt_ImagingLib.c ! test/Makefile Changeset: e82ddcc1b2fb Author: serb Date: 2013-08-12 19:57 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e82ddcc1b2fb 8021275: Better screening for ScreenMenu Reviewed-by: art ! src/macosx/classes/com/apple/laf/ScreenMenu.java Changeset: 3e3cbd93f4f1 Author: twisti Date: 2013-08-12 13:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e3cbd93f4f1 8022066: Evaluation of method reference to signature polymorphic method crashes VM Reviewed-by: jrose ! src/share/classes/java/lang/invoke/MethodHandles.java + test/java/lang/invoke/MethodHandleConstants.java Changeset: e173b8786362 Author: ksrini Date: 2013-08-14 10:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e173b8786362 8021355: REGRESSION: Five closed/java/awt/SplashScreen tests fail since 7u45 b01 on Linux, Solaris Reviewed-by: dholmes, anthony, ahgross, erikj ! src/solaris/bin/java_md_solinux.c Changeset: 31010ca3da3e Author: chegar Date: 2013-08-15 21:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31010ca3da3e Merge ! makefiles/CompileNativeLibraries.gmk ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java - test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java - test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh Changeset: 3f85c96eafcc Author: weijun Date: 2013-08-14 15:25 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f85c96eafcc 8022931: Enhance Kerberos exceptions Reviewed-by: xuelei, ahgross ! src/share/classes/javax/security/auth/kerberos/KeyTab.java Changeset: 50bdb9577b27 Author: erikj Date: 2013-08-19 12:30 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/50bdb9577b27 8022719: tools/launcher/RunpathTest.java fails after 8012146 Reviewed-by: chegar ! test/tools/launcher/RunpathTest.java Changeset: 0f279113c95a Author: erikj Date: 2013-08-19 14:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0f279113c95a 8023231: Remove comma from jtreg bug line Reviewed-by: alanb, chegar ! test/tools/launcher/RunpathTest.java Changeset: ad35b4b6ce8e Author: chegar Date: 2013-08-23 12:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad35b4b6ce8e Merge Changeset: 29f73bc50bd4 Author: chegar Date: 2013-08-30 09:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/29f73bc50bd4 Merge ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk - src/share/classes/com/sun/security/auth/PolicyParser.java - src/share/classes/com/sun/security/auth/SubjectCodeSource.java ! src/share/classes/java/net/InetAddress.java - src/share/classes/java/util/jar/UnsupportedProfileException.java - src/share/classes/sun/security/provider/ConfigSpiFile.java ! src/solaris/native/java/net/NetworkInterface.c - test/java/net/URLClassLoader/profiles/Basic.java - test/java/net/URLClassLoader/profiles/Lib.java - test/java/net/URLClassLoader/profiles/basic.sh - test/tools/jar/AddAndUpdateProfile.java - test/tools/launcher/profiles/Basic.java - test/tools/launcher/profiles/Logging.java - test/tools/launcher/profiles/Main.java - test/tools/launcher/profiles/VersionCheck.java Changeset: a8593bc7c29d Author: chegar Date: 2013-09-06 09:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8593bc7c29d Merge ! src/share/classes/java/lang/Class.java - src/share/classes/sun/misc/Compare.java - src/share/classes/sun/misc/Sort.java Changeset: 22ea25e71b4c Author: chegar Date: 2013-09-14 19:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/22ea25e71b4c Merge Changeset: 240072825ada Author: chegar Date: 2013-10-03 19:06 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/240072825ada Merge ! make/sun/awt/Makefile ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/Images.gmk - src/macosx/classes/sun/lwawt/SelectionClearListener.java - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/invoke/MethodHandles.java - src/share/classes/java/util/stream/CloseableStream.java - src/share/classes/java/util/stream/DelegatingStream.java ! src/share/classes/javax/management/MBeanNotificationInfo.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/font/layout/SunLayoutEngine.cpp ! src/solaris/bin/java_md_solinux.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface_winXP.c - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so - test/java/util/Collection/ListDefaults.java - test/java/util/Map/CheckRandomHashSeed.java - test/java/util/Map/TreeBinSplitBackToEntries.java - test/java/util/concurrent/ConcurrentHashMap/toArray.java - test/java/util/regex/PatternTest.java - test/sun/tools/jconsole/ImmutableResourceTest.java - test/sun/tools/jconsole/ImmutableResourceTest.sh ! test/tools/launcher/RunpathTest.java Changeset: adbf6d61c820 Author: chegar Date: 2013-10-07 11:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/adbf6d61c820 8025991: tools/launcher/RunpathTest.java fails Reviewed-by: erikj ! test/tools/launcher/RunpathTest.java Changeset: 99832c718cb8 Author: chegar Date: 2013-10-15 09:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/99832c718cb8 Merge - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/solaris/native/java/net/Inet6AddressImpl.c Changeset: 3dbfab65c17e Author: chegar Date: 2013-10-15 13:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3dbfab65c17e Merge ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/lang/ClassLoader.java - src/share/classes/java/net/HttpURLPermission.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/NumberFormatter.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 Changeset: 27ac58b9a62a Author: chegar Date: 2013-10-15 20:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27ac58b9a62a 8026513: ProblemList.txt Updates (10/2013) Reviewed-by: alanb ! test/ProblemList.txt Changeset: 78ffa90c77b2 Author: chegar Date: 2013-10-15 20:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78ffa90c77b2 Merge From chris.hegarty at oracle.com Tue Oct 15 13:15:40 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Oct 2013 20:15:40 +0000 Subject: hg: jdk8/tl/langtools: 14 new changesets Message-ID: <20131015201701.A023D6240F@hg.openjdk.java.net> Changeset: 84df20dc604a Author: bpatel Date: 2013-07-24 15:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/84df20dc604a 8016675: Make Javadoc pages more robust Reviewed-by: jlaskey, ksrini ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java + test/com/sun/javadoc/testWindowTitle/TestWindowTitle.java + test/com/sun/javadoc/testWindowTitle/p1/C1.java + test/com/sun/javadoc/testWindowTitle/p2/C2.java Changeset: 8b3e2cc5f1de Author: chegar Date: 2013-07-25 19:06 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8b3e2cc5f1de Merge - test/tools/javac/generics/6723444/T6723444.out - test/tools/javac/generics/7015430/T7015430.out Changeset: 0d75d3b96477 Author: chegar Date: 2013-08-02 11:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0d75d3b96477 Merge Changeset: 2d1a54d213c2 Author: chegar Date: 2013-08-09 14:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2d1a54d213c2 Merge Changeset: 84b6d75ff2c9 Author: chegar Date: 2013-08-15 21:34 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/84b6d75ff2c9 Merge Changeset: a540e2a926cf Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a540e2a926cf Merge Changeset: a8f0c3583a86 Author: chegar Date: 2013-08-30 10:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a8f0c3583a86 Merge - test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java - test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java Changeset: 6250a7f0aba6 Author: chegar Date: 2013-09-06 10:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6250a7f0aba6 Merge - test/com/sun/javadoc/testNavagation/TestNavagation.java - test/com/sun/javadoc/testNavagation/pkg/A.java - test/com/sun/javadoc/testNavagation/pkg/C.java - test/com/sun/javadoc/testNavagation/pkg/E.java - test/com/sun/javadoc/testNavagation/pkg/I.java - test/tools/javac/8015701/AnonymousParameters.java Changeset: a6901af8a2e4 Author: chegar Date: 2013-09-14 20:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a6901af8a2e4 Merge Changeset: 2c13a5da6854 Author: chegar Date: 2013-10-03 19:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2c13a5da6854 Merge ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java - src/share/classes/com/sun/tools/javac/code/Annotations.java - test/tools/javac/diags/examples/CyclicInference.java - test/tools/javac/diags/examples/MrefStat.java.rej - test/tools/javac/diags/examples/MrefStat1.java.rej - test/tools/javac/lambda/TargetType10.out - test/tools/javac/lambda/typeInference/InferenceTest5.java - test/tools/javac/lambda/typeInference/InferenceTest_neg5.java - test/tools/javac/lambda/typeInference/InferenceTest_neg5.out Changeset: 86e57f576e65 Author: chegar Date: 2013-10-11 19:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/86e57f576e65 Merge ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java Changeset: 46feacb99698 Author: chegar Date: 2013-10-15 14:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/46feacb99698 Merge - src/share/classes/com/sun/javadoc/package.html - src/share/classes/com/sun/tools/classfile/package.html - src/share/classes/com/sun/tools/doclets/formats/html/markup/package.html - src/share/classes/com/sun/tools/doclets/formats/html/package.html - src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/package.html - src/share/classes/com/sun/tools/doclets/internal/toolkit/package.html - src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/package.html - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/package.html - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/package.html - src/share/classes/com/sun/tools/doclets/package.html - src/share/classes/com/sun/tools/javap/package.html Changeset: 90c9ae4bc756 Author: chegar Date: 2013-10-15 20:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/90c9ae4bc756 Merge Changeset: dd073728085d Author: chegar Date: 2013-10-15 21:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dd073728085d Merge From daniel.daugherty at oracle.com Tue Oct 15 15:09:11 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Tue, 15 Oct 2013 22:09:11 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7165611: implement Full Debug Symbols on MacOS X hotspot Message-ID: <20131015220925.9724A62425@hg.openjdk.java.net> Changeset: f509b8f4699b Author: dcubed Date: 2013-10-15 08:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f509b8f4699b 7165611: implement Full Debug Symbols on MacOS X hotspot Summary: Add MacOS X FDS support to hotspot; add minimal MacOS X FDS import support to jdk; add MacOS X FDS support to install; add MacOS X FDS support to root. Reviewed-by: erikj, sla, dholmes, rdurbin, tbell, ihse ! make/Makefile ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/jsig.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/universal.gmk ! make/bsd/makefiles/vm.make ! make/defs.make From daniel.daugherty at oracle.com Tue Oct 15 15:12:33 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Tue, 15 Oct 2013 22:12:33 +0000 Subject: hg: hsx/hotspot-rt: 7165611: implement Full Debug Symbols on MacOS X hotspot Message-ID: <20131015221234.AAA9962426@hg.openjdk.java.net> Changeset: 22c6f0b7e2b5 Author: dcubed Date: 2013-10-15 08:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/rev/22c6f0b7e2b5 7165611: implement Full Debug Symbols on MacOS X hotspot Summary: Add MacOS X FDS support to hotspot; add minimal MacOS X FDS import support to jdk; add MacOS X FDS support to install; add MacOS X FDS support to root. Reviewed-by: erikj, sla, dholmes, rdurbin, tbell, ihse ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/makefiles/NativeCompilation.gmk From daniel.daugherty at oracle.com Tue Oct 15 15:15:27 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Tue, 15 Oct 2013 22:15:27 +0000 Subject: hg: hsx/hotspot-rt/jdk: 7165611: implement Full Debug Symbols on MacOS X hotspot Message-ID: <20131015221711.07CAC62427@hg.openjdk.java.net> Changeset: 01b81253f2d5 Author: dcubed Date: 2013-10-15 08:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/jdk/rev/01b81253f2d5 7165611: implement Full Debug Symbols on MacOS X hotspot Summary: Add MacOS X FDS support to hotspot; add minimal MacOS X FDS import support to jdk; add MacOS X FDS support to install; add MacOS X FDS support to root. Reviewed-by: erikj, sla, dholmes, rdurbin, tbell, ihse ! make/common/Defs-macosx.gmk ! make/common/Defs.gmk ! make/java/redist/Makefile ! makefiles/Import.gmk ! makefiles/Tools.gmk From philip.race at oracle.com Tue Oct 15 15:48:46 2013 From: philip.race at oracle.com (Phil Race) Date: Tue, 15 Oct 2013 15:48:46 -0700 Subject: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to build the class library on AIX In-Reply-To: References: <523A27A8.404@oracle.com> <523B01DF.1030902@oracle.com> Message-ID: <525DC64E.3060404@oracle.com> Hello Volker, I just remembered & got back to these changes - my email inbox isn't a very good reminder system. I am OK with everything I see in the client areas except as below :- /* Very basic start for AIX - feel free to complete .. 169 */ We should remove this comment. If that means first getting any necessary completion from IBM folks, please ask them. Given the lack of fontconfig on AIX as standard its probably more important for AIX than any other OS so I suggest the latter. > * insted it has to be installed from the "AIX Toolbox for Linux Applications" insted -> instead X11SurfaceData.c: #ifndef MAX and #ifndef MIN I found that re-definition warnings are seen at least on 64 bit linux. Maybe you should rename these too generically named macros to XSD_MAX and XSD_MIN. > extern int dladdr(void *addr, Dl_info *info); // use the HotSpot implementation from libjvm.so Did you ever get an opinion on this from the libraries or hotspot teams ? -phil. On 9/19/2013 7:28 AM, Volker Simonis wrote: > Hi Phil, > > I'm open to any good ideas. > > The current solution is pragmatic, simple and it has no impact on > existing platforms. > > The other possibility I see is to put the 'dladdr' implantation into > its own library (something equivalent to "libjli") and link that > library to "libawt". But I currently don't see any existing library I > could put the implementation into. > > Notice that the change I propose already contains an extra > implementation of 'dladdr' for AIX in > "src/solaris/demo/jvmti/hprof/hprof_md.c" because "libhprof" is not > linked against libjvm and we therefore can not use the 'extern'-trick > there. > > Of course it would be nice if there would be a small library which > contains 'dladdr' and which could be linked against both, "libawt" and > "libhprof". But I think that would require bigger shared changes (with > possible empty implementations on the current platforms). > > What do other think? > > Regards, > Volker > > > On Thu, Sep 19, 2013 at 3:53 PM, Phil Race wrote: >> Hi, >> >> w.r.t the one issue below : is the awt load library code the only place you >> need/are doing this ? If someone else (hotspot, core-libs) already assented >> to this >> then I guess I could too but I'd like to hear for sure that hotspot and >> core-libs >> teams both agree to this approach and whether there is an alternative. >> >> -phil. >> >> >> On 9/19/13 4:29 AM, Volker Simonis wrote: >> >> Hi Phil, >> >> thank you for looking at the changes. Please find my answers inline: >> >> >>> /* AIX does not provide the 'dladdr' function. But fortunately, we've >>> >>> 42 * already implemented it in the HotSpot, because we need it there as >>> 43 * well (see hotspot/src/os/aix/vm/porting_aix.{hpp,cpp}). >>> >>> Whilst this is in "ifdef AIX" this reliance on an exported hotspot >>> function sounds hacky. What actual requirement is there that the >>> AIX class libraries be so tightly-coupled with that VM? >>> There is no contract there. >>> >> You're right, there is no contract. It's just pragmatic solution and I think >> it should always work because the libjvm will always be loaded at the point >> in AWT where it is used. Another solution would be to re-implement the >> functionality in the class library and I don't like code duplication either. >> >>> -phil. >>> >>> From jonathan.gibbons at oracle.com Tue Oct 15 15:58:43 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 15 Oct 2013 22:58:43 +0000 Subject: hg: jdk8/tl/langtools: 8026564: import changes from type-annotations forest Message-ID: <20131015225846.A7F786242A@hg.openjdk.java.net> Changeset: b0c086cd4520 Author: jjg Date: 2013-10-15 15:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b0c086cd4520 8026564: import changes from type-annotations forest Reviewed-by: jjg Contributed-by: wdietl at gmail.com, steve.sides at oracle.com ! make/build.properties ! make/build.xml ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/javax/lang/model/AnnotatedConstruct.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java ! test/tools/javac/T7042623.java ! test/tools/javac/annotations/typeAnnotations/classfile/ClassfileTestHelper.java + test/tools/javac/annotations/typeAnnotations/classfile/Scopes.java ! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedImport.java ! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage1.java ! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage1.out ! test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage2.java ! test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion.java ! test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion.out ! test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion7.out ! test/tools/javac/annotations/typeAnnotations/failures/BadCast.java ! test/tools/javac/annotations/typeAnnotations/failures/BadCast.out + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.java + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.out + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.out ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.java - test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.out + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.java + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.out + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass3.java + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass3.out ! test/tools/javac/annotations/typeAnnotations/failures/IncompleteArray.java ! test/tools/javac/annotations/typeAnnotations/failures/IncompleteArray.out - test/tools/javac/annotations/typeAnnotations/failures/IncompleteVararg.java - test/tools/javac/annotations/typeAnnotations/failures/IncompleteVararg.out ! test/tools/javac/annotations/typeAnnotations/failures/IndexArray.java ! test/tools/javac/annotations/typeAnnotations/failures/IndexArray.out ! test/tools/javac/annotations/typeAnnotations/failures/LintCast.out ! test/tools/javac/annotations/typeAnnotations/failures/OldArray.java + test/tools/javac/annotations/typeAnnotations/failures/OldArray.out ! test/tools/javac/annotations/typeAnnotations/failures/Scopes.java ! test/tools/javac/annotations/typeAnnotations/failures/Scopes.out ! test/tools/javac/annotations/typeAnnotations/failures/StaticFields.java ! test/tools/javac/annotations/typeAnnotations/failures/StaticFields.out - test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.java - test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.out ! test/tools/javac/annotations/typeAnnotations/failures/TypeVariableCycleTest.java + test/tools/javac/annotations/typeAnnotations/failures/TypeVariableMissingTA.java + test/tools/javac/annotations/typeAnnotations/failures/TypeVariableMissingTA.out - test/tools/javac/diags/examples/CantAnnotateNestedType.java + test/tools/javac/diags/examples/CantAnnotateScoping.java + test/tools/javac/diags/examples/CantAnnotateScoping1.java - test/tools/javac/diags/examples/CantAnnotateStaticClass.java ! test/tools/javac/lib/DPrinter.java ! test/tools/javac/processing/model/type/BasicAnnoTests.java From brian.burkhalter at oracle.com Tue Oct 15 16:47:39 2013 From: brian.burkhalter at oracle.com (brian.burkhalter at oracle.com) Date: Tue, 15 Oct 2013 23:47:39 +0000 Subject: hg: jdk8/tl/jdk: 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown Message-ID: <20131015234802.A3DAB6242E@hg.openjdk.java.net> Changeset: 3676f04e6553 Author: bpb Date: 2013-10-15 16:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3676f04e6553 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown Summary: Modify UHE exception message for EAI_AGAIN failures. Reviewed-by: alanb, chegar, michaelm, dsamersoff Contributed-by: Brian Burkhalter ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c From david.holmes at oracle.com Tue Oct 15 17:54:53 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Wed, 16 Oct 2013 00:54:53 +0000 Subject: hg: jdk8/tl/jdk: 8026378: TEST_BUG: Clean up TEST.groups Message-ID: <20131016005509.13F4162431@hg.openjdk.java.net> Changeset: e33aea66caa3 Author: dholmes Date: 2013-10-15 20:54 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e33aea66caa3 8026378: TEST_BUG: Clean up TEST.groups Reviewed-by: mduigou, mchung, alanb ! test/TEST.groups From david.holmes at oracle.com Tue Oct 15 21:06:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Oct 2013 14:06:42 +1000 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <525D4490.3070506@oracle.com> References: <525D4490.3070506@oracle.com> Message-ID: <525E10D2.2060604@oracle.com> Hi Katja, Not a review just a couple of meta comments. First I've added hotspto-dev as all these changes to the test library need a wider review audience. I'm a little concerned about its current rate of expansion. Second all the new files have the wrong copyright notice - they should have the OpenJDK copyright. Thanks, David On 15/10/2013 11:35 PM, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > The purpose of this fix is to get rid of intermittent failures in > sun/tools/jstatd tests and make the tests more stable, legible and > maintainable. > > Thanks, > Katja > > Webrev: > http://cr.openjdk.java.net/~ykantser/8022229/webrev.00/ > > Primal bug: > https://bugs.openjdk.java.net/browse/JDK-8022229 > > Similar bugs: > https://bugs.openjdk.java.net/browse/JDK-8019630 > https://bugs.openjdk.java.net/browse/JDK-6636094 > https://bugs.openjdk.java.net/browse/JDK-6543979 From weijun.wang at oracle.com Tue Oct 15 23:40:36 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 16 Oct 2013 06:40:36 +0000 Subject: hg: jdk8/tl/jdk: 8025124: InitialToken.useNullKey incorrectly applies NULL_KEY in some cases Message-ID: <20131016064144.9D15162446@hg.openjdk.java.net> Changeset: a70aab9b373e Author: weijun Date: 2013-10-16 14:39 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a70aab9b373e 8025124: InitialToken.useNullKey incorrectly applies NULL_KEY in some cases Reviewed-by: xuelei ! src/share/classes/sun/security/jgss/krb5/InitialToken.java ! src/share/classes/sun/security/krb5/KrbCred.java From sundararajan.athijegannathan at oracle.com Tue Oct 15 23:54:54 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 16 Oct 2013 06:54:54 +0000 Subject: hg: jdk8/tl/nashorn: 7 new changesets Message-ID: <20131016065502.808F862447@hg.openjdk.java.net> Changeset: 6cb4f20d971f Author: jlaskey Date: 2013-10-11 14:54 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/6cb4f20d971f 8026309: latest runsunspider.js tests contains several bugs Reviewed-by: sundar, lagergren Contributed-by: james.laskey at oracle.com ! test/script/basic/runsunspider.js Changeset: 8c617a092d68 Author: hannesw Date: 2013-10-14 11:45 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8c617a092d68 8026016: too many relinks dominate avatar.js http benchmark Reviewed-by: sundar, jlaskey, attila ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8026016.js + test/script/basic/JDK-8026016.js.EXPECTED Changeset: d155c4a7703c Author: attila Date: 2013-10-14 12:41 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d155c4a7703c 8026113: Nashorn arrays should automatically convert to Java arrays Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java + test/src/jdk/nashorn/api/javaaccess/ArrayConversionTest.java Changeset: 64e841576c68 Author: attila Date: 2013-10-15 15:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/64e841576c68 8026397: Fix ambiguity with array conversion, including passing JS NativeArrays in Java variable arity methods' vararg array position Reviewed-by: jlaskey, sundar ! src/jdk/internal/dynalink/beans/SingleDynamicMethod.java ! src/jdk/internal/dynalink/support/Guards.java ! src/jdk/internal/dynalink/support/messages.properties ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! test/src/jdk/nashorn/api/javaaccess/ArrayConversionTest.java Changeset: aa452eb4a5d0 Author: hannesw Date: 2013-10-15 17:37 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/aa452eb4a5d0 8026367: Add a sync keyword to mozilla_compat Reviewed-by: sundar, attila, lagergren ! src/jdk/nashorn/api/scripting/ScriptUtils.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + test/script/basic/JDK-8026367.js ! test/script/sandbox/loadcompat.js Changeset: b3ee112a328e Author: jlaskey Date: 2013-10-15 13:14 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b3ee112a328e 8026498: Revert: latest runsunspider.js tests contains several bugs Reviewed-by: sundar, hannesw Contributed-by: james.laskey at oracle.com ! test/script/basic/runsunspider.js Changeset: 9a13e95cc40f Author: sundar Date: 2013-10-15 22:13 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/9a13e95cc40f Merge From yekaterina.kantserova at oracle.com Wed Oct 16 01:06:12 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 16 Oct 2013 10:06:12 +0200 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <525E10D2.2060604@oracle.com> References: <525D4490.3070506@oracle.com> <525E10D2.2060604@oracle.com> Message-ID: <525E48F4.9000001@oracle.com> Hi David, Thank you for your comments! You have right, it's worth to check testlibrary changes twice. For example Erik Helin has pointed out to me there already is Asserts.java in hotspot/testlibrary. I don't mind to merge hotspot testlibrary into jdk. Thanks, Katja On 10/16/2013 06:06 AM, David Holmes wrote: > Hi Katja, > > Not a review just a couple of meta comments. > > First I've added hotspto-dev as all these changes to the test library > need a wider review audience. I'm a little concerned about its current > rate of expansion. > > Second all the new files have the wrong copyright notice - they should > have the OpenJDK copyright. > > Thanks, > David > > On 15/10/2013 11:35 PM, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> The purpose of this fix is to get rid of intermittent failures in >> sun/tools/jstatd tests and make the tests more stable, legible and >> maintainable. >> >> Thanks, >> Katja >> >> Webrev: >> http://cr.openjdk.java.net/~ykantser/8022229/webrev.00/ >> >> Primal bug: >> https://bugs.openjdk.java.net/browse/JDK-8022229 >> >> Similar bugs: >> https://bugs.openjdk.java.net/browse/JDK-8019630 >> https://bugs.openjdk.java.net/browse/JDK-6636094 >> https://bugs.openjdk.java.net/browse/JDK-6543979 From jaroslav.bachorik at oracle.com Wed Oct 16 01:19:48 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 16 Oct 2013 10:19:48 +0200 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <525E48F4.9000001@oracle.com> References: <525D4490.3070506@oracle.com> <525E10D2.2060604@oracle.com> <525E48F4.9000001@oracle.com> Message-ID: <525E4C24.7020602@oracle.com> On 16.10.2013 10:06, Yekaterina Kantserova wrote: > Hi David, > > Thank you for your comments! > > You have right, it's worth to check testlibrary changes twice. For > example Erik Helin has pointed out to me there already is Asserts.java > in hotspot/testlibrary. I don't mind to merge hotspot testlibrary into jdk. This is already tracked by JDK-8015497. It would be nice to have one shared testlibrary, though. -JB- > > Thanks, > Katja > > > > On 10/16/2013 06:06 AM, David Holmes wrote: >> Hi Katja, >> >> Not a review just a couple of meta comments. >> >> First I've added hotspto-dev as all these changes to the test library >> need a wider review audience. I'm a little concerned about its current >> rate of expansion. >> >> Second all the new files have the wrong copyright notice - they should >> have the OpenJDK copyright. >> >> Thanks, >> David >> >> On 15/10/2013 11:35 PM, Yekaterina Kantserova wrote: >>> Hi, >>> >>> Could I please have a review of this fix. >>> >>> The purpose of this fix is to get rid of intermittent failures in >>> sun/tools/jstatd tests and make the tests more stable, legible and >>> maintainable. >>> >>> Thanks, >>> Katja >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ykantser/8022229/webrev.00/ >>> >>> Primal bug: >>> https://bugs.openjdk.java.net/browse/JDK-8022229 >>> >>> Similar bugs: >>> https://bugs.openjdk.java.net/browse/JDK-8019630 >>> https://bugs.openjdk.java.net/browse/JDK-6636094 >>> https://bugs.openjdk.java.net/browse/JDK-6543979 > From staffan.larsen at oracle.com Wed Oct 16 01:48:45 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 16 Oct 2013 10:48:45 +0200 Subject: RFR (S): 8025925: jmap fails with "field _length not found in type HeapRegionSeq" In-Reply-To: <1381834405.2686.75.camel@cirrus> References: <1381834405.2686.75.camel@cirrus> Message-ID: <789CB0EE-019F-4FFA-BFE1-2F6C31D2721B@oracle.com> Looks good! Thanks, /Staffan On 15 okt 2013, at 12:53, Thomas Schatzl wrote: > Hi all, > > can I have reviews for the following change? It updates the SA agent > that got out of date after the changes for JDK-7163191 where the > HeapRegionSeq class has been refactored. > > The changes mirror the changes in the C++ code of that revision, adding > a G1HeapRegionTable java class, and the associated modifications in the > HeapRegionSeq class. > > There have been no interface changes to the HeapRegionSeq class to avoid > breakage of any tools depending on it. > > Webrev: > http://cr.openjdk.java.net/~tschatzl/8025925/webrev/ > > Testing: > Connecting an SA-agent with the change on a running java program; test > case in bug report > > (I added the serviceability-dev mailing list as additional recipients as > the change also concerns this part of the VM) > > Thanks, > Thomas > > From jaroslav.bachorik at oracle.com Wed Oct 16 01:50:51 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 16 Oct 2013 10:50:51 +0200 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <525D4490.3070506@oracle.com> References: <525D4490.3070506@oracle.com> Message-ID: <525E536B.40800@oracle.com> On 15.10.2013 15:35, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > The purpose of this fix is to get rid of intermittent failures in > sun/tools/jstatd tests and make the tests more stable, legible and > maintainable. > > Thanks, > Katja > > Webrev: > http://cr.openjdk.java.net/~ykantser/8022229/webrev.00/ > > Primal bug: > https://bugs.openjdk.java.net/browse/JDK-8022229 > > Similar bugs: > https://bugs.openjdk.java.net/browse/JDK-8019630 > https://bugs.openjdk.java.net/browse/JDK-6636094 > https://bugs.openjdk.java.net/browse/JDK-6543979 > Hi Katja, these are my comments: test/sun/tools/jstatd/JstatdHelper.java ======================================= * 82-84 Should be moved to 91 since the check is only valid for Tool.RMIREGISTRY * Started processes are not cleaned up in case they get stuck for some reason. The original test tried to explicitely kill the target processes. test/lib/testlibrary/jdk/testlibrary/Asserts.java ================================================= * Missing javadoc for the public library methods test/lib/testlibrary/jdk/testlibrary/ProcessThread.java ======================================================= * Missing javadoc for the public library methods test/lib/testlibrary/jdk/testlibrary/TestThread.java ==================================================== * Missing javadoc for the public library methods test/lib/testlibrary/jdk/testlibrary/Utils.java =============================================== * Missing javadoc for the public library methods * 57 serverSocket.close() should be called in "finally" block to make sure the resources are released even in case of an exception being thrown test/sun/tools/jstatd/JstatGcutilParser.java ============================================ * The comments from the original test explaining the tested format are missing Cheers, -JB- From yekaterina.kantserova at oracle.com Wed Oct 16 02:02:40 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 16 Oct 2013 11:02:40 +0200 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <525E536B.40800@oracle.com> References: <525D4490.3070506@oracle.com> <525E536B.40800@oracle.com> Message-ID: <525E5630.2050105@oracle.com> Thanks a lot for comments! Will check and change. // Katja On 10/16/2013 10:50 AM, Jaroslav Bachorik wrote: > On 15.10.2013 15:35, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> The purpose of this fix is to get rid of intermittent failures in >> sun/tools/jstatd tests and make the tests more stable, legible and >> maintainable. >> >> Thanks, >> Katja >> >> Webrev: >> http://cr.openjdk.java.net/~ykantser/8022229/webrev.00/ >> >> Primal bug: >> https://bugs.openjdk.java.net/browse/JDK-8022229 >> >> Similar bugs: >> https://bugs.openjdk.java.net/browse/JDK-8019630 >> https://bugs.openjdk.java.net/browse/JDK-6636094 >> https://bugs.openjdk.java.net/browse/JDK-6543979 >> > > Hi Katja, > > these are my comments: > > test/sun/tools/jstatd/JstatdHelper.java > ======================================= > * 82-84 Should be moved to 91 since the check is only valid for > Tool.RMIREGISTRY > * Started processes are not cleaned up in case they get stuck for some > reason. The original test tried to explicitely kill the target processes. > > > test/lib/testlibrary/jdk/testlibrary/Asserts.java > ================================================= > * Missing javadoc for the public library methods > > > test/lib/testlibrary/jdk/testlibrary/ProcessThread.java > ======================================================= > * Missing javadoc for the public library methods > > > test/lib/testlibrary/jdk/testlibrary/TestThread.java > ==================================================== > * Missing javadoc for the public library methods > > > test/lib/testlibrary/jdk/testlibrary/Utils.java > =============================================== > * Missing javadoc for the public library methods > > * 57 serverSocket.close() should be called in "finally" block to make > sure the resources are released even in case of an exception being thrown > > > test/sun/tools/jstatd/JstatGcutilParser.java > ============================================ > * The comments from the original test explaining the tested format are > missing > > > Cheers, > > -JB- From thomas.schatzl at oracle.com Wed Oct 16 03:35:49 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 16 Oct 2013 12:35:49 +0200 Subject: RFR (S): 8025925: jmap fails with "field _length not found in type HeapRegionSeq" In-Reply-To: <789CB0EE-019F-4FFA-BFE1-2F6C31D2721B@oracle.com> References: <1381834405.2686.75.camel@cirrus> <789CB0EE-019F-4FFA-BFE1-2F6C31D2721B@oracle.com> Message-ID: <1381919749.2747.8.camel@cirrus> Hi, On Wed, 2013-10-16 at 10:48 +0200, Staffan Larsen wrote: > Looks good! > Thanks Staffan and Mikael for the reviews! Thomas From staffan.larsen at oracle.com Wed Oct 16 03:42:21 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Wed, 16 Oct 2013 10:42:21 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8025638: jmap returns 0 instead of 1 when it fails. Message-ID: <20131016104226.C815462455@hg.openjdk.java.net> Changeset: 7fe6ef09d242 Author: farvidsson Date: 2013-10-16 09:20 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7fe6ef09d242 8025638: jmap returns 0 instead of 1 when it fails. Summary: Re-factored some code handling return values and fails/errors during tool execution. Reviewed-by: sla, kevinw Contributed-by: fredrik.arvidsson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FlagDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JSnap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/ObjectHistogram.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/StackTrace.java ! agent/src/share/classes/sun/jvm/hotspot/tools/SysPropsDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/JSDB.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java From dmitry.degrave at oracle.com Wed Oct 16 04:17:36 2013 From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com) Date: Wed, 16 Oct 2013 11:17:36 +0000 Subject: hg: jdk8/tl/jdk: 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed Message-ID: <20131016111755.CC42F62456@hg.openjdk.java.net> Changeset: 9ea6a464c147 Author: igerasim Date: 2013-10-15 21:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9ea6a464c147 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed Summary: Properly close PipedStreams. Additional testing for malformed input Reviewed-by: darcy, sherman ! test/java/util/zip/GZIP/GZIPInZip.java From mikael.auno at oracle.com Wed Oct 16 05:04:21 2013 From: mikael.auno at oracle.com (Mikael Auno) Date: Wed, 16 Oct 2013 14:04:21 +0200 Subject: RFR: 8009681: TEST_BUG: MethodExitReturnValuesTest.java fails with when there are unexpected background threads In-Reply-To: <62E7E237-46A6-46A7-8682-BE332F296F3D@oracle.com> References: <516E9DB9.8020009@oracle.com> <62E7E237-46A6-46A7-8682-BE332F296F3D@oracle.com> Message-ID: <525E80C5.6040802@oracle.com> This bug got a bit lost from my radar after vacation, but I've picked it again now. I've moved Arrays.asList() as suggested. In further testing of the fix though, I found that the include list is not enough, as one of the expected method exit events is from String.intern(), which might also be called from background threads. To counter this, I added a thread filter to the events. This also has the added benefit of speeding up the test significantly (from 90 seconds to about 5 seconds) in the cases where there are background threads interfering. Also added to this webrev is a fix for MethodEntryExitEvents.java which had exactly the same problem and a similar test design as MethodExitReturnValuesTest.java. The updated webrev is at http://cr.openjdk.java.net/~allwin/auno/8009681/webrev.00/. Thanks, Mikael On 2013-05-28 08:46, Staffan Larsen wrote: > Looks good. > > You could optimize it a bit by not doing the Arrays.asList() on every > methodExit event. > > /Staffan > > On 17 apr 2013, at 15:03, Mikael Auno > wrote: > >> Hi, I'd like some reviews on >> http://cr.openjdk.java.net/~nloodin/8009681/webrev.01/ for >> JDK-8009681 (http://bugs.sun.com/view_bug.do?bug_id=8009681). >> >> The issue here is that when MethodExitReturnValuesTest hooks into >> MethodExit events through JDI it uses an exclude list to filter out >> classes from which it is not interested in these events. This is >> bound to break over and over again as new features are added to the >> JDK. I've changed the test to use an include list instead, >> containing only the handful of classes the test is actually >> interested in. >> >> Thanks, >> Mikael > From erik.joelsson at oracle.com Wed Oct 16 05:25:42 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 16 Oct 2013 12:25:42 +0000 Subject: hg: jdk8/tl: 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Message-ID: <20131016122542.E4D5B62459@hg.openjdk.java.net> Changeset: af81988013b5 Author: erikj Date: 2013-10-16 13:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/af81988013b5 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Reviewed-by: dholmes, chegar ! common/makefiles/JavaCompilation.gmk ! common/makefiles/RMICompilation.gmk From erik.joelsson at oracle.com Wed Oct 16 05:26:00 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 16 Oct 2013 12:26:00 +0000 Subject: hg: jdk8/tl/corba: 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Message-ID: <20131016122602.1BA126245A@hg.openjdk.java.net> Changeset: 438c54c148a6 Author: erikj Date: 2013-10-16 13:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/438c54c148a6 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Reviewed-by: dholmes, chegar ! makefiles/BuildCorba.gmk From erik.joelsson at oracle.com Wed Oct 16 06:53:54 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 16 Oct 2013 13:53:54 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131016135529.AE6586245F@hg.openjdk.java.net> Changeset: 76a7c0bc74fd Author: erikj Date: 2013-10-16 13:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76a7c0bc74fd 6604021: RMIC is defaulting to BOOT jdk version, needs to be rmic.jar Reviewed-by: dholmes, chegar ! makefiles/GendataBreakIterator.gmk ! makefiles/GenerateClasses.gmk ! makefiles/Setup.gmk ! src/share/classes/sun/tools/tree/Node.java Changeset: e078fd8a78f6 Author: erikj Date: 2013-10-16 15:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e078fd8a78f6 Merge From shanliang.jiang at oracle.com Wed Oct 16 06:58:31 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 16 Oct 2013 15:58:31 +0200 Subject: Codereview request: 8026028 [findbugs] findbugs report some issue in com.sun.jmx.snmp package In-Reply-To: <508E8F79.60909@oracle.com> References: <508E8F79.60909@oracle.com> Message-ID: <525E9B87.9050406@oracle.com> Hi, Please review the following fix, main issue here is that we should clone an internal variable before returning. webrev: http://cr.openjdk.java.net/~sjiang/JDK-8026028/00/ bug https://bugs.openjdk.java.net/browse/JDK-8026028 Thanks, Shanliang From rob.mckenna at oracle.com Wed Oct 16 07:08:57 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Wed, 16 Oct 2013 14:08:57 +0000 Subject: hg: jdk8/tl/jdk: 8026245: InetAddress.getLocalHost crash if IPv6 disabled (macosx) Message-ID: <20131016140923.AF19E62460@hg.openjdk.java.net> Changeset: d8eec0e3a023 Author: robm Date: 2013-10-16 15:06 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d8eec0e3a023 8026245: InetAddress.getLocalHost crash if IPv6 disabled (macosx) Reviewed-by: chegar, alanb ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! test/java/net/InetAddress/GetLocalHostWithSM.java ! test/java/net/Socket/GetLocalAddress.java From jaroslav.bachorik at oracle.com Wed Oct 16 07:18:39 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 16 Oct 2013 16:18:39 +0200 Subject: RFR 7197919: java/lang/management/ThreadMXBean/ThreadBlockedCount.java has concurency issues Message-ID: <525EA03F.2070106@oracle.com> Please, review this simple test change. The test tries to get the number of times a certain thread was blocked during the test run and intermittently fails with the difference of 1 - the expected number is 4 but the reported number is 3. When updating the thread statistics (the blocked count in this case) no lock is used so there might be stale data when the ThreadMXBean retrieves the stats. The patch tries to workaround this problem by retrying a few times with the added delay. The test will try to obtain the correct result for at most 10 seconds - after that it will fail if the retrieved blocked count does not equal the expected blocked count. Issue : https://bugs.openjdk.java.net/browse/JDK-7197919 Webrev: http://cr.openjdk.java.net/~jbachorik/7197919/webrev.00 Thanks, -JB- From jaroslav.bachorik at oracle.com Wed Oct 16 07:44:47 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 16 Oct 2013 16:44:47 +0200 Subject: [PING] Re: jmx-dev RFR: 8024613 javax/management/remote/mandatory/connection/RMIConnector_NPETest.java failing intermittently In-Reply-To: <524BFB87.10808@oracle.com> References: <523C3F8B.6080002@oracle.com> <523C459A.3080303@oracle.com> <524BFB87.10808@oracle.com> Message-ID: <525EA65F.9040509@oracle.com> On 2.10.2013 12:55, Jaroslav Bachorik wrote: > On 20.9.2013 14:54, shanliang wrote: >> Jaroslav, >> >> It is a good idea to use the RMI Testlibrary. >> >> Better to call: >> agent.close(); >> >> at Line 55, close the RMIRegistry (rmid.shutdown(rmidPort) Line 55) >> does not ensure the JMX connector doing full clean, it is always better >> to do clean within a test. > > Thanks. Implemented. > > http://cr.openjdk.java.net/~jbachorik/8024613/webrev.01 > > -JB- > >> >> Shanliang >> >> >> Jaroslav Bachorik wrote: >>> Please, review the following change for JDK-8024613 >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8024613 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8024613/webrev.00/ >>> >>> >>> The patch takes care of intermittent test failures caused by timing >>> issues when starting the RMID process. It could happen that the RMID >>> process hasn't been properly initialized in the timeframe of 5 seconds >>> and the test would fail. >>> >>> The patch replaces the home-brewed RMID process management with the >>> one available in the RMI Testlibrary which is used by more tests and >>> therefore should be more stable. >>> >>> Thanks, >>> >>> -JB- >> > From daniel.fuchs at oracle.com Wed Oct 16 07:49:42 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 16 Oct 2013 16:49:42 +0200 Subject: [PING] Re: jmx-dev RFR: 8024613 javax/management/remote/mandatory/connection/RMIConnector_NPETest.java failing intermittently In-Reply-To: <525EA65F.9040509@oracle.com> References: <523C3F8B.6080002@oracle.com> <523C459A.3080303@oracle.com> <524BFB87.10808@oracle.com> <525EA65F.9040509@oracle.com> Message-ID: <525EA786.6020508@oracle.com> Hi Jaroslav, Looks fine to me (not a reviewer). -- daniel On 10/16/13 4:44 PM, Jaroslav Bachorik wrote: > On 2.10.2013 12:55, Jaroslav Bachorik wrote: >> On 20.9.2013 14:54, shanliang wrote: >>> Jaroslav, >>> >>> It is a good idea to use the RMI Testlibrary. >>> >>> Better to call: >>> agent.close(); >>> >>> at Line 55, close the RMIRegistry (rmid.shutdown(rmidPort) Line 55) >>> does not ensure the JMX connector doing full clean, it is always better >>> to do clean within a test. >> >> Thanks. Implemented. >> >> http://cr.openjdk.java.net/~jbachorik/8024613/webrev.01 >> >> -JB- >> >>> >>> Shanliang >>> >>> >>> Jaroslav Bachorik wrote: >>>> Please, review the following change for JDK-8024613 >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8024613 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8024613/webrev.00/ >>>> >>>> >>>> The patch takes care of intermittent test failures caused by timing >>>> issues when starting the RMID process. It could happen that the RMID >>>> process hasn't been properly initialized in the timeframe of 5 seconds >>>> and the test would fail. >>>> >>>> The patch replaces the home-brewed RMID process management with the >>>> one available in the RMI Testlibrary which is used by more tests and >>>> therefore should be more stable. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From shanliang.jiang at oracle.com Wed Oct 16 07:50:13 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Wed, 16 Oct 2013 16:50:13 +0200 Subject: [PING] Re: jmx-dev RFR: 8024613 javax/management/remote/mandatory/connection/RMIConnector_NPETest.java failing intermittently In-Reply-To: <525EA65F.9040509@oracle.com> References: <523C3F8B.6080002@oracle.com> <523C459A.3080303@oracle.com> <524BFB87.10808@oracle.com> <525EA65F.9040509@oracle.com> Message-ID: <525EA7A5.7080904@oracle.com> Looks fine to me. Shanliang Jaroslav Bachorik wrote: > On 2.10.2013 12:55, Jaroslav Bachorik wrote: >> On 20.9.2013 14:54, shanliang wrote: >>> Jaroslav, >>> >>> It is a good idea to use the RMI Testlibrary. >>> >>> Better to call: >>> agent.close(); >>> >>> at Line 55, close the RMIRegistry (rmid.shutdown(rmidPort) Line 55) >>> does not ensure the JMX connector doing full clean, it is always better >>> to do clean within a test. >> >> Thanks. Implemented. >> >> http://cr.openjdk.java.net/~jbachorik/8024613/webrev.01 >> >> -JB- >> >>> >>> Shanliang >>> >>> >>> Jaroslav Bachorik wrote: >>>> Please, review the following change for JDK-8024613 >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8024613 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8024613/webrev.00/ >>>> >>>> >>>> The patch takes care of intermittent test failures caused by timing >>>> issues when starting the RMID process. It could happen that the RMID >>>> process hasn't been properly initialized in the timeframe of 5 seconds >>>> and the test would fail. >>>> >>>> The patch replaces the home-brewed RMID process management with the >>>> one available in the RMI Testlibrary which is used by more tests and >>>> therefore should be more stable. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From daniel.fuchs at oracle.com Wed Oct 16 08:22:37 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Wed, 16 Oct 2013 15:22:37 +0000 Subject: hg: jdk8/tl/jdk: 8011638: Remove deprecated methods in sun.util.logging.PlatformLogger Message-ID: <20131016152401.B019A62465@hg.openjdk.java.net> Changeset: 445667b19e32 Author: dfuchs Date: 2013-10-16 17:19 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/445667b19e32 8011638: Remove deprecated methods in sun.util.logging.PlatformLogger Reviewed-by: psandoz, mchung, alanb, chegar ! src/share/classes/sun/font/FontUtilities.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! test/sun/util/logging/PlatformLoggerTest.java From erik.helin at oracle.com Wed Oct 16 09:09:14 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 16 Oct 2013 18:09:14 +0200 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops Message-ID: <20131016160914.GA10865@ehelin-thinkpad> Hi all, this patch fixes an issue where an oop in JvmtiBreakpoint, JvmtiBreakpoint::_class_loader, was found by the unhandled oop detector. Instead of registering the oop as an unhandled oop, which would have worked, I decided to wrap the oop in a handle as long as it is on the stack. A JvmtiBreakpoint is created on the stack by the two methods JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This JvmtiBreakpoint is only created to carry the Method*, jlocation and oop to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, when at a safepoint, allocate a new JvmtiBreakpoint on the native heap, copy the values from the stack allocated JvmtiBreakpoint and then place/clear the newly alloacted JvmtiBreakpoint in JvmtiCurrentBreakpoints::_jvmti_breakpoints. I have updated to the code to check that the public constructor is only used to allocate JvmtiBreakpoints on the stack (to warn a future programmer if he/she decides to allocate one on the heap). The class_loader oop is now wrapped in a Handle for stack allocated JvmtiBreakpoints. Due to the stack allocated JvmtiBreakpoint having the oop in a handle, the oops_do method of VM_ChangeBreakpoints can be removed. This also makes the oop in the handle safe for use after the VM_ChangeBreakpoint operation is finished. The unhandled oop in the JvmtiBreakpoint allocated on the heap will be visited by the GC via jvmtiExport::oops_do -> JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being added to. I've also removed some dead code to simplify the change: - GrowableCache::insert - JvmtiBreakpoint::copy - JvmtiBreakpoint::lessThan - GrowableElement::lessThan Finally, I also formatted JvmtiEnv::ClearBreakpoint and Jvmti::SetBreakpoint exactly the same to highlight that they share all code except one line. Unfortunately, I was not able to remove this code duplication in a good way. Webrev: http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ Testing: - JPRT - The four tests that were failing are now passing Thanks, Erik From jaroslav.bachorik at oracle.com Wed Oct 16 09:16:15 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 16 Oct 2013 18:16:15 +0200 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <525CE56D.4000708@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> <52556604.3080900@oracle.com> <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> <525622B4.5020606@oracle.com> <52568940.4000704@oracle.com> <23435103-156B-434F-994C-B6F913EE0364@oracle.com> <525BFC0D.8090101@oracle.com> <525CE56D.4000708@oracle.com> Message-ID: <525EBBCF.3020303@oracle.com> On 15.10.2013 08:49, David Holmes wrote: > Hi Jaroslav, > > os_bsd.cpp / os_linux.cpp: > > If you don't have a monotonic clock you leave timer_frequency set to 0! > (So you need to test on a system without a monotonic clock, or else > force it to act as-if not present.) > > That aside I don't trust clock_getres to give values that actually allow > the timer frequency to be determined. As per the comments in os_linux.cpp: > > // It's fixed in newer kernels, however clock_getres() still returns > // 1/HZ. We check if clock_getres() works, but will ignore its reported > // resolution for now. Hopefully as people move to new kernels, this > // won't be a problem. > > we don't know what kernels provide real values here and which provide > dummy ones. > > On BSD you haven't modified os::elapsed_counter. > > Looking at the linux changes I don't think the logic is correct even if > clock_getres is accurate. In the existing code we have: > > elapsed_counter -> elapsed time in microseconds > elapsed_frequency -> 1000 * 1000 (ie micros per second) > elapsed_time -> elapsed_counter*0.000001 -> time in seconds > > Now we have: > > elapsed_counter -> elapsed time in nanoseconds > elapsed_frequency -> 1x10^9 / whatever clock_getres says > elapsed_time -> counter/frequency -> ??? > > So elapsed_time not, in general, going to give the elapsed time in > seconds. And elapsed_time is not dependent on the "frequency" at all > because elapsed_counter is not reporting ticks but an actual elapsed > "time" in nanoseconds. > > > Also note that we constants for: > > NANOSECS_PER_SEC > NANOSECS_PER_MILLISEC > > to aid with time conversions. > > The linux webrev contains unrelated UseLargePages changes! Sorry for the mess with UseLargePages changes :/ I've fixed the problems with the frequency (using a fixed number as before) and I kept the changes to minimum. I was hesitating about changing the elapsed_counter precision from microseconds to nanoseconds but since solaris and windows versions already use nanosecond ticks for elapsed_counter I think the change is safe. The update webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 > > > David > ----- > > > On 15/10/2013 12:13 AM, Jaroslav Bachorik wrote: >> On 10.10.2013 13:15, Staffan Larsen wrote: >>> >>> On 10 okt 2013, at 13:02, Jaroslav Bachorik >>> wrote: >>> >>>> On 10.10.2013 05:44, David Holmes wrote: >>>>> On 10/10/2013 4:12 AM, Staffan Larsen wrote: >>>>>> >>>>>> On 9 okt 2013, at 16:19, Jaroslav Bachorik >>>>>> wrote: >>>>>> >>>>>>> On 9.10.2013 16:10, Staffan Larsen wrote: >>>>>>>> There is now an awful amount of different timestamps in the >>>>>>>> Management class. Can they be consolidated somehow? At least >>>>>>>> _begin_vm_creation_time and the new _begin_vm_creation_ns. >>>>>>>> >>>>>>>> This discussion also implies that the "elapsed time" we print in >>>>>>>> the >>>>>>>> hs_err file is also wrong. It uses os::elapsedTime() which uses >>>>>>>> os::elapsed_counter(). >>>>>>>> >>>>>>>> And I guess the same thing for the VM.uptime Diagnostic Command >>>>>>>> (class VMUptimeDCmd) which also relies on os::elapsed_counter(). >>>>>>> >>>>>>> Also the reported GC pauses duration might be wrong since it uses >>>>>>> Management::timestamp(). >>>>>>> >>>>>>> On the first sight the change looks rather trivial. But, honestly, >>>>>>> I'm not sure which other parts could for whatever reason break once >>>>>>> the time-of-day timestamp is replaced with a monotonic equivalent. >>>>>>> One would think that it shouldn't matter but one never knows ... >>>>>>> >>>>>>> Staffan, do you think this kind of change is suitable for the >>>>>>> current >>>>>>> phase of JDK release cycle? I think I could improve the patch in few >>>>>>> days and then it should probably be able to pass the review before >>>>>>> ZBB. But, it's only P3 ... >>>>>> >>>>>> I think it is a bit late in the release cycle to clean this up in the >>>>>> way it should be cleaned up. I think we should wait until the first 8 >>>>>> update release and do a more thorough job than we have time for right >>>>>> now. >>>>> >>>>> I second that. The elapsed_counter/elpased_timer APIs and >>>>> implementations are a tangled mess. But part of the problem has been >>>>> that people want/expect monotonic time-of-day based timestamps (yes a >>>>> contradiction - though some people make sure TOD does not get modified >>>>> on their production systems). The use of timestamps in logging has >>>>> to be >>>>> examined carefully - mainly GC logging. I recall a "simple" attempted >>>>> change in the past that resulted in trying to compare a nanoTime based >>>>> timestamp with the TOD. :( >>>> >>>> Actually, if I'm reading the sources right for Solaris and Win the >>>> monotonic clock source is used to provide elapsed_counter() value. It >>>> falls back to TOD when the monotonic clock source is not available. >>>> For Linux/BSD the TOD is used directly. >>>> >>>> This makes me wonder if changing the linux/bsd implementation to >>>> follow the same logic would be really that disruptive. >>> >>> Good point. I would like a world where elapsed_counter is monotonic >>> (where possible). Still a bit scary this late in the release, but an >>> interesting experiment. >> >> The change is rather simple and tests ok. All the means to get a >> monotonic timestamp are already there and proved to work. The core tests >> in JPRT went fine. >> >> The updated webrev is at >> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.02 >> >> -JB- >> >>> >>> /Staffan >>> >>> >>> >>> >>>> >>>> -JB- >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> /Staffan >>>>>> >>>>>> >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> >>>>>>>> /Staffan >>>>>>>> >>>>>>>> >>>>>>>> On 9 okt 2013, at 13:26, Jaroslav Bachorik >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 8.10.2013 23:46, David Holmes wrote: >>>>>>>>>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>>>>>>>>> On 8.10.2013 09:34, David Holmes wrote: >>>>>>>>>>>> Jaroslav, >>>>>>>>>>>> >>>>>>>>>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> currently the JVM uptime reported by the RuntimeMXBean is >>>>>>>>>>>>> based on >>>>>>>>>>>>> System.currentTimeMillis() which makes it susceptible to >>>>>>>>>>>>> changes of the >>>>>>>>>>>>> OS time (eg. changing timezone, NTP synchronization etc.). The >>>>>>>>>>>>> uptime >>>>>>>>>>>>> should not depend on the system time and should be calculated >>>>>>>>>>>>> using a >>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>> >>>>>>>>>>>>> There is already the way to get the actual JVM uptime in >>>>>>>>>>>>> ticks. >>>>>>>>>>>>> It is >>>>>>>>>>>>> accessible as Management::timestamp() and the ticks are >>>>>>>>>>>>> convertible to >>>>>>>>>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus >>>>>>>>>>>>> making it >>>>>>>>>>>>> very >>>>>>>>>>>>> easy to switch to the monotonic clock based uptime. >>>>>>>>>>>> >>>>>>>>>>>> Maybe I'm missing something but TiumeStamp updates using >>>>>>>>>>>> os::elapsed_counter() which on Linux uses gettimeofday so is >>>>>>>>>>>> not a >>>>>>>>>>>> monotonic clock source. >>>>>>>>>>> >>>>>>>>>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>>>>>>>>> >>>>>>>>>>> Is there any reason why a non monotonic clock source is used for >>>>>>>>>>> timestamping except of the historical one? os::javaTimeNanos() >>>>>>>>>>> uses >>>>>>>>>>> montonic clock when available - why can't be the same used for >>>>>>>>>>> os::elapsed_counter() especially when a counter based on >>>>>>>>>>> "gettimeofday" >>>>>>>>>>> is not really a counter? >>>>>>>>>> >>>>>>>>>> It is all historical. These elapsed_counters and elapsed_timers >>>>>>>>>> make me >>>>>>>>>> cringe. But changing it has a lot of potential consequences >>>>>>>>>> because of >>>>>>>>>> the way these are used in logging etc. Certainly not something >>>>>>>>>> to be >>>>>>>>>> contemplated at this stage of JDK 8. >>>>>>>>>> >>>>>>>>>> Perhaps a simpler fix here is to expose a startUpTimeNanos that >>>>>>>>>> can then >>>>>>>>>> be used for the uptime. >>>>>>>>> >>>>>>>>> My attempt at this is at >>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >>>>>>>>> I am using os::javaTimeNanos() to get the monotonic ticks where >>>>>>>>> possible. >>>>>>>>> >>>>>>>>> The JDK part stays the same as for webrev.00 >>>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> The patch consists of the hotspot and jdk parts. >>>>>>>>>>>>> >>>>>>>>>>>>> For the hotspot a new constant needs to be introduced in >>>>>>>>>>>>> src/share/vm/services/jmm.h and the actual logic to obtain the >>>>>>>>>>>>> uptime in >>>>>>>>>>>>> milliseconds is added in src/share/vm/services/management.cpp. >>>>>>>>>>>>> >>>>>>>>>>>>> For the jdk the changes comprise of adding the necessary JNI >>>>>>>>>>>>> bridging >>>>>>>>>>>>> methods in order to get the new uptime, introducing the same >>>>>>>>>>>>> constant >>>>>>>>>>>>> that is used in hotspot and changes to mapfile-vers files in >>>>>>>>>>>>> order to >>>>>>>>>>>>> properly build the native library. >>>>>>>>>>>>> >>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>>>>>>>>> Webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> From coleen.phillimore at oracle.com Wed Oct 16 10:25:50 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 16 Oct 2013 13:25:50 -0400 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <20131016160914.GA10865@ehelin-thinkpad> References: <20131016160914.GA10865@ehelin-thinkpad> Message-ID: <525ECC1E.4000805@oracle.com> Erik, Thank you for doing the extra cleanup for this. Did you run the nsk.jvmti.testlist tests too though? These things have a nasty way of interacting. The code looks good though. thanks, Coleen On 10/16/2013 12:09 PM, Erik Helin wrote: > Hi all, > > this patch fixes an issue where an oop in JvmtiBreakpoint, > JvmtiBreakpoint::_class_loader, was found by the unhandled oop detector. > > Instead of registering the oop as an unhandled oop, which would have > worked, I decided to wrap the oop in a handle as long as it is on the > stack. > > A JvmtiBreakpoint is created on the stack by the two methods > JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This > JvmtiBreakpoint is only created to carry the Method*, jlocation and oop > to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, when > at a safepoint, allocate a new JvmtiBreakpoint on the native heap, copy > the values from the stack allocated JvmtiBreakpoint and then place/clear the > newly alloacted JvmtiBreakpoint in > JvmtiCurrentBreakpoints::_jvmti_breakpoints. > > I have updated to the code to check that the public constructor is only > used to allocate JvmtiBreakpoints on the stack (to warn a future > programmer if he/she decides to allocate one on the heap). The > class_loader oop is now wrapped in a Handle for stack allocated > JvmtiBreakpoints. > > Due to the stack allocated JvmtiBreakpoint having the oop in a handle, > the oops_do method of VM_ChangeBreakpoints can be removed. This also > makes the oop in the handle safe for use after the VM_ChangeBreakpoint > operation is finished. > > The unhandled oop in the JvmtiBreakpoint allocated on the heap will be > visited by the GC via jvmtiExport::oops_do -> > JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> > GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being > added to. > > I've also removed some dead code to simplify the change: > - GrowableCache::insert > - JvmtiBreakpoint::copy > - JvmtiBreakpoint::lessThan > - GrowableElement::lessThan > > Finally, I also formatted JvmtiEnv::ClearBreakpoint and > Jvmti::SetBreakpoint exactly the same to highlight that they share all > code except one line. Unfortunately, I was not able to remove this code > duplication in a good way. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ > > Testing: > - JPRT > - The four tests that were failing are now passing > > Thanks, > Erik From mikael.gerdin at oracle.com Wed Oct 16 10:47:36 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 16 Oct 2013 19:47:36 +0200 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <20131016160914.GA10865@ehelin-thinkpad> References: <20131016160914.GA10865@ehelin-thinkpad> Message-ID: <525ED138.1000305@oracle.com> Erik, (it's not necessary to cross-post between hotspot-dev and hotspot-gc-dev, so I removed hotspot-gc from the CC list) On 2013-10-16 18:09, Erik Helin wrote: > Hi all, > > this patch fixes an issue where an oop in JvmtiBreakpoint, > JvmtiBreakpoint::_class_loader, was found by the unhandled oop detector. > > Instead of registering the oop as an unhandled oop, which would have > worked, I decided to wrap the oop in a handle as long as it is on the > stack. > > A JvmtiBreakpoint is created on the stack by the two methods > JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This > JvmtiBreakpoint is only created to carry the Method*, jlocation and oop > to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, when > at a safepoint, allocate a new JvmtiBreakpoint on the native heap, copy > the values from the stack allocated JvmtiBreakpoint and then place/clear the > newly alloacted JvmtiBreakpoint in > JvmtiCurrentBreakpoints::_jvmti_breakpoints. > > I have updated to the code to check that the public constructor is only > used to allocate JvmtiBreakpoints on the stack (to warn a future > programmer if he/she decides to allocate one on the heap). The > class_loader oop is now wrapped in a Handle for stack allocated > JvmtiBreakpoints. > > Due to the stack allocated JvmtiBreakpoint having the oop in a handle, > the oops_do method of VM_ChangeBreakpoints can be removed. This also > makes the oop in the handle safe for use after the VM_ChangeBreakpoint > operation is finished. > > The unhandled oop in the JvmtiBreakpoint allocated on the heap will be > visited by the GC via jvmtiExport::oops_do -> > JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> > GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being > added to. > > I've also removed some dead code to simplify the change: > - GrowableCache::insert > - JvmtiBreakpoint::copy > - JvmtiBreakpoint::lessThan > - GrowableElement::lessThan > > Finally, I also formatted JvmtiEnv::ClearBreakpoint and > Jvmti::SetBreakpoint exactly the same to highlight that they share all > code except one line. Unfortunately, I was not able to remove this code > duplication in a good way. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ jvmtiImpl.hpp: Since clone() uses unhandled oops, and is only supposed to be used by the VM operation, would it make sense to assert(SafepointSynchronize::is_at_safepoint())? 196 GrowableElement *clone() { 197 return new JvmtiBreakpoint(_method, _bci, _class_loader_handle); jvmtiImpl.cpp: No comments. jvmtiEnv.cpp: Have you verified that the generated JVMTI entry point contains a ResourceMark or is it just not needed? - ResourceMark rm; + HandleMark hm; Otherwise the code change looks good. One thing that you didn't describe here, but which was related to the bug (which we discussed) was the fact that the old code tried to "do the right thing" WRT CheckUnhandledOops, but it incorrectly added a Method*: thread->allow_unhandled_oop((oop*)&_method); We should take care to find other such places where we try to put a non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in the unhandled oops code. /Mikael > > Testing: > - JPRT > - The four tests that were failing are now passing > > Thanks, > Erik > From jonathan.gibbons at oracle.com Wed Oct 16 10:49:47 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 16 Oct 2013 17:49:47 +0000 Subject: hg: jdk8/tl/langtools: 8026704: Build failure with --enable-debug Message-ID: <20131016174953.24F266246F@hg.openjdk.java.net> Changeset: d7e155f874a7 Author: jjg Date: 2013-10-16 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d7e155f874a7 8026704: Build failure with --enable-debug Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java - test/tools/javac/lambda/LocalVariableTable.java From daniel.fuchs at oracle.com Wed Oct 16 11:50:18 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Wed, 16 Oct 2013 18:50:18 +0000 Subject: hg: jdk8/tl/jdk: 8013839: Enhance Logger API for handling of resource bundles; ... Message-ID: <20131016185101.EFBBA62472@hg.openjdk.java.net> Changeset: 2ef43f3a901c Author: dfuchs Date: 2013-10-16 20:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ef43f3a901c 8013839: Enhance Logger API for handling of resource bundles 4814565: (rb) add method to get basename from a ResourceBundle Summary: adds Logger.setResourceBundle(ResourceBundle) and ResourceBundle.getBaseBundleName() Reviewed-by: mchung, naoto ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/logging/Logger.java + test/java/util/ResourceBundle/getBaseBundleName/TestGetBaseBundleName.java + test/java/util/ResourceBundle/getBaseBundleName/resources/ListBundle.java + test/java/util/ResourceBundle/getBaseBundleName/resources/ListBundle_fr.java + test/java/util/ResourceBundle/getBaseBundleName/resources/PropertyBundle.properties + test/java/util/ResourceBundle/getBaseBundleName/resources/PropertyBundle_fr.properties + test/java/util/logging/Logger/logrb/TestLogrbResourceBundle.java + test/java/util/logging/Logger/logrb/resources/ListBundle.java + test/java/util/logging/Logger/logrb/resources/ListBundle_fr.java + test/java/util/logging/Logger/logrb/resources/PropertyBundle.properties + test/java/util/logging/Logger/logrb/resources/PropertyBundle_fr.properties + test/java/util/logging/Logger/setResourceBundle/TestSetResourceBundle.java + test/java/util/logging/Logger/setResourceBundle/resources/ListBundle.java + test/java/util/logging/Logger/setResourceBundle/resources/ListBundle_fr.java + test/java/util/logging/Logger/setResourceBundle/resources/PropertyBundle.properties + test/java/util/logging/Logger/setResourceBundle/resources/PropertyBundle_fr.properties From staffan.larsen at oracle.com Wed Oct 16 12:23:00 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Wed, 16 Oct 2013 19:23:00 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8026703: Wrongly placed element in Event-Based JVM Tracing .xsl files Message-ID: <20131016192309.5755D62478@hg.openjdk.java.net> Changeset: 042cf42c72bd Author: simonis Date: 2013-10-16 15:06 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/042cf42c72bd 8026703: Wrongly placed element in Event-Based JVM Tracing .xsl files Reviewed-by: sla, kamg ! src/share/vm/trace/traceEventClasses.xsl ! src/share/vm/trace/traceEventIds.xsl ! src/share/vm/trace/traceTypes.xsl From mike.duigou at oracle.com Wed Oct 16 13:12:51 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 16 Oct 2013 20:12:51 +0000 Subject: hg: jdk8/tl/jdk: 8025910: rename substream(long) -> skip and remove substream(long, long) Message-ID: <20131016201329.3606C6247F@hg.openjdk.java.net> Changeset: cf9cb3d241a3 Author: mduigou Date: 2013-10-16 13:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf9cb3d241a3 8025910: rename substream(long) -> skip and remove substream(long,long) Reviewed-by: psandoz, henryjen ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongPipeline.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java ! test/java/util/stream/boottest/java/util/stream/SpinedBufferTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntSliceOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java From eric.mccorkle at oracle.com Wed Oct 16 13:33:46 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Wed, 16 Oct 2013 20:33:46 +0000 Subject: hg: jdk8/tl/langtools: 8026286: Improper locking of annotation queues causes assertion failures.; ... Message-ID: <20131016203408.AFEED62487@hg.openjdk.java.net> Changeset: 7f6481e5fe3a Author: emc Date: 2013-10-16 16:33 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7f6481e5fe3a 8026286: Improper locking of annotation queues causes assertion failures. 8026063: Calls to annotate.flush() cause incorrect type annotations to be generated. Summary: Fix locking in ClassReader.java Reviewed-by: jfranck ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/annotations/typeAnnotations/TestAnonInnerInstance1.java ! test/tools/javac/annotations/typeAnnotations/classfile/T8008762.java From sean.coffey at oracle.com Wed Oct 16 13:21:42 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Wed, 16 Oct 2013 20:21:42 +0000 Subject: hg: jdk8/tl/jdk: 8025255: (tz) Support tzdata2013g Message-ID: <20131016202214.A84AF62480@hg.openjdk.java.net> Changeset: 60e3cdbe8cdf Author: aefimov Date: 2013-10-13 14:19 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60e3cdbe8cdf 8025255: (tz) Support tzdata2013g Reviewed-by: okutsu, mfang ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/etcetera ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/iso3166.tab ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/antarctica ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/backward ! test/sun/util/calendar/zi/tzdata/etcetera ! test/sun/util/calendar/zi/tzdata/europe ! test/sun/util/calendar/zi/tzdata/iso3166.tab ! test/sun/util/calendar/zi/tzdata/leapseconds ! test/sun/util/calendar/zi/tzdata/northamerica ! test/sun/util/calendar/zi/tzdata/southamerica ! test/sun/util/calendar/zi/tzdata/zone.tab From dmitry.samersoff at oracle.com Wed Oct 16 14:10:43 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 17 Oct 2013 01:10:43 +0400 Subject: RR(S): JDK-8025812 tmtools/jmap/heap_config tests fail on Linux-ia32 because it 'Can't attach to the core file' In-Reply-To: <4D55BF19-5B5A-4DD1-BC12-E96EEC625438@oracle.com> References: <525931C6.8050607@oracle.com> <4D55BF19-5B5A-4DD1-BC12-E96EEC625438@oracle.com> Message-ID: <525F00D3.8090807@oracle.com> Staffan, Just realized that my letter remain unsent. Fixed in-place, press shift-reload. http://cr.openjdk.java.net/~dsamersoff/JDK-8025812/webrev.01/ -Dmitry On 2013-10-14 11:49, Staffan Larsen wrote: > The fix looks good, but I have a problem with the ROUNDUP_PAGE macro. First, I don't like having macros defined in the middle of a method. Second, the definition of the macro includes the value of a local variable which is a bit hairy. Can't you just ROUNDUP directly in the four places it's needed? I think it would make for more readable code. > > nit on line 743: filed -> field > > Thanks, > /Staffan > > On 12 okt 2013, at 13:25, Dmitry Samersoff wrote: > >> Hi Everybody, >> >> Please review the fix >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8025812/webrev.01/ >> >> The value of p_memsz filed of elf header of LOAD section inside coredump >> is rounded up to page size. So round up corresponding value read from >> the header of library it self. >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Wed Oct 16 14:11:27 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 17 Oct 2013 01:11:27 +0400 Subject: URG! Need a second reviewer! Re: RR(S): JDK-8025812 tmtools/jmap/heap_config tests fail on Linux-ia32 because it 'Can't attach to the core file' In-Reply-To: <4D55BF19-5B5A-4DD1-BC12-E96EEC625438@oracle.com> References: <525931C6.8050607@oracle.com> <4D55BF19-5B5A-4DD1-BC12-E96EEC625438@oracle.com> Message-ID: <525F00FF.9020505@oracle.com> On 2013-10-14 11:49, Staffan Larsen wrote: > The fix looks good, but I have a problem with the ROUNDUP_PAGE macro. First, I don't like having macros defined in the middle of a method. Second, the definition of the macro includes the value of a local variable which is a bit hairy. Can't you just ROUNDUP directly in the four places it's needed? I think it would make for more readable code. > > nit on line 743: filed -> field > > Thanks, > /Staffan > > On 12 okt 2013, at 13:25, Dmitry Samersoff wrote: > >> Hi Everybody, >> >> Please review the fix >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8025812/webrev.01/ >> >> The value of p_memsz filed of elf header of LOAD section inside coredump >> is rounded up to page size. So round up corresponding value read from >> the header of library it self. >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From harold.seigel at oracle.com Wed Oct 16 14:27:23 2013 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Wed, 16 Oct 2013 21:27:23 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20131016212740.9C7E56248B@hg.openjdk.java.net> Changeset: d248425bcfe8 Author: hseigel Date: 2013-10-16 14:32 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d248425bcfe8 8024804: Crash when InterfaceMethodref resolves to Object.registerNatives Summary: Added check for NULL prior to continuation of method look up to avoid runtime crash during look up of Object's superclass' methods. Reviewed-by: coleenp, hseigel Contributed-by: lois.foltan at oracle.com ! src/share/vm/interpreter/linkResolver.cpp + test/runtime/8024804/RegisterNatives.java Changeset: 9e0ef3f02648 Author: hseigel Date: 2013-10-16 15:26 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9e0ef3f02648 Merge From david.holmes at oracle.com Wed Oct 16 19:26:40 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Oct 2013 12:26:40 +1000 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <525EBBCF.3020303@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> <52556604.3080900@oracle.com> <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> <525622B4.5020606@oracle.com> <52568940.4000704@oracle.com> <23435103-156B-434F-994C-B6F913EE0364@oracle.com> <525BFC0D.8090101@oracle.com> <525CE56D.4000708@oracle.com> <525EBBCF.3020303@oracle.com> Message-ID: <525F4AE0.1000406@oracle.com> Hi Jaroslav, Minor nit: os::elapsed_time should really be defined in terms of the other functions ie: return ((double) os::elapsed_counter()) / os::elapsed_frequency(); I also prefer the cast above as it is very clear that we will be doing a floating-point division. Aside: AFAICS os::elapsed_time() is never actually used ?? I agree that it appears that changing the frequency should be okay. Thanks, David On 17/10/2013 2:16 AM, Jaroslav Bachorik wrote: > On 15.10.2013 08:49, David Holmes wrote: >> Hi Jaroslav, >> >> os_bsd.cpp / os_linux.cpp: >> >> If you don't have a monotonic clock you leave timer_frequency set to 0! >> (So you need to test on a system without a monotonic clock, or else >> force it to act as-if not present.) >> >> That aside I don't trust clock_getres to give values that actually allow >> the timer frequency to be determined. As per the comments in >> os_linux.cpp: >> >> // It's fixed in newer kernels, however clock_getres() still returns >> // 1/HZ. We check if clock_getres() works, but will ignore its reported >> // resolution for now. Hopefully as people move to new kernels, this >> // won't be a problem. >> >> we don't know what kernels provide real values here and which provide >> dummy ones. >> >> On BSD you haven't modified os::elapsed_counter. >> >> Looking at the linux changes I don't think the logic is correct even if >> clock_getres is accurate. In the existing code we have: >> >> elapsed_counter -> elapsed time in microseconds >> elapsed_frequency -> 1000 * 1000 (ie micros per second) >> elapsed_time -> elapsed_counter*0.000001 -> time in seconds >> >> Now we have: >> >> elapsed_counter -> elapsed time in nanoseconds >> elapsed_frequency -> 1x10^9 / whatever clock_getres says >> elapsed_time -> counter/frequency -> ??? >> >> So elapsed_time not, in general, going to give the elapsed time in >> seconds. And elapsed_time is not dependent on the "frequency" at all >> because elapsed_counter is not reporting ticks but an actual elapsed >> "time" in nanoseconds. >> >> >> Also note that we constants for: >> >> NANOSECS_PER_SEC >> NANOSECS_PER_MILLISEC >> >> to aid with time conversions. >> >> The linux webrev contains unrelated UseLargePages changes! > > Sorry for the mess with UseLargePages changes :/ > > I've fixed the problems with the frequency (using a fixed number as > before) and I kept the changes to minimum. > > I was hesitating about changing the elapsed_counter precision from > microseconds to nanoseconds but since solaris and windows versions > already use nanosecond ticks for elapsed_counter I think the change is > safe. > > The update webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 > >> >> >> David >> ----- >> >> >> On 15/10/2013 12:13 AM, Jaroslav Bachorik wrote: >>> On 10.10.2013 13:15, Staffan Larsen wrote: >>>> >>>> On 10 okt 2013, at 13:02, Jaroslav Bachorik >>>> wrote: >>>> >>>>> On 10.10.2013 05:44, David Holmes wrote: >>>>>> On 10/10/2013 4:12 AM, Staffan Larsen wrote: >>>>>>> >>>>>>> On 9 okt 2013, at 16:19, Jaroslav Bachorik >>>>>>> wrote: >>>>>>> >>>>>>>> On 9.10.2013 16:10, Staffan Larsen wrote: >>>>>>>>> There is now an awful amount of different timestamps in the >>>>>>>>> Management class. Can they be consolidated somehow? At least >>>>>>>>> _begin_vm_creation_time and the new _begin_vm_creation_ns. >>>>>>>>> >>>>>>>>> This discussion also implies that the "elapsed time" we print in >>>>>>>>> the >>>>>>>>> hs_err file is also wrong. It uses os::elapsedTime() which uses >>>>>>>>> os::elapsed_counter(). >>>>>>>>> >>>>>>>>> And I guess the same thing for the VM.uptime Diagnostic Command >>>>>>>>> (class VMUptimeDCmd) which also relies on os::elapsed_counter(). >>>>>>>> >>>>>>>> Also the reported GC pauses duration might be wrong since it uses >>>>>>>> Management::timestamp(). >>>>>>>> >>>>>>>> On the first sight the change looks rather trivial. But, honestly, >>>>>>>> I'm not sure which other parts could for whatever reason break once >>>>>>>> the time-of-day timestamp is replaced with a monotonic equivalent. >>>>>>>> One would think that it shouldn't matter but one never knows ... >>>>>>>> >>>>>>>> Staffan, do you think this kind of change is suitable for the >>>>>>>> current >>>>>>>> phase of JDK release cycle? I think I could improve the patch in >>>>>>>> few >>>>>>>> days and then it should probably be able to pass the review before >>>>>>>> ZBB. But, it's only P3 ... >>>>>>> >>>>>>> I think it is a bit late in the release cycle to clean this up in >>>>>>> the >>>>>>> way it should be cleaned up. I think we should wait until the >>>>>>> first 8 >>>>>>> update release and do a more thorough job than we have time for >>>>>>> right >>>>>>> now. >>>>>> >>>>>> I second that. The elapsed_counter/elpased_timer APIs and >>>>>> implementations are a tangled mess. But part of the problem has been >>>>>> that people want/expect monotonic time-of-day based timestamps (yes a >>>>>> contradiction - though some people make sure TOD does not get >>>>>> modified >>>>>> on their production systems). The use of timestamps in logging has >>>>>> to be >>>>>> examined carefully - mainly GC logging. I recall a "simple" attempted >>>>>> change in the past that resulted in trying to compare a nanoTime >>>>>> based >>>>>> timestamp with the TOD. :( >>>>> >>>>> Actually, if I'm reading the sources right for Solaris and Win the >>>>> monotonic clock source is used to provide elapsed_counter() value. It >>>>> falls back to TOD when the monotonic clock source is not available. >>>>> For Linux/BSD the TOD is used directly. >>>>> >>>>> This makes me wonder if changing the linux/bsd implementation to >>>>> follow the same logic would be really that disruptive. >>>> >>>> Good point. I would like a world where elapsed_counter is monotonic >>>> (where possible). Still a bit scary this late in the release, but an >>>> interesting experiment. >>> >>> The change is rather simple and tests ok. All the means to get a >>> monotonic timestamp are already there and proved to work. The core tests >>> in JPRT went fine. >>> >>> The updated webrev is at >>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.02 >>> >>> -JB- >>> >>>> >>>> /Staffan >>>> >>>> >>>> >>>> >>>>> >>>>> -JB- >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>>> >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9 okt 2013, at 13:26, Jaroslav Bachorik >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On 8.10.2013 23:46, David Holmes wrote: >>>>>>>>>>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>> On 8.10.2013 09:34, David Holmes wrote: >>>>>>>>>>>>> Jaroslav, >>>>>>>>>>>>> >>>>>>>>>>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> currently the JVM uptime reported by the RuntimeMXBean is >>>>>>>>>>>>>> based on >>>>>>>>>>>>>> System.currentTimeMillis() which makes it susceptible to >>>>>>>>>>>>>> changes of the >>>>>>>>>>>>>> OS time (eg. changing timezone, NTP synchronization etc.). >>>>>>>>>>>>>> The >>>>>>>>>>>>>> uptime >>>>>>>>>>>>>> should not depend on the system time and should be calculated >>>>>>>>>>>>>> using a >>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is already the way to get the actual JVM uptime in >>>>>>>>>>>>>> ticks. >>>>>>>>>>>>>> It is >>>>>>>>>>>>>> accessible as Management::timestamp() and the ticks are >>>>>>>>>>>>>> convertible to >>>>>>>>>>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus >>>>>>>>>>>>>> making it >>>>>>>>>>>>>> very >>>>>>>>>>>>>> easy to switch to the monotonic clock based uptime. >>>>>>>>>>>>> >>>>>>>>>>>>> Maybe I'm missing something but TiumeStamp updates using >>>>>>>>>>>>> os::elapsed_counter() which on Linux uses gettimeofday so is >>>>>>>>>>>>> not a >>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>> >>>>>>>>>>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>>>>>>>>>> >>>>>>>>>>>> Is there any reason why a non monotonic clock source is used >>>>>>>>>>>> for >>>>>>>>>>>> timestamping except of the historical one? os::javaTimeNanos() >>>>>>>>>>>> uses >>>>>>>>>>>> montonic clock when available - why can't be the same used for >>>>>>>>>>>> os::elapsed_counter() especially when a counter based on >>>>>>>>>>>> "gettimeofday" >>>>>>>>>>>> is not really a counter? >>>>>>>>>>> >>>>>>>>>>> It is all historical. These elapsed_counters and elapsed_timers >>>>>>>>>>> make me >>>>>>>>>>> cringe. But changing it has a lot of potential consequences >>>>>>>>>>> because of >>>>>>>>>>> the way these are used in logging etc. Certainly not something >>>>>>>>>>> to be >>>>>>>>>>> contemplated at this stage of JDK 8. >>>>>>>>>>> >>>>>>>>>>> Perhaps a simpler fix here is to expose a startUpTimeNanos that >>>>>>>>>>> can then >>>>>>>>>>> be used for the uptime. >>>>>>>>>> >>>>>>>>>> My attempt at this is at >>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >>>>>>>>>> I am using os::javaTimeNanos() to get the monotonic ticks where >>>>>>>>>> possible. >>>>>>>>>> >>>>>>>>>> The JDK part stays the same as for webrev.00 >>>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> -JB- >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> The patch consists of the hotspot and jdk parts. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For the hotspot a new constant needs to be introduced in >>>>>>>>>>>>>> src/share/vm/services/jmm.h and the actual logic to obtain >>>>>>>>>>>>>> the >>>>>>>>>>>>>> uptime in >>>>>>>>>>>>>> milliseconds is added in >>>>>>>>>>>>>> src/share/vm/services/management.cpp. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For the jdk the changes comprise of adding the necessary JNI >>>>>>>>>>>>>> bridging >>>>>>>>>>>>>> methods in order to get the new uptime, introducing the same >>>>>>>>>>>>>> constant >>>>>>>>>>>>>> that is used in hotspot and changes to mapfile-vers files in >>>>>>>>>>>>>> order to >>>>>>>>>>>>>> properly build the native library. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> -JB- >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> > From david.holmes at oracle.com Wed Oct 16 19:46:05 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Oct 2013 12:46:05 +1000 Subject: URG! Need a second reviewer! Re: RR(S): JDK-8025812 tmtools/jmap/heap_config tests fail on Linux-ia32 because it 'Can't attach to the core file' In-Reply-To: <525F00FF.9020505@oracle.com> References: <525931C6.8050607@oracle.com> <4D55BF19-5B5A-4DD1-BC12-E96EEC625438@oracle.com> <525F00FF.9020505@oracle.com> Message-ID: <525F4F6D.4060409@oracle.com> Hi Dmitry, In 716 static inline size_t round_page(int x){ 717 static int page_size; 718 719 page_size = sysconf(_SC_PAGE_SIZE); 720 return ROUNDUP(x,page_size); 721 } Does page_size being static mean that line 719 will only be executed once? Otherwise it serves no purpose. Typo: exisiting Otherwise seems okay. Thanks, David On 17/10/2013 7:11 AM, Dmitry Samersoff wrote: > On 2013-10-14 11:49, Staffan Larsen wrote: >> The fix looks good, but I have a problem with the ROUNDUP_PAGE macro. First, I don't like having macros defined in the middle of a method. Second, the definition of the macro includes the value of a local variable which is a bit hairy. Can't you just ROUNDUP directly in the four places it's needed? I think it would make for more readable code. >> >> nit on line 743: filed -> field >> >> Thanks, >> /Staffan >> >> On 12 okt 2013, at 13:25, Dmitry Samersoff wrote: >> >>> Hi Everybody, >>> >>> Please review the fix >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8025812/webrev.01/ >>> >>> The value of p_memsz filed of elf header of LOAD section inside coredump >>> is rounded up to page size. So round up corresponding value read from >>> the header of library it self. >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. >> > > From henry.jen at oracle.com Wed Oct 16 21:36:57 2013 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Thu, 17 Oct 2013 04:36:57 +0000 Subject: hg: jdk8/tl/jdk: 8026768: java.util.Map.Entry comparingBy methods missing @since 1.8 Message-ID: <20131017043716.577F96249C@hg.openjdk.java.net> Changeset: e2e3c2c249e2 Author: henryjen Date: 2013-10-16 21:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2e3c2c249e2 8026768: java.util.Map.Entry comparingBy methods missing @since 1.8 Reviewed-by: dholmes ! src/share/classes/java/util/Map.java From yuka.kamiya at oracle.com Wed Oct 16 21:59:32 2013 From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com) Date: Thu, 17 Oct 2013 04:59:32 +0000 Subject: hg: jdk8/tl/jdk: 8025703: Update LSR datafile for BCP 47 Message-ID: <20131017045944.38A556249E@hg.openjdk.java.net> Changeset: ce266885222d Author: peytoia Date: 2013-10-17 13:57 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce266885222d 8025703: Update LSR datafile for BCP 47 Reviewed-by: okutsu ! src/share/classes/sun/util/locale/LocaleEquivalentMaps.java + test/java/util/Locale/Bug8025703.java ! test/java/util/Locale/tools/language-subtag-registry.txt From bradford.wetmore at oracle.com Wed Oct 16 23:39:29 2013 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Thu, 17 Oct 2013 06:39:29 +0000 Subject: hg: jdk8/tl/jdk: 8026762: jdk8-tl builds windows builds failing in corba - javac: no source files Message-ID: <20131017064008.E091E624A3@hg.openjdk.java.net> Changeset: a45acc8de0f3 Author: wetmore Date: 2013-10-16 23:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a45acc8de0f3 8026762: jdk8-tl builds windows builds failing in corba - javac: no source files Reviewed-by: katleman, dholmes ! makefiles/GenerateClasses.gmk From bradford.wetmore at oracle.com Wed Oct 16 23:38:53 2013 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Thu, 17 Oct 2013 06:38:53 +0000 Subject: hg: jdk8/tl/corba: 8026762: jdk8-tl builds windows builds failing in corba - javac: no source files Message-ID: <20131017063854.64EAC624A1@hg.openjdk.java.net> Changeset: 1a71d800b032 Author: wetmore Date: 2013-10-16 23:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/1a71d800b032 8026762: jdk8-tl builds windows builds failing in corba - javac: no source files Reviewed-by: katleman, dholmes ! makefiles/BuildCorba.gmk From sundararajan.athijegannathan at oracle.com Thu Oct 17 02:21:13 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 17 Oct 2013 09:21:13 +0000 Subject: hg: jdk8/tl/nashorn: 3 new changesets Message-ID: <20131017092119.09F41624A6@hg.openjdk.java.net> Changeset: 1899da5c71d3 Author: hannesw Date: 2013-10-16 10:12 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1899da5c71d3 8026692: eval() throws NullPointerException with --compile-only Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Lower.java + test/script/basic/JDK-8026692.js Changeset: 2d5f9f77c199 Author: hannesw Date: 2013-10-16 10:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/2d5f9f77c199 8026693: getType() called on DISCARD node Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java + test/script/basic/JDK-8026693.js Changeset: adc5639fc4b9 Author: sundar Date: 2013-10-17 13:02 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/adc5639fc4b9 Merge From daniel.fuchs at oracle.com Thu Oct 17 02:53:47 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 17 Oct 2013 11:53:47 +0200 Subject: jmx-dev Codereview request: 8026028 [findbugs] findbugs report some issue in com.sun.jmx.snmp package In-Reply-To: <525E9B87.9050406@oracle.com> References: <508E8F79.60909@oracle.com> <525E9B87.9050406@oracle.com> Message-ID: <525FB3AB.3040105@oracle.com> Hi Shanliang, Looks good! -- daniel On 10/16/13 3:58 PM, shanliang wrote: > Hi, > > Please review the following fix, main issue here is that we should clone > an internal variable before returning. > > webrev: > http://cr.openjdk.java.net/~sjiang/JDK-8026028/00/ > > bug > https://bugs.openjdk.java.net/browse/JDK-8026028 > > Thanks, > Shanliang > > > > From dmitry.samersoff at oracle.com Thu Oct 17 03:10:27 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 17 Oct 2013 14:10:27 +0400 Subject: URG! Need a second reviewer! Re: RR(S): JDK-8025812 tmtools/jmap/heap_config tests fail on Linux-ia32 because it 'Can't attach to the core file' In-Reply-To: <525F4F6D.4060409@oracle.com> References: <525931C6.8050607@oracle.com> <4D55BF19-5B5A-4DD1-BC12-E96EEC625438@oracle.com> <525F00FF.9020505@oracle.com> <525F4F6D.4060409@oracle.com> Message-ID: <525FB793.8080108@oracle.com> David, OK. I'm guilty overcomplicating simple things. I step back and followed Staffan advice to just use ROUNDUP macro directly. Webrev changed in-place. http://cr.openjdk.java.net/~dsamersoff/JDK-8025812/webrev.01/ -Dmitry On 2013-10-17 06:46, David Holmes wrote: > Hi Dmitry, > > In > > 716 static inline size_t round_page(int x){ > 717 static int page_size;id, > 718 > 719 page_size = sysconf(_SC_PAGE_SIZE); > 720 return ROUNDUP(x,page_size); > 721 } > > Does page_size being static mean that line 719 will only be executed > once? Otherwise it serves no purpose. > > Typo: exisiting > > Otherwise seems okay. > > Thanks, > David > > On 17/10/2013 7:11 AM, Dmitry Samersoff wrote: >> On 2013-10-14 11:49, Staffan Larsen wrote: >>> The fix looks good, but I have a problem with the ROUNDUP_PAGE macro. >>> First, I don't like having macros defined in the middle of a method. >>> Second, the definition of the macro includes the value of a local >>> variable which is a bit hairy. Can't you just ROUNDUP directly in the >>> four places it's needed? I think it would make for more readable code. >>> >>> nit on line 743: filed -> field >>> >>> Thanks, >>> /Staffan >>> >>> On 12 okt 2013, at 13:25, Dmitry Samersoff >>> wrote: >>> >>>> Hi Everybody, >>>> >>>> Please review the fix >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8025812/webrev.01/ >>>> >>>> The value of p_memsz filed of elf header of LOAD section inside >>>> coredump >>>> is rounded up to page size. So round up corresponding value read from >>>> the header of library it self. >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. >>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Thu Oct 17 03:10:39 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 17 Oct 2013 12:10:39 +0200 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <525F4AE0.1000406@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> <52556604.3080900@oracle.com> <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> <525622B4.5020606@oracle.com> <52568940.4000704@oracle.com> <23435103-156B-434F-994C-B6F913EE0364@oracle.com> <525BFC0D.8090101@oracle.com> <525CE56D.4000708@oracle.com> <525EBBCF.3020303@oracle.com> <525F4AE0.1000406@oracle.com> Message-ID: <525FB79F.7070101@oracle.com> Hi David, On 17.10.2013 04:26, David Holmes wrote: > Hi Jaroslav, > > Minor nit: os::elapsed_time should really be defined in terms of the > other functions ie: > > return ((double) os::elapsed_counter()) / os::elapsed_frequency(); Ok. I've changed it. It better communicates the way the elapsedTime is calculated anyway. > > I also prefer the cast above as it is very clear that we will be doing a > floating-point division. > > Aside: AFAICS os::elapsed_time() is never actually used ?? Actually, it is os::elapsedTime() and this one is used quite a lot. The "elapsed_time()" form is used only in bytecodeHistogram.hpp, parNewGeneration.hpp and g1CollectedHeap.hpp, where it is also declared. > > I agree that it appears that changing the frequency should be okay. Thanks for the feedback. Updated webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 -JB- > > Thanks, > David > > On 17/10/2013 2:16 AM, Jaroslav Bachorik wrote: >> On 15.10.2013 08:49, David Holmes wrote: >>> Hi Jaroslav, >>> >>> os_bsd.cpp / os_linux.cpp: >>> >>> If you don't have a monotonic clock you leave timer_frequency set to 0! >>> (So you need to test on a system without a monotonic clock, or else >>> force it to act as-if not present.) >>> >>> That aside I don't trust clock_getres to give values that actually allow >>> the timer frequency to be determined. As per the comments in >>> os_linux.cpp: >>> >>> // It's fixed in newer kernels, however clock_getres() still returns >>> // 1/HZ. We check if clock_getres() works, but will ignore its reported >>> // resolution for now. Hopefully as people move to new kernels, this >>> // won't be a problem. >>> >>> we don't know what kernels provide real values here and which provide >>> dummy ones. >>> >>> On BSD you haven't modified os::elapsed_counter. >>> >>> Looking at the linux changes I don't think the logic is correct even if >>> clock_getres is accurate. In the existing code we have: >>> >>> elapsed_counter -> elapsed time in microseconds >>> elapsed_frequency -> 1000 * 1000 (ie micros per second) >>> elapsed_time -> elapsed_counter*0.000001 -> time in seconds >>> >>> Now we have: >>> >>> elapsed_counter -> elapsed time in nanoseconds >>> elapsed_frequency -> 1x10^9 / whatever clock_getres says >>> elapsed_time -> counter/frequency -> ??? >>> >>> So elapsed_time not, in general, going to give the elapsed time in >>> seconds. And elapsed_time is not dependent on the "frequency" at all >>> because elapsed_counter is not reporting ticks but an actual elapsed >>> "time" in nanoseconds. >>> >>> >>> Also note that we constants for: >>> >>> NANOSECS_PER_SEC >>> NANOSECS_PER_MILLISEC >>> >>> to aid with time conversions. >>> >>> The linux webrev contains unrelated UseLargePages changes! >> >> Sorry for the mess with UseLargePages changes :/ >> >> I've fixed the problems with the frequency (using a fixed number as >> before) and I kept the changes to minimum. >> >> I was hesitating about changing the elapsed_counter precision from >> microseconds to nanoseconds but since solaris and windows versions >> already use nanosecond ticks for elapsed_counter I think the change is >> safe. >> >> The update webrev: >> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 >> >>> >>> >>> David >>> ----- >>> >>> >>> On 15/10/2013 12:13 AM, Jaroslav Bachorik wrote: >>>> On 10.10.2013 13:15, Staffan Larsen wrote: >>>>> >>>>> On 10 okt 2013, at 13:02, Jaroslav Bachorik >>>>> wrote: >>>>> >>>>>> On 10.10.2013 05:44, David Holmes wrote: >>>>>>> On 10/10/2013 4:12 AM, Staffan Larsen wrote: >>>>>>>> >>>>>>>> On 9 okt 2013, at 16:19, Jaroslav Bachorik >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 9.10.2013 16:10, Staffan Larsen wrote: >>>>>>>>>> There is now an awful amount of different timestamps in the >>>>>>>>>> Management class. Can they be consolidated somehow? At least >>>>>>>>>> _begin_vm_creation_time and the new _begin_vm_creation_ns. >>>>>>>>>> >>>>>>>>>> This discussion also implies that the "elapsed time" we print in >>>>>>>>>> the >>>>>>>>>> hs_err file is also wrong. It uses os::elapsedTime() which uses >>>>>>>>>> os::elapsed_counter(). >>>>>>>>>> >>>>>>>>>> And I guess the same thing for the VM.uptime Diagnostic Command >>>>>>>>>> (class VMUptimeDCmd) which also relies on os::elapsed_counter(). >>>>>>>>> >>>>>>>>> Also the reported GC pauses duration might be wrong since it uses >>>>>>>>> Management::timestamp(). >>>>>>>>> >>>>>>>>> On the first sight the change looks rather trivial. But, honestly, >>>>>>>>> I'm not sure which other parts could for whatever reason break >>>>>>>>> once >>>>>>>>> the time-of-day timestamp is replaced with a monotonic equivalent. >>>>>>>>> One would think that it shouldn't matter but one never knows ... >>>>>>>>> >>>>>>>>> Staffan, do you think this kind of change is suitable for the >>>>>>>>> current >>>>>>>>> phase of JDK release cycle? I think I could improve the patch in >>>>>>>>> few >>>>>>>>> days and then it should probably be able to pass the review before >>>>>>>>> ZBB. But, it's only P3 ... >>>>>>>> >>>>>>>> I think it is a bit late in the release cycle to clean this up in >>>>>>>> the >>>>>>>> way it should be cleaned up. I think we should wait until the >>>>>>>> first 8 >>>>>>>> update release and do a more thorough job than we have time for >>>>>>>> right >>>>>>>> now. >>>>>>> >>>>>>> I second that. The elapsed_counter/elpased_timer APIs and >>>>>>> implementations are a tangled mess. But part of the problem has been >>>>>>> that people want/expect monotonic time-of-day based timestamps >>>>>>> (yes a >>>>>>> contradiction - though some people make sure TOD does not get >>>>>>> modified >>>>>>> on their production systems). The use of timestamps in logging has >>>>>>> to be >>>>>>> examined carefully - mainly GC logging. I recall a "simple" >>>>>>> attempted >>>>>>> change in the past that resulted in trying to compare a nanoTime >>>>>>> based >>>>>>> timestamp with the TOD. :( >>>>>> >>>>>> Actually, if I'm reading the sources right for Solaris and Win the >>>>>> monotonic clock source is used to provide elapsed_counter() value. It >>>>>> falls back to TOD when the monotonic clock source is not available. >>>>>> For Linux/BSD the TOD is used directly. >>>>>> >>>>>> This makes me wonder if changing the linux/bsd implementation to >>>>>> follow the same logic would be really that disruptive. >>>>> >>>>> Good point. I would like a world where elapsed_counter is monotonic >>>>> (where possible). Still a bit scary this late in the release, but an >>>>> interesting experiment. >>>> >>>> The change is rather simple and tests ok. All the means to get a >>>> monotonic timestamp are already there and proved to work. The core >>>> tests >>>> in JPRT went fine. >>>> >>>> The updated webrev is at >>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.02 >>>> >>>> -JB- >>>> >>>>> >>>>> /Staffan >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> -JB- >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> /Staffan >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>>>>>>>> >>>>>>>>>> /Staffan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 9 okt 2013, at 13:26, Jaroslav Bachorik >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On 8.10.2013 23:46, David Holmes wrote: >>>>>>>>>>>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>> On 8.10.2013 09:34, David Holmes wrote: >>>>>>>>>>>>>> Jaroslav, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> currently the JVM uptime reported by the RuntimeMXBean is >>>>>>>>>>>>>>> based on >>>>>>>>>>>>>>> System.currentTimeMillis() which makes it susceptible to >>>>>>>>>>>>>>> changes of the >>>>>>>>>>>>>>> OS time (eg. changing timezone, NTP synchronization etc.). >>>>>>>>>>>>>>> The >>>>>>>>>>>>>>> uptime >>>>>>>>>>>>>>> should not depend on the system time and should be >>>>>>>>>>>>>>> calculated >>>>>>>>>>>>>>> using a >>>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is already the way to get the actual JVM uptime in >>>>>>>>>>>>>>> ticks. >>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>> accessible as Management::timestamp() and the ticks are >>>>>>>>>>>>>>> convertible to >>>>>>>>>>>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus >>>>>>>>>>>>>>> making it >>>>>>>>>>>>>>> very >>>>>>>>>>>>>>> easy to switch to the monotonic clock based uptime. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Maybe I'm missing something but TiumeStamp updates using >>>>>>>>>>>>>> os::elapsed_counter() which on Linux uses gettimeofday so is >>>>>>>>>>>>>> not a >>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>> >>>>>>>>>>>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>>>>>>>>>>> >>>>>>>>>>>>> Is there any reason why a non monotonic clock source is used >>>>>>>>>>>>> for >>>>>>>>>>>>> timestamping except of the historical one? os::javaTimeNanos() >>>>>>>>>>>>> uses >>>>>>>>>>>>> montonic clock when available - why can't be the same used for >>>>>>>>>>>>> os::elapsed_counter() especially when a counter based on >>>>>>>>>>>>> "gettimeofday" >>>>>>>>>>>>> is not really a counter? >>>>>>>>>>>> >>>>>>>>>>>> It is all historical. These elapsed_counters and elapsed_timers >>>>>>>>>>>> make me >>>>>>>>>>>> cringe. But changing it has a lot of potential consequences >>>>>>>>>>>> because of >>>>>>>>>>>> the way these are used in logging etc. Certainly not something >>>>>>>>>>>> to be >>>>>>>>>>>> contemplated at this stage of JDK 8. >>>>>>>>>>>> >>>>>>>>>>>> Perhaps a simpler fix here is to expose a startUpTimeNanos that >>>>>>>>>>>> can then >>>>>>>>>>>> be used for the uptime. >>>>>>>>>>> >>>>>>>>>>> My attempt at this is at >>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >>>>>>>>>>> I am using os::javaTimeNanos() to get the monotonic ticks where >>>>>>>>>>> possible. >>>>>>>>>>> >>>>>>>>>>> The JDK part stays the same as for webrev.00 >>>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> -JB- >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> David >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> The patch consists of the hotspot and jdk parts. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For the hotspot a new constant needs to be introduced in >>>>>>>>>>>>>>> src/share/vm/services/jmm.h and the actual logic to obtain >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> uptime in >>>>>>>>>>>>>>> milliseconds is added in >>>>>>>>>>>>>>> src/share/vm/services/management.cpp. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For the jdk the changes comprise of adding the necessary JNI >>>>>>>>>>>>>>> bridging >>>>>>>>>>>>>>> methods in order to get the new uptime, introducing the same >>>>>>>>>>>>>>> constant >>>>>>>>>>>>>>> that is used in hotspot and changes to mapfile-vers files in >>>>>>>>>>>>>>> order to >>>>>>>>>>>>>>> properly build the native library. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -JB- >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >> From paul.sandoz at oracle.com Thu Oct 17 03:28:14 2013 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 17 Oct 2013 12:28:14 +0200 Subject: Codereview request: 8026028 [findbugs] findbugs report some issue in com.sun.jmx.snmp package In-Reply-To: <525E9B87.9050406@oracle.com> References: <508E8F79.60909@oracle.com> <525E9B87.9050406@oracle.com> Message-ID: On Oct 16, 2013, at 3:58 PM, shanliang wrote: > Hi, > > Please review the following fix, main issue here is that we should clone an internal variable before returning. > > webrev: > http://cr.openjdk.java.net/~sjiang/JDK-8026028/00/ > > bug > https://bugs.openjdk.java.net/browse/JDK-8026028 > +1. Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131017/291bbc5f/signature.asc From staffan.larsen at oracle.com Thu Oct 17 03:46:49 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 17 Oct 2013 12:46:49 +0200 Subject: URG! Need a second reviewer! Re: RR(S): JDK-8025812 tmtools/jmap/heap_config tests fail on Linux-ia32 because it 'Can't attach to the core file' In-Reply-To: <525FB793.8080108@oracle.com> References: <525931C6.8050607@oracle.com> <4D55BF19-5B5A-4DD1-BC12-E96EEC625438@oracle.com> <525F00FF.9020505@oracle.com> <525F4F6D.4060409@oracle.com> <525FB793.8080108@oracle.com> Message-ID: <40DF0154-7A8A-4315-B817-8B8D51CAC4A7@oracle.com> This version looks good. A minor nit is a missing space after the comma in calls to ROUNDUP. /Staffan On 17 okt 2013, at 12:10, Dmitry Samersoff wrote: > David, > > OK. I'm guilty overcomplicating simple things. I step back and > followed Staffan advice to just use ROUNDUP macro directly. > > Webrev changed in-place. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8025812/webrev.01/ > > -Dmitry > > On 2013-10-17 06:46, David Holmes wrote: >> Hi Dmitry, >> >> In >> >> 716 static inline size_t round_page(int x){ >> 717 static int page_size;id, >> 718 >> 719 page_size = sysconf(_SC_PAGE_SIZE); >> 720 return ROUNDUP(x,page_size); >> 721 } >> >> Does page_size being static mean that line 719 will only be executed >> once? Otherwise it serves no purpose. >> >> Typo: exisiting >> >> Otherwise seems okay. >> >> Thanks, >> David >> >> On 17/10/2013 7:11 AM, Dmitry Samersoff wrote: >>> On 2013-10-14 11:49, Staffan Larsen wrote: >>>> The fix looks good, but I have a problem with the ROUNDUP_PAGE macro. >>>> First, I don't like having macros defined in the middle of a method. >>>> Second, the definition of the macro includes the value of a local >>>> variable which is a bit hairy. Can't you just ROUNDUP directly in the >>>> four places it's needed? I think it would make for more readable code. >>>> >>>> nit on line 743: filed -> field >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 12 okt 2013, at 13:25, Dmitry Samersoff >>>> wrote: >>>> >>>>> Hi Everybody, >>>>> >>>>> Please review the fix >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8025812/webrev.01/ >>>>> >>>>> The value of p_memsz filed of elf header of LOAD section inside >>>>> coredump >>>>> is rounded up to page size. So round up corresponding value read from >>>>> the header of library it self. >>>>> >>>>> -- >>>>> Dmitry Samersoff >>>>> Oracle Java development team, Saint Petersburg, Russia >>>>> * I would love to change the world, but they won't give me the sources. >>>> >>> >>> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Thu Oct 17 03:54:56 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 17 Oct 2013 14:54:56 +0400 Subject: URG! Need a second reviewer! Re: RR(S): JDK-8025812 tmtools/jmap/heap_config tests fail on Linux-ia32 because it 'Can't attach to the core file' In-Reply-To: <40DF0154-7A8A-4315-B817-8B8D51CAC4A7@oracle.com> References: <525931C6.8050607@oracle.com> <4D55BF19-5B5A-4DD1-BC12-E96EEC625438@oracle.com> <525F00FF.9020505@oracle.com> <525F4F6D.4060409@oracle.com> <525FB793.8080108@oracle.com> <40DF0154-7A8A-4315-B817-8B8D51CAC4A7@oracle.com> Message-ID: <525FC200.6060900@oracle.com> Staffan, On 2013-10-17 14:46, Staffan Larsen wrote: > This version looks good. A minor nit is a missing space after the comma in calls to ROUNDUP. Thank you (nit fixed and webrev reloaded) -Dmitry > > /Staffan > > > On 17 okt 2013, at 12:10, Dmitry Samersoff wrote: > >> David, >> >> OK. I'm guilty overcomplicating simple things. I step back and >> followed Staffan advice to just use ROUNDUP macro directly. >> >> Webrev changed in-place. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8025812/webrev.01/ >> >> -Dmitry >> >> On 2013-10-17 06:46, David Holmes wrote: >>> Hi Dmitry, >>> >>> In >>> >>> 716 static inline size_t round_page(int x){ >>> 717 static int page_size;id, >>> 718 >>> 719 page_size = sysconf(_SC_PAGE_SIZE); >>> 720 return ROUNDUP(x,page_size); >>> 721 } >>> >>> Does page_size being static mean that line 719 will only be executed >>> once? Otherwise it serves no purpose. >>> >>> Typo: exisiting >>> >>> Otherwise seems okay. >>> >>> Thanks, >>> David >>> >>> On 17/10/2013 7:11 AM, Dmitry Samersoff wrote: >>>> On 2013-10-14 11:49, Staffan Larsen wrote: >>>>> The fix looks good, but I have a problem with the ROUNDUP_PAGE macro. >>>>> First, I don't like having macros defined in the middle of a method. >>>>> Second, the definition of the macro includes the value of a local >>>>> variable which is a bit hairy. Can't you just ROUNDUP directly in the >>>>> four places it's needed? I think it would make for more readable code. >>>>> >>>>> nit on line 743: filed -> field >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> On 12 okt 2013, at 13:25, Dmitry Samersoff >>>>> wrote: >>>>> >>>>>> Hi Everybody, >>>>>> >>>>>> Please review the fix >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8025812/webrev.01/ >>>>>> >>>>>> The value of p_memsz filed of elf header of LOAD section inside >>>>>> coredump >>>>>> is rounded up to page size. So round up corresponding value read from >>>>>> the header of library it self. >>>>>> >>>>>> -- >>>>>> Dmitry Samersoff >>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>> * I would love to change the world, but they won't give me the sources. >>>>> >>>> >>>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Thu Oct 17 04:01:20 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 17 Oct 2013 13:01:20 +0200 Subject: URG! Need a second reviewer! Re: RR(S): JDK-8025812 tmtools/jmap/heap_config tests fail on Linux-ia32 because it 'Can't attach to the core file' In-Reply-To: <525FC200.6060900@oracle.com> References: <525931C6.8050607@oracle.com> <4D55BF19-5B5A-4DD1-BC12-E96EEC625438@oracle.com> <525F00FF.9020505@oracle.com> <525F4F6D.4060409@oracle.com> <525FB793.8080108@oracle.com> <40DF0154-7A8A-4315-B817-8B8D51CAC4A7@oracle.com> <525FC200.6060900@oracle.com> Message-ID: Thanks - good to go! On 17 okt 2013, at 12:54, Dmitry Samersoff wrote: > Staffan, > > On 2013-10-17 14:46, Staffan Larsen wrote: >> This version looks good. A minor nit is a missing space after the comma in calls to ROUNDUP. > > Thank you (nit fixed and webrev reloaded) > > -Dmitry > >> >> /Staffan >> >> >> On 17 okt 2013, at 12:10, Dmitry Samersoff wrote: >> >>> David, >>> >>> OK. I'm guilty overcomplicating simple things. I step back and >>> followed Staffan advice to just use ROUNDUP macro directly. >>> >>> Webrev changed in-place. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8025812/webrev.01/ >>> >>> -Dmitry >>> >>> On 2013-10-17 06:46, David Holmes wrote: >>>> Hi Dmitry, >>>> >>>> In >>>> >>>> 716 static inline size_t round_page(int x){ >>>> 717 static int page_size;id, >>>> 718 >>>> 719 page_size = sysconf(_SC_PAGE_SIZE); >>>> 720 return ROUNDUP(x,page_size); >>>> 721 } >>>> >>>> Does page_size being static mean that line 719 will only be executed >>>> once? Otherwise it serves no purpose. >>>> >>>> Typo: exisiting >>>> >>>> Otherwise seems okay. >>>> >>>> Thanks, >>>> David >>>> >>>> On 17/10/2013 7:11 AM, Dmitry Samersoff wrote: >>>>> On 2013-10-14 11:49, Staffan Larsen wrote: >>>>>> The fix looks good, but I have a problem with the ROUNDUP_PAGE macro. >>>>>> First, I don't like having macros defined in the middle of a method. >>>>>> Second, the definition of the macro includes the value of a local >>>>>> variable which is a bit hairy. Can't you just ROUNDUP directly in the >>>>>> four places it's needed? I think it would make for more readable code. >>>>>> >>>>>> nit on line 743: filed -> field >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>> On 12 okt 2013, at 13:25, Dmitry Samersoff >>>>>> wrote: >>>>>> >>>>>>> Hi Everybody, >>>>>>> >>>>>>> Please review the fix >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8025812/webrev.01/ >>>>>>> >>>>>>> The value of p_memsz filed of elf header of LOAD section inside >>>>>>> coredump >>>>>>> is rounded up to page size. So round up corresponding value read from >>>>>>> the header of library it self. >>>>>>> >>>>>>> -- >>>>>>> Dmitry Samersoff >>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>> * I would love to change the world, but they won't give me the sources. >>>>>> >>>>> >>>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Thu Oct 17 04:07:36 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Oct 2013 21:07:36 +1000 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <525FB79F.7070101@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> <52556604.3080900@oracle.com> <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> <525622B4.5020606@oracle.com> <52568940.4000704@oracle.com> <23435103-156B-434F-994C-B6F913EE0364@oracle.com> <525BFC0D.8090101@oracle.com> <525CE56D.4000708@oracle.com> <525EBBCF.3020303@oracle.com> <525F4AE0.1000406@oracle.com> <525FB79F.7070101@oracle.com> Message-ID: <525FC4F8.1020004@oracle.com> On 17/10/2013 8:10 PM, Jaroslav Bachorik wrote: > Hi David, > > On 17.10.2013 04:26, David Holmes wrote: >> Hi Jaroslav, >> >> Minor nit: os::elapsed_time should really be defined in terms of the >> other functions ie: >> >> return ((double) os::elapsed_counter()) / os::elapsed_frequency(); > > Ok. I've changed it. It better communicates the way the elapsedTime is > calculated anyway. > >> >> I also prefer the cast above as it is very clear that we will be doing a >> floating-point division. >> >> Aside: AFAICS os::elapsed_time() is never actually used ?? > > Actually, it is os::elapsedTime() and this one is used quite a lot. The > "elapsed_time()" form is used only in bytecodeHistogram.hpp, > parNewGeneration.hpp and g1CollectedHeap.hpp, where it is also declared. AFAICS they all define their own elapsed_time() functions they don't use os::elapsed_time(). >> >> I agree that it appears that changing the frequency should be okay. > > Thanks for the feedback. > > Updated webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 That should be .04 version :) Looks okay. Thanks, David > -JB- > >> >> Thanks, >> David >> >> On 17/10/2013 2:16 AM, Jaroslav Bachorik wrote: >>> On 15.10.2013 08:49, David Holmes wrote: >>>> Hi Jaroslav, >>>> >>>> os_bsd.cpp / os_linux.cpp: >>>> >>>> If you don't have a monotonic clock you leave timer_frequency set to 0! >>>> (So you need to test on a system without a monotonic clock, or else >>>> force it to act as-if not present.) >>>> >>>> That aside I don't trust clock_getres to give values that actually >>>> allow >>>> the timer frequency to be determined. As per the comments in >>>> os_linux.cpp: >>>> >>>> // It's fixed in newer kernels, however clock_getres() still returns >>>> // 1/HZ. We check if clock_getres() works, but will ignore its reported >>>> // resolution for now. Hopefully as people move to new kernels, this >>>> // won't be a problem. >>>> >>>> we don't know what kernels provide real values here and which provide >>>> dummy ones. >>>> >>>> On BSD you haven't modified os::elapsed_counter. >>>> >>>> Looking at the linux changes I don't think the logic is correct even if >>>> clock_getres is accurate. In the existing code we have: >>>> >>>> elapsed_counter -> elapsed time in microseconds >>>> elapsed_frequency -> 1000 * 1000 (ie micros per second) >>>> elapsed_time -> elapsed_counter*0.000001 -> time in seconds >>>> >>>> Now we have: >>>> >>>> elapsed_counter -> elapsed time in nanoseconds >>>> elapsed_frequency -> 1x10^9 / whatever clock_getres says >>>> elapsed_time -> counter/frequency -> ??? >>>> >>>> So elapsed_time not, in general, going to give the elapsed time in >>>> seconds. And elapsed_time is not dependent on the "frequency" at all >>>> because elapsed_counter is not reporting ticks but an actual elapsed >>>> "time" in nanoseconds. >>>> >>>> >>>> Also note that we constants for: >>>> >>>> NANOSECS_PER_SEC >>>> NANOSECS_PER_MILLISEC >>>> >>>> to aid with time conversions. >>>> >>>> The linux webrev contains unrelated UseLargePages changes! >>> >>> Sorry for the mess with UseLargePages changes :/ >>> >>> I've fixed the problems with the frequency (using a fixed number as >>> before) and I kept the changes to minimum. >>> >>> I was hesitating about changing the elapsed_counter precision from >>> microseconds to nanoseconds but since solaris and windows versions >>> already use nanosecond ticks for elapsed_counter I think the change is >>> safe. >>> >>> The update webrev: >>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 >>> >>>> >>>> >>>> David >>>> ----- >>>> >>>> >>>> On 15/10/2013 12:13 AM, Jaroslav Bachorik wrote: >>>>> On 10.10.2013 13:15, Staffan Larsen wrote: >>>>>> >>>>>> On 10 okt 2013, at 13:02, Jaroslav Bachorik >>>>>> wrote: >>>>>> >>>>>>> On 10.10.2013 05:44, David Holmes wrote: >>>>>>>> On 10/10/2013 4:12 AM, Staffan Larsen wrote: >>>>>>>>> >>>>>>>>> On 9 okt 2013, at 16:19, Jaroslav Bachorik >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On 9.10.2013 16:10, Staffan Larsen wrote: >>>>>>>>>>> There is now an awful amount of different timestamps in the >>>>>>>>>>> Management class. Can they be consolidated somehow? At least >>>>>>>>>>> _begin_vm_creation_time and the new _begin_vm_creation_ns. >>>>>>>>>>> >>>>>>>>>>> This discussion also implies that the "elapsed time" we print in >>>>>>>>>>> the >>>>>>>>>>> hs_err file is also wrong. It uses os::elapsedTime() which uses >>>>>>>>>>> os::elapsed_counter(). >>>>>>>>>>> >>>>>>>>>>> And I guess the same thing for the VM.uptime Diagnostic Command >>>>>>>>>>> (class VMUptimeDCmd) which also relies on os::elapsed_counter(). >>>>>>>>>> >>>>>>>>>> Also the reported GC pauses duration might be wrong since it uses >>>>>>>>>> Management::timestamp(). >>>>>>>>>> >>>>>>>>>> On the first sight the change looks rather trivial. But, >>>>>>>>>> honestly, >>>>>>>>>> I'm not sure which other parts could for whatever reason break >>>>>>>>>> once >>>>>>>>>> the time-of-day timestamp is replaced with a monotonic >>>>>>>>>> equivalent. >>>>>>>>>> One would think that it shouldn't matter but one never knows ... >>>>>>>>>> >>>>>>>>>> Staffan, do you think this kind of change is suitable for the >>>>>>>>>> current >>>>>>>>>> phase of JDK release cycle? I think I could improve the patch in >>>>>>>>>> few >>>>>>>>>> days and then it should probably be able to pass the review >>>>>>>>>> before >>>>>>>>>> ZBB. But, it's only P3 ... >>>>>>>>> >>>>>>>>> I think it is a bit late in the release cycle to clean this up in >>>>>>>>> the >>>>>>>>> way it should be cleaned up. I think we should wait until the >>>>>>>>> first 8 >>>>>>>>> update release and do a more thorough job than we have time for >>>>>>>>> right >>>>>>>>> now. >>>>>>>> >>>>>>>> I second that. The elapsed_counter/elpased_timer APIs and >>>>>>>> implementations are a tangled mess. But part of the problem has >>>>>>>> been >>>>>>>> that people want/expect monotonic time-of-day based timestamps >>>>>>>> (yes a >>>>>>>> contradiction - though some people make sure TOD does not get >>>>>>>> modified >>>>>>>> on their production systems). The use of timestamps in logging has >>>>>>>> to be >>>>>>>> examined carefully - mainly GC logging. I recall a "simple" >>>>>>>> attempted >>>>>>>> change in the past that resulted in trying to compare a nanoTime >>>>>>>> based >>>>>>>> timestamp with the TOD. :( >>>>>>> >>>>>>> Actually, if I'm reading the sources right for Solaris and Win the >>>>>>> monotonic clock source is used to provide elapsed_counter() >>>>>>> value. It >>>>>>> falls back to TOD when the monotonic clock source is not available. >>>>>>> For Linux/BSD the TOD is used directly. >>>>>>> >>>>>>> This makes me wonder if changing the linux/bsd implementation to >>>>>>> follow the same logic would be really that disruptive. >>>>>> >>>>>> Good point. I would like a world where elapsed_counter is monotonic >>>>>> (where possible). Still a bit scary this late in the release, but an >>>>>> interesting experiment. >>>>> >>>>> The change is rather simple and tests ok. All the means to get a >>>>> monotonic timestamp are already there and proved to work. The core >>>>> tests >>>>> in JPRT went fine. >>>>> >>>>> The updated webrev is at >>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.02 >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> /Staffan >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> -JB- >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> /Staffan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 9 okt 2013, at 13:26, Jaroslav Bachorik >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 8.10.2013 23:46, David Holmes wrote: >>>>>>>>>>>>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>> On 8.10.2013 09:34, David Holmes wrote: >>>>>>>>>>>>>>> Jaroslav, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> currently the JVM uptime reported by the RuntimeMXBean is >>>>>>>>>>>>>>>> based on >>>>>>>>>>>>>>>> System.currentTimeMillis() which makes it susceptible to >>>>>>>>>>>>>>>> changes of the >>>>>>>>>>>>>>>> OS time (eg. changing timezone, NTP synchronization etc.). >>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>> uptime >>>>>>>>>>>>>>>> should not depend on the system time and should be >>>>>>>>>>>>>>>> calculated >>>>>>>>>>>>>>>> using a >>>>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There is already the way to get the actual JVM uptime in >>>>>>>>>>>>>>>> ticks. >>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>> accessible as Management::timestamp() and the ticks are >>>>>>>>>>>>>>>> convertible to >>>>>>>>>>>>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus >>>>>>>>>>>>>>>> making it >>>>>>>>>>>>>>>> very >>>>>>>>>>>>>>>> easy to switch to the monotonic clock based uptime. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Maybe I'm missing something but TiumeStamp updates using >>>>>>>>>>>>>>> os::elapsed_counter() which on Linux uses gettimeofday so is >>>>>>>>>>>>>>> not a >>>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is there any reason why a non monotonic clock source is used >>>>>>>>>>>>>> for >>>>>>>>>>>>>> timestamping except of the historical one? >>>>>>>>>>>>>> os::javaTimeNanos() >>>>>>>>>>>>>> uses >>>>>>>>>>>>>> montonic clock when available - why can't be the same used >>>>>>>>>>>>>> for >>>>>>>>>>>>>> os::elapsed_counter() especially when a counter based on >>>>>>>>>>>>>> "gettimeofday" >>>>>>>>>>>>>> is not really a counter? >>>>>>>>>>>>> >>>>>>>>>>>>> It is all historical. These elapsed_counters and >>>>>>>>>>>>> elapsed_timers >>>>>>>>>>>>> make me >>>>>>>>>>>>> cringe. But changing it has a lot of potential consequences >>>>>>>>>>>>> because of >>>>>>>>>>>>> the way these are used in logging etc. Certainly not something >>>>>>>>>>>>> to be >>>>>>>>>>>>> contemplated at this stage of JDK 8. >>>>>>>>>>>>> >>>>>>>>>>>>> Perhaps a simpler fix here is to expose a startUpTimeNanos >>>>>>>>>>>>> that >>>>>>>>>>>>> can then >>>>>>>>>>>>> be used for the uptime. >>>>>>>>>>>> >>>>>>>>>>>> My attempt at this is at >>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >>>>>>>>>>>> I am using os::javaTimeNanos() to get the monotonic ticks where >>>>>>>>>>>> possible. >>>>>>>>>>>> >>>>>>>>>>>> The JDK part stays the same as for webrev.00 >>>>>>>>>>>> >>>>>>>>>>>> -JB- >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The patch consists of the hotspot and jdk parts. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For the hotspot a new constant needs to be introduced in >>>>>>>>>>>>>>>> src/share/vm/services/jmm.h and the actual logic to obtain >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> uptime in >>>>>>>>>>>>>>>> milliseconds is added in >>>>>>>>>>>>>>>> src/share/vm/services/management.cpp. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For the jdk the changes comprise of adding the necessary >>>>>>>>>>>>>>>> JNI >>>>>>>>>>>>>>>> bridging >>>>>>>>>>>>>>>> methods in order to get the new uptime, introducing the >>>>>>>>>>>>>>>> same >>>>>>>>>>>>>>>> constant >>>>>>>>>>>>>>>> that is used in hotspot and changes to mapfile-vers >>>>>>>>>>>>>>>> files in >>>>>>>>>>>>>>>> order to >>>>>>>>>>>>>>>> properly build the native library. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>> > From david.holmes at oracle.com Thu Oct 17 04:08:33 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Oct 2013 21:08:33 +1000 Subject: URG! Need a second reviewer! Re: RR(S): JDK-8025812 tmtools/jmap/heap_config tests fail on Linux-ia32 because it 'Can't attach to the core file' In-Reply-To: References: <525931C6.8050607@oracle.com> <4D55BF19-5B5A-4DD1-BC12-E96EEC625438@oracle.com> <525F00FF.9020505@oracle.com> <525F4F6D.4060409@oracle.com> <525FB793.8080108@oracle.com> <40DF0154-7A8A-4315-B817-8B8D51CAC4A7@oracle.com> <525FC200.6060900@oracle.com> Message-ID: <525FC531.7050400@oracle.com> On 17/10/2013 9:01 PM, Staffan Larsen wrote: > Thanks - good to go! +1 Thanks, David > On 17 okt 2013, at 12:54, Dmitry Samersoff wrote: > >> Staffan, >> >> On 2013-10-17 14:46, Staffan Larsen wrote: >>> This version looks good. A minor nit is a missing space after the comma in calls to ROUNDUP. >> >> Thank you (nit fixed and webrev reloaded) >> >> -Dmitry >> >>> >>> /Staffan >>> >>> >>> On 17 okt 2013, at 12:10, Dmitry Samersoff wrote: >>> >>>> David, >>>> >>>> OK. I'm guilty overcomplicating simple things. I step back and >>>> followed Staffan advice to just use ROUNDUP macro directly. >>>> >>>> Webrev changed in-place. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8025812/webrev.01/ >>>> >>>> -Dmitry >>>> >>>> On 2013-10-17 06:46, David Holmes wrote: >>>>> Hi Dmitry, >>>>> >>>>> In >>>>> >>>>> 716 static inline size_t round_page(int x){ >>>>> 717 static int page_size;id, >>>>> 718 >>>>> 719 page_size = sysconf(_SC_PAGE_SIZE); >>>>> 720 return ROUNDUP(x,page_size); >>>>> 721 } >>>>> >>>>> Does page_size being static mean that line 719 will only be executed >>>>> once? Otherwise it serves no purpose. >>>>> >>>>> Typo: exisiting >>>>> >>>>> Otherwise seems okay. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 17/10/2013 7:11 AM, Dmitry Samersoff wrote: >>>>>> On 2013-10-14 11:49, Staffan Larsen wrote: >>>>>>> The fix looks good, but I have a problem with the ROUNDUP_PAGE macro. >>>>>>> First, I don't like having macros defined in the middle of a method. >>>>>>> Second, the definition of the macro includes the value of a local >>>>>>> variable which is a bit hairy. Can't you just ROUNDUP directly in the >>>>>>> four places it's needed? I think it would make for more readable code. >>>>>>> >>>>>>> nit on line 743: filed -> field >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>>> >>>>>>> On 12 okt 2013, at 13:25, Dmitry Samersoff >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Everybody, >>>>>>>> >>>>>>>> Please review the fix >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8025812/webrev.01/ >>>>>>>> >>>>>>>> The value of p_memsz filed of elf header of LOAD section inside >>>>>>>> coredump >>>>>>>> is rounded up to page size. So round up corresponding value read from >>>>>>>> the header of library it self. >>>>>>>> >>>>>>>> -- >>>>>>>> Dmitry Samersoff >>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>> * I would love to change the world, but they won't give me the sources. >>>>>>> >>>>>> >>>>>> >>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > From david.holmes at oracle.com Thu Oct 17 04:13:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Oct 2013 21:13:49 +1000 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <525FC4F8.1020004@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> <52556604.3080900@oracle.com> <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> <525622B4.5020606@oracle.com> <52568940.4000704@oracle.com> <23435103-156B-434F-994C-B6F913EE0364@oracle.com> <525BFC0D.8090101@oracle.com> <525CE56D.4000708@oracle.com> <525EBBCF.3020303@oracle.com> <525F4AE0.1000406@oracle.com> <525FB79F.7070101@oracle.com> <525FC4F8.1020004@oracle.com> Message-ID: <525FC66D.9040602@oracle.com> On 17/10/2013 9:07 PM, David Holmes wrote: > On 17/10/2013 8:10 PM, Jaroslav Bachorik wrote: >> Hi David, >> >> On 17.10.2013 04:26, David Holmes wrote: >>> Hi Jaroslav, >>> >>> Minor nit: os::elapsed_time should really be defined in terms of the >>> other functions ie: >>> >>> return ((double) os::elapsed_counter()) / os::elapsed_frequency(); >> >> Ok. I've changed it. It better communicates the way the elapsedTime is >> calculated anyway. >> >>> >>> I also prefer the cast above as it is very clear that we will be doing a >>> floating-point division. >>> >>> Aside: AFAICS os::elapsed_time() is never actually used ?? >> >> Actually, it is os::elapsedTime() and this one is used quite a lot. The >> "elapsed_time()" form is used only in bytecodeHistogram.hpp, >> parNewGeneration.hpp and g1CollectedHeap.hpp, where it is also declared. > > AFAICS they all define their own elapsed_time() functions they don't use > os::elapsed_time(). Ooops! I mis-grepped. It is os::elapsedTime not os::elapsed_time Nothing like inconsistent naming :( David ----- >>> >>> I agree that it appears that changing the frequency should be okay. >> >> Thanks for the feedback. >> >> Updated webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 > > That should be .04 version :) > > Looks okay. > > Thanks, > David > >> -JB- >> >>> >>> Thanks, >>> David >>> >>> On 17/10/2013 2:16 AM, Jaroslav Bachorik wrote: >>>> On 15.10.2013 08:49, David Holmes wrote: >>>>> Hi Jaroslav, >>>>> >>>>> os_bsd.cpp / os_linux.cpp: >>>>> >>>>> If you don't have a monotonic clock you leave timer_frequency set >>>>> to 0! >>>>> (So you need to test on a system without a monotonic clock, or else >>>>> force it to act as-if not present.) >>>>> >>>>> That aside I don't trust clock_getres to give values that actually >>>>> allow >>>>> the timer frequency to be determined. As per the comments in >>>>> os_linux.cpp: >>>>> >>>>> // It's fixed in newer kernels, however clock_getres() still returns >>>>> // 1/HZ. We check if clock_getres() works, but will ignore its >>>>> reported >>>>> // resolution for now. Hopefully as people move to new kernels, this >>>>> // won't be a problem. >>>>> >>>>> we don't know what kernels provide real values here and which provide >>>>> dummy ones. >>>>> >>>>> On BSD you haven't modified os::elapsed_counter. >>>>> >>>>> Looking at the linux changes I don't think the logic is correct >>>>> even if >>>>> clock_getres is accurate. In the existing code we have: >>>>> >>>>> elapsed_counter -> elapsed time in microseconds >>>>> elapsed_frequency -> 1000 * 1000 (ie micros per second) >>>>> elapsed_time -> elapsed_counter*0.000001 -> time in seconds >>>>> >>>>> Now we have: >>>>> >>>>> elapsed_counter -> elapsed time in nanoseconds >>>>> elapsed_frequency -> 1x10^9 / whatever clock_getres says >>>>> elapsed_time -> counter/frequency -> ??? >>>>> >>>>> So elapsed_time not, in general, going to give the elapsed time in >>>>> seconds. And elapsed_time is not dependent on the "frequency" at all >>>>> because elapsed_counter is not reporting ticks but an actual elapsed >>>>> "time" in nanoseconds. >>>>> >>>>> >>>>> Also note that we constants for: >>>>> >>>>> NANOSECS_PER_SEC >>>>> NANOSECS_PER_MILLISEC >>>>> >>>>> to aid with time conversions. >>>>> >>>>> The linux webrev contains unrelated UseLargePages changes! >>>> >>>> Sorry for the mess with UseLargePages changes :/ >>>> >>>> I've fixed the problems with the frequency (using a fixed number as >>>> before) and I kept the changes to minimum. >>>> >>>> I was hesitating about changing the elapsed_counter precision from >>>> microseconds to nanoseconds but since solaris and windows versions >>>> already use nanosecond ticks for elapsed_counter I think the change is >>>> safe. >>>> >>>> The update webrev: >>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 >>>> >>>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>> On 15/10/2013 12:13 AM, Jaroslav Bachorik wrote: >>>>>> On 10.10.2013 13:15, Staffan Larsen wrote: >>>>>>> >>>>>>> On 10 okt 2013, at 13:02, Jaroslav Bachorik >>>>>>> wrote: >>>>>>> >>>>>>>> On 10.10.2013 05:44, David Holmes wrote: >>>>>>>>> On 10/10/2013 4:12 AM, Staffan Larsen wrote: >>>>>>>>>> >>>>>>>>>> On 9 okt 2013, at 16:19, Jaroslav Bachorik >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On 9.10.2013 16:10, Staffan Larsen wrote: >>>>>>>>>>>> There is now an awful amount of different timestamps in the >>>>>>>>>>>> Management class. Can they be consolidated somehow? At least >>>>>>>>>>>> _begin_vm_creation_time and the new _begin_vm_creation_ns. >>>>>>>>>>>> >>>>>>>>>>>> This discussion also implies that the "elapsed time" we >>>>>>>>>>>> print in >>>>>>>>>>>> the >>>>>>>>>>>> hs_err file is also wrong. It uses os::elapsedTime() which uses >>>>>>>>>>>> os::elapsed_counter(). >>>>>>>>>>>> >>>>>>>>>>>> And I guess the same thing for the VM.uptime Diagnostic Command >>>>>>>>>>>> (class VMUptimeDCmd) which also relies on >>>>>>>>>>>> os::elapsed_counter(). >>>>>>>>>>> >>>>>>>>>>> Also the reported GC pauses duration might be wrong since it >>>>>>>>>>> uses >>>>>>>>>>> Management::timestamp(). >>>>>>>>>>> >>>>>>>>>>> On the first sight the change looks rather trivial. But, >>>>>>>>>>> honestly, >>>>>>>>>>> I'm not sure which other parts could for whatever reason break >>>>>>>>>>> once >>>>>>>>>>> the time-of-day timestamp is replaced with a monotonic >>>>>>>>>>> equivalent. >>>>>>>>>>> One would think that it shouldn't matter but one never knows ... >>>>>>>>>>> >>>>>>>>>>> Staffan, do you think this kind of change is suitable for the >>>>>>>>>>> current >>>>>>>>>>> phase of JDK release cycle? I think I could improve the patch in >>>>>>>>>>> few >>>>>>>>>>> days and then it should probably be able to pass the review >>>>>>>>>>> before >>>>>>>>>>> ZBB. But, it's only P3 ... >>>>>>>>>> >>>>>>>>>> I think it is a bit late in the release cycle to clean this up in >>>>>>>>>> the >>>>>>>>>> way it should be cleaned up. I think we should wait until the >>>>>>>>>> first 8 >>>>>>>>>> update release and do a more thorough job than we have time for >>>>>>>>>> right >>>>>>>>>> now. >>>>>>>>> >>>>>>>>> I second that. The elapsed_counter/elpased_timer APIs and >>>>>>>>> implementations are a tangled mess. But part of the problem has >>>>>>>>> been >>>>>>>>> that people want/expect monotonic time-of-day based timestamps >>>>>>>>> (yes a >>>>>>>>> contradiction - though some people make sure TOD does not get >>>>>>>>> modified >>>>>>>>> on their production systems). The use of timestamps in logging has >>>>>>>>> to be >>>>>>>>> examined carefully - mainly GC logging. I recall a "simple" >>>>>>>>> attempted >>>>>>>>> change in the past that resulted in trying to compare a nanoTime >>>>>>>>> based >>>>>>>>> timestamp with the TOD. :( >>>>>>>> >>>>>>>> Actually, if I'm reading the sources right for Solaris and Win the >>>>>>>> monotonic clock source is used to provide elapsed_counter() >>>>>>>> value. It >>>>>>>> falls back to TOD when the monotonic clock source is not available. >>>>>>>> For Linux/BSD the TOD is used directly. >>>>>>>> >>>>>>>> This makes me wonder if changing the linux/bsd implementation to >>>>>>>> follow the same logic would be really that disruptive. >>>>>>> >>>>>>> Good point. I would like a world where elapsed_counter is monotonic >>>>>>> (where possible). Still a bit scary this late in the release, but an >>>>>>> interesting experiment. >>>>>> >>>>>> The change is rather simple and tests ok. All the means to get a >>>>>> monotonic timestamp are already there and proved to work. The core >>>>>> tests >>>>>> in JPRT went fine. >>>>>> >>>>>> The updated webrev is at >>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.02 >>>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> -JB- >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> /Staffan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> /Staffan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 9 okt 2013, at 13:26, Jaroslav Bachorik >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On 8.10.2013 23:46, David Holmes wrote: >>>>>>>>>>>>>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>>> On 8.10.2013 09:34, David Holmes wrote: >>>>>>>>>>>>>>>> Jaroslav, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> currently the JVM uptime reported by the RuntimeMXBean is >>>>>>>>>>>>>>>>> based on >>>>>>>>>>>>>>>>> System.currentTimeMillis() which makes it susceptible to >>>>>>>>>>>>>>>>> changes of the >>>>>>>>>>>>>>>>> OS time (eg. changing timezone, NTP synchronization etc.). >>>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>>> uptime >>>>>>>>>>>>>>>>> should not depend on the system time and should be >>>>>>>>>>>>>>>>> calculated >>>>>>>>>>>>>>>>> using a >>>>>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There is already the way to get the actual JVM uptime in >>>>>>>>>>>>>>>>> ticks. >>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>> accessible as Management::timestamp() and the ticks are >>>>>>>>>>>>>>>>> convertible to >>>>>>>>>>>>>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus >>>>>>>>>>>>>>>>> making it >>>>>>>>>>>>>>>>> very >>>>>>>>>>>>>>>>> easy to switch to the monotonic clock based uptime. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Maybe I'm missing something but TiumeStamp updates using >>>>>>>>>>>>>>>> os::elapsed_counter() which on Linux uses gettimeofday >>>>>>>>>>>>>>>> so is >>>>>>>>>>>>>>>> not a >>>>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is there any reason why a non monotonic clock source is used >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> timestamping except of the historical one? >>>>>>>>>>>>>>> os::javaTimeNanos() >>>>>>>>>>>>>>> uses >>>>>>>>>>>>>>> montonic clock when available - why can't be the same used >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> os::elapsed_counter() especially when a counter based on >>>>>>>>>>>>>>> "gettimeofday" >>>>>>>>>>>>>>> is not really a counter? >>>>>>>>>>>>>> >>>>>>>>>>>>>> It is all historical. These elapsed_counters and >>>>>>>>>>>>>> elapsed_timers >>>>>>>>>>>>>> make me >>>>>>>>>>>>>> cringe. But changing it has a lot of potential consequences >>>>>>>>>>>>>> because of >>>>>>>>>>>>>> the way these are used in logging etc. Certainly not >>>>>>>>>>>>>> something >>>>>>>>>>>>>> to be >>>>>>>>>>>>>> contemplated at this stage of JDK 8. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Perhaps a simpler fix here is to expose a startUpTimeNanos >>>>>>>>>>>>>> that >>>>>>>>>>>>>> can then >>>>>>>>>>>>>> be used for the uptime. >>>>>>>>>>>>> >>>>>>>>>>>>> My attempt at this is at >>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >>>>>>>>>>>>> >>>>>>>>>>>>> I am using os::javaTimeNanos() to get the monotonic ticks >>>>>>>>>>>>> where >>>>>>>>>>>>> possible. >>>>>>>>>>>>> >>>>>>>>>>>>> The JDK part stays the same as for webrev.00 >>>>>>>>>>>>> >>>>>>>>>>>>> -JB- >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The patch consists of the hotspot and jdk parts. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> For the hotspot a new constant needs to be introduced in >>>>>>>>>>>>>>>>> src/share/vm/services/jmm.h and the actual logic to obtain >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> uptime in >>>>>>>>>>>>>>>>> milliseconds is added in >>>>>>>>>>>>>>>>> src/share/vm/services/management.cpp. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> For the jdk the changes comprise of adding the necessary >>>>>>>>>>>>>>>>> JNI >>>>>>>>>>>>>>>>> bridging >>>>>>>>>>>>>>>>> methods in order to get the new uptime, introducing the >>>>>>>>>>>>>>>>> same >>>>>>>>>>>>>>>>> constant >>>>>>>>>>>>>>>>> that is used in hotspot and changes to mapfile-vers >>>>>>>>>>>>>>>>> files in >>>>>>>>>>>>>>>>> order to >>>>>>>>>>>>>>>>> properly build the native library. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> From joel.franck at oracle.com Thu Oct 17 04:41:09 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Thu, 17 Oct 2013 11:41:09 +0000 Subject: hg: jdk8/tl/langtools: 8015372: Update tests for Method Parameter Reflection API to check whether a parameter is final Message-ID: <20131017114115.E9E15624AB@hg.openjdk.java.net> Changeset: a48d3b981083 Author: mnunez Date: 2013-10-17 13:27 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a48d3b981083 8015372: Update tests for Method Parameter Reflection API to check whether a parameter is final Reviewed-by: jjg, jfranck ! test/tools/javac/MethodParameters/AnnotationTest.java + test/tools/javac/MethodParameters/AnnotationTest.out ! test/tools/javac/MethodParameters/AnonymousClass.java + test/tools/javac/MethodParameters/AnonymousClass.out ! test/tools/javac/MethodParameters/ClassFileVisitor.java ! test/tools/javac/MethodParameters/Constructors.java + test/tools/javac/MethodParameters/Constructors.out ! test/tools/javac/MethodParameters/EnumTest.java + test/tools/javac/MethodParameters/EnumTest.out ! test/tools/javac/MethodParameters/InstanceMethods.java + test/tools/javac/MethodParameters/InstanceMethods.out ! test/tools/javac/MethodParameters/LambdaTest.java + test/tools/javac/MethodParameters/LambdaTest.out ! test/tools/javac/MethodParameters/LocalClassTest.java + test/tools/javac/MethodParameters/LocalClassTest.out ! test/tools/javac/MethodParameters/MemberClassTest.java + test/tools/javac/MethodParameters/MemberClassTest.out ! test/tools/javac/MethodParameters/ReflectionVisitor.java ! test/tools/javac/MethodParameters/StaticMethods.java + test/tools/javac/MethodParameters/StaticMethods.out ! test/tools/javac/MethodParameters/Tester.java ! test/tools/javac/MethodParameters/UncommonParamNames.java + test/tools/javac/MethodParameters/UncommonParamNames.out From jaroslav.bachorik at oracle.com Thu Oct 17 05:09:40 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 17 Oct 2013 14:09:40 +0200 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <525FC4F8.1020004@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> <52556604.3080900@oracle.com> <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> <525622B4.5020606@oracle.com> <52568940.4000704@oracle.com> <23435103-156B-434F-994C-B6F913EE0364@oracle.com> <525BFC0D.8090101@oracle.com> <525CE56D.4000708@oracle.com> <525EBBCF.3020303@oracle.com> <525F4AE0.1000406@oracle.com> <525FB79F.7070101@oracle.com> <525FC4F8.1020004@oracle.com> Message-ID: <525FD384.4010904@oracle.com> On 17.10.2013 13:07, David Holmes wrote: > On 17/10/2013 8:10 PM, Jaroslav Bachorik wrote: >> Hi David, >> >> On 17.10.2013 04:26, David Holmes wrote: >>> Hi Jaroslav, >>> >>> Minor nit: os::elapsed_time should really be defined in terms of the >>> other functions ie: >>> >>> return ((double) os::elapsed_counter()) / os::elapsed_frequency(); >> >> Ok. I've changed it. It better communicates the way the elapsedTime is >> calculated anyway. >> >>> >>> I also prefer the cast above as it is very clear that we will be doing a >>> floating-point division. >>> >>> Aside: AFAICS os::elapsed_time() is never actually used ?? >> >> Actually, it is os::elapsedTime() and this one is used quite a lot. The >> "elapsed_time()" form is used only in bytecodeHistogram.hpp, >> parNewGeneration.hpp and g1CollectedHeap.hpp, where it is also declared. > > AFAICS they all define their own elapsed_time() functions they don't use > os::elapsed_time(). > >>> >>> I agree that it appears that changing the frequency should be okay. >> >> Thanks for the feedback. >> >> Updated webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 > > That should be .04 version :) Yep :( copy-paste ... http://cr.openjdk.java.net/~jbachorik/6523160/webrev.04 > > Looks okay. > > Thanks, > David > >> -JB- >> >>> >>> Thanks, >>> David >>> >>> On 17/10/2013 2:16 AM, Jaroslav Bachorik wrote: >>>> On 15.10.2013 08:49, David Holmes wrote: >>>>> Hi Jaroslav, >>>>> >>>>> os_bsd.cpp / os_linux.cpp: >>>>> >>>>> If you don't have a monotonic clock you leave timer_frequency set >>>>> to 0! >>>>> (So you need to test on a system without a monotonic clock, or else >>>>> force it to act as-if not present.) >>>>> >>>>> That aside I don't trust clock_getres to give values that actually >>>>> allow >>>>> the timer frequency to be determined. As per the comments in >>>>> os_linux.cpp: >>>>> >>>>> // It's fixed in newer kernels, however clock_getres() still returns >>>>> // 1/HZ. We check if clock_getres() works, but will ignore its >>>>> reported >>>>> // resolution for now. Hopefully as people move to new kernels, this >>>>> // won't be a problem. >>>>> >>>>> we don't know what kernels provide real values here and which provide >>>>> dummy ones. >>>>> >>>>> On BSD you haven't modified os::elapsed_counter. >>>>> >>>>> Looking at the linux changes I don't think the logic is correct >>>>> even if >>>>> clock_getres is accurate. In the existing code we have: >>>>> >>>>> elapsed_counter -> elapsed time in microseconds >>>>> elapsed_frequency -> 1000 * 1000 (ie micros per second) >>>>> elapsed_time -> elapsed_counter*0.000001 -> time in seconds >>>>> >>>>> Now we have: >>>>> >>>>> elapsed_counter -> elapsed time in nanoseconds >>>>> elapsed_frequency -> 1x10^9 / whatever clock_getres says >>>>> elapsed_time -> counter/frequency -> ??? >>>>> >>>>> So elapsed_time not, in general, going to give the elapsed time in >>>>> seconds. And elapsed_time is not dependent on the "frequency" at all >>>>> because elapsed_counter is not reporting ticks but an actual elapsed >>>>> "time" in nanoseconds. >>>>> >>>>> >>>>> Also note that we constants for: >>>>> >>>>> NANOSECS_PER_SEC >>>>> NANOSECS_PER_MILLISEC >>>>> >>>>> to aid with time conversions. >>>>> >>>>> The linux webrev contains unrelated UseLargePages changes! >>>> >>>> Sorry for the mess with UseLargePages changes :/ >>>> >>>> I've fixed the problems with the frequency (using a fixed number as >>>> before) and I kept the changes to minimum. >>>> >>>> I was hesitating about changing the elapsed_counter precision from >>>> microseconds to nanoseconds but since solaris and windows versions >>>> already use nanosecond ticks for elapsed_counter I think the change is >>>> safe. >>>> >>>> The update webrev: >>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 >>>> >>>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>> On 15/10/2013 12:13 AM, Jaroslav Bachorik wrote: >>>>>> On 10.10.2013 13:15, Staffan Larsen wrote: >>>>>>> >>>>>>> On 10 okt 2013, at 13:02, Jaroslav Bachorik >>>>>>> wrote: >>>>>>> >>>>>>>> On 10.10.2013 05:44, David Holmes wrote: >>>>>>>>> On 10/10/2013 4:12 AM, Staffan Larsen wrote: >>>>>>>>>> >>>>>>>>>> On 9 okt 2013, at 16:19, Jaroslav Bachorik >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On 9.10.2013 16:10, Staffan Larsen wrote: >>>>>>>>>>>> There is now an awful amount of different timestamps in the >>>>>>>>>>>> Management class. Can they be consolidated somehow? At least >>>>>>>>>>>> _begin_vm_creation_time and the new _begin_vm_creation_ns. >>>>>>>>>>>> >>>>>>>>>>>> This discussion also implies that the "elapsed time" we >>>>>>>>>>>> print in >>>>>>>>>>>> the >>>>>>>>>>>> hs_err file is also wrong. It uses os::elapsedTime() which uses >>>>>>>>>>>> os::elapsed_counter(). >>>>>>>>>>>> >>>>>>>>>>>> And I guess the same thing for the VM.uptime Diagnostic Command >>>>>>>>>>>> (class VMUptimeDCmd) which also relies on >>>>>>>>>>>> os::elapsed_counter(). >>>>>>>>>>> >>>>>>>>>>> Also the reported GC pauses duration might be wrong since it >>>>>>>>>>> uses >>>>>>>>>>> Management::timestamp(). >>>>>>>>>>> >>>>>>>>>>> On the first sight the change looks rather trivial. But, >>>>>>>>>>> honestly, >>>>>>>>>>> I'm not sure which other parts could for whatever reason break >>>>>>>>>>> once >>>>>>>>>>> the time-of-day timestamp is replaced with a monotonic >>>>>>>>>>> equivalent. >>>>>>>>>>> One would think that it shouldn't matter but one never knows ... >>>>>>>>>>> >>>>>>>>>>> Staffan, do you think this kind of change is suitable for the >>>>>>>>>>> current >>>>>>>>>>> phase of JDK release cycle? I think I could improve the patch in >>>>>>>>>>> few >>>>>>>>>>> days and then it should probably be able to pass the review >>>>>>>>>>> before >>>>>>>>>>> ZBB. But, it's only P3 ... >>>>>>>>>> >>>>>>>>>> I think it is a bit late in the release cycle to clean this up in >>>>>>>>>> the >>>>>>>>>> way it should be cleaned up. I think we should wait until the >>>>>>>>>> first 8 >>>>>>>>>> update release and do a more thorough job than we have time for >>>>>>>>>> right >>>>>>>>>> now. >>>>>>>>> >>>>>>>>> I second that. The elapsed_counter/elpased_timer APIs and >>>>>>>>> implementations are a tangled mess. But part of the problem has >>>>>>>>> been >>>>>>>>> that people want/expect monotonic time-of-day based timestamps >>>>>>>>> (yes a >>>>>>>>> contradiction - though some people make sure TOD does not get >>>>>>>>> modified >>>>>>>>> on their production systems). The use of timestamps in logging has >>>>>>>>> to be >>>>>>>>> examined carefully - mainly GC logging. I recall a "simple" >>>>>>>>> attempted >>>>>>>>> change in the past that resulted in trying to compare a nanoTime >>>>>>>>> based >>>>>>>>> timestamp with the TOD. :( >>>>>>>> >>>>>>>> Actually, if I'm reading the sources right for Solaris and Win the >>>>>>>> monotonic clock source is used to provide elapsed_counter() >>>>>>>> value. It >>>>>>>> falls back to TOD when the monotonic clock source is not available. >>>>>>>> For Linux/BSD the TOD is used directly. >>>>>>>> >>>>>>>> This makes me wonder if changing the linux/bsd implementation to >>>>>>>> follow the same logic would be really that disruptive. >>>>>>> >>>>>>> Good point. I would like a world where elapsed_counter is monotonic >>>>>>> (where possible). Still a bit scary this late in the release, but an >>>>>>> interesting experiment. >>>>>> >>>>>> The change is rather simple and tests ok. All the means to get a >>>>>> monotonic timestamp are already there and proved to work. The core >>>>>> tests >>>>>> in JPRT went fine. >>>>>> >>>>>> The updated webrev is at >>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.02 >>>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> -JB- >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> /Staffan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> /Staffan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 9 okt 2013, at 13:26, Jaroslav Bachorik >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On 8.10.2013 23:46, David Holmes wrote: >>>>>>>>>>>>>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>>> On 8.10.2013 09:34, David Holmes wrote: >>>>>>>>>>>>>>>> Jaroslav, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> currently the JVM uptime reported by the RuntimeMXBean is >>>>>>>>>>>>>>>>> based on >>>>>>>>>>>>>>>>> System.currentTimeMillis() which makes it susceptible to >>>>>>>>>>>>>>>>> changes of the >>>>>>>>>>>>>>>>> OS time (eg. changing timezone, NTP synchronization etc.). >>>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>>> uptime >>>>>>>>>>>>>>>>> should not depend on the system time and should be >>>>>>>>>>>>>>>>> calculated >>>>>>>>>>>>>>>>> using a >>>>>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There is already the way to get the actual JVM uptime in >>>>>>>>>>>>>>>>> ticks. >>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>> accessible as Management::timestamp() and the ticks are >>>>>>>>>>>>>>>>> convertible to >>>>>>>>>>>>>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus >>>>>>>>>>>>>>>>> making it >>>>>>>>>>>>>>>>> very >>>>>>>>>>>>>>>>> easy to switch to the monotonic clock based uptime. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Maybe I'm missing something but TiumeStamp updates using >>>>>>>>>>>>>>>> os::elapsed_counter() which on Linux uses gettimeofday >>>>>>>>>>>>>>>> so is >>>>>>>>>>>>>>>> not a >>>>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is there any reason why a non monotonic clock source is used >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> timestamping except of the historical one? >>>>>>>>>>>>>>> os::javaTimeNanos() >>>>>>>>>>>>>>> uses >>>>>>>>>>>>>>> montonic clock when available - why can't be the same used >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> os::elapsed_counter() especially when a counter based on >>>>>>>>>>>>>>> "gettimeofday" >>>>>>>>>>>>>>> is not really a counter? >>>>>>>>>>>>>> >>>>>>>>>>>>>> It is all historical. These elapsed_counters and >>>>>>>>>>>>>> elapsed_timers >>>>>>>>>>>>>> make me >>>>>>>>>>>>>> cringe. But changing it has a lot of potential consequences >>>>>>>>>>>>>> because of >>>>>>>>>>>>>> the way these are used in logging etc. Certainly not >>>>>>>>>>>>>> something >>>>>>>>>>>>>> to be >>>>>>>>>>>>>> contemplated at this stage of JDK 8. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Perhaps a simpler fix here is to expose a startUpTimeNanos >>>>>>>>>>>>>> that >>>>>>>>>>>>>> can then >>>>>>>>>>>>>> be used for the uptime. >>>>>>>>>>>>> >>>>>>>>>>>>> My attempt at this is at >>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >>>>>>>>>>>>> >>>>>>>>>>>>> I am using os::javaTimeNanos() to get the monotonic ticks >>>>>>>>>>>>> where >>>>>>>>>>>>> possible. >>>>>>>>>>>>> >>>>>>>>>>>>> The JDK part stays the same as for webrev.00 >>>>>>>>>>>>> >>>>>>>>>>>>> -JB- >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The patch consists of the hotspot and jdk parts. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> For the hotspot a new constant needs to be introduced in >>>>>>>>>>>>>>>>> src/share/vm/services/jmm.h and the actual logic to obtain >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> uptime in >>>>>>>>>>>>>>>>> milliseconds is added in >>>>>>>>>>>>>>>>> src/share/vm/services/management.cpp. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> For the jdk the changes comprise of adding the necessary >>>>>>>>>>>>>>>>> JNI >>>>>>>>>>>>>>>>> bridging >>>>>>>>>>>>>>>>> methods in order to get the new uptime, introducing the >>>>>>>>>>>>>>>>> same >>>>>>>>>>>>>>>>> constant >>>>>>>>>>>>>>>>> that is used in hotspot and changes to mapfile-vers >>>>>>>>>>>>>>>>> files in >>>>>>>>>>>>>>>>> order to >>>>>>>>>>>>>>>>> properly build the native library. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> From joel.franck at oracle.com Thu Oct 17 05:25:14 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Thu, 17 Oct 2013 12:25:14 +0000 Subject: hg: jdk8/tl/langtools: 8008192: Better ordering checks needed in repeatingAnnotations/combo/ReflectionTest Message-ID: <20131017122518.F1F19624AC@hg.openjdk.java.net> Changeset: 4d8af6fda907 Author: mnunez Date: 2013-10-17 13:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4d8af6fda907 8008192: Better ordering checks needed in repeatingAnnotations/combo/ReflectionTest Reviewed-by: jjg, jfranck ! test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java ! test/tools/javac/annotations/repeatingAnnotations/combo/ReflectionTest.java From weijun.wang at oracle.com Thu Oct 17 05:57:11 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 17 Oct 2013 12:57:11 +0000 Subject: hg: jdk8/tl/jdk: 8026712: TEST_BUG: update sun/security/tools/keytool/autotest.sh with a new location to find of libsoftokn3.so Message-ID: <20131017125803.9530A624AD@hg.openjdk.java.net> Changeset: 37e3dcb798c3 Author: weijun Date: 2013-10-17 20:56 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/37e3dcb798c3 8026712: TEST_BUG: update sun/security/tools/keytool/autotest.sh with a new location to find of libsoftokn3.so Reviewed-by: vinnie ! test/sun/security/tools/keytool/autotest.sh From volker.simonis at gmail.com Thu Oct 17 06:42:34 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 17 Oct 2013 15:42:34 +0200 Subject: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to build the class library on AIX In-Reply-To: <525DC64E.3060404@oracle.com> References: <523A27A8.404@oracle.com> <523B01DF.1030902@oracle.com> <525DC64E.3060404@oracle.com> Message-ID: Hi Phil, thanks a lot for the review. Please see my comments inline: On Wed, Oct 16, 2013 at 12:48 AM, Phil Race wrote: > Hello Volker, > > I just remembered & got back to these changes - my email inbox isn't a very > good reminder system. > > I am OK with everything I see in the client areas except as below :- > > /* Very basic start for AIX - feel free to complete .. > 169 */ > > We should remove this comment. If that means first getting > any necessary completion from IBM folks, please ask them. > Given the lack of fontconfig on AIX as standard its probably > more important for AIX than any other OS so I suggest the latter. > I've just checked with a colleague and the two paths seem to be the correct (and only standard) locations for Type1 and TrueType fonts on AIX. So I'll remove the comment and change to code to: #elif defined(AIX) static char *fullAixFontPath[] = { "/usr/lpp/X11/lib/X11/fonts/Type1", /* from X11.fnt.iso_T1 */ "/usr/lpp/X11/lib/X11/fonts/TrueType", /* from X11.fnt.ucs.ttf */ NULL, /* terminates the list */ }; #endif because "/usr/lib/X11/fonts/" are actually just symlinks to the real location under "/usr/lpp". The comment also names the filesets (i.e. the default AIX packages) which contain the corresponding fonts. > >> > * insted it has to be installed from the "AIX Toolbox for Linux > Applications" > > insted -> instead > Fixed. > X11SurfaceData.c: > > #ifndef MAX > and > #ifndef MIN > > I found that re-definition warnings are seen at least on > 64 bit linux. Maybe you should rename these too generically > named macros to XSD_MAX and XSD_MIN. > That's a good idea. Done. > >> extern int dladdr(void *addr, Dl_info *info); // use the HotSpot >> implementation from libjvm.so > > Did you ever get an opinion on this from the libraries or hotspot teams ? > No, I didn't got any opinions on that topic. I'm currently preparing a new webrev for the second review round where we can then hopefully clarify that point. Thank you and best regards, Volker > -phil. > > > On 9/19/2013 7:28 AM, Volker Simonis wrote: >> >> Hi Phil, >> >> I'm open to any good ideas. >> >> The current solution is pragmatic, simple and it has no impact on >> existing platforms. >> >> The other possibility I see is to put the 'dladdr' implantation into >> its own library (something equivalent to "libjli") and link that >> library to "libawt". But I currently don't see any existing library I >> could put the implementation into. >> >> Notice that the change I propose already contains an extra >> implementation of 'dladdr' for AIX in >> "src/solaris/demo/jvmti/hprof/hprof_md.c" because "libhprof" is not >> linked against libjvm and we therefore can not use the 'extern'-trick >> there. >> >> Of course it would be nice if there would be a small library which >> contains 'dladdr' and which could be linked against both, "libawt" and >> "libhprof". But I think that would require bigger shared changes (with >> possible empty implementations on the current platforms). >> >> What do other think? >> >> Regards, >> Volker >> >> >> On Thu, Sep 19, 2013 at 3:53 PM, Phil Race wrote: >>> >>> Hi, >>> >>> w.r.t the one issue below : is the awt load library code the only place >>> you >>> need/are doing this ? If someone else (hotspot, core-libs) already >>> assented >>> to this >>> then I guess I could too but I'd like to hear for sure that hotspot and >>> core-libs >>> teams both agree to this approach and whether there is an alternative. >>> >>> -phil. >>> >>> >>> On 9/19/13 4:29 AM, Volker Simonis wrote: >>> >>> Hi Phil, >>> >>> thank you for looking at the changes. Please find my answers inline: >>> >>> >>>> /* AIX does not provide the 'dladdr' function. But fortunately, we've >>>> >>>> 42 * already implemented it in the HotSpot, because we need it there >>>> as >>>> 43 * well (see hotspot/src/os/aix/vm/porting_aix.{hpp,cpp}). >>>> >>>> Whilst this is in "ifdef AIX" this reliance on an exported hotspot >>>> function sounds hacky. What actual requirement is there that the >>>> AIX class libraries be so tightly-coupled with that VM? >>>> There is no contract there. >>>> >>> You're right, there is no contract. It's just pragmatic solution and I >>> think >>> it should always work because the libjvm will always be loaded at the >>> point >>> in AWT where it is used. Another solution would be to re-implement the >>> functionality in the class library and I don't like code duplication >>> either. >>> >>>> -phil. >>>> >>>> > From fredrik.arvidsson at oracle.com Thu Oct 17 07:02:56 2013 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Thu, 17 Oct 2013 16:02:56 +0200 Subject: RFR (S): JDK-8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes In-Reply-To: <525CF1F1.1010400@oracle.com> References: <5249643F.3030209@oracle.com> <524A7B07.1000300@oracle.com> <524BE733.2070205@oracle.com> <525CF1F1.1010400@oracle.com> Message-ID: <525FEE10.9030508@oracle.com> Hi I have added a new revision of my changes here: http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.02/ The idea is to use a lock called metaspace_lock available inside the ClassLoaderData objects that the ClassLoaderDataGraph holds, this prevents classes to be added/removed/updated during the gathering phase. When iterating using the new LoadedClassesClosure implementation only array classes and instance classes that are marked as loaded will be visited. The LoadedClassesClosure implementation uses a Stack to store classes during the gathering phase. This changes the count-allocate-add-extract approach that was used before into a add-extract way of doing it instead. I am still not sure how to do with the GetClassLoaderClasses to make it consistent. I would eventually like to get rid of the JvmtiGetLoadedClassesClosure and the use of the SystemDictionary if possible. But right now I just cant see how to get hold of the initiating loader for a class without using the SystemDictionary. /Fredrik On 2013-10-15 09:42, serguei.spitsyn at oracle.com wrote: > > There are two questions on the list that we still need to resolve in > this fix: > (1) What is the best way to protect the work with CLDG from > concurrent additions of CLD's to it > (2) The *GetClassLoaderClasses* needs a fix as well to be consistent > with the GetLoadedClasses > > I had some private conversations with Fredrik and John Rose and > after some analysis came up with the suggestion: > > (1) Continue using the *SystemDictionary_lock* to protect > consistency of the loaded classes data. > The issue is that adding CLD's to the SLDG is not currently > protected by the *SystemDictionary_lock*. > I'm suggesting to add it to the > *SystemDictionary::parse_stream* (please, see the webrev below). > > (2) There was some doubt that a similar fix for the > *GetClassLoaderClasses* is needed because > the CL+SD (taken from the host class) does not reference the > associated anonymous classes. > The question is: Can we consider the host's class CL as the > initiating CL? > My reading is that the answer to this question is: "Yes, we can". > Even though the CL itself does not have references to its > anonymous classes, > there are references from the anonymous classes's CLD's to its CL. > These references can be used in the *increment_with_loader* and > *add_with_loader* > the same way as it was before. > > This is a webrev that includes the Fredrik's fix as a base plus the > implemented suggestion: > http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/fredrik/8024423-JVMTI-ANO/ > > Some help from the HotSpot team is needed to estimate if this approach > is Ok and does not have rat holes in it. > Opinions are very welcome. > > Thanks, > Serguei > > > On 10/2/13 2:28 AM, Fredrik Arvidsson wrote: >> Hi and thanks for all your comments. >> >> I have simplified the code in *instanceKlass.cpp* like suggested and >> here is a new webrev: >> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.01/ >> >> >> Regarding the need to synchronize the access to ClassLoaderDataGraph >> I have come to the conclusion that it should be safe to call this >> without any additional synchronization since newly loaded and added >> classes are appended to the end of its 'list' of classes. This would >> mean that the call could 'miss' the classes added during the >> collection phase, but this is not a big issue. I hope that my >> conclusion is correct. >> >> I believe that the JvmtiGetLoadedClasses::getClassLoaderClasses(...) >> method is to be left alone this time since I got the impression that >> only SystemDictionary 'knows' about initiating class loaders. >> >> There is plenty of room for improvement and simplification of much of >> the code in this area, but I feel that it must wait until another >> time. The task to re-factor and simplify would quickly grow out of >> hands I'm afraid :) >> >> Cheers >> /Fredrik >> >> On 2013-10-01 09:34, serguei.spitsyn at oracle.com wrote: >>> Hi Frederik, >>> >>> >>> Thank you for jumping on this issue! >>> >>> >>> *src/share/vm/oops/instanceKlass.cpp* >>> 2333 int src_index = 0; >>> 2334 while (src_index < src_length) { >>> 2335 dest[dest_index++] = src[src_index++]; >>> 2336 } >>> 2337 >>> 2338 // If we have a hash, append it >>> 2339 if(hash_len > 0) { >>> 2340 int hash_index = 0; >>> 2341 while (hash_index < hash_len) { >>> 2342 dest[dest_index++] = hash_buf[hash_index++]; >>> 2343 } >>> 2344 } >>> >>> The above can be simplified a little bit: >>> // Add the actual class name >>> for (int src_index = 0; src_index < src_length; ) { >>> dest[dest_index++] = src[src_index++]; >>> } >>> // If we have a hash, append it >>> for (int hash_index = 0; hash_index < hash_len; ) { >>> dest[dest_index++] = hash_buf[hash_index++]; >>> } >>> >>> The conditionif(hash_len > 0) is covered by the loop itself. >>> >>> Style-related comments: >>> -wrong indent at the lines: 2316-2319 >>> - need a space after the 'if' at the lines: 2315, 2339 >>> >>> >>> *src/share/vm/prims/jvmtiGetLoadedClasses.cpp >>> >>> *The copyright comment must be up-to-date. >>> The comments at the lines 35-38, 258-260 are not valid anymore. >>> >>> >>> > In this review I still have an outstanding unanswered question about >>> > the need to synchronize the access to the: >>> >>> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >>> > and >>> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >>> >>> This kind of walking is usually done at safepoint in a VM_Operation. >>> You will find many examples in the jvmtiEnv.cpp, for instance, VM_GetAllStackTraces. >>> The suggestion from Mikael is good too. >>> >>> Should this fix include the getClassLoaderClasses() as well? >>> I'm still trying to realize the impact and consistency of this fix. :( >>> >>> What tests are you going to run for verification? >>> >>> Thanks, >>> Serguei >>> * >>> *On 9/30/13 4:45 AM, Fredrik Arvidsson wrote: >>>> Hi >>>> >>>> Please help me to review the changes below: >>>> >>>> Jira case: https://bugs.openjdk.java.net/browse/JDK-8024423 >>>> Webrev: >>>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/ >>>> >>>> >>>> In this review I still have an outstanding unanswered question >>>> about the need to synchronize the access to the: >>>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >>>> and >>>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >>>> >>>> calls in >>>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/src/share/vm/prims/jvmtiGetLoadedClasses.cpp.udiff.html >>>> >>>> Please give me advise on this. >>>> >>>> There will be a review soon regarding re-enabling the tests that failed because of the above bug, see: >>>> https://bugs.openjdk.java.net/browse/JDK-8025576 >>>> >>>> Cheers >>>> /Fredrik >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131017/0c98c5dc/attachment-0001.html From eric.mccorkle at oracle.com Thu Oct 17 06:34:44 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Thu, 17 Oct 2013 13:34:44 +0000 Subject: hg: jdk8/tl/jdk: 8022718: Runtime accessibility checking: protected class, if extended, should be accessible from another package Message-ID: <20131017133532.AC669624B1@hg.openjdk.java.net> Changeset: 0a6730b5e192 Author: drchase Date: 2013-10-16 17:55 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a6730b5e192 8022718: Runtime accessibility checking: protected class, if extended, should be accessible from another package Summary: Modify accessibility check; it was muddled about Java vs JVM protection terminology. Reviewed-by: jrose ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/reflect/Reflection.java + test/java/lang/invoke/accessProtectedSuper/BogoLoader.java + test/java/lang/invoke/accessProtectedSuper/MethodInvoker.java + test/java/lang/invoke/accessProtectedSuper/Test.java + test/java/lang/invoke/accessProtectedSuper/anotherpkg/MethodSupplierOuter.java From roger.riggs at oracle.com Thu Oct 17 07:46:09 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Thu, 17 Oct 2013 14:46:09 +0000 Subject: hg: jdk8/tl/jdk: 8026516: javadoc errors in java.time Message-ID: <20131017144656.B3B64624B4@hg.openjdk.java.net> Changeset: 36fe6a9bd43e Author: rriggs Date: 2013-10-17 10:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/36fe6a9bd43e 8026516: javadoc errors in java.time Summary: Corrected links to TemporalQuery and TemporalField.resolve Reviewed-by: mduigou, darcy, lancea ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/Era.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/IsoEra.java ! src/share/classes/java/time/chrono/MinguoChronology.java ! src/share/classes/java/time/chrono/MinguoEra.java ! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! src/share/classes/java/time/chrono/ThaiBuddhistEra.java ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/JulianFields.java ! src/share/classes/java/time/temporal/Temporal.java ! src/share/classes/java/time/temporal/WeekFields.java ! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/java/time/zone/ZoneRules.java From sean.mullan at oracle.com Thu Oct 17 08:36:38 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 17 Oct 2013 15:36:38 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20131017153852.56D75624B7@hg.openjdk.java.net> Changeset: 5d866df64ae3 Author: mullan Date: 2013-10-17 10:18 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d866df64ae3 8026346: test/java/lang/SecurityManager/CheckPackageAccess.java failing Reviewed-by: vinnie ! src/share/lib/security/java.security-macosx ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 04e8b8fc6906 Author: mullan Date: 2013-10-17 10:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/04e8b8fc6906 Merge - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m - src/share/classes/java/net/HttpURLPermission.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 Changeset: 85a73ad28c53 Author: mullan Date: 2013-10-17 11:34 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85a73ad28c53 Merge From dmitry.samersoff at oracle.com Thu Oct 17 09:12:27 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Thu, 17 Oct 2013 16:12:27 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8025812: tmtools/jmap/heap_config tests fail on Linux-ia32 because it Cant attach to the core file Message-ID: <20131017161233.79070624B9@hg.openjdk.java.net> Changeset: 1bee3014cf2a Author: dsamersoff Date: 2013-10-17 16:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1bee3014cf2a 8025812: tmtools/jmap/heap_config tests fail on Linux-ia32 because it Cant attach to the core file Summary: Coredump store memsz elf field rounded up to page Reviewed-by: dholmes, sla ! agent/src/os/linux/ps_core.c From roger.riggs at oracle.com Thu Oct 17 10:50:14 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Thu, 17 Oct 2013 17:50:14 +0000 Subject: hg: jdk8/tl/jdk: 8026183: minor documentation problems in java.lang.invoke; ... Message-ID: <20131017175026.571B6624C9@hg.openjdk.java.net> Changeset: 456a9b199208 Author: rriggs Date: 2013-10-17 13:43 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/456a9b199208 8026183: minor documentation problems in java.lang.invoke 8015808: Typo in MethodHandle javadoc Summary: Fix typos and javadoc markup and extraneous paragraph tags Reviewed-by: lancea ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/ConstantCallSite.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java From huizhe.wang at oracle.com Thu Oct 17 11:24:19 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Thu, 17 Oct 2013 18:24:19 +0000 Subject: hg: jdk8/tl/jaxp: 8015243: SchemaFactory does not catch enum. value that is not in the value space of the base type, anyURI Message-ID: <20131017182425.949BC624CB@hg.openjdk.java.net> Changeset: 0c3f951630fe Author: joehw Date: 2013-10-17 11:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/0c3f951630fe 8015243: SchemaFactory does not catch enum. value that is not in the value space of the base type, anyURI Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/util/URI.java From staffan.larsen at oracle.com Thu Oct 17 11:30:39 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 17 Oct 2013 20:30:39 +0200 Subject: RFR: 8026789 Update test/java/lang/instrument/Re(transform|define)BigClass.sh test to use NMT for memory leak detection Message-ID: <71403A99-3B7E-4323-9F83-23DB537DF5AC@oracle.com> The two tests currently use /proc/self/stat to read the virtual memory usage for the process. This only works on linux and only gives a single value to analyze. NMT works on all platforms and gives a lot more detail about where the memory is consumed. Without this fix, I can repro JDK-8023201 when stressing the machine heavily, but with this fix the test passes. The reason for this is probably that NMT uses a more granular measurement of committed memory, and not that the VM actually uses less memory. I have retained the memory growth limit of 32MB, but if that is a good value or not, I don't know. When stressing the test, I see NMT reporting about 1MB in committed memory growth. I have also removed the tests from ProblemList.txt. webrev: http://cr.openjdk.java.net/~sla/8026789/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8026789 Thanks, /Staffan From huizhe.wang at oracle.com Thu Oct 17 11:56:34 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Thu, 17 Oct 2013 18:56:34 +0000 Subject: hg: jdk8/tl/jdk: 8015243: SchemaFactory does not catch enum. value that is not in the value space of the base type, anyURI Message-ID: <20131017185713.BB0FF624CC@hg.openjdk.java.net> Changeset: bc04f561bb78 Author: joehw Date: 2013-10-17 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bc04f561bb78 8015243: SchemaFactory does not catch enum. value that is not in the value space of the base type, anyURI Reviewed-by: lancea + test/javax/xml/jaxp/validation/8015243/AnyURITest.java + test/javax/xml/jaxp/validation/8015243/anyURI_b006.xsd From jason.uh at oracle.com Thu Oct 17 12:01:16 2013 From: jason.uh at oracle.com (jason.uh at oracle.com) Date: Thu, 17 Oct 2013 19:01:16 +0000 Subject: hg: jdk8/tl/jdk: 8026233: test/sun/security/tools/keytool/StorePasswords.java needs to clean up files Message-ID: <20131017190128.182E5624CE@hg.openjdk.java.net> Changeset: fa38f8e0accd Author: juh Date: 2013-10-17 12:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fa38f8e0accd 8026233: test/sun/security/tools/keytool/StorePasswords.java needs to clean up files Reviewed-by: vinnie ! test/sun/security/tools/keytool/StorePasswords.java From staffan.larsen at oracle.com Thu Oct 17 12:00:43 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 17 Oct 2013 19:00:43 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20131017190055.A6EB4624CD@hg.openjdk.java.net> Changeset: ffb471203842 Author: erikj Date: 2013-10-17 16:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ffb471203842 8026792: HOTSPOT: licensee reports a JDK8 build failure after 8005849/8005008 fixes integrated. Reviewed-by: dholmes, sla ! make/windows/makefiles/trace.make Changeset: ad8e901ca2e1 Author: sla Date: 2013-10-17 12:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ad8e901ca2e1 Merge From lance.andersen at oracle.com Thu Oct 17 12:16:48 2013 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Thu, 17 Oct 2013 19:16:48 +0000 Subject: hg: jdk8/tl/jdk: 8026812: doclint clean up for java.sql and javax.sql Message-ID: <20131017191711.EAAEA624CF@hg.openjdk.java.net> Changeset: 64c0ac7cd936 Author: lancea Date: 2013-10-17 15:14 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64c0ac7cd936 8026812: doclint clean up for java.sql and javax.sql Reviewed-by: mduigou ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/Connection.java ! src/share/classes/java/sql/DatabaseMetaData.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/SQLException.java ! src/share/classes/java/sql/SQLFeatureNotSupportedException.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/sql/SQLWarning.java ! src/share/classes/java/sql/SQLXML.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/javax/sql/CommonDataSource.java ! src/share/classes/javax/sql/RowSet.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/CachedRowSet.java ! src/share/classes/javax/sql/rowset/FilteredRowSet.java ! src/share/classes/javax/sql/rowset/JdbcRowSet.java ! src/share/classes/javax/sql/rowset/JoinRowSet.java ! src/share/classes/javax/sql/rowset/Joinable.java ! src/share/classes/javax/sql/rowset/Predicate.java ! src/share/classes/javax/sql/rowset/WebRowSet.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/share/classes/javax/sql/rowset/spi/SyncProvider.java ! src/share/classes/javax/sql/rowset/spi/SyncResolver.java From gnu.andrew at redhat.com Thu Oct 17 12:25:30 2013 From: gnu.andrew at redhat.com (Andrew) Date: Thu, 17 Oct 2013 15:25:30 -0400 (EDT) Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <5251C216.105@oracle.com> References: <5251C216.105@oracle.com> Message-ID: <1898888421.8989993.1382037930696.JavaMail.root@redhat.com> ----- Original Message ----- > > As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported, > I'd like to have another attempt at adding the annotation to a number of > JDK specific APIs that are long standing exported, documented and > supported APIs. Specifically, the following APIs: > > - Java Debug Interface (com.sun.jdi) > - Attach API (com.sun.tools.attach) > - SCTP API (com.sun.nio.sctp) > - HTTP server API (com.sun.net.httpserver) > - Management extensions (com.sun.management) > - JConsole Plugin API (com.sun.tools.jconsole) > - JDK-specific API to JAAS (com.sun.security.auth) > - JDK-specific JGSS API (com.sun.security.jgss) > > (The javadoc for each of these APIs is currently generated in the build) > > The webrev with the proposed update is here: > http://cr.openjdk.java.net/~alanb/8008662/webrev.02/ > > As per the original webrev, I've added package-info.java to a number of > packages that didn't have any description. In a few cases, I've had to > rename the legacy package.html to package-info.java. > > For the review then the intention is that @jdk.Exported be added to the > package-info and all public/protected types in these APIs. The only > exceptions are two cases where I've added @jdk.Exported(false), > specifically: > > - com.sun.management.OSMBeanFactory as it clearly documents to stay away > - com.sun.security.auth.callback.DialogCallbackHandler as it for the > chop (see JEP 162) > > Thanks, > > Alan. > I just came across this trying to understand what the new annotation means. Is the intention for these 'exported' APIs to be eventually replaced by proper parts of the specification (i.e. java.* or javax.*). I'm not keen on the idea of encouraging the use of APIs that are only in this implementation of the JDK. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From mandy.chung at oracle.com Thu Oct 17 13:24:00 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 17 Oct 2013 20:24:00 +0000 Subject: hg: jdk8/tl/langtools: 8015912: jdeps support to output in dot file format; ... Message-ID: <20131017202405.ABBB9624D4@hg.openjdk.java.net> Changeset: defadd528513 Author: mchung Date: 2013-10-17 13:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/defadd528513 8015912: jdeps support to output in dot file format 8026255: Switch jdeps to follow traditional Java option style Reviewed-by: alanb ! src/share/classes/com/sun/tools/jdeps/Analyzer.java ! src/share/classes/com/sun/tools/jdeps/Archive.java ! src/share/classes/com/sun/tools/jdeps/ClassFileReader.java ! src/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/share/classes/com/sun/tools/jdeps/PlatformClassPath.java + src/share/classes/com/sun/tools/jdeps/Profile.java - src/share/classes/com/sun/tools/jdeps/Profiles.java ! src/share/classes/com/sun/tools/jdeps/resources/jdeps.properties + test/tools/jdeps/APIDeps.java ! test/tools/jdeps/Basic.java ! test/tools/jdeps/Test.java + test/tools/jdeps/b/B.java + test/tools/jdeps/c/C.java + test/tools/jdeps/c/I.java + test/tools/jdeps/d/D.java + test/tools/jdeps/e/E.java + test/tools/jdeps/f/F.java + test/tools/jdeps/g/G.java + test/tools/jdeps/m/Bar.java + test/tools/jdeps/m/Foo.java + test/tools/jdeps/m/Gee.java From mandy.chung at oracle.com Thu Oct 17 13:25:21 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 17 Oct 2013 20:25:21 +0000 Subject: hg: jdk8/tl/jdk: 8015912: jdeps support to output in dot file format; ... Message-ID: <20131017202546.776B1624D5@hg.openjdk.java.net> Changeset: 3735d81552a7 Author: mchung Date: 2013-10-17 13:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3735d81552a7 8015912: jdeps support to output in dot file format 8026255: Switch jdeps to follow traditional Java option style Reviewed-by: alanb ! test/sun/reflect/CallerSensitive/CallerSensitiveFinder.java From mike.duigou at oracle.com Thu Oct 17 13:54:19 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 17 Oct 2013 20:54:19 +0000 Subject: hg: jdk8/tl/jdk: 8004138: ForkJoinTask leaks exceptions Message-ID: <20131017205508.2266B624D9@hg.openjdk.java.net> Changeset: c1af85c48819 Author: mduigou Date: 2013-10-17 12:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1af85c48819 8004138: ForkJoinTask leaks exceptions Reviewed-by: chegar, mduigou, psandoz, martin Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/ForkJoinTask.java + test/java/util/concurrent/forkjoin/FJExceptionTableLeak.java From mandy.chung at oracle.com Thu Oct 17 14:04:50 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 Oct 2013 14:04:50 -0700 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <1898888421.8989993.1382037930696.JavaMail.root@redhat.com> References: <5251C216.105@oracle.com> <1898888421.8989993.1382037930696.JavaMail.root@redhat.com> Message-ID: <526050F2.1050204@oracle.com> On 10/17/13 12:25 PM, Andrew wrote: > > I just came across this trying to understand what the new annotation means. > > Is the intention for these 'exported' APIs to be eventually replaced by proper > parts of the specification (i.e. java.* or javax.*). I'm not keen on the idea > of encouraging the use of APIs that are only in this implementation of the JDK. @Exported APIs are supported for use outside JDK implementation. You can refer to JEP 179 [1] for details. Most of the APIs annotated with @Exported are not new and have been supported by Oracle JDK(links to jdk7 docs) http://docs.oracle.com/javase/7/docs/technotes/guides/management/ http://docs.oracle.com/javase/7/docs/technotes/guides/security/index.html The JDK internal APIs remain to be unsupported. Mandy [1] http://openjdk.java.net/jeps/179 From mike.duigou at oracle.com Thu Oct 17 14:09:29 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 17 Oct 2013 21:09:29 +0000 Subject: hg: jdk8/tl: 8026062: webrev.ksh: fix bug title web scraping, remove teamware, sac, "open bug", -l and wxfile support Message-ID: <20131017210929.D5FED624DA@hg.openjdk.java.net> Changeset: 9ec6626d43bb Author: mduigou Date: 2013-10-17 14:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/9ec6626d43bb 8026062: webrev.ksh: fix bug title web scraping, remove teamware, sac, "open bug", -l and wxfile support Reviewed-by: weijun, dsamersoff, darcy, jrose, tbell ! make/scripts/webrev.ksh From erik.helin at oracle.com Thu Oct 17 14:28:52 2013 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 17 Oct 2013 23:28:52 +0200 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <525ED138.1000305@oracle.com> References: <20131016160914.GA10865@ehelin-thinkpad> <525ED138.1000305@oracle.com> Message-ID: <20131017212852.GA6066@ehelin-thinkpad> Hi Mikael and Coleen, thanks for your reviews! On 2013-10-16, Mikael Gerdin wrote: > jvmtiImpl.hpp: > Since clone() uses unhandled oops, and is only supposed to be used > by the VM operation, would it make sense to > assert(SafepointSynchronize::is_at_safepoint())? > > 196 GrowableElement *clone() { > 197 return new JvmtiBreakpoint(_method, _bci, _class_loader_handle); Agree, I've updated the patch. A new webrev is located at: http://cr.openjdk.java.net/~ehelin/8025834/webrev.01/ On 2013-10-16, Mikael Gerdin wrote: > jvmtiEnv.cpp: > Have you verified that the generated JVMTI entry point contains a > ResourceMark or is it just not needed? > - ResourceMark rm; > + HandleMark hm; The JVMTI entry point does not contain a ResourceMark. However, I have verified that a ResourceMark is not needed for jvmtiEnv::SetBreakpoint nor for jvmtiEnv::ClearBreapoint. The only codes that needs a ResourceMark is JvmtiBreakpoints::prints, but that method already has a ResourceMark. On 2013-10-16, Coleen Phillimore wrote: > Did you run the nsk.jvmti.testlist tests too though? No, I had not run the nsk.jvmti.testlist test, but I have now :) I run both with and without the patch on the latest hsx/hotspot-gc. I also run with and without -XX:+CheckUnhandledOops. The results were all the same: 598 passed an 11 failed (the same tests for all combinations). So, the patch does not introduce any regressions for this test suite. Thanks, Erik On 2013-10-16, Mikael Gerdin wrote: > Erik, > > (it's not necessary to cross-post between hotspot-dev and > hotspot-gc-dev, so I removed hotspot-gc from the CC list) > > On 2013-10-16 18:09, Erik Helin wrote: > >Hi all, > > > >this patch fixes an issue where an oop in JvmtiBreakpoint, > >JvmtiBreakpoint::_class_loader, was found by the unhandled oop detector. > > > >Instead of registering the oop as an unhandled oop, which would have > >worked, I decided to wrap the oop in a handle as long as it is on the > >stack. > > > >A JvmtiBreakpoint is created on the stack by the two methods > >JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This > >JvmtiBreakpoint is only created to carry the Method*, jlocation and oop > >to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, when > >at a safepoint, allocate a new JvmtiBreakpoint on the native heap, copy > >the values from the stack allocated JvmtiBreakpoint and then place/clear the > >newly alloacted JvmtiBreakpoint in > >JvmtiCurrentBreakpoints::_jvmti_breakpoints. > > > >I have updated to the code to check that the public constructor is only > >used to allocate JvmtiBreakpoints on the stack (to warn a future > >programmer if he/she decides to allocate one on the heap). The > >class_loader oop is now wrapped in a Handle for stack allocated > >JvmtiBreakpoints. > > > >Due to the stack allocated JvmtiBreakpoint having the oop in a handle, > >the oops_do method of VM_ChangeBreakpoints can be removed. This also > >makes the oop in the handle safe for use after the VM_ChangeBreakpoint > >operation is finished. > > > >The unhandled oop in the JvmtiBreakpoint allocated on the heap will be > >visited by the GC via jvmtiExport::oops_do -> > >JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> > >GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being > >added to. > > > >I've also removed some dead code to simplify the change: > >- GrowableCache::insert > >- JvmtiBreakpoint::copy > >- JvmtiBreakpoint::lessThan > >- GrowableElement::lessThan > > > >Finally, I also formatted JvmtiEnv::ClearBreakpoint and > >Jvmti::SetBreakpoint exactly the same to highlight that they share all > >code except one line. Unfortunately, I was not able to remove this code > >duplication in a good way. > > > >Webrev: > >http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ > > jvmtiImpl.hpp: > Since clone() uses unhandled oops, and is only supposed to be used > by the VM operation, would it make sense to > assert(SafepointSynchronize::is_at_safepoint())? > > 196 GrowableElement *clone() { > 197 return new JvmtiBreakpoint(_method, _bci, _class_loader_handle); > > jvmtiImpl.cpp: > No comments. > > jvmtiEnv.cpp: > Have you verified that the generated JVMTI entry point contains a > ResourceMark or is it just not needed? > - ResourceMark rm; > + HandleMark hm; > > Otherwise the code change looks good. > > > One thing that you didn't describe here, but which was related to > the bug (which we discussed) was the fact that the old code tried to > "do the right thing" WRT CheckUnhandledOops, but it incorrectly > added a Method*: > > thread->allow_unhandled_oop((oop*)&_method); > > We should take care to find other such places where we try to put a > non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in > the unhandled oops code. > > /Mikael > > > > >Testing: > >- JPRT > >- The four tests that were failing are now passing > > > >Thanks, > >Erik > > > From brian.burkhalter at oracle.com Thu Oct 17 15:06:40 2013 From: brian.burkhalter at oracle.com (brian.burkhalter at oracle.com) Date: Thu, 17 Oct 2013 22:06:40 +0000 Subject: hg: jdk8/tl/jdk: 8026832: Clean up straggling doclint warnings in java.math Message-ID: <20131017220653.11AC7624DB@hg.openjdk.java.net> Changeset: e76bb2436b04 Author: bpb Date: 2013-10-17 15:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e76bb2436b04 8026832: Clean up straggling doclint warnings in java.math Summary: Fix empty paragraph tag warnings. Reviewed-by: lancea ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/RoundingMode.java From huizhe.wang at oracle.com Thu Oct 17 16:36:09 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Thu, 17 Oct 2013 23:36:09 +0000 Subject: hg: jdk8/tl/jaxp: 8016500: Unlocalized warnigs. Message-ID: <20131017233615.5F800624DF@hg.openjdk.java.net> Changeset: 951c1f7fdb10 Author: joehw Date: 2013-10-17 16:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/951c1f7fdb10 8016500: Unlocalized warnigs. Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/jaxp/DefaultValidationErrorHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java From lana.steuck at oracle.com Thu Oct 17 17:50:44 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Oct 2013 00:50:44 +0000 Subject: hg: jdk8/tl/jaxp: 5 new changesets Message-ID: <20131018005108.4E110624ED@hg.openjdk.java.net> Changeset: acae2e8a46df Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/acae2e8a46df 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! makefiles/BuildJaxp.gmk ! makefiles/Makefile Changeset: c1f9158fbb9c Author: katleman Date: 2013-10-16 11:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/c1f9158fbb9c Merge Changeset: e85dd07c0eea Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/e85dd07c0eea Added tag jdk8-b112 for changeset c1f9158fbb9c ! .hgtags Changeset: 31c82bc71ae3 Author: lana Date: 2013-10-17 15:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/31c82bc71ae3 Merge Changeset: 2f1e1e2c2242 Author: lana Date: 2013-10-17 17:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2f1e1e2c2242 Merge From lana.steuck at oracle.com Thu Oct 17 17:50:44 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Oct 2013 00:50:44 +0000 Subject: hg: jdk8/tl: 25 new changesets Message-ID: <20131018005048.530AB624EA@hg.openjdk.java.net> Changeset: 7dea0ce25bdc Author: pbhat Date: 2013-05-30 16:00 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7dea0ce25bdc Merge ! common/autoconf/generated-configure.sh Changeset: d081bdbf904d Author: jqzuo Date: 2013-06-10 16:15 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d081bdbf904d Merge ! common/autoconf/generated-configure.sh Changeset: b59990653fb9 Author: pbhat Date: 2013-06-21 18:56 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b59990653fb9 Merge ! common/autoconf/generated-configure.sh Changeset: dd345e4b51fb Author: pbhat Date: 2013-07-05 11:00 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/dd345e4b51fb Merge ! common/autoconf/generated-configure.sh Changeset: 24cc2d9b0af5 Author: pbhat Date: 2013-07-18 16:49 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/24cc2d9b0af5 Merge ! common/autoconf/generated-configure.sh Changeset: 4a4c9e7bc6c9 Author: pbhat Date: 2013-07-25 17:26 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4a4c9e7bc6c9 Merge Changeset: 63d794ade242 Author: pbhat Date: 2013-08-02 09:41 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/63d794ade242 Merge Changeset: a5485b9a2d14 Author: pbhat Date: 2013-08-09 14:54 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/a5485b9a2d14 Merge Changeset: 028ac95111b9 Author: pbhat Date: 2013-08-16 14:33 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/028ac95111b9 Merge Changeset: 4b686cbc32c7 Author: pbhat Date: 2013-08-23 09:45 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4b686cbc32c7 Merge ! common/autoconf/generated-configure.sh Changeset: ec583e324aaf Author: pbhat Date: 2013-08-30 10:14 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ec583e324aaf Merge ! common/autoconf/generated-configure.sh Changeset: 96f00091b570 Author: pbhat Date: 2013-09-05 11:23 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/96f00091b570 Merge ! common/autoconf/generated-configure.sh Changeset: 69096d4b1da2 Author: pbhat Date: 2013-09-12 12:08 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/69096d4b1da2 Merge ! common/autoconf/generated-configure.sh Changeset: 5a306baf3bb7 Author: pbhat Date: 2013-09-19 14:01 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/5a306baf3bb7 Merge ! common/autoconf/generated-configure.sh Changeset: 88ca3ff9ce2d Author: billyh Date: 2013-09-25 10:50 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/88ca3ff9ce2d 8025262: new64jre/new64jdk wrappers should be removed, build 32-bit AU during windows-amd64 builds instead Reviewed-by: amenkov, jqzuo ! make/install-rules.gmk Changeset: c8066e5d7a7b Author: pbhat Date: 2013-09-26 11:20 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c8066e5d7a7b Merge Changeset: 00ae95ca1755 Author: pbhat Date: 2013-10-03 09:52 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/00ae95ca1755 Merge Changeset: 7deff16cf438 Author: jqzuo Date: 2013-10-14 18:53 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7deff16cf438 Merge ! common/autoconf/generated-configure.sh Changeset: ec48d637778a Author: tbell Date: 2013-10-09 18:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ec48d637778a 8023611: Win32 and win64: Remove all the WARNINGS in JDK 8 builds for Windows 2008 and MSVS 2010 SP1 Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: 174a54ce39c4 Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/174a54ce39c4 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! NewMakefile.gmk ! common/autoconf/autogen.sh ! common/autoconf/basics.m4 ! common/autoconf/basics_windows.m4 ! common/autoconf/boot-jdk.m4 ! common/autoconf/bootcycle-spec.gmk.in ! common/autoconf/build-aux/config.guess ! common/autoconf/build-performance.m4 ! common/autoconf/builddeps.conf.example ! common/autoconf/builddeps.conf.nfs.example ! common/autoconf/builddeps.m4 ! common/autoconf/compare.sh.in ! common/autoconf/config.h.in ! common/autoconf/configure ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/autoconf/libraries.m4 ! common/autoconf/platform.m4 ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/autoconf/toolchain_windows.m4 ! common/makefiles/HotspotWrapper.gmk ! common/makefiles/IdlCompilation.gmk ! common/makefiles/JavaCompilation.gmk ! common/makefiles/Jprt.gmk ! common/makefiles/Main.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/MakeHelpers.gmk ! common/makefiles/NativeCompilation.gmk ! common/makefiles/RMICompilation.gmk ! common/makefiles/devkit/Makefile ! common/makefiles/devkit/Tools.gmk ! common/makefiles/javadoc/CORE_PKGS.gmk ! common/makefiles/javadoc/Javadoc.gmk ! common/makefiles/javadoc/NON_CORE_PKGS.gmk ! common/makefiles/javadoc/Notes.html Changeset: 6274d4cd22d3 Author: erikj Date: 2013-10-14 11:54 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6274d4cd22d3 8025921: Make LOG=debug output more readable Reviewed-by: tbell, ihse ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeBase.gmk Changeset: 547316ea137d Author: katleman Date: 2013-10-16 11:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/547316ea137d Merge ! common/autoconf/generated-configure.sh ! common/makefiles/javadoc/CORE_PKGS.gmk ! common/makefiles/javadoc/Javadoc.gmk Changeset: ac748011cbbf Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ac748011cbbf Added tag jdk8-b112 for changeset 547316ea137d ! .hgtags Changeset: 77473affb9c0 Author: lana Date: 2013-10-17 13:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/77473affb9c0 Merge ! common/makefiles/JavaCompilation.gmk ! common/makefiles/RMICompilation.gmk Changeset: 35c14ec3e12f Author: lana Date: 2013-10-17 15:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/35c14ec3e12f Merge From lana.steuck at oracle.com Thu Oct 17 17:50:23 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Oct 2013 00:50:23 +0000 Subject: hg: jdk8/tl/corba: 4 new changesets Message-ID: <20131018005033.E0ED4624E9@hg.openjdk.java.net> Changeset: 66fc1a749867 Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/66fc1a749867 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! makefiles/BuildCorba.gmk ! makefiles/Makefile Changeset: 43cec76d1d62 Author: katleman Date: 2013-10-16 11:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/43cec76d1d62 Merge Changeset: 54aa9b7d743d Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/54aa9b7d743d Added tag jdk8-b112 for changeset 43cec76d1d62 ! .hgtags Changeset: 1c01208087b5 Author: lana Date: 2013-10-17 14:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/1c01208087b5 Merge ! makefiles/BuildCorba.gmk From lana.steuck at oracle.com Thu Oct 17 17:50:53 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Oct 2013 00:50:53 +0000 Subject: hg: jdk8/tl/nashorn: 4 new changesets Message-ID: <20131018005104.D2C70624EB@hg.openjdk.java.net> Changeset: 45399f3ef717 Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/45399f3ef717 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! makefiles/BuildNashorn.gmk ! makefiles/Makefile Changeset: 6a4fdb3bb4e3 Author: katleman Date: 2013-10-16 12:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/6a4fdb3bb4e3 Merge Changeset: 103590fc1e0a Author: cl Date: 2013-10-17 09:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/103590fc1e0a Added tag jdk8-b112 for changeset 6a4fdb3bb4e3 ! .hgtags Changeset: 676cd7bf5e09 Author: lana Date: 2013-10-17 16:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/676cd7bf5e09 Merge From lana.steuck at oracle.com Thu Oct 17 17:50:44 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Oct 2013 00:50:44 +0000 Subject: hg: jdk8/tl/jaxws: 4 new changesets Message-ID: <20131018005105.164FF624EC@hg.openjdk.java.net> Changeset: 602fdd7bb765 Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/602fdd7bb765 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! makefiles/BuildJaxws.gmk ! makefiles/Makefile Changeset: dbdd5c762509 Author: katleman Date: 2013-10-16 11:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/dbdd5c762509 Merge Changeset: 9ca9735d9966 Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/9ca9735d9966 Added tag jdk8-b112 for changeset dbdd5c762509 ! .hgtags Changeset: be7d1f874b96 Author: lana Date: 2013-10-17 16:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/be7d1f874b96 Merge From lana.steuck at oracle.com Thu Oct 17 17:50:53 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Oct 2013 00:50:53 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20131018005124.34CF9624EE@hg.openjdk.java.net> Changeset: 343aeb2033f0 Author: ihse Date: 2013-10-10 14:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/343aeb2033f0 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! makefiles/BuildLangtools.gmk ! makefiles/Makefile Changeset: 954dd199d6ff Author: katleman Date: 2013-10-16 12:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/954dd199d6ff Merge Changeset: 8f54b4231c28 Author: cl Date: 2013-10-17 09:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8f54b4231c28 Added tag jdk8-b112 for changeset 954dd199d6ff ! .hgtags Changeset: bca97b47f0a2 Author: lana Date: 2013-10-17 16:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bca97b47f0a2 Merge From lana.steuck at oracle.com Thu Oct 17 17:52:44 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Oct 2013 00:52:44 +0000 Subject: hg: jdk8/tl/jdk: 11 new changesets Message-ID: <20131018005525.F31C0624F0@hg.openjdk.java.net> Changeset: 28191d3ff921 Author: erikj Date: 2013-10-09 16:22 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/28191d3ff921 8026144: Missing mkdir in Images.gmk Reviewed-by: tbell ! makefiles/Images.gmk Changeset: 86df2e879eca Author: tbell Date: 2013-10-09 18:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86df2e879eca 8023611: Win32 and win64: Remove all the WARNINGS in JDK 8 builds for Windows 2008 and MSVS 2010 SP1 Reviewed-by: erikj ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Sanity.gmk Changeset: 98d98ec01f07 Author: tbell Date: 2013-10-09 23:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98d98ec01f07 Merge Changeset: 9c60860b1812 Author: ihse Date: 2013-10-10 15:06 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9c60860b1812 8001931: The new build system whitespace cleanup Reviewed-by: tbell, simonis, erikj ! makefiles/BuildJdk.gmk ! makefiles/Bundles.gmk ! makefiles/CompileDemos.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CopySamples.gmk ! makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk ! makefiles/GendataFontConfig.gmk ! makefiles/GendataHtml32dtd.gmk ! makefiles/GendataTZDB.gmk ! makefiles/GendataTimeZone.gmk ! makefiles/GenerateClasses.gmk ! makefiles/GenerateData.gmk ! makefiles/GenerateJavaSources.gmk ! makefiles/GensrcBuffer.gmk ! makefiles/GensrcCLDR.gmk ! makefiles/GensrcCharacterData.gmk ! makefiles/GensrcCharsetCoder.gmk ! makefiles/GensrcCharsetMapping.gmk ! makefiles/GensrcExceptions.gmk ! makefiles/GensrcIcons.gmk ! makefiles/GensrcJDWP.gmk ! makefiles/GensrcJObjC.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! makefiles/GensrcMisc.gmk ! makefiles/GensrcProperties.gmk ! makefiles/GensrcSwing.gmk ! makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk ! makefiles/Import.gmk ! makefiles/Makefile ! makefiles/PatchList.solaris ! makefiles/ProfileNames.gmk ! makefiles/Profiles.gmk ! makefiles/Setup.gmk ! makefiles/SignJars.gmk ! makefiles/Tools.gmk ! makefiles/jpda/jdwp/jdwp.spec ! makefiles/jprt.gmk ! makefiles/jprt.properties ! makefiles/mapfiles/libawt/mapfile-mawt-vers ! makefiles/mapfiles/libawt/mapfile-vers ! makefiles/mapfiles/libawt/mapfile-vers-linux ! makefiles/mapfiles/libawt_headless/mapfile-vers ! makefiles/mapfiles/libawt_xawt/mapfile-vers ! makefiles/mapfiles/libfontmanager/mapfile-vers ! makefiles/mapfiles/libfontmanager/mapfile-vers.openjdk ! makefiles/mapfiles/libj2pcsc/mapfile-vers ! makefiles/mapfiles/libjdga/mapfile-vers ! makefiles/mapfiles/libjli/mapfile-vers ! makefiles/mapfiles/libverify/mapfile-vers ! makefiles/profile-includes.txt ! makefiles/profile-rtjar-includes.txt ! makefiles/scripts/addNotices.sh ! makefiles/scripts/genCharsetProvider.sh ! makefiles/scripts/genExceptions.sh ! makefiles/scripts/localelist.sh ! makefiles/sun/awt/ToBin.java Changeset: cf3ee0e2c1a5 Author: erikj Date: 2013-10-14 11:36 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf3ee0e2c1a5 8025612: rt.jar still has old specification value in the manifest Reviewed-by: alanb, dholmes, tbell, wetmore ! make/tools/manifest.mf Changeset: 986acae7efe9 Author: ihse Date: 2013-10-15 13:06 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/986acae7efe9 8001933: Move Gensrc*.gmk and Gendata*.gmk into separate directories. Reviewed-by: erikj, tbell ! makefiles/BuildJdk.gmk ! makefiles/CreateJars.gmk - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.gmk ! makefiles/GenerateData.gmk - makefiles/GenerateJavaSources.gmk + makefiles/GenerateSources.gmk - makefiles/GensrcBuffer.gmk - makefiles/GensrcCLDR.gmk - makefiles/GensrcCharacterData.gmk - makefiles/GensrcCharsetCoder.gmk - makefiles/GensrcCharsetMapping.gmk - makefiles/GensrcExceptions.gmk - makefiles/GensrcIcons.gmk - makefiles/GensrcJDWP.gmk - makefiles/GensrcJObjC.gmk - makefiles/GensrcLocaleDataMetaInfo.gmk - makefiles/GensrcMisc.gmk - makefiles/GensrcProperties.gmk - makefiles/GensrcSwing.gmk - makefiles/GensrcX11Wrappers.gmk + makefiles/gendata/GendataBreakIterator.gmk + makefiles/gendata/GendataFontConfig.gmk + makefiles/gendata/GendataHtml32dtd.gmk + makefiles/gendata/GendataTZDB.gmk + makefiles/gendata/GendataTimeZone.gmk + makefiles/gensrc/GensrcBuffer.gmk + makefiles/gensrc/GensrcCLDR.gmk + makefiles/gensrc/GensrcCharacterData.gmk + makefiles/gensrc/GensrcCharsetCoder.gmk + makefiles/gensrc/GensrcCharsetMapping.gmk + makefiles/gensrc/GensrcExceptions.gmk + makefiles/gensrc/GensrcIcons.gmk + makefiles/gensrc/GensrcJDWP.gmk + makefiles/gensrc/GensrcJObjC.gmk + makefiles/gensrc/GensrcLocaleDataMetaInfo.gmk + makefiles/gensrc/GensrcMisc.gmk + makefiles/gensrc/GensrcProperties.gmk + makefiles/gensrc/GensrcSwing.gmk + makefiles/gensrc/GensrcX11Wrappers.gmk Changeset: eef656e1bdeb Author: ksrini Date: 2013-10-16 07:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eef656e1bdeb 8026500: [infra] remove extraneous docs in solaris images Reviewed-by: erikj, mchung, tbell ! makefiles/Images.gmk - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 Changeset: f002f5f3a16c Author: katleman Date: 2013-10-16 12:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f002f5f3a16c Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.gmk - makefiles/GenerateJavaSources.gmk - makefiles/GensrcBuffer.gmk - makefiles/GensrcCLDR.gmk - makefiles/GensrcCharacterData.gmk - makefiles/GensrcCharsetCoder.gmk - makefiles/GensrcCharsetMapping.gmk - makefiles/GensrcExceptions.gmk - makefiles/GensrcIcons.gmk - makefiles/GensrcJDWP.gmk - makefiles/GensrcJObjC.gmk - makefiles/GensrcLocaleDataMetaInfo.gmk - makefiles/GensrcMisc.gmk - makefiles/GensrcProperties.gmk - makefiles/GensrcSwing.gmk - makefiles/GensrcX11Wrappers.gmk ! makefiles/Profiles.gmk ! makefiles/profile-includes.txt - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 Changeset: bef8f6d429de Author: cl Date: 2013-10-17 09:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bef8f6d429de Added tag jdk8-b112 for changeset f002f5f3a16c ! .hgtags Changeset: 187d5ccb5b18 Author: lana Date: 2013-10-17 15:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/187d5ccb5b18 Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CreateJars.gmk - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.gmk ! makefiles/GenerateClasses.gmk - makefiles/GenerateJavaSources.gmk - makefiles/GensrcBuffer.gmk - makefiles/GensrcCLDR.gmk - makefiles/GensrcCharacterData.gmk - makefiles/GensrcCharsetCoder.gmk - makefiles/GensrcCharsetMapping.gmk - makefiles/GensrcExceptions.gmk - makefiles/GensrcIcons.gmk - makefiles/GensrcJDWP.gmk - makefiles/GensrcJObjC.gmk - makefiles/GensrcLocaleDataMetaInfo.gmk - makefiles/GensrcMisc.gmk - makefiles/GensrcProperties.gmk - makefiles/GensrcSwing.gmk - makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk ! makefiles/Setup.gmk ! makefiles/Tools.gmk + makefiles/gendata/GendataBreakIterator.gmk ! makefiles/profile-includes.txt - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 Changeset: b73fb7920645 Author: lana Date: 2013-10-17 15:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b73fb7920645 Merge - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.gmk - makefiles/GenerateJavaSources.gmk - makefiles/GensrcBuffer.gmk - makefiles/GensrcCLDR.gmk - makefiles/GensrcCharacterData.gmk - makefiles/GensrcCharsetCoder.gmk - makefiles/GensrcCharsetMapping.gmk - makefiles/GensrcExceptions.gmk - makefiles/GensrcIcons.gmk - makefiles/GensrcJDWP.gmk - makefiles/GensrcJObjC.gmk - makefiles/GensrcLocaleDataMetaInfo.gmk - makefiles/GensrcMisc.gmk - makefiles/GensrcProperties.gmk - makefiles/GensrcSwing.gmk - makefiles/GensrcX11Wrappers.gmk - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 From lana.steuck at oracle.com Thu Oct 17 17:52:44 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Oct 2013 00:52:44 +0000 Subject: hg: jdk8/tl/hotspot: 46 new changesets Message-ID: <20131018005433.C131B624EF@hg.openjdk.java.net> Changeset: deec468baebd Author: amurillo Date: 2013-10-04 14:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/deec468baebd 8025859: new hotspot build - hs25-b54 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 5b3b75d9eb2f Author: coleenp Date: 2013-10-01 14:23 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5b3b75d9eb2f 8025570: Naked oop in test/serviceability/ParserTest Summary: Fix for two naked objArrayOop(s) oops causing test failure Reviewed-by: coleenp, ctornqvi Contributed-by: lois.foltan at oracle.com ! src/share/vm/prims/wbtestmethods/parserTests.cpp Changeset: f21415c32ca1 Author: coleenp Date: 2013-10-01 15:41 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f21415c32ca1 Merge Changeset: d574419c5372 Author: mseledtsov Date: 2013-10-02 15:17 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d574419c5372 8025671: Test name changed, test list not updated. Test6878713.sh Summary: Removed the obsolete test from the test group file Reviewed-by: sla, ctornqvi, dholmes ! test/TEST.groups Changeset: 931f105563c5 Author: coleenp Date: 2013-10-02 13:02 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/931f105563c5 8025569: -XX:+CheckUnhandledOops crashes on Windows Summary: Disable CHECK_UNHANDLED_OOPS in fastdebug builds for JDK 8 on WIndows 32 & 64 bit machines Reviewed-by: coleenp, ctornqvi, zgu Contributed-by: lois.foltan at oracle.com ! make/windows/makefiles/fastdebug.make Changeset: 6f73bc5df986 Author: coleenp Date: 2013-10-02 15:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6f73bc5df986 Merge Changeset: 2bd38d594b9a Author: dsamersoff Date: 2013-10-02 20:58 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2bd38d594b9a 8025283: Nits in os_bsd file breaks compilation of open hotspot Summary: Couple of nits in os_bsd.cpp brake compilation of open hotspot on non-apple platforms Reviewed-by: sla, sspitsyn ! src/os/bsd/vm/os_bsd.cpp Changeset: 9855f17334d8 Author: dsamersoff Date: 2013-10-03 01:12 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9855f17334d8 Merge Changeset: 5705c7ee6dd7 Author: dsamersoff Date: 2013-10-02 22:27 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5705c7ee6dd7 8025250: SA: Sync linux and bsd versions of ps_core file Summary: linux/ps_core.c and bsd/ps_core.c share most of code, but it has different formatting, comments etc. Reviewed-by: sla, minqi ! agent/src/os/bsd/ps_core.c ! agent/src/os/linux/ps_core.c Changeset: 7ae82c3a781a Author: dsamersoff Date: 2013-10-03 04:42 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ae82c3a781a Merge Changeset: faff125a1ead Author: dsamersoff Date: 2013-10-03 12:39 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/faff125a1ead 8022616: u4 should not be used as a type for thread_id Summary: Usage of u4 as a type for thread_id cause a compilation error on platform, where thread_id is a pointer Reviewed-by: sla, sspitsyn, minqi ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp Changeset: 07f8c2a453f8 Author: coleenp Date: 2013-10-03 18:53 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/07f8c2a453f8 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV Summary: Redefined class in stack trace may not be found by method_idnum so handle null. Reviewed-by: sla, dcubed, sspitsyn ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 3374b92de2d9 Author: coleenp Date: 2013-10-03 18:50 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3374b92de2d9 8025004: -XX:+CheckUnhandledOops asserts for JDK 8 Solaris fastdebug binaries Summary: Remove unnecessary volatile keyword on stack locals within instanceKlass.cpp to work around Solaris Studio C++ compiler issue Reviewed-by: coleenp, dcubed Contributed-by: lois.foltan at oracle.com ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 3bf767171ea4 Author: coleenp Date: 2013-10-05 00:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3bf767171ea4 Merge Changeset: 675ffabf3798 Author: mikael Date: 2013-10-02 09:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/675ffabf3798 8024087: Remove dead JVM_{Get,Set}PrimitiveFieldValues functions Summary: The two functions were used to support JDK 1.3 but are no longer in use Reviewed-by: coleenp, ctornqvi, twisti, dsamersoff ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/nativeLookup.cpp Changeset: a1fd44b003c7 Author: coleenp Date: 2013-10-05 00:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a1fd44b003c7 Merge Changeset: 4212bfb33d76 Author: coleenp Date: 2013-10-05 03:14 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4212bfb33d76 Merge Changeset: 2720ab7a0d70 Author: ccheung Date: 2013-10-04 21:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2720ab7a0d70 Merge ! src/share/vm/prims/jvm.cpp Changeset: febab3a8f203 Author: erikj Date: 2013-10-04 12:45 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/febab3a8f203 8007446: Add /MP to cl.exe speeds up windows builds of OpenJDK. Reviewed-by: sla, ctornqvi ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make Changeset: 763705f0fec3 Author: sla Date: 2013-10-04 13:01 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/763705f0fec3 8016845: SA is unable to use hsdis on windows Summary: Added sadis.c to the build to provide missing symbols in sawindbg.dll. Added code to use the correct hsdisXXX.dll filename on different windows platforms. Reviewed-by: sla, mgerdin Contributed-by: fredrik.arvidsson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java ! make/windows/makefiles/sa.make Changeset: f9be370a7d54 Author: sla Date: 2013-10-05 15:18 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f9be370a7d54 8025922: JNI access to Strings need to check if the value field is non-null Reviewed-by: dholmes, dcubed ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp Changeset: 8ef918538e22 Author: sla Date: 2013-10-04 13:44 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8ef918538e22 6313383: SA: Update jmap to support HPROF binary format "JAVA PROFILE 1.0.2" Summary: Adds support for large(>4G) heap dumps in hprof format. Adds tests and updates testlibrary. Reviewed-by: sla, allwin Contributed-by: fredrik.arvidsson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! test/TEST.groups + test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapProc.java + test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 9c63ad02c0a4 Author: sla Date: 2013-10-05 10:56 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9c63ad02c0a4 Merge Changeset: cc4f5f8d885e Author: mseledtsov Date: 2013-10-06 16:13 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cc4f5f8d885e 8023796: [TESTBUG] Add -XX:-TransmitErrorReport to runtime/6888954/vmerrors.sh Summary: added -XX:-TransmitErrorReport to the test Reviewed-by: stefank, ctornqvi ! test/runtime/6888954/vmerrors.sh ! test/runtime/memory/ReserveMemory.java Changeset: ac9cb1d5a202 Author: acorn Date: 2013-10-07 12:20 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ac9cb1d5a202 8009130: Lambda: Fix access controls, loader constraints. Summary: New default methods list with inherited superinterface methods Reviewed-by: minqi, sspitsyn, coleenp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/reflectionUtils.cpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 615d83933195 Author: dholmes Date: 2013-10-08 02:56 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/615d83933195 8026025: JVM_GetCallerClass allows Reflection.getCallerClass(int depth) to use Reviewed-by: alanb, dholmes, twisti Contributed-by: mandy.chung at oracle.com ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: c90e76575b03 Author: kevinw Date: 2013-10-08 09:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c90e76575b03 8019375: Internal symbol table size should be tunable. Reviewed-by: coleenp, kamg ! agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: ced68a57cdbd Author: kevinw Date: 2013-10-08 11:37 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ced68a57cdbd Merge Changeset: c72075c2883e Author: acorn Date: 2013-10-08 16:58 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c72075c2883e 8026022: Verifier: allow anon classes to invokespecial host class/intf methods. Reviewed-by: coleenp, bharadwaj ! src/share/vm/classfile/verifier.cpp Changeset: d25557d03ec0 Author: acorn Date: 2013-10-09 17:57 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d25557d03ec0 8026185: nsk/jvmit/GetMethodDeclaringClass/declcls001 failed Summary: Missed initialization. Thanks Coleen. Reviewed-by: coleenp, minqi ! src/share/vm/oops/instanceKlass.cpp Changeset: c01f4910f5f5 Author: ccheung Date: 2013-10-10 13:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c01f4910f5f5 Merge Changeset: 9b4d0569f2f4 Author: jwilhelm Date: 2013-10-03 21:36 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9b4d0569f2f4 8025852: Remove unnecessary setters in collector policy classes Summary: Use instance variables directly within the collector policy classes and remove unused setters. Reviewed-by: tschatzl, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp Changeset: 087f02e22fc2 Author: jwilhelm Date: 2013-10-04 22:08 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/087f02e22fc2 8025854: Use "young gen" instead of "eden" Summary: Changed a few descriptions and variable names to young gen. Reviewed-by: tschatzl, jcoomes ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 263f2c796d6c Author: stefank Date: 2013-10-05 10:14 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/263f2c796d6c 8024838: Significant slowdown due to transparent huge pages Summary: Don't turn on transparent huge pages (-XX:+UseTransparentHugePages) unless explicitly specified on the command line. This has the effect that large pages are never turned on Linux unless the user has explicitly enabled any of the large pages flags: -XX:+UseLargePages, -XX:+UseTransparentHugePages, -XX:+UseHugeTLBFS, and -XX:+UseSHM. Reviewed-by: jwilhelm, tschatzl, brutisso ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp + test/runtime/memory/LargePages/TestLargePagesFlags.java Changeset: 8618e0d7735b Author: stefank Date: 2013-10-05 08:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8618e0d7735b Merge Changeset: 04b18a42c2f3 Author: mgerdin Date: 2013-10-04 13:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/04b18a42c2f3 8025526: VirtualSpace should support per-instance disabling of large pages Summary: Add a new initialization function to VirtualSpace which allows the caller to override the max commit granularity. Reviewed-by: stefank, ehelin, tschatzl ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp Changeset: 69944b868a32 Author: mgerdin Date: 2013-10-08 17:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/69944b868a32 8014555: G1: Memory ordering problem with Conc refinement and card marking Summary: Add a StoreLoad barrier in the G1 post-barrier to fix a race with concurrent refinement. Also-reviewed-by: martin.doerr at sap.com Reviewed-by: iveresov, tschatzl, brutisso, roland, kvn ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/opto/graphKit.cpp Changeset: b4d8a3d4db73 Author: tamao Date: 2013-10-09 11:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b4d8a3d4db73 8010506: Typos and errors in descriptions of vm options in globals.hpp Summary: Fix typos and errors in descriptions of vm options in globals.hpp Reviewed-by: jmasa, jwilhelm ! src/share/vm/runtime/globals.hpp Changeset: 82af7d7a0128 Author: tschatzl Date: 2013-10-09 10:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/82af7d7a0128 8003420: NPG: make new GC root for pd_set Summary: Move protection domain oops from system dictionary entries into a seperate set; the system dictionary references entries in that set now. This allows fast iteration during non-classunloading garbage collection. Implementation based on initial prototype from Ioi Lam (iklam). Reviewed-by: coleenp, iklam + agent/src/share/classes/sun/jvm/hotspot/memory/ProtectionDomainCacheEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/ProtectionDomainEntry.java ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 85c1ca43713f Author: stefank Date: 2013-10-07 15:51 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/85c1ca43713f 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces Reviewed-by: brutisso, jmasa, coleenp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: a6414751d537 Author: stefank Date: 2013-10-07 15:51 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a6414751d537 8025996: Track metaspace usage when metaspace is expanded Reviewed-by: coleenp, ehelin ! src/share/vm/memory/metaspace.cpp ! src/share/vm/services/memoryService.hpp Changeset: aa6f2ea19d8f Author: jcoomes Date: 2013-10-11 08:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aa6f2ea19d8f Merge ! src/os/linux/vm/os_linux.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 4a845c7a4638 Author: amurillo Date: 2013-10-11 13:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4a845c7a4638 Merge Changeset: 0ed9a90f45e1 Author: amurillo Date: 2013-10-11 13:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0ed9a90f45e1 Added tag hs25-b54 for changeset 4a845c7a4638 ! .hgtags Changeset: aeae561a6d0b Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aeae561a6d0b Added tag jdk8-b112 for changeset 0ed9a90f45e1 ! .hgtags Changeset: 1a93f2c5945a Author: lana Date: 2013-10-17 14:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1a93f2c5945a Merge ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make ! src/share/vm/classfile/classFileParser.cpp From weijun.wang at oracle.com Thu Oct 17 18:00:02 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 18 Oct 2013 01:00:02 +0000 Subject: hg: jdk8/tl/jdk: 7025699: Policy Tool is not accessible by keyboard Message-ID: <20131018010020.7680F624F1@hg.openjdk.java.net> Changeset: c1616a944d1c Author: weijun Date: 2013-10-18 08:57 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1616a944d1c 7025699: Policy Tool is not accessible by keyboard Reviewed-by: alexp, weijun Contributed-by: Leif Samuelsson ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! src/share/classes/sun/security/tools/policytool/Resources.java ! test/sun/security/tools/policytool/Alias.html ! test/sun/security/tools/policytool/OpenPolicy.html ! test/sun/security/tools/policytool/UpdatePermissions.html From joe.darcy at oracle.com Thu Oct 17 19:11:05 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 18 Oct 2013 02:11:05 +0000 Subject: hg: jdk8/tl/langtools: 8026838: Fix new doclint issues in javax.annotation.processing Message-ID: <20131018021117.C1794624F4@hg.openjdk.java.net> Changeset: 7af634b1fc5b Author: darcy Date: 2013-10-17 19:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7af634b1fc5b 8026838: Fix new doclint issues in javax.annotation.processing Reviewed-by: jjg ! src/share/classes/javax/annotation/processing/Processor.java From mandy.chung at oracle.com Thu Oct 17 19:51:03 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 18 Oct 2013 02:51:03 +0000 Subject: hg: jdk8/tl/jdk: 8025799: Restore sun.reflect.Reflection.getCallerClass(int) until a replacement API is provided Message-ID: <20131018025201.EFA98624F6@hg.openjdk.java.net> Changeset: 042a473535aa Author: mchung Date: 2013-10-17 19:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/042a473535aa 8025799: Restore sun.reflect.Reflection.getCallerClass(int) until a replacement API is provided Reviewed-by: alanb, forax, dholmes, twisti ! makefiles/mapfiles/libjava/mapfile-vers ! makefiles/mapfiles/libjava/reorder-sparc ! makefiles/mapfiles/libjava/reorder-sparcv9 ! makefiles/mapfiles/libjava/reorder-x86 ! src/share/classes/sun/reflect/Reflection.java ! src/share/javavm/export/jvm.h ! src/share/native/sun/reflect/Reflection.c + test/sun/reflect/Reflection/GetCallerClassWithDepth.java From joe.darcy at oracle.com Thu Oct 17 22:22:49 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 18 Oct 2013 05:22:49 +0000 Subject: hg: jdk8/tl/jdk: 8026840: Fix new doclint issues in javax.naming Message-ID: <20131018052321.D251D624FC@hg.openjdk.java.net> Changeset: 8a7b1b615100 Author: darcy Date: 2013-10-17 22:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a7b1b615100 8026840: Fix new doclint issues in javax.naming Reviewed-by: mchung ! src/share/classes/javax/naming/CompositeName.java ! src/share/classes/javax/naming/CompoundName.java ! src/share/classes/javax/naming/Context.java ! src/share/classes/javax/naming/InitialContext.java ! src/share/classes/javax/naming/ReferralException.java ! src/share/classes/javax/naming/directory/DirContext.java ! src/share/classes/javax/naming/event/EventContext.java ! src/share/classes/javax/naming/ldap/LdapContext.java ! src/share/classes/javax/naming/ldap/Rdn.java From serguei.spitsyn at oracle.com Thu Oct 17 22:49:31 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 17 Oct 2013 22:49:31 -0700 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <20131017212852.GA6066@ehelin-thinkpad> References: <20131016160914.GA10865@ehelin-thinkpad> <525ED138.1000305@oracle.com> <20131017212852.GA6066@ehelin-thinkpad> Message-ID: <5260CBEB.1000902@oracle.com> Hi Erik, The fix looks good in general. But one thing is confusing in the fix. Why do you keep both _class_loader and _class_loader_handle in the JvmtiBreakpoint class? Also, you need to run the nsk.jdi.testlist and nsk.jdwp.testlist test suites as well. Thanks, Serguei On 10/17/13 2:28 PM, Erik Helin wrote: > Hi Mikael and Coleen, > > thanks for your reviews! > > On 2013-10-16, Mikael Gerdin wrote: >> jvmtiImpl.hpp: >> Since clone() uses unhandled oops, and is only supposed to be used >> by the VM operation, would it make sense to >> assert(SafepointSynchronize::is_at_safepoint())? >> >> 196 GrowableElement *clone() { >> 197 return new JvmtiBreakpoint(_method, _bci, _class_loader_handle); > Agree, I've updated the patch. A new webrev is located at: > http://cr.openjdk.java.net/~ehelin/8025834/webrev.01/ > > On 2013-10-16, Mikael Gerdin wrote: >> jvmtiEnv.cpp: >> Have you verified that the generated JVMTI entry point contains a >> ResourceMark or is it just not needed? >> - ResourceMark rm; >> + HandleMark hm; > The JVMTI entry point does not contain a ResourceMark. However, I have > verified that a ResourceMark is not needed for jvmtiEnv::SetBreakpoint > nor for jvmtiEnv::ClearBreapoint. The only codes that needs a > ResourceMark is JvmtiBreakpoints::prints, but that method already has a > ResourceMark. > > On 2013-10-16, Coleen Phillimore wrote: >> Did you run the nsk.jvmti.testlist tests too though? > No, I had not run the nsk.jvmti.testlist test, but I have now :) > > I run both with and without the patch on the latest hsx/hotspot-gc. I > also run with and without -XX:+CheckUnhandledOops. The results were all > the same: 598 passed an 11 failed (the same tests for all combinations). > So, the patch does not introduce any regressions for this test suite. > > Thanks, > Erik > > On 2013-10-16, Mikael Gerdin wrote: >> Erik, >> >> (it's not necessary to cross-post between hotspot-dev and >> hotspot-gc-dev, so I removed hotspot-gc from the CC list) >> >> On 2013-10-16 18:09, Erik Helin wrote: >>> Hi all, >>> >>> this patch fixes an issue where an oop in JvmtiBreakpoint, >>> JvmtiBreakpoint::_class_loader, was found by the unhandled oop detector. >>> >>> Instead of registering the oop as an unhandled oop, which would have >>> worked, I decided to wrap the oop in a handle as long as it is on the >>> stack. >>> >>> A JvmtiBreakpoint is created on the stack by the two methods >>> JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This >>> JvmtiBreakpoint is only created to carry the Method*, jlocation and oop >>> to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, when >>> at a safepoint, allocate a new JvmtiBreakpoint on the native heap, copy >>> the values from the stack allocated JvmtiBreakpoint and then place/clear the >>> newly alloacted JvmtiBreakpoint in >>> JvmtiCurrentBreakpoints::_jvmti_breakpoints. >>> >>> I have updated to the code to check that the public constructor is only >>> used to allocate JvmtiBreakpoints on the stack (to warn a future >>> programmer if he/she decides to allocate one on the heap). The >>> class_loader oop is now wrapped in a Handle for stack allocated >>> JvmtiBreakpoints. >>> >>> Due to the stack allocated JvmtiBreakpoint having the oop in a handle, >>> the oops_do method of VM_ChangeBreakpoints can be removed. This also >>> makes the oop in the handle safe for use after the VM_ChangeBreakpoint >>> operation is finished. >>> >>> The unhandled oop in the JvmtiBreakpoint allocated on the heap will be >>> visited by the GC via jvmtiExport::oops_do -> >>> JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> >>> GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being >>> added to. >>> >>> I've also removed some dead code to simplify the change: >>> - GrowableCache::insert >>> - JvmtiBreakpoint::copy >>> - JvmtiBreakpoint::lessThan >>> - GrowableElement::lessThan >>> >>> Finally, I also formatted JvmtiEnv::ClearBreakpoint and >>> Jvmti::SetBreakpoint exactly the same to highlight that they share all >>> code except one line. Unfortunately, I was not able to remove this code >>> duplication in a good way. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ >> jvmtiImpl.hpp: >> Since clone() uses unhandled oops, and is only supposed to be used >> by the VM operation, would it make sense to >> assert(SafepointSynchronize::is_at_safepoint())? >> >> 196 GrowableElement *clone() { >> 197 return new JvmtiBreakpoint(_method, _bci, _class_loader_handle); >> >> jvmtiImpl.cpp: >> No comments. >> >> jvmtiEnv.cpp: >> Have you verified that the generated JVMTI entry point contains a >> ResourceMark or is it just not needed? >> - ResourceMark rm; >> + HandleMark hm; >> >> Otherwise the code change looks good. >> >> >> One thing that you didn't describe here, but which was related to >> the bug (which we discussed) was the fact that the old code tried to >> "do the right thing" WRT CheckUnhandledOops, but it incorrectly >> added a Method*: >> >> thread->allow_unhandled_oop((oop*)&_method); >> >> We should take care to find other such places where we try to put a >> non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in >> the unhandled oops code. >> >> /Mikael >> >>> Testing: >>> - JPRT >>> - The four tests that were failing are now passing >>> >>> Thanks, >>> Erik >>> From serguei.spitsyn at oracle.com Thu Oct 17 22:51:14 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 17 Oct 2013 22:51:14 -0700 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <5260CBEB.1000902@oracle.com> References: <20131016160914.GA10865@ehelin-thinkpad> <525ED138.1000305@oracle.com> <20131017212852.GA6066@ehelin-thinkpad> <5260CBEB.1000902@oracle.com> Message-ID: <5260CC52.7050306@oracle.com> I forgot to say "thank you" for taking care about this issue! Thanks, Serguei On 10/17/13 10:49 PM, serguei.spitsyn at oracle.com wrote: > Hi Erik, > > The fix looks good in general. > > But one thing is confusing in the fix. > Why do you keep both _class_loader and _class_loader_handle in the > JvmtiBreakpoint class? > > Also, you need to run the nsk.jdi.testlist and nsk.jdwp.testlist test > suites as well. > > Thanks, > Serguei > > > On 10/17/13 2:28 PM, Erik Helin wrote: >> Hi Mikael and Coleen, >> >> thanks for your reviews! >> >> On 2013-10-16, Mikael Gerdin wrote: >>> jvmtiImpl.hpp: >>> Since clone() uses unhandled oops, and is only supposed to be used >>> by the VM operation, would it make sense to >>> assert(SafepointSynchronize::is_at_safepoint())? >>> >>> 196 GrowableElement *clone() { >>> 197 return new JvmtiBreakpoint(_method, _bci, >>> _class_loader_handle); >> Agree, I've updated the patch. A new webrev is located at: >> http://cr.openjdk.java.net/~ehelin/8025834/webrev.01/ >> >> On 2013-10-16, Mikael Gerdin wrote: >>> jvmtiEnv.cpp: >>> Have you verified that the generated JVMTI entry point contains a >>> ResourceMark or is it just not needed? >>> - ResourceMark rm; >>> + HandleMark hm; >> The JVMTI entry point does not contain a ResourceMark. However, I have >> verified that a ResourceMark is not needed for jvmtiEnv::SetBreakpoint >> nor for jvmtiEnv::ClearBreapoint. The only codes that needs a >> ResourceMark is JvmtiBreakpoints::prints, but that method already has a >> ResourceMark. >> >> On 2013-10-16, Coleen Phillimore wrote: >>> Did you run the nsk.jvmti.testlist tests too though? >> No, I had not run the nsk.jvmti.testlist test, but I have now :) >> >> I run both with and without the patch on the latest hsx/hotspot-gc. I >> also run with and without -XX:+CheckUnhandledOops. The results were all >> the same: 598 passed an 11 failed (the same tests for all combinations). >> So, the patch does not introduce any regressions for this test suite. >> >> Thanks, >> Erik >> >> On 2013-10-16, Mikael Gerdin wrote: >>> Erik, >>> >>> (it's not necessary to cross-post between hotspot-dev and >>> hotspot-gc-dev, so I removed hotspot-gc from the CC list) >>> >>> On 2013-10-16 18:09, Erik Helin wrote: >>>> Hi all, >>>> >>>> this patch fixes an issue where an oop in JvmtiBreakpoint, >>>> JvmtiBreakpoint::_class_loader, was found by the unhandled oop >>>> detector. >>>> >>>> Instead of registering the oop as an unhandled oop, which would have >>>> worked, I decided to wrap the oop in a handle as long as it is on the >>>> stack. >>>> >>>> A JvmtiBreakpoint is created on the stack by the two methods >>>> JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This >>>> JvmtiBreakpoint is only created to carry the Method*, jlocation and >>>> oop >>>> to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, >>>> when >>>> at a safepoint, allocate a new JvmtiBreakpoint on the native heap, >>>> copy >>>> the values from the stack allocated JvmtiBreakpoint and then >>>> place/clear the >>>> newly alloacted JvmtiBreakpoint in >>>> JvmtiCurrentBreakpoints::_jvmti_breakpoints. >>>> >>>> I have updated to the code to check that the public constructor is >>>> only >>>> used to allocate JvmtiBreakpoints on the stack (to warn a future >>>> programmer if he/she decides to allocate one on the heap). The >>>> class_loader oop is now wrapped in a Handle for stack allocated >>>> JvmtiBreakpoints. >>>> >>>> Due to the stack allocated JvmtiBreakpoint having the oop in a handle, >>>> the oops_do method of VM_ChangeBreakpoints can be removed. This also >>>> makes the oop in the handle safe for use after the VM_ChangeBreakpoint >>>> operation is finished. >>>> >>>> The unhandled oop in the JvmtiBreakpoint allocated on the heap will be >>>> visited by the GC via jvmtiExport::oops_do -> >>>> JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> >>>> GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being >>>> added to. >>>> >>>> I've also removed some dead code to simplify the change: >>>> - GrowableCache::insert >>>> - JvmtiBreakpoint::copy >>>> - JvmtiBreakpoint::lessThan >>>> - GrowableElement::lessThan >>>> >>>> Finally, I also formatted JvmtiEnv::ClearBreakpoint and >>>> Jvmti::SetBreakpoint exactly the same to highlight that they share all >>>> code except one line. Unfortunately, I was not able to remove this >>>> code >>>> duplication in a good way. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ >>> jvmtiImpl.hpp: >>> Since clone() uses unhandled oops, and is only supposed to be used >>> by the VM operation, would it make sense to >>> assert(SafepointSynchronize::is_at_safepoint())? >>> >>> 196 GrowableElement *clone() { >>> 197 return new JvmtiBreakpoint(_method, _bci, >>> _class_loader_handle); >>> >>> jvmtiImpl.cpp: >>> No comments. >>> >>> jvmtiEnv.cpp: >>> Have you verified that the generated JVMTI entry point contains a >>> ResourceMark or is it just not needed? >>> - ResourceMark rm; >>> + HandleMark hm; >>> >>> Otherwise the code change looks good. >>> >>> >>> One thing that you didn't describe here, but which was related to >>> the bug (which we discussed) was the fact that the old code tried to >>> "do the right thing" WRT CheckUnhandledOops, but it incorrectly >>> added a Method*: >>> >>> thread->allow_unhandled_oop((oop*)&_method); >>> >>> We should take care to find other such places where we try to put a >>> non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in >>> the unhandled oops code. >>> >>> /Mikael >>> >>>> Testing: >>>> - JPRT >>>> - The four tests that were failing are now passing >>>> >>>> Thanks, >>>> Erik >>>> > From david.holmes at oracle.com Thu Oct 17 23:03:20 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Oct 2013 16:03:20 +1000 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <5260CBEB.1000902@oracle.com> References: <20131016160914.GA10865@ehelin-thinkpad> <525ED138.1000305@oracle.com> <20131017212852.GA6066@ehelin-thinkpad> <5260CBEB.1000902@oracle.com> Message-ID: <5260CF28.2040403@oracle.com> On 18/10/2013 3:49 PM, serguei.spitsyn at oracle.com wrote: > Hi Erik, > > The fix looks good in general. > > But one thing is confusing in the fix. > Why do you keep both _class_loader and _class_loader_handle in the > JvmtiBreakpoint class? Even more confusing to me is the fact the neither of these seem to actually be used anywhere ??? But if we have the Handle then the oop is redundant AFAICS. David > Also, you need to run the nsk.jdi.testlist and nsk.jdwp.testlist test > suites as well. > > Thanks, > Serguei > > > On 10/17/13 2:28 PM, Erik Helin wrote: >> Hi Mikael and Coleen, >> >> thanks for your reviews! >> >> On 2013-10-16, Mikael Gerdin wrote: >>> jvmtiImpl.hpp: >>> Since clone() uses unhandled oops, and is only supposed to be used >>> by the VM operation, would it make sense to >>> assert(SafepointSynchronize::is_at_safepoint())? >>> >>> 196 GrowableElement *clone() { >>> 197 return new JvmtiBreakpoint(_method, _bci, >>> _class_loader_handle); >> Agree, I've updated the patch. A new webrev is located at: >> http://cr.openjdk.java.net/~ehelin/8025834/webrev.01/ >> >> On 2013-10-16, Mikael Gerdin wrote: >>> jvmtiEnv.cpp: >>> Have you verified that the generated JVMTI entry point contains a >>> ResourceMark or is it just not needed? >>> - ResourceMark rm; >>> + HandleMark hm; >> The JVMTI entry point does not contain a ResourceMark. However, I have >> verified that a ResourceMark is not needed for jvmtiEnv::SetBreakpoint >> nor for jvmtiEnv::ClearBreapoint. The only codes that needs a >> ResourceMark is JvmtiBreakpoints::prints, but that method already has a >> ResourceMark. >> >> On 2013-10-16, Coleen Phillimore wrote: >>> Did you run the nsk.jvmti.testlist tests too though? >> No, I had not run the nsk.jvmti.testlist test, but I have now :) >> >> I run both with and without the patch on the latest hsx/hotspot-gc. I >> also run with and without -XX:+CheckUnhandledOops. The results were all >> the same: 598 passed an 11 failed (the same tests for all combinations). >> So, the patch does not introduce any regressions for this test suite. >> >> Thanks, >> Erik >> >> On 2013-10-16, Mikael Gerdin wrote: >>> Erik, >>> >>> (it's not necessary to cross-post between hotspot-dev and >>> hotspot-gc-dev, so I removed hotspot-gc from the CC list) >>> >>> On 2013-10-16 18:09, Erik Helin wrote: >>>> Hi all, >>>> >>>> this patch fixes an issue where an oop in JvmtiBreakpoint, >>>> JvmtiBreakpoint::_class_loader, was found by the unhandled oop >>>> detector. >>>> >>>> Instead of registering the oop as an unhandled oop, which would have >>>> worked, I decided to wrap the oop in a handle as long as it is on the >>>> stack. >>>> >>>> A JvmtiBreakpoint is created on the stack by the two methods >>>> JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This >>>> JvmtiBreakpoint is only created to carry the Method*, jlocation and oop >>>> to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, >>>> when >>>> at a safepoint, allocate a new JvmtiBreakpoint on the native heap, copy >>>> the values from the stack allocated JvmtiBreakpoint and then >>>> place/clear the >>>> newly alloacted JvmtiBreakpoint in >>>> JvmtiCurrentBreakpoints::_jvmti_breakpoints. >>>> >>>> I have updated to the code to check that the public constructor is only >>>> used to allocate JvmtiBreakpoints on the stack (to warn a future >>>> programmer if he/she decides to allocate one on the heap). The >>>> class_loader oop is now wrapped in a Handle for stack allocated >>>> JvmtiBreakpoints. >>>> >>>> Due to the stack allocated JvmtiBreakpoint having the oop in a handle, >>>> the oops_do method of VM_ChangeBreakpoints can be removed. This also >>>> makes the oop in the handle safe for use after the VM_ChangeBreakpoint >>>> operation is finished. >>>> >>>> The unhandled oop in the JvmtiBreakpoint allocated on the heap will be >>>> visited by the GC via jvmtiExport::oops_do -> >>>> JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> >>>> GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being >>>> added to. >>>> >>>> I've also removed some dead code to simplify the change: >>>> - GrowableCache::insert >>>> - JvmtiBreakpoint::copy >>>> - JvmtiBreakpoint::lessThan >>>> - GrowableElement::lessThan >>>> >>>> Finally, I also formatted JvmtiEnv::ClearBreakpoint and >>>> Jvmti::SetBreakpoint exactly the same to highlight that they share all >>>> code except one line. Unfortunately, I was not able to remove this code >>>> duplication in a good way. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ >>> jvmtiImpl.hpp: >>> Since clone() uses unhandled oops, and is only supposed to be used >>> by the VM operation, would it make sense to >>> assert(SafepointSynchronize::is_at_safepoint())? >>> >>> 196 GrowableElement *clone() { >>> 197 return new JvmtiBreakpoint(_method, _bci, >>> _class_loader_handle); >>> >>> jvmtiImpl.cpp: >>> No comments. >>> >>> jvmtiEnv.cpp: >>> Have you verified that the generated JVMTI entry point contains a >>> ResourceMark or is it just not needed? >>> - ResourceMark rm; >>> + HandleMark hm; >>> >>> Otherwise the code change looks good. >>> >>> >>> One thing that you didn't describe here, but which was related to >>> the bug (which we discussed) was the fact that the old code tried to >>> "do the right thing" WRT CheckUnhandledOops, but it incorrectly >>> added a Method*: >>> >>> thread->allow_unhandled_oop((oop*)&_method); >>> >>> We should take care to find other such places where we try to put a >>> non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in >>> the unhandled oops code. >>> >>> /Mikael >>> >>>> Testing: >>>> - JPRT >>>> - The four tests that were failing are now passing >>>> >>>> Thanks, >>>> Erik >>>> > From xueming.shen at oracle.com Thu Oct 17 23:42:03 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 18 Oct 2013 06:42:03 +0000 Subject: hg: jdk8/tl/jdk: 8025971: Remove ZoneId.OLD_SHORT_IDS; ... Message-ID: <20131018064229.C8DCE624FD@hg.openjdk.java.net> Changeset: 658e121bda42 Author: sherman Date: 2013-10-17 23:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/658e121bda42 8025971: Remove ZoneId.OLD_SHORT_IDS 8026197: Slow reading tzdb.dat if the JRE is on a high-latency, remote file system Summary: removed the compatiblity old short-ids mapping Reviewed-by: okutsu ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/zone/TzdbZoneRulesProvider.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! test/java/time/tck/java/time/TCKZoneId.java ! test/java/util/Calendar/JavatimeTest.java From serguei.spitsyn at oracle.com Fri Oct 18 00:24:30 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 18 Oct 2013 00:24:30 -0700 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <5260CF28.2040403@oracle.com> References: <20131016160914.GA10865@ehelin-thinkpad> <525ED138.1000305@oracle.com> <20131017212852.GA6066@ehelin-thinkpad> <5260CBEB.1000902@oracle.com> <5260CF28.2040403@oracle.com> Message-ID: <5260E22E.1010503@oracle.com> On 10/17/13 11:03 PM, David Holmes wrote: > On 18/10/2013 3:49 PM, serguei.spitsyn at oracle.com wrote: >> Hi Erik, >> >> The fix looks good in general. >> >> But one thing is confusing in the fix. >> Why do you keep both _class_loader and _class_loader_handle in the >> JvmtiBreakpoint class? > > Even more confusing to me is the fact the neither of these seem to > actually be used anywhere ??? Nice catch, David. I do not see too any of them is really used. Is it a leftover after the permgen elimination? > > But if we have the Handle then the oop is redundant AFAICS. Right. The issue is that the oop version is used in the oops_do. Not sure if we can get rid of oops_do. It may have an empty body though. Thanks, Serguei > > David > >> Also, you need to run the nsk.jdi.testlist and nsk.jdwp.testlist test >> suites as well. >> >> Thanks, >> Serguei >> >> >> On 10/17/13 2:28 PM, Erik Helin wrote: >>> Hi Mikael and Coleen, >>> >>> thanks for your reviews! >>> >>> On 2013-10-16, Mikael Gerdin wrote: >>>> jvmtiImpl.hpp: >>>> Since clone() uses unhandled oops, and is only supposed to be used >>>> by the VM operation, would it make sense to >>>> assert(SafepointSynchronize::is_at_safepoint())? >>>> >>>> 196 GrowableElement *clone() { >>>> 197 return new JvmtiBreakpoint(_method, _bci, >>>> _class_loader_handle); >>> Agree, I've updated the patch. A new webrev is located at: >>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.01/ >>> >>> On 2013-10-16, Mikael Gerdin wrote: >>>> jvmtiEnv.cpp: >>>> Have you verified that the generated JVMTI entry point contains a >>>> ResourceMark or is it just not needed? >>>> - ResourceMark rm; >>>> + HandleMark hm; >>> The JVMTI entry point does not contain a ResourceMark. However, I have >>> verified that a ResourceMark is not needed for jvmtiEnv::SetBreakpoint >>> nor for jvmtiEnv::ClearBreapoint. The only codes that needs a >>> ResourceMark is JvmtiBreakpoints::prints, but that method already has a >>> ResourceMark. >>> >>> On 2013-10-16, Coleen Phillimore wrote: >>>> Did you run the nsk.jvmti.testlist tests too though? >>> No, I had not run the nsk.jvmti.testlist test, but I have now :) >>> >>> I run both with and without the patch on the latest hsx/hotspot-gc. I >>> also run with and without -XX:+CheckUnhandledOops. The results were all >>> the same: 598 passed an 11 failed (the same tests for all >>> combinations). >>> So, the patch does not introduce any regressions for this test suite. >>> >>> Thanks, >>> Erik >>> >>> On 2013-10-16, Mikael Gerdin wrote: >>>> Erik, >>>> >>>> (it's not necessary to cross-post between hotspot-dev and >>>> hotspot-gc-dev, so I removed hotspot-gc from the CC list) >>>> >>>> On 2013-10-16 18:09, Erik Helin wrote: >>>>> Hi all, >>>>> >>>>> this patch fixes an issue where an oop in JvmtiBreakpoint, >>>>> JvmtiBreakpoint::_class_loader, was found by the unhandled oop >>>>> detector. >>>>> >>>>> Instead of registering the oop as an unhandled oop, which would have >>>>> worked, I decided to wrap the oop in a handle as long as it is on the >>>>> stack. >>>>> >>>>> A JvmtiBreakpoint is created on the stack by the two methods >>>>> JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This >>>>> JvmtiBreakpoint is only created to carry the Method*, jlocation >>>>> and oop >>>>> to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, >>>>> when >>>>> at a safepoint, allocate a new JvmtiBreakpoint on the native heap, >>>>> copy >>>>> the values from the stack allocated JvmtiBreakpoint and then >>>>> place/clear the >>>>> newly alloacted JvmtiBreakpoint in >>>>> JvmtiCurrentBreakpoints::_jvmti_breakpoints. >>>>> >>>>> I have updated to the code to check that the public constructor is >>>>> only >>>>> used to allocate JvmtiBreakpoints on the stack (to warn a future >>>>> programmer if he/she decides to allocate one on the heap). The >>>>> class_loader oop is now wrapped in a Handle for stack allocated >>>>> JvmtiBreakpoints. >>>>> >>>>> Due to the stack allocated JvmtiBreakpoint having the oop in a >>>>> handle, >>>>> the oops_do method of VM_ChangeBreakpoints can be removed. This also >>>>> makes the oop in the handle safe for use after the >>>>> VM_ChangeBreakpoint >>>>> operation is finished. >>>>> >>>>> The unhandled oop in the JvmtiBreakpoint allocated on the heap >>>>> will be >>>>> visited by the GC via jvmtiExport::oops_do -> >>>>> JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> >>>>> GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being >>>>> added to. >>>>> >>>>> I've also removed some dead code to simplify the change: >>>>> - GrowableCache::insert >>>>> - JvmtiBreakpoint::copy >>>>> - JvmtiBreakpoint::lessThan >>>>> - GrowableElement::lessThan >>>>> >>>>> Finally, I also formatted JvmtiEnv::ClearBreakpoint and >>>>> Jvmti::SetBreakpoint exactly the same to highlight that they share >>>>> all >>>>> code except one line. Unfortunately, I was not able to remove this >>>>> code >>>>> duplication in a good way. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ >>>> jvmtiImpl.hpp: >>>> Since clone() uses unhandled oops, and is only supposed to be used >>>> by the VM operation, would it make sense to >>>> assert(SafepointSynchronize::is_at_safepoint())? >>>> >>>> 196 GrowableElement *clone() { >>>> 197 return new JvmtiBreakpoint(_method, _bci, >>>> _class_loader_handle); >>>> >>>> jvmtiImpl.cpp: >>>> No comments. >>>> >>>> jvmtiEnv.cpp: >>>> Have you verified that the generated JVMTI entry point contains a >>>> ResourceMark or is it just not needed? >>>> - ResourceMark rm; >>>> + HandleMark hm; >>>> >>>> Otherwise the code change looks good. >>>> >>>> >>>> One thing that you didn't describe here, but which was related to >>>> the bug (which we discussed) was the fact that the old code tried to >>>> "do the right thing" WRT CheckUnhandledOops, but it incorrectly >>>> added a Method*: >>>> >>>> thread->allow_unhandled_oop((oop*)&_method); >>>> >>>> We should take care to find other such places where we try to put a >>>> non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in >>>> the unhandled oops code. >>>> >>>> /Mikael >>>> >>>>> Testing: >>>>> - JPRT >>>>> - The four tests that were failing are now passing >>>>> >>>>> Thanks, >>>>> Erik >>>>> >> From serguei.spitsyn at oracle.com Fri Oct 18 00:58:56 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 18 Oct 2013 00:58:56 -0700 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <5260E22E.1010503@oracle.com> References: <20131016160914.GA10865@ehelin-thinkpad> <525ED138.1000305@oracle.com> <20131017212852.GA6066@ehelin-thinkpad> <5260CBEB.1000902@oracle.com> <5260CF28.2040403@oracle.com> <5260E22E.1010503@oracle.com> Message-ID: <5260EA40.50200@oracle.com> On 10/18/13 12:24 AM, serguei.spitsyn at oracle.com wrote: > On 10/17/13 11:03 PM, David Holmes wrote: >> On 18/10/2013 3:49 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Erik, >>> >>> The fix looks good in general. >>> >>> But one thing is confusing in the fix. >>> Why do you keep both _class_loader and _class_loader_handle in the >>> JvmtiBreakpoint class? >> >> Even more confusing to me is the fact the neither of these seem to >> actually be used anywhere ??? > > Nice catch, David. > I do not see too any of them is really used. > Is it a leftover after the permgen elimination? Maybe this is a rush judging. It depends on the closure->do_oop() that is used for traversing I thought that the KeepAliveClosure is used below (basing on the comment). class JvmtiBreakpoint : public GrowableElement { . . . void oops_do(OopClosure* f) { // Mark the method loader as live f->do_oop(&_class_loader); } This oops_do() is not needed if we have handle instead of oop. > >> >> But if we have the Handle then the oop is redundant AFAICS. > > Right. > The issue is that the oop version is used in the oops_do. > Not sure if we can get rid of oops_do. > It may have an empty body though. Getting rid of the oops_do will require more cleanup that needs to be accurate. Thanks, Serguei > > > Thanks, > Serguei > >> >> David >> >>> Also, you need to run the nsk.jdi.testlist and nsk.jdwp.testlist test >>> suites as well. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/17/13 2:28 PM, Erik Helin wrote: >>>> Hi Mikael and Coleen, >>>> >>>> thanks for your reviews! >>>> >>>> On 2013-10-16, Mikael Gerdin wrote: >>>>> jvmtiImpl.hpp: >>>>> Since clone() uses unhandled oops, and is only supposed to be used >>>>> by the VM operation, would it make sense to >>>>> assert(SafepointSynchronize::is_at_safepoint())? >>>>> >>>>> 196 GrowableElement *clone() { >>>>> 197 return new JvmtiBreakpoint(_method, _bci, >>>>> _class_loader_handle); >>>> Agree, I've updated the patch. A new webrev is located at: >>>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.01/ >>>> >>>> On 2013-10-16, Mikael Gerdin wrote: >>>>> jvmtiEnv.cpp: >>>>> Have you verified that the generated JVMTI entry point contains a >>>>> ResourceMark or is it just not needed? >>>>> - ResourceMark rm; >>>>> + HandleMark hm; >>>> The JVMTI entry point does not contain a ResourceMark. However, I have >>>> verified that a ResourceMark is not needed for jvmtiEnv::SetBreakpoint >>>> nor for jvmtiEnv::ClearBreapoint. The only codes that needs a >>>> ResourceMark is JvmtiBreakpoints::prints, but that method already >>>> has a >>>> ResourceMark. >>>> >>>> On 2013-10-16, Coleen Phillimore wrote: >>>>> Did you run the nsk.jvmti.testlist tests too though? >>>> No, I had not run the nsk.jvmti.testlist test, but I have now :) >>>> >>>> I run both with and without the patch on the latest hsx/hotspot-gc. I >>>> also run with and without -XX:+CheckUnhandledOops. The results were >>>> all >>>> the same: 598 passed an 11 failed (the same tests for all >>>> combinations). >>>> So, the patch does not introduce any regressions for this test suite. >>>> >>>> Thanks, >>>> Erik >>>> >>>> On 2013-10-16, Mikael Gerdin wrote: >>>>> Erik, >>>>> >>>>> (it's not necessary to cross-post between hotspot-dev and >>>>> hotspot-gc-dev, so I removed hotspot-gc from the CC list) >>>>> >>>>> On 2013-10-16 18:09, Erik Helin wrote: >>>>>> Hi all, >>>>>> >>>>>> this patch fixes an issue where an oop in JvmtiBreakpoint, >>>>>> JvmtiBreakpoint::_class_loader, was found by the unhandled oop >>>>>> detector. >>>>>> >>>>>> Instead of registering the oop as an unhandled oop, which would have >>>>>> worked, I decided to wrap the oop in a handle as long as it is on >>>>>> the >>>>>> stack. >>>>>> >>>>>> A JvmtiBreakpoint is created on the stack by the two methods >>>>>> JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This >>>>>> JvmtiBreakpoint is only created to carry the Method*, jlocation >>>>>> and oop >>>>>> to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, >>>>>> when >>>>>> at a safepoint, allocate a new JvmtiBreakpoint on the native >>>>>> heap, copy >>>>>> the values from the stack allocated JvmtiBreakpoint and then >>>>>> place/clear the >>>>>> newly alloacted JvmtiBreakpoint in >>>>>> JvmtiCurrentBreakpoints::_jvmti_breakpoints. >>>>>> >>>>>> I have updated to the code to check that the public constructor >>>>>> is only >>>>>> used to allocate JvmtiBreakpoints on the stack (to warn a future >>>>>> programmer if he/she decides to allocate one on the heap). The >>>>>> class_loader oop is now wrapped in a Handle for stack allocated >>>>>> JvmtiBreakpoints. >>>>>> >>>>>> Due to the stack allocated JvmtiBreakpoint having the oop in a >>>>>> handle, >>>>>> the oops_do method of VM_ChangeBreakpoints can be removed. This also >>>>>> makes the oop in the handle safe for use after the >>>>>> VM_ChangeBreakpoint >>>>>> operation is finished. >>>>>> >>>>>> The unhandled oop in the JvmtiBreakpoint allocated on the heap >>>>>> will be >>>>>> visited by the GC via jvmtiExport::oops_do -> >>>>>> JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> >>>>>> GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is >>>>>> being >>>>>> added to. >>>>>> >>>>>> I've also removed some dead code to simplify the change: >>>>>> - GrowableCache::insert >>>>>> - JvmtiBreakpoint::copy >>>>>> - JvmtiBreakpoint::lessThan >>>>>> - GrowableElement::lessThan >>>>>> >>>>>> Finally, I also formatted JvmtiEnv::ClearBreakpoint and >>>>>> Jvmti::SetBreakpoint exactly the same to highlight that they >>>>>> share all >>>>>> code except one line. Unfortunately, I was not able to remove >>>>>> this code >>>>>> duplication in a good way. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ >>>>> jvmtiImpl.hpp: >>>>> Since clone() uses unhandled oops, and is only supposed to be used >>>>> by the VM operation, would it make sense to >>>>> assert(SafepointSynchronize::is_at_safepoint())? >>>>> >>>>> 196 GrowableElement *clone() { >>>>> 197 return new JvmtiBreakpoint(_method, _bci, >>>>> _class_loader_handle); >>>>> >>>>> jvmtiImpl.cpp: >>>>> No comments. >>>>> >>>>> jvmtiEnv.cpp: >>>>> Have you verified that the generated JVMTI entry point contains a >>>>> ResourceMark or is it just not needed? >>>>> - ResourceMark rm; >>>>> + HandleMark hm; >>>>> >>>>> Otherwise the code change looks good. >>>>> >>>>> >>>>> One thing that you didn't describe here, but which was related to >>>>> the bug (which we discussed) was the fact that the old code tried to >>>>> "do the right thing" WRT CheckUnhandledOops, but it incorrectly >>>>> added a Method*: >>>>> >>>>> thread->allow_unhandled_oop((oop*)&_method); >>>>> >>>>> We should take care to find other such places where we try to put a >>>>> non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in >>>>> the unhandled oops code. >>>>> >>>>> /Mikael >>>>> >>>>>> Testing: >>>>>> - JPRT >>>>>> - The four tests that were failing are now passing >>>>>> >>>>>> Thanks, >>>>>> Erik >>>>>> >>> > From david.holmes at oracle.com Fri Oct 18 01:04:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Oct 2013 18:04:09 +1000 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <5260EA40.50200@oracle.com> References: <20131016160914.GA10865@ehelin-thinkpad> <525ED138.1000305@oracle.com> <20131017212852.GA6066@ehelin-thinkpad> <5260CBEB.1000902@oracle.com> <5260CF28.2040403@oracle.com> <5260E22E.1010503@oracle.com> <5260EA40.50200@oracle.com> Message-ID: <5260EB79.8080401@oracle.com> On 18/10/2013 5:58 PM, serguei.spitsyn at oracle.com wrote: > On 10/18/13 12:24 AM, serguei.spitsyn at oracle.com wrote: >> On 10/17/13 11:03 PM, David Holmes wrote: >>> On 18/10/2013 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Erik, >>>> >>>> The fix looks good in general. >>>> >>>> But one thing is confusing in the fix. >>>> Why do you keep both _class_loader and _class_loader_handle in the >>>> JvmtiBreakpoint class? >>> >>> Even more confusing to me is the fact the neither of these seem to >>> actually be used anywhere ??? >> >> Nice catch, David. >> I do not see too any of them is really used. >> Is it a leftover after the permgen elimination? > > Maybe this is a rush judging. > It depends on the closure->do_oop() that is used for traversing > I thought that the KeepAliveClosure is used below (basing on the comment). > > class JvmtiBreakpoint : public GrowableElement { > . . . > void oops_do(OopClosure* f) { > // Mark the method loader as live > f->do_oop(&_class_loader); > } > > This oops_do() is not needed if we have handle instead of oop. Ah! Maybe the only purpose of keeping the class_loader (whether oop or Handle) is that it is kept alive outside of its normal lifecycle. But still we should only need the Handle or the Oop, not both. And if there is no oop we should not need an oops_do. David > >> >>> >>> But if we have the Handle then the oop is redundant AFAICS. >> >> Right. >> The issue is that the oop version is used in the oops_do. >> Not sure if we can get rid of oops_do. >> It may have an empty body though. > > Getting rid of the oops_do will require more cleanup that needs to be > accurate. > > > Thanks, > Serguei > >> >> >> Thanks, >> Serguei >> >>> >>> David >>> >>>> Also, you need to run the nsk.jdi.testlist and nsk.jdwp.testlist test >>>> suites as well. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 10/17/13 2:28 PM, Erik Helin wrote: >>>>> Hi Mikael and Coleen, >>>>> >>>>> thanks for your reviews! >>>>> >>>>> On 2013-10-16, Mikael Gerdin wrote: >>>>>> jvmtiImpl.hpp: >>>>>> Since clone() uses unhandled oops, and is only supposed to be used >>>>>> by the VM operation, would it make sense to >>>>>> assert(SafepointSynchronize::is_at_safepoint())? >>>>>> >>>>>> 196 GrowableElement *clone() { >>>>>> 197 return new JvmtiBreakpoint(_method, _bci, >>>>>> _class_loader_handle); >>>>> Agree, I've updated the patch. A new webrev is located at: >>>>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.01/ >>>>> >>>>> On 2013-10-16, Mikael Gerdin wrote: >>>>>> jvmtiEnv.cpp: >>>>>> Have you verified that the generated JVMTI entry point contains a >>>>>> ResourceMark or is it just not needed? >>>>>> - ResourceMark rm; >>>>>> + HandleMark hm; >>>>> The JVMTI entry point does not contain a ResourceMark. However, I have >>>>> verified that a ResourceMark is not needed for jvmtiEnv::SetBreakpoint >>>>> nor for jvmtiEnv::ClearBreapoint. The only codes that needs a >>>>> ResourceMark is JvmtiBreakpoints::prints, but that method already >>>>> has a >>>>> ResourceMark. >>>>> >>>>> On 2013-10-16, Coleen Phillimore wrote: >>>>>> Did you run the nsk.jvmti.testlist tests too though? >>>>> No, I had not run the nsk.jvmti.testlist test, but I have now :) >>>>> >>>>> I run both with and without the patch on the latest hsx/hotspot-gc. I >>>>> also run with and without -XX:+CheckUnhandledOops. The results were >>>>> all >>>>> the same: 598 passed an 11 failed (the same tests for all >>>>> combinations). >>>>> So, the patch does not introduce any regressions for this test suite. >>>>> >>>>> Thanks, >>>>> Erik >>>>> >>>>> On 2013-10-16, Mikael Gerdin wrote: >>>>>> Erik, >>>>>> >>>>>> (it's not necessary to cross-post between hotspot-dev and >>>>>> hotspot-gc-dev, so I removed hotspot-gc from the CC list) >>>>>> >>>>>> On 2013-10-16 18:09, Erik Helin wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> this patch fixes an issue where an oop in JvmtiBreakpoint, >>>>>>> JvmtiBreakpoint::_class_loader, was found by the unhandled oop >>>>>>> detector. >>>>>>> >>>>>>> Instead of registering the oop as an unhandled oop, which would have >>>>>>> worked, I decided to wrap the oop in a handle as long as it is on >>>>>>> the >>>>>>> stack. >>>>>>> >>>>>>> A JvmtiBreakpoint is created on the stack by the two methods >>>>>>> JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This >>>>>>> JvmtiBreakpoint is only created to carry the Method*, jlocation >>>>>>> and oop >>>>>>> to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, >>>>>>> when >>>>>>> at a safepoint, allocate a new JvmtiBreakpoint on the native >>>>>>> heap, copy >>>>>>> the values from the stack allocated JvmtiBreakpoint and then >>>>>>> place/clear the >>>>>>> newly alloacted JvmtiBreakpoint in >>>>>>> JvmtiCurrentBreakpoints::_jvmti_breakpoints. >>>>>>> >>>>>>> I have updated to the code to check that the public constructor >>>>>>> is only >>>>>>> used to allocate JvmtiBreakpoints on the stack (to warn a future >>>>>>> programmer if he/she decides to allocate one on the heap). The >>>>>>> class_loader oop is now wrapped in a Handle for stack allocated >>>>>>> JvmtiBreakpoints. >>>>>>> >>>>>>> Due to the stack allocated JvmtiBreakpoint having the oop in a >>>>>>> handle, >>>>>>> the oops_do method of VM_ChangeBreakpoints can be removed. This also >>>>>>> makes the oop in the handle safe for use after the >>>>>>> VM_ChangeBreakpoint >>>>>>> operation is finished. >>>>>>> >>>>>>> The unhandled oop in the JvmtiBreakpoint allocated on the heap >>>>>>> will be >>>>>>> visited by the GC via jvmtiExport::oops_do -> >>>>>>> JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> >>>>>>> GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is >>>>>>> being >>>>>>> added to. >>>>>>> >>>>>>> I've also removed some dead code to simplify the change: >>>>>>> - GrowableCache::insert >>>>>>> - JvmtiBreakpoint::copy >>>>>>> - JvmtiBreakpoint::lessThan >>>>>>> - GrowableElement::lessThan >>>>>>> >>>>>>> Finally, I also formatted JvmtiEnv::ClearBreakpoint and >>>>>>> Jvmti::SetBreakpoint exactly the same to highlight that they >>>>>>> share all >>>>>>> code except one line. Unfortunately, I was not able to remove >>>>>>> this code >>>>>>> duplication in a good way. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ >>>>>> jvmtiImpl.hpp: >>>>>> Since clone() uses unhandled oops, and is only supposed to be used >>>>>> by the VM operation, would it make sense to >>>>>> assert(SafepointSynchronize::is_at_safepoint())? >>>>>> >>>>>> 196 GrowableElement *clone() { >>>>>> 197 return new JvmtiBreakpoint(_method, _bci, >>>>>> _class_loader_handle); >>>>>> >>>>>> jvmtiImpl.cpp: >>>>>> No comments. >>>>>> >>>>>> jvmtiEnv.cpp: >>>>>> Have you verified that the generated JVMTI entry point contains a >>>>>> ResourceMark or is it just not needed? >>>>>> - ResourceMark rm; >>>>>> + HandleMark hm; >>>>>> >>>>>> Otherwise the code change looks good. >>>>>> >>>>>> >>>>>> One thing that you didn't describe here, but which was related to >>>>>> the bug (which we discussed) was the fact that the old code tried to >>>>>> "do the right thing" WRT CheckUnhandledOops, but it incorrectly >>>>>> added a Method*: >>>>>> >>>>>> thread->allow_unhandled_oop((oop*)&_method); >>>>>> >>>>>> We should take care to find other such places where we try to put a >>>>>> non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in >>>>>> the unhandled oops code. >>>>>> >>>>>> /Mikael >>>>>> >>>>>>> Testing: >>>>>>> - JPRT >>>>>>> - The four tests that were failing are now passing >>>>>>> >>>>>>> Thanks, >>>>>>> Erik >>>>>>> >>>> >> > From stefan.karlsson at oracle.com Fri Oct 18 01:29:09 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 18 Oct 2013 10:29:09 +0200 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <20131016160914.GA10865@ehelin-thinkpad> References: <20131016160914.GA10865@ehelin-thinkpad> Message-ID: <5260F155.4000107@oracle.com> On 2013-10-16 18:09, Erik Helin wrote: > Hi all, > > this patch fixes an issue where an oop in JvmtiBreakpoint, > JvmtiBreakpoint::_class_loader, was found by the unhandled oop detector. > > Instead of registering the oop as an unhandled oop, which would have > worked, I decided to wrap the oop in a handle as long as it is on the > stack. > > A JvmtiBreakpoint is created on the stack by the two methods > JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This > JvmtiBreakpoint is only created to carry the Method*, jlocation and oop > to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, when > at a safepoint, allocate a new JvmtiBreakpoint on the native heap, copy > the values from the stack allocated JvmtiBreakpoint and then place/clear the > newly alloacted JvmtiBreakpoint in > JvmtiCurrentBreakpoints::_jvmti_breakpoints. > > I have updated to the code to check that the public constructor is only > used to allocate JvmtiBreakpoints on the stack (to warn a future > programmer if he/she decides to allocate one on the heap). The > class_loader oop is now wrapped in a Handle for stack allocated > JvmtiBreakpoints. > > Due to the stack allocated JvmtiBreakpoint having the oop in a handle, > the oops_do method of VM_ChangeBreakpoints can be removed. This also > makes the oop in the handle safe for use after the VM_ChangeBreakpoint > operation is finished. > > The unhandled oop in the JvmtiBreakpoint allocated on the heap will be > visited by the GC via jvmtiExport::oops_do -> > JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> > GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is being > added to. > > I've also removed some dead code to simplify the change: > - GrowableCache::insert > - JvmtiBreakpoint::copy > - JvmtiBreakpoint::lessThan > - GrowableElement::lessThan > > Finally, I also formatted JvmtiEnv::ClearBreakpoint and > Jvmti::SetBreakpoint exactly the same to highlight that they share all > code except one line. Unfortunately, I was not able to remove this code > duplication in a good way. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ Not a review. I think there's a pre-existing bug in this code. Registering the class loader as a way to keep the Klass alive will not work for breakpoints in Anonymous Classes (JSR292). Anonymous classes have to register the mirror. See the code in the ClassLoaderData::is_alive: bool ClassLoaderData::is_alive(BoolObjectClosure* is_alive_closure) const { bool alive = is_anonymous() ? is_alive_closure->do_object_b(_klasses->java_mirror()) : class_loader() == NULL || is_alive_closure->do_object_b(class_loader()); assert(!alive || claimed(), "must be claimed"); return alive; } We probably want to add a function ClassLoaderData::keep_alive_oop() which returns the class loader for normal classes and the mirror for the anonymous classes, and use that in this and similar situations. StefanK > > Testing: > - JPRT > - The four tests that were failing are now passing > > Thanks, > Erik From staffan.larsen at oracle.com Fri Oct 18 01:37:16 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 18 Oct 2013 10:37:16 +0200 Subject: RFR: 8021897 EXCEPTION_ACCESS_VIOLATION on debugging String.contentEquals() Message-ID: This is a continuation of a review from the hotspot repo: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-October/009657.html The hotspot fix has now reached JDK8-TL so I can now push the test and JDK fix. The problem has to do with stepping into the String constructor and asking to see the value of the String. JDWP does this via GetStringUTFChars which crashed if the String didn't have a value field. That call now returns NULL and needs to be checked in JDWP. I have also added a test that breakpoints in String's constructor and verifies that it is ok to get the value of the String. webrev: http://cr.openjdk.java.net/~sla/8021897/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8021897 Thanks, /Staffan From serguei.spitsyn at oracle.com Fri Oct 18 02:23:22 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 18 Oct 2013 02:23:22 -0700 Subject: RFR: 8021897 EXCEPTION_ACCESS_VIOLATION on debugging String.contentEquals() In-Reply-To: References: Message-ID: <5260FE0A.1040901@oracle.com> Staffan, It looks good. A minor suggestion is to initialize length here: jint length = string != NULL ? (int)strlen(string) : 0; Thanks, Serguei On 10/18/13 1:37 AM, Staffan Larsen wrote: > This is a continuation of a review from the hotspot repo: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-October/009657.html The hotspot fix has now reached JDK8-TL so I can now push the test and JDK fix. > > The problem has to do with stepping into the String constructor and asking to see the value of the String. JDWP does this via GetStringUTFChars which crashed if the String didn't have a value field. That call now returns NULL and needs to be checked in JDWP. > > I have also added a test that breakpoints in String's constructor and verifies that it is ok to get the value of the String. > > webrev: http://cr.openjdk.java.net/~sla/8021897/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8021897 > > Thanks, > /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131018/d4147176/attachment.html From Alan.Bateman at oracle.com Fri Oct 18 02:37:39 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 Oct 2013 10:37:39 +0100 Subject: RFR: 8021897 EXCEPTION_ACCESS_VIOLATION on debugging String.contentEquals() In-Reply-To: References: Message-ID: <52610163.8050401@oracle.com> On 18/10/2013 09:37, Staffan Larsen wrote: > This is a continuation of a review from the hotspot repo: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-October/009657.html The hotspot fix has now reached JDK8-TL so I can now push the test and JDK fix. > > The problem has to do with stepping into the String constructor and asking to see the value of the String. JDWP does this via GetStringUTFChars which crashed if the String didn't have a value field. That call now returns NULL and needs to be checked in JDWP. > > I have also added a test that breakpoints in String's constructor and verifies that it is ok to get the value of the String. > > webrev: http://cr.openjdk.java.net/~sla/8021897/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8021897 > > Thanks, > /Staffan This looks okay to me. -Alan. From staffan.larsen at oracle.com Fri Oct 18 02:52:06 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 18 Oct 2013 11:52:06 +0200 Subject: RFR: 8021897 EXCEPTION_ACCESS_VIOLATION on debugging String.contentEquals() In-Reply-To: <5260FE0A.1040901@oracle.com> References: <5260FE0A.1040901@oracle.com> Message-ID: <32985807-955C-47D3-A8B3-3B1BD30E9407@oracle.com> Alan, Serguei: Thanks for the reviews! I updated the fix with Serguei's comment and will push this version: http://cr.openjdk.java.net/~sla/8021897/webrev.01/ /Staffan On 18 okt 2013, at 11:23, serguei.spitsyn at oracle.com wrote: > Staffan, > > It looks good. > A minor suggestion is to initialize length here: > jint length = string != NULL ? (int)strlen(string) : 0; > > Thanks, > Serguei > > > On 10/18/13 1:37 AM, Staffan Larsen wrote: >> This is a continuation of a review from the hotspot repo: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-October/009657.html The hotspot fix has now reached JDK8-TL so I can now push the test and JDK fix. >> >> The problem has to do with stepping into the String constructor and asking to see the value of the String. JDWP does this via GetStringUTFChars which crashed if the String didn't have a value field. That call now returns NULL and needs to be checked in JDWP. >> >> I have also added a test that breakpoints in String's constructor and verifies that it is ok to get the value of the String. >> >> webrev: http://cr.openjdk.java.net/~sla/8021897/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8021897 >> >> Thanks, >> /Staffan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131018/73867c57/attachment-0001.html From Alan.Bateman at oracle.com Fri Oct 18 03:01:48 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 Oct 2013 11:01:48 +0100 Subject: 8008662: Add @jdk.Exported to JDK-specific/exported APIs In-Reply-To: <1898888421.8989993.1382037930696.JavaMail.root@redhat.com> References: <5251C216.105@oracle.com> <1898888421.8989993.1382037930696.JavaMail.root@redhat.com> Message-ID: <5261070C.60408@oracle.com> On 17/10/2013 20:25, Andrew wrote: > : > > Is the intention for these 'exported' APIs to be eventually replaced by proper > parts of the specification (i.e. java.* or javax.*). I'm not keen on the idea > of encouraging the use of APIs that are only in this implementation of the JDK. Just to add to Mandy's comments, the boat debated a long time ago on some of these. For example the Java Debug Interface (JDI) was in Sun's JDK 1.2 (1998). Since then almost every IDE has been using it (I think Eclipse might have their own implementation). Looking back then maybe it should have been standardized a long time ago but it's not clear that it's worth doing now. The HTTP server API has its own story. As I recall (and my memory is a bit hazy) then there wasn't agreement to include it as part of Java SE 6 and it had to be moved to a com.sun.net package so that it could be used for the web services APIs. The history on SCTP is that it was still an IEFT draft at the time and that it would have been too premature to attempt to standardize an API. So the decision was to start out with a com.sun API and get experience with it before re-visiting in the future to see if there is strong need to define a standard API. -Alan. From serguei.spitsyn at oracle.com Fri Oct 18 03:39:18 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 18 Oct 2013 03:39:18 -0700 Subject: RFR (S): JDK-8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes In-Reply-To: <525FEE10.9030508@oracle.com> References: <5249643F.3030209@oracle.com> <524A7B07.1000300@oracle.com> <524BE733.2070205@oracle.com> <525CF1F1.1010400@oracle.com> <525FEE10.9030508@oracle.com> Message-ID: <52610FD6.8000002@oracle.com> Hi Fredrik, I like this approach in general but am still looking into some details. There is also one concern from Coleen about the anonymous classes: they appear in the CLDG/CLD partially initialized. For details, look at the function SystemDictionary::parse_stream() that is called from the Unsafe_DefineAnonymousClass_impl(). Thanks, Serguei On 10/17/13 7:02 AM, Fredrik Arvidsson wrote: > Hi > > I have added a new revision of my changes here: > http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.02/ > > > The idea is to use a lock called metaspace_lock available inside the > ClassLoaderData objects that the ClassLoaderDataGraph holds, this > prevents classes to be added/removed/updated during the gathering > phase. When iterating using the new LoadedClassesClosure > implementation only array classes and instance classes that are marked > as loaded will be visited. The LoadedClassesClosure implementation > uses a Stack to store classes during the gathering phase. This > changes the count-allocate-add-extract approach that was used before > into a add-extract way of doing it instead. > > I am still not sure how to do with the GetClassLoaderClasses to make > it consistent. I would eventually like to get rid of the > JvmtiGetLoadedClassesClosure and the use of the SystemDictionary if > possible. But right now I just cant see how to get hold of the > initiating loader for a class without using the SystemDictionary. > > /Fredrik > > On 2013-10-15 09:42, serguei.spitsyn at oracle.com wrote: >> >> There are two questions on the list that we still need to resolve in >> this fix: >> (1) What is the best way to protect the work with CLDG from >> concurrent additions of CLD's to it >> (2) The *GetClassLoaderClasses* needs a fix as well to be consistent >> with the GetLoadedClasses >> >> I had some private conversations with Fredrik and John Rose and >> after some analysis came up with the suggestion: >> >> (1) Continue using the *SystemDictionary_lock* to protect >> consistency of the loaded classes data. >> The issue is that adding CLD's to the SLDG is not currently >> protected by the *SystemDictionary_lock*. >> I'm suggesting to add it to the >> *SystemDictionary::parse_stream* (please, see the webrev below). >> >> (2) There was some doubt that a similar fix for the >> *GetClassLoaderClasses* is needed because >> the CL+SD (taken from the host class) does not reference the >> associated anonymous classes. >> The question is: Can we consider the host's class CL as the >> initiating CL? >> My reading is that the answer to this question is: "Yes, we can". >> Even though the CL itself does not have references to its >> anonymous classes, >> there are references from the anonymous classes's CLD's to its CL. >> These references can be used in the *increment_with_loader* >> and *add_with_loader* >> the same way as it was before. >> >> This is a webrev that includes the Fredrik's fix as a base plus the >> implemented suggestion: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/fredrik/8024423-JVMTI-ANO/ >> >> Some help from the HotSpot team is needed to estimate if this >> approach is Ok and does not have rat holes in it. >> Opinions are very welcome. >> >> Thanks, >> Serguei >> >> >> On 10/2/13 2:28 AM, Fredrik Arvidsson wrote: >>> Hi and thanks for all your comments. >>> >>> I have simplified the code in *instanceKlass.cpp* like suggested and >>> here is a new webrev: >>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.01/ >>> >>> >>> Regarding the need to synchronize the access to ClassLoaderDataGraph >>> I have come to the conclusion that it should be safe to call this >>> without any additional synchronization since newly loaded and added >>> classes are appended to the end of its 'list' of classes. This would >>> mean that the call could 'miss' the classes added during the >>> collection phase, but this is not a big issue. I hope that my >>> conclusion is correct. >>> >>> I believe that the JvmtiGetLoadedClasses::getClassLoaderClasses(...) >>> method is to be left alone this time since I got the impression that >>> only SystemDictionary 'knows' about initiating class loaders. >>> >>> There is plenty of room for improvement and simplification of much >>> of the code in this area, but I feel that it must wait until another >>> time. The task to re-factor and simplify would quickly grow out of >>> hands I'm afraid :) >>> >>> Cheers >>> /Fredrik >>> >>> On 2013-10-01 09:34, serguei.spitsyn at oracle.com wrote: >>>> Hi Frederik, >>>> >>>> >>>> Thank you for jumping on this issue! >>>> >>>> >>>> *src/share/vm/oops/instanceKlass.cpp* >>>> 2333 int src_index = 0; >>>> 2334 while (src_index < src_length) { >>>> 2335 dest[dest_index++] = src[src_index++]; >>>> 2336 } >>>> 2337 >>>> 2338 // If we have a hash, append it >>>> 2339 if(hash_len > 0) { >>>> 2340 int hash_index = 0; >>>> 2341 while (hash_index < hash_len) { >>>> 2342 dest[dest_index++] = hash_buf[hash_index++]; >>>> 2343 } >>>> 2344 } >>>> >>>> The above can be simplified a little bit: >>>> // Add the actual class name >>>> for (int src_index = 0; src_index < src_length; ) { >>>> dest[dest_index++] = src[src_index++]; >>>> } >>>> // If we have a hash, append it >>>> for (int hash_index = 0; hash_index < hash_len; ) { >>>> dest[dest_index++] = hash_buf[hash_index++]; >>>> } >>>> >>>> The conditionif(hash_len > 0) is covered by the loop itself. >>>> >>>> Style-related comments: >>>> -wrong indent at the lines: 2316-2319 >>>> - need a space after the 'if' at the lines: 2315, 2339 >>>> >>>> >>>> *src/share/vm/prims/jvmtiGetLoadedClasses.cpp >>>> >>>> *The copyright comment must be up-to-date. >>>> The comments at the lines 35-38, 258-260 are not valid anymore. >>>> >>>> >>>> > In this review I still have an outstanding unanswered question about >>>> > the need to synchronize the access to the: >>>> >>>> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >>>> > and >>>> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >>>> >>>> This kind of walking is usually done at safepoint in a VM_Operation. >>>> You will find many examples in the jvmtiEnv.cpp, for instance, VM_GetAllStackTraces. >>>> The suggestion from Mikael is good too. >>>> >>>> Should this fix include the getClassLoaderClasses() as well? >>>> I'm still trying to realize the impact and consistency of this fix. :( >>>> >>>> What tests are you going to run for verification? >>>> >>>> Thanks, >>>> Serguei >>>> * >>>> *On 9/30/13 4:45 AM, Fredrik Arvidsson wrote: >>>>> Hi >>>>> >>>>> Please help me to review the changes below: >>>>> >>>>> Jira case: https://bugs.openjdk.java.net/browse/JDK-8024423 >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/ >>>>> >>>>> >>>>> In this review I still have an outstanding unanswered question >>>>> about the need to synchronize the access to the: >>>>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >>>>> and >>>>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >>>>> >>>>> calls in >>>>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/src/share/vm/prims/jvmtiGetLoadedClasses.cpp.udiff.html >>>>> >>>>> Please give me advise on this. >>>>> >>>>> There will be a review soon regarding re-enabling the tests that failed because of the above bug, see: >>>>> https://bugs.openjdk.java.net/browse/JDK-8025576 >>>>> >>>>> Cheers >>>>> /Fredrik >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131018/56a218b0/attachment.html From staffan.larsen at oracle.com Fri Oct 18 03:56:23 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 18 Oct 2013 12:56:23 +0200 Subject: RFR: 8009681: TEST_BUG: MethodExitReturnValuesTest.java fails with when there are unexpected background threads In-Reply-To: <525E80C5.6040802@oracle.com> References: <516E9DB9.8020009@oracle.com> <62E7E237-46A6-46A7-8682-BE332F296F3D@oracle.com> <525E80C5.6040802@oracle.com> Message-ID: <848A2E80-1793-4C2B-AD20-EA1E473B1820@oracle.com> Looks good! Thanks, /Staffan On 16 okt 2013, at 14:04, Mikael Auno wrote: > This bug got a bit lost from my radar after vacation, but I've picked it > again now. I've moved Arrays.asList() as suggested. In further testing of the fix though, I found that the include list is not enough, as one of the expected method exit events is from String.intern(), which might also be called from background threads. To counter this, I added a thread filter to the events. This also has the added benefit of speeding up the test significantly (from 90 seconds to about 5 seconds) in the cases where there are background threads interfering. > > Also added to this webrev is a fix for MethodEntryExitEvents.java which had exactly the same problem and a similar test design as MethodExitReturnValuesTest.java. > > The updated webrev is at http://cr.openjdk.java.net/~allwin/auno/8009681/webrev.00/. > > Thanks, > Mikael > > On 2013-05-28 08:46, Staffan Larsen wrote: >> Looks good. >> >> You could optimize it a bit by not doing the Arrays.asList() on every >> methodExit event. >> >> /Staffan >> >> On 17 apr 2013, at 15:03, Mikael Auno >> wrote: >> >>> Hi, I'd like some reviews on >>> http://cr.openjdk.java.net/~nloodin/8009681/webrev.01/ for >>> JDK-8009681 (http://bugs.sun.com/view_bug.do?bug_id=8009681). >>> >>> The issue here is that when MethodExitReturnValuesTest hooks into >>> MethodExit events through JDI it uses an exclude list to filter out >>> classes from which it is not interested in these events. This is >>> bound to break over and over again as new features are added to the >>> JDK. I've changed the test to use an include list instead, >>> containing only the handful of classes the test is actually >>> interested in. >>> >>> Thanks, > >> Mikael >> > From erik.helin at oracle.com Fri Oct 18 03:56:44 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 18 Oct 2013 12:56:44 +0200 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <5260EB79.8080401@oracle.com> References: <20131016160914.GA10865@ehelin-thinkpad> <525ED138.1000305@oracle.com> <20131017212852.GA6066@ehelin-thinkpad> <5260CBEB.1000902@oracle.com> <5260CF28.2040403@oracle.com> <5260E22E.1010503@oracle.com> <5260EA40.50200@oracle.com> <5260EB79.8080401@oracle.com> Message-ID: <20131018105644.GA2408@ehelin-thinkpad> Hi David and Serguei, thanks for having a look at this change! On 2013-10-18, David Holmes wrote: > On 18/10/2013 5:58 PM, serguei.spitsyn at oracle.com wrote: > >On 10/18/13 12:24 AM, serguei.spitsyn at oracle.com wrote: > >>On 10/17/13 11:03 PM, David Holmes wrote: > >>>On 18/10/2013 3:49 PM, serguei.spitsyn at oracle.com wrote: > >>>>Hi Erik, > >>>> > >>>>The fix looks good in general. > >>>> > >>>>But one thing is confusing in the fix. > >>>>Why do you keep both _class_loader and _class_loader_handle in the > >>>>JvmtiBreakpoint class? > >>> > >>>Even more confusing to me is the fact the neither of these seem to > >>>actually be used anywhere ??? > >> > >>Nice catch, David. > >>I do not see too any of them is really used. > >>Is it a leftover after the permgen elimination? > > > >Maybe this is a rush judging. > >It depends on the closure->do_oop() that is used for traversing > >I thought that the KeepAliveClosure is used below (basing on the comment). > > > >class JvmtiBreakpoint : public GrowableElement { > > . . . > > void oops_do(OopClosure* f) { > > // Mark the method loader as live > > f->do_oop(&_class_loader); > > } > > > >This oops_do() is not needed if we have handle instead of oop. > > Ah! Maybe the only purpose of keeping the class_loader (whether oop > or Handle) is that it is kept alive outside of its normal lifecycle. > > But still we should only need the Handle or the Oop, not both. And > if there is no oop we should not need an oops_do. I will try to explain the problem, the current implementation and then my change. The problem ----------- The problem is that JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint are passed a Method*. We must ensure that the class for this Method is kept alive by the GC. We do this by informing the GC that it must visit the class loader for the Method's class when marking. This can be done in two ways: - Putting a Handle on the stack containing an oop to the class loader - Have an oops_do method that we ensure will be called by the GC during marking A third option is to make sure (by inspecting the code) that no GC can occur that might cause problems, but this is a very brittle solution once a new programmer comes along and adds/removes code. The current implementation -------------------------- In JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint, we create a JvmtiBreakpoint on the stack. This JvmtiBreakpoint contains an "unhandled" oop to the class loader of the Method's class. A pointer to the JvmtiBreakpoint allocated on the stack will be passed to VM_ChangeBreakpoint via JvmtiBreakpoints::set/clear. In the doit() method of VM_ChangeBreakpoint, JvmtiBreakpoints::set_at_safepoint will be called. A new JvmtiBreakpoint will be allocated on the heap by JvmtiBreakpoints::set_at_safepoint. The JvmtiBreakpoint on the heap will contain the same oop as the one in the JvmtiBreakpoint allocated on the stack earlier. The oop in the JvmtiBreakpoint allocated on the heap will be found by the GC, because VM_ChangeBreakpoint has an oops_do method (see first email for how this oops_do method is called). Once the VM_ChangeBreakpoint operation is done, then the JvmtiBreakpoint allocated on the heap will either be cleared due to a clear operation (and we do not care about the oop any longer) or it will be placed in JvmtiBreakpoints. JvmtiBreakpoints also has an oops_do which ensures that the oop now will be found by the GC. We will now pop the call stack and return to JvmtiEnv::SetBreakpoint or JvmtiEnv::ClearBreakpoint. No code in JvmtiEnv::SetBreakpoint or JvmtiEnv::ClearBreakpoint is touching the JvmtiBreakpoint after the VM_ChangeBreakpoint operation has been run. Furthermore, no GC can today occur before the call to VMThread::execute in JvmtiBreakpoints::set/clear. This means that the current implementation is safe, but understanding this is quite tricky. The change ---------- My proposed solution was the following: - When a JvmtiBreakpoint is allocated on the stack, place an oop to the Method's class loader in a Handle. - When a JvmtiBreakpoint is allocated on the heap, just store the oop to Method's class lodear in a field. The JvmtiBreakpoint will be placed in _jvmti_breakpoints which will be visited by the GC, which makes the GC call JvmtiBreakpoint::oops_do. Of course, this means that that if a GC occurs before the JvmtiBreakpoint in constructed in JvmtiEnv::SetBreakpoint or JvmtiEnv::ClearBreakpoint, the Method's class might be garbage collected. Ideally, we should wrap the Method* in jvmti_SetBreakpoint and jvmti_ClearBreakpoint in jvmtiEnter.cpp (a cpp file generated from an XML file via an XSL tranformation). As icing on the cake, if someone redefines the method that we are receiving a pointer to, then this code will probably not work at all. I believe (I am not sure) that this should be solved by having a MethodHandle wrapping the Method*. This change is just a first step towards safer code. I've gotten feedback internally that it is hard to understand the new code. I will try to see if I can update the change to make this clearer. Thanks for getting all the way to the end of this email :) Erik > David > > > > >> > >>> > >>>But if we have the Handle then the oop is redundant AFAICS. > >> > >>Right. > >>The issue is that the oop version is used in the oops_do. > >>Not sure if we can get rid of oops_do. > >>It may have an empty body though. > > > >Getting rid of the oops_do will require more cleanup that needs to be > >accurate. > > > > > >Thanks, > >Serguei > > > >> > >> > >>Thanks, > >>Serguei > >> > >>> > >>>David > >>> > >>>>Also, you need to run the nsk.jdi.testlist and nsk.jdwp.testlist test > >>>>suites as well. > >>>> > >>>>Thanks, > >>>>Serguei > >>>> > >>>> > >>>>On 10/17/13 2:28 PM, Erik Helin wrote: > >>>>>Hi Mikael and Coleen, > >>>>> > >>>>>thanks for your reviews! > >>>>> > >>>>>On 2013-10-16, Mikael Gerdin wrote: > >>>>>>jvmtiImpl.hpp: > >>>>>>Since clone() uses unhandled oops, and is only supposed to be used > >>>>>>by the VM operation, would it make sense to > >>>>>>assert(SafepointSynchronize::is_at_safepoint())? > >>>>>> > >>>>>>196 GrowableElement *clone() { > >>>>>> 197 return new JvmtiBreakpoint(_method, _bci, > >>>>>>_class_loader_handle); > >>>>>Agree, I've updated the patch. A new webrev is located at: > >>>>>http://cr.openjdk.java.net/~ehelin/8025834/webrev.01/ > >>>>> > >>>>>On 2013-10-16, Mikael Gerdin wrote: > >>>>>>jvmtiEnv.cpp: > >>>>>>Have you verified that the generated JVMTI entry point contains a > >>>>>>ResourceMark or is it just not needed? > >>>>>>- ResourceMark rm; > >>>>>>+ HandleMark hm; > >>>>>The JVMTI entry point does not contain a ResourceMark. However, I have > >>>>>verified that a ResourceMark is not needed for jvmtiEnv::SetBreakpoint > >>>>>nor for jvmtiEnv::ClearBreapoint. The only codes that needs a > >>>>>ResourceMark is JvmtiBreakpoints::prints, but that method already > >>>>>has a > >>>>>ResourceMark. > >>>>> > >>>>>On 2013-10-16, Coleen Phillimore wrote: > >>>>>>Did you run the nsk.jvmti.testlist tests too though? > >>>>>No, I had not run the nsk.jvmti.testlist test, but I have now :) > >>>>> > >>>>>I run both with and without the patch on the latest hsx/hotspot-gc. I > >>>>>also run with and without -XX:+CheckUnhandledOops. The results were > >>>>>all > >>>>>the same: 598 passed an 11 failed (the same tests for all > >>>>>combinations). > >>>>>So, the patch does not introduce any regressions for this test suite. > >>>>> > >>>>>Thanks, > >>>>>Erik > >>>>> > >>>>>On 2013-10-16, Mikael Gerdin wrote: > >>>>>>Erik, > >>>>>> > >>>>>>(it's not necessary to cross-post between hotspot-dev and > >>>>>>hotspot-gc-dev, so I removed hotspot-gc from the CC list) > >>>>>> > >>>>>>On 2013-10-16 18:09, Erik Helin wrote: > >>>>>>>Hi all, > >>>>>>> > >>>>>>>this patch fixes an issue where an oop in JvmtiBreakpoint, > >>>>>>>JvmtiBreakpoint::_class_loader, was found by the unhandled oop > >>>>>>>detector. > >>>>>>> > >>>>>>>Instead of registering the oop as an unhandled oop, which would have > >>>>>>>worked, I decided to wrap the oop in a handle as long as it is on > >>>>>>>the > >>>>>>>stack. > >>>>>>> > >>>>>>>A JvmtiBreakpoint is created on the stack by the two methods > >>>>>>>JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This > >>>>>>>JvmtiBreakpoint is only created to carry the Method*, jlocation > >>>>>>>and oop > >>>>>>>to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, > >>>>>>>when > >>>>>>>at a safepoint, allocate a new JvmtiBreakpoint on the native > >>>>>>>heap, copy > >>>>>>>the values from the stack allocated JvmtiBreakpoint and then > >>>>>>>place/clear the > >>>>>>>newly alloacted JvmtiBreakpoint in > >>>>>>>JvmtiCurrentBreakpoints::_jvmti_breakpoints. > >>>>>>> > >>>>>>>I have updated to the code to check that the public constructor > >>>>>>>is only > >>>>>>>used to allocate JvmtiBreakpoints on the stack (to warn a future > >>>>>>>programmer if he/she decides to allocate one on the heap). The > >>>>>>>class_loader oop is now wrapped in a Handle for stack allocated > >>>>>>>JvmtiBreakpoints. > >>>>>>> > >>>>>>>Due to the stack allocated JvmtiBreakpoint having the oop in a > >>>>>>>handle, > >>>>>>>the oops_do method of VM_ChangeBreakpoints can be removed. This also > >>>>>>>makes the oop in the handle safe for use after the > >>>>>>>VM_ChangeBreakpoint > >>>>>>>operation is finished. > >>>>>>> > >>>>>>>The unhandled oop in the JvmtiBreakpoint allocated on the heap > >>>>>>>will be > >>>>>>>visited by the GC via jvmtiExport::oops_do -> > >>>>>>>JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> > >>>>>>>GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is > >>>>>>>being > >>>>>>>added to. > >>>>>>> > >>>>>>>I've also removed some dead code to simplify the change: > >>>>>>>- GrowableCache::insert > >>>>>>>- JvmtiBreakpoint::copy > >>>>>>>- JvmtiBreakpoint::lessThan > >>>>>>>- GrowableElement::lessThan > >>>>>>> > >>>>>>>Finally, I also formatted JvmtiEnv::ClearBreakpoint and > >>>>>>>Jvmti::SetBreakpoint exactly the same to highlight that they > >>>>>>>share all > >>>>>>>code except one line. Unfortunately, I was not able to remove > >>>>>>>this code > >>>>>>>duplication in a good way. > >>>>>>> > >>>>>>>Webrev: > >>>>>>>http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ > >>>>>>jvmtiImpl.hpp: > >>>>>>Since clone() uses unhandled oops, and is only supposed to be used > >>>>>>by the VM operation, would it make sense to > >>>>>>assert(SafepointSynchronize::is_at_safepoint())? > >>>>>> > >>>>>>196 GrowableElement *clone() { > >>>>>> 197 return new JvmtiBreakpoint(_method, _bci, > >>>>>>_class_loader_handle); > >>>>>> > >>>>>>jvmtiImpl.cpp: > >>>>>>No comments. > >>>>>> > >>>>>>jvmtiEnv.cpp: > >>>>>>Have you verified that the generated JVMTI entry point contains a > >>>>>>ResourceMark or is it just not needed? > >>>>>>- ResourceMark rm; > >>>>>>+ HandleMark hm; > >>>>>> > >>>>>>Otherwise the code change looks good. > >>>>>> > >>>>>> > >>>>>>One thing that you didn't describe here, but which was related to > >>>>>>the bug (which we discussed) was the fact that the old code tried to > >>>>>>"do the right thing" WRT CheckUnhandledOops, but it incorrectly > >>>>>>added a Method*: > >>>>>> > >>>>>>thread->allow_unhandled_oop((oop*)&_method); > >>>>>> > >>>>>>We should take care to find other such places where we try to put a > >>>>>>non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in > >>>>>>the unhandled oops code. > >>>>>> > >>>>>>/Mikael > >>>>>> > >>>>>>>Testing: > >>>>>>>- JPRT > >>>>>>>- The four tests that were failing are now passing > >>>>>>> > >>>>>>>Thanks, > >>>>>>>Erik > >>>>>>> > >>>> > >> > > From staffan.larsen at oracle.com Fri Oct 18 04:02:29 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 18 Oct 2013 13:02:29 +0200 Subject: jmx-dev RFR 6523160: RuntimeMXBean.getUptime() returns negative values In-Reply-To: <525FD384.4010904@oracle.com> References: <524BDD9E.1050100@oracle.com> <5253B596.1000206@oracle.com> <5253FC54.4010407@oracle.com> <52547D24.9060806@oracle.com> <52553D63.5000508@oracle.com> <8AF79393-C5A2-4458-AF72-2B90A85F11C3@oracle.com> <52556604.3080900@oracle.com> <5AFB7AC3-43C0-4A48-B716-1434CD7DBA93@oracle.com> <525622B4.5020606@oracle.com> <52568940.4000704@oracle.com> <23435103-156B-434F-994C-B6F913EE0364@oracle.com> <525BFC0D.8090101@oracle.com> <525CE56D.4000708@oracle.com> <525EBBCF.3020303@oracle.com> <525F4AE0.1000406@oracle.com> <525FB79F.7070101@oracle.com> <525FC4F8.1020004@oracle.com> <525FD384.4010904@oracle.com> Message-ID: Looks good to me. Thanks, /Staffan On 17 okt 2013, at 14:09, Jaroslav Bachorik wrote: > On 17.10.2013 13:07, David Holmes wrote: >> On 17/10/2013 8:10 PM, Jaroslav Bachorik wrote: >>> Hi David, >>> >>> On 17.10.2013 04:26, David Holmes wrote: >>>> Hi Jaroslav, >>>> >>>> Minor nit: os::elapsed_time should really be defined in terms of the >>>> other functions ie: >>>> >>>> return ((double) os::elapsed_counter()) / os::elapsed_frequency(); >>> >>> Ok. I've changed it. It better communicates the way the elapsedTime is >>> calculated anyway. >>> >>>> >>>> I also prefer the cast above as it is very clear that we will be doing a >>>> floating-point division. >>>> >>>> Aside: AFAICS os::elapsed_time() is never actually used ?? >>> >>> Actually, it is os::elapsedTime() and this one is used quite a lot. The >>> "elapsed_time()" form is used only in bytecodeHistogram.hpp, >>> parNewGeneration.hpp and g1CollectedHeap.hpp, where it is also declared. >> >> AFAICS they all define their own elapsed_time() functions they don't use >> os::elapsed_time(). >> >>>> >>>> I agree that it appears that changing the frequency should be okay. >>> >>> Thanks for the feedback. >>> >>> Updated webrev: http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 >> >> That should be .04 version :) > > Yep :( copy-paste ... > http://cr.openjdk.java.net/~jbachorik/6523160/webrev.04 > >> >> Looks okay. >> >> Thanks, >> David >> >>> -JB- >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 17/10/2013 2:16 AM, Jaroslav Bachorik wrote: >>>>> On 15.10.2013 08:49, David Holmes wrote: >>>>>> Hi Jaroslav, >>>>>> >>>>>> os_bsd.cpp / os_linux.cpp: >>>>>> >>>>>> If you don't have a monotonic clock you leave timer_frequency set >>>>>> to 0! >>>>>> (So you need to test on a system without a monotonic clock, or else >>>>>> force it to act as-if not present.) >>>>>> >>>>>> That aside I don't trust clock_getres to give values that actually >>>>>> allow >>>>>> the timer frequency to be determined. As per the comments in >>>>>> os_linux.cpp: >>>>>> >>>>>> // It's fixed in newer kernels, however clock_getres() still returns >>>>>> // 1/HZ. We check if clock_getres() works, but will ignore its >>>>>> reported >>>>>> // resolution for now. Hopefully as people move to new kernels, this >>>>>> // won't be a problem. >>>>>> >>>>>> we don't know what kernels provide real values here and which provide >>>>>> dummy ones. >>>>>> >>>>>> On BSD you haven't modified os::elapsed_counter. >>>>>> >>>>>> Looking at the linux changes I don't think the logic is correct >>>>>> even if >>>>>> clock_getres is accurate. In the existing code we have: >>>>>> >>>>>> elapsed_counter -> elapsed time in microseconds >>>>>> elapsed_frequency -> 1000 * 1000 (ie micros per second) >>>>>> elapsed_time -> elapsed_counter*0.000001 -> time in seconds >>>>>> >>>>>> Now we have: >>>>>> >>>>>> elapsed_counter -> elapsed time in nanoseconds >>>>>> elapsed_frequency -> 1x10^9 / whatever clock_getres says >>>>>> elapsed_time -> counter/frequency -> ??? >>>>>> >>>>>> So elapsed_time not, in general, going to give the elapsed time in >>>>>> seconds. And elapsed_time is not dependent on the "frequency" at all >>>>>> because elapsed_counter is not reporting ticks but an actual elapsed >>>>>> "time" in nanoseconds. >>>>>> >>>>>> >>>>>> Also note that we constants for: >>>>>> >>>>>> NANOSECS_PER_SEC >>>>>> NANOSECS_PER_MILLISEC >>>>>> >>>>>> to aid with time conversions. >>>>>> >>>>>> The linux webrev contains unrelated UseLargePages changes! >>>>> >>>>> Sorry for the mess with UseLargePages changes :/ >>>>> >>>>> I've fixed the problems with the frequency (using a fixed number as >>>>> before) and I kept the changes to minimum. >>>>> >>>>> I was hesitating about changing the elapsed_counter precision from >>>>> microseconds to nanoseconds but since solaris and windows versions >>>>> already use nanosecond ticks for elapsed_counter I think the change is >>>>> safe. >>>>> >>>>> The update webrev: >>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.03 >>>>> >>>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>> On 15/10/2013 12:13 AM, Jaroslav Bachorik wrote: >>>>>>> On 10.10.2013 13:15, Staffan Larsen wrote: >>>>>>>> >>>>>>>> On 10 okt 2013, at 13:02, Jaroslav Bachorik >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 10.10.2013 05:44, David Holmes wrote: >>>>>>>>>> On 10/10/2013 4:12 AM, Staffan Larsen wrote: >>>>>>>>>>> >>>>>>>>>>> On 9 okt 2013, at 16:19, Jaroslav Bachorik >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 9.10.2013 16:10, Staffan Larsen wrote: >>>>>>>>>>>>> There is now an awful amount of different timestamps in the >>>>>>>>>>>>> Management class. Can they be consolidated somehow? At least >>>>>>>>>>>>> _begin_vm_creation_time and the new _begin_vm_creation_ns. >>>>>>>>>>>>> >>>>>>>>>>>>> This discussion also implies that the "elapsed time" we >>>>>>>>>>>>> print in >>>>>>>>>>>>> the >>>>>>>>>>>>> hs_err file is also wrong. It uses os::elapsedTime() which uses >>>>>>>>>>>>> os::elapsed_counter(). >>>>>>>>>>>>> >>>>>>>>>>>>> And I guess the same thing for the VM.uptime Diagnostic Command >>>>>>>>>>>>> (class VMUptimeDCmd) which also relies on >>>>>>>>>>>>> os::elapsed_counter(). >>>>>>>>>>>> >>>>>>>>>>>> Also the reported GC pauses duration might be wrong since it >>>>>>>>>>>> uses >>>>>>>>>>>> Management::timestamp(). >>>>>>>>>>>> >>>>>>>>>>>> On the first sight the change looks rather trivial. But, >>>>>>>>>>>> honestly, >>>>>>>>>>>> I'm not sure which other parts could for whatever reason break >>>>>>>>>>>> once >>>>>>>>>>>> the time-of-day timestamp is replaced with a monotonic >>>>>>>>>>>> equivalent. >>>>>>>>>>>> One would think that it shouldn't matter but one never knows ... >>>>>>>>>>>> >>>>>>>>>>>> Staffan, do you think this kind of change is suitable for the >>>>>>>>>>>> current >>>>>>>>>>>> phase of JDK release cycle? I think I could improve the patch in >>>>>>>>>>>> few >>>>>>>>>>>> days and then it should probably be able to pass the review >>>>>>>>>>>> before >>>>>>>>>>>> ZBB. But, it's only P3 ... >>>>>>>>>>> >>>>>>>>>>> I think it is a bit late in the release cycle to clean this up in >>>>>>>>>>> the >>>>>>>>>>> way it should be cleaned up. I think we should wait until the >>>>>>>>>>> first 8 >>>>>>>>>>> update release and do a more thorough job than we have time for >>>>>>>>>>> right >>>>>>>>>>> now. >>>>>>>>>> >>>>>>>>>> I second that. The elapsed_counter/elpased_timer APIs and >>>>>>>>>> implementations are a tangled mess. But part of the problem has >>>>>>>>>> been >>>>>>>>>> that people want/expect monotonic time-of-day based timestamps >>>>>>>>>> (yes a >>>>>>>>>> contradiction - though some people make sure TOD does not get >>>>>>>>>> modified >>>>>>>>>> on their production systems). The use of timestamps in logging has >>>>>>>>>> to be >>>>>>>>>> examined carefully - mainly GC logging. I recall a "simple" >>>>>>>>>> attempted >>>>>>>>>> change in the past that resulted in trying to compare a nanoTime >>>>>>>>>> based >>>>>>>>>> timestamp with the TOD. :( >>>>>>>>> >>>>>>>>> Actually, if I'm reading the sources right for Solaris and Win the >>>>>>>>> monotonic clock source is used to provide elapsed_counter() >>>>>>>>> value. It >>>>>>>>> falls back to TOD when the monotonic clock source is not available. >>>>>>>>> For Linux/BSD the TOD is used directly. >>>>>>>>> >>>>>>>>> This makes me wonder if changing the linux/bsd implementation to >>>>>>>>> follow the same logic would be really that disruptive. >>>>>>>> >>>>>>>> Good point. I would like a world where elapsed_counter is monotonic >>>>>>>> (where possible). Still a bit scary this late in the release, but an >>>>>>>> interesting experiment. >>>>>>> >>>>>>> The change is rather simple and tests ok. All the means to get a >>>>>>> monotonic timestamp are already there and proved to work. The core >>>>>>> tests >>>>>>> in JPRT went fine. >>>>>>> >>>>>>> The updated webrev is at >>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.02 >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> >>>>>>>> /Staffan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> -JB- >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> /Staffan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -JB- >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> /Staffan >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 9 okt 2013, at 13:26, Jaroslav Bachorik >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 8.10.2013 23:46, David Holmes wrote: >>>>>>>>>>>>>>> On 8/10/2013 10:36 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>>>> On 8.10.2013 09:34, David Holmes wrote: >>>>>>>>>>>>>>>>> Jaroslav, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 2/10/2013 6:47 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> currently the JVM uptime reported by the RuntimeMXBean is >>>>>>>>>>>>>>>>>> based on >>>>>>>>>>>>>>>>>> System.currentTimeMillis() which makes it susceptible to >>>>>>>>>>>>>>>>>> changes of the >>>>>>>>>>>>>>>>>> OS time (eg. changing timezone, NTP synchronization etc.). >>>>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>>>> uptime >>>>>>>>>>>>>>>>>> should not depend on the system time and should be >>>>>>>>>>>>>>>>>> calculated >>>>>>>>>>>>>>>>>> using a >>>>>>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> There is already the way to get the actual JVM uptime in >>>>>>>>>>>>>>>>>> ticks. >>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>>> accessible as Management::timestamp() and the ticks are >>>>>>>>>>>>>>>>>> convertible to >>>>>>>>>>>>>>>>>> milliseconds using Management::ticks_to_ms(ts_ticks) thus >>>>>>>>>>>>>>>>>> making it >>>>>>>>>>>>>>>>>> very >>>>>>>>>>>>>>>>>> easy to switch to the monotonic clock based uptime. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Maybe I'm missing something but TiumeStamp updates using >>>>>>>>>>>>>>>>> os::elapsed_counter() which on Linux uses gettimeofday >>>>>>>>>>>>>>>>> so is >>>>>>>>>>>>>>>>> not a >>>>>>>>>>>>>>>>> monotonic clock source. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hm, yes. I wasn't aware of this linux/bsd specific. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is there any reason why a non monotonic clock source is used >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>> timestamping except of the historical one? >>>>>>>>>>>>>>>> os::javaTimeNanos() >>>>>>>>>>>>>>>> uses >>>>>>>>>>>>>>>> montonic clock when available - why can't be the same used >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>> os::elapsed_counter() especially when a counter based on >>>>>>>>>>>>>>>> "gettimeofday" >>>>>>>>>>>>>>>> is not really a counter? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It is all historical. These elapsed_counters and >>>>>>>>>>>>>>> elapsed_timers >>>>>>>>>>>>>>> make me >>>>>>>>>>>>>>> cringe. But changing it has a lot of potential consequences >>>>>>>>>>>>>>> because of >>>>>>>>>>>>>>> the way these are used in logging etc. Certainly not >>>>>>>>>>>>>>> something >>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>> contemplated at this stage of JDK 8. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Perhaps a simpler fix here is to expose a startUpTimeNanos >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> can then >>>>>>>>>>>>>>> be used for the uptime. >>>>>>>>>>>>>> >>>>>>>>>>>>>> My attempt at this is at >>>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.01/hotspot >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am using os::javaTimeNanos() to get the monotonic ticks >>>>>>>>>>>>>> where >>>>>>>>>>>>>> possible. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The JDK part stays the same as for webrev.00 >>>>>>>>>>>>>> >>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The patch consists of the hotspot and jdk parts. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> For the hotspot a new constant needs to be introduced in >>>>>>>>>>>>>>>>>> src/share/vm/services/jmm.h and the actual logic to obtain >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> uptime in >>>>>>>>>>>>>>>>>> milliseconds is added in >>>>>>>>>>>>>>>>>> src/share/vm/services/management.cpp. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> For the jdk the changes comprise of adding the necessary >>>>>>>>>>>>>>>>>> JNI >>>>>>>>>>>>>>>>>> bridging >>>>>>>>>>>>>>>>>> methods in order to get the new uptime, introducing the >>>>>>>>>>>>>>>>>> same >>>>>>>>>>>>>>>>>> constant >>>>>>>>>>>>>>>>>> that is used in hotspot and changes to mapfile-vers >>>>>>>>>>>>>>>>>> files in >>>>>>>>>>>>>>>>>> order to >>>>>>>>>>>>>>>>>> properly build the native library. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6523160 >>>>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/6523160/webrev.00 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> > From staffan.larsen at oracle.com Fri Oct 18 04:05:17 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 18 Oct 2013 13:05:17 +0200 Subject: [PING] jmx-dev RFR: 8024613 javax/management/remote/mandatory/connection/RMIConnector_NPETest.java failing intermittently In-Reply-To: <525EA65F.9040509@oracle.com> References: <523C3F8B.6080002@oracle.com> <523C459A.3080303@oracle.com> <524BFB87.10808@oracle.com> <525EA65F.9040509@oracle.com> Message-ID: <306F58ED-6630-4AB0-877E-49083631C4C2@oracle.com> Looks good! Thanks, /Staffan On 16 okt 2013, at 16:44, Jaroslav Bachorik wrote: > On 2.10.2013 12:55, Jaroslav Bachorik wrote: >> On 20.9.2013 14:54, shanliang wrote: >>> Jaroslav, >>> >>> It is a good idea to use the RMI Testlibrary. >>> >>> Better to call: >>> agent.close(); >>> >>> at Line 55, close the RMIRegistry (rmid.shutdown(rmidPort) Line 55) >>> does not ensure the JMX connector doing full clean, it is always better >>> to do clean within a test. >> >> Thanks. Implemented. >> >> http://cr.openjdk.java.net/~jbachorik/8024613/webrev.01 >> >> -JB- >> >>> >>> Shanliang >>> >>> >>> Jaroslav Bachorik wrote: >>>> Please, review the following change for JDK-8024613 >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8024613 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8024613/webrev.00/ >>>> >>>> >>>> The patch takes care of intermittent test failures caused by timing >>>> issues when starting the RMID process. It could happen that the RMID >>>> process hasn't been properly initialized in the timeframe of 5 seconds >>>> and the test would fail. >>>> >>>> The patch replaces the home-brewed RMID process management with the >>>> one available in the RMI Testlibrary which is used by more tests and >>>> therefore should be more stable. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From staffan.larsen at oracle.com Fri Oct 18 03:35:44 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Fri, 18 Oct 2013 10:35:44 +0000 Subject: hg: jdk8/tl/jdk: 8021897: EXCEPTION_ACCESS_VIOLATION on debugging String.contentEquals() Message-ID: <20131018103634.618EC6250D@hg.openjdk.java.net> Changeset: 8479a48d9fd4 Author: sla Date: 2013-10-18 11:52 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8479a48d9fd4 8021897: EXCEPTION_ACCESS_VIOLATION on debugging String.contentEquals() Reviewed-by: alanb, sspitsyn ! src/share/back/outStream.c + test/com/sun/jdi/GetUninitializedStringValue.java From staffan.larsen at oracle.com Fri Oct 18 04:09:07 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 18 Oct 2013 13:09:07 +0200 Subject: RFR 7197919: java/lang/management/ThreadMXBean/ThreadBlockedCount.java has concurency issues In-Reply-To: <525EA03F.2070106@oracle.com> References: <525EA03F.2070106@oracle.com> Message-ID: <5D7A8C19-DB9C-4CE7-B18A-E22C74C0794C@oracle.com> Looks good! Nit: for(int i=0;i<100;i++) should have more spaces: for (int i = 0; i < 100; i++) Thanks, /Staffan On 16 okt 2013, at 16:18, Jaroslav Bachorik wrote: > Please, review this simple test change. > > The test tries to get the number of times a certain thread was blocked during the test run and intermittently fails with the difference of 1 - the expected number is 4 but the reported number is 3. > > When updating the thread statistics (the blocked count in this case) no lock is used so there might be stale data when the ThreadMXBean retrieves the stats. The patch tries to workaround this problem by retrying a few times with the added delay. The test will try to obtain the correct result for at most 10 seconds - after that it will fail if the retrieved blocked count does not equal the expected blocked count. > > Issue : https://bugs.openjdk.java.net/browse/JDK-7197919 > Webrev: http://cr.openjdk.java.net/~jbachorik/7197919/webrev.00 > > Thanks, > > -JB- From peter.allwin at oracle.com Fri Oct 18 04:09:31 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Fri, 18 Oct 2013 13:09:31 +0200 Subject: RFR: 8009681: TEST_BUG: MethodExitReturnValuesTest.java fails with when there are unexpected background threads In-Reply-To: <848A2E80-1793-4C2B-AD20-EA1E473B1820@oracle.com> References: <516E9DB9.8020009@oracle.com> <62E7E237-46A6-46A7-8682-BE332F296F3D@oracle.com> <525E80C5.6040802@oracle.com> <848A2E80-1793-4C2B-AD20-EA1E473B1820@oracle.com> Message-ID: <34FEB736-B9ED-4D0F-92EA-313B370309FC@oracle.com> +1 Thanks, /peter On Oct 18, 2013, at 12:56 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > > On 16 okt 2013, at 14:04, Mikael Auno wrote: > >> This bug got a bit lost from my radar after vacation, but I've picked it >> again now. I've moved Arrays.asList() as suggested. In further testing of the fix though, I found that the include list is not enough, as one of the expected method exit events is from String.intern(), which might also be called from background threads. To counter this, I added a thread filter to the events. This also has the added benefit of speeding up the test significantly (from 90 seconds to about 5 seconds) in the cases where there are background threads interfering. >> >> Also added to this webrev is a fix for MethodEntryExitEvents.java which had exactly the same problem and a similar test design as MethodExitReturnValuesTest.java. >> >> The updated webrev is at http://cr.openjdk.java.net/~allwin/auno/8009681/webrev.00/. >> >> Thanks, >> Mikael >> >> On 2013-05-28 08:46, Staffan Larsen wrote: >>> Looks good. >>> >>> You could optimize it a bit by not doing the Arrays.asList() on every >>> methodExit event. >>> >>> /Staffan >>> >>> On 17 apr 2013, at 15:03, Mikael Auno >>> wrote: >>> >>>> Hi, I'd like some reviews on >>>> http://cr.openjdk.java.net/~nloodin/8009681/webrev.01/ for >>>> JDK-8009681 (http://bugs.sun.com/view_bug.do?bug_id=8009681). >>>> >>>> The issue here is that when MethodExitReturnValuesTest hooks into >>>> MethodExit events through JDI it uses an exclude list to filter out >>>> classes from which it is not interested in these events. This is >>>> bound to break over and over again as new features are added to the >>>> JDK. I've changed the test to use an include list instead, >>>> containing only the handful of classes the test is actually >>>> interested in. >>>> >>>> Thanks, >>>> Mikael >>> >> > From staffan.larsen at oracle.com Fri Oct 18 04:30:06 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 18 Oct 2013 13:30:06 +0200 Subject: RFR: 8026789 Update test/java/lang/instrument/Re(transform|define)BigClass.sh test to use NMT for memory leak detection In-Reply-To: <71403A99-3B7E-4323-9F83-23DB537DF5AC@oracle.com> References: <71403A99-3B7E-4323-9F83-23DB537DF5AC@oracle.com> Message-ID: <15538B52-3C6E-4F04-87F3-D5C997BD2BEC@oracle.com> Not all platforms support the 'detail' level of Native Memory Tracking. That level isn't strictly necessary for the test in my fix below, but provides more data when an error happens. I have change the test to only use 'detail' when it is supported by the JVM, otherwise I fall back to 'summary'. updated webrev: http://cr.openjdk.java.net/~sla/8026789/webrev.01/ Thanks, /Staffan On 17 okt 2013, at 20:30, Staffan Larsen wrote: > The two tests currently use /proc/self/stat to read the virtual memory usage for the process. This only works on linux and only gives a single value to analyze. NMT works on all platforms and gives a lot more detail about where the memory is consumed. > > Without this fix, I can repro JDK-8023201 when stressing the machine heavily, but with this fix the test passes. The reason for this is probably that NMT uses a more granular measurement of committed memory, and not that the VM actually uses less memory. I have retained the memory growth limit of 32MB, but if that is a good value or not, I don't know. When stressing the test, I see NMT reporting about 1MB in committed memory growth. > > I have also removed the tests from ProblemList.txt. > > webrev: http://cr.openjdk.java.net/~sla/8026789/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8026789 > > Thanks, > /Staffan > From fredrik.arvidsson at oracle.com Fri Oct 18 06:41:05 2013 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Fri, 18 Oct 2013 15:41:05 +0200 Subject: RFR (XXS) 8026808: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failed with unexpected exit value Message-ID: <52613A71.7010500@oracle.com> Hi Please help me with this tiny review: Webrev: http://cr.openjdk.java.net/~farvidsson/8026808/webrev.00/index.html Bug: https://bugs.openjdk.java.net/browse/JDK-8026808 About this bug: This bug was revealed by another test-fix: https://bugs.openjdk.java.net/browse/JDK-8025638. The JDKToolLauncher have probably never worked in Solaris 64 environments. JTReg tests run in JPRT: http://sthjprt.se.oracle.com/archives/2013/10/2013-10-18-094943.farvidss.hotspot/ verified successful. Cheers /F From alan.bateman at oracle.com Fri Oct 18 06:37:22 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 18 Oct 2013 13:37:22 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20131018133958.A96F96251E@hg.openjdk.java.net> Changeset: da695008417f Author: alanb Date: 2013-10-18 13:45 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da695008417f 8026859: (fs) test/java/nio/file/Files/StreamTest.java fails to compile intermittently Reviewed-by: psandoz ! test/java/nio/file/Files/StreamTest.java Changeset: 4e065f5b4a16 Author: igerasim Date: 2013-10-18 16:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4e065f5b4a16 8026756: Test java/util/zip/GZIP/GZIPInZip.java failed Reviewed-by: alanb ! test/java/util/zip/GZIP/GZIPInZip.java Changeset: 329cf77821e8 Author: alanb Date: 2013-10-18 13:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/329cf77821e8 7050570: (fs) FileSysteProvider fails to initializes if run with file.encoding set to Cp037 Reviewed-by: sherman, ulfzibis ! src/share/classes/sun/nio/fs/Util.java ! src/solaris/classes/sun/nio/fs/GnomeFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/LinuxDosFileAttributeView.java ! src/solaris/classes/sun/nio/fs/LinuxFileStore.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java ! src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/UnixException.java ! src/solaris/classes/sun/nio/fs/UnixFileStore.java ! src/solaris/classes/sun/nio/fs/UnixFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixMountEntry.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/classes/sun/nio/fs/UnixUserPrincipals.java From shanliang.jiang at oracle.com Fri Oct 18 07:16:51 2013 From: shanliang.jiang at oracle.com (shanliang.jiang at oracle.com) Date: Fri, 18 Oct 2013 14:16:51 +0000 Subject: hg: jdk8/tl/jdk: 8026028: [findbugs] findbugs report some issue in com.sun.jmx.snmp package Message-ID: <20131018141711.BB89162528@hg.openjdk.java.net> Changeset: 4161f17dfe2b Author: sjiang Date: 2013-10-18 16:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4161f17dfe2b 8026028: [findbugs] findbugs report some issue in com.sun.jmx.snmp package Reviewed-by: psandoz, dfuchs ! src/share/classes/com/sun/jmx/snmp/SnmpString.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java ! src/share/classes/com/sun/jmx/snmp/daemon/CommunicatorServer.java + test/com/sun/jmx/snmp/NoInfoLeakTest.java From shanliang.jiang at oracle.com Fri Oct 18 07:57:42 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 18 Oct 2013 16:57:42 +0200 Subject: jmx-dev Codereview request: 8026028 [findbugs] findbugs report some issue in com.sun.jmx.snmp package In-Reply-To: <525FB3AB.3040105@oracle.com> References: <508E8F79.60909@oracle.com> <525E9B87.9050406@oracle.com> <525FB3AB.3040105@oracle.com> Message-ID: <52614C66.6040507@oracle.com> Thanks Paul and Daniel for the review. Shanliang Daniel Fuchs wrote: > Hi Shanliang, > > Looks good! > > -- daniel > > On 10/16/13 3:58 PM, shanliang wrote: >> Hi, >> >> Please review the following fix, main issue here is that we should clone >> an internal variable before returning. >> >> webrev: >> http://cr.openjdk.java.net/~sjiang/JDK-8026028/00/ >> >> bug >> https://bugs.openjdk.java.net/browse/JDK-8026028 >> >> Thanks, >> Shanliang >> >> >> >> > From sundararajan.athijegannathan at oracle.com Fri Oct 18 07:03:09 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 18 Oct 2013 14:03:09 +0000 Subject: hg: jdk8/tl/nashorn: 4 new changesets Message-ID: <20131018140316.E28096251F@hg.openjdk.java.net> Changeset: b01a10c7c7c2 Author: attila Date: 2013-10-17 12:38 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b01a10c7c7c2 8026161: Don't narrow floating-point literals in the lexer Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/runtime/JSType.java + test/script/basic/JDK-8026161.js + test/script/basic/JDK-8026161.js.EXPECTED ! test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java Changeset: a2065f67857c Author: hannesw Date: 2013-10-17 17:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a2065f67857c 8026701: Array.prototype.splice is slow on dense arrays Reviewed-by: lagergren, sundar, jlaskey ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java ! test/examples/array-micro.js + test/script/basic/JDK-8026701.js + test/script/basic/JDK-8026701.js.EXPECTED Changeset: 66d27c77b455 Author: hannesw Date: 2013-10-18 12:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/66d27c77b455 8026805: Array.prototype.length doesn't work as expected Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java + test/script/basic/JDK-8026805.js Changeset: b5b4c98b072b Author: sundar Date: 2013-10-18 18:26 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b5b4c98b072b Merge From dmitry.samersoff at oracle.com Fri Oct 18 08:11:47 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Fri, 18 Oct 2013 15:11:47 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets Message-ID: <20131018151200.405BE6252D@hg.openjdk.java.net> Changeset: d2db09f281ca Author: dsamersoff Date: 2013-10-17 16:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d2db09f281ca 8005810: Update Hotspot Serviceability Agent for Method Parameter Reflection and Generic Type Signature Data Summary: Hotspot was updated to store method parameter reflection and generic type signature data at runtime. Serviceability agent support was updated for this data Reviewed-by: coleenp, minqi, sla Contributed-by: eric.mccorkle at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! src/share/vm/runtime/vmStructs.cpp Changeset: b942ac65ac86 Author: dsamersoff Date: 2013-10-17 17:01 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b942ac65ac86 Merge Changeset: d0453d2fd045 Author: dsamersoff Date: 2013-10-18 10:37 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d0453d2fd045 Merge From alan.bateman at oracle.com Fri Oct 18 08:14:29 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 18 Oct 2013 15:14:29 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131018151520.E42916252E@hg.openjdk.java.net> Changeset: 602aa6fa46c6 Author: alanb Date: 2013-10-18 15:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/602aa6fa46c6 8026876: (fs) Build issue with src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java Reviewed-by: psandoz ! src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java Changeset: 93f4f012deaf Author: alanb Date: 2013-10-18 16:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93f4f012deaf Merge From rob.mckenna at oracle.com Fri Oct 18 08:30:13 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Fri, 18 Oct 2013 15:30:13 +0000 Subject: hg: jdk8/tl/jdk: 8024660: TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log open in fastdebug builds Message-ID: <20131018153027.4058E6252F@hg.openjdk.java.net> Changeset: 8d1d5a5aeb41 Author: robm Date: 2013-10-18 16:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d1d5a5aeb41 8024660: TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log open in fastdebug builds Reviewed-by: alanb Contributed-by: pavel.punegov at oracle.com ! test/java/lang/ProcessBuilder/InheritIOEHandle.java ! test/java/lang/ProcessBuilder/SiblingIOEHandle.java From daniel.daugherty at oracle.com Fri Oct 18 09:36:02 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 18 Oct 2013 10:36:02 -0600 Subject: RFR: 8026789 Update test/java/lang/instrument/Re(transform|define)BigClass.sh test to use NMT for memory leak detection In-Reply-To: <71403A99-3B7E-4323-9F83-23DB537DF5AC@oracle.com> References: <71403A99-3B7E-4323-9F83-23DB537DF5AC@oracle.com> Message-ID: <52616372.6000100@oracle.com> > webrev: http://cr.openjdk.java.net/~sla/8026789/webrev.00/ test/ProblemList.txt Interesting. The tests are on the list via 8023201, but you're tweaking the tests via 8026789. I'm guessing you don't want to say (yet) that this fix resolved the 'leak' in 8023201. test/java/lang/instrument/RedefineBigClass.sh No comments. test/java/lang/instrument/RedefineBigClassApp.java line 38: // Do a short warmup before creating the NMT baseline I think of 'warmup' as running code rather than sleeping. Perhaps: // Give the VM some time for initial memory allocs to happen. The 'Kb' uses in the test should be 'KB'; 'Kb' is kilo-bits. test/java/lang/instrument/RetransformBigClass.sh No comments. test/java/lang/instrument/RetransformBigClassApp.java line 38: // Do a short warmup before creating the NMT baseline Same comment as above. The 'Kb' uses in the test should be 'KB'; 'Kb' is kilo-bits. test/java/lang/instrument/NMTHelper.java Nice, very nice. Thumbs up. Dan On 10/17/13 12:30 PM, Staffan Larsen wrote: > The two tests currently use /proc/self/stat to read the virtual memory usage for the process. This only works on linux and only gives a single value to analyze. NMT works on all platforms and gives a lot more detail about where the memory is consumed. > > Without this fix, I can repro JDK-8023201 when stressing the machine heavily, but with this fix the test passes. The reason for this is probably that NMT uses a more granular measurement of committed memory, and not that the VM actually uses less memory. I have retained the memory growth limit of 32MB, but if that is a good value or not, I don't know. When stressing the test, I see NMT reporting about 1MB in committed memory growth. > > I have also removed the tests from ProblemList.txt. > > webrev: http://cr.openjdk.java.net/~sla/8026789/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8026789 > > Thanks, > /Staffan > From mandy.chung at oracle.com Fri Oct 18 09:42:32 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 18 Oct 2013 09:42:32 -0700 Subject: jmx-dev RFR 7197919: java/lang/management/ThreadMXBean/ThreadBlockedCount.java has concurency issues In-Reply-To: <525EA03F.2070106@oracle.com> References: <525EA03F.2070106@oracle.com> Message-ID: <526164F8.1070501@oracle.com> On 10/16/2013 7:18 AM, Jaroslav Bachorik wrote: > Please, review this simple test change. > > The test tries to get the number of times a certain thread was blocked > during the test run and intermittently fails with the difference of 1 > - the expected number is 4 but the reported number is 3. > > When updating the thread statistics (the blocked count in this case) > no lock is used so there might be stale data when the ThreadMXBean > retrieves the stats. The patch tries to workaround this problem by > retrying a few times with the added delay. The test will try to obtain > the correct result for at most 10 seconds - after that it will fail if > the retrieved blocked count does not equal the expected blocked count. > > Issue : https://bugs.openjdk.java.net/browse/JDK-7197919 > Webrev: http://cr.openjdk.java.net/~jbachorik/7197919/webrev.00 Looks okay. I notice that existing code that catches InterruptedException only sets testFailed to true but continue. I think it might be good to fix them to return if IE is caught to fail-fast like what your fix does. Mandy From dmitry.samersoff at oracle.com Fri Oct 18 13:08:15 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Fri, 18 Oct 2013 20:08:15 +0000 Subject: hg: jdk8/tl/jdk: 8004213: JDP packet needs pid, broadcast interval and rmi server hostname fields Message-ID: <20131018200958.8668062548@hg.openjdk.java.net> Changeset: 88436832cfd0 Author: dsamersoff Date: 2013-10-19 00:05 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/88436832cfd0 8004213: JDP packet needs pid, broadcast interval and rmi server hostname fields Summary: Add some extra fileds to jdp packet Reviewed-by: allwin, sla, hirt ! src/share/classes/sun/management/jdp/JdpController.java ! src/share/classes/sun/management/jdp/JdpJmxPacket.java ! test/sun/management/jdp/JdpClient.java ! test/sun/management/jdp/JdpDoSomething.java ! test/sun/management/jdp/JdpTest.sh From roger.riggs at oracle.com Fri Oct 18 14:34:27 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Fri, 18 Oct 2013 21:34:27 +0000 Subject: hg: jdk8/tl/jdk: 8025828: Late binding of Chronology to appendValueReduced Message-ID: <20131018213445.AC1EB6254C@hg.openjdk.java.net> Changeset: 7a947daa8f51 Author: rriggs Date: 2013-10-18 16:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a947daa8f51 8025828: Late binding of Chronology to appendValueReduced Summary: Add a listener to the parseContext called when the Chronology changes Reviewed-by: sherman ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/DateTimeParseContext.java ! test/java/time/test/java/time/format/TestReducedParser.java From jonathan.gibbons at oracle.com Fri Oct 18 15:05:43 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 18 Oct 2013 22:05:43 +0000 Subject: hg: jdk8/tl/langtools: 8026749: Missing LV table in lambda bodies Message-ID: <20131018220557.096896254E@hg.openjdk.java.net> Changeset: 7de97abc4a5c Author: jjg Date: 2013-10-18 15:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7de97abc4a5c 8026749: Missing LV table in lambda bodies Reviewed-by: vromero, jlahoda ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/lambda/LocalVariableTable.java From bhavesh.x.patel at oracle.com Fri Oct 18 16:35:50 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Fri, 18 Oct 2013 23:35:50 +0000 Subject: hg: jdk8/tl/langtools: 8026567: Use meaningful style names for strong and italic styles. Message-ID: <20131018233556.27B2E6255C@hg.openjdk.java.net> Changeset: 130b8c0e570e Author: bpatel Date: 2013-10-18 16:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/130b8c0e570e 8026567: Use meaningful style names for strong and italic styles. Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeFieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! test/com/sun/javadoc/AuthorDD/AuthorDD.java ! test/com/sun/javadoc/testAnnotationTypes/TestAnnotationTypes.java ! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java ! test/com/sun/javadoc/testClassTree/TestClassTree.java ! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java ! test/com/sun/javadoc/testDeprecatedDocs/TestDeprecatedDocs.java ! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/com/sun/javadoc/testHref/TestHref.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testHtmlStrongTag/TestHtmlStrongTag.java ! test/com/sun/javadoc/testIndex/TestIndex.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java ! test/com/sun/javadoc/testLegacyTaglet/Check.java ! test/com/sun/javadoc/testLinkOption/TestLinkOption.java ! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java ! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java ! test/com/sun/javadoc/testNavigation/TestNavigation.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenMethodDocCopy.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethods.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java ! test/com/sun/javadoc/testPackageDeprecation/TestPackageDeprecation.java ! test/com/sun/javadoc/testParamTaglet/TestParamTaglet.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testProfiles/TestProfiles.java ! test/com/sun/javadoc/testProfiles/TestProfilesConfiguration.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/com/sun/javadoc/testSimpleTag/TestSimpleTag.java ! test/com/sun/javadoc/testSimpleTagInherit/TestSimpleTagInherit.java ! test/com/sun/javadoc/testSinceTag/TestSinceTag.java ! test/com/sun/javadoc/testTagOutput/TestTagOutput.java ! test/com/sun/javadoc/testTaglets/TestTaglets.java ! test/com/sun/javadoc/testTaglets/taglets/Foo.java ! test/com/sun/javadoc/testThrowsHead/TestThrowsHead.java ! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java ! test/com/sun/javadoc/testValueTag/TestValueTag.java From calvin.cheung at oracle.com Sat Oct 19 01:52:33 2013 From: calvin.cheung at oracle.com (calvin.cheung at oracle.com) Date: Sat, 19 Oct 2013 08:52:33 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 54 new changesets Message-ID: <20131019085437.02D026256A@hg.openjdk.java.net> Changeset: 02d171a3b5d1 Author: cl Date: 2013-10-10 10:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/02d171a3b5d1 Added tag jdk8-b111 for changeset f6962730bbde ! .hgtags Changeset: 4a845c7a4638 Author: amurillo Date: 2013-10-11 13:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4a845c7a4638 Merge Changeset: 0ed9a90f45e1 Author: amurillo Date: 2013-10-11 13:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0ed9a90f45e1 Added tag hs25-b54 for changeset 4a845c7a4638 ! .hgtags Changeset: 7c26dced065e Author: amurillo Date: 2013-10-11 13:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7c26dced065e 8026265: new hotspot build - hs25-b55 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e8703d708e6e Author: ccheung Date: 2013-10-16 11:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e8703d708e6e Merge Changeset: 1e814e391ee8 Author: anoll Date: 2013-10-04 09:19 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1e814e391ee8 8025656: compiler/8013496/Test8013496.sh fails on assert Summary: Ensure the thread is in correct state; rewrote test in Java Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp - test/compiler/8013496/Test8013496.sh + test/compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java Changeset: 0c4c40f5c399 Author: twisti Date: 2013-10-04 10:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0c4c40f5c399 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods Reviewed-by: kvn, roland ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/parse.hpp Changeset: 5f1241525a01 Author: twisti Date: 2013-10-04 19:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5f1241525a01 Merge Changeset: bf8a21c3ab3b Author: vlivanov Date: 2013-10-07 14:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bf8a21c3ab3b 8025849: Redundant "pid" in VM log file name (e.g. hotspot_pidpid12345.log) Reviewed-by: twisti, azeemj ! src/share/vm/utilities/ostream.cpp Changeset: 5cc2d82aa82a Author: vlivanov Date: 2013-10-07 14:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5cc2d82aa82a 8024943: ciReplay: fails to dump replay data during safepointing Reviewed-by: kvn, twisti ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/utilities/vmError.cpp Changeset: f478c98e8114 Author: vlivanov Date: 2013-10-07 14:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f478c98e8114 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range Reviewed-by: iveresov, roland, kvn, twisti ! src/share/vm/opto/parse2.cpp Changeset: 5741fc86a2ee Author: vlivanov Date: 2013-10-07 14:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5741fc86a2ee 8025845: Default methods are unnecessarily marked w/ force_inline directive in some situations Reviewed-by: acorn, kvn ! src/share/vm/classfile/defaultMethods.cpp Changeset: c775af091fe9 Author: twisti Date: 2013-10-07 10:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c775af091fe9 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method Reviewed-by: kvn ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/parseHelper.cpp Changeset: d9043b88eeb3 Author: roland Date: 2013-10-03 10:55 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d9043b88eeb3 8024067: Missing replace_in_map() calls following null checks Summary: add replace_in_map() calls following some null checks in type checks Reviewed-by: kvn ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp Changeset: 17cda06bcb7d Author: iveresov Date: 2013-10-08 07:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/17cda06bcb7d Merge ! src/share/vm/classfile/defaultMethods.cpp - test/compiler/8013496/Test8013496.sh Changeset: 6171eb9da4fd Author: twisti Date: 2013-10-08 19:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6171eb9da4fd 8007923: Tests on references fails Reviewed-by: kvn, iveresov ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/opto/escape.cpp Changeset: 98692a2d36d7 Author: adlertz Date: 2013-10-09 13:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/98692a2d36d7 8013830: [parfait] Uninitialised pointer 'Reachblock' may be used as argument Summary: Replace uninitialised pointer with NULL at argument. Reviewed-by: kvn, roland, twisti ! src/share/vm/opto/reg_split.cpp Changeset: 4e7f99b70d9d Author: adlertz Date: 2013-10-09 05:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4e7f99b70d9d Merge - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java Changeset: 46ef27bcacb3 Author: twisti Date: 2013-10-09 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/46ef27bcacb3 8020750: Node::get_int: guarantee(t != NULL) failed: must be con Reviewed-by: kvn, roland ! src/share/vm/opto/ifnode.cpp Changeset: d13d7aba8c12 Author: roland Date: 2013-10-09 16:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d13d7aba8c12 8023657: New type profiling points: arguments to call Summary: x86 interpreter and c1 type profiling for arguments at calls Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciKlass.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObjArrayKlass.hpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciTypeArrayKlass.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp Changeset: 8b80b262e501 Author: twisti Date: 2013-10-11 10:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8b80b262e501 8005173: assert(false) failed: DEBUG MESSAGE: exception oop must be empty (macroAssembler_x86.cpp:625) Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/thread.hpp Changeset: d8a449d2f5b2 Author: adlertz Date: 2013-10-11 13:10 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d8a449d2f5b2 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: Summary: Increased the LRG AllStack mask size since the previous size was not big enough when compiling huge methods (60k+ nodes) Reviewed-by: kvn, roland, twisti ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/ifg.cpp Changeset: 2348b2726e1d Author: adlertz Date: 2013-10-11 19:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2348b2726e1d Merge Changeset: dd2cf1d1248b Author: adlertz Date: 2013-10-12 01:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/dd2cf1d1248b Merge Changeset: 469216acdb28 Author: anoll Date: 2013-10-10 15:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/469216acdb28 8023014: CodeSweeperSweepNoFlushTest.java fails with HS crash Summary: Ensure ensure correct initialization of compiler runtime Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_Compiler.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/compiler/abstractCompiler.cpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/c2compiler.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkCompiler.hpp + test/compiler/startup/SmallCodeCacheStartup.java Changeset: ed2c74787eb5 Author: twisti Date: 2013-10-11 19:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ed2c74787eb5 Merge Changeset: ce0cc25bc5e2 Author: roland Date: 2013-10-12 12:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ce0cc25bc5e2 8026054: New type profiling points: type of return values at calls Summary: x86 interpreter and c1 type profiling for return values at calls Reviewed-by: kvn, twisti ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp Changeset: f50418dfb1b7 Author: iveresov Date: 2013-10-13 13:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f50418dfb1b7 Merge ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp - test/compiler/8013496/Test8013496.sh Changeset: e504cd481ec0 Author: twisti Date: 2013-10-14 19:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e504cd481ec0 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set Reviewed-by: kvn ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp Changeset: 8df6f123d35e Author: drchase Date: 2013-10-12 17:26 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8df6f123d35e 8026124: JSR-292 bug: java.nio.file.Path.toString cores dump Summary: catch problem case, assert it matches valid input, new test Reviewed-by: jrose, twisti, kvn ! src/share/vm/interpreter/linkResolver.cpp + test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java + test/compiler/jsr292/createsInterfaceDotEqualsCallInfo.js Changeset: f91a9a696e5e Author: kvn Date: 2013-10-15 12:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f91a9a696e5e 8026293: Schedule part of G1 pre-barrier late Summary: move rare executed part of G1 write barrier from hot path. Reviewed-by: kvn, twisti, roland Contributed-by: staffan.friberg at oracle.com ! src/share/vm/opto/graphKit.cpp Changeset: 1263c7e17e1c Author: kvn Date: 2013-10-15 17:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1263c7e17e1c Merge Changeset: 4a2acfb16e97 Author: rbackman Date: 2013-10-11 12:06 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4a2acfb16e97 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 Reviewed-by: kvn, twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/mathexactnode.cpp ! src/share/vm/opto/mathexactnode.hpp + test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 90abdd727e64 Author: iveresov Date: 2013-10-16 11:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/90abdd727e64 8009303: Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 Summary: Do memory flow analysis in string concat optimizier to exclude cases when computation of arguments to StringBuffer::append has side effects Reviewed-by: kvn, twisti ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/stringopts.cpp Changeset: 8f4bb1773fd9 Author: iveresov Date: 2013-10-17 10:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8f4bb1773fd9 Merge ! src/share/vm/interpreter/linkResolver.cpp - test/compiler/8013496/Test8013496.sh Changeset: 7114c4597ae3 Author: acorn Date: 2013-10-17 23:30 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7114c4597ae3 8026365: NoClassDefinitionFound for anonymous class invokespecial. Reviewed-by: dcubed, kamg ! src/share/vm/classfile/verifier.cpp ! test/TEST.groups Changeset: 9c8289162268 Author: jwilhelm Date: 2013-10-11 16:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9c8289162268 8024776: Max/MinHeapFreeRatio descriptions should be more precise Summary: Descriptions for Max/MinHeapFreeRatio updated Reviewed-by: ehelin, jmasa ! src/share/vm/runtime/globals.hpp Changeset: 2382ff14d889 Author: jwilhelm Date: 2013-10-12 05:08 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2382ff14d889 Merge ! src/share/vm/runtime/globals.hpp Changeset: 24f32d09a0d7 Author: jwilhelm Date: 2013-10-12 00:49 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/24f32d09a0d7 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize Summary: Exit with an error if incompatible NewSize and MaxNeSize are set Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: d6818f623792 Author: tschatzl Date: 2013-10-15 11:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d6818f623792 8026186: gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java Compilation failed Summary: After a method rename in JDK-8014905 the mentioned test did not compile any more. Fix the uses of the affected method. Reviewed-by: jwilhelm, mgerdin, jmasa ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 027006a47a6d Author: sjohanss Date: 2013-10-14 14:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/027006a47a6d 8025661: Ill-formed -Xminf and -Xmaxf options values interpreted as 0 Summary: Using strtod() instead of atof() when parsing -Xminf and -Xmaxf. Reviewed-by: brutisso, pliden ! src/share/vm/runtime/arguments.cpp + test/gc/arguments/TestHeapFreeRatio.java Changeset: 82fcc0567fef Author: mgerdin Date: 2013-10-15 04:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/82fcc0567fef Merge Changeset: 6f1919cfd18c Author: pliden Date: 2013-10-15 11:38 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6f1919cfd18c 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full gcs, expect 0 full gcs Reviewed-by: brutisso, tschatzl ! test/TEST.groups - test/gc/7168848/HumongousAlloc.java + test/gc/g1/TestHumongousAllocInitialMark.java Changeset: bfd52054aeb8 Author: pliden Date: 2013-10-15 11:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bfd52054aeb8 8024632: Description of InitialSurvivorRatio flag in globals.hpp is incorrect Reviewed-by: brutisso, tschatzl, kmo, tamao ! src/share/vm/runtime/globals.hpp Changeset: 041c5da41ac4 Author: pliden Date: 2013-10-15 11:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/041c5da41ac4 8024634: gc/startup_warnings tests can fail due to unrelated warnings Reviewed-by: brutisso, jwilhelm, tamao ! test/gc/startup_warnings/TestCMS.java ! test/gc/startup_warnings/TestCMSNoIncrementalMode.java ! test/gc/startup_warnings/TestG1.java ! test/gc/startup_warnings/TestParNewCMS.java ! test/gc/startup_warnings/TestParallelGC.java ! test/gc/startup_warnings/TestParallelScavengeSerialOld.java ! test/gc/startup_warnings/TestSerialGC.java Changeset: f16726924734 Author: stefank Date: 2013-10-15 07:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f16726924734 Merge - test/gc/7168848/HumongousAlloc.java Changeset: bdfbb1fb19ca Author: stefank Date: 2013-10-15 14:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bdfbb1fb19ca 8026391: The Metachunk header wastes memory Reviewed-by: coleenp, jmasa ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeList.cpp - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ec2e26e26183 Author: stefank Date: 2013-10-15 14:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ec2e26e26183 8026392: Metachunks and Metablocks are using a too large alignment Reviewed-by: coleenp, jmasa ! src/share/vm/memory/metachunk.cpp Changeset: 9e5fadad7fdf Author: tschatzl Date: 2013-10-16 11:46 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9e5fadad7fdf 8025925: jmap fails with "field _length not found in type HeapRegionSeq" Summary: The change JDK-7163191 changed the data layout of a class that is referenced by the java code of the SA agent. This fix synchronizes the SA agent with that change. Reviewed-by: sla, mgerdin + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1HeapRegionTable.java ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java Changeset: 28df60a5badf Author: stefank Date: 2013-10-17 08:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/28df60a5badf 8026707: JDK-8026391 broke the optimized build target Reviewed-by: mgerdin, coleenp ! src/share/vm/memory/metachunk.hpp Changeset: 94c0343b1887 Author: stefank Date: 2013-10-17 08:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/94c0343b1887 8026715: Remove the MetaDataDeallocateALot develop flag Reviewed-by: coleenp, mgerdin ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/globals.hpp Changeset: bf9e50c573ad Author: jmasa Date: 2013-10-17 06:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/bf9e50c573ad 8025635: SoftReferences are not cleared before metaspace OOME are thrown Reviewed-by: jcoomes, tamao, tschatzl, stefank ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp Changeset: c51cd6af7e61 Author: jcoomes Date: 2013-10-18 12:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c51cd6af7e61 Merge ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! test/TEST.groups - test/compiler/8013496/Test8013496.sh ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: ee99e1a7c5fb Author: ccheung Date: 2013-10-18 19:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ee99e1a7c5fb Merge ! src/share/vm/interpreter/linkResolver.cpp - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! src/share/vm/runtime/vmStructs.cpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java From david.holmes at oracle.com Sat Oct 19 05:19:55 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 19 Oct 2013 22:19:55 +1000 Subject: RFR (XXS) 8026808: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failed with unexpected exit value In-Reply-To: <52613A71.7010500@oracle.com> References: <52613A71.7010500@oracle.com> Message-ID: <526278EB.5010203@oracle.com> Hi Fredrik, On 18/10/2013 11:41 PM, Fredrik Arvidsson wrote: > Hi > > Please help me with this tiny review: > > Webrev: > http://cr.openjdk.java.net/~farvidsson/8026808/webrev.00/index.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8026808 > > About this bug: > This bug was revealed by another test-fix: > https://bugs.openjdk.java.net/browse/JDK-8025638. The JDKToolLauncher > have probably never worked in Solaris 64 environments. I don't see the connection to 64-bit from the fix but I suspect it may be a confusion between launcher args (like -d64) and VM args (like -XX:+foo). AFAICS the tools will accept both -d64 and -J-d64. Your change to vmArgs is wrong. It explicitly states that it adds -J to the arg and you have removed that. When launching a tool (javac, javap, etc) you have to pass VM args via -J - and that is what this method was supposed to do. AFAICS based on the usage example given in the code: 40 * JDKToolLauncher jmap = JDKToolLauncher.create("jmap") 41 * .addVMArg("-XX:+PrintGC"); 42 * .addVMArg("-XX:+PrintGCDetails") 43 * .addToolArg("-heap") 44 * .addToolArg(pid); 45 * ProcessBuilder pb = new ProcessBuilder(jmap.getCommand()); the existing code was correct. Based on the jtreg log in the bug report: Command line: [/export/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/rt_baseline/solaris-amd64/bin/java -d64 -Xmx1g JMapHProfLargeHeapProc 22528 ] Extracted pid: 18298 jmap command: [/export/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/rt_baseline/solaris-amd64/bin/jmap, -d64, -dump:format=b,file=18298-heap.hprof, 18298] it would seem to me that the problem is the presence of commas in the jmap command (compare with the java command). Not that I can see where they come from. I can't find this test in our repo - where is it? David ----- > JTReg tests run in JPRT: > http://sthjprt.se.oracle.com/archives/2013/10/2013-10-18-094943.farvidss.hotspot/ > verified successful. > > Cheers > /F From vicente.romero at oracle.com Sat Oct 19 09:55:15 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sat, 19 Oct 2013 16:55:15 +0000 Subject: hg: jdk8/tl/jdk: 8026854: java.time.temporal.TemporalQueries doesn't compile after javac modification to lambda flow analysis Message-ID: <20131019165527.959BC6256F@hg.openjdk.java.net> Changeset: fbb7510f788d Author: vromero Date: 2013-10-19 17:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fbb7510f788d 8026854: java.time.temporal.TemporalQueries doesn't compile after javac modification to lambda flow analysis Reviewed-by: psandoz ! src/share/classes/java/time/temporal/TemporalQueries.java From vicente.romero at oracle.com Sat Oct 19 09:58:11 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sat, 19 Oct 2013 16:58:11 +0000 Subject: hg: jdk8/tl/langtools: 8024809: javac, some lambda programs are rejected by flow analysis Message-ID: <20131019165814.CA79E62570@hg.openjdk.java.net> Changeset: c4292590fc70 Author: vromero Date: 2013-10-19 17:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c4292590fc70 8024809: javac, some lambda programs are rejected by flow analysis Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! test/tools/javac/lambda/8016081/T8016081.java ! test/tools/javac/lambda/LambdaExpr13.java + test/tools/javac/lambda/T8024809/SelfInitializerInLambdaTesta.java + test/tools/javac/lambda/T8024809/SelfInitializerInLambdaTesta.out + test/tools/javac/lambda/T8024809/SelfInitializerInLambdaTestb.java + test/tools/javac/lambda/T8024809/SelfInitializerInLambdaTestb.out ! test/tools/javac/lambda/TestSelfRef.java From dmitry.samersoff at oracle.com Sat Oct 19 10:03:18 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Sat, 19 Oct 2013 17:03:18 +0000 Subject: hg: jdk8/tl/jdk: 8024071: In ManagementAgent.start it should be possible to set the jdp.name parameter. Message-ID: <20131019170333.8A13962571@hg.openjdk.java.net> Changeset: 392acefef659 Author: dsamersoff Date: 2013-10-19 20:59 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/392acefef659 8024071: In ManagementAgent.start it should be possible to set the jdp.name parameter. Summary: Pass one more property from Agent to JdpController Reviewed-by: jbachorik, sla ! src/share/classes/sun/management/Agent.java ! test/sun/management/jdp/JdpTest.sh ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh From staffan.larsen at oracle.com Sat Oct 19 10:42:17 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Sat, 19 Oct 2013 19:42:17 +0200 Subject: RFR: 8026789 Update test/java/lang/instrument/Re(transform|define)BigClass.sh test to use NMT for memory leak detection In-Reply-To: <52616372.6000100@oracle.com> References: <71403A99-3B7E-4323-9F83-23DB537DF5AC@oracle.com> <52616372.6000100@oracle.com> Message-ID: <82BC4270-CE1D-486F-A588-9F57BD7AD227@oracle.com> On 18 okt 2013, at 18:36, Daniel D. Daugherty wrote: > > webrev: http://cr.openjdk.java.net/~sla/8026789/webrev.00/ > > test/ProblemList.txt > Interesting. The tests are on the list via 8023201, but you're > tweaking the tests via 8026789. I'm guessing you don't want to > say (yet) that this fix resolved the 'leak' in 8023201. Yeah, it's a bit of a mixup here... > test/java/lang/instrument/RedefineBigClass.sh > No comments. > > test/java/lang/instrument/RedefineBigClassApp.java > line 38: // Do a short warmup before creating the NMT baseline > I think of 'warmup' as running code rather than sleeping. > Perhaps: > > // Give the VM some time for initial memory allocs to happen. The work is being done in the background by the Agent class, the App class just waits until the Agent is done. > The 'Kb' uses in the test should be 'KB'; 'Kb' is kilo-bits. I'll fix that. > test/java/lang/instrument/RetransformBigClass.sh > No comments. > > test/java/lang/instrument/RetransformBigClassApp.java > line 38: // Do a short warmup before creating the NMT baseline > Same comment as above. > > The 'Kb' uses in the test should be 'KB'; 'Kb' is kilo-bits. > > test/java/lang/instrument/NMTHelper.java > Nice, very nice. I wish there was a way to use the same syntax as the jcmd command line when using a JMX bean, though. Thanks, /Staffan > > Thumbs up. > > Dan > > > On 10/17/13 12:30 PM, Staffan Larsen wrote: >> The two tests currently use /proc/self/stat to read the virtual memory usage for the process. This only works on linux and only gives a single value to analyze. NMT works on all platforms and gives a lot more detail about where the memory is consumed. >> >> Without this fix, I can repro JDK-8023201 when stressing the machine heavily, but with this fix the test passes. The reason for this is probably that NMT uses a more granular measurement of committed memory, and not that the VM actually uses less memory. I have retained the memory growth limit of 32MB, but if that is a good value or not, I don't know. When stressing the test, I see NMT reporting about 1MB in committed memory growth. >> >> I have also removed the tests from ProblemList.txt. >> >> webrev: http://cr.openjdk.java.net/~sla/8026789/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8026789 >> >> Thanks, >> /Staffan >> > From kumar.x.srinivasan at oracle.com Sat Oct 19 15:22:37 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 19 Oct 2013 22:22:37 +0000 Subject: hg: jdk8/tl/jdk: 8026794: Test tools/pack200/TimeStamp.java fails while opening golden.jar.native.IST on linux-ppc(v2) Message-ID: <20131019222421.9D33C62574@hg.openjdk.java.net> Changeset: ede89a97e80a Author: ksrini Date: 2013-10-19 15:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ede89a97e80a 8026794: Test tools/pack200/TimeStamp.java fails while opening golden.jar.native.IST on linux-ppc(v2) Reviewed-by: dholmes ! src/share/native/com/sun/java/util/jar/pack/zip.cpp From dmitry.samersoff at oracle.com Sat Oct 19 16:52:48 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Sat, 19 Oct 2013 23:52:48 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8026930: In ManagementAgent.start it should be possible to set the jdp.name parameter (hotspot part) Message-ID: <20131019235258.C94D362577@hg.openjdk.java.net> Changeset: 996d1f2f056f Author: dsamersoff Date: 2013-10-19 21:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/996d1f2f056f 8026930: In ManagementAgent.start it should be possible to set the jdp.name parameter (hotspot part) Summary: Pass one more property from Agent to JdpController Reviewed-by: jbachorik, sla ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp From karen.kinnear at oracle.com Sat Oct 19 20:57:06 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Sun, 20 Oct 2013 03:57:06 +0000 Subject: hg: jdk8/tl/hotspot: 8026893: Push 8026365 to TL early and add test Message-ID: <20131020035724.7665D62581@hg.openjdk.java.net> Changeset: e39b138b2518 Author: acorn Date: 2013-10-19 18:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e39b138b2518 8026893: Push 8026365 to TL early and add test Reviewed-by: dcubed, kamg ! src/share/vm/classfile/verifier.cpp ! test/TEST.groups + test/runtime/8026365/InvokeSpecialAnonTest.java From jonathan.gibbons at oracle.com Sun Oct 20 12:05:49 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sun, 20 Oct 2013 19:05:49 +0000 Subject: hg: jdk8/tl/langtools: 8025109: Better encapsulation for AnnotatedType Message-ID: <20131020190557.63EAE6258F@hg.openjdk.java.net> Changeset: e5d3cd43c85e Author: jjg Date: 2013-10-20 12:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e5d3cd43c85e 8025109: Better encapsulation for AnnotatedType Reviewed-by: jjg Contributed-by: wdietl at gmail.com ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java From jonathan.gibbons at oracle.com Sun Oct 20 12:47:52 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sun, 20 Oct 2013 19:47:52 +0000 Subject: hg: jdk8/tl/langtools: 8026791: wrong type_path encoded for method_return on an inner class constructor Message-ID: <20131020194755.500B662595@hg.openjdk.java.net> Changeset: ae4f5cb78ebd Author: jjg Date: 2013-10-20 12:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ae4f5cb78ebd 8026791: wrong type_path encoded for method_return on an inner class constructor Reviewed-by: jjg Contributed-by: wdietl at gmail.com ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java From kumar.x.srinivasan at oracle.com Sun Oct 20 12:56:05 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sun, 20 Oct 2013 19:56:05 +0000 Subject: hg: jdk8/tl/langtools: 8026931: MethodParameters tests failing on Windows Message-ID: <20131020195608.29A9E62597@hg.openjdk.java.net> Changeset: 399c738e5103 Author: ksrini Date: 2013-10-20 12:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/399c738e5103 8026931: MethodParameters tests failing on Windows Reviewed-by: jjg, vromero ! test/tools/javac/MethodParameters/Tester.java From robert.field at oracle.com Sun Oct 20 18:09:08 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Mon, 21 Oct 2013 01:09:08 +0000 Subject: hg: jdk8/tl/jdk: 8025631: Enhance Lambda construction Message-ID: <20131021010923.9665062599@hg.openjdk.java.net> Changeset: 71ecbde5e5e4 Author: rfield Date: 2013-10-20 18:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71ecbde5e5e4 8025631: Enhance Lambda construction Reviewed-by: ksrini, ahgross ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java - src/share/classes/java/lang/invoke/MagicLambdaImpl.java From sundararajan.athijegannathan at oracle.com Mon Oct 21 00:42:36 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 21 Oct 2013 07:42:36 +0000 Subject: hg: jdk8/tl/nashorn: 2 new changesets Message-ID: <20131021074241.09385625A1@hg.openjdk.java.net> Changeset: d8aa87d292eb Author: hannesw Date: 2013-10-18 22:42 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d8aa87d292eb 8026858: Array length does not handle defined properties correctly Reviewed-by: jlaskey ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8026858.js Changeset: 612886fe324d Author: sundar Date: 2013-10-21 10:09 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/612886fe324d Merge From jaroslav.bachorik at oracle.com Mon Oct 21 01:47:49 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 21 Oct 2013 10:47:49 +0200 Subject: jmx-dev RFR 7197919: java/lang/management/ThreadMXBean/ThreadBlockedCount.java has concurency issues In-Reply-To: <526164F8.1070501@oracle.com> References: <525EA03F.2070106@oracle.com> <526164F8.1070501@oracle.com> Message-ID: <5264EA35.2070605@oracle.com> On 18.10.2013 18:42, Mandy Chung wrote: > On 10/16/2013 7:18 AM, Jaroslav Bachorik wrote: >> Please, review this simple test change. >> >> The test tries to get the number of times a certain thread was blocked >> during the test run and intermittently fails with the difference of 1 >> - the expected number is 4 but the reported number is 3. >> >> When updating the thread statistics (the blocked count in this case) >> no lock is used so there might be stale data when the ThreadMXBean >> retrieves the stats. The patch tries to workaround this problem by >> retrying a few times with the added delay. The test will try to obtain >> the correct result for at most 10 seconds - after that it will fail if >> the retrieved blocked count does not equal the expected blocked count. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-7197919 >> Webrev: http://cr.openjdk.java.net/~jbachorik/7197919/webrev.00 > > Looks okay. I notice that existing code that catches > InterruptedException only sets testFailed to true but continue. I think > it might be good to fix them to return if IE is caught to fail-fast like > what your fix does. Unfortunately, it's not possible to directly return in those cases. The synchronization logic relies on the code passing through all the "signal"/"waitForSignal" pairs for the test to finish - otherwise the test might just hang. I have at least added loop breaks to fail a bit faster in case of IE. -JB- > > Mandy From erik.helin at oracle.com Mon Oct 21 01:48:32 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 21 Oct 2013 10:48:32 +0200 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <20131018105644.GA2408@ehelin-thinkpad> References: <20131016160914.GA10865@ehelin-thinkpad> <525ED138.1000305@oracle.com> <20131017212852.GA6066@ehelin-thinkpad> <5260CBEB.1000902@oracle.com> <5260CF28.2040403@oracle.com> <5260E22E.1010503@oracle.com> <5260EA40.50200@oracle.com> <5260EB79.8080401@oracle.com> <20131018105644.GA2408@ehelin-thinkpad> Message-ID: <20131021084832.GC2608@ehelin-thinkpad> All, after having discussed this issue some more, I've decided to split it into multiple issues: - The crash when using -XX:+CheckUnhandledOops - Using MethodHandle instead of Method* - Using java_mirror() for anonymous classes I will send out a new webrev with a much smaller change that only solves the first issue (the crash with -XX:+CheckUnhandledOops). This review request will be labeled (round 2) as in: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops (round 2). For the other two issues, I have created the following two bugs: - https://bugs.openjdk.java.net/browse/JDK-8026946 - https://bugs.openjdk.java.net/browse/JDK-8026948 Everyone, thanks for all your feedback on this change! Erik On 2013-10-18, Erik Helin wrote: > Hi David and Serguei, > > thanks for having a look at this change! > > On 2013-10-18, David Holmes wrote: > > On 18/10/2013 5:58 PM, serguei.spitsyn at oracle.com wrote: > > >On 10/18/13 12:24 AM, serguei.spitsyn at oracle.com wrote: > > >>On 10/17/13 11:03 PM, David Holmes wrote: > > >>>On 18/10/2013 3:49 PM, serguei.spitsyn at oracle.com wrote: > > >>>>Hi Erik, > > >>>> > > >>>>The fix looks good in general. > > >>>> > > >>>>But one thing is confusing in the fix. > > >>>>Why do you keep both _class_loader and _class_loader_handle in the > > >>>>JvmtiBreakpoint class? > > >>> > > >>>Even more confusing to me is the fact the neither of these seem to > > >>>actually be used anywhere ??? > > >> > > >>Nice catch, David. > > >>I do not see too any of them is really used. > > >>Is it a leftover after the permgen elimination? > > > > > >Maybe this is a rush judging. > > >It depends on the closure->do_oop() that is used for traversing > > >I thought that the KeepAliveClosure is used below (basing on the comment). > > > > > >class JvmtiBreakpoint : public GrowableElement { > > > . . . > > > void oops_do(OopClosure* f) { > > > // Mark the method loader as live > > > f->do_oop(&_class_loader); > > > } > > > > > >This oops_do() is not needed if we have handle instead of oop. > > > > Ah! Maybe the only purpose of keeping the class_loader (whether oop > > or Handle) is that it is kept alive outside of its normal lifecycle. > > > > But still we should only need the Handle or the Oop, not both. And > > if there is no oop we should not need an oops_do. > > I will try to explain the problem, the current implementation and then > my change. > > The problem > ----------- > > The problem is that JvmtiEnv::SetBreakpoint and > JvmtiEnv::ClearBreakpoint are passed a Method*. We must ensure that the > class for this Method is kept alive by the GC. We do this by informing > the GC that it must visit the class loader for the Method's class when > marking. This can be done in two ways: > - Putting a Handle on the stack containing an oop to the class loader > - Have an oops_do method that we ensure will be called by the GC during > marking > > A third option is to make sure (by inspecting the code) that no GC can > occur that might cause problems, but this is a very brittle solution > once a new programmer comes along and adds/removes code. > > The current implementation > -------------------------- > > In JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint, we create a > JvmtiBreakpoint on the stack. This JvmtiBreakpoint contains an > "unhandled" oop to the class loader of the Method's class. > > A pointer to the JvmtiBreakpoint allocated on the stack will be passed > to VM_ChangeBreakpoint via JvmtiBreakpoints::set/clear. > In the doit() method of VM_ChangeBreakpoint, > JvmtiBreakpoints::set_at_safepoint will be called. A new JvmtiBreakpoint > will be allocated on the heap by JvmtiBreakpoints::set_at_safepoint. > > The JvmtiBreakpoint on the heap will contain the same oop as the one in > the JvmtiBreakpoint allocated on the stack earlier. The oop in the > JvmtiBreakpoint allocated on the heap will be found by the GC, because > VM_ChangeBreakpoint has an oops_do method (see first email for how this > oops_do method is called). > > Once the VM_ChangeBreakpoint operation is done, then the JvmtiBreakpoint > allocated on the heap will either be cleared due to a clear operation > (and we do not care about the oop any longer) or it will be placed in > JvmtiBreakpoints. JvmtiBreakpoints also has an oops_do which ensures > that the oop now will be found by the GC. > > We will now pop the call stack and return to JvmtiEnv::SetBreakpoint or > JvmtiEnv::ClearBreakpoint. No code in JvmtiEnv::SetBreakpoint or > JvmtiEnv::ClearBreakpoint is touching the JvmtiBreakpoint after the > VM_ChangeBreakpoint operation has been run. > > Furthermore, no GC can today occur before the call to VMThread::execute > in JvmtiBreakpoints::set/clear. > > This means that the current implementation is safe, but understanding > this is quite tricky. > > The change > ---------- > > My proposed solution was the following: > - When a JvmtiBreakpoint is allocated on the stack, place an oop to the > Method's class loader in a Handle. > - When a JvmtiBreakpoint is allocated on the heap, just store the oop to > Method's class lodear in a field. The JvmtiBreakpoint will be placed > in _jvmti_breakpoints which will be visited by the GC, which makes the > GC call JvmtiBreakpoint::oops_do. > > Of course, this means that that if a GC occurs before the > JvmtiBreakpoint in constructed in JvmtiEnv::SetBreakpoint or > JvmtiEnv::ClearBreakpoint, the Method's class might be garbage > collected. Ideally, we should wrap the Method* in jvmti_SetBreakpoint > and jvmti_ClearBreakpoint in jvmtiEnter.cpp (a cpp file generated from > an XML file via an XSL tranformation). > > As icing on the cake, if someone redefines the method that we are > receiving a pointer to, then this code will probably not work at all. I > believe (I am not sure) that this should be solved by having a > MethodHandle wrapping the Method*. > > This change is just a first step towards safer code. > > I've gotten feedback internally that it is hard to understand the > new code. I will try to see if I can update the change to make this > clearer. > > Thanks for getting all the way to the end of this email :) > > Erik > > > David > > > > > > > >> > > >>> > > >>>But if we have the Handle then the oop is redundant AFAICS. > > >> > > >>Right. > > >>The issue is that the oop version is used in the oops_do. > > >>Not sure if we can get rid of oops_do. > > >>It may have an empty body though. > > > > > >Getting rid of the oops_do will require more cleanup that needs to be > > >accurate. > > > > > > > > >Thanks, > > >Serguei > > > > > >> > > >> > > >>Thanks, > > >>Serguei > > >> > > >>> > > >>>David > > >>> > > >>>>Also, you need to run the nsk.jdi.testlist and nsk.jdwp.testlist test > > >>>>suites as well. > > >>>> > > >>>>Thanks, > > >>>>Serguei > > >>>> > > >>>> > > >>>>On 10/17/13 2:28 PM, Erik Helin wrote: > > >>>>>Hi Mikael and Coleen, > > >>>>> > > >>>>>thanks for your reviews! > > >>>>> > > >>>>>On 2013-10-16, Mikael Gerdin wrote: > > >>>>>>jvmtiImpl.hpp: > > >>>>>>Since clone() uses unhandled oops, and is only supposed to be used > > >>>>>>by the VM operation, would it make sense to > > >>>>>>assert(SafepointSynchronize::is_at_safepoint())? > > >>>>>> > > >>>>>>196 GrowableElement *clone() { > > >>>>>> 197 return new JvmtiBreakpoint(_method, _bci, > > >>>>>>_class_loader_handle); > > >>>>>Agree, I've updated the patch. A new webrev is located at: > > >>>>>http://cr.openjdk.java.net/~ehelin/8025834/webrev.01/ > > >>>>> > > >>>>>On 2013-10-16, Mikael Gerdin wrote: > > >>>>>>jvmtiEnv.cpp: > > >>>>>>Have you verified that the generated JVMTI entry point contains a > > >>>>>>ResourceMark or is it just not needed? > > >>>>>>- ResourceMark rm; > > >>>>>>+ HandleMark hm; > > >>>>>The JVMTI entry point does not contain a ResourceMark. However, I have > > >>>>>verified that a ResourceMark is not needed for jvmtiEnv::SetBreakpoint > > >>>>>nor for jvmtiEnv::ClearBreapoint. The only codes that needs a > > >>>>>ResourceMark is JvmtiBreakpoints::prints, but that method already > > >>>>>has a > > >>>>>ResourceMark. > > >>>>> > > >>>>>On 2013-10-16, Coleen Phillimore wrote: > > >>>>>>Did you run the nsk.jvmti.testlist tests too though? > > >>>>>No, I had not run the nsk.jvmti.testlist test, but I have now :) > > >>>>> > > >>>>>I run both with and without the patch on the latest hsx/hotspot-gc. I > > >>>>>also run with and without -XX:+CheckUnhandledOops. The results were > > >>>>>all > > >>>>>the same: 598 passed an 11 failed (the same tests for all > > >>>>>combinations). > > >>>>>So, the patch does not introduce any regressions for this test suite. > > >>>>> > > >>>>>Thanks, > > >>>>>Erik > > >>>>> > > >>>>>On 2013-10-16, Mikael Gerdin wrote: > > >>>>>>Erik, > > >>>>>> > > >>>>>>(it's not necessary to cross-post between hotspot-dev and > > >>>>>>hotspot-gc-dev, so I removed hotspot-gc from the CC list) > > >>>>>> > > >>>>>>On 2013-10-16 18:09, Erik Helin wrote: > > >>>>>>>Hi all, > > >>>>>>> > > >>>>>>>this patch fixes an issue where an oop in JvmtiBreakpoint, > > >>>>>>>JvmtiBreakpoint::_class_loader, was found by the unhandled oop > > >>>>>>>detector. > > >>>>>>> > > >>>>>>>Instead of registering the oop as an unhandled oop, which would have > > >>>>>>>worked, I decided to wrap the oop in a handle as long as it is on > > >>>>>>>the > > >>>>>>>stack. > > >>>>>>> > > >>>>>>>A JvmtiBreakpoint is created on the stack by the two methods > > >>>>>>>JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This > > >>>>>>>JvmtiBreakpoint is only created to carry the Method*, jlocation > > >>>>>>>and oop > > >>>>>>>to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, > > >>>>>>>when > > >>>>>>>at a safepoint, allocate a new JvmtiBreakpoint on the native > > >>>>>>>heap, copy > > >>>>>>>the values from the stack allocated JvmtiBreakpoint and then > > >>>>>>>place/clear the > > >>>>>>>newly alloacted JvmtiBreakpoint in > > >>>>>>>JvmtiCurrentBreakpoints::_jvmti_breakpoints. > > >>>>>>> > > >>>>>>>I have updated to the code to check that the public constructor > > >>>>>>>is only > > >>>>>>>used to allocate JvmtiBreakpoints on the stack (to warn a future > > >>>>>>>programmer if he/she decides to allocate one on the heap). The > > >>>>>>>class_loader oop is now wrapped in a Handle for stack allocated > > >>>>>>>JvmtiBreakpoints. > > >>>>>>> > > >>>>>>>Due to the stack allocated JvmtiBreakpoint having the oop in a > > >>>>>>>handle, > > >>>>>>>the oops_do method of VM_ChangeBreakpoints can be removed. This also > > >>>>>>>makes the oop in the handle safe for use after the > > >>>>>>>VM_ChangeBreakpoint > > >>>>>>>operation is finished. > > >>>>>>> > > >>>>>>>The unhandled oop in the JvmtiBreakpoint allocated on the heap > > >>>>>>>will be > > >>>>>>>visited by the GC via jvmtiExport::oops_do -> > > >>>>>>>JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> > > >>>>>>>GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is > > >>>>>>>being > > >>>>>>>added to. > > >>>>>>> > > >>>>>>>I've also removed some dead code to simplify the change: > > >>>>>>>- GrowableCache::insert > > >>>>>>>- JvmtiBreakpoint::copy > > >>>>>>>- JvmtiBreakpoint::lessThan > > >>>>>>>- GrowableElement::lessThan > > >>>>>>> > > >>>>>>>Finally, I also formatted JvmtiEnv::ClearBreakpoint and > > >>>>>>>Jvmti::SetBreakpoint exactly the same to highlight that they > > >>>>>>>share all > > >>>>>>>code except one line. Unfortunately, I was not able to remove > > >>>>>>>this code > > >>>>>>>duplication in a good way. > > >>>>>>> > > >>>>>>>Webrev: > > >>>>>>>http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ > > >>>>>>jvmtiImpl.hpp: > > >>>>>>Since clone() uses unhandled oops, and is only supposed to be used > > >>>>>>by the VM operation, would it make sense to > > >>>>>>assert(SafepointSynchronize::is_at_safepoint())? > > >>>>>> > > >>>>>>196 GrowableElement *clone() { > > >>>>>> 197 return new JvmtiBreakpoint(_method, _bci, > > >>>>>>_class_loader_handle); > > >>>>>> > > >>>>>>jvmtiImpl.cpp: > > >>>>>>No comments. > > >>>>>> > > >>>>>>jvmtiEnv.cpp: > > >>>>>>Have you verified that the generated JVMTI entry point contains a > > >>>>>>ResourceMark or is it just not needed? > > >>>>>>- ResourceMark rm; > > >>>>>>+ HandleMark hm; > > >>>>>> > > >>>>>>Otherwise the code change looks good. > > >>>>>> > > >>>>>> > > >>>>>>One thing that you didn't describe here, but which was related to > > >>>>>>the bug (which we discussed) was the fact that the old code tried to > > >>>>>>"do the right thing" WRT CheckUnhandledOops, but it incorrectly > > >>>>>>added a Method*: > > >>>>>> > > >>>>>>thread->allow_unhandled_oop((oop*)&_method); > > >>>>>> > > >>>>>>We should take care to find other such places where we try to put a > > >>>>>>non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in > > >>>>>>the unhandled oops code. > > >>>>>> > > >>>>>>/Mikael > > >>>>>> > > >>>>>>>Testing: > > >>>>>>>- JPRT > > >>>>>>>- The four tests that were failing are now passing > > >>>>>>> > > >>>>>>>Thanks, > > >>>>>>>Erik > > >>>>>>> > > >>>> > > >> > > > From jaroslav.bachorik at oracle.com Mon Oct 21 01:51:42 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Mon, 21 Oct 2013 08:51:42 +0000 Subject: hg: jdk8/tl/jdk: 7197919: java/lang/management/ThreadMXBean/ThreadBlockedCount.java has concurency issues Message-ID: <20131021085242.BFA25625A4@hg.openjdk.java.net> Changeset: 30c46debdf0f Author: jbachorik Date: 2013-10-21 10:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/30c46debdf0f 7197919: java/lang/management/ThreadMXBean/ThreadBlockedCount.java has concurency issues Reviewed-by: sla, mchung ! test/java/lang/management/ThreadMXBean/ThreadBlockedCount.java From daniel.fuchs at oracle.com Mon Oct 21 02:18:54 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Mon, 21 Oct 2013 09:18:54 +0000 Subject: hg: jdk8/tl/jdk: 8016344: (props) Properties.storeToXML behaviour has changed from JDK 6 to 7 Message-ID: <20131021091921.77D07625A7@hg.openjdk.java.net> Changeset: 567d47fd3fe2 Author: dfuchs Date: 2013-10-21 11:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/567d47fd3fe2 8016344: (props) Properties.storeToXML behaviour has changed from JDK 6 to 7 Summary: When storing Properties to XML only locally defined properties must be saved. Reviewed-by: psandoz, mchung, alanb ! src/share/classes/jdk/internal/util/xml/PropertiesDefaultHandler.java ! src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java + test/java/util/Properties/LoadAndStoreXMLWithDefaults.java From erik.helin at oracle.com Mon Oct 21 02:26:51 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 21 Oct 2013 11:26:51 +0200 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops (round 2) Message-ID: <20131021092651.GD2608@ehelin-thinkpad> Hi all, this is the second version of a patch for JDK-8025834. Background: In JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint, we create a JvmtiBreakpoint on the stack. This JvmtiBreakpoint contains an "unhandled" oop to the class loader of the Method's class. A pointer to the JvmtiBreakpoint allocated on the stack will be passed to VM_ChangeBreakpoint via JvmtiBreakpoints::set/clear. The VM_ChangeBreakpoint class has an oops_do method that will visit the oop in the JvmtiBreakpoint that was allocated on the stack. Since no GC can occur before the JvmtiBreakpoint has been passed to the VM_ChangeBreakpoint (which is then passed to VMThread::execute), there is no need to have a Handle for the _class_loader oop. Once the VM_ChangeBreakpoint is on the VMThread's list for being executed, the oop will be found via VMThread::oops_do. The oop can't be changed to a Handle because JvmtiBreakpoint:s are also allocated on the heap, and Handles are only used for oops allocated on the stack. This patch therefore registers the oop as "unhandled" to tell the unhandled oop verifier to (rightfully) ignore it. Webrev: http://cr.openjdk.java.net/~ehelin/8025834/round-2/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8025834 As I explained in a previous email, there are additional issues in the JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreapoints methods: - https://bugs.openjdk.java.net/browse/JDK-8026946 - https://bugs.openjdk.java.net/browse/JDK-8026948 This change does not intend to fix these issues. Thanks, Erik From dmitry.samersoff at oracle.com Mon Oct 21 02:50:52 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 21 Oct 2013 13:50:52 +0400 Subject: RR(XS): JDK-8026950 Nits in agent ps_proc.c file breaks compilation of open hotspot Message-ID: <5264F8FC.7040307@oracle.com> Hi Everybody, Please review a small fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8026950/webrev.01/ -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.fuchs at oracle.com Mon Oct 21 03:07:31 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Mon, 21 Oct 2013 10:07:31 +0000 Subject: hg: jdk8/tl/jdk: 8026499: Root Logger level can be reset unexpectedly Message-ID: <20131021100830.7177E625B0@hg.openjdk.java.net> Changeset: c81125493ca6 Author: dfuchs Date: 2013-10-21 12:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c81125493ca6 8026499: Root Logger level can be reset unexpectedly Summary: This fix prevents the logger's level to be re-initialized if it has already been initialized. Reviewed-by: mchung ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/LogManager/RootLogger/setLevel/TestRootLoggerLevel.java From jaroslav.bachorik at oracle.com Mon Oct 21 04:03:04 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 21 Oct 2013 13:03:04 +0200 Subject: RFR 7140929: NotSerializableNotifTest.java fails intermittently Message-ID: <526509E8.4030002@oracle.com> Hi, please, review the following small test change: Issue: https://bugs.openjdk.java.net/browse/JDK-7140929 Webrev: http://cr.openjdk.java.net/~jbachorik/7140929/webrev.00 The test fails intermittently, mostly when it is run with -Xcomp option. The failure is due to fixed timeout used in the test when waiting for the notifications arrival. Tests of such slow configurations are run with "timeoutfactor" set but the NotSerializableNotifTest does not respect the timeoutfactor. The patch allows the test to reflect the provided "timeoutfactor" and therefore successfully pass even when -Xcomp is used. Thanks, -JB- From jaroslav.bachorik at oracle.com Mon Oct 21 01:56:56 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Mon, 21 Oct 2013 08:56:56 +0000 Subject: hg: jdk8/tl/jdk: 8024613: javax/management/remote/mandatory/connection/RMIConnector_NPETest.java failing intermittently Message-ID: <20131021085715.40CD9625A5@hg.openjdk.java.net> Changeset: d8694ad1ed2d Author: jbachorik Date: 2013-10-21 10:54 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d8694ad1ed2d 8024613: javax/management/remote/mandatory/connection/RMIConnector_NPETest.java failing intermittently Summary: RMID needs a varying amount of time to start its socket server. We need to cater for it. Reviewed-by: sjiang, dfuchs, sla ! test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java From mikael.gerdin at oracle.com Mon Oct 21 04:07:02 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 21 Oct 2013 13:07:02 +0200 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops (round 2) In-Reply-To: <20131021092651.GD2608@ehelin-thinkpad> References: <20131021092651.GD2608@ehelin-thinkpad> Message-ID: <2541260.D7TBTJESY6@mgerdin03> Erik, On Monday 21 October 2013 11.26.51 Erik Helin wrote: > Hi all, > > this is the second version of a patch for JDK-8025834. > > Background: > In JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint, we create a > JvmtiBreakpoint on the stack. This JvmtiBreakpoint contains an > "unhandled" oop to the class loader of the Method's class. > > A pointer to the JvmtiBreakpoint allocated on the stack will be passed > to VM_ChangeBreakpoint via JvmtiBreakpoints::set/clear. The > VM_ChangeBreakpoint class has an oops_do method that will visit the oop > in the JvmtiBreakpoint that was allocated on the stack. > > Since no GC can occur before the JvmtiBreakpoint has been passed to the > VM_ChangeBreakpoint (which is then passed to VMThread::execute), there > is no need to have a Handle for the _class_loader oop. Once the > VM_ChangeBreakpoint is on the VMThread's list for being executed, the > oop will be found via VMThread::oops_do. > > The oop can't be changed to a Handle because JvmtiBreakpoint:s are also > allocated on the heap, and Handles are only used for oops allocated on > the stack. > > This patch therefore registers the oop as "unhandled" to tell the > unhandled oop verifier to (rightfully) ignore it. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8025834/round-2/webrev.00/ The change looks good to me. /Mikael > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8025834 > > As I explained in a previous email, there are additional issues in the > JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreapoints methods: > - https://bugs.openjdk.java.net/browse/JDK-8026946 > - https://bugs.openjdk.java.net/browse/JDK-8026948 > This change does not intend to fix these issues. > > Thanks, > Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131021/fb4441bf/attachment-0001.html From Alan.Bateman at oracle.com Mon Oct 21 04:20:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Oct 2013 12:20:17 +0100 Subject: RFR 7140929: NotSerializableNotifTest.java fails intermittently In-Reply-To: <526509E8.4030002@oracle.com> References: <526509E8.4030002@oracle.com> Message-ID: <52650DF1.2050008@oracle.com> On 21/10/2013 12:03, Jaroslav Bachorik wrote: > Hi, > > please, review the following small test change: > > Issue: https://bugs.openjdk.java.net/browse/JDK-7140929 > Webrev: http://cr.openjdk.java.net/~jbachorik/7140929/webrev.00 > > The test fails intermittently, mostly when it is run with -Xcomp > option. The failure is due to fixed timeout used in the test when > waiting for the notifications arrival. Tests of such slow > configurations are run with "timeoutfactor" set but the > NotSerializableNotifTest does not respect the timeoutfactor. > > The patch allows the test to reflect the provided "timeoutfactor" and > therefore successfully pass even when -Xcomp is used. Good to see test.timeout.factor being used (I think a lot of tests could benefit from using it). The change in the webrev looks okay, in the sense that you have scaled the existing 10s timeout. -Alan. From staffan.larsen at oracle.com Mon Oct 21 04:42:54 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 21 Oct 2013 13:42:54 +0200 Subject: RR(XS): JDK-8026950 Nits in agent ps_proc.c file breaks compilation of open hotspot In-Reply-To: <5264F8FC.7040307@oracle.com> References: <5264F8FC.7040307@oracle.com> Message-ID: <4D200679-D0B9-482B-80A4-85877FA1FBBF@oracle.com> Looks good! Thanks, /Staffan On 21 okt 2013, at 11:50, Dmitry Samersoff wrote: > Hi Everybody, > > Please review a small fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8026950/webrev.01/ > > -Dmitry > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From shanliang.jiang at oracle.com Mon Oct 21 04:45:53 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 21 Oct 2013 13:45:53 +0200 Subject: jmx-dev RFR 7140929: NotSerializableNotifTest.java fails intermittently In-Reply-To: <526509E8.4030002@oracle.com> References: <526509E8.4030002@oracle.com> Message-ID: <526513F1.4080700@oracle.com> Jaroslav, Look fine to me, thanks to fix the timing. Next time we may need to fix its fixed port:) Shanliang Jaroslav Bachorik wrote: > Hi, > > please, review the following small test change: > > Issue: https://bugs.openjdk.java.net/browse/JDK-7140929 > Webrev: http://cr.openjdk.java.net/~jbachorik/7140929/webrev.00 > > The test fails intermittently, mostly when it is run with -Xcomp > option. The failure is due to fixed timeout used in the test when > waiting for the notifications arrival. Tests of such slow > configurations are run with "timeoutfactor" set but the > NotSerializableNotifTest does not respect the timeoutfactor. > > The patch allows the test to reflect the provided "timeoutfactor" and > therefore successfully pass even when -Xcomp is used. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Mon Oct 21 04:55:50 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 21 Oct 2013 13:55:50 +0200 Subject: RFR 6309226: TEST: java/lang/management/ThreadMXBean/SynchronizationStatistics.java didn't check Thread.sleep Message-ID: <52651646.4050705@oracle.com> Please, review this small patch for a test failing due to the updated implementation in JDK6. Issue: https://bugs.openjdk.java.net/browse/JDK-6309226 Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.00/ The test fails due to the change in mustang where ThreadMXBean.getThreadInfo().getWaitedTime() and ThreadMXBean.getThreadInfo().getWaitedCount() include Thread.sleep() too. Unfortunately, Thread.sleep() is used throughout the test for synchronization purposes and this breaks the test. In the patch I propose to replace Thread.sleep() with busy wait and hinting the scheduler by Thread.yield(). While not very elegant it successfully works around inclusion of unknown number of Thread.sleep()s (they are called in loop). Thanks, -JB- From jaroslav.bachorik at oracle.com Mon Oct 21 04:59:53 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Mon, 21 Oct 2013 11:59:53 +0000 Subject: hg: jdk8/tl/jdk: 7140929: NotSerializableNotifTest.java fails intermittently Message-ID: <20131021120131.16C9B625B2@hg.openjdk.java.net> Changeset: 698baf22e081 Author: jbachorik Date: 2013-10-21 13:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/698baf22e081 7140929: NotSerializableNotifTest.java fails intermittently Reviewed-by: sjiang, alanb ! test/javax/management/remote/mandatory/notif/NotSerializableNotifTest.java From erik.helin at oracle.com Mon Oct 21 05:36:14 2013 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 21 Oct 2013 14:36:14 +0200 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops (round 2) In-Reply-To: <2541260.D7TBTJESY6@mgerdin03> References: <20131021092651.GD2608@ehelin-thinkpad> <2541260.D7TBTJESY6@mgerdin03> Message-ID: <20131021123614.GA10430@ehelin-thinkpad> Hi Mikael, thanks for reviewing! Based on internal feedback, I've updated the comment slightly: diff --git a/src/share/vm/prims/jvmtiImpl.cpp b/src/share/vm/prims/jvmtiImpl.cpp --- a/src/share/vm/prims/jvmtiImpl.cpp +++ b/src/share/vm/prims/jvmtiImpl.cpp @@ -225,18 +225,20 @@ _method = NULL; _bci = 0; _class_loader = NULL; -#ifdef CHECK_UNHANDLED_OOPS - // This one is always allocated with new, but check it just in case. - Thread *thread = Thread::current(); - if (thread->is_in_stack((address)&_method)) { - thread->allow_unhandled_oop((oop*)&_method); - } -#endif // CHECK_UNHANDLED_OOPS } JvmtiBreakpoint::JvmtiBreakpoint(Method* m_method, jlocation location) { _method = m_method; _class_loader = _method->method_holder()->class_loader_data()->class_loader(); +#ifdef CHECK_UNHANDLED_OOPS + // _class_loader can't be wrapped in a Handle, because JvmtiBreakpoint:s are + // eventually allocated on the heap. + // + // The code handling JvmtiBreakpoint:s allocated on the stack can't be + // interrupted by a GC until _class_loader is reachable by the GC via the + // oops_do method. + Thread::current()->allow_unhandled_oop(&_class_loader); +#endif // CHECK_UNHANDLED_OOPS assert(_method != NULL, "_method != NULL"); _bci = (int) location; assert(_bci >= 0, "_bci >= 0"); What do you think? Thanks, Erik On 2013-10-21, Mikael Gerdin wrote: > Erik, > > On Monday 21 October 2013 11.26.51 Erik Helin wrote: > > Hi all, > > > > this is the second version of a patch for JDK-8025834. > > > > Background: > > In JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint, we create a > > JvmtiBreakpoint on the stack. This JvmtiBreakpoint contains an > > "unhandled" oop to the class loader of the Method's class. > > > > A pointer to the JvmtiBreakpoint allocated on the stack will be passed > > to VM_ChangeBreakpoint via JvmtiBreakpoints::set/clear. The > > VM_ChangeBreakpoint class has an oops_do method that will visit the oop > > in the JvmtiBreakpoint that was allocated on the stack. > > > > Since no GC can occur before the JvmtiBreakpoint has been passed to the > > VM_ChangeBreakpoint (which is then passed to VMThread::execute), there > > is no need to have a Handle for the _class_loader oop. Once the > > VM_ChangeBreakpoint is on the VMThread's list for being executed, the > > oop will be found via VMThread::oops_do. > > > > The oop can't be changed to a Handle because JvmtiBreakpoint:s are also > > allocated on the heap, and Handles are only used for oops allocated on > > the stack. > > > > This patch therefore registers the oop as "unhandled" to tell the > > unhandled oop verifier to (rightfully) ignore it. > > > > Webrev: > > http://cr.openjdk.java.net/~ehelin/8025834/round-2/webrev.00/ > > The change looks good to me. > > /Mikael > > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8025834 > > > > As I explained in a previous email, there are additional issues in the > > JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreapoints methods: > > - https://bugs.openjdk.java.net/browse/JDK-8026946 > > - https://bugs.openjdk.java.net/browse/JDK-8026948 > > This change does not intend to fix these issues. > > > > Thanks, > > Erik > From coleen.phillimore at oracle.com Mon Oct 21 07:07:19 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 21 Oct 2013 10:07:19 -0400 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops In-Reply-To: <20131021084832.GC2608@ehelin-thinkpad> References: <20131016160914.GA10865@ehelin-thinkpad> <525ED138.1000305@oracle.com> <20131017212852.GA6066@ehelin-thinkpad> <5260CBEB.1000902@oracle.com> <5260CF28.2040403@oracle.com> <5260E22E.1010503@oracle.com> <5260EA40.50200@oracle.com> <5260EB79.8080401@oracle.com> <20131018105644.GA2408@ehelin-thinkpad> <20131021084832.GC2608@ehelin-thinkpad> Message-ID: <52653517.5010502@oracle.com> This sounds reasonable. Coleen On 10/21/2013 04:48 AM, Erik Helin wrote: > All, > > after having discussed this issue some more, I've decided to split it into > multiple issues: > - The crash when using -XX:+CheckUnhandledOops > - Using MethodHandle instead of Method* > - Using java_mirror() for anonymous classes > > I will send out a new webrev with a much smaller change that only solves > the first issue (the crash with -XX:+CheckUnhandledOops). This review request > will be labeled (round 2) as in: > RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops (round 2). > > For the other two issues, I have created the following two bugs: > - https://bugs.openjdk.java.net/browse/JDK-8026946 > - https://bugs.openjdk.java.net/browse/JDK-8026948 > > Everyone, thanks for all your feedback on this change! > Erik > > On 2013-10-18, Erik Helin wrote: >> Hi David and Serguei, >> >> thanks for having a look at this change! >> >> On 2013-10-18, David Holmes wrote: >>> On 18/10/2013 5:58 PM, serguei.spitsyn at oracle.com wrote: >>>> On 10/18/13 12:24 AM, serguei.spitsyn at oracle.com wrote: >>>>> On 10/17/13 11:03 PM, David Holmes wrote: >>>>>> On 18/10/2013 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Erik, >>>>>>> >>>>>>> The fix looks good in general. >>>>>>> >>>>>>> But one thing is confusing in the fix. >>>>>>> Why do you keep both _class_loader and _class_loader_handle in the >>>>>>> JvmtiBreakpoint class? >>>>>> Even more confusing to me is the fact the neither of these seem to >>>>>> actually be used anywhere ??? >>>>> Nice catch, David. >>>>> I do not see too any of them is really used. >>>>> Is it a leftover after the permgen elimination? >>>> Maybe this is a rush judging. >>>> It depends on the closure->do_oop() that is used for traversing >>>> I thought that the KeepAliveClosure is used below (basing on the comment). >>>> >>>> class JvmtiBreakpoint : public GrowableElement { >>>> . . . >>>> void oops_do(OopClosure* f) { >>>> // Mark the method loader as live >>>> f->do_oop(&_class_loader); >>>> } >>>> >>>> This oops_do() is not needed if we have handle instead of oop. >>> Ah! Maybe the only purpose of keeping the class_loader (whether oop >>> or Handle) is that it is kept alive outside of its normal lifecycle. >>> >>> But still we should only need the Handle or the Oop, not both. And >>> if there is no oop we should not need an oops_do. >> I will try to explain the problem, the current implementation and then >> my change. >> >> The problem >> ----------- >> >> The problem is that JvmtiEnv::SetBreakpoint and >> JvmtiEnv::ClearBreakpoint are passed a Method*. We must ensure that the >> class for this Method is kept alive by the GC. We do this by informing >> the GC that it must visit the class loader for the Method's class when >> marking. This can be done in two ways: >> - Putting a Handle on the stack containing an oop to the class loader >> - Have an oops_do method that we ensure will be called by the GC during >> marking >> >> A third option is to make sure (by inspecting the code) that no GC can >> occur that might cause problems, but this is a very brittle solution >> once a new programmer comes along and adds/removes code. >> >> The current implementation >> -------------------------- >> >> In JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint, we create a >> JvmtiBreakpoint on the stack. This JvmtiBreakpoint contains an >> "unhandled" oop to the class loader of the Method's class. >> >> A pointer to the JvmtiBreakpoint allocated on the stack will be passed >> to VM_ChangeBreakpoint via JvmtiBreakpoints::set/clear. >> In the doit() method of VM_ChangeBreakpoint, >> JvmtiBreakpoints::set_at_safepoint will be called. A new JvmtiBreakpoint >> will be allocated on the heap by JvmtiBreakpoints::set_at_safepoint. >> >> The JvmtiBreakpoint on the heap will contain the same oop as the one in >> the JvmtiBreakpoint allocated on the stack earlier. The oop in the >> JvmtiBreakpoint allocated on the heap will be found by the GC, because >> VM_ChangeBreakpoint has an oops_do method (see first email for how this >> oops_do method is called). >> >> Once the VM_ChangeBreakpoint operation is done, then the JvmtiBreakpoint >> allocated on the heap will either be cleared due to a clear operation >> (and we do not care about the oop any longer) or it will be placed in >> JvmtiBreakpoints. JvmtiBreakpoints also has an oops_do which ensures >> that the oop now will be found by the GC. >> >> We will now pop the call stack and return to JvmtiEnv::SetBreakpoint or >> JvmtiEnv::ClearBreakpoint. No code in JvmtiEnv::SetBreakpoint or >> JvmtiEnv::ClearBreakpoint is touching the JvmtiBreakpoint after the >> VM_ChangeBreakpoint operation has been run. >> >> Furthermore, no GC can today occur before the call to VMThread::execute >> in JvmtiBreakpoints::set/clear. >> >> This means that the current implementation is safe, but understanding >> this is quite tricky. >> >> The change >> ---------- >> >> My proposed solution was the following: >> - When a JvmtiBreakpoint is allocated on the stack, place an oop to the >> Method's class loader in a Handle. >> - When a JvmtiBreakpoint is allocated on the heap, just store the oop to >> Method's class lodear in a field. The JvmtiBreakpoint will be placed >> in _jvmti_breakpoints which will be visited by the GC, which makes the >> GC call JvmtiBreakpoint::oops_do. >> >> Of course, this means that that if a GC occurs before the >> JvmtiBreakpoint in constructed in JvmtiEnv::SetBreakpoint or >> JvmtiEnv::ClearBreakpoint, the Method's class might be garbage >> collected. Ideally, we should wrap the Method* in jvmti_SetBreakpoint >> and jvmti_ClearBreakpoint in jvmtiEnter.cpp (a cpp file generated from >> an XML file via an XSL tranformation). >> >> As icing on the cake, if someone redefines the method that we are >> receiving a pointer to, then this code will probably not work at all. I >> believe (I am not sure) that this should be solved by having a >> MethodHandle wrapping the Method*. >> >> This change is just a first step towards safer code. >> >> I've gotten feedback internally that it is hard to understand the >> new code. I will try to see if I can update the change to make this >> clearer. >> >> Thanks for getting all the way to the end of this email :) >> >> Erik >> >>> David >>> >>>>>> But if we have the Handle then the oop is redundant AFAICS. >>>>> Right. >>>>> The issue is that the oop version is used in the oops_do. >>>>> Not sure if we can get rid of oops_do. >>>>> It may have an empty body though. >>>> Getting rid of the oops_do will require more cleanup that needs to be >>>> accurate. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> David >>>>>> >>>>>>> Also, you need to run the nsk.jdi.testlist and nsk.jdwp.testlist test >>>>>>> suites as well. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 10/17/13 2:28 PM, Erik Helin wrote: >>>>>>>> Hi Mikael and Coleen, >>>>>>>> >>>>>>>> thanks for your reviews! >>>>>>>> >>>>>>>> On 2013-10-16, Mikael Gerdin wrote: >>>>>>>>> jvmtiImpl.hpp: >>>>>>>>> Since clone() uses unhandled oops, and is only supposed to be used >>>>>>>>> by the VM operation, would it make sense to >>>>>>>>> assert(SafepointSynchronize::is_at_safepoint())? >>>>>>>>> >>>>>>>>> 196 GrowableElement *clone() { >>>>>>>>> 197 return new JvmtiBreakpoint(_method, _bci, >>>>>>>>> _class_loader_handle); >>>>>>>> Agree, I've updated the patch. A new webrev is located at: >>>>>>>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.01/ >>>>>>>> >>>>>>>> On 2013-10-16, Mikael Gerdin wrote: >>>>>>>>> jvmtiEnv.cpp: >>>>>>>>> Have you verified that the generated JVMTI entry point contains a >>>>>>>>> ResourceMark or is it just not needed? >>>>>>>>> - ResourceMark rm; >>>>>>>>> + HandleMark hm; >>>>>>>> The JVMTI entry point does not contain a ResourceMark. However, I have >>>>>>>> verified that a ResourceMark is not needed for jvmtiEnv::SetBreakpoint >>>>>>>> nor for jvmtiEnv::ClearBreapoint. The only codes that needs a >>>>>>>> ResourceMark is JvmtiBreakpoints::prints, but that method already >>>>>>>> has a >>>>>>>> ResourceMark. >>>>>>>> >>>>>>>> On 2013-10-16, Coleen Phillimore wrote: >>>>>>>>> Did you run the nsk.jvmti.testlist tests too though? >>>>>>>> No, I had not run the nsk.jvmti.testlist test, but I have now :) >>>>>>>> >>>>>>>> I run both with and without the patch on the latest hsx/hotspot-gc. I >>>>>>>> also run with and without -XX:+CheckUnhandledOops. The results were >>>>>>>> all >>>>>>>> the same: 598 passed an 11 failed (the same tests for all >>>>>>>> combinations). >>>>>>>> So, the patch does not introduce any regressions for this test suite. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Erik >>>>>>>> >>>>>>>> On 2013-10-16, Mikael Gerdin wrote: >>>>>>>>> Erik, >>>>>>>>> >>>>>>>>> (it's not necessary to cross-post between hotspot-dev and >>>>>>>>> hotspot-gc-dev, so I removed hotspot-gc from the CC list) >>>>>>>>> >>>>>>>>> On 2013-10-16 18:09, Erik Helin wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> this patch fixes an issue where an oop in JvmtiBreakpoint, >>>>>>>>>> JvmtiBreakpoint::_class_loader, was found by the unhandled oop >>>>>>>>>> detector. >>>>>>>>>> >>>>>>>>>> Instead of registering the oop as an unhandled oop, which would have >>>>>>>>>> worked, I decided to wrap the oop in a handle as long as it is on >>>>>>>>>> the >>>>>>>>>> stack. >>>>>>>>>> >>>>>>>>>> A JvmtiBreakpoint is created on the stack by the two methods >>>>>>>>>> JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint. This >>>>>>>>>> JvmtiBreakpoint is only created to carry the Method*, jlocation >>>>>>>>>> and oop >>>>>>>>>> to a VM operation, VM_ChangeBreakpoints. VM_ChangeBreakpoints will, >>>>>>>>>> when >>>>>>>>>> at a safepoint, allocate a new JvmtiBreakpoint on the native >>>>>>>>>> heap, copy >>>>>>>>>> the values from the stack allocated JvmtiBreakpoint and then >>>>>>>>>> place/clear the >>>>>>>>>> newly alloacted JvmtiBreakpoint in >>>>>>>>>> JvmtiCurrentBreakpoints::_jvmti_breakpoints. >>>>>>>>>> >>>>>>>>>> I have updated to the code to check that the public constructor >>>>>>>>>> is only >>>>>>>>>> used to allocate JvmtiBreakpoints on the stack (to warn a future >>>>>>>>>> programmer if he/she decides to allocate one on the heap). The >>>>>>>>>> class_loader oop is now wrapped in a Handle for stack allocated >>>>>>>>>> JvmtiBreakpoints. >>>>>>>>>> >>>>>>>>>> Due to the stack allocated JvmtiBreakpoint having the oop in a >>>>>>>>>> handle, >>>>>>>>>> the oops_do method of VM_ChangeBreakpoints can be removed. This also >>>>>>>>>> makes the oop in the handle safe for use after the >>>>>>>>>> VM_ChangeBreakpoint >>>>>>>>>> operation is finished. >>>>>>>>>> >>>>>>>>>> The unhandled oop in the JvmtiBreakpoint allocated on the heap >>>>>>>>>> will be >>>>>>>>>> visited by the GC via jvmtiExport::oops_do -> >>>>>>>>>> JvmtiCurrentBreakpoints::oops_do -> JvmtiBreakpoints::oops_do -> >>>>>>>>>> GrowableCache::oops_do -> JvmtiBreakpoint::oops_do, since it is >>>>>>>>>> being >>>>>>>>>> added to. >>>>>>>>>> >>>>>>>>>> I've also removed some dead code to simplify the change: >>>>>>>>>> - GrowableCache::insert >>>>>>>>>> - JvmtiBreakpoint::copy >>>>>>>>>> - JvmtiBreakpoint::lessThan >>>>>>>>>> - GrowableElement::lessThan >>>>>>>>>> >>>>>>>>>> Finally, I also formatted JvmtiEnv::ClearBreakpoint and >>>>>>>>>> Jvmti::SetBreakpoint exactly the same to highlight that they >>>>>>>>>> share all >>>>>>>>>> code except one line. Unfortunately, I was not able to remove >>>>>>>>>> this code >>>>>>>>>> duplication in a good way. >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~ehelin/8025834/webrev.00/ >>>>>>>>> jvmtiImpl.hpp: >>>>>>>>> Since clone() uses unhandled oops, and is only supposed to be used >>>>>>>>> by the VM operation, would it make sense to >>>>>>>>> assert(SafepointSynchronize::is_at_safepoint())? >>>>>>>>> >>>>>>>>> 196 GrowableElement *clone() { >>>>>>>>> 197 return new JvmtiBreakpoint(_method, _bci, >>>>>>>>> _class_loader_handle); >>>>>>>>> >>>>>>>>> jvmtiImpl.cpp: >>>>>>>>> No comments. >>>>>>>>> >>>>>>>>> jvmtiEnv.cpp: >>>>>>>>> Have you verified that the generated JVMTI entry point contains a >>>>>>>>> ResourceMark or is it just not needed? >>>>>>>>> - ResourceMark rm; >>>>>>>>> + HandleMark hm; >>>>>>>>> >>>>>>>>> Otherwise the code change looks good. >>>>>>>>> >>>>>>>>> >>>>>>>>> One thing that you didn't describe here, but which was related to >>>>>>>>> the bug (which we discussed) was the fact that the old code tried to >>>>>>>>> "do the right thing" WRT CheckUnhandledOops, but it incorrectly >>>>>>>>> added a Method*: >>>>>>>>> >>>>>>>>> thread->allow_unhandled_oop((oop*)&_method); >>>>>>>>> >>>>>>>>> We should take care to find other such places where we try to put a >>>>>>>>> non-oop in allow_unhandled_oop(), perhaps checking is_oop_or_null in >>>>>>>>> the unhandled oops code. >>>>>>>>> >>>>>>>>> /Mikael >>>>>>>>> >>>>>>>>>> Testing: >>>>>>>>>> - JPRT >>>>>>>>>> - The four tests that were failing are now passing >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Erik >>>>>>>>>> From jaroslav.bachorik at oracle.com Mon Oct 21 07:46:48 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 21 Oct 2013 16:46:48 +0200 Subject: RFR 7112404: 2 tests in java/lang/management/ManagementFactory fails with G1 because expect non-zero pools Message-ID: <52653E58.9070508@oracle.com> Please, review this simple test fix. Issue: https://bugs.openjdk.java.net/browse/JDK-7112404 Webrev: http://cr.openjdk.java.net/~jbachorik/7112404/webrev.00 The tests assume the MemoryUsage#commited values to be positive (>0) while according to the MemoryUsage only negative values are invalid. Therefore the tests should check and fail only when MemoryUsage#commited is < 0. Thanks, -JB- From daniel.fuchs at oracle.com Mon Oct 21 07:56:07 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 21 Oct 2013 16:56:07 +0200 Subject: jmx-dev RFR 7140929: NotSerializableNotifTest.java fails intermittently In-Reply-To: <526509E8.4030002@oracle.com> References: <526509E8.4030002@oracle.com> Message-ID: <52654087.4020905@oracle.com> On 10/21/13 1:03 PM, Jaroslav Bachorik wrote: > Hi, > > please, review the following small test change: > > Issue: https://bugs.openjdk.java.net/browse/JDK-7140929 > Webrev: http://cr.openjdk.java.net/~jbachorik/7140929/webrev.00 > > The test fails intermittently, mostly when it is run with -Xcomp option. > The failure is due to fixed timeout used in the test when waiting for > the notifications arrival. Tests of such slow configurations are run > with "timeoutfactor" set but the NotSerializableNotifTest does not > respect the timeoutfactor. > > The patch allows the test to reflect the provided "timeoutfactor" and > therefore successfully pass even when -Xcomp is used. > > Thanks, > > -JB- Hi Jaroslav, Looks good to me. I didn't know timeoutFactor was availaible as a system property. You can probably simplify the code like this: private static double timeoutFactor; ... main(...) { ... timeoutFactor = Double.parseDouble( System.getProperty("test.timeout.factor", "1.0") ); } (no need for the timeoutVal variable) regards, -- daniel From vicente.romero at oracle.com Mon Oct 21 07:58:20 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 21 Oct 2013 14:58:20 +0000 Subject: hg: jdk8/tl/langtools: 8026956: test tools/javac/lambda/TargetType58.java is failing after a libs change Message-ID: <20131021145825.D37E9625BF@hg.openjdk.java.net> Changeset: 9f876bd43f55 Author: vromero Date: 2013-10-21 15:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9f876bd43f55 8026956: test tools/javac/lambda/TargetType58.java is failing after a libs change Reviewed-by: jfranck ! test/tools/javac/lambda/TargetType58.java From shanliang.jiang at oracle.com Mon Oct 21 08:14:18 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 21 Oct 2013 17:14:18 +0200 Subject: jmx-dev RFR 7112404: 2 tests in java/lang/management/ManagementFactory fails with G1 because expect non-zero pools In-Reply-To: <52653E58.9070508@oracle.com> References: <52653E58.9070508@oracle.com> Message-ID: <526544CA.1030601@oracle.com> Looks OK. 164 // sanity check to have non-zero usage should be changed to ? 164 // sanity check to have non-negative usage Shanliang Jaroslav Bachorik wrote: > Please, review this simple test fix. > > Issue: https://bugs.openjdk.java.net/browse/JDK-7112404 > Webrev: http://cr.openjdk.java.net/~jbachorik/7112404/webrev.00 > > The tests assume the MemoryUsage#commited values to be positive (>0) > while according to the MemoryUsage only negative values are invalid. > Therefore the tests should check and fail only when > MemoryUsage#commited is < 0. > > Thanks, > > -JB- From yekaterina.kantserova at oracle.com Mon Oct 21 08:23:41 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 21 Oct 2013 17:23:41 +0200 Subject: Fwd: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <525D4490.3070506@oracle.com> References: <525D4490.3070506@oracle.com> Message-ID: <526546FD.5020909@oracle.com> Hi, I've done following changes after the reviews: - added open copyrights - documented all public functions in jdk.testlibrary.TestThread, jdk.testlibrary.XRun, jdk.testlibrary.ProcessThread, jdk.testlibrary.Utils - merged jdk.testlibrary.Asserts from hotspot testlibrary Jaroslav's comments: - test/sun/tools/jstatd/JstatdHelper.java 82-84 - is deleted, different exception can show up there while waiting until jstatd is up and running; better just look for valid pid; - test/sun/tools/jstatd/JstatdHelper.java clean up processes - since jstatd process is daemon, the "clean up" is to kill the target process. Please look at the changed JstatdHelper and tell me if it's still unclear. - test/lib/testlibrary/jdk/testlibrary/Utils.java serverSocket.close() should be called in "finally" - fixed Webrev: http://cr.openjdk.java.net/~ykantser/8022229/webrev.01/ Primal bug: https://bugs.openjdk.java.net/browse/JDK-8022229 Similar bugs: https://bugs.openjdk.java.net/browse/JDK-8019630 https://bugs.openjdk.java.net/browse/JDK-6636094 https://bugs.openjdk.java.net/browse/JDK-6543979 Thanks, Katja -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131021/f9a8bfb3/attachment.html From konstantin.shefov at oracle.com Mon Oct 21 02:39:45 2013 From: konstantin.shefov at oracle.com (konstantin.shefov at oracle.com) Date: Mon, 21 Oct 2013 09:39:45 +0000 Subject: hg: jdk8/tl/nashorn: 8026871: NASHORN TEST: Enable possibility to test Nashorn use of JavaFX canvas. Message-ID: <20131021094010.A0FC4625A9@hg.openjdk.java.net> Changeset: f22742d5daa3 Author: kshefov Date: 2013-10-21 13:31 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f22742d5daa3 8026871: NASHORN TEST: Enable possibility to test Nashorn use of JavaFX canvas. Reviewed-by: jlaskey, sundar ! make/build.xml ! make/project.properties + test/script/jfx.js + test/script/jfx/flyingimage.js + test/script/jfx/flyingimage/flyingimage.png + test/script/jfx/flyingimage/golden/linux.png + test/script/jfx/flyingimage/golden/macosx.png + test/script/jfx/flyingimage/golden/windows.png + test/script/jfx/kaleidoscope.js + test/script/jfx/kaleidoscope/golden/linux.png + test/script/jfx/kaleidoscope/golden/macosx.png + test/script/jfx/kaleidoscope/golden/windows.png From xueming.shen at oracle.com Mon Oct 21 11:18:35 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Mon, 21 Oct 2013 18:18:35 +0000 Subject: hg: jdk8/tl/jdk: 8026842: Remove Time-Zone IDs HST/EST/MST Message-ID: <20131021181901.2D1B9625C7@hg.openjdk.java.net> Changeset: f0c18a5e3ae5 Author: sherman Date: 2013-10-21 11:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f0c18a5e3ae5 8026842: Remove Time-Zone IDs HST/EST/MST Summary: removed these ids from ZoneId's zid list, supported via short_ids list Reviewed-by: okutsu ! make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java From joe.darcy at oracle.com Mon Oct 21 12:55:04 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 21 Oct 2013 19:55:04 +0000 Subject: hg: jdk8/tl/jdk: 8022658: Revisit FunctionalInterface on some core libs types Message-ID: <20131021195523.7A5B7625CB@hg.openjdk.java.net> Changeset: c1700125d041 Author: darcy Date: 2013-10-21 12:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1700125d041 8022658: Revisit FunctionalInterface on some core libs types Reviewed-by: briangoetz, mduigou, mr ! src/share/classes/java/io/Closeable.java ! src/share/classes/java/io/Flushable.java ! src/share/classes/java/lang/AutoCloseable.java ! src/share/classes/java/lang/Comparable.java ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/lang/Readable.java From serguei.spitsyn at oracle.com Mon Oct 21 14:02:19 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 21 Oct 2013 14:02:19 -0700 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops (round 2) In-Reply-To: <20131021092651.GD2608@ehelin-thinkpad> References: <20131021092651.GD2608@ehelin-thinkpad> Message-ID: <5265965B.3090406@oracle.com> Erik, It looks good. Thank you for filing new bugs. Thanks, Serguei On 10/21/13 2:26 AM, Erik Helin wrote: > Hi all, > > this is the second version of a patch for JDK-8025834. > > Background: > In JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint, we create a > JvmtiBreakpoint on the stack. This JvmtiBreakpoint contains an > "unhandled" oop to the class loader of the Method's class. > > A pointer to the JvmtiBreakpoint allocated on the stack will be passed > to VM_ChangeBreakpoint via JvmtiBreakpoints::set/clear. The > VM_ChangeBreakpoint class has an oops_do method that will visit the oop > in the JvmtiBreakpoint that was allocated on the stack. > > Since no GC can occur before the JvmtiBreakpoint has been passed to the > VM_ChangeBreakpoint (which is then passed to VMThread::execute), there > is no need to have a Handle for the _class_loader oop. Once the > VM_ChangeBreakpoint is on the VMThread's list for being executed, the > oop will be found via VMThread::oops_do. > > The oop can't be changed to a Handle because JvmtiBreakpoint:s are also > allocated on the heap, and Handles are only used for oops allocated on > the stack. > > This patch therefore registers the oop as "unhandled" to tell the > unhandled oop verifier to (rightfully) ignore it. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8025834/round-2/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8025834 > > As I explained in a previous email, there are additional issues in the > JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreapoints methods: > - https://bugs.openjdk.java.net/browse/JDK-8026946 > - https://bugs.openjdk.java.net/browse/JDK-8026948 > This change does not intend to fix these issues. > > Thanks, > Erik From yuka.kamiya at oracle.com Mon Oct 21 14:15:42 2013 From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com) Date: Mon, 21 Oct 2013 21:15:42 +0000 Subject: hg: jdk8/tl/jdk: 8020037: String.toLowerCase incorrectly increases length, if string contains \u0130 char Message-ID: <20131021211555.660D0625CD@hg.openjdk.java.net> Changeset: e8683d5b2b0a Author: peytoia Date: 2013-10-22 06:13 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8683d5b2b0a 8020037: String.toLowerCase incorrectly increases length, if string contains \u0130 char Reviewed-by: naoto ! src/share/classes/java/lang/ConditionalSpecialCasing.java ! src/share/classes/java/lang/String.java ! test/java/lang/String/ToLowerCase.java From joe.darcy at oracle.com Mon Oct 21 15:37:42 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 21 Oct 2013 22:37:42 +0000 Subject: hg: jdk8/tl/langtools: 8026984: Clarity intended use of jdk.Exported Message-ID: <20131021223750.0B666625CF@hg.openjdk.java.net> Changeset: b82982ac3ca2 Author: darcy Date: 2013-10-21 15:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b82982ac3ca2 8026984: Clarity intended use of jdk.Exported Reviewed-by: psandoz, mr, alanb ! src/share/classes/jdk/Exported.java From xueming.shen at oracle.com Mon Oct 21 18:22:38 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 22 Oct 2013 01:22:38 +0000 Subject: hg: jdk8/tl/jdk: 8008386: (cs) Unmappable leading should be decoded to replacement. Message-ID: <20131022012324.5038F625D4@hg.openjdk.java.net> Changeset: 3b00bf85a6f5 Author: sherman Date: 2013-10-21 18:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b00bf85a6f5 8008386: (cs) Unmappable leading should be decoded to replacement. Summary: updated the unmappable/malformed detecting handling for db charsets Reviewed-by: naoto ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! test/sun/nio/cs/TestIBMBugs.java + test/sun/nio/cs/TestUnmappable.java From joel.franck at oracle.com Mon Oct 21 19:13:26 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Tue, 22 Oct 2013 02:13:26 +0000 Subject: hg: jdk8/tl/langtools: 8026855: AnnoConstruct.getAnnotationsByType includes inherited indirectly present annotations even when containee type is not inheritable Message-ID: <20131022021332.E33E4625D8@hg.openjdk.java.net> Changeset: ac839d6f4953 Author: jfranck Date: 2013-10-22 03:36 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ac839d6f4953 8026855: AnnoConstruct.getAnnotationsByType includes inherited indirectly present annotations even when containee type is not inheritable Summary: In AnnoConstruct.getAnnotationByType() check that the annotation sought after is inherited before looking on supertypes. Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/AnnoConstruct.java + test/tools/javac/processing/model/element/TestNonInherited.java From coleen.phillimore at oracle.com Mon Oct 21 20:40:30 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 22 Oct 2013 03:40:30 +0000 Subject: hg: jdk8/tl/jdk: 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV Message-ID: <20131022034109.39927625E4@hg.openjdk.java.net> Changeset: f581b72e3715 Author: sla Date: 2013-10-21 23:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f581b72e3715 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV Summary: Redefined class in stack trace may not be found by method_idnum so handle null. Reviewed-by: coleenp, dcubed, sspitsyn ! test/java/lang/instrument/RedefineMethodInBacktrace.sh ! test/java/lang/instrument/RedefineMethodInBacktraceApp.java + test/java/lang/instrument/RedefineMethodInBacktraceTargetB.java + test/java/lang/instrument/RedefineMethodInBacktraceTargetB_2.java From calvin.cheung at oracle.com Mon Oct 21 20:48:07 2013 From: calvin.cheung at oracle.com (calvin.cheung at oracle.com) Date: Tue, 22 Oct 2013 03:48:07 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 6 new changesets Message-ID: <20131022034844.A718C625E5@hg.openjdk.java.net> Changeset: aeae561a6d0b Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/aeae561a6d0b Added tag jdk8-b112 for changeset 0ed9a90f45e1 ! .hgtags Changeset: 23b8db5ea31d Author: amurillo Date: 2013-10-18 21:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/23b8db5ea31d Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: e8cbdc701bfb Author: amurillo Date: 2013-10-18 21:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e8cbdc701bfb Added tag hs25-b55 for changeset 23b8db5ea31d ! .hgtags Changeset: d6d8aeb2c2d4 Author: amurillo Date: 2013-10-19 08:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d6d8aeb2c2d4 8026928: new hotspot build - hs25-b56 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 384c92148c68 Author: amurillo Date: 2013-10-21 14:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/384c92148c68 8023496: [jprt] build and test solaris 64-bits only Reviewed-by: tbell, jcoomes ! make/jprt.properties Changeset: 1327b7f85503 Author: ccheung Date: 2013-10-21 17:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1327b7f85503 Merge From jason.uh at oracle.com Mon Oct 21 20:55:14 2013 From: jason.uh at oracle.com (jason.uh at oracle.com) Date: Tue, 22 Oct 2013 03:55:14 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20131022035619.396A7625E6@hg.openjdk.java.net> Changeset: 975e3a89814e Author: darcy Date: 2013-10-21 13:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/975e3a89814e 8024603: Turn on javac lint checking for auxiliaryclass, empty, and try in jdk build Reviewed-by: erikj, ihse, chegar ! makefiles/Setup.gmk Changeset: f443d9b863cf Author: juh Date: 2013-10-21 22:05 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f443d9b863cf Merge Changeset: d0882a1deeb5 Author: juh Date: 2013-10-22 03:49 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d0882a1deeb5 Merge From kumar.x.srinivasan at oracle.com Mon Oct 21 21:34:12 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 22 Oct 2013 04:34:12 +0000 Subject: hg: jdk8/tl/langtools: 8026758: Inefficient code in LambdaToMethod Message-ID: <20131022043417.6CA25625EC@hg.openjdk.java.net> Changeset: 87c950ea88be Author: ksrini Date: 2013-10-21 20:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/87c950ea88be 8026758: Inefficient code in LambdaToMethod Reviewed-by: jjg, jlahoda, rfield ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java From david.holmes at oracle.com Tue Oct 22 00:09:05 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Oct 2013 17:09:05 +1000 Subject: RFR (XXS) 8026808: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failed with unexpected exit value In-Reply-To: <526278EB.5010203@oracle.com> References: <52613A71.7010500@oracle.com> <526278EB.5010203@oracle.com> Message-ID: <52662491.50705@oracle.com> Hi Fredrik, After our email side-bar it seems to me that the bug here is in the JDKToolLauncher constructor: private JDKToolLauncher(String tool, boolean useCompilerJDK) { if (useCompilerJDK) { executable = JDKToolFinder.getJDKTool(tool); } else { executable = JDKToolFinder.getCurrentJDKTool(tool); } vmArgs.addAll(Arrays.asList(ProcessTools.getPlatformSpecificVMArgs())); } The last line does not add the -J where needed and could/should be: for (String vmArg : ProcessTools.getPlatformSpecificVMArgs()) { addVMArg(vmArg); } But your change still ends up adding -J where needed. To me it seemed that it modified addVMArg in a way that was inconsistent with its specification, but on further reflection that is not the case. My apologies for the erroneous commentary. Reviewed. Thanks, David On 19/10/2013 10:19 PM, David Holmes wrote: > Hi Fredrik, > > On 18/10/2013 11:41 PM, Fredrik Arvidsson wrote: >> Hi >> >> Please help me with this tiny review: >> >> Webrev: >> http://cr.openjdk.java.net/~farvidsson/8026808/webrev.00/index.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8026808 >> >> About this bug: >> This bug was revealed by another test-fix: >> https://bugs.openjdk.java.net/browse/JDK-8025638. The JDKToolLauncher >> have probably never worked in Solaris 64 environments. > > I don't see the connection to 64-bit from the fix but I suspect it may > be a confusion between launcher args (like -d64) and VM args (like > -XX:+foo). AFAICS the tools will accept both -d64 and -J-d64. > > Your change to vmArgs is wrong. It explicitly states that it adds -J to > the arg and you have removed that. When launching a tool (javac, javap, > etc) you have to pass VM args via -J - and that is what this method was > supposed to do. AFAICS based on the usage example given in the code: > > 40 * JDKToolLauncher jmap = JDKToolLauncher.create("jmap") > 41 * .addVMArg("-XX:+PrintGC"); > 42 * .addVMArg("-XX:+PrintGCDetails") > 43 * .addToolArg("-heap") > 44 * .addToolArg(pid); > 45 * ProcessBuilder pb = new ProcessBuilder(jmap.getCommand()); > > the existing code was correct. > > Based on the jtreg log in the bug report: > > Command line: > [/export/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/rt_baseline/solaris-amd64/bin/java > -d64 -Xmx1g JMapHProfLargeHeapProc 22528 ] > Extracted pid: 18298 > jmap command: > [/export/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/rt_baseline/solaris-amd64/bin/jmap, > -d64, -dump:format=b,file=18298-heap.hprof, 18298] > > it would seem to me that the problem is the presence of commas in the > jmap command (compare with the java command). Not that I can see where > they come from. I can't find this test in our repo - where is it? > > David > ----- > >> JTReg tests run in JPRT: >> http://sthjprt.se.oracle.com/archives/2013/10/2013-10-18-094943.farvidss.hotspot/ >> >> verified successful. >> >> Cheers >> /F From david.holmes at oracle.com Tue Oct 22 00:58:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Oct 2013 17:58:21 +1000 Subject: RFR 6309226: TEST: java/lang/management/ThreadMXBean/SynchronizationStatistics.java didn't check Thread.sleep In-Reply-To: <52651646.4050705@oracle.com> References: <52651646.4050705@oracle.com> Message-ID: <5266301D.5040002@oracle.com> On 21/10/2013 9:55 PM, Jaroslav Bachorik wrote: > Please, review this small patch for a test failing due to the updated > implementation in JDK6. > > Issue: https://bugs.openjdk.java.net/browse/JDK-6309226 > Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.00/ > > The test fails due to the change in mustang where > ThreadMXBean.getThreadInfo().getWaitedTime() and > ThreadMXBean.getThreadInfo().getWaitedCount() include Thread.sleep() > too. Unfortunately, Thread.sleep() is used throughout the test for > synchronization purposes and this breaks the test. > > In the patch I propose to replace Thread.sleep() with busy wait and > hinting the scheduler by Thread.yield(). While not very elegant it > successfully works around inclusion of unknown number of Thread.sleep()s > (they are called in loop). Not elegant and not completely reliable either. Probably adequate on a multi-core system but single-core and with some schedulers it could just be a busy spin. David > Thanks, > > -JB- From yekaterina.kantserova at oracle.com Tue Oct 22 01:18:08 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 22 Oct 2013 10:18:08 +0200 Subject: RFR (XSS): 8026962: Put java/lang/management/ClassLoadingMXBean/LoadCounts.java into ProblemList.txt Message-ID: <526634C0.3020607@oracle.com> Hi, Could I please have a review of this fix. Webrev: http://cr.openjdk.java.net/~ykantser/8026962/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8026962 Thanks, Katja From yekaterina.kantserova at oracle.com Tue Oct 22 01:24:19 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 22 Oct 2013 10:24:19 +0200 Subject: Fwd: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <526546FD.5020909@oracle.com> References: <525D4490.3070506@oracle.com> <526546FD.5020909@oracle.com> Message-ID: <52663633.2080206@oracle.com> Sorry, the wrong webrev link has slipped through. Here is the right one: http://cr.openjdk.java.net/~ykantser/8022229/webrev.01/ Thanks, Katja On 10/21/2013 05:23 PM, Yekaterina Kantserova wrote: > Hi, > > I've done following changes after the reviews: > - added open copyrights > - documented all public functions in jdk.testlibrary.TestThread, > jdk.testlibrary.XRun, jdk.testlibrary.ProcessThread, jdk.testlibrary.Utils > - merged jdk.testlibrary.Asserts from hotspot testlibrary > > Jaroslav's comments: > - test/sun/tools/jstatd/JstatdHelper.java 82-84 - is deleted, > different exception can show up there while waiting until jstatd is up > and running; better just look for valid pid; > - test/sun/tools/jstatd/JstatdHelper.java clean up processes - since > jstatd process is daemon, the "clean up" is to kill the target > process. Please look at the changed JstatdHelper and tell me if it's > still unclear. > - test/lib/testlibrary/jdk/testlibrary/Utils.java serverSocket.close() > should be called in "finally" - fixed > > Webrev: > http://cr.openjdk.java.net/~ykantser/8022229/webrev.01/ > > Primal bug: > https://bugs.openjdk.java.net/browse/JDK-8022229 > > Similar bugs: > https://bugs.openjdk.java.net/browse/JDK-8019630 > https://bugs.openjdk.java.net/browse/JDK-6636094 > https://bugs.openjdk.java.net/browse/JDK-6543979 > > Thanks, > Katja -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131022/8a963836/attachment.html From jaroslav.bachorik at oracle.com Tue Oct 22 01:29:42 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 22 Oct 2013 10:29:42 +0200 Subject: RFR (XSS): 8026962: Put java/lang/management/ClassLoadingMXBean/LoadCounts.java into ProblemList.txt In-Reply-To: <526634C0.3020607@oracle.com> References: <526634C0.3020607@oracle.com> Message-ID: <52663776.2040606@oracle.com> Looks fine. (not-a-reviewer) -JB- On 22.10.2013 10:18, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > Webrev: > http://cr.openjdk.java.net/~ykantser/8026962/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8026962 > > Thanks, > Katja > From joel.franck at oracle.com Tue Oct 22 01:32:15 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Tue, 22 Oct 2013 08:32:15 +0000 Subject: hg: jdk8/tl/langtools: 8026857: AnnoConstruct.getAnnotationsByType does not search supertype for inherited annotations if @SomeContainer({}) is present Message-ID: <20131022083233.2FDB3625F6@hg.openjdk.java.net> Changeset: f003f09144ff Author: jfranck Date: 2013-10-22 10:08 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f003f09144ff 8026857: AnnoConstruct.getAnnotationsByType does not search supertype for inherited annotations if @SomeContainer({}) is present Summary: An empty container should not stop javac from looking at supertypes for inherited repeating annotations Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/AnnoConstruct.java + test/tools/javac/processing/model/element/TestEmptyContainer.java From staffan.larsen at oracle.com Tue Oct 22 01:48:18 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 22 Oct 2013 10:48:18 +0200 Subject: RFR (XSS): 8026962: Put java/lang/management/ClassLoadingMXBean/LoadCounts.java into ProblemList.txt In-Reply-To: <526634C0.3020607@oracle.com> References: <526634C0.3020607@oracle.com> Message-ID: Looks good! Thanks, /Staffan On 22 okt 2013, at 10:18, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this fix. > > Webrev: > http://cr.openjdk.java.net/~ykantser/8026962/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8026962 > > Thanks, > Katja > From joel.franck at oracle.com Tue Oct 22 01:50:53 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Tue, 22 Oct 2013 08:50:53 +0000 Subject: hg: jdk8/tl/jdk: 8009411: (reflect) Class.getMethods should not include static methods from interfaces Message-ID: <20131022085246.E9B7F625F7@hg.openjdk.java.net> Changeset: 04ba97b7c2f9 Author: jfranck Date: 2013-10-22 10:34 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/04ba97b7c2f9 8009411: (reflect) Class.getMethods should not include static methods from interfaces Summary: Update getMethods() and getMethod() to filter out interface statics Reviewed-by: darcy Contributed-by: joel.franck at oracle.com, andreas.lundblad at oracle.com, amy.lu at oracle.com, peter.levart at gmail.com ! src/share/classes/java/lang/Class.java ! test/java/lang/reflect/DefaultStaticTest/DefaultStaticInvokeTest.java ! test/java/lang/reflect/DefaultStaticTest/DefaultStaticTestData.java + test/java/lang/reflect/Method/InterfaceStatic/StaticInterfaceMethodInWayOfDefault.java From staffan.larsen at oracle.com Tue Oct 22 02:46:23 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Tue, 22 Oct 2013 09:46:23 +0000 Subject: hg: jdk8/tl/jdk: 8026962: Put java/lang/management/ClassLoadingMXBean/LoadCounts.java into ProblemList.txt Message-ID: <20131022095104.B1C45625FE@hg.openjdk.java.net> Changeset: bb2fb6be8b2a Author: ykantser Date: 2013-10-22 10:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb2fb6be8b2a 8026962: Put java/lang/management/ClassLoadingMXBean/LoadCounts.java into ProblemList.txt Reviewed-by: sla, jbachorik ! test/ProblemList.txt From joel.franck at oracle.com Tue Oct 22 03:40:00 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Tue, 22 Oct 2013 10:40:00 +0000 Subject: hg: jdk8/tl/jdk: 8004912: Repeating annotations - getAnnotationsByType(Class) is not working as expected for few inheritance scenarios; ... Message-ID: <20131022104043.279CA62603@hg.openjdk.java.net> Changeset: b07856d0de34 Author: alundblad Date: 2013-10-22 12:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b07856d0de34 8004912: Repeating annotations - getAnnotationsByType(Class) is not working as expected for few inheritance scenarios 8019420: Repeatable non-inheritable annotation types are mishandled by Core Reflection Reviewed-by: jfranck ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Parameter.java ! src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java ! src/share/classes/sun/reflect/annotation/AnnotationSupport.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java + test/java/lang/annotation/repeatingAnnotations/NonInheritableContainee.java + test/java/lang/annotation/repeatingAnnotations/OrderUnitTest.java ! test/java/lang/annotation/repeatingAnnotations/RepeatedUnitTest.java From alan.bateman at oracle.com Tue Oct 22 03:45:01 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 22 Oct 2013 10:45:01 +0000 Subject: hg: jdk8/tl/corba: 8021257: com.sun.corba.se.** should be on restricted package list Message-ID: <20131022104503.E67AB62604@hg.openjdk.java.net> Changeset: 52ad44f9a3ec Author: alanb Date: 2013-10-22 11:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/52ad44f9a3ec 8021257: com.sun.corba.se.** should be on restricted package list Reviewed-by: chegar, coffeys, smarks Contributed-by: alan.bateman at oralce.com, mark.sheppard at oracle.com ! src/share/classes/javax/rmi/CORBA/Stub.java ! src/share/classes/javax/rmi/CORBA/Util.java ! src/share/classes/javax/rmi/PortableRemoteObject.java ! src/share/classes/org/omg/CORBA/ORB.java From jaroslav.bachorik at oracle.com Tue Oct 22 04:03:48 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 22 Oct 2013 13:03:48 +0200 Subject: RFR 6309226: TEST: java/lang/management/ThreadMXBean/SynchronizationStatistics.java didn't check Thread.sleep In-Reply-To: <5266301D.5040002@oracle.com> References: <52651646.4050705@oracle.com> <5266301D.5040002@oracle.com> Message-ID: <52665B94.8090902@oracle.com> On 22.10.2013 09:58, David Holmes wrote: > On 21/10/2013 9:55 PM, Jaroslav Bachorik wrote: >> Please, review this small patch for a test failing due to the updated >> implementation in JDK6. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-6309226 >> Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.00/ >> >> The test fails due to the change in mustang where >> ThreadMXBean.getThreadInfo().getWaitedTime() and >> ThreadMXBean.getThreadInfo().getWaitedCount() include Thread.sleep() >> too. Unfortunately, Thread.sleep() is used throughout the test for >> synchronization purposes and this breaks the test. >> >> In the patch I propose to replace Thread.sleep() with busy wait and >> hinting the scheduler by Thread.yield(). While not very elegant it >> successfully works around inclusion of unknown number of Thread.sleep()s >> (they are called in loop). > > Not elegant and not completely reliable either. Probably adequate on a > multi-core system but single-core and with some schedulers it could just > be a busy spin. :/ Ok, so I need to account for the Thread.sleep() calls made outside of the test code but still reported by the ThreadMXBean. Not that elegant, too, but at least should be reliable. http://cr.openjdk.java.net/~jbachorik/6309226/webrev.01 -JB- > > David > >> Thanks, >> >> -JB- From alan.bateman at oracle.com Tue Oct 22 04:10:17 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 22 Oct 2013 11:10:17 +0000 Subject: hg: jdk8/tl/jdk: 8024833: (fc) FileChannel.map does not handle async close/interrupt correctly Message-ID: <20131022111029.DAFE562607@hg.openjdk.java.net> Changeset: f15ad52cffed Author: alanb Date: 2013-10-22 12:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f15ad52cffed 8024833: (fc) FileChannel.map does not handle async close/interrupt correctly Reviewed-by: alanb Contributed-by: chris.w.dennis at gmail.com ! src/share/classes/sun/nio/ch/FileChannelImpl.java + test/java/nio/channels/FileChannel/InterruptMapDeadlock.java From alan.bateman at oracle.com Tue Oct 22 03:48:37 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 22 Oct 2013 10:48:37 +0000 Subject: hg: jdk8/tl/jdk: 8021257: com.sun.corba.se.** should be on restricted package list Message-ID: <20131022104859.02ADC62605@hg.openjdk.java.net> Changeset: 6f9515a9519f Author: alanb Date: 2013-10-22 11:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6f9515a9519f 8021257: com.sun.corba.se.** should be on restricted package list Reviewed-by: chegar, coffeys, smarks, mullan Contributed-by: alan.bateman at oralce.com, mark.sheppard at oracle.com ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/lang/SecurityManager/CheckPackageAccess.java From vicente.romero at oracle.com Tue Oct 22 05:59:17 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 22 Oct 2013 12:59:17 +0000 Subject: hg: jdk8/tl/langtools: 8025290: javac implicit versus explicit lambda compilation error Message-ID: <20131022125922.C6C4F62610@hg.openjdk.java.net> Changeset: 963c57175e40 Author: vromero Date: 2013-10-22 13:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/963c57175e40 8025290: javac implicit versus explicit lambda compilation error Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/util/JavacMessages.java + test/tools/javac/lambda/T8025290/ExplicitVSImplicitLambdaTest.java From chris.hegarty at oracle.com Tue Oct 22 06:05:59 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 22 Oct 2013 13:05:59 +0000 Subject: hg: jdk8/tl/jdk: 8017779: java/net/Authenticator/B4769350.java fails Message-ID: <20131022130621.8F56862611@hg.openjdk.java.net> Changeset: 7cafbb397683 Author: chegar Date: 2013-10-22 14:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7cafbb397683 8017779: java/net/Authenticator/B4769350.java fails Reviewed-by: chegar Contributed-by: Tristan Yan , Kurchi Subhra Hazra ! test/java/net/Authenticator/B4769350.java From sean.mullan at oracle.com Tue Oct 22 06:14:04 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 22 Oct 2013 13:14:04 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20131022131513.B657F62612@hg.openjdk.java.net> Changeset: 5f4aecd73caa Author: mullan Date: 2013-10-22 08:03 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5f4aecd73caa 8021191: Add isAuthorized check to limited doPrivileged methods Reviewed-by: weijun, xuelei ! src/share/classes/java/security/AccessControlContext.java ! src/share/classes/java/security/AccessController.java Changeset: 948b390b6952 Author: mullan Date: 2013-10-22 08:17 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/948b390b6952 Merge - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.gmk - makefiles/GenerateJavaSources.gmk - makefiles/GensrcBuffer.gmk - makefiles/GensrcCLDR.gmk - makefiles/GensrcCharacterData.gmk - makefiles/GensrcCharsetCoder.gmk - makefiles/GensrcCharsetMapping.gmk - makefiles/GensrcExceptions.gmk - makefiles/GensrcIcons.gmk - makefiles/GensrcJDWP.gmk - makefiles/GensrcJObjC.gmk - makefiles/GensrcLocaleDataMetaInfo.gmk - makefiles/GensrcMisc.gmk - makefiles/GensrcProperties.gmk - makefiles/GensrcSwing.gmk - makefiles/GensrcX11Wrappers.gmk - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m - src/share/classes/java/lang/invoke/MagicLambdaImpl.java - src/share/classes/java/net/HttpURLPermission.java - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 Changeset: 3ea9af449b36 Author: mullan Date: 2013-10-22 09:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3ea9af449b36 Merge - test/java/net/NetworkInterface/MemLeakTest.java From mikael.auno at oracle.com Tue Oct 22 06:22:34 2013 From: mikael.auno at oracle.com (Mikael Auno) Date: Tue, 22 Oct 2013 15:22:34 +0200 Subject: RFR: 8009681: TEST_BUG: MethodExitReturnValuesTest.java fails with when there are unexpected background threads In-Reply-To: <34FEB736-B9ED-4D0F-92EA-313B370309FC@oracle.com> References: <516E9DB9.8020009@oracle.com> <62E7E237-46A6-46A7-8682-BE332F296F3D@oracle.com> <525E80C5.6040802@oracle.com> <848A2E80-1793-4C2B-AD20-EA1E473B1820@oracle.com> <34FEB736-B9ED-4D0F-92EA-313B370309FC@oracle.com> Message-ID: <52667C1A.6040608@oracle.com> Thanks for the reviews. Mikael On 2013-10-18 13:09, Peter Allwin wrote: > +1 > > Thanks, > /peter > > On Oct 18, 2013, at 12:56 PM, Staffan Larsen wrote: > >> Looks good! >> >> Thanks, >> /Staffan >> >> On 16 okt 2013, at 14:04, Mikael Auno wrote: >> >>> This bug got a bit lost from my radar after vacation, but I've picked it >>> again now. I've moved Arrays.asList() as suggested. In further testing of the fix though, I found that the include list is not enough, as one of the expected method exit events is from String.intern(), which might also be called from background threads. To counter this, I added a thread filter to the events. This also has the added benefit of speeding up the test significantly (from 90 seconds to about 5 seconds) in the cases where there are background threads interfering. >>> >>> Also added to this webrev is a fix for MethodEntryExitEvents.java which had exactly the same problem and a similar test design as MethodExitReturnValuesTest.java. >>> >>> The updated webrev is at http://cr.openjdk.java.net/~allwin/auno/8009681/webrev.00/. >>> >>> Thanks, >>> Mikael >>> >>> On 2013-05-28 08:46, Staffan Larsen wrote: >>>> Looks good. >>>> >>>> You could optimize it a bit by not doing the Arrays.asList() on every >>>> methodExit event. >>>> >>>> /Staffan >>>> >>>> On 17 apr 2013, at 15:03, Mikael Auno >>>> wrote: >>>> >>>>> Hi, I'd like some reviews on >>>>> http://cr.openjdk.java.net/~nloodin/8009681/webrev.01/ for >>>>> JDK-8009681 (http://bugs.sun.com/view_bug.do?bug_id=8009681). >>>>> >>>>> The issue here is that when MethodExitReturnValuesTest hooks into >>>>> MethodExit events through JDI it uses an exclude list to filter out >>>>> classes from which it is not interested in these events. This is >>>>> bound to break over and over again as new features are added to the >>>>> JDK. I've changed the test to use an include list instead, >>>>> containing only the handful of classes the test is actually >>>>> interested in. >>>>> >>>>> Thanks, >>>>> Mikael >>>> >>> >> > From alan.bateman at oracle.com Tue Oct 22 06:20:53 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 22 Oct 2013 13:20:53 +0000 Subject: hg: jdk8/tl/jdk: 7074436: (sc) SocketChannel can do short gathering writes when channel configured blocking (win) Message-ID: <20131022132115.916A762613@hg.openjdk.java.net> Changeset: 54869853c06c Author: alanb Date: 2013-10-22 14:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/54869853c06c 7074436: (sc) SocketChannel can do short gathering writes when channel configured blocking (win) Reviewed-by: chegar ! src/windows/native/sun/nio/ch/SocketDispatcher.c ! test/java/nio/channels/SocketChannel/ShortWrite.java From jaroslav.bachorik at oracle.com Tue Oct 22 06:47:41 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 22 Oct 2013 15:47:41 +0200 Subject: RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool Message-ID: <526681FD.90604@oracle.com> Please, review the following test fix: Issue: https://bugs.openjdk.java.net/browse/JDK-8020467 Webrev: http://cr.openjdk.java.net/~jbachorik/8020467/webrev.01 The test tries to make sure that the "pool usage threshold" trigger and the reported pool memory usage are not contradicting each other. The problem is that it is not possible to get the "pool usage threshold exceeded" flag and the pool memory usage atomicly in regard to the GC. Specifically, when "CMS Old Gen" pool is examined and the usage is retrieved before a GC promotes some objects to the old gen but the usage threshold is checked after the GC has promoted some instance into the old gen the test will fail. The patch makes sure that there are some instances promoted in "CMS Old Gen" before checking the "pool usage threshold" to get semi-consistent view. Thanks, -JB- From sundararajan.athijegannathan at oracle.com Tue Oct 22 07:27:40 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 22 Oct 2013 14:27:40 +0000 Subject: hg: jdk8/tl/nashorn: 5 new changesets Message-ID: <20131022142752.D0F3A6261A@hg.openjdk.java.net> Changeset: d8d5b7919c57 Author: sundar Date: 2013-10-22 14:27 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d8d5b7919c57 8027016: Array.prototype.indexOf should return -1 when array is of length zero Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/objects/NativeArray.java + test/script/basic/JDK-8027016.js Changeset: 6d339d98074e Author: hannesw Date: 2013-10-22 11:12 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/6d339d98074e 8027015: AutoCloseable no longer implements @FunctionalInterface Reviewed-by: lagergren, sundar ! test/script/basic/NASHORN-397.js Changeset: d24a4fabdce1 Author: hannesw Date: 2013-10-22 11:31 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d24a4fabdce1 8026955: for-in should convert primitive values to object Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8026955.js + test/script/basic/JDK-8026955.js.EXPECTED Changeset: 360761288b38 Author: sundar Date: 2013-10-22 17:38 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/360761288b38 8027024: String.prototype.charAt and charCodeAt do not evaluate 'self' and 'pos' arguments in right order Reviewed-by: jlaskey, attila, lagergren ! src/jdk/nashorn/internal/objects/NativeString.java ! src/overview.html + test/script/basic/JDK-8027024.js + test/script/basic/JDK-8027024.js.EXPECTED Changeset: d04028e6b624 Author: sundar Date: 2013-10-22 17:47 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/d04028e6b624 Merge From coleen.phillimore at oracle.com Tue Oct 22 07:51:02 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 22 Oct 2013 10:51:02 -0400 Subject: RFR (S): JDK-8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes In-Reply-To: <525FEE10.9030508@oracle.com> References: <5249643F.3030209@oracle.com> <524A7B07.1000300@oracle.com> <524BE733.2070205@oracle.com> <525CF1F1.1010400@oracle.com> <525FEE10.9030508@oracle.com> Message-ID: <526690D6.6060103@oracle.com> Frederik, This code looks good and addresses my concerns. It's an improvement and resolves this issue. I suggest that we should wait to see what initiating loader means for anonymous classes since the jvm doesn't have that information readily before tackling that. But ship this fix definitely. thanks, Coleen On 10/17/2013 10:02 AM, Fredrik Arvidsson wrote: > Hi > > I have added a new revision of my changes here: > http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.02/ > > > The idea is to use a lock called metaspace_lock available inside the > ClassLoaderData objects that the ClassLoaderDataGraph holds, this > prevents classes to be added/removed/updated during the gathering > phase. When iterating using the new LoadedClassesClosure > implementation only array classes and instance classes that are marked > as loaded will be visited. The LoadedClassesClosure implementation > uses a Stack to store classes during the gathering phase. This > changes the count-allocate-add-extract approach that was used before > into a add-extract way of doing it instead. > > I am still not sure how to do with the GetClassLoaderClasses to make > it consistent. I would eventually like to get rid of the > JvmtiGetLoadedClassesClosure and the use of the SystemDictionary if > possible. But right now I just cant see how to get hold of the > initiating loader for a class without using the SystemDictionary. > > /Fredrik > > On 2013-10-15 09:42, serguei.spitsyn at oracle.com wrote: >> >> There are two questions on the list that we still need to resolve in >> this fix: >> (1) What is the best way to protect the work with CLDG from >> concurrent additions of CLD's to it >> (2) The *GetClassLoaderClasses* needs a fix as well to be consistent >> with the GetLoadedClasses >> >> I had some private conversations with Fredrik and John Rose and >> after some analysis came up with the suggestion: >> >> (1) Continue using the *SystemDictionary_lock* to protect >> consistency of the loaded classes data. >> The issue is that adding CLD's to the SLDG is not currently >> protected by the *SystemDictionary_lock*. >> I'm suggesting to add it to the >> *SystemDictionary::parse_stream* (please, see the webrev below). >> >> (2) There was some doubt that a similar fix for the >> *GetClassLoaderClasses* is needed because >> the CL+SD (taken from the host class) does not reference the >> associated anonymous classes. >> The question is: Can we consider the host's class CL as the >> initiating CL? >> My reading is that the answer to this question is: "Yes, we can". >> Even though the CL itself does not have references to its >> anonymous classes, >> there are references from the anonymous classes's CLD's to its CL. >> These references can be used in the *increment_with_loader* >> and *add_with_loader* >> the same way as it was before. >> >> This is a webrev that includes the Fredrik's fix as a base plus the >> implemented suggestion: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/fredrik/8024423-JVMTI-ANO/ >> >> Some help from the HotSpot team is needed to estimate if this >> approach is Ok and does not have rat holes in it. >> Opinions are very welcome. >> >> Thanks, >> Serguei >> >> >> On 10/2/13 2:28 AM, Fredrik Arvidsson wrote: >>> Hi and thanks for all your comments. >>> >>> I have simplified the code in *instanceKlass.cpp* like suggested and >>> here is a new webrev: >>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.01/ >>> >>> >>> Regarding the need to synchronize the access to ClassLoaderDataGraph >>> I have come to the conclusion that it should be safe to call this >>> without any additional synchronization since newly loaded and added >>> classes are appended to the end of its 'list' of classes. This would >>> mean that the call could 'miss' the classes added during the >>> collection phase, but this is not a big issue. I hope that my >>> conclusion is correct. >>> >>> I believe that the JvmtiGetLoadedClasses::getClassLoaderClasses(...) >>> method is to be left alone this time since I got the impression that >>> only SystemDictionary 'knows' about initiating class loaders. >>> >>> There is plenty of room for improvement and simplification of much >>> of the code in this area, but I feel that it must wait until another >>> time. The task to re-factor and simplify would quickly grow out of >>> hands I'm afraid :) >>> >>> Cheers >>> /Fredrik >>> >>> On 2013-10-01 09:34, serguei.spitsyn at oracle.com wrote: >>>> Hi Frederik, >>>> >>>> >>>> Thank you for jumping on this issue! >>>> >>>> >>>> *src/share/vm/oops/instanceKlass.cpp* >>>> 2333 int src_index = 0; >>>> 2334 while (src_index < src_length) { >>>> 2335 dest[dest_index++] = src[src_index++]; >>>> 2336 } >>>> 2337 >>>> 2338 // If we have a hash, append it >>>> 2339 if(hash_len > 0) { >>>> 2340 int hash_index = 0; >>>> 2341 while (hash_index < hash_len) { >>>> 2342 dest[dest_index++] = hash_buf[hash_index++]; >>>> 2343 } >>>> 2344 } >>>> >>>> The above can be simplified a little bit: >>>> // Add the actual class name >>>> for (int src_index = 0; src_index < src_length; ) { >>>> dest[dest_index++] = src[src_index++]; >>>> } >>>> // If we have a hash, append it >>>> for (int hash_index = 0; hash_index < hash_len; ) { >>>> dest[dest_index++] = hash_buf[hash_index++]; >>>> } >>>> >>>> The conditionif(hash_len > 0) is covered by the loop itself. >>>> >>>> Style-related comments: >>>> -wrong indent at the lines: 2316-2319 >>>> - need a space after the 'if' at the lines: 2315, 2339 >>>> >>>> >>>> *src/share/vm/prims/jvmtiGetLoadedClasses.cpp >>>> >>>> *The copyright comment must be up-to-date. >>>> The comments at the lines 35-38, 258-260 are not valid anymore. >>>> >>>> >>>> > In this review I still have an outstanding unanswered question about >>>> > the need to synchronize the access to the: >>>> >>>> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >>>> > and >>>> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >>>> >>>> This kind of walking is usually done at safepoint in a VM_Operation. >>>> You will find many examples in the jvmtiEnv.cpp, for instance, VM_GetAllStackTraces. >>>> The suggestion from Mikael is good too. >>>> >>>> Should this fix include the getClassLoaderClasses() as well? >>>> I'm still trying to realize the impact and consistency of this fix. :( >>>> >>>> What tests are you going to run for verification? >>>> >>>> Thanks, >>>> Serguei >>>> * >>>> *On 9/30/13 4:45 AM, Fredrik Arvidsson wrote: >>>>> Hi >>>>> >>>>> Please help me to review the changes below: >>>>> >>>>> Jira case: https://bugs.openjdk.java.net/browse/JDK-8024423 >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/ >>>>> >>>>> >>>>> In this review I still have an outstanding unanswered question >>>>> about the need to synchronize the access to the: >>>>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >>>>> and >>>>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >>>>> >>>>> calls in >>>>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/src/share/vm/prims/jvmtiGetLoadedClasses.cpp.udiff.html >>>>> >>>>> Please give me advise on this. >>>>> >>>>> There will be a review soon regarding re-enabling the tests that failed because of the above bug, see: >>>>> https://bugs.openjdk.java.net/browse/JDK-8025576 >>>>> >>>>> Cheers >>>>> /Fredrik >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131022/564c0f0a/attachment.html From stefan.karlsson at oracle.com Tue Oct 22 08:11:44 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 22 Oct 2013 17:11:44 +0200 Subject: RFR (S): JDK-8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes In-Reply-To: <525FEE10.9030508@oracle.com> References: <5249643F.3030209@oracle.com> <524A7B07.1000300@oracle.com> <524BE733.2070205@oracle.com> <525CF1F1.1010400@oracle.com> <525FEE10.9030508@oracle.com> Message-ID: <526695B0.2000402@oracle.com> On 10/17/13 4:02 PM, Fredrik Arvidsson wrote: > Hi > > I have added a new revision of my changes here: > http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.02/ > I haven't looked at the patch i great detail, but I found this code: + void LoadedClassesClosure::do_klass(Klass* k) { + // Collect all jclasses + for (Klass* l = k; l != NULL; l = l->array_klass_or_null()) { + oop mirror = l->java_mirror(); + _classStack.push((jclass) _env->jni_reference(mirror)); + } + } I think you are adding the array klasses multiple times. ClassLoaderData::loaded_classes_do() is visiting all array klasses, so you shouldn't be traversing the l->array_klass_or_null() chain. StefanK > The idea is to use a lock called metaspace_lock available inside the > ClassLoaderData objects that the ClassLoaderDataGraph holds, this > prevents classes to be added/removed/updated during the gathering > phase. When iterating using the new LoadedClassesClosure > implementation only array classes and instance classes that are marked > as loaded will be visited. The LoadedClassesClosure implementation > uses a Stack to store classes during the gathering phase. This > changes the count-allocate-add-extract approach that was used before > into a add-extract way of doing it instead. > > I am still not sure how to do with the GetClassLoaderClasses to make > it consistent. I would eventually like to get rid of the > JvmtiGetLoadedClassesClosure and the use of the SystemDictionary if > possible. But right now I just cant see how to get hold of the > initiating loader for a class without using the SystemDictionary. > > /Fredrik > > On 2013-10-15 09:42, serguei.spitsyn at oracle.com wrote: >> >> There are two questions on the list that we still need to resolve in >> this fix: >> (1) What is the best way to protect the work with CLDG from >> concurrent additions of CLD's to it >> (2) The *GetClassLoaderClasses* needs a fix as well to be consistent >> with the GetLoadedClasses >> >> I had some private conversations with Fredrik and John Rose and >> after some analysis came up with the suggestion: >> >> (1) Continue using the *SystemDictionary_lock* to protect >> consistency of the loaded classes data. >> The issue is that adding CLD's to the SLDG is not currently >> protected by the *SystemDictionary_lock*. >> I'm suggesting to add it to the >> *SystemDictionary::parse_stream* (please, see the webrev below). >> >> (2) There was some doubt that a similar fix for the >> *GetClassLoaderClasses* is needed because >> the CL+SD (taken from the host class) does not reference the >> associated anonymous classes. >> The question is: Can we consider the host's class CL as the >> initiating CL? >> My reading is that the answer to this question is: "Yes, we can". >> Even though the CL itself does not have references to its >> anonymous classes, >> there are references from the anonymous classes's CLD's to its CL. >> These references can be used in the *increment_with_loader* >> and *add_with_loader* >> the same way as it was before. >> >> This is a webrev that includes the Fredrik's fix as a base plus the >> implemented suggestion: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/fredrik/8024423-JVMTI-ANO/ >> >> Some help from the HotSpot team is needed to estimate if this >> approach is Ok and does not have rat holes in it. >> Opinions are very welcome. >> >> Thanks, >> Serguei >> >> >> On 10/2/13 2:28 AM, Fredrik Arvidsson wrote: >>> Hi and thanks for all your comments. >>> >>> I have simplified the code in *instanceKlass.cpp* like suggested and >>> here is a new webrev: >>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.01/ >>> >>> >>> Regarding the need to synchronize the access to ClassLoaderDataGraph >>> I have come to the conclusion that it should be safe to call this >>> without any additional synchronization since newly loaded and added >>> classes are appended to the end of its 'list' of classes. This would >>> mean that the call could 'miss' the classes added during the >>> collection phase, but this is not a big issue. I hope that my >>> conclusion is correct. >>> >>> I believe that the JvmtiGetLoadedClasses::getClassLoaderClasses(...) >>> method is to be left alone this time since I got the impression that >>> only SystemDictionary 'knows' about initiating class loaders. >>> >>> There is plenty of room for improvement and simplification of much >>> of the code in this area, but I feel that it must wait until another >>> time. The task to re-factor and simplify would quickly grow out of >>> hands I'm afraid :) >>> >>> Cheers >>> /Fredrik >>> >>> On 2013-10-01 09:34, serguei.spitsyn at oracle.com wrote: >>>> Hi Frederik, >>>> >>>> >>>> Thank you for jumping on this issue! >>>> >>>> >>>> *src/share/vm/oops/instanceKlass.cpp* >>>> 2333 int src_index = 0; >>>> 2334 while (src_index < src_length) { >>>> 2335 dest[dest_index++] = src[src_index++]; >>>> 2336 } >>>> 2337 >>>> 2338 // If we have a hash, append it >>>> 2339 if(hash_len > 0) { >>>> 2340 int hash_index = 0; >>>> 2341 while (hash_index < hash_len) { >>>> 2342 dest[dest_index++] = hash_buf[hash_index++]; >>>> 2343 } >>>> 2344 } >>>> >>>> The above can be simplified a little bit: >>>> // Add the actual class name >>>> for (int src_index = 0; src_index < src_length; ) { >>>> dest[dest_index++] = src[src_index++]; >>>> } >>>> // If we have a hash, append it >>>> for (int hash_index = 0; hash_index < hash_len; ) { >>>> dest[dest_index++] = hash_buf[hash_index++]; >>>> } >>>> >>>> The conditionif(hash_len > 0) is covered by the loop itself. >>>> >>>> Style-related comments: >>>> -wrong indent at the lines: 2316-2319 >>>> - need a space after the 'if' at the lines: 2315, 2339 >>>> >>>> >>>> *src/share/vm/prims/jvmtiGetLoadedClasses.cpp >>>> >>>> *The copyright comment must be up-to-date. >>>> The comments at the lines 35-38, 258-260 are not valid anymore. >>>> >>>> >>>> > In this review I still have an outstanding unanswered question about >>>> > the need to synchronize the access to the: >>>> >>>> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >>>> > and >>>> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >>>> >>>> This kind of walking is usually done at safepoint in a VM_Operation. >>>> You will find many examples in the jvmtiEnv.cpp, for instance, VM_GetAllStackTraces. >>>> The suggestion from Mikael is good too. >>>> >>>> Should this fix include the getClassLoaderClasses() as well? >>>> I'm still trying to realize the impact and consistency of this fix. :( >>>> >>>> What tests are you going to run for verification? >>>> >>>> Thanks, >>>> Serguei >>>> * >>>> *On 9/30/13 4:45 AM, Fredrik Arvidsson wrote: >>>>> Hi >>>>> >>>>> Please help me to review the changes below: >>>>> >>>>> Jira case: https://bugs.openjdk.java.net/browse/JDK-8024423 >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/ >>>>> >>>>> >>>>> In this review I still have an outstanding unanswered question >>>>> about the need to synchronize the access to the: >>>>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >>>>> and >>>>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >>>>> >>>>> calls in >>>>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/src/share/vm/prims/jvmtiGetLoadedClasses.cpp.udiff.html >>>>> >>>>> Please give me advise on this. >>>>> >>>>> There will be a review soon regarding re-enabling the tests that failed because of the above bug, see: >>>>> https://bugs.openjdk.java.net/browse/JDK-8025576 >>>>> >>>>> Cheers >>>>> /Fredrik >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131022/0e11e193/attachment-0001.html From serguei.spitsyn at oracle.com Tue Oct 22 08:31:44 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 22 Oct 2013 08:31:44 -0700 Subject: RFR (S): JDK-8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes In-Reply-To: <525FEE10.9030508@oracle.com> References: <5249643F.3030209@oracle.com> <524A7B07.1000300@oracle.com> <524BE733.2070205@oracle.com> <525CF1F1.1010400@oracle.com> <525FEE10.9030508@oracle.com> Message-ID: <52669A60.10605@oracle.com> Hi Fredrik, The fix looks good modulo the comment from Stefan about the array classes. Thank you for addressing the comments from the 1st round! Please, file an RFE on the GetClassLoaderClasses to keep track of it. Thanks, Serguei On 10/17/13 7:02 AM, Fredrik Arvidsson wrote: > Hi > > I have added a new revision of my changes here: > http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.02/ > > > The idea is to use a lock called metaspace_lock available inside the > ClassLoaderData objects that the ClassLoaderDataGraph holds, this > prevents classes to be added/removed/updated during the gathering > phase. When iterating using the new LoadedClassesClosure > implementation only array classes and instance classes that are marked > as loaded will be visited. The LoadedClassesClosure implementation > uses a Stack to store classes during the gathering phase. This > changes the count-allocate-add-extract approach that was used before > into a add-extract way of doing it instead. > > I am still not sure how to do with the GetClassLoaderClasses to make > it consistent. I would eventually like to get rid of the > JvmtiGetLoadedClassesClosure and the use of the SystemDictionary if > possible. But right now I just cant see how to get hold of the > initiating loader for a class without using the SystemDictionary. > > /Fredrik > > On 2013-10-15 09:42, serguei.spitsyn at oracle.com wrote: >> >> There are two questions on the list that we still need to resolve in >> this fix: >> (1) What is the best way to protect the work with CLDG from >> concurrent additions of CLD's to it >> (2) The *GetClassLoaderClasses* needs a fix as well to be consistent >> with the GetLoadedClasses >> >> I had some private conversations with Fredrik and John Rose and >> after some analysis came up with the suggestion: >> >> (1) Continue using the *SystemDictionary_lock* to protect >> consistency of the loaded classes data. >> The issue is that adding CLD's to the SLDG is not currently >> protected by the *SystemDictionary_lock*. >> I'm suggesting to add it to the >> *SystemDictionary::parse_stream* (please, see the webrev below). >> >> (2) There was some doubt that a similar fix for the >> *GetClassLoaderClasses* is needed because >> the CL+SD (taken from the host class) does not reference the >> associated anonymous classes. >> The question is: Can we consider the host's class CL as the >> initiating CL? >> My reading is that the answer to this question is: "Yes, we can". >> Even though the CL itself does not have references to its >> anonymous classes, >> there are references from the anonymous classes's CLD's to its CL. >> These references can be used in the *increment_with_loader* >> and *add_with_loader* >> the same way as it was before. >> >> This is a webrev that includes the Fredrik's fix as a base plus the >> implemented suggestion: >> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/fredrik/8024423-JVMTI-ANO/ >> >> Some help from the HotSpot team is needed to estimate if this >> approach is Ok and does not have rat holes in it. >> Opinions are very welcome. >> >> Thanks, >> Serguei >> >> >> On 10/2/13 2:28 AM, Fredrik Arvidsson wrote: >>> Hi and thanks for all your comments. >>> >>> I have simplified the code in *instanceKlass.cpp* like suggested and >>> here is a new webrev: >>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.01/ >>> >>> >>> Regarding the need to synchronize the access to ClassLoaderDataGraph >>> I have come to the conclusion that it should be safe to call this >>> without any additional synchronization since newly loaded and added >>> classes are appended to the end of its 'list' of classes. This would >>> mean that the call could 'miss' the classes added during the >>> collection phase, but this is not a big issue. I hope that my >>> conclusion is correct. >>> >>> I believe that the JvmtiGetLoadedClasses::getClassLoaderClasses(...) >>> method is to be left alone this time since I got the impression that >>> only SystemDictionary 'knows' about initiating class loaders. >>> >>> There is plenty of room for improvement and simplification of much >>> of the code in this area, but I feel that it must wait until another >>> time. The task to re-factor and simplify would quickly grow out of >>> hands I'm afraid :) >>> >>> Cheers >>> /Fredrik >>> >>> On 2013-10-01 09:34, serguei.spitsyn at oracle.com wrote: >>>> Hi Frederik, >>>> >>>> >>>> Thank you for jumping on this issue! >>>> >>>> >>>> *src/share/vm/oops/instanceKlass.cpp* >>>> 2333 int src_index = 0; >>>> 2334 while (src_index < src_length) { >>>> 2335 dest[dest_index++] = src[src_index++]; >>>> 2336 } >>>> 2337 >>>> 2338 // If we have a hash, append it >>>> 2339 if(hash_len > 0) { >>>> 2340 int hash_index = 0; >>>> 2341 while (hash_index < hash_len) { >>>> 2342 dest[dest_index++] = hash_buf[hash_index++]; >>>> 2343 } >>>> 2344 } >>>> >>>> The above can be simplified a little bit: >>>> // Add the actual class name >>>> for (int src_index = 0; src_index < src_length; ) { >>>> dest[dest_index++] = src[src_index++]; >>>> } >>>> // If we have a hash, append it >>>> for (int hash_index = 0; hash_index < hash_len; ) { >>>> dest[dest_index++] = hash_buf[hash_index++]; >>>> } >>>> >>>> The conditionif(hash_len > 0) is covered by the loop itself. >>>> >>>> Style-related comments: >>>> -wrong indent at the lines: 2316-2319 >>>> - need a space after the 'if' at the lines: 2315, 2339 >>>> >>>> >>>> *src/share/vm/prims/jvmtiGetLoadedClasses.cpp >>>> >>>> *The copyright comment must be up-to-date. >>>> The comments at the lines 35-38, 258-260 are not valid anymore. >>>> >>>> >>>> > In this review I still have an outstanding unanswered question about >>>> > the need to synchronize the access to the: >>>> >>>> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >>>> > and >>>> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >>>> >>>> This kind of walking is usually done at safepoint in a VM_Operation. >>>> You will find many examples in the jvmtiEnv.cpp, for instance, VM_GetAllStackTraces. >>>> The suggestion from Mikael is good too. >>>> >>>> Should this fix include the getClassLoaderClasses() as well? >>>> I'm still trying to realize the impact and consistency of this fix. :( >>>> >>>> What tests are you going to run for verification? >>>> >>>> Thanks, >>>> Serguei >>>> * >>>> *On 9/30/13 4:45 AM, Fredrik Arvidsson wrote: >>>>> Hi >>>>> >>>>> Please help me to review the changes below: >>>>> >>>>> Jira case: https://bugs.openjdk.java.net/browse/JDK-8024423 >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/ >>>>> >>>>> >>>>> In this review I still have an outstanding unanswered question >>>>> about the need to synchronize the access to the: >>>>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >>>>> and >>>>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >>>>> >>>>> calls in >>>>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/src/share/vm/prims/jvmtiGetLoadedClasses.cpp.udiff.html >>>>> >>>>> Please give me advise on this. >>>>> >>>>> There will be a review soon regarding re-enabling the tests that failed because of the above bug, see: >>>>> https://bugs.openjdk.java.net/browse/JDK-8025576 >>>>> >>>>> Cheers >>>>> /Fredrik >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131022/b2562d87/attachment.html From chris.hegarty at oracle.com Tue Oct 22 05:36:20 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 22 Oct 2013 12:36:20 +0000 Subject: hg: jdk8/tl/jdk: 8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with the latest jdk8 build Message-ID: <20131022123706.7CC186260C@hg.openjdk.java.net> Changeset: 6a1989dc302d Author: igerasim Date: 2013-10-15 18:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a1989dc302d 8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with the latest jdk8 build Summary: Removing the test as it is unreliable and fails intermittently Reviewed-by: chegar - test/java/net/NetworkInterface/MemLeakTest.java From sundararajan.athijegannathan at oracle.com Tue Oct 22 10:07:41 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 22 Oct 2013 17:07:41 +0000 Subject: hg: jdk8/tl/nashorn: 4 new changesets Message-ID: <20131022170746.7ACAB6262F@hg.openjdk.java.net> Changeset: 0ecbc0188b64 Author: attila Date: 2013-10-22 16:43 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0ecbc0188b64 8027031: complete merging of loads and converts Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java Changeset: 6f19eb443a47 Author: attila Date: 2013-10-22 17:52 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/6f19eb443a47 8027037: Make ScriptObjectMirror conversions work for any JSObject Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/nashorn/api/scripting/JSObject.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java Changeset: eae4e4c1f613 Author: sundar Date: 2013-10-22 22:04 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/eae4e4c1f613 8027020: [regression] java.lang.VerifyError: Bad type on operand stack Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/runtime/ScriptLoader.java Changeset: 734f71f8a2c3 Author: sundar Date: 2013-10-22 22:12 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/734f71f8a2c3 Merge From brian.burkhalter at oracle.com Tue Oct 22 10:45:40 2013 From: brian.burkhalter at oracle.com (brian.burkhalter at oracle.com) Date: Tue, 22 Oct 2013 17:45:40 +0000 Subject: hg: jdk8/tl/jdk: 8026806: Incomplete test of getaddrinfo() return value could lead to incorrect exception for Windows Inet 6 Message-ID: <20131022174611.289E562631@hg.openjdk.java.net> Changeset: 9758edb6976f Author: bpb Date: 2013-10-22 10:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9758edb6976f 8026806: Incomplete test of getaddrinfo() return value could lead to incorrect exception for Windows Inet 6 Summary: Check getaddrinfo return value before calling WSAGetLastError. Reviewed-by: alanb, dsamersoff ! src/windows/native/java/net/Inet6AddressImpl.c From eric.mccorkle at oracle.com Tue Oct 22 10:56:14 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Tue, 22 Oct 2013 17:56:14 +0000 Subject: hg: jdk8/tl/jdk: 8026818: Defmeth failures with -mode invoke Message-ID: <20131022175633.3094562632@hg.openjdk.java.net> Changeset: 23b124cbf242 Author: drchase Date: 2013-10-22 12:57 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23b124cbf242 8026818: Defmeth failures with -mode invoke Summary: Added test for IllegalAccessException -> IllegalAccessError path to check if root cause was AbstractMethodError Reviewed-by: jrose ! src/share/classes/java/lang/invoke/MethodHandleNatives.java From alexander.zuev at oracle.com Tue Oct 22 11:21:33 2013 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Tue, 22 Oct 2013 18:21:33 +0000 Subject: hg: jdk8/tl/jdk: 8026873: tools/launcher/VersionCheck.java fails in jprt because of jmc.ini Message-ID: <20131022182200.2511A62633@hg.openjdk.java.net> Changeset: 72c0f289a8cb Author: kizune Date: 2013-10-22 22:18 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72c0f289a8cb 8026873: tools/launcher/VersionCheck.java fails in jprt because of jmc.ini Reviewed-by: ksrini ! test/tools/launcher/VersionCheck.java From brian.burkhalter at oracle.com Tue Oct 22 11:29:39 2013 From: brian.burkhalter at oracle.com (brian.burkhalter at oracle.com) Date: Tue, 22 Oct 2013 18:29:39 +0000 Subject: hg: jdk8/tl/jdk: 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE; ... Message-ID: <20131022183012.BF5E962634@hg.openjdk.java.net> Changeset: 2be08cdd1ced Author: bpb Date: 2013-10-22 11:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2be08cdd1ced 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE 6445180: URLClassLoader does not describe the behavior of several methods with respect to null arguments Summary: Document when a NPE will be thrown by URLClassLoader constructors, newInstance(), findClass(), and getPermissions(). Reviewed-by: alanb, mduigou, chegar, dholmes, jrose ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/javax/management/remote/rmi/NoCallStackClassLoader.java ! src/share/classes/sun/applet/AppletClassLoader.java + test/java/net/URLClassLoader/NullURLTest.java From joe.darcy at oracle.com Tue Oct 22 12:07:55 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 22 Oct 2013 19:07:55 +0000 Subject: hg: jdk8/tl/jdk: 8027062: Fix lint and doclint issues in java.lang.{ClassLoader, ClassValue, SecurityManager} Message-ID: <20131022190815.58A6962637@hg.openjdk.java.net> Changeset: 9a32af82bd1e Author: darcy Date: 2013-10-22 12:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9a32af82bd1e 8027062: Fix lint and doclint issues in java.lang.{ClassLoader, ClassValue, SecurityManager} Reviewed-by: chegar, forax, alanb, mduigou ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/ClassValue.java ! src/share/classes/java/lang/SecurityManager.java From jason.uh at oracle.com Tue Oct 22 11:58:28 2013 From: jason.uh at oracle.com (jason.uh at oracle.com) Date: Tue, 22 Oct 2013 18:58:28 +0000 Subject: hg: jdk8/tl/jdk: 8025287: NPE in api/java_security/cert/PKIXRevocationChecker/GeneralTests_GeneralTests Message-ID: <20131022185847.9573E62635@hg.openjdk.java.net> Changeset: c956a5d0618f Author: juh Date: 2013-10-22 11:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c956a5d0618f 8025287: NPE in api/java_security/cert/PKIXRevocationChecker/GeneralTests_GeneralTests Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! test/java/security/cert/PKIXRevocationChecker/UnitTest.java From roger.riggs at oracle.com Tue Oct 22 12:14:52 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Tue, 22 Oct 2013 19:14:52 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20131022191556.1E56E62638@hg.openjdk.java.net> Changeset: e2b814e68956 Author: rriggs Date: 2013-10-22 15:03 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2b814e68956 8024686: Cleanup of java.time serialization source Summary: optimize serialized form of OffsetTime, OffsetDateTime; correct order of modifiers Reviewed-by: sherman ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/chrono/ChronoPeriodImpl.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/temporal/WeekFields.java ! src/share/classes/java/time/zone/Ser.java ! src/share/classes/java/time/zone/ZoneOffsetTransition.java ! test/java/time/tck/java/time/serial/TCKOffsetDateTimeSerialization.java ! test/java/time/tck/java/time/serial/TCKOffsetTimeSerialization.java Changeset: d5c2b125ed0f Author: rriggs Date: 2013-10-22 15:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d5c2b125ed0f Merge Changeset: cd60848c87b2 Author: rriggs Date: 2013-10-22 15:11 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd60848c87b2 Merge From mandy.chung at oracle.com Tue Oct 22 12:38:56 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 Oct 2013 12:38:56 -0700 Subject: RFR 7112404: 2 tests in java/lang/management/ManagementFactory fails with G1 because expect non-zero pools In-Reply-To: <52653E58.9070508@oracle.com> References: <52653E58.9070508@oracle.com> Message-ID: <5266D450.5050506@oracle.com> On 10/21/13 7:46 AM, Jaroslav Bachorik wrote: > Please, review this simple test fix. > > Issue: https://bugs.openjdk.java.net/browse/JDK-7112404 > Webrev: http://cr.openjdk.java.net/~jbachorik/7112404/webrev.00 > Looks okay to me. Mandy > The tests assume the MemoryUsage#commited values to be positive (>0) > while according to the MemoryUsage only negative values are invalid. > Therefore the tests should check and fail only when > MemoryUsage#commited is < 0. > > Thanks, > > -JB- From mandy.chung at oracle.com Tue Oct 22 13:04:38 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 Oct 2013 13:04:38 -0700 Subject: RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: <526681FD.90604@oracle.com> References: <526681FD.90604@oracle.com> Message-ID: <5266DA56.6050609@oracle.com> Hi Jaroslav, On 10/22/13 6:47 AM, Jaroslav Bachorik wrote: > Please, review the following test fix: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8020467 > Webrev: http://cr.openjdk.java.net/~jbachorik/8020467/webrev.01 > Have you considered to force GC when getUsed() == 0 regardless of which memory pool it is? This will avoid special casing for CMS old gen in the test and will handle similar issue in the future for a different collector implementation. To make the test reliable, the test should still pass if the memory pool has no object in it (G1 survivor space case?). Mandy > The test tries to make sure that the "pool usage threshold" trigger > and the reported pool memory usage are not contradicting each other. > The problem is that it is not possible to get the "pool usage > threshold exceeded" flag and the pool memory usage atomicly in regard > to the GC. Specifically, when "CMS Old Gen" pool is examined and the > usage is retrieved before a GC promotes some objects to the old gen > but the usage threshold is checked after the GC has promoted some > instance into the old gen the test will fail. > > The patch makes sure that there are some instances promoted in "CMS > Old Gen" before checking the "pool usage threshold" to get > semi-consistent view. > > Thanks, > > -JB- From michael.fang at oracle.com Tue Oct 22 14:39:52 2013 From: michael.fang at oracle.com (michael.fang at oracle.com) Date: Tue, 22 Oct 2013 21:39:52 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20131022214106.4FDE562644@hg.openjdk.java.net> Changeset: e84413f066e0 Author: mfang Date: 2013-10-22 14:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e84413f066e0 8026109: [ja] overtranslation of jarsigner in command line output Reviewed-by: naoto ! src/share/classes/sun/security/tools/jarsigner/Resources_ja.java Changeset: 25ebb8b61371 Author: mfang Date: 2013-10-22 14:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/25ebb8b61371 6607048: clear extra l10n resource files in demo Reviewed-by: naoto, yhuang - src/share/demo/jfc/Notepad/resources/Notepad_fr.properties - src/share/demo/jfc/Notepad/resources/Notepad_sv.properties Changeset: f2ddffb4b165 Author: mfang Date: 2013-10-22 14:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f2ddffb4b165 Merge From roger.riggs at oracle.com Tue Oct 22 14:16:59 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Tue, 22 Oct 2013 21:16:59 +0000 Subject: hg: jdk8/tl/jdk: 8026982: javadoc errors in core libs Message-ID: <20131022211712.B127862640@hg.openjdk.java.net> Changeset: 4bb758a77fd7 Author: rriggs Date: 2013-10-22 17:02 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bb758a77fd7 8026982: javadoc errors in core libs Summary: Cleanup of javadoc -Xlint errors Reviewed-by: lancea, mduigou, darcy, mullan, mchung ! src/share/classes/java/io/ByteArrayInputStream.java ! src/share/classes/java/io/ByteArrayOutputStream.java ! src/share/classes/java/io/DataInput.java ! src/share/classes/java/io/DataOutput.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/io/InputStream.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/PipedInputStream.java ! src/share/classes/java/io/PipedReader.java ! src/share/classes/java/io/RandomAccessFile.java ! src/share/classes/java/io/Serializable.java ! src/share/classes/java/io/SerializablePermission.java ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/ArrayStoreException.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassCastException.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/RuntimePermission.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/ManagementPermission.java ! src/share/classes/java/lang/management/MemoryUsage.java ! src/share/classes/java/lang/management/package.html ! src/share/classes/java/lang/reflect/ReflectPermission.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/MulticastSocket.java ! src/share/classes/java/net/NetPermission.java ! src/share/classes/java/net/Proxy.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketOptions.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/java/net/URI.java ! src/share/classes/java/net/URLConnection.java ! src/share/classes/java/net/URLDecoder.java ! src/share/classes/java/net/URLEncoder.java ! src/share/classes/java/net/URLPermission.java ! src/share/classes/java/net/package-info.java ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/file/FileSystem.java ! src/share/classes/java/rmi/activation/ActivationGroup.java ! src/share/classes/java/rmi/dgc/VMID.java ! src/share/classes/java/rmi/server/UnicastRemoteObject.java ! src/share/classes/java/security/AccessController.java ! src/share/classes/java/security/AlgorithmParameterGenerator.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/CodeSource.java ! src/share/classes/java/security/Key.java ! src/share/classes/java/security/KeyPairGenerator.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/MessageDigest.java ! src/share/classes/java/security/Permission.java ! src/share/classes/java/security/PermissionCollection.java ! src/share/classes/java/security/SecurityPermission.java ! src/share/classes/java/security/Signature.java ! src/share/classes/java/security/SignedObject.java ! src/share/classes/java/security/acl/Acl.java ! src/share/classes/java/security/cert/CertificateFactory.java ! src/share/classes/java/security/cert/PKIXRevocationChecker.java ! src/share/classes/java/security/cert/PolicyQualifierInfo.java ! src/share/classes/java/security/cert/TrustAnchor.java ! src/share/classes/java/security/cert/X509CertSelector.java ! src/share/classes/java/security/interfaces/DSAKeyPairGenerator.java ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/java/text/Normalizer.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/util/Base64.java ! src/share/classes/java/util/BitSet.java ! src/share/classes/java/util/Deque.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/Properties.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/java/util/Queue.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/java/util/UUID.java ! src/share/classes/java/util/concurrent/BlockingDeque.java ! src/share/classes/java/util/concurrent/BlockingQueue.java ! src/share/classes/java/util/concurrent/Future.java ! src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java ! src/share/classes/java/util/jar/Pack200.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/spi/LocaleServiceProvider.java From stuart.marks at oracle.com Tue Oct 22 14:58:33 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Tue, 22 Oct 2013 21:58:33 +0000 Subject: hg: jdk8/tl/jdk: 8026427: deprecate obsolete APIs from java.rmi Message-ID: <20131022215848.A9B0B62645@hg.openjdk.java.net> Changeset: 9fbf35589211 Author: smarks Date: 2013-10-22 14:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9fbf35589211 8026427: deprecate obsolete APIs from java.rmi Reviewed-by: alanb, dfuchs ! src/share/classes/java/rmi/RMISecurityManager.java ! src/share/classes/java/rmi/activation/ActivationGroup.java ! src/share/classes/java/rmi/server/ServerRef.java ! src/share/classes/java/rmi/server/SocketSecurityException.java From henry.jen at oracle.com Tue Oct 22 15:24:43 2013 From: henry.jen at oracle.com (henry.jen at oracle.com) Date: Tue, 22 Oct 2013 22:24:43 +0000 Subject: hg: jdk8/tl/jdk: 8025909: Lambda Library Spec Updates; ... Message-ID: <20131022222514.047256264E@hg.openjdk.java.net> Changeset: 0913c3bab168 Author: henryjen Date: 2013-10-22 15:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0913c3bab168 8025909: Lambda Library Spec Updates 8024179: Document limitations and performance characteristics of stream sources and operations 8024138: (Spec clarification) Lambda Metafacory spec should state DMH constraint on implMethod Reviewed-by: mduigou Contributed-by: brian.goetz at oracle.com, paul.sandoz at oracle.com ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/share/classes/java/lang/invoke/SerializedLambda.java ! src/share/classes/java/util/DoubleSummaryStatistics.java ! src/share/classes/java/util/Iterator.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/PrimitiveIterator.java ! src/share/classes/java/util/Spliterator.java ! src/share/classes/java/util/function/package-info.java ! src/share/classes/java/util/stream/BaseStream.java ! src/share/classes/java/util/stream/Collectors.java ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Node.java ! src/share/classes/java/util/stream/SpinedBuffer.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/StreamSupport.java ! src/share/classes/java/util/stream/package-info.java From harold.seigel at oracle.com Tue Oct 22 16:06:27 2013 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 22 Oct 2013 23:06:27 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8026394: Eclipse fails with JDK8 build 111 Message-ID: <20131022230632.2329062650@hg.openjdk.java.net> Changeset: 662c154d2749 Author: hseigel Date: 2013-10-22 14:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/662c154d2749 8026394: Eclipse fails with JDK8 build 111 Summary: If the resolved interface does not itself contain "clone" or "finalize" methods, the method/interface method resolution looks to the interface's super class, java.lang.Object. With the JDK 8 interface method accessability check requirement, since these two methods are declared within Object as protected, they must be special cased in LinkResolver::check_method_accessability() in order to avoid an IAE. Reviewed-by: acorn, dholmes Contributed-by: lois.foltan at oracle.com ! src/share/vm/interpreter/linkResolver.cpp + test/runtime/8026394/InterfaceObjectTest.java From sean.mullan at oracle.com Tue Oct 22 16:45:36 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 22 Oct 2013 23:45:36 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131022234642.4FFA762659@hg.openjdk.java.net> Changeset: fc7a6fa3589a Author: ascarpino Date: 2013-10-22 19:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc7a6fa3589a 8025763: Provider does not override new Hashtable methods Reviewed-by: mullan ! src/share/classes/java/security/Provider.java Changeset: b065de1700d3 Author: mullan Date: 2013-10-22 19:43 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b065de1700d3 Merge - src/share/demo/jfc/Notepad/resources/Notepad_fr.properties - src/share/demo/jfc/Notepad/resources/Notepad_sv.properties From robert.field at oracle.com Tue Oct 22 16:55:56 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Tue, 22 Oct 2013 23:55:56 +0000 Subject: hg: jdk8/tl/langtools: 8023668: Desugar serializable lambda bodies using more robust naming scheme Message-ID: <20131022235607.226DE6265E@hg.openjdk.java.net> Changeset: 6cd16d8ed2b9 Author: rfield Date: 2013-10-22 16:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6cd16d8ed2b9 8023668: Desugar serializable lambda bodies using more robust naming scheme Summary: lambda / bridged method-reference naming overhaul Reviewed-by: ksrini, briangoetz ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! test/tools/javac/MethodParameters/LambdaTest.out ! test/tools/javac/T8019486/WrongLVTForLambdaTest.java + test/tools/javac/lambda/lambdaNaming/TestSerializedLambdaNameStability.java + test/tools/javac/lambda/lambdaNaming/after/TESTNameOfCapturedArgs.java + test/tools/javac/lambda/lambdaNaming/after/TESTOrderOfCapturedArgs.java + test/tools/javac/lambda/lambdaNaming/after/TESTTargetName.java + test/tools/javac/lambda/lambdaNaming/after/TESTTargetType.java + test/tools/javac/lambda/lambdaNaming/after/TESTTypesOfCapturedArgs.java + test/tools/javac/lambda/lambdaNaming/after/TESTVariableAssignmentTarget.java + test/tools/javac/lambda/lambdaNaming/before/TESTNameOfCapturedArgs.java + test/tools/javac/lambda/lambdaNaming/before/TESTOrderOfCapturedArgs.java + test/tools/javac/lambda/lambdaNaming/before/TESTTargetName.java + test/tools/javac/lambda/lambdaNaming/before/TESTTargetType.java + test/tools/javac/lambda/lambdaNaming/before/TESTTypesOfCapturedArgs.java + test/tools/javac/lambda/lambdaNaming/before/TESTVariableAssignmentTarget.java From weijun.wang at oracle.com Tue Oct 22 17:33:12 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 23 Oct 2013 00:33:12 +0000 Subject: hg: jdk8/tl/jdk: 8027026: Change keytool -genkeypair to use -keyalg RSA Message-ID: <20131023003331.C4AF262664@hg.openjdk.java.net> Changeset: d545d67e2f68 Author: weijun Date: 2013-10-23 08:32 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d545d67e2f68 8027026: Change keytool -genkeypair to use -keyalg RSA Reviewed-by: alanb, chegar, mullan ! test/ProblemList.txt ! test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh ! test/java/util/jar/JarInputStream/ExtraFileInMetaInf.java ! test/sun/security/pkcs12/PKCS12SameKeyId.java ! test/sun/security/tools/jarsigner/TimestampCheck.java ! test/sun/security/tools/jarsigner/checkusage.sh ! test/sun/security/tools/jarsigner/collator.sh ! test/sun/security/tools/jarsigner/crl.sh ! test/sun/security/tools/jarsigner/jvindex.sh ! test/sun/security/tools/jarsigner/newsize7.sh ! test/sun/security/tools/jarsigner/onlymanifest.sh ! test/sun/security/tools/jarsigner/passtype.sh ! test/sun/security/tools/jarsigner/samename.sh ! test/sun/security/tools/jarsigner/ts.sh ! test/sun/security/tools/keytool/CloseFile.java ! test/sun/security/tools/keytool/ListKeychainStore.sh ! test/sun/security/tools/keytool/StartDateTest.java ! test/sun/security/tools/keytool/UnknownAndUnparseable.java ! test/sun/security/tools/keytool/emptysubject.sh ! test/sun/security/tools/keytool/importreadall.sh ! test/sun/security/tools/keytool/p12importks.sh ! test/sun/security/tools/keytool/readjar.sh ! test/sun/security/tools/keytool/selfissued.sh ! test/sun/security/tools/keytool/trystore.sh ! test/sun/security/validator/certreplace.sh ! test/sun/security/validator/samedn.sh From david.holmes at oracle.com Tue Oct 22 17:40:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Oct 2013 10:40:21 +1000 Subject: RFR 6309226: TEST: java/lang/management/ThreadMXBean/SynchronizationStatistics.java didn't check Thread.sleep In-Reply-To: <52665B94.8090902@oracle.com> References: <52651646.4050705@oracle.com> <5266301D.5040002@oracle.com> <52665B94.8090902@oracle.com> Message-ID: <52671AF5.8050703@oracle.com> On 22/10/2013 9:03 PM, Jaroslav Bachorik wrote: > On 22.10.2013 09:58, David Holmes wrote: >> On 21/10/2013 9:55 PM, Jaroslav Bachorik wrote: >>> Please, review this small patch for a test failing due to the updated >>> implementation in JDK6. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-6309226 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.00/ >>> >>> The test fails due to the change in mustang where >>> ThreadMXBean.getThreadInfo().getWaitedTime() and >>> ThreadMXBean.getThreadInfo().getWaitedCount() include Thread.sleep() >>> too. Unfortunately, Thread.sleep() is used throughout the test for >>> synchronization purposes and this breaks the test. >>> >>> In the patch I propose to replace Thread.sleep() with busy wait and >>> hinting the scheduler by Thread.yield(). While not very elegant it >>> successfully works around inclusion of unknown number of Thread.sleep()s >>> (they are called in loop). >> >> Not elegant and not completely reliable either. Probably adequate on a >> multi-core system but single-core and with some schedulers it could just >> be a busy spin. > > :/ Ok, so I need to account for the Thread.sleep() calls made outside of > the test code but still reported by the ThreadMXBean. Not that elegant, > too, but at least should be reliable. > > http://cr.openjdk.java.net/~jbachorik/6309226/webrev.01 Sorry, I can't follow the logic of that test enough to determine whether this compensating logic is correct. Whether this is more reliable depends on whether the 5% tolerance in timeRangeCheck is enough to account for all the potential inaccuracies in the time measurements. On a lightly loaded system it may be, but otherwise ... a context switch after determining the base time and doing the sleep could add an arbitrary load and cpu-dependent delay. It might be less reliable than the yield approach :( I can't help wonder whether there is a more explicit synchronization mechanism that will avoid the need for goSleep? But that becomes a much bigger task to deal with. I will leave this for the serviceability team to determine the best course of action. Thanks, David > -JB- > >> >> David >> >>> Thanks, >>> >>> -JB- > From jonathan.gibbons at oracle.com Tue Oct 22 17:46:26 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 23 Oct 2013 00:46:26 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20131023004635.B39DA62666@hg.openjdk.java.net> Changeset: 351d6808c1a5 Author: jjg Date: 2013-10-22 17:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/351d6808c1a5 8027119: Cleanup javadoc comments for taglet API Reviewed-by: mduigou ! src/share/classes/com/sun/javadoc/Tag.java Changeset: 41d3ffca22ff Author: jjg Date: 2013-10-22 17:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/41d3ffca22ff Merge From ioi.lam at oracle.com Tue Oct 22 19:11:41 2013 From: ioi.lam at oracle.com (ioi.lam at oracle.com) Date: Wed, 23 Oct 2013 02:11:41 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20131023021215.2CC0D62669@hg.openjdk.java.net> Changeset: b8860472c377 Author: iklam Date: 2013-10-22 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b8860472c377 8014910: deadlock between JVM/TI ClassPrepare event handler and CompilerThread Summary: Revert changes in JDK-8008962 Reviewed-by: coleenp, sspitsyn ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiEnv.cpp Changeset: 28be4c586b70 Author: iklam Date: 2013-10-22 16:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/28be4c586b70 Merge From david.holmes at oracle.com Tue Oct 22 19:21:23 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Oct 2013 12:21:23 +1000 Subject: RFR: 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops (round 2) In-Reply-To: <20131021092651.GD2608@ehelin-thinkpad> References: <20131021092651.GD2608@ehelin-thinkpad> Message-ID: <526732A3.5030201@oracle.com> Hi Erik, Sorry I hadn't had a chance to get back to this. This new approach seems fine - though I had to convince myself of the no GC can occur part :) A couple of typos: JvmtiBreakpoint:s The :s should just be s Thanks, David On 21/10/2013 7:26 PM, Erik Helin wrote: > Hi all, > > this is the second version of a patch for JDK-8025834. > > Background: > In JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint, we create a > JvmtiBreakpoint on the stack. This JvmtiBreakpoint contains an > "unhandled" oop to the class loader of the Method's class. > > A pointer to the JvmtiBreakpoint allocated on the stack will be passed > to VM_ChangeBreakpoint via JvmtiBreakpoints::set/clear. The > VM_ChangeBreakpoint class has an oops_do method that will visit the oop > in the JvmtiBreakpoint that was allocated on the stack. > > Since no GC can occur before the JvmtiBreakpoint has been passed to the > VM_ChangeBreakpoint (which is then passed to VMThread::execute), there > is no need to have a Handle for the _class_loader oop. Once the > VM_ChangeBreakpoint is on the VMThread's list for being executed, the > oop will be found via VMThread::oops_do. > > The oop can't be changed to a Handle because JvmtiBreakpoint:s are also > allocated on the heap, and Handles are only used for oops allocated on > the stack. > > This patch therefore registers the oop as "unhandled" to tell the > unhandled oop verifier to (rightfully) ignore it. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8025834/round-2/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8025834 > > As I explained in a previous email, there are additional issues in the > JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreapoints methods: > - https://bugs.openjdk.java.net/browse/JDK-8026946 > - https://bugs.openjdk.java.net/browse/JDK-8026948 > This change does not intend to fix these issues. > > Thanks, > Erik > From david.holmes at oracle.com Tue Oct 22 19:37:20 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Oct 2013 12:37:20 +1000 Subject: RR(XS): JDK-8026950 Nits in agent ps_proc.c file breaks compilation of open hotspot In-Reply-To: <5264F8FC.7040307@oracle.com> References: <5264F8FC.7040307@oracle.com> Message-ID: <52673660.8080905@oracle.com> On 21/10/2013 7:50 PM, Dmitry Samersoff wrote: > Hi Everybody, > > Please review a small fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8026950/webrev.01/ I don't understand why this is only a compile error on "open hotspot"? PT_CONTINUE seems to be the necessary value for OSX and other BSD systems. Do some systems have an alias in place? Reviewed. David > -Dmitry > From harold.seigel at oracle.com Tue Oct 22 22:03:54 2013 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Wed, 23 Oct 2013 05:03:54 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20131023050416.59E006266E@hg.openjdk.java.net> Changeset: a997d762fa20 Author: hseigel Date: 2013-10-22 15:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a997d762fa20 8026809: [TESTBUG] Create regression test for JDK-8026041 Summary: Created simple regression test for the bug Reviewed-by: hseigel, lfoltan, zgu Contributed-by: mikhailo.seledtsov at oracle.com + test/runtime/CommandLine/PrintGCApplicationConcurrentTime.java Changeset: c183576a2dd1 Author: hseigel Date: 2013-10-22 22:14 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c183576a2dd1 Merge From staffan.larsen at oracle.com Tue Oct 22 22:50:24 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 23 Oct 2013 07:50:24 +0200 Subject: RR(XS): JDK-8026950 Nits in agent ps_proc.c file breaks compilation of open hotspot In-Reply-To: <52673660.8080905@oracle.com> References: <5264F8FC.7040307@oracle.com> <52673660.8080905@oracle.com> Message-ID: <19F50FC0-0E8B-4C27-B2EC-BF303EA8DC18@oracle.com> On 23 okt 2013, at 04:37, David Holmes wrote: > On 21/10/2013 7:50 PM, Dmitry Samersoff wrote: >> Hi Everybody, >> >> Please review a small fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8026950/webrev.01/ > > I don't understand why this is only a compile error on "open hotspot"? PT_CONTINUE seems to be the necessary value for OSX and other BSD systems. Do some systems have an alias in place? This code isn't used by the OS X port, only "other" BSD". /Staffan > > Reviewed. > > David > >> -Dmitry >> From staffan.larsen at oracle.com Wed Oct 23 00:30:58 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 23 Oct 2013 09:30:58 +0200 Subject: RFR (XXS) 8026808: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failed with unexpected exit value In-Reply-To: <52613A71.7010500@oracle.com> References: <52613A71.7010500@oracle.com> Message-ID: <97CA169C-FA98-47BA-83F3-2F26B6A2BE58@oracle.com> Looks good! Thanks, /Staffan On 18 okt 2013, at 15:41, Fredrik Arvidsson wrote: > Hi > > Please help me with this tiny review: > > Webrev: http://cr.openjdk.java.net/~farvidsson/8026808/webrev.00/index.html > Bug: https://bugs.openjdk.java.net/browse/JDK-8026808 > > About this bug: > This bug was revealed by another test-fix: https://bugs.openjdk.java.net/browse/JDK-8025638. The JDKToolLauncher have probably never worked in Solaris 64 environments. > > JTReg tests run in JPRT: http://sthjprt.se.oracle.com/archives/2013/10/2013-10-18-094943.farvidss.hotspot/ verified successful. > > Cheers > /F From jaroslav.bachorik at oracle.com Wed Oct 23 00:42:08 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 23 Oct 2013 09:42:08 +0200 Subject: RFR 6309226: TEST: java/lang/management/ThreadMXBean/SynchronizationStatistics.java didn't check Thread.sleep In-Reply-To: <52671AF5.8050703@oracle.com> References: <52651646.4050705@oracle.com> <5266301D.5040002@oracle.com> <52665B94.8090902@oracle.com> <52671AF5.8050703@oracle.com> Message-ID: <52677DD0.7000808@oracle.com> On 23.10.2013 02:40, David Holmes wrote: > On 22/10/2013 9:03 PM, Jaroslav Bachorik wrote: >> On 22.10.2013 09:58, David Holmes wrote: >>> On 21/10/2013 9:55 PM, Jaroslav Bachorik wrote: >>>> Please, review this small patch for a test failing due to the updated >>>> implementation in JDK6. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-6309226 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/6309226/webrev.00/ >>>> >>>> The test fails due to the change in mustang where >>>> ThreadMXBean.getThreadInfo().getWaitedTime() and >>>> ThreadMXBean.getThreadInfo().getWaitedCount() include Thread.sleep() >>>> too. Unfortunately, Thread.sleep() is used throughout the test for >>>> synchronization purposes and this breaks the test. >>>> >>>> In the patch I propose to replace Thread.sleep() with busy wait and >>>> hinting the scheduler by Thread.yield(). While not very elegant it >>>> successfully works around inclusion of unknown number of >>>> Thread.sleep()s >>>> (they are called in loop). >>> >>> Not elegant and not completely reliable either. Probably adequate on a >>> multi-core system but single-core and with some schedulers it could just >>> be a busy spin. >> >> :/ Ok, so I need to account for the Thread.sleep() calls made outside of >> the test code but still reported by the ThreadMXBean. Not that elegant, >> too, but at least should be reliable. >> >> http://cr.openjdk.java.net/~jbachorik/6309226/webrev.01 > > Sorry, I can't follow the logic of that test enough to determine whether > this compensating logic is correct. It simply adds the number of times and the time spent in sleeping during calls to goSleep() from the BlockedThread (the one that actually counts). It seems to be correct - otherwise the test would fail because the numbers wouldn't match. > > Whether this is more reliable depends on whether the 5% tolerance in > timeRangeCheck is enough to account for all the potential inaccuracies > in the time measurements. On a lightly loaded system it may be, but > otherwise ... a context switch after determining the base time and doing > the sleep could add an arbitrary load and cpu-dependent delay. It might > be less reliable than the yield approach :( I wonder how would "yield" in busy wait behave on a single core architecture. I need the second thread to progress while busy-waiting ... > > I can't help wonder whether there is a more explicit synchronization > mechanism that will avoid the need for goSleep? But that becomes a much > bigger task to deal with. Yes. The only task of this fix is to enable the test to be run even after Thread.sleep() started to be included in the waited time (sometime in JDK6 timeframe). I suppose the test was successfully used before the change and if there are any problems with timing additional issues will be filed and the test will be redesigned. For now I would like to keep the change simple and really focus on making the test executable on JDK7/8. > > I will leave this for the serviceability team to determine the best > course of action. Thanks for valuable comments, anyway. -JB- > > Thanks, > David > >> -JB- >> >>> >>> David >>> >>>> Thanks, >>>> >>>> -JB- >> From jaroslav.bachorik at oracle.com Wed Oct 23 01:02:08 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 23 Oct 2013 10:02:08 +0200 Subject: RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: <5266DA56.6050609@oracle.com> References: <526681FD.90604@oracle.com> <5266DA56.6050609@oracle.com> Message-ID: <52678280.1070004@oracle.com> On 22.10.2013 22:04, Mandy Chung wrote: > Hi Jaroslav, > > On 10/22/13 6:47 AM, Jaroslav Bachorik wrote: >> Please, review the following test fix: >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8020467 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8020467/webrev.01 >> > > Have you considered to force GC when getUsed() == 0 regardless of which > memory pool it is? This will avoid special casing for CMS old gen in > the test and will handle similar issue in the future for a different > collector implementation. To make the test reliable, the test should > still pass if the memory pool has no object in it (G1 survivor space > case?). Hi Mandy, I don't know whether GC will help for other pools - but I can enable it for all pools - it should not hurt. The test should pass even with on object in the monitored pool since the pool should not report an exceeded threshold. -JB- > > Mandy > >> The test tries to make sure that the "pool usage threshold" trigger >> and the reported pool memory usage are not contradicting each other. >> The problem is that it is not possible to get the "pool usage >> threshold exceeded" flag and the pool memory usage atomicly in regard >> to the GC. Specifically, when "CMS Old Gen" pool is examined and the >> usage is retrieved before a GC promotes some objects to the old gen >> but the usage threshold is checked after the GC has promoted some >> instance into the old gen the test will fail. >> >> The patch makes sure that there are some instances promoted in "CMS >> Old Gen" before checking the "pool usage threshold" to get >> semi-consistent view. >> >> Thanks, >> >> -JB- > From fredrik.arvidsson at oracle.com Wed Oct 23 01:04:45 2013 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Wed, 23 Oct 2013 10:04:45 +0200 Subject: RFR (S): JDK-8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes In-Reply-To: <526695B0.2000402@oracle.com> References: <5249643F.3030209@oracle.com> <524A7B07.1000300@oracle.com> <524BE733.2070205@oracle.com> <525CF1F1.1010400@oracle.com> <525FEE10.9030508@oracle.com> <526695B0.2000402@oracle.com> Message-ID: <5267831D.4060101@oracle.com> Hi The latest and hopefully last review version of this change can be found here: http://cr.openjdk.java.net/~farvidsson/8024423/webrev.03/ Cheers /F On 2013-10-22 17:11, Stefan Karlsson wrote: > On 10/17/13 4:02 PM, Fredrik Arvidsson wrote: >> Hi >> >> I have added a new revision of my changes here: >> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.02/ >> > > I haven't looked at the patch i great detail, but I found this code: > > + void LoadedClassesClosure::do_klass(Klass* k) { > + // Collect all jclasses > + for (Klass* l = k; l != NULL; l = l->array_klass_or_null()) { > + oop mirror = l->java_mirror(); > + _classStack.push((jclass) _env->jni_reference(mirror)); > + } > + } > > I think you are adding the array klasses multiple times. > ClassLoaderData::loaded_classes_do() is visiting all array klasses, so > you shouldn't be traversing the l->array_klass_or_null() chain. > > StefanK > >> The idea is to use a lock called metaspace_lock available inside the >> ClassLoaderData objects that the ClassLoaderDataGraph holds, this >> prevents classes to be added/removed/updated during the gathering >> phase. When iterating using the new LoadedClassesClosure >> implementation only array classes and instance classes that are >> marked as loaded will be visited. The LoadedClassesClosure >> implementation uses a Stack to store classes during the >> gathering phase. This changes the count-allocate-add-extract approach >> that was used before into a add-extract way of doing it instead. >> >> I am still not sure how to do with the GetClassLoaderClasses to make >> it consistent. I would eventually like to get rid of the >> JvmtiGetLoadedClassesClosure and the use of the SystemDictionary if >> possible. But right now I just cant see how to get hold of the >> initiating loader for a class without using the SystemDictionary. >> >> /Fredrik >> >> On 2013-10-15 09:42, serguei.spitsyn at oracle.com wrote: >>> >>> There are two questions on the list that we still need to resolve in >>> this fix: >>> (1) What is the best way to protect the work with CLDG from >>> concurrent additions of CLD's to it >>> (2) The *GetClassLoaderClasses* needs a fix as well to be >>> consistent with the GetLoadedClasses >>> >>> I had some private conversations with Fredrik and John Rose and >>> after some analysis came up with the suggestion: >>> >>> (1) Continue using the *SystemDictionary_lock* to protect >>> consistency of the loaded classes data. >>> The issue is that adding CLD's to the SLDG is not currently >>> protected by the *SystemDictionary_lock*. >>> I'm suggesting to add it to the >>> *SystemDictionary::parse_stream* (please, see the webrev below). >>> >>> (2) There was some doubt that a similar fix for the >>> *GetClassLoaderClasses* is needed because >>> the CL+SD (taken from the host class) does not reference the >>> associated anonymous classes. >>> The question is: Can we consider the host's class CL as the >>> initiating CL? >>> My reading is that the answer to this question is: "Yes, we can". >>> Even though the CL itself does not have references to its >>> anonymous classes, >>> there are references from the anonymous classes's CLD's to >>> its CL. >>> These references can be used in the *increment_with_loader* >>> and *add_with_loader* >>> the same way as it was before. >>> >>> This is a webrev that includes the Fredrik's fix as a base plus the >>> implemented suggestion: >>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/fredrik/8024423-JVMTI-ANO/ >>> >>> Some help from the HotSpot team is needed to estimate if this >>> approach is Ok and does not have rat holes in it. >>> Opinions are very welcome. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/2/13 2:28 AM, Fredrik Arvidsson wrote: >>>> Hi and thanks for all your comments. >>>> >>>> I have simplified the code in *instanceKlass.cpp* like suggested >>>> and here is a new webrev: >>>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.01/ >>>> >>>> >>>> Regarding the need to synchronize the access to >>>> ClassLoaderDataGraph I have come to the conclusion that it should >>>> be safe to call this without any additional synchronization since >>>> newly loaded and added classes are appended to the end of its >>>> 'list' of classes. This would mean that the call could 'miss' the >>>> classes added during the collection phase, but this is not a big >>>> issue. I hope that my conclusion is correct. >>>> >>>> I believe that the >>>> JvmtiGetLoadedClasses::getClassLoaderClasses(...) method is to be >>>> left alone this time since I got the impression that only >>>> SystemDictionary 'knows' about initiating class loaders. >>>> >>>> There is plenty of room for improvement and simplification of much >>>> of the code in this area, but I feel that it must wait until >>>> another time. The task to re-factor and simplify would quickly grow >>>> out of hands I'm afraid :) >>>> >>>> Cheers >>>> /Fredrik >>>> >>>> On 2013-10-01 09:34, serguei.spitsyn at oracle.com wrote: >>>>> Hi Frederik, >>>>> >>>>> >>>>> Thank you for jumping on this issue! >>>>> >>>>> >>>>> *src/share/vm/oops/instanceKlass.cpp* >>>>> 2333 int src_index = 0; >>>>> 2334 while (src_index < src_length) { >>>>> 2335 dest[dest_index++] = src[src_index++]; >>>>> 2336 } >>>>> 2337 >>>>> 2338 // If we have a hash, append it >>>>> 2339 if(hash_len > 0) { >>>>> 2340 int hash_index = 0; >>>>> 2341 while (hash_index < hash_len) { >>>>> 2342 dest[dest_index++] = hash_buf[hash_index++]; >>>>> 2343 } >>>>> 2344 } >>>>> >>>>> The above can be simplified a little bit: >>>>> // Add the actual class name >>>>> for (int src_index = 0; src_index < src_length; ) { >>>>> dest[dest_index++] = src[src_index++]; >>>>> } >>>>> // If we have a hash, append it >>>>> for (int hash_index = 0; hash_index < hash_len; ) { >>>>> dest[dest_index++] = hash_buf[hash_index++]; >>>>> } >>>>> >>>>> The conditionif(hash_len > 0) is covered by the loop itself. >>>>> >>>>> Style-related comments: >>>>> -wrong indent at the lines: 2316-2319 >>>>> - need a space after the 'if' at the lines: 2315, 2339 >>>>> >>>>> >>>>> *src/share/vm/prims/jvmtiGetLoadedClasses.cpp >>>>> >>>>> *The copyright comment must be up-to-date. >>>>> The comments at the lines 35-38, 258-260 are not valid anymore. >>>>> >>>>> >>>>> > In this review I still have an outstanding unanswered question about >>>>> > the need to synchronize the access to the: >>>>> >>>>> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >>>>> > and >>>>> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >>>>> >>>>> This kind of walking is usually done at safepoint in a VM_Operation. >>>>> You will find many examples in the jvmtiEnv.cpp, for instance, VM_GetAllStackTraces. >>>>> The suggestion from Mikael is good too. >>>>> >>>>> Should this fix include the getClassLoaderClasses() as well? >>>>> I'm still trying to realize the impact and consistency of this fix. :( >>>>> >>>>> What tests are you going to run for verification? >>>>> >>>>> Thanks, >>>>> Serguei >>>>> * >>>>> *On 9/30/13 4:45 AM, Fredrik Arvidsson wrote: >>>>>> Hi >>>>>> >>>>>> Please help me to review the changes below: >>>>>> >>>>>> Jira case: https://bugs.openjdk.java.net/browse/JDK-8024423 >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/ >>>>>> >>>>>> >>>>>> In this review I still have an outstanding unanswered question >>>>>> about the need to synchronize the access to the: >>>>>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >>>>>> and >>>>>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >>>>>> >>>>>> calls in >>>>>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/src/share/vm/prims/jvmtiGetLoadedClasses.cpp.udiff.html >>>>>> >>>>>> Please give me advise on this. >>>>>> >>>>>> There will be a review soon regarding re-enabling the tests that failed because of the above bug, see: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8025576 >>>>>> >>>>>> Cheers >>>>>> /Fredrik >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131023/426d9db5/attachment-0001.html From staffan.larsen at oracle.com Wed Oct 23 01:08:24 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 23 Oct 2013 10:08:24 +0200 Subject: jmx-dev RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: <52678280.1070004@oracle.com> References: <526681FD.90604@oracle.com> <5266DA56.6050609@oracle.com> <52678280.1070004@oracle.com> Message-ID: <4972770C-A8BB-40A0-9BB8-885AA6B707BC@oracle.com> I think you can simplify the logic for forcing a GC to just a simple call to "System.gc();". AFAIK System.gc() will cause a full collection to happen for all collectors. /Staffan On 23 okt 2013, at 10:02, Jaroslav Bachorik wrote: > On 22.10.2013 22:04, Mandy Chung wrote: >> Hi Jaroslav, >> >> On 10/22/13 6:47 AM, Jaroslav Bachorik wrote: >>> Please, review the following test fix: >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8020467 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8020467/webrev.01 >>> >> >> Have you considered to force GC when getUsed() == 0 regardless of which >> memory pool it is? This will avoid special casing for CMS old gen in >> the test and will handle similar issue in the future for a different >> collector implementation. To make the test reliable, the test should >> still pass if the memory pool has no object in it (G1 survivor space >> case?). > > Hi Mandy, > > I don't know whether GC will help for other pools - but I can enable it for all pools - it should not hurt. > > The test should pass even with on object in the monitored pool since the pool should not report an exceeded threshold. > > -JB- > >> >> Mandy >> >>> The test tries to make sure that the "pool usage threshold" trigger >>> and the reported pool memory usage are not contradicting each other. >>> The problem is that it is not possible to get the "pool usage >>> threshold exceeded" flag and the pool memory usage atomicly in regard >>> to the GC. Specifically, when "CMS Old Gen" pool is examined and the >>> usage is retrieved before a GC promotes some objects to the old gen >>> but the usage threshold is checked after the GC has promoted some >>> instance into the old gen the test will fail. >>> >>> The patch makes sure that there are some instances promoted in "CMS >>> Old Gen" before checking the "pool usage threshold" to get >>> semi-consistent view. >>> >>> Thanks, >>> >>> -JB- >> > From jaroslav.bachorik at oracle.com Wed Oct 23 01:12:57 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 23 Oct 2013 10:12:57 +0200 Subject: jmx-dev RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: <4972770C-A8BB-40A0-9BB8-885AA6B707BC@oracle.com> References: <526681FD.90604@oracle.com> <5266DA56.6050609@oracle.com> <52678280.1070004@oracle.com> <4972770C-A8BB-40A0-9BB8-885AA6B707BC@oracle.com> Message-ID: <52678509.2020002@oracle.com> On 23.10.2013 10:08, Staffan Larsen wrote: > I think you can simplify the logic for forcing a GC to just a simple call to "System.gc();". AFAIK System.gc() will cause a full collection to happen for all collectors. Hm, will it now? I had the impression that it was just hinting the GC system to perform GC but it might decide to ignore it. I need to be sure that the GC was performed before continuing - otherwise I might get inconsistent data again. -JB- > > /Staffan > > On 23 okt 2013, at 10:02, Jaroslav Bachorik wrote: > >> On 22.10.2013 22:04, Mandy Chung wrote: >>> Hi Jaroslav, >>> >>> On 10/22/13 6:47 AM, Jaroslav Bachorik wrote: >>>> Please, review the following test fix: >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8020467 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8020467/webrev.01 >>>> >>> >>> Have you considered to force GC when getUsed() == 0 regardless of which >>> memory pool it is? This will avoid special casing for CMS old gen in >>> the test and will handle similar issue in the future for a different >>> collector implementation. To make the test reliable, the test should >>> still pass if the memory pool has no object in it (G1 survivor space >>> case?). >> >> Hi Mandy, >> >> I don't know whether GC will help for other pools - but I can enable it for all pools - it should not hurt. >> >> The test should pass even with on object in the monitored pool since the pool should not report an exceeded threshold. >> >> -JB- >> >>> >>> Mandy >>> >>>> The test tries to make sure that the "pool usage threshold" trigger >>>> and the reported pool memory usage are not contradicting each other. >>>> The problem is that it is not possible to get the "pool usage >>>> threshold exceeded" flag and the pool memory usage atomicly in regard >>>> to the GC. Specifically, when "CMS Old Gen" pool is examined and the >>>> usage is retrieved before a GC promotes some objects to the old gen >>>> but the usage threshold is checked after the GC has promoted some >>>> instance into the old gen the test will fail. >>>> >>>> The patch makes sure that there are some instances promoted in "CMS >>>> Old Gen" before checking the "pool usage threshold" to get >>>> semi-consistent view. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From serguei.spitsyn at oracle.com Wed Oct 23 01:18:14 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 23 Oct 2013 01:18:14 -0700 Subject: RFR (S): JDK-8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes In-Reply-To: <5267831D.4060101@oracle.com> References: <5249643F.3030209@oracle.com> <524A7B07.1000300@oracle.com> <524BE733.2070205@oracle.com> <525CF1F1.1010400@oracle.com> <525FEE10.9030508@oracle.com> <526695B0.2000402@oracle.com> <5267831D.4060101@oracle.com> Message-ID: <52678646.9050805@oracle.com> Fredrik, The fix is good, good job! It is still a good idea to run the nsk.jvmti and nsk.jdi tests to be safe. Thanks, Serguei On 10/23/13 1:04 AM, Fredrik Arvidsson wrote: > Hi > > The latest and hopefully last review version of this change can be > found here: > http://cr.openjdk.java.net/~farvidsson/8024423/webrev.03/ > > > Cheers > /F > > On 2013-10-22 17:11, Stefan Karlsson wrote: >> On 10/17/13 4:02 PM, Fredrik Arvidsson wrote: >>> Hi >>> >>> I have added a new revision of my changes here: >>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.02/ >>> >> >> I haven't looked at the patch i great detail, but I found this code: >> >> + void LoadedClassesClosure::do_klass(Klass* k) { >> + // Collect all jclasses >> + for (Klass* l = k; l != NULL; l = l->array_klass_or_null()) { >> + oop mirror = l->java_mirror(); >> + _classStack.push((jclass) _env->jni_reference(mirror)); >> + } >> + } >> >> I think you are adding the array klasses multiple times. >> ClassLoaderData::loaded_classes_do() is visiting all array klasses, >> so you shouldn't be traversing the l->array_klass_or_null() chain. >> >> StefanK >> >>> The idea is to use a lock called metaspace_lock available inside the >>> ClassLoaderData objects that the ClassLoaderDataGraph holds, this >>> prevents classes to be added/removed/updated during the gathering >>> phase. When iterating using the new LoadedClassesClosure >>> implementation only array classes and instance classes that are >>> marked as loaded will be visited. The LoadedClassesClosure >>> implementation uses a Stack to store classes during the >>> gathering phase. This changes the count-allocate-add-extract >>> approach that was used before into a add-extract way of doing it >>> instead. >>> >>> I am still not sure how to do with the GetClassLoaderClasses to make >>> it consistent. I would eventually like to get rid of the >>> JvmtiGetLoadedClassesClosure and the use of the SystemDictionary if >>> possible. But right now I just cant see how to get hold of the >>> initiating loader for a class without using the SystemDictionary. >>> >>> /Fredrik >>> >>> On 2013-10-15 09:42, serguei.spitsyn at oracle.com wrote: >>>> >>>> There are two questions on the list that we still need to resolve >>>> in this fix: >>>> (1) What is the best way to protect the work with CLDG from >>>> concurrent additions of CLD's to it >>>> (2) The *GetClassLoaderClasses* needs a fix as well to be >>>> consistent with the GetLoadedClasses >>>> >>>> I had some private conversations with Fredrik and John Rose and >>>> after some analysis came up with the suggestion: >>>> >>>> (1) Continue using the *SystemDictionary_lock* to protect >>>> consistency of the loaded classes data. >>>> The issue is that adding CLD's to the SLDG is not currently >>>> protected by the *SystemDictionary_lock*. >>>> I'm suggesting to add it to the >>>> *SystemDictionary::parse_stream* (please, see the webrev below). >>>> >>>> (2) There was some doubt that a similar fix for the >>>> *GetClassLoaderClasses* is needed because >>>> the CL+SD (taken from the host class) does not reference the >>>> associated anonymous classes. >>>> The question is: Can we consider the host's class CL as the >>>> initiating CL? >>>> My reading is that the answer to this question is: "Yes, we >>>> can". >>>> Even though the CL itself does not have references to its >>>> anonymous classes, >>>> there are references from the anonymous classes's CLD's to >>>> its CL. >>>> These references can be used in the *increment_with_loader* >>>> and *add_with_loader* >>>> the same way as it was before. >>>> >>>> This is a webrev that includes the Fredrik's fix as a base plus the >>>> implemented suggestion: >>>> http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2013/hotspot/fredrik/8024423-JVMTI-ANO/ >>>> >>>> Some help from the HotSpot team is needed to estimate if this >>>> approach is Ok and does not have rat holes in it. >>>> Opinions are very welcome. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 10/2/13 2:28 AM, Fredrik Arvidsson wrote: >>>>> Hi and thanks for all your comments. >>>>> >>>>> I have simplified the code in *instanceKlass.cpp* like suggested >>>>> and here is a new webrev: >>>>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.01/ >>>>> >>>>> >>>>> Regarding the need to synchronize the access to >>>>> ClassLoaderDataGraph I have come to the conclusion that it should >>>>> be safe to call this without any additional synchronization since >>>>> newly loaded and added classes are appended to the end of its >>>>> 'list' of classes. This would mean that the call could 'miss' the >>>>> classes added during the collection phase, but this is not a big >>>>> issue. I hope that my conclusion is correct. >>>>> >>>>> I believe that the >>>>> JvmtiGetLoadedClasses::getClassLoaderClasses(...) method is to be >>>>> left alone this time since I got the impression that only >>>>> SystemDictionary 'knows' about initiating class loaders. >>>>> >>>>> There is plenty of room for improvement and simplification of much >>>>> of the code in this area, but I feel that it must wait until >>>>> another time. The task to re-factor and simplify would quickly >>>>> grow out of hands I'm afraid :) >>>>> >>>>> Cheers >>>>> /Fredrik >>>>> >>>>> On 2013-10-01 09:34, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Frederik, >>>>>> >>>>>> >>>>>> Thank you for jumping on this issue! >>>>>> >>>>>> >>>>>> *src/share/vm/oops/instanceKlass.cpp* >>>>>> 2333 int src_index = 0; >>>>>> 2334 while (src_index < src_length) { >>>>>> 2335 dest[dest_index++] = src[src_index++]; >>>>>> 2336 } >>>>>> 2337 >>>>>> 2338 // If we have a hash, append it >>>>>> 2339 if(hash_len > 0) { >>>>>> 2340 int hash_index = 0; >>>>>> 2341 while (hash_index < hash_len) { >>>>>> 2342 dest[dest_index++] = hash_buf[hash_index++]; >>>>>> 2343 } >>>>>> 2344 } >>>>>> >>>>>> The above can be simplified a little bit: >>>>>> // Add the actual class name >>>>>> for (int src_index = 0; src_index < src_length; ) { >>>>>> dest[dest_index++] = src[src_index++]; >>>>>> } >>>>>> // If we have a hash, append it >>>>>> for (int hash_index = 0; hash_index < hash_len; ) { >>>>>> dest[dest_index++] = hash_buf[hash_index++]; >>>>>> } >>>>>> >>>>>> The conditionif(hash_len > 0) is covered by the loop itself. >>>>>> >>>>>> Style-related comments: >>>>>> -wrong indent at the lines: 2316-2319 >>>>>> - need a space after the 'if' at the lines: 2315, 2339 >>>>>> >>>>>> >>>>>> *src/share/vm/prims/jvmtiGetLoadedClasses.cpp >>>>>> >>>>>> *The copyright comment must be up-to-date. >>>>>> The comments at the lines 35-38, 258-260 are not valid anymore. >>>>>> >>>>>> >>>>>> > In this review I still have an outstanding unanswered question about >>>>>> > the need to synchronize the access to the: >>>>>> >>>>>> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >>>>>> > and >>>>>> > ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >>>>>> >>>>>> This kind of walking is usually done at safepoint in a VM_Operation. >>>>>> You will find many examples in the jvmtiEnv.cpp, for instance, VM_GetAllStackTraces. >>>>>> The suggestion from Mikael is good too. >>>>>> >>>>>> Should this fix include the getClassLoaderClasses() as well? >>>>>> I'm still trying to realize the impact and consistency of this fix. :( >>>>>> >>>>>> What tests are you going to run for verification? >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> * >>>>>> *On 9/30/13 4:45 AM, Fredrik Arvidsson wrote: >>>>>>> Hi >>>>>>> >>>>>>> Please help me to review the changes below: >>>>>>> >>>>>>> Jira case: https://bugs.openjdk.java.net/browse/JDK-8024423 >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/ >>>>>>> >>>>>>> >>>>>>> In this review I still have an outstanding unanswered question >>>>>>> about the need to synchronize the access to the: >>>>>>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::increment); >>>>>>> and >>>>>>> ClassLoaderDataGraph::classes_do(&JvmtiGetLoadedClassesClosure::add); >>>>>>> >>>>>>> calls in >>>>>>> http://cr.openjdk.java.net/~allwin/farvidss/8024423/webrev.00/src/share/vm/prims/jvmtiGetLoadedClasses.cpp.udiff.html >>>>>>> >>>>>>> Please give me advise on this. >>>>>>> >>>>>>> There will be a review soon regarding re-enabling the tests that failed because of the above bug, see: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025576 >>>>>>> >>>>>>> Cheers >>>>>>> /Fredrik >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131023/408184bb/attachment-0001.html From staffan.larsen at oracle.com Wed Oct 23 01:18:49 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 23 Oct 2013 10:18:49 +0200 Subject: jmx-dev RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: <52678509.2020002@oracle.com> References: <526681FD.90604@oracle.com> <5266DA56.6050609@oracle.com> <52678280.1070004@oracle.com> <4972770C-A8BB-40A0-9BB8-885AA6B707BC@oracle.com> <52678509.2020002@oracle.com> Message-ID: <68F92D47-E916-426B-8D6A-2EA48302053D@oracle.com> On 23 okt 2013, at 10:12, Jaroslav Bachorik wrote: > On 23.10.2013 10:08, Staffan Larsen wrote: >> I think you can simplify the logic for forcing a GC to just a simple call to "System.gc();". AFAIK System.gc() will cause a full collection to happen for all collectors. > > Hm, will it now? I had the impression that it was just hinting the GC system to perform GC but it might decide to ignore it. I need to be sure that the GC was performed before continuing - otherwise I might get inconsistent data again. According to the spec it's just a hint, but I think the implementation happens to be a force. But better safe than sorry. :) /Staffan > > -JB- > >> >> /Staffan >> >> On 23 okt 2013, at 10:02, Jaroslav Bachorik wrote: >> >>> On 22.10.2013 22:04, Mandy Chung wrote: >>>> Hi Jaroslav, >>>> >>>> On 10/22/13 6:47 AM, Jaroslav Bachorik wrote: >>>>> Please, review the following test fix: >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8020467 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8020467/webrev.01 >>>>> >>>> >>>> Have you considered to force GC when getUsed() == 0 regardless of which >>>> memory pool it is? This will avoid special casing for CMS old gen in >>>> the test and will handle similar issue in the future for a different >>>> collector implementation. To make the test reliable, the test should >>>> still pass if the memory pool has no object in it (G1 survivor space >>>> case?). >>> >>> Hi Mandy, >>> >>> I don't know whether GC will help for other pools - but I can enable it for all pools - it should not hurt. >>> >>> The test should pass even with on object in the monitored pool since the pool should not report an exceeded threshold. >>> >>> -JB- >>> >>>> >>>> Mandy >>>> >>>>> The test tries to make sure that the "pool usage threshold" trigger >>>>> and the reported pool memory usage are not contradicting each other. >>>>> The problem is that it is not possible to get the "pool usage >>>>> threshold exceeded" flag and the pool memory usage atomicly in regard >>>>> to the GC. Specifically, when "CMS Old Gen" pool is examined and the >>>>> usage is retrieved before a GC promotes some objects to the old gen >>>>> but the usage threshold is checked after the GC has promoted some >>>>> instance into the old gen the test will fail. >>>>> >>>>> The patch makes sure that there are some instances promoted in "CMS >>>>> Old Gen" before checking the "pool usage threshold" to get >>>>> semi-consistent view. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> >>> >> > From erik.gahlin at oracle.com Wed Oct 23 01:51:15 2013 From: erik.gahlin at oracle.com (erik.gahlin at oracle.com) Date: Wed, 23 Oct 2013 08:51:15 +0000 Subject: hg: jdk8/tl/jdk: 7105883: JDWP: agent crash if there exists a ThreadGroup with null name Message-ID: <20131023085207.791F162674@hg.openjdk.java.net> Changeset: c077a2810782 Author: egahlin Date: 2013-10-23 10:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c077a2810782 7105883: JDWP: agent crash if there exists a ThreadGroup with null name Reviewed-by: sla, jbachorik ! src/share/back/ThreadGroupReferenceImpl.c + test/com/sun/jdi/NullThreadGroupNameTest.java From dmitry.samersoff at oracle.com Wed Oct 23 02:38:04 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 23 Oct 2013 13:38:04 +0400 Subject: RR(XS): JDK-8026950 Nits in agent ps_proc.c file breaks compilation of open hotspot In-Reply-To: <52673660.8080905@oracle.com> References: <5264F8FC.7040307@oracle.com> <52673660.8080905@oracle.com> Message-ID: <526798FC.70809@oracle.com> David, SA doesn't support live process debugging on OSX, so this file is not compiled during libsaproc.dynlib build. But yes, if I enable compilation of this file during OSX build it fails as well, so this fix is required to go froward. May I consider you as a reviewer? -Dmitry On 2013-10-23 06:37, David Holmes wrote: > On 21/10/2013 7:50 PM, Dmitry Samersoff wrote: >> Hi Everybody, >> >> Please review a small fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8026950/webrev.01/ > > I don't understand why this is only a compile error on "open hotspot"? > PT_CONTINUE seems to be the necessary value for OSX and other BSD > systems. Do some systems have an alias in place? > > Reviewed. > > David > >> -Dmitry >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From michael.x.mcmahon at oracle.com Wed Oct 23 03:04:28 2013 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Wed, 23 Oct 2013 10:04:28 +0000 Subject: hg: jdk8/tl/jdk: 8025734: Use literal IP address where possible in SocketPermission generated by HttpURLPermission Message-ID: <20131023100553.8290C62675@hg.openjdk.java.net> Changeset: 1b0dfa631b6f Author: michaelm Date: 2013-10-23 11:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1b0dfa631b6f 8025734: Use literal IP address where possible in SocketPermission generated by HttpURLPermission Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/java/net/URLPermission/nstest/LookupTest.java + test/java/net/URLPermission/nstest/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/java/net/URLPermission/nstest/SimpleNameService.java + test/java/net/URLPermission/nstest/SimpleNameServiceDescriptor.java + test/java/net/URLPermission/nstest/policy From jan.lahoda at oracle.com Wed Oct 23 03:50:12 2013 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Wed, 23 Oct 2013 10:50:12 +0000 Subject: hg: jdk8/tl/langtools: 8026508: Invokedynamic instructions don't get line number table entries Message-ID: <20131023105049.42B6362678@hg.openjdk.java.net> Changeset: b05db8c815e8 Author: jlahoda Date: 2013-10-23 07:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b05db8c815e8 8026508: Invokedynamic instructions don't get line number table entries Summary: Setting or correcting positions for many trees produced by LambdaToMethod. Reviewed-by: vromero, rfield ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/T8019486/WrongLNTForLambdaTest.java - test/tools/javac/T8019486/WrongLVTForLambdaTest.java From staffan.larsen at oracle.com Wed Oct 23 03:55:57 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 23 Oct 2013 12:55:57 +0200 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <52663633.2080206@oracle.com> References: <525D4490.3070506@oracle.com> <526546FD.5020909@oracle.com> <52663633.2080206@oracle.com> Message-ID: <0805924E-F724-477D-B4C2-742ACB58075E@oracle.com> test/lib/testlibrary/jdk/testlibrary/Asserts.java Same code as already exists in the hotspot testlibrary. No further comments. test/lib/testlibrary/jdk/testlibrary/ProcessThread.java L33: stating -> starting L66: staring -> starting test/lib/testlibrary/jdk/testlibrary/TestThread.java This code comes from an internal test library. No further comments. test/lib/testlibrary/jdk/testlibrary/Utils.java No comments. test/lib/testlibrary/jdk/testlibrary/XRun.java This code comes from an internal test library. No further comments. test/sun/tools/jstatd/JstatGcutilParser.java The parse() method could be made more robust by discarding any lines that come before the header lines. This can happen if the JVM outputs a warning message for some reason before running jstat. I don't like the special-case for the CCS column in verify() - took me a while to find it. Should we add a new enum called PERCENTAGE_OR_DASH to handle that instead? L67: getType() should be private. test/sun/tools/jstatd/JstatdHelper.java: L54: Does verifyJpsOutput() work correctly with output of the form: 1234 -- main class information unavailable 1235 -- process information unavailable Also: same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. L46: "attach" is probably not the best way to describe the operation of jps. It does not attach to the process, it merely lists the running processes. Perhaps runJps() is a better name? test/sun/tools/jstatd/TestJstatdDefaults.java test/sun/tools/jstatd/TestJstatdExternalRegistry.java test/sun/tools/jstatd/TestJstatdPort.java test/sun/tools/jstatd/TestJstatdPortAndServer.java test/sun/tools/jstatd/TestJstatdServer.java No comments. test/sun/tools/jstatd/TestJstatdUsage.java Same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. test/sun/tools/jstatd/ToolConfig.java ToolConfig + Utils.get(Forward)VmOptions() seem to be doing similar things to JDKToolLauncher in the hotspot testlibrary. It is unfortunate if we have two ways to do similar things in the two different testlibraries. Would it be possible to reuse the hotspot code here instead? You have also changed the test. Previously the tools were not launched with the jtreg -vmoptions (test.vm.opts), whereas now they will be. Is this intentional? General comments: Can't we do: * @library /lib/testlibrary instead of * @library ../../../lib/testlibrary ? It seems that at least some of the functionality should be reused for re-writing the jstat and jps tests as well. I guess we can look at that at a later time, though. While I applaud the move from shell scripts to Java code, I can't shake the feeling that the shell scripts were easier to read and follow. The Java code is much more verbose and spread out over multiple helpers and libraries, making it harder to grasp. That may be the price we have to pay, though. Thanks, /Staffan On 22 okt 2013, at 10:24, Yekaterina Kantserova wrote: > Sorry, the wrong webrev link has slipped through. > > Here is the right one: > > http://cr.openjdk.java.net/~ykantser/8022229/webrev.01/ > > Thanks, > Katja > > > > On 10/21/2013 05:23 PM, Yekaterina Kantserova wrote: >> Hi, >> >> I've done following changes after the reviews: >> - added open copyrights >> - documented all public functions in jdk.testlibrary.TestThread, jdk.testlibrary.XRun, jdk.testlibrary.ProcessThread, jdk.testlibrary.Utils >> - merged jdk.testlibrary.Asserts from hotspot testlibrary >> >> Jaroslav's comments: >> - test/sun/tools/jstatd/JstatdHelper.java 82-84 - is deleted, different exception can show up there while waiting until jstatd is up and running; better just look for valid pid; >> - test/sun/tools/jstatd/JstatdHelper.java clean up processes - since jstatd process is daemon, the "clean up" is to kill the target process. Please look at the changed JstatdHelper and tell me if it's still unclear. >> - test/lib/testlibrary/jdk/testlibrary/Utils.java serverSocket.close() should be called in "finally" - fixed >> >> Webrev: >> http://cr.openjdk.java.net/~ykantser/8022229/webrev.01/ >> >> Primal bug: >> https://bugs.openjdk.java.net/browse/JDK-8022229 >> >> Similar bugs: >> https://bugs.openjdk.java.net/browse/JDK-8019630 >> https://bugs.openjdk.java.net/browse/JDK-6636094 >> https://bugs.openjdk.java.net/browse/JDK-6543979 >> >> Thanks, >> Katja > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131023/93522d7f/attachment-0001.html From jaroslav.bachorik at oracle.com Wed Oct 23 04:12:54 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 23 Oct 2013 13:12:54 +0200 Subject: Fwd: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <526546FD.5020909@oracle.com> References: <525D4490.3070506@oracle.com> <526546FD.5020909@oracle.com> Message-ID: <5267AF36.3030201@oracle.com> Hi Katja, On 21.10.2013 17:23, Yekaterina Kantserova wrote: > Hi, > > I've done following changes after the reviews: > - added open copyrights > - documented all public functions in jdk.testlibrary.TestThread, > jdk.testlibrary.XRun, jdk.testlibrary.ProcessThread, jdk.testlibrary.Utils > - merged jdk.testlibrary.Asserts from hotspot testlibrary > > Jaroslav's comments: > - test/sun/tools/jstatd/JstatdHelper.java 82-84 - is deleted, different > exception can show up there while waiting until jstatd is up and > running; better just look for valid pid; > - test/sun/tools/jstatd/JstatdHelper.java clean up processes - since > jstatd process is daemon, the "clean up" is to kill the target process. > Please look at the changed JstatdHelper and tell me if it's still unclear. > - test/lib/testlibrary/jdk/testlibrary/Utils.java serverSocket.close() > should be called in "finally" - fixed Thanks. I have no further comments. -JB- > > Webrev: > http://cr.openjdk.java.net/~ykantser/8022229/webrev.01/ > > Primal bug: > https://bugs.openjdk.java.net/browse/JDK-8022229 > > Similar bugs: > https://bugs.openjdk.java.net/browse/JDK-8019630 > https://bugs.openjdk.java.net/browse/JDK-6636094 > https://bugs.openjdk.java.net/browse/JDK-6543979 > > Thanks, > Katja > From staffan.larsen at oracle.com Wed Oct 23 04:09:16 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Wed, 23 Oct 2013 11:09:16 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8026808: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failed with unexpected exit value Message-ID: <20131023110938.0DF9E6267B@hg.openjdk.java.net> Changeset: b658cfe35857 Author: farvidsson Date: 2013-10-23 10:24 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b658cfe35857 8026808: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failed with unexpected exit value Summary: Fixes a bug with vmArgs when using JDKToolLauncher Reviewed-by: sla, dholmes ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java From staffan.larsen at oracle.com Wed Oct 23 04:16:27 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 23 Oct 2013 13:16:27 +0200 Subject: RR(XS): JDK-8026950 Nits in agent ps_proc.c file breaks compilation of open hotspot In-Reply-To: <526798FC.70809@oracle.com> References: <5264F8FC.7040307@oracle.com> <52673660.8080905@oracle.com> <526798FC.70809@oracle.com> Message-ID: <5D934D08-0684-4E8C-8DE0-644717AC2FEB@oracle.com> That is not entirely correct. Live process debugging is supported on OSX, but it happens in MacosxDebuggerLocal.m, not in ps_proc.c. /Staffan On 23 okt 2013, at 11:38, Dmitry Samersoff wrote: > David, > > SA doesn't support live process debugging on OSX, so this file is not > compiled during libsaproc.dynlib build. > > But yes, if I enable compilation of this file during OSX build it fails > as well, so this fix is required to go froward. > > May I consider you as a reviewer? > > -Dmitry > > > On 2013-10-23 06:37, David Holmes wrote: >> On 21/10/2013 7:50 PM, Dmitry Samersoff wrote: >>> Hi Everybody, >>> >>> Please review a small fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8026950/webrev.01/ >> >> I don't understand why this is only a compile error on "open hotspot"? >> PT_CONTINUE seems to be the necessary value for OSX and other BSD >> systems. Do some systems have an alias in place? >> >> Reviewed. >> >> David >> >>> -Dmitry >>> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Wed Oct 23 04:23:18 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 23 Oct 2013 15:23:18 +0400 Subject: RR(XS): JDK-8026950 Nits in agent ps_proc.c file breaks compilation of open hotspot In-Reply-To: <5D934D08-0684-4E8C-8DE0-644717AC2FEB@oracle.com> References: <5264F8FC.7040307@oracle.com> <52673660.8080905@oracle.com> <526798FC.70809@oracle.com> <5D934D08-0684-4E8C-8DE0-644717AC2FEB@oracle.com> Message-ID: <5267B1A6.4040701@oracle.com> Staffan, Sorry for being wrong and thank you for clarification! -Dmitry On 2013-10-23 15:16, Staffan Larsen wrote: > That is not entirely correct. Live process debugging is supported on OSX, but it happens in MacosxDebuggerLocal.m, not in ps_proc.c. > > /Staffan > > On 23 okt 2013, at 11:38, Dmitry Samersoff wrote: > >> David, >> >> SA doesn't support live process debugging on OSX, so this file is not >> compiled during libsaproc.dynlib build. >> >> But yes, if I enable compilation of this file during OSX build it fails >> as well, so this fix is required to go froward. >> >> May I consider you as a reviewer? >> >> -Dmitry >> >> >> On 2013-10-23 06:37, David Holmes wrote: >>> On 21/10/2013 7:50 PM, Dmitry Samersoff wrote: >>>> Hi Everybody, >>>> >>>> Please review a small fix. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8026950/webrev.01/ >>> >>> I don't understand why this is only a compile error on "open hotspot"? >>> PT_CONTINUE seems to be the necessary value for OSX and other BSD >>> systems. Do some systems have an alias in place? >>> >>> Reviewed. >>> >>> David >>> >>>> -Dmitry >>>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From bengt.rutisson at oracle.com Wed Oct 23 05:40:13 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 23 Oct 2013 14:40:13 +0200 Subject: jmx-dev RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: <68F92D47-E916-426B-8D6A-2EA48302053D@oracle.com> References: <526681FD.90604@oracle.com> <5266DA56.6050609@oracle.com> <52678280.1070004@oracle.com> <4972770C-A8BB-40A0-9BB8-885AA6B707BC@oracle.com> <52678509.2020002@oracle.com> <68F92D47-E916-426B-8D6A-2EA48302053D@oracle.com> Message-ID: <5267C3AD.5050306@oracle.com> Hi Jaroslav, A couple of questions. I don't understand why this is a CMS only problem? Why don't the other collectors have the same issue? I guess it is less likely that the other collectors start (or complete) a GC without a lot of allocation going on. But at least G1 should have the same problem. Also, from the problem description in the CR I would have guessed that you want the GC to happen between these two statements: p.setUsageThreshold(1); MemoryUsage u = p.getUsage(); Now you have added the GC just after these statements. I thought that was what caused the problem. That you read the usage data at one point, then a GC happens and you compare the cached usage data to the new data that p.isUsageThresholdExceeded() will fetch. Looking at the promoteToOldGen() method I assume that the intent is that the code should be using the return value. So my guess is that this code: 94 if (p.getName().equals("CMS Old Gen")) { 95 promoteToOldGen(p, u); 96 } Should be: 94 if (p.getName().equals("CMS Old Gen")) { 95 u = promoteToOldGen(p, u); 96 } With that, I think it might work. But I still don't understand why this is only a CMS problem. One more question about the promoteToOldGen() and forceGC() methods. I don't really know much about how the different beans work, but are we sure that the MemoryPoolMXBeans and GarbageCollectorMXBeans use the same pool names? That is, are you sure that forceGC() actually will do anything? As for just doing a System.gc() to force a GC I think you can rely on that System.gc() does a full GC in Hotspot unless someone sets -XX:+DisableExplicitGC on the command line. Considering that you are relying on Hotspot specifc names for pools I don't think it is a limitation to the test to rely on the Hotspot implementatoin of System.gc(). Thanks, Bengt On 2013-10-23 10:18, Staffan Larsen wrote: > On 23 okt 2013, at 10:12, Jaroslav Bachorik wrote: > >> On 23.10.2013 10:08, Staffan Larsen wrote: >>> I think you can simplify the logic for forcing a GC to just a simple call to "System.gc();". AFAIK System.gc() will cause a full collection to happen for all collectors. >> Hm, will it now? I had the impression that it was just hinting the GC system to perform GC but it might decide to ignore it. I need to be sure that the GC was performed before continuing - otherwise I might get inconsistent data again. > According to the spec it's just a hint, but I think the implementation happens to be a force. But better safe than sorry. :) > > /Staffan > >> -JB- >> >>> /Staffan >>> >>> On 23 okt 2013, at 10:02, Jaroslav Bachorik wrote: >>> >>>> On 22.10.2013 22:04, Mandy Chung wrote: >>>>> Hi Jaroslav, >>>>> >>>>> On 10/22/13 6:47 AM, Jaroslav Bachorik wrote: >>>>>> Please, review the following test fix: >>>>>> >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8020467 >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8020467/webrev.01 >>>>>> >>>>> Have you considered to force GC when getUsed() == 0 regardless of which >>>>> memory pool it is? This will avoid special casing for CMS old gen in >>>>> the test and will handle similar issue in the future for a different >>>>> collector implementation. To make the test reliable, the test should >>>>> still pass if the memory pool has no object in it (G1 survivor space >>>>> case?). >>>> Hi Mandy, >>>> >>>> I don't know whether GC will help for other pools - but I can enable it for all pools - it should not hurt. >>>> >>>> The test should pass even with on object in the monitored pool since the pool should not report an exceeded threshold. >>>> >>>> -JB- >>>> >>>>> Mandy >>>>> >>>>>> The test tries to make sure that the "pool usage threshold" trigger >>>>>> and the reported pool memory usage are not contradicting each other. >>>>>> The problem is that it is not possible to get the "pool usage >>>>>> threshold exceeded" flag and the pool memory usage atomicly in regard >>>>>> to the GC. Specifically, when "CMS Old Gen" pool is examined and the >>>>>> usage is retrieved before a GC promotes some objects to the old gen >>>>>> but the usage threshold is checked after the GC has promoted some >>>>>> instance into the old gen the test will fail. >>>>>> >>>>>> The patch makes sure that there are some instances promoted in "CMS >>>>>> Old Gen" before checking the "pool usage threshold" to get >>>>>> semi-consistent view. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- From jaroslav.bachorik at oracle.com Wed Oct 23 05:55:43 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 23 Oct 2013 14:55:43 +0200 Subject: jmx-dev RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: <5267C3AD.5050306@oracle.com> References: <526681FD.90604@oracle.com> <5266DA56.6050609@oracle.com> <52678280.1070004@oracle.com> <4972770C-A8BB-40A0-9BB8-885AA6B707BC@oracle.com> <52678509.2020002@oracle.com> <68F92D47-E916-426B-8D6A-2EA48302053D@oracle.com> <5267C3AD.5050306@oracle.com> Message-ID: <5267C74F.2010302@oracle.com> Hi Bengt, On 23.10.2013 14:40, Bengt Rutisson wrote: > > Hi Jaroslav, > > A couple of questions. > > I don't understand why this is a CMS only problem? Why don't the other > collectors have the same issue? I guess it is less likely that the other > collectors start (or complete) a GC without a lot of allocation going > on. But at least G1 should have the same problem. I don't really know. If there are other pools that can have the "used" value 0 before a GC happens then yes, they are susceptible to the same problem. > > Also, from the problem description in the CR I would have guessed that > you want the GC to happen between these two statements: > > p.setUsageThreshold(1); > MemoryUsage u = p.getUsage(); This is all but a heuristic here. The problem lies in the fact that it is not possible to retrieve the pool usage and the "threshold exceeded" flag consistently in one atomic operation. I might get usable data from the first call and then I don't need to force GC. > > Now you have added the GC just after these statements. I thought that > was what caused the problem. That you read the usage data at one point, > then a GC happens and you compare the cached usage > data to the new data that p.isUsageThresholdExceeded() will fetch. > > Looking at the promoteToOldGen() method I assume that the intent is that > the code should be using the return value. So my guess is that this code: > > 94 if (p.getName().equals("CMS Old Gen")) { > 95 promoteToOldGen(p, u); > 96 } > > Should be: > > 94 if (p.getName().equals("CMS Old Gen")) { > 95 u = promoteToOldGen(p, u); > 96 } Indeed. It was meant to re-fetch the usage after GC. > > With that, I think it might work. But I still don't understand why this > is only a CMS problem. > > One more question about the promoteToOldGen() and forceGC() methods. I > don't really know much about how the different beans work, but are we > sure that the MemoryPoolMXBeans and GarbageCollectorMXBeans use the same > pool names? That is, are you sure that forceGC() actually will do anything? They use the pool names as reported by the GC infrastracture so they should be the same. > > As for just doing a System.gc() to force a GC I think you can rely on > that System.gc() does a full GC in Hotspot unless someone sets > -XX:+DisableExplicitGC on the command line. Considering that you are > relying on Hotspot specifc names for pools I don't think it is a > limitation to the test to rely on the Hotspot implementatoin of > System.gc(). Good to know. I guess I could simplify the change and just call System.gc(), after all. Thanks, -JB- > > Thanks, > Bengt > > > > > On 2013-10-23 10:18, Staffan Larsen wrote: >> On 23 okt 2013, at 10:12, Jaroslav Bachorik >> wrote: >> >>> On 23.10.2013 10:08, Staffan Larsen wrote: >>>> I think you can simplify the logic for forcing a GC to just a simple >>>> call to "System.gc();". AFAIK System.gc() will cause a full >>>> collection to happen for all collectors. >>> Hm, will it now? I had the impression that it was just hinting the GC >>> system to perform GC but it might decide to ignore it. I need to be >>> sure that the GC was performed before continuing - otherwise I might >>> get inconsistent data again. >> According to the spec it's just a hint, but I think the implementation >> happens to be a force. But better safe than sorry. :) >> >> /Staffan >> >>> -JB- >>> >>>> /Staffan >>>> >>>> On 23 okt 2013, at 10:02, Jaroslav Bachorik >>>> wrote: >>>> >>>>> On 22.10.2013 22:04, Mandy Chung wrote: >>>>>> Hi Jaroslav, >>>>>> >>>>>> On 10/22/13 6:47 AM, Jaroslav Bachorik wrote: >>>>>>> Please, review the following test fix: >>>>>>> >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8020467 >>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8020467/webrev.01 >>>>>>> >>>>>> Have you considered to force GC when getUsed() == 0 regardless of >>>>>> which >>>>>> memory pool it is? This will avoid special casing for CMS old gen in >>>>>> the test and will handle similar issue in the future for a different >>>>>> collector implementation. To make the test reliable, the test should >>>>>> still pass if the memory pool has no object in it (G1 survivor space >>>>>> case?). >>>>> Hi Mandy, >>>>> >>>>> I don't know whether GC will help for other pools - but I can >>>>> enable it for all pools - it should not hurt. >>>>> >>>>> The test should pass even with on object in the monitored pool >>>>> since the pool should not report an exceeded threshold. >>>>> >>>>> -JB- >>>>> >>>>>> Mandy >>>>>> >>>>>>> The test tries to make sure that the "pool usage threshold" trigger >>>>>>> and the reported pool memory usage are not contradicting each other. >>>>>>> The problem is that it is not possible to get the "pool usage >>>>>>> threshold exceeded" flag and the pool memory usage atomicly in >>>>>>> regard >>>>>>> to the GC. Specifically, when "CMS Old Gen" pool is examined and the >>>>>>> usage is retrieved before a GC promotes some objects to the old gen >>>>>>> but the usage threshold is checked after the GC has promoted some >>>>>>> instance into the old gen the test will fail. >>>>>>> >>>>>>> The patch makes sure that there are some instances promoted in "CMS >>>>>>> Old Gen" before checking the "pool usage threshold" to get >>>>>>> semi-consistent view. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- > From alex.schenkman at oracle.com Wed Oct 23 05:51:38 2013 From: alex.schenkman at oracle.com (Alex Schenkman) Date: Wed, 23 Oct 2013 14:51:38 +0200 Subject: RFR 8014506: Test for Jdp (Java Discovery Protocol) feature In-Reply-To: <52244497.8010902@oracle.com> References: <51A31867.9080602@oracle.com> <51CAC09B.7070706@oracle.com> <7E2E50A8-1FB1-429B-8AAB-94863C215623@oracle.com> <51D56A11.5030600@oracle.com> <5214AC0A.4010603@oracle.com> <70F043F0-9F19-4761-B175-1D6652B5A146@oracle.com> <3B20B5DC-9E92-4EB6-97FF-0F2D2B4E1E10@oracle.com> <52244497.8010902@oracle.com> Message-ID: <5267C65A.9060602@oracle.com> Hi Staffan, Any chance you can review this again? http://cr.openjdk.java.net/~dsamersoff/sponsorship/aschenkman/8014506/ Thanks in advance! On 2013-09-02 09:56, Alex Schenkman wrote: > I've added a README file and moved Dmitry's tests into its own folder, > to address the comments below. > http://cr.openjdk.java.net/~dsamersoff/sponsorship/aschenkman/8014506/webrev.03/ > > > On 2013-08-21 20:10, Staffan Larsen wrote: >> A couple of more comments: >> >> - It was a little too hard to figure out exactly how the tests >> worked: who is sending JDP packets? who is listening for them? who is >> launching the tests? Perhaps it would make sense to add a small >> readme which explains how it all fits together? >> >> - There are already some JDP tests in that directory which are also >> made up of a couple of files. Mixing them together makes it hard to >> see which files belong to which set of tests. Maybe we should have >> distinct subfolders for the sets? >> >> - There is also the question of how much overlap there are between >> your tests and the already existing tests. It would be preferable to >> have no overlap. Perhaps some of the existing shell-based tests can >> be subsumed by your java-based tests? >> >> Thanks, >> /Staffan >> >> On 21 aug 2013, at 18:15, Staffan Larsen > > wrote: >> >>> Alex, >>> >>> This looks a lot better than the previous version. Thanks for >>> cleaning things up. Below are a couple of comments: >>> >>> - Use of "package" is discouraged for jtreg test: >>> http://openjdk.java.net/jtreg/faq.html#question4.9 >>> >>> - Maybe change name of SpecificLauncher.java to >>> SpecificJdpAddressLauncher.java? >>> >>> - The constructor and onSocketTimeOut() in JdpOffTest.java has wrong >>> indentation. >>> >>> - The comment for JdpOffTest.shouldContinue() has weird indentation. >>> >>> - How does one run PacketTest.java? It looks like a TestNG test, but >>> I couldn't get jtreg to run it. >>> >>> - Why the mix of standard jtreg tests and TestNG tests? >>> >>> - nit: somewhat non-standard formatting with spaces inside >>> parens: socket.receive( datagram ); >>> >>> - nit: statements should be on a new line: >>> if ( hasTestLivedLongEnough() ) { shutdown(); } >>> >>> >>> Thanks, >>> /Staffan >>> >>> On 21 aug 2013, at 14:01, Alex Schenkman >> > wrote: >>> >>>> Staffan, do you think you can take another look this? >>>> Thanks! >>>> >>>> On 2013-07-04 14:26, Alex Schenkman wrote: >>>>> Thanks Staffan for your comments. >>>>> >>>>> The indentation is corrected in all files, sorry about that. >>>>> >>>>> About the racing condition in PortFinder.java, you are absolutely >>>>> right, there is no warranty that this port will be free. >>>>> I do not know a better way to do this. Any suggestions? >>>>> On the other hand, even if this fails every now and then, it will >>>>> work most of the times and it is better than what we have today. >>>>> I have added better comments in PortFinder to reflect the problem. >>>>> >>>>> The new webrev is here [1], at the same address than before. >>>>> >>>>> Thanks! >>>>> >>>>> [1] http://cr.openjdk.java.net/~dsamersoff/8014506/webrev.01/ >>>>> >>>>> >>>>> PS: >>>>> PortFinder.java, line 37: >>>>> There is an extra

tag that should be removed. >>>>> >>>>> >>>>> >>>>> On 2013-06-26 13:54, Staffan Larsen wrote: >>>>>> test/lib/testlibrary/jdk/testlibrary/PortFinder.java: >>>>>> >>>>>> - This looks racy to me. There is no guarantee that the port will still be available after the call to close(). >>>>>> - Missing copyright notice. >>>>>> - In comment "on of them" -> "one of them" >>>>>> >>>>>> test/sun/management/jdp/ClientConnection.java: >>>>>> >>>>>> - broken indentation >>>>>> - inconsistent spacing in method calls. Sometime "joinGroup(address);" and sometimes "setSoTimeout( msTimeOut );". Should be without spaces. >>>>>> >>>>>> test/sun/management/jdp/DynamicLauncher.java: >>>>>> >>>>>> - type: binded -> bound >>>>>> - inconsistent spacing in method calls >>>>>> >>>>>> test/sun/management/jdp/JdpOffTest.java >>>>>> >>>>>> - broken indentation >>>>>> >>>>>> test/sun/management/jdp/JdpTestUtil.java >>>>>> >>>>>> - broken indentation >>>>>> >>>>>> >>>>>> I stopped reading here. Can we get these basic things fixed before the next review round, please? >>>>>> >>>>>> /Staffan >>>>>> >>>>>> >>>>>> On 26 jun 2013, at 12:21, Dmitry Samersoff wrote: >>>>>> >>>>>>> Nils, >>>>>>> >>>>>>> I'm sponsoring this push but don't see any review replies in this thread. >>>>>>> >>>>>>> Webrev refreshed against latest tl is here: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8014506/webrev.01/ >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> On 2013-05-27 12:25, Alex Schenkman wrote: >>>>>>>> Please review these tests for the Jdp protocol. >>>>>>>> >>>>>>>> There are three cases: >>>>>>>> 1) Jdp is off. >>>>>>>> 2) Jdp is on and using default address and port. >>>>>>>> 3) Jdp is on using custom address and port. >>>>>>>> >>>>>>>> Tests:http://cr.openjdk.java.net/~nloodin/8014506/webrev.00/ >>>>>>>> >>>>>>>> Jdp feature enhancement:https://jbs.oracle.com/bugs/browse/JDK-8002048 >>>>>>>> JDK CCC:http://ccc.us.oracle.com/8002048 >>>>>>>> >>>>>>>> >>>>>>>> Thanks in advance! >>>>>>>> >>>>>>>> -- >>>>>>>> Alex Schenkman >>>>>>>> Java VM SQE Stockholm >>>>>>>> >>>>>>> -- >>>>>>> Dmitry Samersoff >>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>> * I would love to change the world, but they won't give me the sources. >>>>> >>>>> -- >>>>> Alex Schenkman >>>>> Java VM SQE Stockholm >>>> >>>> -- >>>> Alex Schenkman >>>> Java VM SQE Stockholm >>> >> > > -- > Alex Schenkman > Java VM SQE Stockholm -- Alex Schenkman Java VM SQE Stockholm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131023/f1e4f591/attachment.html From jaroslav.bachorik at oracle.com Wed Oct 23 06:08:27 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Wed, 23 Oct 2013 13:08:27 +0000 Subject: hg: jdk8/tl/jdk: 7112404: 2 tests in java/lang/management/ManagementFactory fails with G1 because expect non-zero pools Message-ID: <20131023130859.9146862686@hg.openjdk.java.net> Changeset: f4970c7abe93 Author: jbachorik Date: 2013-10-23 15:03 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4970c7abe93 7112404: 2 tests in java/lang/management/ManagementFactory fails with G1 because expect non-zero pools Reviewed-by: mchung, sjiang ! test/java/lang/management/ManagementFactory/ProxyTypeMapping.java ! test/java/lang/management/ManagementFactory/ValidateOpenTypes.java From bengt.rutisson at oracle.com Wed Oct 23 06:15:44 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 23 Oct 2013 15:15:44 +0200 Subject: jmx-dev RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: <5267C74F.2010302@oracle.com> References: <526681FD.90604@oracle.com> <5266DA56.6050609@oracle.com> <52678280.1070004@oracle.com> <4972770C-A8BB-40A0-9BB8-885AA6B707BC@oracle.com> <52678509.2020002@oracle.com> <68F92D47-E916-426B-8D6A-2EA48302053D@oracle.com> <5267C3AD.5050306@oracle.com> <5267C74F.2010302@oracle.com> Message-ID: <5267CC00.7080509@oracle.com> On 2013-10-23 14:55, Jaroslav Bachorik wrote: > Hi Bengt, > > On 23.10.2013 14:40, Bengt Rutisson wrote: >> >> Hi Jaroslav, >> >> A couple of questions. >> >> I don't understand why this is a CMS only problem? Why don't the other >> collectors have the same issue? I guess it is less likely that the other >> collectors start (or complete) a GC without a lot of allocation going >> on. But at least G1 should have the same problem. > > I don't really know. If there are other pools that can have the "used" > value 0 before a GC happens then yes, they are susceptible to the same > problem. I think all the "old" pools can have 0 used before a GC happens. But except for CMS and G1 it is less likely that a GC happens unless you do allocations. As long as they keep the 0 used the test will pass. So, my guess is that to be on the safe side all "old" pools should make sure to do a full GC first. > >> >> Also, from the problem description in the CR I would have guessed that >> you want the GC to happen between these two statements: >> >> p.setUsageThreshold(1); >> MemoryUsage u = p.getUsage(); > > This is all but a heuristic here. The problem lies in the fact that it > is not possible to retrieve the pool usage and the "threshold > exceeded" flag consistently in one atomic operation. I might get > usable data from the first call and then I don't need to force GC. Right. This is why I think you want to avoid a GC after you have fetched getUsage() but before you do isUsageThresholdExceeded(). With your suggested patch you are explicitly inserting a GC at that point. To me this sounds like the opposite of what you want to do. > >> >> Now you have added the GC just after these statements. I thought that >> was what caused the problem. That you read the usage data at one point, >> then a GC happens and you compare the cached usage >> data to the new data that p.isUsageThresholdExceeded() will fetch. >> >> Looking at the promoteToOldGen() method I assume that the intent is that >> the code should be using the return value. So my guess is that this >> code: >> >> 94 if (p.getName().equals("CMS Old Gen")) { >> 95 promoteToOldGen(p, u); >> 96 } >> >> Should be: >> >> 94 if (p.getName().equals("CMS Old Gen")) { >> 95 u = promoteToOldGen(p, u); >> 96 } > > Indeed. It was meant to re-fetch the usage after GC. OK. Good. With this code I think it should work. Now you make sure to get the GC before you do getUsage(). > >> >> With that, I think it might work. But I still don't understand why this >> is only a CMS problem. >> >> One more question about the promoteToOldGen() and forceGC() methods. I >> don't really know much about how the different beans work, but are we >> sure that the MemoryPoolMXBeans and GarbageCollectorMXBeans use the same >> pool names? That is, are you sure that forceGC() actually will do >> anything? > > They use the pool names as reported by the GC infrastracture so they > should be the same. Ok. > >> >> As for just doing a System.gc() to force a GC I think you can rely on >> that System.gc() does a full GC in Hotspot unless someone sets >> -XX:+DisableExplicitGC on the command line. Considering that you are >> relying on Hotspot specifc names for pools I don't think it is a >> limitation to the test to rely on the Hotspot implementatoin of >> System.gc(). > > Good to know. I guess I could simplify the change and just call > System.gc(), after all. Yes, I think that' simpler. Thanks, Bengt > > Thanks, > > -JB- > >> >> Thanks, >> Bengt >> >> >> >> >> On 2013-10-23 10:18, Staffan Larsen wrote: >>> On 23 okt 2013, at 10:12, Jaroslav Bachorik >>> wrote: >>> >>>> On 23.10.2013 10:08, Staffan Larsen wrote: >>>>> I think you can simplify the logic for forcing a GC to just a simple >>>>> call to "System.gc();". AFAIK System.gc() will cause a full >>>>> collection to happen for all collectors. >>>> Hm, will it now? I had the impression that it was just hinting the GC >>>> system to perform GC but it might decide to ignore it. I need to be >>>> sure that the GC was performed before continuing - otherwise I might >>>> get inconsistent data again. >>> According to the spec it's just a hint, but I think the implementation >>> happens to be a force. But better safe than sorry. :) >>> >>> /Staffan >>> >>>> -JB- >>>> >>>>> /Staffan >>>>> >>>>> On 23 okt 2013, at 10:02, Jaroslav Bachorik >>>>> wrote: >>>>> >>>>>> On 22.10.2013 22:04, Mandy Chung wrote: >>>>>>> Hi Jaroslav, >>>>>>> >>>>>>> On 10/22/13 6:47 AM, Jaroslav Bachorik wrote: >>>>>>>> Please, review the following test fix: >>>>>>>> >>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8020467 >>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8020467/webrev.01 >>>>>>>> >>>>>>> Have you considered to force GC when getUsed() == 0 regardless of >>>>>>> which >>>>>>> memory pool it is? This will avoid special casing for CMS old >>>>>>> gen in >>>>>>> the test and will handle similar issue in the future for a >>>>>>> different >>>>>>> collector implementation. To make the test reliable, the test >>>>>>> should >>>>>>> still pass if the memory pool has no object in it (G1 survivor >>>>>>> space >>>>>>> case?). >>>>>> Hi Mandy, >>>>>> >>>>>> I don't know whether GC will help for other pools - but I can >>>>>> enable it for all pools - it should not hurt. >>>>>> >>>>>> The test should pass even with on object in the monitored pool >>>>>> since the pool should not report an exceeded threshold. >>>>>> >>>>>> -JB- >>>>>> >>>>>>> Mandy >>>>>>> >>>>>>>> The test tries to make sure that the "pool usage threshold" >>>>>>>> trigger >>>>>>>> and the reported pool memory usage are not contradicting each >>>>>>>> other. >>>>>>>> The problem is that it is not possible to get the "pool usage >>>>>>>> threshold exceeded" flag and the pool memory usage atomicly in >>>>>>>> regard >>>>>>>> to the GC. Specifically, when "CMS Old Gen" pool is examined >>>>>>>> and the >>>>>>>> usage is retrieved before a GC promotes some objects to the old >>>>>>>> gen >>>>>>>> but the usage threshold is checked after the GC has promoted some >>>>>>>> instance into the old gen the test will fail. >>>>>>>> >>>>>>>> The patch makes sure that there are some instances promoted in >>>>>>>> "CMS >>>>>>>> Old Gen" before checking the "pool usage threshold" to get >>>>>>>> semi-consistent view. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -JB- >> > From staffan.larsen at oracle.com Wed Oct 23 07:05:43 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Wed, 23 Oct 2013 14:05:43 +0000 Subject: hg: jdk8/tl/jdk: 8026789: Update test/java/lang/instrument/Re(transform|define)BigClass.sh test to use NMT for memory leak detection Message-ID: <20131023140613.0642362689@hg.openjdk.java.net> Changeset: 8c20e9ef8709 Author: sla Date: 2013-10-23 15:55 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8c20e9ef8709 8026789: Update test/java/lang/instrument/Re(transform|define)BigClass.sh test to use NMT for memory leak detection Reviewed-by: dcubed ! test/ProblemList.txt + test/java/lang/instrument/NMTHelper.java ! test/java/lang/instrument/RedefineBigClass.sh ! test/java/lang/instrument/RedefineBigClassApp.java ! test/java/lang/instrument/RetransformBigClass.sh ! test/java/lang/instrument/RetransformBigClassApp.java From chris.hegarty at oracle.com Wed Oct 23 06:39:16 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 23 Oct 2013 13:39:16 +0000 Subject: hg: jdk8/tl/jdk: 8020758: HttpCookie constructor does not throw IAE when name contains a space Message-ID: <20131023133946.0C7DA62687@hg.openjdk.java.net> Changeset: f120672b91ef Author: chegar Date: 2013-10-23 14:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f120672b91ef 8020758: HttpCookie constructor does not throw IAE when name contains a space Reviewed-by: michaelm, msheppar ! src/share/classes/java/net/HttpCookie.java ! test/java/net/CookieHandler/TestHttpCookie.java From jaroslav.bachorik at oracle.com Wed Oct 23 07:32:28 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 23 Oct 2013 16:32:28 +0200 Subject: jmx-dev RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: <5267CC00.7080509@oracle.com> References: <526681FD.90604@oracle.com> <5266DA56.6050609@oracle.com> <52678280.1070004@oracle.com> <4972770C-A8BB-40A0-9BB8-885AA6B707BC@oracle.com> <52678509.2020002@oracle.com> <68F92D47-E916-426B-8D6A-2EA48302053D@oracle.com> <5267C3AD.5050306@oracle.com> <5267C74F.2010302@oracle.com> <5267CC00.7080509@oracle.com> Message-ID: <5267DDFC.4060607@oracle.com> On 23.10.2013 15:15, Bengt Rutisson wrote: > > On 2013-10-23 14:55, Jaroslav Bachorik wrote: >> Hi Bengt, >> >> On 23.10.2013 14:40, Bengt Rutisson wrote: >>> >>> Hi Jaroslav, >>> >>> A couple of questions. >>> >>> I don't understand why this is a CMS only problem? Why don't the other >>> collectors have the same issue? I guess it is less likely that the other >>> collectors start (or complete) a GC without a lot of allocation going >>> on. But at least G1 should have the same problem. >> >> I don't really know. If there are other pools that can have the "used" >> value 0 before a GC happens then yes, they are susceptible to the same >> problem. > > I think all the "old" pools can have 0 used before a GC happens. But > except for CMS and G1 it is less likely that a GC happens unless you do > allocations. As long as they keep the 0 used the test will pass. So, my > guess is that to be on the safe side all "old" pools should make sure to > do a full GC first. > >> >>> >>> Also, from the problem description in the CR I would have guessed that >>> you want the GC to happen between these two statements: >>> >>> p.setUsageThreshold(1); >>> MemoryUsage u = p.getUsage(); >> >> This is all but a heuristic here. The problem lies in the fact that it >> is not possible to retrieve the pool usage and the "threshold >> exceeded" flag consistently in one atomic operation. I might get >> usable data from the first call and then I don't need to force GC. > > Right. This is why I think you want to avoid a GC after you have fetched > getUsage() but before you do isUsageThresholdExceeded(). With your > suggested patch you are explicitly inserting a GC at that point. To me > this sounds like the opposite of what you want to do. I've updated the patch. The GC is called even before the first attempt to get the pool memory usage and System.gc() is used to perform GC (no MXBean checks). This should simplify the change a bit. http://cr.openjdk.java.net/~jbachorik/8020467/webrev.02 -JB- > >> >>> >>> Now you have added the GC just after these statements. I thought that >>> was what caused the problem. That you read the usage data at one point, >>> then a GC happens and you compare the cached usage >>> data to the new data that p.isUsageThresholdExceeded() will fetch. >>> >>> Looking at the promoteToOldGen() method I assume that the intent is that >>> the code should be using the return value. So my guess is that this >>> code: >>> >>> 94 if (p.getName().equals("CMS Old Gen")) { >>> 95 promoteToOldGen(p, u); >>> 96 } >>> >>> Should be: >>> >>> 94 if (p.getName().equals("CMS Old Gen")) { >>> 95 u = promoteToOldGen(p, u); >>> 96 } >> >> Indeed. It was meant to re-fetch the usage after GC. > > OK. Good. With this code I think it should work. Now you make sure to > get the GC before you do getUsage(). > >> >>> >>> With that, I think it might work. But I still don't understand why this >>> is only a CMS problem. >>> >>> One more question about the promoteToOldGen() and forceGC() methods. I >>> don't really know much about how the different beans work, but are we >>> sure that the MemoryPoolMXBeans and GarbageCollectorMXBeans use the same >>> pool names? That is, are you sure that forceGC() actually will do >>> anything? >> >> They use the pool names as reported by the GC infrastracture so they >> should be the same. > > Ok. > >> >>> >>> As for just doing a System.gc() to force a GC I think you can rely on >>> that System.gc() does a full GC in Hotspot unless someone sets >>> -XX:+DisableExplicitGC on the command line. Considering that you are >>> relying on Hotspot specifc names for pools I don't think it is a >>> limitation to the test to rely on the Hotspot implementatoin of >>> System.gc(). >> >> Good to know. I guess I could simplify the change and just call >> System.gc(), after all. > > Yes, I think that' simpler. > > Thanks, > Bengt > >> >> Thanks, >> >> -JB- >> >>> >>> Thanks, >>> Bengt >>> >>> >>> >>> >>> On 2013-10-23 10:18, Staffan Larsen wrote: >>>> On 23 okt 2013, at 10:12, Jaroslav Bachorik >>>> wrote: >>>> >>>>> On 23.10.2013 10:08, Staffan Larsen wrote: >>>>>> I think you can simplify the logic for forcing a GC to just a simple >>>>>> call to "System.gc();". AFAIK System.gc() will cause a full >>>>>> collection to happen for all collectors. >>>>> Hm, will it now? I had the impression that it was just hinting the GC >>>>> system to perform GC but it might decide to ignore it. I need to be >>>>> sure that the GC was performed before continuing - otherwise I might >>>>> get inconsistent data again. >>>> According to the spec it's just a hint, but I think the implementation >>>> happens to be a force. But better safe than sorry. :) >>>> >>>> /Staffan >>>> >>>>> -JB- >>>>> >>>>>> /Staffan >>>>>> >>>>>> On 23 okt 2013, at 10:02, Jaroslav Bachorik >>>>>> wrote: >>>>>> >>>>>>> On 22.10.2013 22:04, Mandy Chung wrote: >>>>>>>> Hi Jaroslav, >>>>>>>> >>>>>>>> On 10/22/13 6:47 AM, Jaroslav Bachorik wrote: >>>>>>>>> Please, review the following test fix: >>>>>>>>> >>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8020467 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8020467/webrev.01 >>>>>>>>> >>>>>>>> Have you considered to force GC when getUsed() == 0 regardless of >>>>>>>> which >>>>>>>> memory pool it is? This will avoid special casing for CMS old >>>>>>>> gen in >>>>>>>> the test and will handle similar issue in the future for a >>>>>>>> different >>>>>>>> collector implementation. To make the test reliable, the test >>>>>>>> should >>>>>>>> still pass if the memory pool has no object in it (G1 survivor >>>>>>>> space >>>>>>>> case?). >>>>>>> Hi Mandy, >>>>>>> >>>>>>> I don't know whether GC will help for other pools - but I can >>>>>>> enable it for all pools - it should not hurt. >>>>>>> >>>>>>> The test should pass even with on object in the monitored pool >>>>>>> since the pool should not report an exceeded threshold. >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> Mandy >>>>>>>> >>>>>>>>> The test tries to make sure that the "pool usage threshold" >>>>>>>>> trigger >>>>>>>>> and the reported pool memory usage are not contradicting each >>>>>>>>> other. >>>>>>>>> The problem is that it is not possible to get the "pool usage >>>>>>>>> threshold exceeded" flag and the pool memory usage atomicly in >>>>>>>>> regard >>>>>>>>> to the GC. Specifically, when "CMS Old Gen" pool is examined >>>>>>>>> and the >>>>>>>>> usage is retrieved before a GC promotes some objects to the old >>>>>>>>> gen >>>>>>>>> but the usage threshold is checked after the GC has promoted some >>>>>>>>> instance into the old gen the test will fail. >>>>>>>>> >>>>>>>>> The patch makes sure that there are some instances promoted in >>>>>>>>> "CMS >>>>>>>>> Old Gen" before checking the "pool usage threshold" to get >>>>>>>>> semi-consistent view. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -JB- >>> >> > From bengt.rutisson at oracle.com Wed Oct 23 07:43:30 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 23 Oct 2013 16:43:30 +0200 Subject: jmx-dev RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: <5267DDFC.4060607@oracle.com> References: <526681FD.90604@oracle.com> <5266DA56.6050609@oracle.com> <52678280.1070004@oracle.com> <4972770C-A8BB-40A0-9BB8-885AA6B707BC@oracle.com> <52678509.2020002@oracle.com> <68F92D47-E916-426B-8D6A-2EA48302053D@oracle.com> <5267C3AD.5050306@oracle.com> <5267C74F.2010302@oracle.com> <5267CC00.7080509@oracle.com> <5267DDFC.4060607@oracle.com> Message-ID: <5267E092.6090006@oracle.com> Hi Jaroslav, On 2013-10-23 16:32, Jaroslav Bachorik wrote: > On 23.10.2013 15:15, Bengt Rutisson wrote: >> >> On 2013-10-23 14:55, Jaroslav Bachorik wrote: >>> Hi Bengt, >>> >>> On 23.10.2013 14:40, Bengt Rutisson wrote: >>>> >>>> Hi Jaroslav, >>>> >>>> A couple of questions. >>>> >>>> I don't understand why this is a CMS only problem? Why don't the other >>>> collectors have the same issue? I guess it is less likely that the >>>> other >>>> collectors start (or complete) a GC without a lot of allocation going >>>> on. But at least G1 should have the same problem. >>> >>> I don't really know. If there are other pools that can have the "used" >>> value 0 before a GC happens then yes, they are susceptible to the same >>> problem. >> >> I think all the "old" pools can have 0 used before a GC happens. But >> except for CMS and G1 it is less likely that a GC happens unless you do >> allocations. As long as they keep the 0 used the test will pass. So, my >> guess is that to be on the safe side all "old" pools should make sure to >> do a full GC first. >> >>> >>>> >>>> Also, from the problem description in the CR I would have guessed that >>>> you want the GC to happen between these two statements: >>>> >>>> p.setUsageThreshold(1); >>>> MemoryUsage u = p.getUsage(); >>> >>> This is all but a heuristic here. The problem lies in the fact that it >>> is not possible to retrieve the pool usage and the "threshold >>> exceeded" flag consistently in one atomic operation. I might get >>> usable data from the first call and then I don't need to force GC. >> >> Right. This is why I think you want to avoid a GC after you have fetched >> getUsage() but before you do isUsageThresholdExceeded(). With your >> suggested patch you are explicitly inserting a GC at that point. To me >> this sounds like the opposite of what you want to do. > > I've updated the patch. The GC is called even before the first attempt > to get the pool memory usage and System.gc() is used to perform GC (no > MXBean checks). This should simplify the change a bit. > > http://cr.openjdk.java.net/~jbachorik/8020467/webrev.02 Thanks for doing this update so quickly! Have you been able to verify that this change still fixes the issue? I think it should, but it would be good if we could verify it. This code worries me a little bit: 114 private static MemoryUsage getUsage(MemoryPoolMXBean p) { 115 MemoryUsage u = null; 116 do { 117 System.gc(); 118 u = p.getUsage(); 119 } while (u.getUsed() == 0); 120 return u; 121 } I think one call to System.gc() should be enough. And if it is not, if we still get 0 as used, I think that another System.gc() call will just render the same result. Thus, I'm a bit worried that this will be an endless loop. Since the test actually handles the case where used is 0, I think it is enough to just do a single call to System.gc() and then get the usage data. Thanks, Bengt > > -JB- > >> >>> >>>> >>>> Now you have added the GC just after these statements. I thought that >>>> was what caused the problem. That you read the usage data at one >>>> point, >>>> then a GC happens and you compare the cached usage >>>> data to the new data that p.isUsageThresholdExceeded() will fetch. >>>> >>>> Looking at the promoteToOldGen() method I assume that the intent is >>>> that >>>> the code should be using the return value. So my guess is that this >>>> code: >>>> >>>> 94 if (p.getName().equals("CMS Old Gen")) { >>>> 95 promoteToOldGen(p, u); >>>> 96 } >>>> >>>> Should be: >>>> >>>> 94 if (p.getName().equals("CMS Old Gen")) { >>>> 95 u = promoteToOldGen(p, u); >>>> 96 } >>> >>> Indeed. It was meant to re-fetch the usage after GC. >> >> OK. Good. With this code I think it should work. Now you make sure to >> get the GC before you do getUsage(). >> >>> >>>> >>>> With that, I think it might work. But I still don't understand why >>>> this >>>> is only a CMS problem. >>>> >>>> One more question about the promoteToOldGen() and forceGC() methods. I >>>> don't really know much about how the different beans work, but are we >>>> sure that the MemoryPoolMXBeans and GarbageCollectorMXBeans use the >>>> same >>>> pool names? That is, are you sure that forceGC() actually will do >>>> anything? >>> >>> They use the pool names as reported by the GC infrastracture so they >>> should be the same. >> >> Ok. >> >>> >>>> >>>> As for just doing a System.gc() to force a GC I think you can rely on >>>> that System.gc() does a full GC in Hotspot unless someone sets >>>> -XX:+DisableExplicitGC on the command line. Considering that you are >>>> relying on Hotspot specifc names for pools I don't think it is a >>>> limitation to the test to rely on the Hotspot implementatoin of >>>> System.gc(). >>> >>> Good to know. I guess I could simplify the change and just call >>> System.gc(), after all. >> >> Yes, I think that' simpler. >> >> Thanks, >> Bengt >> >>> >>> Thanks, >>> >>> -JB- >>> >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>> >>>> >>>> On 2013-10-23 10:18, Staffan Larsen wrote: >>>>> On 23 okt 2013, at 10:12, Jaroslav Bachorik >>>>> wrote: >>>>> >>>>>> On 23.10.2013 10:08, Staffan Larsen wrote: >>>>>>> I think you can simplify the logic for forcing a GC to just a >>>>>>> simple >>>>>>> call to "System.gc();". AFAIK System.gc() will cause a full >>>>>>> collection to happen for all collectors. >>>>>> Hm, will it now? I had the impression that it was just hinting >>>>>> the GC >>>>>> system to perform GC but it might decide to ignore it. I need to be >>>>>> sure that the GC was performed before continuing - otherwise I might >>>>>> get inconsistent data again. >>>>> According to the spec it's just a hint, but I think the >>>>> implementation >>>>> happens to be a force. But better safe than sorry. :) >>>>> >>>>> /Staffan >>>>> >>>>>> -JB- >>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> On 23 okt 2013, at 10:02, Jaroslav Bachorik >>>>>>> wrote: >>>>>>> >>>>>>>> On 22.10.2013 22:04, Mandy Chung wrote: >>>>>>>>> Hi Jaroslav, >>>>>>>>> >>>>>>>>> On 10/22/13 6:47 AM, Jaroslav Bachorik wrote: >>>>>>>>>> Please, review the following test fix: >>>>>>>>>> >>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8020467 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8020467/webrev.01 >>>>>>>>>> >>>>>>>>> Have you considered to force GC when getUsed() == 0 regardless of >>>>>>>>> which >>>>>>>>> memory pool it is? This will avoid special casing for CMS old >>>>>>>>> gen in >>>>>>>>> the test and will handle similar issue in the future for a >>>>>>>>> different >>>>>>>>> collector implementation. To make the test reliable, the test >>>>>>>>> should >>>>>>>>> still pass if the memory pool has no object in it (G1 survivor >>>>>>>>> space >>>>>>>>> case?). >>>>>>>> Hi Mandy, >>>>>>>> >>>>>>>> I don't know whether GC will help for other pools - but I can >>>>>>>> enable it for all pools - it should not hurt. >>>>>>>> >>>>>>>> The test should pass even with on object in the monitored pool >>>>>>>> since the pool should not report an exceeded threshold. >>>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>>> Mandy >>>>>>>>> >>>>>>>>>> The test tries to make sure that the "pool usage threshold" >>>>>>>>>> trigger >>>>>>>>>> and the reported pool memory usage are not contradicting each >>>>>>>>>> other. >>>>>>>>>> The problem is that it is not possible to get the "pool usage >>>>>>>>>> threshold exceeded" flag and the pool memory usage atomicly in >>>>>>>>>> regard >>>>>>>>>> to the GC. Specifically, when "CMS Old Gen" pool is examined >>>>>>>>>> and the >>>>>>>>>> usage is retrieved before a GC promotes some objects to the old >>>>>>>>>> gen >>>>>>>>>> but the usage threshold is checked after the GC has promoted >>>>>>>>>> some >>>>>>>>>> instance into the old gen the test will fail. >>>>>>>>>> >>>>>>>>>> The patch makes sure that there are some instances promoted in >>>>>>>>>> "CMS >>>>>>>>>> Old Gen" before checking the "pool usage threshold" to get >>>>>>>>>> semi-consistent view. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -JB- >>>> >>> >> > From jaroslav.bachorik at oracle.com Wed Oct 23 08:07:13 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 23 Oct 2013 17:07:13 +0200 Subject: jmx-dev RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: <5267E092.6090006@oracle.com> References: <526681FD.90604@oracle.com> <5266DA56.6050609@oracle.com> <52678280.1070004@oracle.com> <4972770C-A8BB-40A0-9BB8-885AA6B707BC@oracle.com> <52678509.2020002@oracle.com> <68F92D47-E916-426B-8D6A-2EA48302053D@oracle.com> <5267C3AD.5050306@oracle.com> <5267C74F.2010302@oracle.com> <5267CC00.7080509@oracle.com> <5267DDFC.4060607@oracle.com> <5267E092.6090006@oracle.com> Message-ID: <5267E621.2040601@oracle.com> On 23.10.2013 16:43, Bengt Rutisson wrote: > > Hi Jaroslav, > > On 2013-10-23 16:32, Jaroslav Bachorik wrote: >> On 23.10.2013 15:15, Bengt Rutisson wrote: >>> >>> On 2013-10-23 14:55, Jaroslav Bachorik wrote: >>>> Hi Bengt, >>>> >>>> On 23.10.2013 14:40, Bengt Rutisson wrote: >>>>> >>>>> Hi Jaroslav, >>>>> >>>>> A couple of questions. >>>>> >>>>> I don't understand why this is a CMS only problem? Why don't the other >>>>> collectors have the same issue? I guess it is less likely that the >>>>> other >>>>> collectors start (or complete) a GC without a lot of allocation going >>>>> on. But at least G1 should have the same problem. >>>> >>>> I don't really know. If there are other pools that can have the "used" >>>> value 0 before a GC happens then yes, they are susceptible to the same >>>> problem. >>> >>> I think all the "old" pools can have 0 used before a GC happens. But >>> except for CMS and G1 it is less likely that a GC happens unless you do >>> allocations. As long as they keep the 0 used the test will pass. So, my >>> guess is that to be on the safe side all "old" pools should make sure to >>> do a full GC first. >>> >>>> >>>>> >>>>> Also, from the problem description in the CR I would have guessed that >>>>> you want the GC to happen between these two statements: >>>>> >>>>> p.setUsageThreshold(1); >>>>> MemoryUsage u = p.getUsage(); >>>> >>>> This is all but a heuristic here. The problem lies in the fact that it >>>> is not possible to retrieve the pool usage and the "threshold >>>> exceeded" flag consistently in one atomic operation. I might get >>>> usable data from the first call and then I don't need to force GC. >>> >>> Right. This is why I think you want to avoid a GC after you have fetched >>> getUsage() but before you do isUsageThresholdExceeded(). With your >>> suggested patch you are explicitly inserting a GC at that point. To me >>> this sounds like the opposite of what you want to do. >> >> I've updated the patch. The GC is called even before the first attempt >> to get the pool memory usage and System.gc() is used to perform GC (no >> MXBean checks). This should simplify the change a bit. >> >> http://cr.openjdk.java.net/~jbachorik/8020467/webrev.02 > > Thanks for doing this update so quickly! > > Have you been able to verify that this change still fixes the issue? I > think it should, but it would be good if we could verify it. Yep, it still fixes the problem. Unfortunatelly, the only way to reproduce the problem locally is to run the test under debugger and invoke GC explicitly between getting the pool memory usage and threshold flag. > > This code worries me a little bit: > > 114 private static MemoryUsage getUsage(MemoryPoolMXBean p) { > 115 MemoryUsage u = null; > 116 do { > 117 System.gc(); > 118 u = p.getUsage(); > 119 } while (u.getUsed() == 0); > 120 return u; > 121 } > > I think one call to System.gc() should be enough. And if it is not, if > we still get 0 as used, I think that another System.gc() call will just > render the same result. Thus, I'm a bit worried that this will be an > endless loop. Sounds reasonable. My motivation was to try to make sure some objects are promoted to old gen but it seems redundant and in case of non-oldgen pools might not even work :( > > Since the test actually handles the case where used is 0, I think it is > enough to just do a single call to System.gc() and then get the usage data. Hm, this makes the patch even simpler ... http://cr.openjdk.java.net/~jbachorik/8020467/webrev.03 -JB- > > Thanks, > Bengt > > >> >> -JB- >> >>> >>>> >>>>> >>>>> Now you have added the GC just after these statements. I thought that >>>>> was what caused the problem. That you read the usage data at one >>>>> point, >>>>> then a GC happens and you compare the cached usage >>>>> data to the new data that p.isUsageThresholdExceeded() will fetch. >>>>> >>>>> Looking at the promoteToOldGen() method I assume that the intent is >>>>> that >>>>> the code should be using the return value. So my guess is that this >>>>> code: >>>>> >>>>> 94 if (p.getName().equals("CMS Old Gen")) { >>>>> 95 promoteToOldGen(p, u); >>>>> 96 } >>>>> >>>>> Should be: >>>>> >>>>> 94 if (p.getName().equals("CMS Old Gen")) { >>>>> 95 u = promoteToOldGen(p, u); >>>>> 96 } >>>> >>>> Indeed. It was meant to re-fetch the usage after GC. >>> >>> OK. Good. With this code I think it should work. Now you make sure to >>> get the GC before you do getUsage(). >>> >>>> >>>>> >>>>> With that, I think it might work. But I still don't understand why >>>>> this >>>>> is only a CMS problem. >>>>> >>>>> One more question about the promoteToOldGen() and forceGC() methods. I >>>>> don't really know much about how the different beans work, but are we >>>>> sure that the MemoryPoolMXBeans and GarbageCollectorMXBeans use the >>>>> same >>>>> pool names? That is, are you sure that forceGC() actually will do >>>>> anything? >>>> >>>> They use the pool names as reported by the GC infrastracture so they >>>> should be the same. >>> >>> Ok. >>> >>>> >>>>> >>>>> As for just doing a System.gc() to force a GC I think you can rely on >>>>> that System.gc() does a full GC in Hotspot unless someone sets >>>>> -XX:+DisableExplicitGC on the command line. Considering that you are >>>>> relying on Hotspot specifc names for pools I don't think it is a >>>>> limitation to the test to rely on the Hotspot implementatoin of >>>>> System.gc(). >>>> >>>> Good to know. I guess I could simplify the change and just call >>>> System.gc(), after all. >>> >>> Yes, I think that' simpler. >>> >>> Thanks, >>> Bengt >>> >>>> >>>> Thanks, >>>> >>>> -JB- >>>> >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>> >>>>> >>>>> >>>>> On 2013-10-23 10:18, Staffan Larsen wrote: >>>>>> On 23 okt 2013, at 10:12, Jaroslav Bachorik >>>>>> wrote: >>>>>> >>>>>>> On 23.10.2013 10:08, Staffan Larsen wrote: >>>>>>>> I think you can simplify the logic for forcing a GC to just a >>>>>>>> simple >>>>>>>> call to "System.gc();". AFAIK System.gc() will cause a full >>>>>>>> collection to happen for all collectors. >>>>>>> Hm, will it now? I had the impression that it was just hinting >>>>>>> the GC >>>>>>> system to perform GC but it might decide to ignore it. I need to be >>>>>>> sure that the GC was performed before continuing - otherwise I might >>>>>>> get inconsistent data again. >>>>>> According to the spec it's just a hint, but I think the >>>>>> implementation >>>>>> happens to be a force. But better safe than sorry. :) >>>>>> >>>>>> /Staffan >>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> /Staffan >>>>>>>> >>>>>>>> On 23 okt 2013, at 10:02, Jaroslav Bachorik >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 22.10.2013 22:04, Mandy Chung wrote: >>>>>>>>>> Hi Jaroslav, >>>>>>>>>> >>>>>>>>>> On 10/22/13 6:47 AM, Jaroslav Bachorik wrote: >>>>>>>>>>> Please, review the following test fix: >>>>>>>>>>> >>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8020467 >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8020467/webrev.01 >>>>>>>>>>> >>>>>>>>>> Have you considered to force GC when getUsed() == 0 regardless of >>>>>>>>>> which >>>>>>>>>> memory pool it is? This will avoid special casing for CMS old >>>>>>>>>> gen in >>>>>>>>>> the test and will handle similar issue in the future for a >>>>>>>>>> different >>>>>>>>>> collector implementation. To make the test reliable, the test >>>>>>>>>> should >>>>>>>>>> still pass if the memory pool has no object in it (G1 survivor >>>>>>>>>> space >>>>>>>>>> case?). >>>>>>>>> Hi Mandy, >>>>>>>>> >>>>>>>>> I don't know whether GC will help for other pools - but I can >>>>>>>>> enable it for all pools - it should not hurt. >>>>>>>>> >>>>>>>>> The test should pass even with on object in the monitored pool >>>>>>>>> since the pool should not report an exceeded threshold. >>>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>>>>>>>> Mandy >>>>>>>>>> >>>>>>>>>>> The test tries to make sure that the "pool usage threshold" >>>>>>>>>>> trigger >>>>>>>>>>> and the reported pool memory usage are not contradicting each >>>>>>>>>>> other. >>>>>>>>>>> The problem is that it is not possible to get the "pool usage >>>>>>>>>>> threshold exceeded" flag and the pool memory usage atomicly in >>>>>>>>>>> regard >>>>>>>>>>> to the GC. Specifically, when "CMS Old Gen" pool is examined >>>>>>>>>>> and the >>>>>>>>>>> usage is retrieved before a GC promotes some objects to the old >>>>>>>>>>> gen >>>>>>>>>>> but the usage threshold is checked after the GC has promoted >>>>>>>>>>> some >>>>>>>>>>> instance into the old gen the test will fail. >>>>>>>>>>> >>>>>>>>>>> The patch makes sure that there are some instances promoted in >>>>>>>>>>> "CMS >>>>>>>>>>> Old Gen" before checking the "pool usage threshold" to get >>>>>>>>>>> semi-consistent view. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> -JB- >>>>> >>>> >>> >> > From jaroslav.bachorik at oracle.com Wed Oct 23 08:16:50 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 23 Oct 2013 17:16:50 +0200 Subject: RFR 8027058: sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh Failed to initialize connector Message-ID: <5267E862.1020804@oracle.com> Please, review the following test change: Issue: https://bugs.openjdk.java.net/browse/JDK-8027058 Webrev: http://cr.openjdk.java.net/~jbachorik/8027058/webrev.00 The test fails when the requested port is unavailable. The test logic already runs the subtests with different port numbers (increasing the port number for each subtest) and this patch adds the logic to increase the port number in case of the subtest failure caused by BindException. This way the test is able to "autodiscover" free ports and run the bootstrap subtests successfully. Thanks, -JB- From daniel.fuchs at oracle.com Wed Oct 23 08:32:20 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 23 Oct 2013 17:32:20 +0200 Subject: RFR 8027058: sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh Failed to initialize connector In-Reply-To: <5267E862.1020804@oracle.com> References: <5267E862.1020804@oracle.com> Message-ID: <5267EC04.9010108@oracle.com> Hi Jaroslav, Have you considered setting a limit on the number of tries you will attempt, rather than just 'while (true)'? It might avoid creating a busy while loop in case there's some global networking issue. -- daniel On 10/23/13 5:16 PM, Jaroslav Bachorik wrote: > Please, review the following test change: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8027058 > Webrev: http://cr.openjdk.java.net/~jbachorik/8027058/webrev.00 > > The test fails when the requested port is unavailable. The test logic > already runs the subtests with different port numbers (increasing the > port number for each subtest) and this patch adds the logic to increase > the port number in case of the subtest failure caused by BindException. > This way the test is able to "autodiscover" free ports and run the > bootstrap subtests successfully. > > Thanks, > > -JB- From bengt.rutisson at oracle.com Wed Oct 23 08:31:18 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 23 Oct 2013 17:31:18 +0200 Subject: jmx-dev RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: <5267E621.2040601@oracle.com> References: <526681FD.90604@oracle.com> <5266DA56.6050609@oracle.com> <52678280.1070004@oracle.com> <4972770C-A8BB-40A0-9BB8-885AA6B707BC@oracle.com> <52678509.2020002@oracle.com> <68F92D47-E916-426B-8D6A-2EA48302053D@oracle.com> <5267C3AD.5050306@oracle.com> <5267C74F.2010302@oracle.com> <5267CC00.7080509@oracle.com> <5267DDFC.4060607@oracle.com> <5267E092.6090006@oracle.com> <5267E621.2040601@oracle.com> Message-ID: <5267EBC6.8010609@oracle.com> Hi again Jaroslav, On 2013-10-23 17:07, Jaroslav Bachorik wrote: > On 23.10.2013 16:43, Bengt Rutisson wrote: >> >> Hi Jaroslav, >> >> On 2013-10-23 16:32, Jaroslav Bachorik wrote: >>> On 23.10.2013 15:15, Bengt Rutisson wrote: >>>> >>>> On 2013-10-23 14:55, Jaroslav Bachorik wrote: >>>>> Hi Bengt, >>>>> >>>>> On 23.10.2013 14:40, Bengt Rutisson wrote: >>>>>> >>>>>> Hi Jaroslav, >>>>>> >>>>>> A couple of questions. >>>>>> >>>>>> I don't understand why this is a CMS only problem? Why don't the >>>>>> other >>>>>> collectors have the same issue? I guess it is less likely that the >>>>>> other >>>>>> collectors start (or complete) a GC without a lot of allocation >>>>>> going >>>>>> on. But at least G1 should have the same problem. >>>>> >>>>> I don't really know. If there are other pools that can have the >>>>> "used" >>>>> value 0 before a GC happens then yes, they are susceptible to the >>>>> same >>>>> problem. >>>> >>>> I think all the "old" pools can have 0 used before a GC happens. But >>>> except for CMS and G1 it is less likely that a GC happens unless >>>> you do >>>> allocations. As long as they keep the 0 used the test will pass. >>>> So, my >>>> guess is that to be on the safe side all "old" pools should make >>>> sure to >>>> do a full GC first. >>>> >>>>> >>>>>> >>>>>> Also, from the problem description in the CR I would have guessed >>>>>> that >>>>>> you want the GC to happen between these two statements: >>>>>> >>>>>> p.setUsageThreshold(1); >>>>>> MemoryUsage u = p.getUsage(); >>>>> >>>>> This is all but a heuristic here. The problem lies in the fact >>>>> that it >>>>> is not possible to retrieve the pool usage and the "threshold >>>>> exceeded" flag consistently in one atomic operation. I might get >>>>> usable data from the first call and then I don't need to force GC. >>>> >>>> Right. This is why I think you want to avoid a GC after you have >>>> fetched >>>> getUsage() but before you do isUsageThresholdExceeded(). With your >>>> suggested patch you are explicitly inserting a GC at that point. To me >>>> this sounds like the opposite of what you want to do. >>> >>> I've updated the patch. The GC is called even before the first attempt >>> to get the pool memory usage and System.gc() is used to perform GC (no >>> MXBean checks). This should simplify the change a bit. >>> >>> http://cr.openjdk.java.net/~jbachorik/8020467/webrev.02 >> >> Thanks for doing this update so quickly! >> >> Have you been able to verify that this change still fixes the issue? I >> think it should, but it would be good if we could verify it. > > Yep, it still fixes the problem. Unfortunatelly, the only way to > reproduce the problem locally is to run the test under debugger and > invoke GC explicitly between getting the pool memory usage and > threshold flag. > >> >> This code worries me a little bit: >> >> 114 private static MemoryUsage getUsage(MemoryPoolMXBean p) { >> 115 MemoryUsage u = null; >> 116 do { >> 117 System.gc(); >> 118 u = p.getUsage(); >> 119 } while (u.getUsed() == 0); >> 120 return u; >> 121 } >> >> I think one call to System.gc() should be enough. And if it is not, if >> we still get 0 as used, I think that another System.gc() call will just >> render the same result. Thus, I'm a bit worried that this will be an >> endless loop. > > Sounds reasonable. My motivation was to try to make sure some objects > are promoted to old gen but it seems redundant and in case of > non-oldgen pools might not even work :( > >> >> Since the test actually handles the case where used is 0, I think it is >> enough to just do a single call to System.gc() and then get the usage >> data. > > Hm, this makes the patch even simpler ... > http://cr.openjdk.java.net/~jbachorik/8020467/webrev.03 Yes, I think this looks simple and good. :-) Thanks, Bengt > > -JB- > > >> >> Thanks, >> Bengt >> >> >>> >>> -JB- >>> >>>> >>>>> >>>>>> >>>>>> Now you have added the GC just after these statements. I thought >>>>>> that >>>>>> was what caused the problem. That you read the usage data at one >>>>>> point, >>>>>> then a GC happens and you compare the cached usage >>>>>> data to the new data that p.isUsageThresholdExceeded() will fetch. >>>>>> >>>>>> Looking at the promoteToOldGen() method I assume that the intent is >>>>>> that >>>>>> the code should be using the return value. So my guess is that this >>>>>> code: >>>>>> >>>>>> 94 if (p.getName().equals("CMS Old Gen")) { >>>>>> 95 promoteToOldGen(p, u); >>>>>> 96 } >>>>>> >>>>>> Should be: >>>>>> >>>>>> 94 if (p.getName().equals("CMS Old Gen")) { >>>>>> 95 u = promoteToOldGen(p, u); >>>>>> 96 } >>>>> >>>>> Indeed. It was meant to re-fetch the usage after GC. >>>> >>>> OK. Good. With this code I think it should work. Now you make sure to >>>> get the GC before you do getUsage(). >>>> >>>>> >>>>>> >>>>>> With that, I think it might work. But I still don't understand why >>>>>> this >>>>>> is only a CMS problem. >>>>>> >>>>>> One more question about the promoteToOldGen() and forceGC() >>>>>> methods. I >>>>>> don't really know much about how the different beans work, but >>>>>> are we >>>>>> sure that the MemoryPoolMXBeans and GarbageCollectorMXBeans use the >>>>>> same >>>>>> pool names? That is, are you sure that forceGC() actually will do >>>>>> anything? >>>>> >>>>> They use the pool names as reported by the GC infrastracture so they >>>>> should be the same. >>>> >>>> Ok. >>>> >>>>> >>>>>> >>>>>> As for just doing a System.gc() to force a GC I think you can >>>>>> rely on >>>>>> that System.gc() does a full GC in Hotspot unless someone sets >>>>>> -XX:+DisableExplicitGC on the command line. Considering that you are >>>>>> relying on Hotspot specifc names for pools I don't think it is a >>>>>> limitation to the test to rely on the Hotspot implementatoin of >>>>>> System.gc(). >>>>> >>>>> Good to know. I guess I could simplify the change and just call >>>>> System.gc(), after all. >>>> >>>> Yes, I think that' simpler. >>>> >>>> Thanks, >>>> Bengt >>>> >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> Thanks, >>>>>> Bengt >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 2013-10-23 10:18, Staffan Larsen wrote: >>>>>>> On 23 okt 2013, at 10:12, Jaroslav Bachorik >>>>>>> wrote: >>>>>>> >>>>>>>> On 23.10.2013 10:08, Staffan Larsen wrote: >>>>>>>>> I think you can simplify the logic for forcing a GC to just a >>>>>>>>> simple >>>>>>>>> call to "System.gc();". AFAIK System.gc() will cause a full >>>>>>>>> collection to happen for all collectors. >>>>>>>> Hm, will it now? I had the impression that it was just hinting >>>>>>>> the GC >>>>>>>> system to perform GC but it might decide to ignore it. I need >>>>>>>> to be >>>>>>>> sure that the GC was performed before continuing - otherwise I >>>>>>>> might >>>>>>>> get inconsistent data again. >>>>>>> According to the spec it's just a hint, but I think the >>>>>>> implementation >>>>>>> happens to be a force. But better safe than sorry. :) >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>> On 23 okt 2013, at 10:02, Jaroslav Bachorik >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On 22.10.2013 22:04, Mandy Chung wrote: >>>>>>>>>>> Hi Jaroslav, >>>>>>>>>>> >>>>>>>>>>> On 10/22/13 6:47 AM, Jaroslav Bachorik wrote: >>>>>>>>>>>> Please, review the following test fix: >>>>>>>>>>>> >>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8020467 >>>>>>>>>>>> Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/8020467/webrev.01 >>>>>>>>>>>> >>>>>>>>>>> Have you considered to force GC when getUsed() == 0 >>>>>>>>>>> regardless of >>>>>>>>>>> which >>>>>>>>>>> memory pool it is? This will avoid special casing for CMS old >>>>>>>>>>> gen in >>>>>>>>>>> the test and will handle similar issue in the future for a >>>>>>>>>>> different >>>>>>>>>>> collector implementation. To make the test reliable, the test >>>>>>>>>>> should >>>>>>>>>>> still pass if the memory pool has no object in it (G1 survivor >>>>>>>>>>> space >>>>>>>>>>> case?). >>>>>>>>>> Hi Mandy, >>>>>>>>>> >>>>>>>>>> I don't know whether GC will help for other pools - but I can >>>>>>>>>> enable it for all pools - it should not hurt. >>>>>>>>>> >>>>>>>>>> The test should pass even with on object in the monitored pool >>>>>>>>>> since the pool should not report an exceeded threshold. >>>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>>> >>>>>>>>>>> Mandy >>>>>>>>>>> >>>>>>>>>>>> The test tries to make sure that the "pool usage threshold" >>>>>>>>>>>> trigger >>>>>>>>>>>> and the reported pool memory usage are not contradicting each >>>>>>>>>>>> other. >>>>>>>>>>>> The problem is that it is not possible to get the "pool usage >>>>>>>>>>>> threshold exceeded" flag and the pool memory usage atomicly in >>>>>>>>>>>> regard >>>>>>>>>>>> to the GC. Specifically, when "CMS Old Gen" pool is examined >>>>>>>>>>>> and the >>>>>>>>>>>> usage is retrieved before a GC promotes some objects to the >>>>>>>>>>>> old >>>>>>>>>>>> gen >>>>>>>>>>>> but the usage threshold is checked after the GC has promoted >>>>>>>>>>>> some >>>>>>>>>>>> instance into the old gen the test will fail. >>>>>>>>>>>> >>>>>>>>>>>> The patch makes sure that there are some instances promoted in >>>>>>>>>>>> "CMS >>>>>>>>>>>> Old Gen" before checking the "pool usage threshold" to get >>>>>>>>>>>> semi-consistent view. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> -JB- >>>>>> >>>>> >>>> >>> >> > From jaroslav.bachorik at oracle.com Wed Oct 23 08:35:53 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 23 Oct 2013 17:35:53 +0200 Subject: RFR 8027058: sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh Failed to initialize connector In-Reply-To: <5267EC04.9010108@oracle.com> References: <5267E862.1020804@oracle.com> <5267EC04.9010108@oracle.com> Message-ID: <5267ECD9.20304@oracle.com> On 23.10.2013 17:32, Daniel Fuchs wrote: > Hi Jaroslav, > > Have you considered setting a limit on the number of tries you > will attempt, rather than just 'while (true)'? > It might avoid creating a busy while loop in case there's some global > networking issue. It might be difficult to come up with the right number. Probably a few hundred could be enough even for cases when you hit a contiguous range of ports occupied by different applications. -JB- > > -- daniel > > On 10/23/13 5:16 PM, Jaroslav Bachorik wrote: >> Please, review the following test change: >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8027058 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8027058/webrev.00 >> >> The test fails when the requested port is unavailable. The test logic >> already runs the subtests with different port numbers (increasing the >> port number for each subtest) and this patch adds the logic to increase >> the port number in case of the subtest failure caused by BindException. >> This way the test is able to "autodiscover" free ports and run the >> bootstrap subtests successfully. >> >> Thanks, >> >> -JB- > From alexander.zuev at oracle.com Wed Oct 23 07:40:51 2013 From: alexander.zuev at oracle.com (alexander.zuev at oracle.com) Date: Wed, 23 Oct 2013 14:40:51 +0000 Subject: hg: jdk8/tl/jdk: 8020802: Need an ability to create jar files that are invariant to the pack200 packing/unpacking Message-ID: <20131023144119.06BEB6268B@hg.openjdk.java.net> Changeset: 3cdf6ca3ef47 Author: kizune Date: 2013-10-23 18:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3cdf6ca3ef47 8020802: Need an ability to create jar files that are invariant to the pack200 packing/unpacking Reviewed-by: alanb, ksrini ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/jar/resources/jar.properties + test/tools/jar/normalize/TestNormal.java From daniel.fuchs at oracle.com Wed Oct 23 08:49:28 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 23 Oct 2013 17:49:28 +0200 Subject: RFR 8027058: sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh Failed to initialize connector In-Reply-To: <5267ECD9.20304@oracle.com> References: <5267E862.1020804@oracle.com> <5267EC04.9010108@oracle.com> <5267ECD9.20304@oracle.com> Message-ID: <5267F008.808@oracle.com> On 10/23/13 5:35 PM, Jaroslav Bachorik wrote: > On 23.10.2013 17:32, Daniel Fuchs wrote: >> Hi Jaroslav, >> >> Have you considered setting a limit on the number of tries you >> will attempt, rather than just 'while (true)'? >> It might avoid creating a busy while loop in case there's some global >> networking issue. > > It might be difficult to come up with the right number. Probably a few > hundred could be enough even for cases when you hit a contiguous range > of ports occupied by different applications. Instead of using an arbitrary 12424 as the default starting point it could be interesting to try with the first available port + 1; something like: final int startPort; try (ServerSocket s = new ServerSocket(0)) { startPort = s.getLocalPort() + 1; } System.out.println("startPort: "+startPort); But maybe that's what the test that calls the code is already doing? -- daniel > > -JB- > >> >> -- daniel >> >> On 10/23/13 5:16 PM, Jaroslav Bachorik wrote: >>> Please, review the following test change: >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8027058 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8027058/webrev.00 >>> >>> The test fails when the requested port is unavailable. The test logic >>> already runs the subtests with different port numbers (increasing the >>> port number for each subtest) and this patch adds the logic to increase >>> the port number in case of the subtest failure caused by BindException. >>> This way the test is able to "autodiscover" free ports and run the >>> bootstrap subtests successfully. >>> >>> Thanks, >>> >>> -JB- >> > From sean.coffey at oracle.com Wed Oct 23 09:00:59 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Wed, 23 Oct 2013 16:00:59 +0000 Subject: hg: jdk8/tl/jdk: 5036554: unmarshal error on CORBA alias type in CORBA any Message-ID: <20131023160209.B5AA062696@hg.openjdk.java.net> Changeset: 2af3f5a61322 Author: coffeys Date: 2013-10-23 16:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2af3f5a61322 5036554: unmarshal error on CORBA alias type in CORBA any Reviewed-by: chegar, smarks + test/com/sun/corba/5036554/JavaBug.java + test/com/sun/corba/5036554/README + test/com/sun/corba/5036554/TestCorbaBug.sh + test/com/sun/corba/5036554/bug.idl From jaroslav.bachorik at oracle.com Wed Oct 23 09:13:38 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 23 Oct 2013 18:13:38 +0200 Subject: RFR 8027058: sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh Failed to initialize connector In-Reply-To: <5267F008.808@oracle.com> References: <5267E862.1020804@oracle.com> <5267EC04.9010108@oracle.com> <5267ECD9.20304@oracle.com> <5267F008.808@oracle.com> Message-ID: <5267F5B2.7090807@oracle.com> On 23.10.2013 17:49, Daniel Fuchs wrote: > On 10/23/13 5:35 PM, Jaroslav Bachorik wrote: >> On 23.10.2013 17:32, Daniel Fuchs wrote: >>> Hi Jaroslav, >>> >>> Have you considered setting a limit on the number of tries you >>> will attempt, rather than just 'while (true)'? >>> It might avoid creating a busy while loop in case there's some global >>> networking issue. >> >> It might be difficult to come up with the right number. Probably a few >> hundred could be enough even for cases when you hit a contiguous range >> of ports occupied by different applications. > > Instead of using an arbitrary 12424 as the default starting point > it could be interesting to try with the first available port + 1; > > something like: > > final int startPort; > try (ServerSocket s = new ServerSocket(0)) { > startPort = s.getLocalPort() + 1; > } > System.out.println("startPort: "+startPort); > > But maybe that's what the test that calls the code is already doing? Nope, it's hardcoded. I've added the cap for the number of consecutive checks for a port being available and dynamic lookup of the first available port (if it's not specified by the system property "rmi.port"). http://cr.openjdk.java.net/~jbachorik/8027058/webrev.01 Thanks for the additional ideas! -JB- > > -- daniel > > >> >> -JB- >> >>> >>> -- daniel >>> >>> On 10/23/13 5:16 PM, Jaroslav Bachorik wrote: >>>> Please, review the following test change: >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8027058 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8027058/webrev.00 >>>> >>>> The test fails when the requested port is unavailable. The test logic >>>> already runs the subtests with different port numbers (increasing the >>>> port number for each subtest) and this patch adds the logic to increase >>>> the port number in case of the subtest failure caused by BindException. >>>> This way the test is able to "autodiscover" free ports and run the >>>> bootstrap subtests successfully. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From daniel.fuchs at oracle.com Wed Oct 23 09:18:08 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 23 Oct 2013 18:18:08 +0200 Subject: RFR 8027058: sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh Failed to initialize connector In-Reply-To: <5267F5B2.7090807@oracle.com> References: <5267E862.1020804@oracle.com> <5267EC04.9010108@oracle.com> <5267ECD9.20304@oracle.com> <5267F008.808@oracle.com> <5267F5B2.7090807@oracle.com> Message-ID: <5267F6C0.3020606@oracle.com> Looks good to me! -- daniel On 10/23/13 6:13 PM, Jaroslav Bachorik wrote: > On 23.10.2013 17:49, Daniel Fuchs wrote: >> On 10/23/13 5:35 PM, Jaroslav Bachorik wrote: >>> On 23.10.2013 17:32, Daniel Fuchs wrote: >>>> Hi Jaroslav, >>>> >>>> Have you considered setting a limit on the number of tries you >>>> will attempt, rather than just 'while (true)'? >>>> It might avoid creating a busy while loop in case there's some global >>>> networking issue. >>> >>> It might be difficult to come up with the right number. Probably a few >>> hundred could be enough even for cases when you hit a contiguous range >>> of ports occupied by different applications. >> >> Instead of using an arbitrary 12424 as the default starting point >> it could be interesting to try with the first available port + 1; >> >> something like: >> >> final int startPort; >> try (ServerSocket s = new ServerSocket(0)) { >> startPort = s.getLocalPort() + 1; >> } >> System.out.println("startPort: "+startPort); >> >> But maybe that's what the test that calls the code is already doing? > > Nope, it's hardcoded. > > I've added the cap for the number of consecutive checks for a port being > available and dynamic lookup of the first available port (if it's not > specified by the system property "rmi.port"). > > http://cr.openjdk.java.net/~jbachorik/8027058/webrev.01 > > Thanks for the additional ideas! > > -JB- > > >> >> -- daniel >> >> >>> >>> -JB- >>> >>>> >>>> -- daniel >>>> >>>> On 10/23/13 5:16 PM, Jaroslav Bachorik wrote: >>>>> Please, review the following test change: >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8027058 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8027058/webrev.00 >>>>> >>>>> The test fails when the requested port is unavailable. The test logic >>>>> already runs the subtests with different port numbers (increasing the >>>>> port number for each subtest) and this patch adds the logic to >>>>> increase >>>>> the port number in case of the subtest failure caused by >>>>> BindException. >>>>> This way the test is able to "autodiscover" free ports and run the >>>>> bootstrap subtests successfully. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> >>> >> > From sean.coffey at oracle.com Wed Oct 23 08:56:52 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Wed, 23 Oct 2013 15:56:52 +0000 Subject: hg: jdk8/tl/corba: 5036554: unmarshal error on CORBA alias type in CORBA any Message-ID: <20131023155701.2BAAE62693@hg.openjdk.java.net> Changeset: a90e9efa4264 Author: coffeys Date: 2013-10-23 16:45 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/a90e9efa4264 5036554: unmarshal error on CORBA alias type in CORBA any Reviewed-by: chegar, smarks ! src/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java From sundararajan.athijegannathan at oracle.com Wed Oct 23 09:29:42 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 23 Oct 2013 16:29:42 +0000 Subject: hg: jdk8/tl/nashorn: 3 new changesets Message-ID: <20131023162955.2458562698@hg.openjdk.java.net> Changeset: 5df55690fd5b Author: sundar Date: 2013-10-23 17:30 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5df55690fd5b 8027128: jdk.nashorn.api.scripting.JSObject should be an interface Reviewed-by: hannesw, attila, jlaskey + src/jdk/nashorn/api/scripting/AbstractJSObject.java ! src/jdk/nashorn/api/scripting/JSObject.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! test/script/basic/JDK-8024847.js ! test/script/basic/JDK-8024847.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/PluggableJSObjectTest.java ! test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java Changeset: f31ee3a2847d Author: sundar Date: 2013-10-23 20:15 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f31ee3a2847d 8027150: ScriptObjectListAdapter won't work as expected Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/runtime/ListAdapter.java - src/jdk/nashorn/internal/runtime/ScriptObjectListAdapter.java Changeset: 640c1854f742 Author: sundar Date: 2013-10-23 20:21 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/640c1854f742 Merge - src/jdk/nashorn/internal/runtime/ScriptObjectListAdapter.java From robert.field at oracle.com Wed Oct 23 10:28:49 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Wed, 23 Oct 2013 17:28:49 +0000 Subject: hg: jdk8/tl/langtools: 8022720: Method refeerences - private method should be accessible (nested classes) Message-ID: <20131023172853.4DBC46269B@hg.openjdk.java.net> Changeset: 32ea6ccb7607 Author: rfield Date: 2013-10-23 10:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/32ea6ccb7607 8022720: Method refeerences - private method should be accessible (nested classes) Reviewed-by: jjg, ksrini ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/privateMethodReferences/MethodInvoker.java + test/tools/javac/lambda/privateMethodReferences/MethodSupplier.java + test/tools/javac/lambda/privateMethodReferences/ThirdClass.java From robert.field at oracle.com Wed Oct 23 11:37:36 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Wed, 23 Oct 2013 18:37:36 +0000 Subject: hg: jdk8/tl/jdk: 8027176: Remove redundant jdk/lambda/vm/DefaultMethodsTest.java Message-ID: <20131023183806.10E2B6269D@hg.openjdk.java.net> Changeset: 88acc99132e2 Author: rfield Date: 2013-10-23 11:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/88acc99132e2 8027176: Remove redundant jdk/lambda/vm/DefaultMethodsTest.java Reviewed-by: ksrini - test/jdk/lambda/vm/DefaultMethodsTest.java From sean.coffey at oracle.com Wed Oct 23 12:54:25 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Wed, 23 Oct 2013 19:54:25 +0000 Subject: hg: jdk8/tl/jdk: 8026405: javax/xml/ws/clientjar/TestWsImport.java failing on JDK 8 nightly aurora test runs Message-ID: <20131023195510.255C4626A3@hg.openjdk.java.net> Changeset: ee7f1c78bec7 Author: coffeys Date: 2013-10-23 20:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ee7f1c78bec7 8026405: javax/xml/ws/clientjar/TestWsImport.java failing on JDK 8 nightly aurora test runs Reviewed-by: chegar ! test/javax/xml/ws/clientjar/TestWsImport.java From daniel.daugherty at oracle.com Wed Oct 23 13:26:34 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 23 Oct 2013 14:26:34 -0600 Subject: code review round 0 for MacOS X FDS whitespace/indent fixes (8027117) Message-ID: <526830FA.1080104@oracle.com> Greetings, I have some MacOS X Full Debug Symbols whitespace/indent fixes. Here is the JDK8/HSX-25 webrev URL: OpenJDK: http://cr.openjdk.java.net/~dcubed/fds_revamp/8027117-webrev/0-jdk8/ Internal: http://javaweb.us.oracle.com/~ddaugher/fds_revamp/8027117-webrev/0-jdk8/ Because these are whitespace/indent fixes, only the "Cdiffs" and "Udiffs" links show all the changes. This webrev includes changes for the follow repos: jdk8 jdk8/jdk Gory details are below... As always, comments, questions and suggestions are welcome. Dan The fixes for the following two bugs hit JDK8 at the same time, but came up via different sub-baselines: 7165611 implement Full Debug Symbols on MacOS X hotspot https://bugs.openjdk.java.net/browse/JDK-7165611 8001931 build-infra: Apply consistent formatting/indentation to new build-infra files https://bugs.openjdk.java.net/browse/JDK-8001931 During the JDK8 merge process some of the changes from 7165611 were not properly adjusted to meet the new whitespace/indent policy implemented by 8001931. This changeset fixes those style issues. Testing: - JPRT JDK8 forest build and test on all platforms (in process) From gerald.thornbrugh at oracle.com Wed Oct 23 13:41:20 2013 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Wed, 23 Oct 2013 13:41:20 -0700 (PDT) Subject: code review round 0 for MacOS X FDS whitespace/indent fixes (8027117) Message-ID: <5b4bda80-7597-486d-a8fa-2433dc777d3b@default> Hi Dan, Your changes look good but I have a question. On source files that do not have an Oracle copyright like generated-configure.sh is the correct method to leave the copyright as it is? Thanks! Jerry ----- Original Message ----- From: daniel.daugherty at oracle.com To: hotspot-runtime-dev at openjdk.java.net, serviceability-dev at openjdk.java.net, build-dev at openjdk.java.net Sent: Wednesday, October 23, 2013 2:28:54 PM GMT -07:00 US/Canada Mountain Subject: code review round 0 for MacOS X FDS whitespace/indent fixes (8027117) Greetings, I have some MacOS X Full Debug Symbols whitespace/indent fixes. Here is the JDK8/HSX-25 webrev URL: OpenJDK: http://cr.openjdk.java.net/~dcubed/fds_revamp/8027117-webrev/0-jdk8/ Internal: http://javaweb.us.oracle.com/~ddaugher/fds_revamp/8027117-webrev/0-jdk8/ Because these are whitespace/indent fixes, only the "Cdiffs" and "Udiffs" links show all the changes. This webrev includes changes for the follow repos: jdk8 jdk8/jdk Gory details are below... As always, comments, questions and suggestions are welcome. Dan The fixes for the following two bugs hit JDK8 at the same time, but came up via different sub-baselines: 7165611 implement Full Debug Symbols on MacOS X hotspot https://bugs.openjdk.java.net/browse/JDK-7165611 8001931 build-infra: Apply consistent formatting/indentation to new build-infra files https://bugs.openjdk.java.net/browse/JDK-8001931 During the JDK8 merge process some of the changes from 7165611 were not properly adjusted to meet the new whitespace/indent policy implemented by 8001931. This changeset fixes those style issues. Testing: - JPRT JDK8 forest build and test on all platforms (in process) From daniel.daugherty at oracle.com Wed Oct 23 13:55:04 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 23 Oct 2013 14:55:04 -0600 Subject: code review round 0 for MacOS X FDS whitespace/indent fixes (8027117) In-Reply-To: <5b4bda80-7597-486d-a8fa-2433dc777d3b@default> References: <5b4bda80-7597-486d-a8fa-2433dc777d3b@default> Message-ID: <526837A8.4040504@oracle.com> Jerry, Thanks for the fast review! On 10/23/13 2:41 PM, Gerald Thornbrugh wrote: > Hi Dan, > > Your changes look good but I have a question. > > On source files that do not have an Oracle copyright like generated-configure.sh > is the correct method to leave the copyright as it is? generated-configure.sh is a special case relative to the usual (Oracle) copyright rules. In particular, this file (should) match the version generated if you run 'configure' on the code base. The tools that generate the generated-configure.sh file (correctly) do not include an Oracle style copyright. Dan > > Thanks! > > Jerry > > ----- Original Message ----- > From: daniel.daugherty at oracle.com > To: hotspot-runtime-dev at openjdk.java.net, serviceability-dev at openjdk.java.net, build-dev at openjdk.java.net > Sent: Wednesday, October 23, 2013 2:28:54 PM GMT -07:00 US/Canada Mountain > Subject: code review round 0 for MacOS X FDS whitespace/indent fixes (8027117) > > Greetings, > > I have some MacOS X Full Debug Symbols whitespace/indent fixes. > Here is the JDK8/HSX-25 webrev URL: > > OpenJDK: > http://cr.openjdk.java.net/~dcubed/fds_revamp/8027117-webrev/0-jdk8/ > Internal: > http://javaweb.us.oracle.com/~ddaugher/fds_revamp/8027117-webrev/0-jdk8/ > > Because these are whitespace/indent fixes, only the "Cdiffs" and > "Udiffs" links show all the changes. > > This webrev includes changes for the follow repos: > > jdk8 > jdk8/jdk > > Gory details are below... > > As always, comments, questions and suggestions are welcome. > > Dan > > > The fixes for the following two bugs hit JDK8 at the same time, but > came up via different sub-baselines: > > 7165611 implement Full Debug Symbols on MacOS X hotspot > https://bugs.openjdk.java.net/browse/JDK-7165611 > > 8001931 build-infra: Apply consistent formatting/indentation to > new build-infra files > https://bugs.openjdk.java.net/browse/JDK-8001931 > > During the JDK8 merge process some of the changes from 7165611 were not > properly adjusted to meet the new whitespace/indent policy implemented > by 8001931. This changeset fixes those style issues. > > Testing: > - JPRT JDK8 forest build and test on all platforms (in process) From gerald.thornbrugh at oracle.com Wed Oct 23 13:56:41 2013 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Wed, 23 Oct 2013 14:56:41 -0600 Subject: code review round 0 for MacOS X FDS whitespace/indent fixes (8027117) In-Reply-To: <526837A8.4040504@oracle.com> References: <5b4bda80-7597-486d-a8fa-2433dc777d3b@default> <526837A8.4040504@oracle.com> Message-ID: <52683809.50201@oracle.com> Hi Dan, Thanks for the explanation. Jerry > Jerry, > > Thanks for the fast review! > > > On 10/23/13 2:41 PM, Gerald Thornbrugh wrote: >> Hi Dan, >> >> Your changes look good but I have a question. >> >> On source files that do not have an Oracle copyright like >> generated-configure.sh >> is the correct method to leave the copyright as it is? > > generated-configure.sh is a special case relative to the usual (Oracle) > copyright rules. In particular, this file (should) match the version > generated if you run 'configure' on the code base. The tools that > generate the generated-configure.sh file (correctly) do not include an > Oracle style copyright. > > Dan > > >> >> Thanks! >> >> Jerry >> >> ----- Original Message ----- >> From: daniel.daugherty at oracle.com >> To: hotspot-runtime-dev at openjdk.java.net, >> serviceability-dev at openjdk.java.net, build-dev at openjdk.java.net >> Sent: Wednesday, October 23, 2013 2:28:54 PM GMT -07:00 US/Canada >> Mountain >> Subject: code review round 0 for MacOS X FDS whitespace/indent fixes >> (8027117) >> >> Greetings, >> >> I have some MacOS X Full Debug Symbols whitespace/indent fixes. >> Here is the JDK8/HSX-25 webrev URL: >> >> OpenJDK: >> http://cr.openjdk.java.net/~dcubed/fds_revamp/8027117-webrev/0-jdk8/ >> Internal: >> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/8027117-webrev/0-jdk8/ >> >> Because these are whitespace/indent fixes, only the "Cdiffs" and >> "Udiffs" links show all the changes. >> >> This webrev includes changes for the follow repos: >> >> jdk8 >> jdk8/jdk >> >> Gory details are below... >> >> As always, comments, questions and suggestions are welcome. >> >> Dan >> >> >> The fixes for the following two bugs hit JDK8 at the same time, but >> came up via different sub-baselines: >> >> 7165611 implement Full Debug Symbols on MacOS X hotspot >> https://bugs.openjdk.java.net/browse/JDK-7165611 >> >> 8001931 build-infra: Apply consistent formatting/indentation to >> new build-infra files >> https://bugs.openjdk.java.net/browse/JDK-8001931 >> >> During the JDK8 merge process some of the changes from 7165611 were not >> properly adjusted to meet the new whitespace/indent policy implemented >> by 8001931. This changeset fixes those style issues. >> >> Testing: >> - JPRT JDK8 forest build and test on all platforms (in process) > From bhavesh.x.patel at oracle.com Wed Oct 23 13:57:54 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Wed, 23 Oct 2013 20:57:54 +0000 Subject: hg: jdk8/tl/langtools: 8026770: javadoc creates invalid HTML in profile summary pages Message-ID: <20131023205809.E7B2B626A6@hg.openjdk.java.net> Changeset: 8746caa5cf80 Author: bpatel Date: 2013-10-23 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8746caa5cf80 8026770: javadoc creates invalid HTML in profile summary pages Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java ! test/com/sun/javadoc/testProfiles/TestProfiles.java From daniel.daugherty at oracle.com Wed Oct 23 13:59:29 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 23 Oct 2013 14:59:29 -0600 Subject: code review round 0 for MacOS X FDS whitespace/indent fixes (8027117) In-Reply-To: <5268368D.8090708@oracle.com> References: <526830FA.1080104@oracle.com> <52683355.3060806@oracle.com> <5268368D.8090708@oracle.com> Message-ID: <526838B1.3040208@oracle.com> Adding back the other two aliases... Dan On 10/23/13 2:50 PM, Daniel D. Daugherty wrote: > Harold, > > Thanks for the fast review! > > Dan > > On 10/23/13 2:36 PM, harold seigel wrote: >> Hi Dan, >> >> The whitespace/indents look good. >> >> Harold >> >> On 10/23/2013 4:26 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have some MacOS X Full Debug Symbols whitespace/indent fixes. >>> Here is the JDK8/HSX-25 webrev URL: >>> >>> OpenJDK: >>> http://cr.openjdk.java.net/~dcubed/fds_revamp/8027117-webrev/0-jdk8/ >>> Internal: >>> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/8027117-webrev/0-jdk8/ >>> >>> >>> Because these are whitespace/indent fixes, only the "Cdiffs" and >>> "Udiffs" links show all the changes. >>> >>> This webrev includes changes for the follow repos: >>> >>> jdk8 >>> jdk8/jdk >>> >>> Gory details are below... >>> >>> As always, comments, questions and suggestions are welcome. >>> >>> Dan >>> >>> >>> The fixes for the following two bugs hit JDK8 at the same time, but >>> came up via different sub-baselines: >>> >>> 7165611 implement Full Debug Symbols on MacOS X hotspot >>> https://bugs.openjdk.java.net/browse/JDK-7165611 >>> >>> 8001931 build-infra: Apply consistent formatting/indentation to >>> new build-infra files >>> https://bugs.openjdk.java.net/browse/JDK-8001931 >>> >>> During the JDK8 merge process some of the changes from 7165611 were not >>> properly adjusted to meet the new whitespace/indent policy implemented >>> by 8001931. This changeset fixes those style issues. >>> >>> Testing: >>> - JPRT JDK8 forest build and test on all platforms (in process) >> > From daniel.daugherty at oracle.com Wed Oct 23 13:59:55 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 23 Oct 2013 14:59:55 -0600 Subject: code review round 0 for MacOS X FDS whitespace/indent fixes (8027117) In-Reply-To: <5268368B.1090609@oracle.com> References: <526830FA.1080104@oracle.com> <5268368B.1090609@oracle.com> Message-ID: <526838CB.1070906@oracle.com> Adding back the other two aliases... Coleen, Thanks for the fast review! Dan On 10/23/13 2:50 PM, Coleen Phillimore wrote: > > Looks fine. > Coleen > > On 10/23/2013 4:26 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have some MacOS X Full Debug Symbols whitespace/indent fixes. >> Here is the JDK8/HSX-25 webrev URL: >> >> OpenJDK: >> http://cr.openjdk.java.net/~dcubed/fds_revamp/8027117-webrev/0-jdk8/ >> Internal: >> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/8027117-webrev/0-jdk8/ >> >> Because these are whitespace/indent fixes, only the "Cdiffs" and >> "Udiffs" links show all the changes. >> >> This webrev includes changes for the follow repos: >> >> jdk8 >> jdk8/jdk >> >> Gory details are below... >> >> As always, comments, questions and suggestions are welcome. >> >> Dan >> >> >> The fixes for the following two bugs hit JDK8 at the same time, but >> came up via different sub-baselines: >> >> 7165611 implement Full Debug Symbols on MacOS X hotspot >> https://bugs.openjdk.java.net/browse/JDK-7165611 >> >> 8001931 build-infra: Apply consistent formatting/indentation to >> new build-infra files >> https://bugs.openjdk.java.net/browse/JDK-8001931 >> >> During the JDK8 merge process some of the changes from 7165611 were not >> properly adjusted to meet the new whitespace/indent policy implemented >> by 8001931. This changeset fixes those style issues. >> >> Testing: >> - JPRT JDK8 forest build and test on all platforms (in process) > From jan.lahoda at oracle.com Wed Oct 23 14:03:28 2013 From: jan.lahoda at oracle.com (jan.lahoda at oracle.com) Date: Wed, 23 Oct 2013 21:03:28 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20131023210339.D1CA0626A7@hg.openjdk.java.net> Changeset: abc3eaccba73 Author: jlahoda Date: 2013-10-23 23:02 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/abc3eaccba73 8027191: Fix for JDK-8026861 refers to an incorrect bug number Summary: Reverting changeset b05db8c815e8, so that it can be applied again with a correct bug number Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java - test/tools/javac/T8019486/WrongLNTForLambdaTest.java + test/tools/javac/T8019486/WrongLVTForLambdaTest.java Changeset: 864dafc5ab7a Author: jlahoda Date: 2013-10-23 07:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/864dafc5ab7a 8026861: Wrong LineNumberTable for variable declarations in lambdas Summary: Setting or correcting positions for many trees produced by LambdaToMethod. Reviewed-by: vromero, rfield ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/T8019486/WrongLNTForLambdaTest.java - test/tools/javac/T8019486/WrongLVTForLambdaTest.java From mike.duigou at oracle.com Wed Oct 23 14:35:33 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 23 Oct 2013 21:35:33 +0000 Subject: hg: jdk8/tl/jdk: 8024688: further split Map and ConcurrentMap defaults eliminating looping from Map defaults, Map.merge fixes and doc fixes. Message-ID: <20131023213600.7E86A626AD@hg.openjdk.java.net> Changeset: f4129fcfacdc Author: mduigou Date: 2013-10-23 14:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4129fcfacdc 8024688: further split Map and ConcurrentMap defaults eliminating looping from Map defaults, Map.merge fixes and doc fixes. Reviewed-by: psandoz, dholmes ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/concurrent/ConcurrentMap.java ! test/java/util/Map/Defaults.java From robert.field at oracle.com Wed Oct 23 15:17:34 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Wed, 23 Oct 2013 22:17:34 +0000 Subject: hg: jdk8/tl/jdk: 8025868: Several lang/LMBD JCK tests fail with java.lang.BootstrapMethodError Message-ID: <20131023221756.4D2C0626B2@hg.openjdk.java.net> Changeset: d9d3705a992f Author: rfield Date: 2013-10-23 15:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d9d3705a992f 8025868: Several lang/LMBD JCK tests fail with java.lang.BootstrapMethodError Summary: Wildcard marker interfaces can cause duplicate implemented interfaces in generated lambda class Reviewed-by: briangoetz ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + test/java/lang/invoke/lambda/DupIntf.java From mandy.chung at oracle.com Wed Oct 23 16:02:09 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 23 Oct 2013 16:02:09 -0700 Subject: jmx-dev RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: <5267DDFC.4060607@oracle.com> References: <526681FD.90604@oracle.com> <5266DA56.6050609@oracle.com> <52678280.1070004@oracle.com> <4972770C-A8BB-40A0-9BB8-885AA6B707BC@oracle.com> <52678509.2020002@oracle.com> <68F92D47-E916-426B-8D6A-2EA48302053D@oracle.com> <5267C3AD.5050306@oracle.com> <5267C74F.2010302@oracle.com> <5267CC00.7080509@oracle.com> <5267DDFC.4060607@oracle.com> Message-ID: <52685571.1090407@oracle.com> On 10/23/2013 7:32 AM, Jaroslav Bachorik wrote: > I've updated the patch. The GC is called even before the first attempt > to get the pool memory usage and System.gc() is used to perform GC (no > MXBean checks). This should simplify the change a bit. > > http://cr.openjdk.java.net/~jbachorik/8020467/webrev.02 This change is okay. It will force GC once per each memory pool that supports usage threshold (I think 3 memory pools) which is not a huge issue. Perhaps a more reliable option is to make it an othervm test and allocating large object and calling GC once before the verification. Mandy From kumar.x.srinivasan at oracle.com Wed Oct 23 18:08:12 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 24 Oct 2013 01:08:12 +0000 Subject: hg: jdk8/tl/langtools: 8026936: Initialize LamdbaToMethod lazily and as required Message-ID: <20131024010818.99367626BD@hg.openjdk.java.net> Changeset: 31fe30e2deac Author: ksrini Date: 2013-10-23 15:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/31fe30e2deac 8026936: Initialize LamdbaToMethod lazily and as required Reviewed-by: jjg, rfield Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java From david.holmes at oracle.com Wed Oct 23 19:31:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Oct 2013 12:31:07 +1000 Subject: RR(XS): JDK-8026950 Nits in agent ps_proc.c file breaks compilation of open hotspot In-Reply-To: <526798FC.70809@oracle.com> References: <5264F8FC.7040307@oracle.com> <52673660.8080905@oracle.com> <526798FC.70809@oracle.com> Message-ID: <5268866B.7090204@oracle.com> On 23/10/2013 7:38 PM, Dmitry Samersoff wrote: > David, > > SA doesn't support live process debugging on OSX, so this file is not > compiled during libsaproc.dynlib build. > > But yes, if I enable compilation of this file during OSX build it fails > as well, so this fix is required to go froward. Thanks for clarifications that this code is not used on OSX - so another case of the OSX port blindly copying linux code. I wonder how many more such issues remain to be uncovered. :( > May I consider you as a reviewer? Yes as I said in my email "Reviewed" :) David > -Dmitry > > > On 2013-10-23 06:37, David Holmes wrote: >> On 21/10/2013 7:50 PM, Dmitry Samersoff wrote: >>> Hi Everybody, >>> >>> Please review a small fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8026950/webrev.01/ >> >> I don't understand why this is only a compile error on "open hotspot"? >> PT_CONTINUE seems to be the necessary value for OSX and other BSD >> systems. Do some systems have an alias in place? >> >> Reviewed. >> >> David >> >>> -Dmitry >>> > > From eric.mccorkle at oracle.com Wed Oct 23 20:21:23 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Thu, 24 Oct 2013 03:21:23 +0000 Subject: hg: jdk8/tl/langtools: 8006732: support correct bytecode storage of type annotations in multicatch Message-ID: <20131024032129.B1B0B626C2@hg.openjdk.java.net> Changeset: d2fa3f7e964e Author: emc Date: 2013-10-23 23:20 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d2fa3f7e964e 8006732: support correct bytecode storage of type annotations in multicatch Summary: Fix issue with annotations being added before attribution, which causes multicatch not to work right and several tests to fail. Reviewed-by: jfranck, jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.java ! test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.out ! test/tools/javac/annotations/typeAnnotations/newlocations/MultiCatch.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java From eric.mccorkle at oracle.com Wed Oct 23 22:27:49 2013 From: eric.mccorkle at oracle.com (eric.mccorkle at oracle.com) Date: Thu, 24 Oct 2013 05:27:49 +0000 Subject: hg: jdk8/tl/langtools: 8023682: Incorrect attributes emitted for anonymous class declaration Message-ID: <20131024052756.77835626C5@hg.openjdk.java.net> Changeset: 119747cd9f25 Author: emc Date: 2013-10-24 01:27 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/119747cd9f25 8023682: Incorrect attributes emitted for anonymous class declaration Summary: Cause javac to emit type annotations on new instruction as well as anonymous class supertype for annotated anonymous classes. Reviewed-by: jjg, jfranck ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/annotations/typeAnnotations/failures/TypeOnAnonClass.java + test/tools/javac/annotations/typeAnnotations/failures/TypeOnAnonClass.out ! test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DeclarationAnnotation.out ! test/tools/javac/annotations/typeAnnotations/newlocations/AnonymousClass.java From dan.xu at oracle.com Wed Oct 23 22:31:31 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Thu, 24 Oct 2013 05:31:31 +0000 Subject: hg: jdk8/tl/jdk: 7122887: JDK ignores Gnome3 proxy settings Message-ID: <20131024053218.77ACD626C6@hg.openjdk.java.net> Changeset: c9562ac9b812 Author: dxu Date: 2013-10-23 22:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9562ac9b812 7122887: JDK ignores Gnome3 proxy settings Summary: Fix GConf and add to use GProxyResolver to handle network proxy resolution Reviewed-by: chegar ! src/solaris/native/sun/net/spi/DefaultProxySelector.c ! test/java/net/ProxySelector/SystemProxies.java From staffan.larsen at oracle.com Thu Oct 24 00:55:02 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 24 Oct 2013 07:55:02 +0000 Subject: hg: jdk8/tl/jdk: 8009681: TEST_BUG: MethodExitReturnValuesTest.java may fail when there are unexpected background threads Message-ID: <20131024075601.D6FB4626CC@hg.openjdk.java.net> Changeset: e6bc0dca294b Author: sla Date: 2013-10-15 12:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6bc0dca294b 8009681: TEST_BUG: MethodExitReturnValuesTest.java may fail when there are unexpected background threads Reviewed-by: sla, allwin Contributed-by: mikael.auno at oracle.com ! test/com/sun/jdi/MethodEntryExitEvents.java ! test/com/sun/jdi/MethodExitReturnValuesTest.java From erik.joelsson at oracle.com Thu Oct 24 01:05:43 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 24 Oct 2013 10:05:43 +0200 Subject: code review round 0 for MacOS X FDS whitespace/indent fixes (8027117) In-Reply-To: <526830FA.1080104@oracle.com> References: <526830FA.1080104@oracle.com> Message-ID: <5268D4D7.80207@oracle.com> Daniel, Looks good to me. /Erik On 2013-10-23 22:26, Daniel D. Daugherty wrote: > Greetings, > > I have some MacOS X Full Debug Symbols whitespace/indent fixes. > Here is the JDK8/HSX-25 webrev URL: > > OpenJDK: > http://cr.openjdk.java.net/~dcubed/fds_revamp/8027117-webrev/0-jdk8/ > Internal: > http://javaweb.us.oracle.com/~ddaugher/fds_revamp/8027117-webrev/0-jdk8/ > > Because these are whitespace/indent fixes, only the "Cdiffs" and > "Udiffs" links show all the changes. > > This webrev includes changes for the follow repos: > > jdk8 > jdk8/jdk > > Gory details are below... > > As always, comments, questions and suggestions are welcome. > > Dan > > > The fixes for the following two bugs hit JDK8 at the same time, but > came up via different sub-baselines: > > 7165611 implement Full Debug Symbols on MacOS X hotspot > https://bugs.openjdk.java.net/browse/JDK-7165611 > > 8001931 build-infra: Apply consistent formatting/indentation to > new build-infra files > https://bugs.openjdk.java.net/browse/JDK-8001931 > > During the JDK8 merge process some of the changes from 7165611 were not > properly adjusted to meet the new whitespace/indent policy implemented > by 8001931. This changeset fixes those style issues. > > Testing: > - JPRT JDK8 forest build and test on all platforms (in process) From magnus.ihse.bursie at oracle.com Thu Oct 24 01:12:55 2013 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 Oct 2013 10:12:55 +0200 Subject: code review round 0 for MacOS X FDS whitespace/indent fixes (8027117) In-Reply-To: <526830FA.1080104@oracle.com> References: <526830FA.1080104@oracle.com> Message-ID: <5268D687.6000406@oracle.com> On 2013-10-23 22:26, Daniel D. Daugherty wrote: > Greetings, > > I have some MacOS X Full Debug Symbols whitespace/indent fixes. > Here is the JDK8/HSX-25 webrev URL: > > OpenJDK: > http://cr.openjdk.java.net/~dcubed/fds_revamp/8027117-webrev/0-jdk8/ > Internal: > http://javaweb.us.oracle.com/~ddaugher/fds_revamp/8027117-webrev/0-jdk8/ Looks good. Thank you for taking the time to keep the indentation consistent! /Magnus From staffan.larsen at oracle.com Thu Oct 24 01:54:13 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 24 Oct 2013 10:54:13 +0200 Subject: RFR 8014506: Test for Jdp (Java Discovery Protocol) feature In-Reply-To: <5267C65A.9060602@oracle.com> References: <51A31867.9080602@oracle.com> <51CAC09B.7070706@oracle.com> <7E2E50A8-1FB1-429B-8AAB-94863C215623@oracle.com> <51D56A11.5030600@oracle.com> <5214AC0A.4010603@oracle.com> <70F043F0-9F19-4761-B175-1D6652B5A146@oracle.com> <3B20B5DC-9E92-4EB6-97FF-0F2D2B4E1E10@oracle.com> <52244497.8010902@oracle.com> <5267C65A.9060602@oracle.com> Message-ID: <4EDB8911-E772-4B13-B0EB-AA90C729A49A@oracle.com> Alex, test/sun/management/jdp/README Thanks for providing a README! References to JDK-7169888 seem incorrect to me. L8: "written by" appears twice. L11: "defautl" -> "default" test/lib/testlibrary/jdk/testlibrary/PortFinder.java This should be coordinated with the review for 8022229 which contains the same code in a different testlibrary class: http://cr.openjdk.java.net/~ykantser/8022229/webrev.01/test/lib/testlibrary/jdk/testlibrary/Utils.java.html test/sun/management/jdp/7169888/JdpClient.java test/sun/management/jdp/7169888/JdpDoSomething.java test/sun/management/jdp/7169888/JdpTest.sh test/sun/management/jdp/7169888/JdpUnitTest.java These were moved to a subdirectory, but these tests have nothing to do with bug 7169888, so why that name? In any case we should avoid naming test directories after bug ids, and instead use a descriptive name. test/sun/management/jdp/ClientConnection.java No comments. test/sun/management/jdp/DefaultLauncher.java Can "@library ../../../lib/testlibrary" be replaced by "@library /lib/testlibrary" ? test/sun/management/jdp/OffLauncher.java Can "@library ../../../lib/testlibrary" be replaced by "@library /lib/testlibrary" ? test/sun/management/jdp/SpecificJdpAddressLauncher.java Can "@library ../../../lib/testlibrary" be replaced by "@library /lib/testlibrary" ? test/sun/management/jdp/DynamicLauncher.java No comments. test/sun/management/jdp/JdpOffTest.java For the future: it is customary that the file containing the jtreg directives be named xxxTest.java, and supporting files not ending in Test. test/sun/management/jdp/JdpOnTest.java For the future: it is customary that the file containing the jtreg directives be named xxxTest.java, and supporting files not ending in Test. test/sun/management/jdp/JdpTest.java No comments. test/sun/management/jdp/JdpTestUtil.java No comments. test/sun/management/jdp/JdpTestUtilTest.java test/sun/management/jdp/PacketTest.java test/sun/management/jdp/PortAlreadyInUseTest.java These are tests for the tests. But where are the tests for the tests for the tests? :) Not reviewed. Thanks, /Staffan On 23 okt 2013, at 14:51, Alex Schenkman wrote: > Hi Staffan, > > Any chance you can review this again? > http://cr.openjdk.java.net/~dsamersoff/sponsorship/aschenkman/8014506/ > > Thanks in advance! > > On 2013-09-02 09:56, Alex Schenkman wrote: >> I've added a README file and moved Dmitry's tests into its own folder, to address the comments below. >> http://cr.openjdk.java.net/~dsamersoff/sponsorship/aschenkman/8014506/webrev.03/ >> >> On 2013-08-21 20:10, Staffan Larsen wrote: >>> A couple of more comments: >>> >>> - It was a little too hard to figure out exactly how the tests worked: who is sending JDP packets? who is listening for them? who is launching the tests? Perhaps it would make sense to add a small readme which explains how it all fits together? >>> >>> - There are already some JDP tests in that directory which are also made up of a couple of files. Mixing them together makes it hard to see which files belong to which set of tests. Maybe we should have distinct subfolders for the sets? >>> >>> - There is also the question of how much overlap there are between your tests and the already existing tests. It would be preferable to have no overlap. Perhaps some of the existing shell-based tests can be subsumed by your java-based tests? >>> >>> Thanks, >>> /Staffan >>> >>> On 21 aug 2013, at 18:15, Staffan Larsen wrote: >>> >>>> Alex, >>>> >>>> This looks a lot better than the previous version. Thanks for cleaning things up. Below are a couple of comments: >>>> >>>> - Use of "package" is discouraged for jtreg test: http://openjdk.java.net/jtreg/faq.html#question4.9 >>>> >>>> - Maybe change name of SpecificLauncher.java to SpecificJdpAddressLauncher.java? >>>> >>>> - The constructor and onSocketTimeOut() in JdpOffTest.java has wrong indentation. >>>> >>>> - The comment for JdpOffTest.shouldContinue() has weird indentation. >>>> >>>> - How does one run PacketTest.java? It looks like a TestNG test, but I couldn't get jtreg to run it. >>>> >>>> - Why the mix of standard jtreg tests and TestNG tests? >>>> >>>> - nit: somewhat non-standard formatting with spaces inside parens: socket.receive( datagram ); >>>> >>>> - nit: statements should be on a new line: >>>> if ( hasTestLivedLongEnough() ) { shutdown(); } >>>> >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 21 aug 2013, at 14:01, Alex Schenkman wrote: >>>> >>>>> Staffan, do you think you can take another look this? >>>>> Thanks! >>>>> >>>>> On 2013-07-04 14:26, Alex Schenkman wrote: >>>>>> Thanks Staffan for your comments. >>>>>> >>>>>> The indentation is corrected in all files, sorry about that. >>>>>> >>>>>> About the racing condition in PortFinder.java, you are absolutely right, there is no warranty that this port will be free. >>>>>> I do not know a better way to do this. Any suggestions? >>>>>> On the other hand, even if this fails every now and then, it will work most of the times and it is better than what we have today. >>>>>> I have added better comments in PortFinder to reflect the problem. >>>>>> >>>>>> The new webrev is here [1], at the same address than before. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> [1] http://cr.openjdk.java.net/~dsamersoff/8014506/webrev.01/ >>>>>> >>>>>> PS: >>>>>> PortFinder.java, line 37: >>>>>> There is an extra

tag that should be removed. >>>>>> >>>>>> >>>>>> >>>>>> On 2013-06-26 13:54, Staffan Larsen wrote: >>>>>>> test/lib/testlibrary/jdk/testlibrary/PortFinder.java: >>>>>>> >>>>>>> - This looks racy to me. There is no guarantee that the port will still be available after the call to close(). >>>>>>> - Missing copyright notice. >>>>>>> - In comment "on of them" -> "one of them" >>>>>>> >>>>>>> test/sun/management/jdp/ClientConnection.java: >>>>>>> >>>>>>> - broken indentation >>>>>>> - inconsistent spacing in method calls. Sometime "joinGroup(address);" and sometimes "setSoTimeout( msTimeOut );". Should be without spaces. >>>>>>> >>>>>>> test/sun/management/jdp/DynamicLauncher.java: >>>>>>> >>>>>>> - type: binded -> bound >>>>>>> - inconsistent spacing in method calls >>>>>>> >>>>>>> test/sun/management/jdp/JdpOffTest.java >>>>>>> >>>>>>> - broken indentation >>>>>>> >>>>>>> test/sun/management/jdp/JdpTestUtil.java >>>>>>> >>>>>>> - broken indentation >>>>>>> >>>>>>> >>>>>>> I stopped reading here. Can we get these basic things fixed before the next review round, please? >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>> On 26 jun 2013, at 12:21, Dmitry Samersoff wrote: >>>>>>> >>>>>>>> Nils, >>>>>>>> >>>>>>>> I'm sponsoring this push but don't see any review replies in this thread. >>>>>>>> >>>>>>>> Webrev refreshed against latest tl is here: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8014506/webrev.01/ >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2013-05-27 12:25, Alex Schenkman wrote: >>>>>>>>> Please review these tests for the Jdp protocol. >>>>>>>>> >>>>>>>>> There are three cases: >>>>>>>>> 1) Jdp is off. >>>>>>>>> 2) Jdp is on and using default address and port. >>>>>>>>> 3) Jdp is on using custom address and port. >>>>>>>>> >>>>>>>>> Tests: http://cr.openjdk.java.net/~nloodin/8014506/webrev.00/ >>>>>>>>> >>>>>>>>> Jdp feature enhancement: https://jbs.oracle.com/bugs/browse/JDK-8002048 >>>>>>>>> JDK CCC: http://ccc.us.oracle.com/8002048 >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks in advance! >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Alex Schenkman >>>>>>>>> Java VM SQE Stockholm >>>>>>>>> >>>>>>>> -- >>>>>>>> Dmitry Samersoff >>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>> * I would love to change the world, but they won't give me the sources. >>>>>> >>>>>> -- >>>>>> Alex Schenkman >>>>>> Java VM SQE Stockholm >>>>> >>>>> -- >>>>> Alex Schenkman >>>>> Java VM SQE Stockholm >>>> >>> >> >> -- >> Alex Schenkman >> Java VM SQE Stockholm > > -- > Alex Schenkman > Java VM SQE Stockholm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131024/7440f88d/attachment-0001.html From staffan.larsen at oracle.com Thu Oct 24 03:01:01 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 24 Oct 2013 10:01:01 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes Message-ID: <20131024100114.4696C626D0@hg.openjdk.java.net> Changeset: e64f1fe9756b Author: farvidsson Date: 2013-10-24 10:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e64f1fe9756b 8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes Summary: Rewrite of the getLoadedClasses() method implementation to include anonymous classes. Reviewed-by: coleenp, sspitsyn ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp From alan.bateman at oracle.com Thu Oct 24 05:33:45 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Oct 2013 12:33:45 +0000 Subject: hg: jdk8/tl/jdk: 8026344: j.u.c.a *Adder and *Accumulator extend a package private class that is Serializable Message-ID: <20131024123510.1759D626D3@hg.openjdk.java.net> Changeset: 700d62b8d9cc Author: alanb Date: 2013-10-24 13:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/700d62b8d9cc 8026344: j.u.c.a *Adder and *Accumulator extend a package private class that is Serializable Reviewed-by: rriggs, psandoz, chegar Contributed-by: dl at cs.oswego.edu, alan.bateman at oracle.com ! src/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java ! src/share/classes/java/util/concurrent/atomic/DoubleAdder.java ! src/share/classes/java/util/concurrent/atomic/LongAccumulator.java ! src/share/classes/java/util/concurrent/atomic/LongAdder.java + test/java/util/concurrent/atomic/Serial.java From daniel.daugherty at oracle.com Thu Oct 24 05:45:44 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 24 Oct 2013 06:45:44 -0600 Subject: code review round 0 for MacOS X FDS whitespace/indent fixes (8027117) In-Reply-To: <5268D4D7.80207@oracle.com> References: <526830FA.1080104@oracle.com> <5268D4D7.80207@oracle.com> Message-ID: <52691678.3040502@oracle.com> Erik, Thanks for the review! Dan On 10/24/13 2:05 AM, Erik Joelsson wrote: > Daniel, > > Looks good to me. > > /Erik > > On 2013-10-23 22:26, Daniel D. Daugherty wrote: >> Greetings, >> >> I have some MacOS X Full Debug Symbols whitespace/indent fixes. >> Here is the JDK8/HSX-25 webrev URL: >> >> OpenJDK: >> http://cr.openjdk.java.net/~dcubed/fds_revamp/8027117-webrev/0-jdk8/ >> Internal: >> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/8027117-webrev/0-jdk8/ >> >> Because these are whitespace/indent fixes, only the "Cdiffs" and >> "Udiffs" links show all the changes. >> >> This webrev includes changes for the follow repos: >> >> jdk8 >> jdk8/jdk >> >> Gory details are below... >> >> As always, comments, questions and suggestions are welcome. >> >> Dan >> >> >> The fixes for the following two bugs hit JDK8 at the same time, but >> came up via different sub-baselines: >> >> 7165611 implement Full Debug Symbols on MacOS X hotspot >> https://bugs.openjdk.java.net/browse/JDK-7165611 >> >> 8001931 build-infra: Apply consistent formatting/indentation to >> new build-infra files >> https://bugs.openjdk.java.net/browse/JDK-8001931 >> >> During the JDK8 merge process some of the changes from 7165611 were not >> properly adjusted to meet the new whitespace/indent policy implemented >> by 8001931. This changeset fixes those style issues. >> >> Testing: >> - JPRT JDK8 forest build and test on all platforms (in process) > From daniel.daugherty at oracle.com Thu Oct 24 05:47:46 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 24 Oct 2013 06:47:46 -0600 Subject: code review round 0 for MacOS X FDS whitespace/indent fixes (8027117) In-Reply-To: <5268D687.6000406@oracle.com> References: <526830FA.1080104@oracle.com> <5268D687.6000406@oracle.com> Message-ID: <526916F2.7090006@oracle.com> On 10/24/13 2:12 AM, Magnus Ihse Bursie wrote: > On 2013-10-23 22:26, Daniel D. Daugherty wrote: >> Greetings, >> >> I have some MacOS X Full Debug Symbols whitespace/indent fixes. >> Here is the JDK8/HSX-25 webrev URL: >> >> OpenJDK: >> http://cr.openjdk.java.net/~dcubed/fds_revamp/8027117-webrev/0-jdk8/ >> Internal: >> http://javaweb.us.oracle.com/~ddaugher/fds_revamp/8027117-webrev/0-jdk8/ > > Looks good. Thank you for taking the time to keep the indentation > consistent! > > /Magnus Thanks for the review! And thank you for pointing me at the thread that discussed the new makefile guidelines. Dan From fredrik.arvidsson at oracle.com Thu Oct 24 06:11:02 2013 From: fredrik.arvidsson at oracle.com (Fredrik Arvidsson) Date: Thu, 24 Oct 2013 15:11:02 +0200 Subject: RFR (XXS) 8025576: ProblemList.txt updates to reintroduce tests that was excluded Message-ID: <52691C66.5090308@oracle.com> Hi Please help me review the following small change: Bug: https://bugs.openjdk.java.net/browse/JDK-8025576 Webrev: http://cr.openjdk.java.net/~farvidsson/8025576/webrev.00/index.html /Fredrik From Alan.Bateman at oracle.com Thu Oct 24 06:17:43 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Oct 2013 14:17:43 +0100 Subject: RFR (XXS) 8025576: ProblemList.txt updates to reintroduce tests that was excluded In-Reply-To: <52691C66.5090308@oracle.com> References: <52691C66.5090308@oracle.com> Message-ID: <52691DF6.4030200@oracle.com> On 24/10/2013 14:11, Fredrik Arvidsson wrote: > Hi > > Please help me review the following small change: > Bug: https://bugs.openjdk.java.net/browse/JDK-8025576 > Webrev: > http://cr.openjdk.java.net/~farvidsson/8025576/webrev.00/index.html > > > /Fredrik This looks okay to me, the change seems to be hotspot-rt. However, where you are planning to push this? If you push it to hotspot-rt/jdk then it's okay, it's in the same forest as the fix. On the other hand, if you push it to jdk8/tl/jdk then I assume we will have test failures until the hotspot fix gets into master and down to jdk8/tl. -Alan From rob.mckenna at oracle.com Thu Oct 24 06:28:21 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Thu, 24 Oct 2013 13:28:21 +0000 Subject: hg: jdk8/tl/jdk: 8024521: (process) Async close issues with Process InputStream Message-ID: <20131024132846.2F1B3626D6@hg.openjdk.java.net> Changeset: e2ec05b2ed94 Author: igerasim Date: 2013-10-23 15:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2ec05b2ed94 8024521: (process) Async close issues with Process InputStream Reviewed-by: psandoz, martin, alanb, robm ! src/solaris/classes/java/lang/UNIXProcess.java.bsd ! src/solaris/classes/java/lang/UNIXProcess.java.linux + test/java/lang/Runtime/exec/CloseRace.java From yekaterina.kantserova at oracle.com Thu Oct 24 06:57:03 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 24 Oct 2013 15:57:03 +0200 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <0805924E-F724-477D-B4C2-742ACB58075E@oracle.com> References: <525D4490.3070506@oracle.com> <526546FD.5020909@oracle.com> <52663633.2080206@oracle.com> <0805924E-F724-477D-B4C2-742ACB58075E@oracle.com> Message-ID: <5269272F.6090907@oracle.com> Hi, I've done following big changes after the Staffan's review: - ported JDKToolLauncher, JDKToolFinder, Plattform from hotspot testlibrary (http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot) for re-using in ToolConfig - changed "verifiy output form jps, jstat"-methods to ignore warnings from VM - tools will be launched without -vmoptions plusmade fixes for all minor comments. If it's a good idea to push testlibrary changes separately I can make a separate patch for them. Webrev: http://cr.openjdk.java.net/~ykantser/8022229/webrev.02/ Primal bug: https://bugs.openjdk.java.net/browse/JDK-8022229 Similar bugs: https://bugs.openjdk.java.net/browse/JDK-8019630 https://bugs.openjdk.java.net/browse/JDK-6636094 https://bugs.openjdk.java.net/browse/JDK-6543979 Thanks, Katja On 10/23/2013 12:55 PM, Staffan Larsen wrote: > test/lib/testlibrary/jdk/testlibrary/Asserts.java > Same code as already exists in the hotspot testlibrary. > No further comments. > > > test/lib/testlibrary/jdk/testlibrary/ProcessThread.java > L33: stating -> starting > L66: staring -> starting > > > test/lib/testlibrary/jdk/testlibrary/TestThread.java > This code comes from an internal test library. > No further comments. > > > test/lib/testlibrary/jdk/testlibrary/Utils.java > No comments. > > > test/lib/testlibrary/jdk/testlibrary/XRun.java > This code comes from an internal test library. > No further comments. > > > test/sun/tools/jstatd/JstatGcutilParser.java > The parse() method could be made more robust by discarding any lines > that come before the header lines. This can happen if the JVM outputs > a warning message for some reason before running jstat. > I don't like the special-case for the CCS column in verify() - took > me a while to find it. Should we add a new enum called > PERCENTAGE_OR_DASH to handle that instead? > > L67: getType() should be private. > > > test/sun/tools/jstatd/JstatdHelper.java: > L54: Does verifyJpsOutput() work correctly with output of the form: > > 1234 -- main class information unavailable > 1235 -- process information unavailable > > Also: same comment here as for JstatGcutilParser.java: sometimes the > JVM outputs warning messages before the output from the tool. > > L46: "attach" is probably not the best way to describe the operation > of jps. It does not attach to the process, it merely lists the running > processes. Perhaps runJps() is a better name? > > > test/sun/tools/jstatd/TestJstatdDefaults.java > test/sun/tools/jstatd/TestJstatdExternalRegistry.java > test/sun/tools/jstatd/TestJstatdPort.java > test/sun/tools/jstatd/TestJstatdPortAndServer.java > test/sun/tools/jstatd/TestJstatdServer.java > No comments. > > > test/sun/tools/jstatd/TestJstatdUsage.java > Same comment here as for JstatGcutilParser.java: sometimes the JVM > outputs warning messages before the output from the tool. > > > test/sun/tools/jstatd/ToolConfig.java > ToolConfig + Utils.get(Forward)VmOptions() seem to be doing similar > things to JDKToolLauncher in the hotspot testlibrary. It is > unfortunate if we have two ways to do similar things in the two > different testlibraries. Would it be possible to reuse the hotspot > code here instead? > > You have also changed the test. Previously the tools were not > launched with the jtreg -vmoptions (test.vm.opts), whereas now they > will be. Is this intentional? > > > General comments: > > Can't we do: > * @library /lib/testlibrary > instead of > * @library ../../../lib/testlibrary > ? > > It seems that at least some of the functionality should be reused for > re-writing the jstat and jps tests as well. I guess we can look at > that at a later time, though. > > While I applaud the move from shell scripts to Java code, I can't > shake the feeling that the shell scripts were easier to read and > follow. The Java code is much more verbose and spread out over > multiple helpers and libraries, making it harder to grasp. That may be > the price we have to pay, though. > > > Thanks, > /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131024/6f12d3ef/attachment-0001.html From jaroslav.bachorik at oracle.com Thu Oct 24 07:01:43 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 24 Oct 2013 16:01:43 +0200 Subject: jmx-dev RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: <52685571.1090407@oracle.com> References: <526681FD.90604@oracle.com> <5266DA56.6050609@oracle.com> <52678280.1070004@oracle.com> <4972770C-A8BB-40A0-9BB8-885AA6B707BC@oracle.com> <52678509.2020002@oracle.com> <68F92D47-E916-426B-8D6A-2EA48302053D@oracle.com> <5267C3AD.5050306@oracle.com> <5267C74F.2010302@oracle.com> <5267CC00.7080509@oracle.com> <5267DDFC.4060607@oracle.com> <52685571.1090407@oracle.com> Message-ID: <52692847.1030806@oracle.com> Hi Mandy, On 24.10.2013 01:02, Mandy Chung wrote: > > On 10/23/2013 7:32 AM, Jaroslav Bachorik wrote: >> I've updated the patch. The GC is called even before the first attempt >> to get the pool memory usage and System.gc() is used to perform GC (no >> MXBean checks). This should simplify the change a bit. >> >> http://cr.openjdk.java.net/~jbachorik/8020467/webrev.02 > > This change is okay. It will force GC once per each memory pool that > supports usage threshold (I think 3 memory pools) which is not a huge > issue. Perhaps a more reliable option is to make it an othervm test and > allocating large object and calling GC once before the verification. Running it as othervm might improve repeatbility but I don't quite follow the trick with large object. That would be effective for the oldgen pools only, I suppose? There were concerns raised during the review that other pools might be susceptible to the same timing related problems (theoretically). So, if you don't feel strongy about it I would leave the rest of the test as it is - that is calling System.gc() before checking the pool thresholds. -JB- > > Mandy From jaroslav.bachorik at oracle.com Thu Oct 24 07:10:12 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 24 Oct 2013 16:10:12 +0200 Subject: [ping][ping] Re: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <52562FF5.5060304@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> <5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com> <5231DE69.7090309@oracle.com> <523B0B30.4020003@oracle.com> <5252C1B6.2060904@oracle.com> <52537F36.8020001@oracle.com> <5253ED95.20706@oracle.com> <52552EBA.4060308@oracle.com> <52553EAD.4040506@oracle.com> <52562FF5.5060304@oracle.com> Message-ID: <52692A44.9050004@oracle.com> Hi David, On 10.10.2013 06:41, David Holmes wrote: > On 9/10/2013 9:31 PM, Jaroslav Bachorik wrote: >> On 9.10.2013 12:23, David Holmes wrote: >>> Jaroslav, >>> >>> Thanks for the details description of changes - much appreciated. >>> >>> There is a lot to digest in there. :) >> >> Yep, it started as a simple fix :/ >> >>> >>> It isn't obvious to me why these tests require a full JDK? >> >> IDK, LocalManagementTest.sh was listed as one requiring full JDK. Its >> requirements are the same as the ones of CustomLauncherTest.sh (now >> *.java) so it seemed logical to list it there too. > > Ah! Now I see it - it uses tools.jar which implies a full JDK. > >>> >>> I don't quite follow the libjvm lookup logic - I would expect that you >>> would always want to test the libjvm that is currently running - though >>> it is hard to determine that. >> >> I'm afraid I can't be of much assistance here - I just took what was in >> the *.sh version and converted it to *.java. > > Okay. I expect this will need revisiting at some point. So, does this mean "ok, go"? Thanks, -JB- > > Thanks, > David > ----- > > >> -JB- >> >>> >>> Thanks, >>> David >>> >>> On 8/10/2013 9:33 PM, Jaroslav Bachorik wrote: >>>> On 8.10.2013 05:42, David Holmes wrote: >>>>> Jaroslav, >>>>> >>>>> Can you summarise the changes please? With the conversion to Java and >>>>> the infrastructure additions I can't tell what is actually fixing the >>>>> original timeout issue :) >>>> >>>> The timeout was most caused by using the same file for communication >>>> between java processes in more test cases. When those test cases were >>>> run in parallel the file got rewritten silently and some of the tests >>>> could end up trying to connect to incorrect port in the target >>>> application. I was able to reproduce the timeout by interleaving the >>>> test runs for CustomLauncherTest.sh and LocalManagementTest.sh and >>>> adding an artificial delay to CusteomLauncherTest.sh to allow >>>> LocalManagementTest.sh to change the port in the file. >>>> >>>> While it could be fixed by using a different file for each test case I >>>> took the liberty of converting the shell tests to java tests. This >>>> allows me to remove the communication file and, in the end, make the >>>> tests more robust. >>>> >>>> CustomLauncherTest.java and LocalManagementTest.java are the tests >>>> converted from shell to java. I decided to convert >>>> LocalManagementTest.sh as well because it has the same problems as the >>>> CustomLauncherTest.sh. >>>> >>>> The changes in the testlibrary are about introducing new methods >>>> allowing the tests easily start a process and wait for a certain text >>>> appearing in its stdout/stderr. Using these methods the caller can wait >>>> till the callee is fully initialized and eg. ready to accept >>>> connections. >>>> >>>> The changes in launchers make the launchers actually executable + I am >>>> adding a linux-amd64 launcher (I needed that one to work on the changes >>>> locally and thought it might be nice to have one more platform covered >>>> by the test). >>>> >>>> I've update the webrev to include changes to LocalManagementTest and >>>> TEST.groups (both of those tests require JDK) - >>>> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.05 >>>> >>>> -JB- >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 8/10/2013 12:14 AM, Jaroslav Bachorik wrote: >>>>>> On 19.9.2013 16:33, Jaroslav Bachorik wrote: >>>>>>> The updated webrev: >>>>>>> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.03 >>>>>>> >>>>>>> I've moved some of the functionality to the testlibrary. >>>>>>> >>>>>>> -JB - >>>>>>> >>>>>>> On 12.9.2013 17:31, Jaroslav Bachorik wrote: >>>>>>>> On 09/12/2013 05:13 PM, Dmitry Samersoff wrote: >>>>>>>>> Jaroslav, >>>>>>>>> >>>>>>>>> CustomLauncherTest.java: >>>>>>>>> >>>>>>>>> 102: this check could be moved to switch at ll. 108 >>>>>>>>> otherwise test fails on "sunos" and "linux" because PLATFORM >>>>>>>>> remains >>>>>>>>> unset. >>>>>>>> Good idea. Thanks. >>>>>>>> >>>>>>>>> 129: I would prefer don't have pattern like this one ever in shell >>>>>>>>> script. Could you prepare a list of VM's to check and just loop >>>>>>>>> over >>>>>>>>> it? >>>>>>>>> It makes test better readable. Also I think nowdays we can always >>>>>>>>> use >>>>>>>>> server VM. >>>>>>>> I tried to mirror the original shell test as closely as >>>>>>>> possible. It >>>>>>>> would be nice if we could rely on the "server" vm only. Definitely >>>>>>>> more >>>>>>>> readable. >>>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2013-09-12 18:17, Jaroslav Bachorik wrote: >>>>>>>>>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: >>>>>>>>>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote: >>>>>>>>>>>> On 09/12/2013 04:45 AM, David Holmes wrote: >>>>>>>>>>>>> Hi Jaroslav, >>>>>>>>>>>>> >>>>>>>>>>>>> You need a copyright notice in the new file. >>>>>>>>>>>>> >>>>>>>>>>>>> As written this test can only run on a full JDK - so please >>>>>>>>>>>>> add >>>>>>>>>>>>> it to >>>>>>>>>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really >>>>>>>>>>>>> needs to >>>>>>>>>>>>> come >>>>>>>>>>>>> from the test-jdk? And use the VMOPTS passed to the test?) >>>>>>>>>>>>> >>>>>>>>>>>>> Is there a reason this test can't run on OSX? I know it would >>>>>>>>>>>>> need >>>>>>>>>>>>> further modification but was wondering if there is something >>>>>>>>>>>>> inherent in >>>>>>>>>>>>> the test that makes it inapplicable to OSX. >>>>>>>>>>>>> >>>>>>>>>>>>> I think the test would be a lot simpler if the jdk tests had >>>>>>>>>>>>> the >>>>>>>>>>>>> hotspot >>>>>>>>>>>>> test library's process tools available. :( >>>>>>>>>>>> We have some, is there an obvious gap? >>>>>>>>>>>> >>>>>>>>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Hm, thanks for the info. I should have used this library >>>>>>>>>>> instead. >>>>>>>>>>> >>>>>>>>>>> Please, stand by for the updated webrev. >>>>>>>>>> I was able to get rid off the JCMD. Using the testlibrary the >>>>>>>>>> target >>>>>>>>>> application can recognize its own PID and print it to its stdout. >>>>>>>>>> The >>>>>>>>>> main application then just reads the stdout to parse the PID. No >>>>>>>>>> need >>>>>>>>>> for JCMD any more. >>>>>>>>>> >>>>>>>>>> I could not find a way to remove the dependency on "test.jdk" >>>>>>>>>> system >>>>>>>>>> property. According to the jtreg web documentation >>>>>>>>>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a >>>>>>>>>> "test.java" >>>>>>>>>> system property should be available but in fact is not. But it >>>>>>>>>> seems >>>>>>>>>> that the testlibrary uses "test.jdk" system property too. >>>>>>>>>> >>>>>>>>>> The test does not run on OSX because nobody built the launcher >>>>>>>>>> binary :) >>>>>>>>>> I think it is a kind of DIY so I took the liberty of adding a >>>>>>>>>> linux-amd64 launcher while working on the test. >>>>>>>>>> >>>>>>>>>> While working with the test library I realized I was missing a >>>>>>>>>> crucial >>>>>>>>>> feature (at least for my purposes) - waiting for a certain >>>>>>>>>> message to >>>>>>>>>> appear in the stdout/stderr of the launched process. Very often I >>>>>>>>>> need >>>>>>>>>> to wait for the target process to get to certain point before the >>>>>>>>>> test >>>>>>>>>> can be allowed to continue - and the point is indicated by a >>>>>>>>>> message in >>>>>>>>>> stdout/stderr. Currently all the proc tools are designed to >>>>>>>>>> work in >>>>>>>>>> "batch" mode - the whole stdout/stderr is captured in strings and >>>>>>>>>> analyzed after the target process died - and are not suitable for >>>>>>>>>> this >>>>>>>>>> kind of usage. >>>>>>>>>> >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 >>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -Chris. >>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>> Please, review the patch for an intermittently failing test. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The test is a shell test, using files for the interprocess >>>>>>>>>>>>>> synchronization. This leads to intermittent failures. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In order to fix this the test is rewritten in Java - the >>>>>>>>>>>>>> original >>>>>>>>>>>>>> functionality and outputs should be 100% preserved. The >>>>>>>>>>>>>> patch is >>>>>>>>>>>>>> unfortunately a bit difficult to follow since there is no >>>>>>>>>>>>>> similarity >>>>>>>>>>>>>> between the *.sh and *.java file so one needs to go through >>>>>>>>>>>>>> the >>>>>>>>>>>>>> new >>>>>>>>>>>>>> source in whole. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The changes in "launcher" files are all about adding >>>>>>>>>>>>>> permissions to >>>>>>>>>>>>>> execute (0755) and as such the webrev shows no differences. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Issue : JDK-8004926 >>>>>>>>>>>>>> Webrev : >>>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>>>>>>>>>>>> >>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >> From stuart.marks at oracle.com Thu Oct 24 10:14:00 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Thu, 24 Oct 2013 17:14:00 +0000 Subject: hg: jdk8/tl/jdk: 8023862: deprecate HTTP proxying from RMI Message-ID: <20131024171414.72C13626F3@hg.openjdk.java.net> Changeset: 808b9ef4f667 Author: smarks Date: 2013-10-24 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/808b9ef4f667 8023862: deprecate HTTP proxying from RMI Reviewed-by: mchung ! src/share/classes/java/rmi/server/RMISocketFactory.java ! src/share/classes/java/rmi/server/package.html ! src/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java + test/sun/rmi/transport/proxy/DisableHttpDefaultValue.java From brian.goetz at oracle.com Thu Oct 24 10:15:29 2013 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 24 Oct 2013 17:15:29 +0000 Subject: hg: jdk8/tl/jdk: 8019646: Clarify javadoc contract of LambdaMetafactory Message-ID: <20131024171544.B121B626F4@hg.openjdk.java.net> Changeset: 5fa2fd782993 Author: briangoetz Date: 2013-10-24 13:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5fa2fd782993 8019646: Clarify javadoc contract of LambdaMetafactory Reviewed-by: briangoetz, rfield Contributed-by: dan.smith at oracle.com ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java From joel.franck at oracle.com Thu Oct 24 10:21:27 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Thu, 24 Oct 2013 17:21:27 +0000 Subject: hg: jdk8/tl/jdk: 8023651: j.l.r.Constructor.getAnnotatedReceiverType() and j.l.r.Constructor.getAnnotatedReturnType() for inner classes return incorrect result Message-ID: <20131024172140.9227E626F5@hg.openjdk.java.net> Changeset: 93e696ba5923 Author: jfranck Date: 2013-10-24 19:04 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93e696ba5923 8023651: j.l.r.Constructor.getAnnotatedReceiverType() and j.l.r.Constructor.getAnnotatedReturnType() for inner classes return incorrect result Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java ! src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java + test/java/lang/annotation/typeAnnotations/ConstructorReceiverTest.java From joel.franck at oracle.com Thu Oct 24 09:54:10 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Thu, 24 Oct 2013 16:54:10 +0000 Subject: hg: jdk8/tl/jdk: 8027170: Annotations declared on super-super-class should be overridden by super-class. Message-ID: <20131024165457.41DF4626F0@hg.openjdk.java.net> Changeset: b8927cbfb893 Author: alundblad Date: 2013-10-24 18:52 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b8927cbfb893 8027170: Annotations declared on super-super-class should be overridden by super-class. Reviewed-by: jfranck Contributed-by: andreas.lundblad at oracle.com, peter.levart at gmail.com ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/System.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/annotation/AnnotationSupport.java + test/java/lang/annotation/repeatingAnnotations/InheritedAssociatedAnnotations.java From christian.thalinger at oracle.com Thu Oct 24 10:52:55 2013 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 24 Oct 2013 17:52:55 +0000 Subject: hg: jdk8/tl/jdk: 8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms Message-ID: <20131024175306.BA330626F6@hg.openjdk.java.net> Changeset: 66884b270b44 Author: twisti Date: 2013-10-24 10:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/66884b270b44 8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms Reviewed-by: iveresov, jrose ! src/share/classes/java/lang/invoke/MethodHandles.java From xueming.shen at oracle.com Thu Oct 24 11:15:13 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 24 Oct 2013 18:15:13 +0000 Subject: hg: jdk8/tl/jdk: 8025003: Base64 should be less strict with padding Message-ID: <20131024181536.C272A626F7@hg.openjdk.java.net> Changeset: e7bdb2fcc7bc Author: sherman Date: 2013-10-24 11:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7bdb2fcc7bc 8025003: Base64 should be less strict with padding Summary: updated spec and implementation of mime decoder to be lenient for padding Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/Base64GetEncoderTest.java ! test/java/util/Base64/TestBase64.java ! test/java/util/Base64/TestBase64Golden.java From bhavesh.x.patel at oracle.com Thu Oct 24 11:24:17 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Thu, 24 Oct 2013 18:24:17 +0000 Subject: hg: jdk8/tl/langtools: 8006248: Since addition of -Xdoclint, javadoc ignores unknown tags Message-ID: <20131024182422.A6CB9626F9@hg.openjdk.java.net> Changeset: 667843bd2193 Author: bpatel Date: 2013-10-24 11:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/667843bd2193 8006248: Since addition of -Xdoclint, javadoc ignores unknown tags Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/doclint/Env.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java + test/com/sun/javadoc/testCustomTag/TagTestClass.java + test/com/sun/javadoc/testCustomTag/TestCustomTag.java + test/com/sun/javadoc/testCustomTag/taglets/CustomTag.java + test/tools/doclint/CustomTagTest.java + test/tools/doclint/CustomTagTest.out + test/tools/doclint/CustomTagTestWithOption.out ! test/tools/doclint/DocLintTester.java From mandy.chung at oracle.com Thu Oct 24 12:33:08 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 24 Oct 2013 12:33:08 -0700 Subject: jmx-dev RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: <52692847.1030806@oracle.com> References: <526681FD.90604@oracle.com> <5266DA56.6050609@oracle.com> <52678280.1070004@oracle.com> <4972770C-A8BB-40A0-9BB8-885AA6B707BC@oracle.com> <52678509.2020002@oracle.com> <68F92D47-E916-426B-8D6A-2EA48302053D@oracle.com> <5267C3AD.5050306@oracle.com> <5267C74F.2010302@oracle.com> <5267CC00.7080509@oracle.com> <5267DDFC.4060607@oracle.com> <52685571.1090407@oracle.com> <52692847.1030806@oracle.com> Message-ID: <526975F4.8060707@oracle.com> On 10/24/2013 7:01 AM, Jaroslav Bachorik wrote: > Hi Mandy, > > On 24.10.2013 01:02, Mandy Chung wrote: >> >> On 10/23/2013 7:32 AM, Jaroslav Bachorik wrote: >>> I've updated the patch. The GC is called even before the first attempt >>> to get the pool memory usage and System.gc() is used to perform GC (no >>> MXBean checks). This should simplify the change a bit. >>> >>> http://cr.openjdk.java.net/~jbachorik/8020467/webrev.02 >> >> This change is okay. It will force GC once per each memory pool that >> supports usage threshold (I think 3 memory pools) which is not a huge >> issue. Perhaps a more reliable option is to make it an othervm test and >> allocating large object and calling GC once before the verification. > > Running it as othervm might improve repeatbility but I don't quite > follow the trick with large object. That would be effective for the > oldgen pools only, I suppose? There were concerns raised during the > review that other pools might be susceptible to the same timing > related problems (theoretically). This test was written before the samevm/agentvm support. In general we want the tests to be reliable. You want the System.gc() call to reduce the probability of the race such that the initially empty pool is being filled with objects between getUsage() and isUsageThresholdExceeded() methods are called but this has the assumption that there is some large object allocated and get promoted to the old gen (not done in this test though). The other possibility is that the old gen is cleared although it might be rare in practice? Holding on a large object will ensure that the old gen is always filled with something to make it more reliable. > So, if you don't feel strongy about it I would leave the rest of the > test as it is - that is calling System.gc() before checking the pool > thresholds. I just worry that this test will fail some day intermittently again. Since in practice the runtime has space allocated, I think running it in othervm would be adequate. Mandy From huizhe.wang at oracle.com Thu Oct 24 13:46:19 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Thu, 24 Oct 2013 20:46:19 +0000 Subject: hg: jdk8/tl/jaxp: 8004476: XSLT Extension Functions Don't Work in WebStart Message-ID: <20131024204635.A5A19626FF@hg.openjdk.java.net> Changeset: 390e94b9a852 Author: joehw Date: 2013-10-24 13:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/390e94b9a852 8004476: XSLT Extension Functions Don't Work in WebStart Reviewed-by: dfuchs, lancea, alanb ! src/com/sun/org/apache/xalan/internal/XalanConstants.java + src/com/sun/org/apache/xalan/internal/utils/FeatureManager.java + src/com/sun/org/apache/xalan/internal/utils/FeaturePropertyBase.java ! src/com/sun/org/apache/xalan/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xalan/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xalan/internal/xsltc/cmdline/Compile.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionCall.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesHandlerImpl.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/com/sun/org/apache/xerces/internal/utils/SecuritySupport.java ! src/com/sun/org/apache/xpath/internal/jaxp/JAXPExtensionsProvider.java ! src/com/sun/org/apache/xpath/internal/jaxp/XPathExpressionImpl.java ! src/com/sun/org/apache/xpath/internal/jaxp/XPathFactoryImpl.java ! src/com/sun/org/apache/xpath/internal/jaxp/XPathImpl.java From huizhe.wang at oracle.com Thu Oct 24 14:15:06 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Thu, 24 Oct 2013 21:15:06 +0000 Subject: hg: jdk8/tl/jdk: 8004476: XSLT Extension Functions Don't Work in WebStart Message-ID: <20131024211529.D722162701@hg.openjdk.java.net> Changeset: 05dbf105e70f Author: joehw Date: 2013-10-24 14:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/05dbf105e70f 8004476: XSLT Extension Functions Don't Work in WebStart Reviewed-by: dfuchs, lancea, alanb + test/javax/xml/jaxp/transform/jdk8004476/SecureProcessingTest.xml + test/javax/xml/jaxp/transform/jdk8004476/TestBase.java + test/javax/xml/jaxp/transform/jdk8004476/XPathExFuncTest.java + test/javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java + test/javax/xml/jaxp/transform/jdk8004476/tokenize.xml + test/javax/xml/jaxp/transform/jdk8004476/tokenize.xsl From david.holmes at oracle.com Thu Oct 24 15:54:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Oct 2013 08:54:49 +1000 Subject: [ping][ping] Re: jmx-dev RFR: 8004926 sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out In-Reply-To: <52692A44.9050004@oracle.com> References: <52308ECC.1050304@oracle.com> <523138CB.9040401@oracle.com> <52317782.1060300@oracle.com> <523179C8.50606@oracle.com> <5231CCE4.7060902@oracle.com> <5231DA1B.4070706@oracle.com> <5231DE69.7090309@oracle.com> <523B0B30.4020003@oracle.com> <5252C1B6.2060904@oracle.com> <52537F36.8020001@oracle.com> <5253ED95.20706@oracle.com> <52552EBA.4060308@oracle.com> <52553EAD.4040506@oracle.com> <52562FF5.5060304@oracle.com> <52692A44.9050004@oracle.com> Message-ID: <5269A539.8020401@oracle.com> Good to go. Thanks, David On 25/10/2013 12:10 AM, Jaroslav Bachorik wrote: > Hi David, > > On 10.10.2013 06:41, David Holmes wrote: >> On 9/10/2013 9:31 PM, Jaroslav Bachorik wrote: >>> On 9.10.2013 12:23, David Holmes wrote: >>>> Jaroslav, >>>> >>>> Thanks for the details description of changes - much appreciated. >>>> >>>> There is a lot to digest in there. :) >>> >>> Yep, it started as a simple fix :/ >>> >>>> >>>> It isn't obvious to me why these tests require a full JDK? >>> >>> IDK, LocalManagementTest.sh was listed as one requiring full JDK. Its >>> requirements are the same as the ones of CustomLauncherTest.sh (now >>> *.java) so it seemed logical to list it there too. >> >> Ah! Now I see it - it uses tools.jar which implies a full JDK. >> >>>> >>>> I don't quite follow the libjvm lookup logic - I would expect that you >>>> would always want to test the libjvm that is currently running - though >>>> it is hard to determine that. >>> >>> I'm afraid I can't be of much assistance here - I just took what was in >>> the *.sh version and converted it to *.java. >> >> Okay. I expect this will need revisiting at some point. > > So, does this mean "ok, go"? > > Thanks, > > -JB- > >> >> Thanks, >> David >> ----- >> >> >>> -JB- >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 8/10/2013 9:33 PM, Jaroslav Bachorik wrote: >>>>> On 8.10.2013 05:42, David Holmes wrote: >>>>>> Jaroslav, >>>>>> >>>>>> Can you summarise the changes please? With the conversion to Java and >>>>>> the infrastructure additions I can't tell what is actually fixing the >>>>>> original timeout issue :) >>>>> >>>>> The timeout was most caused by using the same file for communication >>>>> between java processes in more test cases. When those test cases were >>>>> run in parallel the file got rewritten silently and some of the tests >>>>> could end up trying to connect to incorrect port in the target >>>>> application. I was able to reproduce the timeout by interleaving the >>>>> test runs for CustomLauncherTest.sh and LocalManagementTest.sh and >>>>> adding an artificial delay to CusteomLauncherTest.sh to allow >>>>> LocalManagementTest.sh to change the port in the file. >>>>> >>>>> While it could be fixed by using a different file for each test case I >>>>> took the liberty of converting the shell tests to java tests. This >>>>> allows me to remove the communication file and, in the end, make the >>>>> tests more robust. >>>>> >>>>> CustomLauncherTest.java and LocalManagementTest.java are the tests >>>>> converted from shell to java. I decided to convert >>>>> LocalManagementTest.sh as well because it has the same problems as the >>>>> CustomLauncherTest.sh. >>>>> >>>>> The changes in the testlibrary are about introducing new methods >>>>> allowing the tests easily start a process and wait for a certain text >>>>> appearing in its stdout/stderr. Using these methods the caller can >>>>> wait >>>>> till the callee is fully initialized and eg. ready to accept >>>>> connections. >>>>> >>>>> The changes in launchers make the launchers actually executable + I am >>>>> adding a linux-amd64 launcher (I needed that one to work on the >>>>> changes >>>>> locally and thought it might be nice to have one more platform covered >>>>> by the test). >>>>> >>>>> I've update the webrev to include changes to LocalManagementTest and >>>>> TEST.groups (both of those tests require JDK) - >>>>> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.05 >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 8/10/2013 12:14 AM, Jaroslav Bachorik wrote: >>>>>>> On 19.9.2013 16:33, Jaroslav Bachorik wrote: >>>>>>>> The updated webrev: >>>>>>>> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.03 >>>>>>>> >>>>>>>> I've moved some of the functionality to the testlibrary. >>>>>>>> >>>>>>>> -JB - >>>>>>>> >>>>>>>> On 12.9.2013 17:31, Jaroslav Bachorik wrote: >>>>>>>>> On 09/12/2013 05:13 PM, Dmitry Samersoff wrote: >>>>>>>>>> Jaroslav, >>>>>>>>>> >>>>>>>>>> CustomLauncherTest.java: >>>>>>>>>> >>>>>>>>>> 102: this check could be moved to switch at ll. 108 >>>>>>>>>> otherwise test fails on "sunos" and "linux" because PLATFORM >>>>>>>>>> remains >>>>>>>>>> unset. >>>>>>>>> Good idea. Thanks. >>>>>>>>> >>>>>>>>>> 129: I would prefer don't have pattern like this one ever in >>>>>>>>>> shell >>>>>>>>>> script. Could you prepare a list of VM's to check and just loop >>>>>>>>>> over >>>>>>>>>> it? >>>>>>>>>> It makes test better readable. Also I think nowdays we can always >>>>>>>>>> use >>>>>>>>>> server VM. >>>>>>>>> I tried to mirror the original shell test as closely as >>>>>>>>> possible. It >>>>>>>>> would be nice if we could rely on the "server" vm only. Definitely >>>>>>>>> more >>>>>>>>> readable. >>>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2013-09-12 18:17, Jaroslav Bachorik wrote: >>>>>>>>>>> On 09/12/2013 10:22 AM, Jaroslav Bachorik wrote: >>>>>>>>>>>> On 09/12/2013 10:12 AM, Chris Hegarty wrote: >>>>>>>>>>>>> On 09/12/2013 04:45 AM, David Holmes wrote: >>>>>>>>>>>>>> Hi Jaroslav, >>>>>>>>>>>>>> >>>>>>>>>>>>>> You need a copyright notice in the new file. >>>>>>>>>>>>>> >>>>>>>>>>>>>> As written this test can only run on a full JDK - so please >>>>>>>>>>>>>> add >>>>>>>>>>>>>> it to >>>>>>>>>>>>>> the :needs_jdk group in TEST.groups. (Does jcmd really >>>>>>>>>>>>>> needs to >>>>>>>>>>>>>> come >>>>>>>>>>>>>> from the test-jdk? And use the VMOPTS passed to the test?) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is there a reason this test can't run on OSX? I know it would >>>>>>>>>>>>>> need >>>>>>>>>>>>>> further modification but was wondering if there is something >>>>>>>>>>>>>> inherent in >>>>>>>>>>>>>> the test that makes it inapplicable to OSX. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think the test would be a lot simpler if the jdk tests had >>>>>>>>>>>>>> the >>>>>>>>>>>>>> hotspot >>>>>>>>>>>>>> test library's process tools available. :( >>>>>>>>>>>>> We have some, is there an obvious gap? >>>>>>>>>>>>> >>>>>>>>>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/e407df8093dc/test/lib/testlibrary/jdk/testlibrary/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Hm, thanks for the info. I should have used this library >>>>>>>>>>>> instead. >>>>>>>>>>>> >>>>>>>>>>>> Please, stand by for the updated webrev. >>>>>>>>>>> I was able to get rid off the JCMD. Using the testlibrary the >>>>>>>>>>> target >>>>>>>>>>> application can recognize its own PID and print it to its >>>>>>>>>>> stdout. >>>>>>>>>>> The >>>>>>>>>>> main application then just reads the stdout to parse the PID. No >>>>>>>>>>> need >>>>>>>>>>> for JCMD any more. >>>>>>>>>>> >>>>>>>>>>> I could not find a way to remove the dependency on "test.jdk" >>>>>>>>>>> system >>>>>>>>>>> property. According to the jtreg web documentation >>>>>>>>>>> (http://openjdk.java.net/jtreg/vmoptions.html#cmdLineOpts) a >>>>>>>>>>> "test.java" >>>>>>>>>>> system property should be available but in fact is not. But it >>>>>>>>>>> seems >>>>>>>>>>> that the testlibrary uses "test.jdk" system property too. >>>>>>>>>>> >>>>>>>>>>> The test does not run on OSX because nobody built the launcher >>>>>>>>>>> binary :) >>>>>>>>>>> I think it is a kind of DIY so I took the liberty of adding a >>>>>>>>>>> linux-amd64 launcher while working on the test. >>>>>>>>>>> >>>>>>>>>>> While working with the test library I realized I was missing a >>>>>>>>>>> crucial >>>>>>>>>>> feature (at least for my purposes) - waiting for a certain >>>>>>>>>>> message to >>>>>>>>>>> appear in the stdout/stderr of the launched process. Very >>>>>>>>>>> often I >>>>>>>>>>> need >>>>>>>>>>> to wait for the target process to get to certain point before >>>>>>>>>>> the >>>>>>>>>>> test >>>>>>>>>>> can be allowed to continue - and the point is indicated by a >>>>>>>>>>> message in >>>>>>>>>>> stdout/stderr. Currently all the proc tools are designed to >>>>>>>>>>> work in >>>>>>>>>>> "batch" mode - the whole stdout/stderr is captured in strings >>>>>>>>>>> and >>>>>>>>>>> analyzed after the target process died - and are not suitable >>>>>>>>>>> for >>>>>>>>>>> this >>>>>>>>>>> kind of usage. >>>>>>>>>>> >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8004926/webrev.01 >>>>>>>>>>> >>>>>>>>>>>> -JB- >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -Chris. >>>>>>>>>>>>> >>>>>>>>>>>>>> David >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 12/09/2013 1:39 AM, Jaroslav Bachorik wrote: >>>>>>>>>>>>>>> Please, review the patch for an intermittently failing test. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The test is a shell test, using files for the interprocess >>>>>>>>>>>>>>> synchronization. This leads to intermittent failures. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In order to fix this the test is rewritten in Java - the >>>>>>>>>>>>>>> original >>>>>>>>>>>>>>> functionality and outputs should be 100% preserved. The >>>>>>>>>>>>>>> patch is >>>>>>>>>>>>>>> unfortunately a bit difficult to follow since there is no >>>>>>>>>>>>>>> similarity >>>>>>>>>>>>>>> between the *.sh and *.java file so one needs to go through >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> new >>>>>>>>>>>>>>> source in whole. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The changes in "launcher" files are all about adding >>>>>>>>>>>>>>> permissions to >>>>>>>>>>>>>>> execute (0755) and as such the webrev shows no differences. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Issue : JDK-8004926 >>>>>>>>>>>>>>> Webrev : >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/8004926/webrev.00 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> > From robert.field at oracle.com Thu Oct 24 16:53:07 2013 From: robert.field at oracle.com (robert.field at oracle.com) Date: Thu, 24 Oct 2013 23:53:07 +0000 Subject: hg: jdk8/tl/langtools: 8027220: DefaultMethodsTest: Change test to match spec Message-ID: <20131024235318.723B06270F@hg.openjdk.java.net> Changeset: 860f1d21763a Author: rfield Date: 2013-10-24 16:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/860f1d21763a 8027220: DefaultMethodsTest: Change test to match spec Reviewed-by: ksrini ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java From weijun.wang at oracle.com Thu Oct 24 17:39:27 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 25 Oct 2013 00:39:27 +0000 Subject: hg: jdk8/tl/jdk: 8026929: remove accelerators from policytool resources Message-ID: <20131025004104.D37F162710@hg.openjdk.java.net> Changeset: e9ec0ca5bab1 Author: weijun Date: 2013-10-25 08:38 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e9ec0ca5bab1 8026929: remove accelerators from policytool resources Reviewed-by: alexp, weijun Contributed-by: Leif Samuelsson ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! src/share/classes/sun/security/tools/policytool/Resources.java From ioi.lam at oracle.com Fri Oct 25 01:15:13 2013 From: ioi.lam at oracle.com (ioi.lam at oracle.com) Date: Fri, 25 Oct 2013 08:15:13 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8020753: JNI_CreateJavaVM on Mac OSX 10.9 Mavericks corrupts the callers stack size Message-ID: <20131025081528.9F3F36272D@hg.openjdk.java.net> Changeset: d70a665e25d7 Author: iklam Date: 2013-10-24 22:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d70a665e25d7 8020753: JNI_CreateJavaVM on Mac OSX 10.9 Mavericks corrupts the callers stack size Summary: Use hard-coded DEFAULT_MAIN_THREAD_STACK_PAGES = 2048 for 10.9 Reviewed-by: dcubed, iveresov Contributed-by: gerard.ziemski at oracle.com ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp From chris.hegarty at oracle.com Fri Oct 25 03:22:48 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 25 Oct 2013 10:22:48 +0000 Subject: hg: jdk8/tl/jdk: 7079145: Remove java/net/ipv6tests/UdpTest.java from the ProblemList.txt Message-ID: <20131025102504.6B5A462738@hg.openjdk.java.net> Changeset: d126301ad372 Author: ewang Date: 2013-10-25 11:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d126301ad372 7079145: Remove java/net/ipv6tests/UdpTest.java from the ProblemList.txt Reviewed-by: alanb, chegar ! test/ProblemList.txt From jaroslav.bachorik at oracle.com Fri Oct 25 04:02:55 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Fri, 25 Oct 2013 11:02:55 +0000 Subject: hg: jdk8/tl/jdk: 8004926: sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out Message-ID: <20131025110336.0F16D6273A@hg.openjdk.java.net> Changeset: 1153022c0a45 Author: jbachorik Date: 2013-10-25 13:01 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1153022c0a45 8004926: sun/management/jmxremote/bootstrap/CustomLauncherTest.sh oftenly times out Summary: Improve reliability by converting the test to Java Reviewed-by: dsamersoff, dholmes ! test/TEST.groups ! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java ! test/lib/testlibrary/jdk/testlibrary/StreamPumper.java + test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java - test/sun/management/jmxremote/bootstrap/CustomLauncherTest.sh + test/sun/management/jmxremote/bootstrap/LocalManagementTest.java - test/sun/management/jmxremote/bootstrap/LocalManagementTest.sh ! test/sun/management/jmxremote/bootstrap/TestApplication.java ! test/sun/management/jmxremote/bootstrap/TestManager.java + test/sun/management/jmxremote/bootstrap/linux-amd64/launcher From staffan.larsen at oracle.com Fri Oct 25 05:09:28 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Fri, 25 Oct 2013 12:09:28 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8027294: Prepare hotspot for non TOD based uptime counter Message-ID: <20131025120933.2150362743@hg.openjdk.java.net> Changeset: e4f478e7781b Author: jbachorik Date: 2013-10-25 09:07 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e4f478e7781b 8027294: Prepare hotspot for non TOD based uptime counter Summary: Use HR timer when available for os::elapsed_counter() on linux/bsd. Add a new counter for the JVM uptime. Reviewed-by: dholmes, sla ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp From harold.seigel at oracle.com Fri Oct 25 10:02:16 2013 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Fri, 25 Oct 2013 17:02:16 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20131025170225.B6D8F62752@hg.openjdk.java.net> Changeset: a6177f601c64 Author: hseigel Date: 2013-10-25 11:05 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a6177f601c64 8026822: metaspace/flags/maxMetaspaceSize throws OOM of unexpected type.java.lang.OutOfMemoryError: Compressed class space Summary: Incorporate chunk size when seeing if OutOfMemoryError was caused by Metaspace or Compressed class space. Reviewed-by: stefank, coleenp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp Changeset: 634715d59d9e Author: hseigel Date: 2013-10-25 11:13 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/634715d59d9e Merge From coleen.phillimore at oracle.com Fri Oct 25 14:28:32 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 25 Oct 2013 21:28:32 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8024927: Nashorn performance regression with CompressedOops Message-ID: <20131025212843.480EB6276F@hg.openjdk.java.net> Changeset: 209aa13ab8c0 Author: coleenp Date: 2013-10-25 15:19 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/209aa13ab8c0 8024927: Nashorn performance regression with CompressedOops Summary: Allocate compressed class space at end of Java heap. For small heap sizes, without CDS, save some space so compressed classes can have the same favorable compression as oops Reviewed-by: stefank, hseigel, goetz ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/utilities/globalDefinitions.hpp + test/runtime/CompressedOops/CompressedClassPointers.java From stuart.marks at oracle.com Fri Oct 25 14:53:31 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Fri, 25 Oct 2013 21:53:31 +0000 Subject: hg: jdk8/tl/jdk: 5063500: Formatter spec says "char" is not an integral type; ... Message-ID: <20131025215345.E77FD62770@hg.openjdk.java.net> Changeset: 8ea272253285 Author: smarks Date: 2013-10-25 14:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8ea272253285 5063500: Formatter spec says "char" is not an integral type 7126305: Wrong Unicode value specified for format conversion character 'd' 8027287: incorrect example in Formatter javadoc Reviewed-by: rriggs, darcy, lancea ! src/share/classes/java/util/Formatter.java From calvin.cheung at oracle.com Sun Oct 27 18:42:03 2013 From: calvin.cheung at oracle.com (calvin.cheung at oracle.com) Date: Mon, 28 Oct 2013 01:42:03 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 41 new changesets Message-ID: <20131028014339.049EB6278E@hg.openjdk.java.net> Changeset: f9d4ed6c88dd Author: dholmes Date: 2013-10-21 20:51 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9d4ed6c88dd 8026872: [TESTBUG] Classes OOMCrashClass4000_1.class and OOMCrashClass1960_2.class from runtime/ClassFile/ tests won't run on compact profiles Reviewed-by: sla, sspitsyn ! test/TEST.groups Changeset: 8cd1abf3ecab Author: dholmes Date: 2013-10-21 21:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8cd1abf3ecab Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! test/TEST.groups - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: 2036c97e3af0 Author: dholmes Date: 2013-10-21 22:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2036c97e3af0 Merge Changeset: b3a4d4279fa3 Author: ccheung Date: 2013-10-24 17:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b3a4d4279fa3 Merge Changeset: 74e00b98d5dd Author: anoll Date: 2013-10-17 19:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/74e00b98d5dd 8026708: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation Summary: Increase size for the template interpreter accordingly Reviewed-by: kvn, twisti ! src/cpu/x86/vm/templateInterpreter_x86.hpp Changeset: 1856ea98184a Author: adlertz Date: 2013-10-18 10:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1856ea98184a 8022783: Nashorn test fails with: assert(!def_outside->member(r)) Summary: Enables private copies of inputs for recent spill copies as well Reviewed-by: kvn, twisti ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/reg_split.cpp Changeset: e3b736cf4fa3 Author: adlertz Date: 2013-10-18 09:36 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e3b736cf4fa3 Merge Changeset: 252d541466ea Author: morris Date: 2013-10-18 12:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/252d541466ea 8008242: VerifyOops is broken on SPARC Summary: Fixed displacement issues in SPARC macroassembler and ensure that getClass intrinsic temporary result is T_METADATA Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 3213ba4d3dff Author: roland Date: 2013-10-19 12:16 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3213ba4d3dff 8024069: replace_in_map() should operate on parent maps Summary: type information gets lost because replace_in_map() doesn't update parent maps Reviewed-by: kvn, twisti ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/multnode.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp Changeset: 19c5a042b0b3 Author: iignatyev Date: 2013-10-19 21:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/19c5a042b0b3 8026414: [TESTBUG] Tests for Tiered/NonTiered levels Reviewed-by: twisti, iveresov + test/compiler/tiered/CompLevelsTest.java + test/compiler/tiered/NonTieredLevelsTest.java + test/compiler/tiered/TieredLevelsTest.java Changeset: 600c83f8e6a5 Author: iignatyev Date: 2013-10-19 21:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/600c83f8e6a5 8023318: compiler/whitebox tests timeout with enabled TieredCompilation Reviewed-by: kvn, twisti ! test/compiler/whitebox/CompilerWhiteBoxTest.java Changeset: e842cc2d2dfb Author: iveresov Date: 2013-10-19 22:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/e842cc2d2dfb Merge Changeset: 52575a17a36c Author: iignatyev Date: 2013-10-21 09:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/52575a17a36c 8026865: [TESTBUG] 'compiler/print/PrintInlining.java' should specify -XX:+UnlockDiagnosticVMOptions Reviewed-by: twisti, iveresov ! test/compiler/print/PrintInlining.java Changeset: 4748b3308cda Author: iveresov Date: 2013-10-21 17:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4748b3308cda Merge Changeset: 5ccbab1c69f3 Author: roland Date: 2013-10-22 09:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5ccbab1c69f3 8026251: New type profiling points: parameters to methods Summary: x86 interpreter and c1 type profiling for parameters on method entries Reviewed-by: kvn, twisti ! src/cpu/x86/vm/bytecodeInterpreter_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp + src/cpu/x86/vm/interp_masm_x86.cpp + src/cpu/x86/vm/interp_masm_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp Changeset: 435c7b4577cd Author: rbackman Date: 2013-10-21 15:31 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/435c7b4577cd 8026959: assert(!n->pinned() || n->is_MachConstantBase()) failed: only pinned MachConstantBase node is expected here Reviewed-by: iveresov, roland ! src/share/vm/opto/compile.cpp Changeset: 36e17466dd39 Author: rbackman Date: 2013-10-22 14:02 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/36e17466dd39 Merge Changeset: 8b4bbba322d3 Author: anoll Date: 2013-10-23 10:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8b4bbba322d3 8026407: VM crashes on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified Summary: Ensure currently required generation of AdapterHandlerLibrary::create_native_wrapper() Reviewed-by: roland, iveresov ! src/share/vm/compiler/compileBroker.cpp Changeset: b2ee5dc63353 Author: roland Date: 2013-10-23 12:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b2ee5dc63353 8024070: C2 needs some form of type speculation Summary: record unused type profile information with type system, propagate and use it. Reviewed-by: kvn, twisti ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/arguments.cpp + test/compiler/types/TypeSpeculation.java Changeset: 4c9115774c8e Author: adlertz Date: 2013-10-23 10:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4c9115774c8e 8026939: assert(Reachblock != NULL) failed: Reachblock must be non-NULL Summary: We can reach this state from phi input rematerialization, so pass in the Reaches of the predecessor Reviewed-by: roland, twisti ! src/share/vm/opto/reg_split.cpp Changeset: 97d400662426 Author: adlertz Date: 2013-10-23 19:22 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/97d400662426 Merge Changeset: 9acbfe04b5c3 Author: iveresov Date: 2013-10-23 11:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9acbfe04b5c3 8026495: JVM Crashes when started with -XX:+DTraceMethodProbes on Solaris x86_64 Summary: Fix wrong calling convention in LIR_Assembler::emit_unwind_handler(), T_METADATA support in calling convention generator, C1 register allocator Reviewed-by: twisti, jrose ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp Changeset: 1c90f0072f0d Author: twisti Date: 2013-10-23 15:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1c90f0072f0d 8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms Reviewed-by: iveresov, jrose ! src/share/vm/classfile/systemDictionary.cpp Changeset: 3a04e444da6d Author: iveresov Date: 2013-10-23 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3a04e444da6d Merge Changeset: 59e8ad757e19 Author: rbackman Date: 2013-10-18 10:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/59e8ad757e19 8026844: Various Math functions needs intrinsification Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/mathexactnode.cpp ! src/share/vm/opto/mathexactnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/intrinsics/mathexact/AddExactICondTest.java + test/compiler/intrinsics/mathexact/AddExactIConstantTest.java + test/compiler/intrinsics/mathexact/AddExactILoadTest.java + test/compiler/intrinsics/mathexact/AddExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/AddExactINonConstantTest.java + test/compiler/intrinsics/mathexact/AddExactIRepeatTest.java + test/compiler/intrinsics/mathexact/AddExactLConstantTest.java + test/compiler/intrinsics/mathexact/AddExactLNonConstantTest.java - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java + test/compiler/intrinsics/mathexact/DecExactITest.java + test/compiler/intrinsics/mathexact/DecExactLTest.java + test/compiler/intrinsics/mathexact/IncExactITest.java + test/compiler/intrinsics/mathexact/IncExactLTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java + test/compiler/intrinsics/mathexact/MulExactICondTest.java + test/compiler/intrinsics/mathexact/MulExactIConstantTest.java + test/compiler/intrinsics/mathexact/MulExactILoadTest.java + test/compiler/intrinsics/mathexact/MulExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/MulExactINonConstantTest.java + test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java + test/compiler/intrinsics/mathexact/MulExactLConstantTest.java + test/compiler/intrinsics/mathexact/MulExactLNonConstantTest.java + test/compiler/intrinsics/mathexact/NegExactIConstantTest.java + test/compiler/intrinsics/mathexact/NegExactILoadTest.java + test/compiler/intrinsics/mathexact/NegExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/NegExactINonConstantTest.java + test/compiler/intrinsics/mathexact/NegExactLConstantTest.java + test/compiler/intrinsics/mathexact/NegExactLNonConstantTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java + test/compiler/intrinsics/mathexact/SubExactICondTest.java + test/compiler/intrinsics/mathexact/SubExactIConstantTest.java + test/compiler/intrinsics/mathexact/SubExactILoadTest.java + test/compiler/intrinsics/mathexact/SubExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/SubExactINonConstantTest.java + test/compiler/intrinsics/mathexact/SubExactIRepeatTest.java + test/compiler/intrinsics/mathexact/SubExactLConstantTest.java + test/compiler/intrinsics/mathexact/SubExactLNonConstantTest.java ! test/compiler/intrinsics/mathexact/Verify.java Changeset: 68f07c29521b Author: anoll Date: 2013-10-15 08:38 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/68f07c29521b 8025740: Typo. Error line for wrong ReservedCodeCacheSize value is printed twice Summary: Remove duplicate print Reviewed-by: kvn, twisti ! src/share/vm/runtime/arguments.cpp Changeset: d95eca175eff Author: sspitsyn Date: 2013-10-23 20:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d95eca175eff 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. Reviewed-by: jrose ! src/share/vm/prims/methodHandles.cpp Changeset: 0d1661d63d70 Author: vlivanov Date: 2013-10-23 20:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0d1661d63d70 8012941: JSR 292: too deep inlining might crash compiler because of stack overflow Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_globals.hpp Changeset: f7d928a3181c Author: roland Date: 2013-10-24 19:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f7d928a3181c 8026978: JSR292: fatal error: Type profiling not implemented on this platform Summary: force TypeProfileLevel to 0 on non x86 Reviewed-by: twisti ! src/share/vm/runtime/arguments.cpp Changeset: 395499125cb0 Author: iveresov Date: 2013-10-24 16:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/395499125cb0 Merge - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 6b32b911d723 Author: iveresov Date: 2013-10-24 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6b32b911d723 Merge ! src/share/vm/runtime/vmStructs.cpp - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 1d1ea10fe09f Author: mgerdin Date: 2013-10-15 13:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1d1ea10fe09f 8015255: NPG: Don't waste fragment at the end of a VirtualSpaceNode before retiring it. Summary: Chunk up the last piece of committed memory in a VSN when getting a new one. Reviewed-by: stefank, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/prims/jni.cpp Changeset: 91a88c8450f4 Author: mgerdin Date: 2013-10-18 09:31 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/91a88c8450f4 8026698: Incorrect error handling in Metaspace::allocate Reviewed-by: stefank, jwilhelm ! src/share/vm/memory/metaspace.cpp Changeset: a1b05d4a6fd0 Author: stefank Date: 2013-10-21 09:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a1b05d4a6fd0 8026781: Add missing test to exercise -XX:+UseLargePagesInMetaspace Reviewed-by: mgerdin, brutisso + test/gc/TestSystemGC.java Changeset: 3dd24766da44 Author: stefank Date: 2013-10-21 01:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3dd24766da44 Merge Changeset: 2fab5b7e6140 Author: ehelin Date: 2013-10-21 14:20 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2fab5b7e6140 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops Reviewed-by: coleenp, mgerdin, sspitsyn ! src/share/vm/prims/jvmtiImpl.cpp Changeset: c7f403b05168 Author: sjohanss Date: 2013-10-22 11:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c7f403b05168 8026848: -XX:+G1SummarizeRSetStats can result in wrong exit code and crash Summary: Changed the use of %d to SIZE_FORMAT macro in format string when printing size_t values. Reviewed-by: stefank, ehelin ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp Changeset: 0823c8bac468 Author: jcoomes Date: 2013-10-22 12:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0823c8bac468 Merge Changeset: 1b422ef5288a Author: tschatzl Date: 2013-10-23 10:23 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1b422ef5288a 8025728: Missing volatile specifier for field G1AllocRegion::_alloc_region Summary: The field G1AllocRegion::_alloc_region needs to be declared volatile as it is used with that intention. Otherwise the compiler may generate the code that reloads the value which might have changed in the meantime, leading to spurious crashes. Reviewed-by: iveresov, simonis, tschatzl Contributed-by: Axel Siebenborn ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp Changeset: 0dcdec729cda Author: jcoomes Date: 2013-10-25 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0dcdec729cda Merge Changeset: b4aa8fc5d0d5 Author: ccheung Date: 2013-10-25 22:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b4aa8fc5d0d5 Merge ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/share/vm/memory/metaspace.cpp - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java From staffan.larsen at oracle.com Mon Oct 28 04:10:13 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 28 Oct 2013 12:10:13 +0100 Subject: RFR: JDK-8027371 Add JDI tests for breakpointing and stepping in lambda code Message-ID: We currently don't have any debugger tests that explicitly exercises lambdas. I have created two tests that at least provide some kind of red-face testing. They aren't very comprehensive, but I still think they add value. webrev: http://cr.openjdk.java.net/~sla/8027371/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8027371 Thanks, /Staffan From staffan.larsen at oracle.com Mon Oct 28 04:57:34 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 28 Oct 2013 12:57:34 +0100 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <5269272F.6090907@oracle.com> References: <525D4490.3070506@oracle.com> <526546FD.5020909@oracle.com> <52663633.2080206@oracle.com> <0805924E-F724-477D-B4C2-742ACB58075E@oracle.com> <5269272F.6090907@oracle.com> Message-ID: <8BB9C412-6A40-48D7-8EFC-4A8AFC3DD581@oracle.com> This looks a lot better. Just few more comments: ToolConfig.java L72 - "getToolOptins" -> "getToolOptions" L35 - why is port stored as a String? Also, could be renamed to rmiRegistryPort to clarify what it is for. Why are some tool-specific options added in getToolOptins() and some in the getJpsCmd()/getJstatdCmd()/... methods? Maybe changing getToolOptins() to only return the host part of the options and moving the rest of the setup to getJpsCmd()/getJstatdCmd()/...? Thanks, /Staffan On 24 okt 2013, at 15:57, Yekaterina Kantserova wrote: > Hi, > > I've done following big changes after the Staffan's review: > - ported JDKToolLauncher, JDKToolFinder, Plattform from hotspot testlibrary (http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot) for re-using in ToolConfig > - changed "verifiy output form jps, jstat"-methods to ignore warnings from VM > - tools will be launched without -vmoptions > > plus made fixes for all minor comments. > > If it's a good idea to push testlibrary changes separately I can make a separate patch for them. > > Webrev: > http://cr.openjdk.java.net/~ykantser/8022229/webrev.02/ > > Primal bug: > https://bugs.openjdk.java.net/browse/JDK-8022229 > > Similar bugs: > https://bugs.openjdk.java.net/browse/JDK-8019630 > https://bugs.openjdk.java.net/browse/JDK-6636094 > https://bugs.openjdk.java.net/browse/JDK-6543979 > > Thanks, > Katja > > > > On 10/23/2013 12:55 PM, Staffan Larsen wrote: >> test/lib/testlibrary/jdk/testlibrary/Asserts.java >> Same code as already exists in the hotspot testlibrary. >> No further comments. >> >> >> test/lib/testlibrary/jdk/testlibrary/ProcessThread.java >> L33: stating -> starting >> L66: staring -> starting >> >> >> test/lib/testlibrary/jdk/testlibrary/TestThread.java >> This code comes from an internal test library. >> No further comments. >> >> >> test/lib/testlibrary/jdk/testlibrary/Utils.java >> No comments. >> >> >> test/lib/testlibrary/jdk/testlibrary/XRun.java >> This code comes from an internal test library. >> No further comments. >> >> >> test/sun/tools/jstatd/JstatGcutilParser.java >> The parse() method could be made more robust by discarding any lines that come before the header lines. This can happen if the JVM outputs a warning message for some reason before running jstat. >> >> I don't like the special-case for the CCS column in verify() - took me a while to find it. Should we add a new enum called PERCENTAGE_OR_DASH to handle that instead? >> >> L67: getType() should be private. >> >> >> test/sun/tools/jstatd/JstatdHelper.java: >> L54: Does verifyJpsOutput() work correctly with output of the form: >> >> 1234 -- main class information unavailable >> 1235 -- process information unavailable >> >> Also: same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. >> >> L46: "attach" is probably not the best way to describe the operation of jps. It does not attach to the process, it merely lists the running processes. Perhaps runJps() is a better name? >> >> >> test/sun/tools/jstatd/TestJstatdDefaults.java >> test/sun/tools/jstatd/TestJstatdExternalRegistry.java >> test/sun/tools/jstatd/TestJstatdPort.java >> test/sun/tools/jstatd/TestJstatdPortAndServer.java >> test/sun/tools/jstatd/TestJstatdServer.java >> No comments. >> >> >> test/sun/tools/jstatd/TestJstatdUsage.java >> Same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. >> >> >> test/sun/tools/jstatd/ToolConfig.java >> ToolConfig + Utils.get(Forward)VmOptions() seem to be doing similar things to JDKToolLauncher in the hotspot testlibrary. It is unfortunate if we have two ways to do similar things in the two different testlibraries. Would it be possible to reuse the hotspot code here instead? >> >> You have also changed the test. Previously the tools were not launched with the jtreg -vmoptions (test.vm.opts), whereas now they will be. Is this intentional? >> >> >> General comments: >> >> Can't we do: >> * @library /lib/testlibrary >> instead of >> * @library ../../../lib/testlibrary >> ? >> >> It seems that at least some of the functionality should be reused for re-writing the jstat and jps tests as well. I guess we can look at that at a later time, though. >> >> While I applaud the move from shell scripts to Java code, I can't shake the feeling that the shell scripts were easier to read and follow. The Java code is much more verbose and spread out over multiple helpers and libraries, making it harder to grasp. That may be the price we have to pay, though. >> >> >> Thanks, >> /Staffan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131028/3e46a447/attachment-0001.html From yekaterina.kantserova at oracle.com Mon Oct 28 09:12:25 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 28 Oct 2013 09:12:25 -0700 (PDT) Subject: Sv: Re: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd Message-ID: <4e22dbcf-e8f1-47e6-8f43-1d7047811528@default> Hi, http://cr.openjdk.java.net/~ykantser/8022229/webrev.03/ Moved ToolConfig functionality to JstatdTest (renamed JstatdHelper) and deleted ToolConfig. The tests are also changed a little: public class TestJstatdDefaults { public static void main(String[] args) throws Throwable { JstatdTest test = new JstatdTest(); test.doTest(); } } Hope it looks better now. Thanks, Katja ----- Ursprungligt meddelande ----- Fr?n: staffan.larsen at oracle.com Till: yekaterina.kantserova at oracle.com Kopia: serviceability-dev at openjdk.java.net, david.holmes at oracle.com, jaroslav.bachorik at oracle.com, christian.tornqvist at oracle.com, hotspot-dev at openjdk.java.net, mattis.castegren at oracle.com Skickat: m?ndag, 28 okt 2013 12:57:38 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien ?mne: Re: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd This looks a lot better. Just few more comments: ToolConfig.java ? L72 - "getToolOptins" -> "getToolOptions" ? L35 - why is port stored as a String? Also, could be renamed to rmiRegistryPort to clarify what it is for. ? Why are some tool-specific options added in?getToolOptins() and some in the?getJpsCmd()/getJstatdCmd()/... methods? Maybe changing?getToolOptins() to only return the host part of the options and moving the rest of the setup to?getJpsCmd()/getJstatdCmd()/...? Thanks, /Staffan On 24 okt 2013, at 15:57, Yekaterina Kantserova < yekaterina.kantserova at oracle.com > wrote: Hi, I've done following big changes after the Staffan's review: - ported JDKToolLauncher, JDKToolFinder, Plattform from hotspot testlibrary ( http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot ) for re-using in ToolConfig - changed "verifiy output form jps, jstat"-methods to ignore warnings from VM - tools will be launched without -vmoptions plus made fixes for all minor comments . If it's a good idea to push testlibrary changes separately I can make a separate patch for them. Webrev: http://cr.openjdk.java.net/~ykantser/8022229/webrev.02/ Primal bug: https://bugs.openjdk.java.net/browse/JDK-8022229 Similar bugs: https://bugs.openjdk.java.net/browse/JDK-8019630 https://bugs.openjdk.java.net/browse/JDK-6636094 https://bugs.openjdk.java.net/browse/JDK-6543979 Thanks, Katja On 10/23/2013 12:55 PM, Staffan Larsen wrote: test/lib/testlibrary/jdk/testlibrary/Asserts.java ? Same code as already exists in the hotspot testlibrary. ? No further comments. test/lib/testlibrary/jdk/testlibrary/ProcessThread.java ? L33: stating -> starting ? L66: staring -> starting test/lib/testlibrary/jdk/testlibrary/TestThread.java ? This code comes from an internal test library. ? No further comments. test/lib/testlibrary/jdk/testlibrary/Utils.java ? No comments. test/lib/testlibrary/jdk/testlibrary/XRun.java ? This code comes from an internal test library. ? No further comments. test/sun/tools/jstatd/JstatGcutilParser.java ? The parse() method could be made more robust by discarding any lines that come before the header lines. This can happen if the JVM outputs a warning message for some reason before running jstat. ?? ? I don't like the special-case for the CCS column in verify() - took me a while to find it. Should we add a new enum called PERCENTAGE_OR_DASH to handle that instead? ? L67:?getType() should be private. test/sun/tools/jstatd/JstatdHelper.java: ? L54: Does?verifyJpsOutput() work correctly with output of the form: 1234 --?main class information unavailable 1235?-- process information unavailable ? Also: same comment here as for?JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. ? L46: "attach" is probably not the best way to describe the operation of jps. It does not attach to the process, it merely lists the running processes. Perhaps runJps() is a better name? test/sun/tools/jstatd/TestJstatdDefaults.java test/sun/tools/jstatd/TestJstatdExternalRegistry.java test/sun/tools/jstatd/TestJstatdPort.java test/sun/tools/jstatd/TestJstatdPortAndServer.java test/sun/tools/jstatd/TestJstatdServer.java ? No comments. test/sun/tools/jstatd/TestJstatdUsage.java ? Same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. test/sun/tools/jstatd/ToolConfig.java ? ToolConfig + Utils.get(Forward)VmOptions() seem to be doing similar things to?JDKToolLauncher in the hotspot testlibrary. It is unfortunate if we have two ways to do similar things in the two different testlibraries. Would it be possible to reuse the hotspot code here instead? ? You have also changed the test. Previously the tools were not launched with the jtreg -vmoptions (test.vm.opts), whereas now they will be. Is this intentional?? General comments: Can't we do: ? * @library /lib/testlibrary instead of ? * @library ../../../lib/testlibrary ? It seems that at least some of the functionality should be reused for re-writing the jstat and jps tests as well. I guess we can look at that at a later time, though. While I applaud the move from shell scripts to Java code, I can't shake the feeling that the shell scripts were easier to read and follow. The Java code is much more verbose and spread out over multiple helpers and libraries, making it harder to grasp. That may be the price we have to pay, though. Thanks, /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131028/e2c494c7/attachment.html From daniel.fuchs at oracle.com Mon Oct 28 06:32:28 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Mon, 28 Oct 2013 13:32:28 +0000 Subject: hg: jdk8/tl/jdk: 8026863: regression in anonymous Logger.setParent method Message-ID: <20131028133301.E4F9C62795@hg.openjdk.java.net> Changeset: af4dd45bc7f7 Author: dfuchs Date: 2013-10-28 10:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af4dd45bc7f7 8026863: regression in anonymous Logger.setParent method Summary: restore behaviour of setParent in anonymous logger and clarifies the spec with respect to security permissions. Reviewed-by: mchung, prr ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/AnonymousLogger/TestAnonymousLogger.java From staffan.larsen at oracle.com Mon Oct 28 11:02:50 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 28 Oct 2013 19:02:50 +0100 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <4e22dbcf-e8f1-47e6-8f43-1d7047811528@default> References: <4e22dbcf-e8f1-47e6-8f43-1d7047811528@default> Message-ID: <0C3DC4C9-53EF-46BD-8733-5851B6D60F4E@oracle.com> Rename JstatdTest.getToolOptions() to JstatdTest.getDestination(). nit: JstatdTest.cleanUpThread() shouldn't be static. Thanks, /Staffan On 28 okt 2013, at 17:12, Yekaterina Kantserova wrote: > Hi, > > http://cr.openjdk.java.net/~ykantser/8022229/webrev.03/ > > Moved ToolConfig functionality to JstatdTest (renamed JstatdHelper) and deleted ToolConfig. The tests are also changed a little: > > public class TestJstatdDefaults { > > public static void main(String[] args) throws Throwable { > JstatdTest test = new JstatdTest(); > test.doTest(); > } > > } > > Hope it looks better now. > > Thanks, > Katja > > ----- Ursprungligt meddelande ----- > Fr?n: staffan.larsen at oracle.com > Till: yekaterina.kantserova at oracle.com > Kopia: serviceability-dev at openjdk.java.net, david.holmes at oracle.com, jaroslav.bachorik at oracle.com,christian.tornqvist at oracle.com, hotspot-dev at openjdk.java.net, mattis.castegren at oracle.com > Skickat: m?ndag, 28 okt 2013 12:57:38 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien > ?mne: Re: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd > > This looks a lot better. Just few more comments: > > ToolConfig.java > L72 - "getToolOptins" -> "getToolOptions" > L35 - why is port stored as a String? Also, could be renamed to rmiRegistryPort to clarify what it is for. > > Why are some tool-specific options added in getToolOptins() and some in the getJpsCmd()/getJstatdCmd()/... methods? Maybe changing getToolOptins() to only return the host part of the options and moving the rest of the setup to getJpsCmd()/getJstatdCmd()/...? > > > Thanks, > /Staffan > > > On 24 okt 2013, at 15:57, Yekaterina Kantserova wrote: > > Hi, > > I've done following big changes after the Staffan's review: > - ported JDKToolLauncher, JDKToolFinder, Plattform from hotspot testlibrary (http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot) for re-using in ToolConfig > - changed "verifiy output form jps, jstat"-methods to ignore warnings from VM > - tools will be launched without -vmoptions > > plus made fixes for all minor comments. > > If it's a good idea to push testlibrary changes separately I can make a separate patch for them. > > Webrev: > http://cr.openjdk.java.net/~ykantser/8022229/webrev.02/ > > Primal bug: > https://bugs.openjdk.java.net/browse/JDK-8022229 > > Similar bugs: > https://bugs.openjdk.java.net/browse/JDK-8019630 > https://bugs.openjdk.java.net/browse/JDK-6636094 > https://bugs.openjdk.java.net/browse/JDK-6543979 > > Thanks, > Katja > > > > On 10/23/2013 12:55 PM, Staffan Larsen wrote: > test/lib/testlibrary/jdk/testlibrary/Asserts.java > Same code as already exists in the hotspot testlibrary. > No further comments. > > > test/lib/testlibrary/jdk/testlibrary/ProcessThread.java > L33: stating -> starting > L66: staring -> starting > > > test/lib/testlibrary/jdk/testlibrary/TestThread.java > This code comes from an internal test library. > No further comments. > > > test/lib/testlibrary/jdk/testlibrary/Utils.java > No comments. > > > test/lib/testlibrary/jdk/testlibrary/XRun.java > This code comes from an internal test library. > No further comments. > > > test/sun/tools/jstatd/JstatGcutilParser.java > The parse() method could be made more robust by discarding any lines that come before the header lines. This can happen if the JVM outputs a warning message for some reason before running jstat. > > I don't like the special-case for the CCS column in verify() - took me a while to find it. Should we add a new enum called PERCENTAGE_OR_DASH to handle that instead? > > L67: getType() should be private. > > > test/sun/tools/jstatd/JstatdHelper.java: > L54: Does verifyJpsOutput() work correctly with output of the form: > > 1234 -- main class information unavailable > 1235 -- process information unavailable > > Also: same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. > > L46: "attach" is probably not the best way to describe the operation of jps. It does not attach to the process, it merely lists the running processes. Perhaps runJps() is a better name? > > > test/sun/tools/jstatd/TestJstatdDefaults.java > test/sun/tools/jstatd/TestJstatdExternalRegistry.java > test/sun/tools/jstatd/TestJstatdPort.java > test/sun/tools/jstatd/TestJstatdPortAndServer.java > test/sun/tools/jstatd/TestJstatdServer.java > No comments. > > > test/sun/tools/jstatd/TestJstatdUsage.java > Same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. > > > test/sun/tools/jstatd/ToolConfig.java > ToolConfig + Utils.get(Forward)VmOptions() seem to be doing similar things to JDKToolLauncher in the hotspot testlibrary. It is unfortunate if we have two ways to do similar things in the two different testlibraries. Would it be possible to reuse the hotspot code here instead? > > You have also changed the test. Previously the tools were not launched with the jtreg -vmoptions (test.vm.opts), whereas now they will be. Is this intentional? > > > General comments: > > Can't we do: > * @library /lib/testlibrary > instead of > * @library ../../../lib/testlibrary > ? > > It seems that at least some of the functionality should be reused for re-writing the jstat and jps tests as well. I guess we can look at that at a later time, though. > > While I applaud the move from shell scripts to Java code, I can't shake the feeling that the shell scripts were easier to read and follow. The Java code is much more verbose and spread out over multiple helpers and libraries, making it harder to grasp. That may be the price we have to pay, though. > > > Thanks, > /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131028/204c6c14/attachment-0001.html From dmitry.samersoff at oracle.com Mon Oct 28 12:09:53 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Mon, 28 Oct 2013 19:09:53 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8026950: Nits in agent ps_proc.c file breaks compilation of open hotspot Message-ID: <20131028191003.C74CB627A0@hg.openjdk.java.net> Changeset: 1a04de1aaedb Author: dsamersoff Date: 2013-10-28 21:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1a04de1aaedb 8026950: Nits in agent ps_proc.c file breaks compilation of open hotspot Summary: Fixed two compilation-breaking nits Reviewed-by: sla, dholmes ! agent/src/os/bsd/ps_proc.c From mandy.chung at oracle.com Mon Oct 28 12:46:24 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 28 Oct 2013 12:46:24 -0700 Subject: RFR: JDK-8027371 Add JDI tests for breakpointing and stepping in lambda code In-Reply-To: References: Message-ID: <526EBF10.4010708@oracle.com> On 10/28/2013 4:10 AM, Staffan Larsen wrote: > We currently don't have any debugger tests that explicitly exercises lambdas. I have created two tests that at least provide some kind of red-face testing. They aren't very comprehensive, but I still think they add value. Agree and these new tests do add value. > webrev: http://cr.openjdk.java.net/~sla/8027371/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8027371 This looks fine to me. Mandy From serguei.spitsyn at oracle.com Mon Oct 28 14:10:13 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 28 Oct 2013 14:10:13 -0700 Subject: RFR: JDK-8027371 Add JDI tests for breakpointing and stepping in lambda code In-Reply-To: References: Message-ID: <526ED2B5.5030102@oracle.com> These are nice to have tests. They look good. Thanks, Serguei On 10/28/13 4:10 AM, Staffan Larsen wrote: > We currently don't have any debugger tests that explicitly exercises lambdas. I have created two tests that at least provide some kind of red-face testing. They aren't very comprehensive, but I still think they add value. > > webrev: http://cr.openjdk.java.net/~sla/8027371/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8027371 > > Thanks, > /Staffan From lana.steuck at oracle.com Mon Oct 28 14:57:28 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 28 Oct 2013 21:57:28 +0000 Subject: hg: jdk8/tl/nashorn: 2 new changesets Message-ID: <20131028215748.D1815627A9@hg.openjdk.java.net> Changeset: 79f7b79bf97b Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/79f7b79bf97b Added tag jdk8-b113 for changeset 676cd7bf5e09 ! .hgtags Changeset: 767e85d2a1b3 Author: lana Date: 2013-10-28 12:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/767e85d2a1b3 Merge From lana.steuck at oracle.com Mon Oct 28 14:57:56 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 28 Oct 2013 21:57:56 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20131028215834.5B5E9627AC@hg.openjdk.java.net> Changeset: 127c2e74d2cf Author: tbell Date: 2013-10-22 16:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/127c2e74d2cf 8027039: [jprt] Remove 32-bit Solaris from jprt.properties files Reviewed-by: mduigou, mchung ! make/jprt.properties Changeset: 54150586ba78 Author: katleman Date: 2013-10-23 08:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/54150586ba78 Merge Changeset: 850d2602ae98 Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/850d2602ae98 Added tag jdk8-b113 for changeset 54150586ba78 ! .hgtags Changeset: 44e3ba40e00c Author: lana Date: 2013-10-28 12:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/44e3ba40e00c Merge From lana.steuck at oracle.com Mon Oct 28 14:57:28 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 28 Oct 2013 21:57:28 +0000 Subject: hg: jdk8/tl/corba: 3 new changesets Message-ID: <20131028215747.A7C6D627A7@hg.openjdk.java.net> Changeset: a259ff3e42d9 Author: tbell Date: 2013-10-22 16:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/a259ff3e42d9 8027039: [jprt] Remove 32-bit Solaris from jprt.properties files Reviewed-by: mduigou, mchung ! make/jprt.properties Changeset: 0bbccf77c23e Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/0bbccf77c23e Added tag jdk8-b113 for changeset a259ff3e42d9 ! .hgtags Changeset: 219e616a6a4f Author: lana Date: 2013-10-28 12:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/219e616a6a4f Merge From lana.steuck at oracle.com Mon Oct 28 14:58:05 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 28 Oct 2013 21:58:05 +0000 Subject: hg: jdk8/tl/jaxp: 3 new changesets Message-ID: <20131028215828.6FE5C627AB@hg.openjdk.java.net> Changeset: 0046d2278204 Author: tbell Date: 2013-10-22 16:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/0046d2278204 8027039: [jprt] Remove 32-bit Solaris from jprt.properties files Reviewed-by: mduigou, mchung ! make/jprt.properties Changeset: 1b1e12117fe2 Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/1b1e12117fe2 Added tag jdk8-b113 for changeset 0046d2278204 ! .hgtags Changeset: 96562bf197f2 Author: lana Date: 2013-10-28 12:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/96562bf197f2 Merge From lana.steuck at oracle.com Mon Oct 28 14:57:34 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 28 Oct 2013 21:57:34 +0000 Subject: hg: jdk8/tl/jaxws: 4 new changesets Message-ID: <20131028215805.27031627AA@hg.openjdk.java.net> Changeset: 17f1b13cd401 Author: simonis Date: 2013-10-21 15:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/17f1b13cd401 8026874: During JAXWS build the newly built JAXP classes should be in the bootclasspath (not only in the classpath) Reviewed-by: erikj ! makefiles/BuildJaxws.gmk Changeset: f20820d1582f Author: katleman Date: 2013-10-22 16:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/f20820d1582f Merge Changeset: 9261f342aa73 Author: tbell Date: 2013-10-22 16:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/9261f342aa73 8027039: [jprt] Remove 32-bit Solaris from jprt.properties files Reviewed-by: mduigou, mchung ! make/jprt.properties Changeset: 9ad289610fc6 Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/9ad289610fc6 Added tag jdk8-b113 for changeset 9261f342aa73 ! .hgtags From lana.steuck at oracle.com Mon Oct 28 15:00:19 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 28 Oct 2013 22:00:19 +0000 Subject: hg: jdk8/tl/hotspot: 70 new changesets Message-ID: <20131028220619.772AB627AD@hg.openjdk.java.net> Changeset: 7c26dced065e Author: amurillo Date: 2013-10-11 13:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7c26dced065e 8026265: new hotspot build - hs25-b55 Reviewed-by: jcoomes ! make/hotspot_version Changeset: b4a4fdc1f464 Author: coleenp Date: 2013-10-09 21:45 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b4a4fdc1f464 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::compare_entry_to and copy_entry_to Summary: Add missing cases. Reviewed-by: sspitsyn, dcubed ! src/share/vm/oops/constantPool.cpp Changeset: e831448418ac Author: coleenp Date: 2013-10-09 22:01 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e831448418ac Merge Changeset: cd7ea1d79dac Author: sla Date: 2013-10-11 13:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd7ea1d79dac 8026199: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Compilation failed Summary: Fixed a compilation failure due to changed method name Reviewed-by: sla, jbachorik Contributed-by: fredrik.arvidsson at oracle.com ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 539144972c1e Author: sla Date: 2013-10-11 14:08 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/539144972c1e 8024425: VM_HeapDumper doesn't put anonymous classes in the heap dump Summary: Switched from using SystemDictionary to using ClassLoaderDataGraph to get the anonymous classes included. Reviewed-by: sla, sspitsyn Contributed-by: fredrik.arvidsson at oracle.com ! src/share/vm/services/heapDumper.cpp Changeset: 301ece1880ad Author: sla Date: 2013-10-11 14:57 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/301ece1880ad Merge Changeset: 28ca974cc21a Author: coleenp Date: 2013-10-11 11:23 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/28ca974cc21a 8022592: assert at constantTag.cpp:57: ShouldNotReachHere() Summary: more missing cases for JVM_CONSTANT_Method{Handle,Type}InError Reviewed-by: hseigel, dcubed ! src/share/vm/oops/constantPool.cpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: 26ae62bc26c4 Author: coleenp Date: 2013-10-11 15:04 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/26ae62bc26c4 Merge Changeset: 0db3ba3f6870 Author: hseigel Date: 2013-10-11 15:33 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0db3ba3f6870 8026041: JVM crashes with assert "assert(is_updated()) failed: must not be clear" with -XX:+PrintGCApplicationConcurrentTime in -Xcomp mode Summary: Prior to printing the time interval in RuntimeService::record_safepoint_begin(), check first that VM initialization is complete. Reviewed-by: coleenp, dholmes, sla, ctornqvi Contributed-by: lois.foltan at oracle.com ! src/share/vm/services/runtimeService.cpp Changeset: df268195b0ea Author: hseigel Date: 2013-10-11 17:08 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/df268195b0ea Merge Changeset: 41459da469ae Author: ccheung Date: 2013-10-11 18:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/41459da469ae Merge Changeset: 83dbf427fedd Author: ccheung Date: 2013-10-11 22:22 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/83dbf427fedd Merge Changeset: 3e265ce4d2dd Author: hseigel Date: 2013-10-12 13:09 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3e265ce4d2dd 8025942: os::Bsd::available_memory() needs implementation Summary: Implement using the host_statistics64() api. Reviewed-by: dsamersoff, morris, dholmes, coleenp, hseigel, dcubed Contributed-by: gerard.ziemski at oracle.com ! src/os/bsd/vm/os_bsd.cpp Changeset: d37a0525c0fe Author: hseigel Date: 2013-10-12 15:39 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d37a0525c0fe 8024667: VM crashes with "assert(method() != NULL) failed: must have set method" Summary: Check if data is in shared spaces before deallocating it. Reviewed-by: coleenp, dcubed ! src/share/vm/memory/metadataFactory.hpp ! src/share/vm/oops/instanceKlass.cpp Changeset: 2f8728d92483 Author: acorn Date: 2013-10-14 21:52 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2f8728d92483 8026299: invokespecial gets ICCE when it should get AME. Reviewed-by: ccheung, coleenp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp Changeset: f509b8f4699b Author: dcubed Date: 2013-10-15 08:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f509b8f4699b 7165611: implement Full Debug Symbols on MacOS X hotspot Summary: Add MacOS X FDS support to hotspot; add minimal MacOS X FDS import support to jdk; add MacOS X FDS support to install; add MacOS X FDS support to root. Reviewed-by: erikj, sla, dholmes, rdurbin, tbell, ihse ! make/Makefile ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/jsig.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/universal.gmk ! make/bsd/makefiles/vm.make ! make/defs.make Changeset: e8703d708e6e Author: ccheung Date: 2013-10-16 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e8703d708e6e Merge Changeset: 1e814e391ee8 Author: anoll Date: 2013-10-04 09:19 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1e814e391ee8 8025656: compiler/8013496/Test8013496.sh fails on assert Summary: Ensure the thread is in correct state; rewrote test in Java Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp - test/compiler/8013496/Test8013496.sh + test/compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java Changeset: 0c4c40f5c399 Author: twisti Date: 2013-10-04 10:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0c4c40f5c399 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods Reviewed-by: kvn, roland ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/parse.hpp Changeset: 5f1241525a01 Author: twisti Date: 2013-10-04 19:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5f1241525a01 Merge Changeset: bf8a21c3ab3b Author: vlivanov Date: 2013-10-07 14:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf8a21c3ab3b 8025849: Redundant "pid" in VM log file name (e.g. hotspot_pidpid12345.log) Reviewed-by: twisti, azeemj ! src/share/vm/utilities/ostream.cpp Changeset: 5cc2d82aa82a Author: vlivanov Date: 2013-10-07 14:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5cc2d82aa82a 8024943: ciReplay: fails to dump replay data during safepointing Reviewed-by: kvn, twisti ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/utilities/vmError.cpp Changeset: f478c98e8114 Author: vlivanov Date: 2013-10-07 14:12 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f478c98e8114 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range Reviewed-by: iveresov, roland, kvn, twisti ! src/share/vm/opto/parse2.cpp Changeset: 5741fc86a2ee Author: vlivanov Date: 2013-10-07 14:13 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5741fc86a2ee 8025845: Default methods are unnecessarily marked w/ force_inline directive in some situations Reviewed-by: acorn, kvn ! src/share/vm/classfile/defaultMethods.cpp Changeset: c775af091fe9 Author: twisti Date: 2013-10-07 10:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c775af091fe9 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method Reviewed-by: kvn ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/parseHelper.cpp Changeset: d9043b88eeb3 Author: roland Date: 2013-10-03 10:55 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d9043b88eeb3 8024067: Missing replace_in_map() calls following null checks Summary: add replace_in_map() calls following some null checks in type checks Reviewed-by: kvn ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp Changeset: 17cda06bcb7d Author: iveresov Date: 2013-10-08 07:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/17cda06bcb7d Merge ! src/share/vm/classfile/defaultMethods.cpp - test/compiler/8013496/Test8013496.sh Changeset: 6171eb9da4fd Author: twisti Date: 2013-10-08 19:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6171eb9da4fd 8007923: Tests on references fails Reviewed-by: kvn, iveresov ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/opto/escape.cpp Changeset: 98692a2d36d7 Author: adlertz Date: 2013-10-09 13:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/98692a2d36d7 8013830: [parfait] Uninitialised pointer 'Reachblock' may be used as argument Summary: Replace uninitialised pointer with NULL at argument. Reviewed-by: kvn, roland, twisti ! src/share/vm/opto/reg_split.cpp Changeset: 4e7f99b70d9d Author: adlertz Date: 2013-10-09 05:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4e7f99b70d9d Merge - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java Changeset: 46ef27bcacb3 Author: twisti Date: 2013-10-09 11:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/46ef27bcacb3 8020750: Node::get_int: guarantee(t != NULL) failed: must be con Reviewed-by: kvn, roland ! src/share/vm/opto/ifnode.cpp Changeset: d13d7aba8c12 Author: roland Date: 2013-10-09 16:32 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d13d7aba8c12 8023657: New type profiling points: arguments to call Summary: x86 interpreter and c1 type profiling for arguments at calls Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciKlass.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObjArrayKlass.hpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciTypeArrayKlass.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp Changeset: 8b80b262e501 Author: twisti Date: 2013-10-11 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8b80b262e501 8005173: assert(false) failed: DEBUG MESSAGE: exception oop must be empty (macroAssembler_x86.cpp:625) Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/thread.hpp Changeset: d8a449d2f5b2 Author: adlertz Date: 2013-10-11 13:10 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d8a449d2f5b2 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: Summary: Increased the LRG AllStack mask size since the previous size was not big enough when compiling huge methods (60k+ nodes) Reviewed-by: kvn, roland, twisti ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/ifg.cpp Changeset: 2348b2726e1d Author: adlertz Date: 2013-10-11 19:16 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2348b2726e1d Merge Changeset: dd2cf1d1248b Author: adlertz Date: 2013-10-12 01:29 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dd2cf1d1248b Merge Changeset: 469216acdb28 Author: anoll Date: 2013-10-10 15:44 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/469216acdb28 8023014: CodeSweeperSweepNoFlushTest.java fails with HS crash Summary: Ensure ensure correct initialization of compiler runtime Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_Compiler.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/compiler/abstractCompiler.cpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/c2compiler.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkCompiler.hpp + test/compiler/startup/SmallCodeCacheStartup.java Changeset: ed2c74787eb5 Author: twisti Date: 2013-10-11 19:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ed2c74787eb5 Merge Changeset: ce0cc25bc5e2 Author: roland Date: 2013-10-12 12:12 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ce0cc25bc5e2 8026054: New type profiling points: type of return values at calls Summary: x86 interpreter and c1 type profiling for return values at calls Reviewed-by: kvn, twisti ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp Changeset: f50418dfb1b7 Author: iveresov Date: 2013-10-13 13:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f50418dfb1b7 Merge ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp - test/compiler/8013496/Test8013496.sh Changeset: e504cd481ec0 Author: twisti Date: 2013-10-14 19:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e504cd481ec0 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set Reviewed-by: kvn ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp Changeset: 8df6f123d35e Author: drchase Date: 2013-10-12 17:26 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8df6f123d35e 8026124: JSR-292 bug: java.nio.file.Path.toString cores dump Summary: catch problem case, assert it matches valid input, new test Reviewed-by: jrose, twisti, kvn ! src/share/vm/interpreter/linkResolver.cpp + test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java + test/compiler/jsr292/createsInterfaceDotEqualsCallInfo.js Changeset: f91a9a696e5e Author: kvn Date: 2013-10-15 12:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f91a9a696e5e 8026293: Schedule part of G1 pre-barrier late Summary: move rare executed part of G1 write barrier from hot path. Reviewed-by: kvn, twisti, roland Contributed-by: staffan.friberg at oracle.com ! src/share/vm/opto/graphKit.cpp Changeset: 1263c7e17e1c Author: kvn Date: 2013-10-15 17:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1263c7e17e1c Merge Changeset: 4a2acfb16e97 Author: rbackman Date: 2013-10-11 12:06 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4a2acfb16e97 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 Reviewed-by: kvn, twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/mathexactnode.cpp ! src/share/vm/opto/mathexactnode.hpp + test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 90abdd727e64 Author: iveresov Date: 2013-10-16 11:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/90abdd727e64 8009303: Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 Summary: Do memory flow analysis in string concat optimizier to exclude cases when computation of arguments to StringBuffer::append has side effects Reviewed-by: kvn, twisti ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/stringopts.cpp Changeset: 8f4bb1773fd9 Author: iveresov Date: 2013-10-17 10:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8f4bb1773fd9 Merge ! src/share/vm/interpreter/linkResolver.cpp - test/compiler/8013496/Test8013496.sh Changeset: 7114c4597ae3 Author: acorn Date: 2013-10-17 23:30 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7114c4597ae3 8026365: NoClassDefinitionFound for anonymous class invokespecial. Reviewed-by: dcubed, kamg ! src/share/vm/classfile/verifier.cpp ! test/TEST.groups Changeset: 9c8289162268 Author: jwilhelm Date: 2013-10-11 16:18 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9c8289162268 8024776: Max/MinHeapFreeRatio descriptions should be more precise Summary: Descriptions for Max/MinHeapFreeRatio updated Reviewed-by: ehelin, jmasa ! src/share/vm/runtime/globals.hpp Changeset: 2382ff14d889 Author: jwilhelm Date: 2013-10-12 05:08 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2382ff14d889 Merge ! src/share/vm/runtime/globals.hpp Changeset: 24f32d09a0d7 Author: jwilhelm Date: 2013-10-12 00:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/24f32d09a0d7 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize Summary: Exit with an error if incompatible NewSize and MaxNeSize are set Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: d6818f623792 Author: tschatzl Date: 2013-10-15 11:18 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d6818f623792 8026186: gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java Compilation failed Summary: After a method rename in JDK-8014905 the mentioned test did not compile any more. Fix the uses of the affected method. Reviewed-by: jwilhelm, mgerdin, jmasa ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 027006a47a6d Author: sjohanss Date: 2013-10-14 14:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/027006a47a6d 8025661: Ill-formed -Xminf and -Xmaxf options values interpreted as 0 Summary: Using strtod() instead of atof() when parsing -Xminf and -Xmaxf. Reviewed-by: brutisso, pliden ! src/share/vm/runtime/arguments.cpp + test/gc/arguments/TestHeapFreeRatio.java Changeset: 82fcc0567fef Author: mgerdin Date: 2013-10-15 04:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/82fcc0567fef Merge Changeset: 6f1919cfd18c Author: pliden Date: 2013-10-15 11:38 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6f1919cfd18c 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full gcs, expect 0 full gcs Reviewed-by: brutisso, tschatzl ! test/TEST.groups - test/gc/7168848/HumongousAlloc.java + test/gc/g1/TestHumongousAllocInitialMark.java Changeset: bfd52054aeb8 Author: pliden Date: 2013-10-15 11:42 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bfd52054aeb8 8024632: Description of InitialSurvivorRatio flag in globals.hpp is incorrect Reviewed-by: brutisso, tschatzl, kmo, tamao ! src/share/vm/runtime/globals.hpp Changeset: 041c5da41ac4 Author: pliden Date: 2013-10-15 11:44 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/041c5da41ac4 8024634: gc/startup_warnings tests can fail due to unrelated warnings Reviewed-by: brutisso, jwilhelm, tamao ! test/gc/startup_warnings/TestCMS.java ! test/gc/startup_warnings/TestCMSNoIncrementalMode.java ! test/gc/startup_warnings/TestG1.java ! test/gc/startup_warnings/TestParNewCMS.java ! test/gc/startup_warnings/TestParallelGC.java ! test/gc/startup_warnings/TestParallelScavengeSerialOld.java ! test/gc/startup_warnings/TestSerialGC.java Changeset: f16726924734 Author: stefank Date: 2013-10-15 07:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f16726924734 Merge - test/gc/7168848/HumongousAlloc.java Changeset: bdfbb1fb19ca Author: stefank Date: 2013-10-15 14:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bdfbb1fb19ca 8026391: The Metachunk header wastes memory Reviewed-by: coleenp, jmasa ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeList.cpp - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ec2e26e26183 Author: stefank Date: 2013-10-15 14:32 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ec2e26e26183 8026392: Metachunks and Metablocks are using a too large alignment Reviewed-by: coleenp, jmasa ! src/share/vm/memory/metachunk.cpp Changeset: 9e5fadad7fdf Author: tschatzl Date: 2013-10-16 11:46 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9e5fadad7fdf 8025925: jmap fails with "field _length not found in type HeapRegionSeq" Summary: The change JDK-7163191 changed the data layout of a class that is referenced by the java code of the SA agent. This fix synchronizes the SA agent with that change. Reviewed-by: sla, mgerdin + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1HeapRegionTable.java ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java Changeset: 28df60a5badf Author: stefank Date: 2013-10-17 08:41 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/28df60a5badf 8026707: JDK-8026391 broke the optimized build target Reviewed-by: mgerdin, coleenp ! src/share/vm/memory/metachunk.hpp Changeset: 94c0343b1887 Author: stefank Date: 2013-10-17 08:42 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/94c0343b1887 8026715: Remove the MetaDataDeallocateALot develop flag Reviewed-by: coleenp, mgerdin ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/globals.hpp Changeset: bf9e50c573ad Author: jmasa Date: 2013-10-17 06:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf9e50c573ad 8025635: SoftReferences are not cleared before metaspace OOME are thrown Reviewed-by: jcoomes, tamao, tschatzl, stefank ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp Changeset: c51cd6af7e61 Author: jcoomes Date: 2013-10-18 12:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c51cd6af7e61 Merge ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! test/TEST.groups - test/compiler/8013496/Test8013496.sh ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 23b8db5ea31d Author: amurillo Date: 2013-10-18 21:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/23b8db5ea31d Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: e8cbdc701bfb Author: amurillo Date: 2013-10-18 21:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e8cbdc701bfb Added tag hs25-b55 for changeset 23b8db5ea31d ! .hgtags Changeset: 4589b398ab03 Author: amurillo Date: 2013-10-22 13:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4589b398ab03 Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: 4a1128861221 Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4a1128861221 Added tag jdk8-b113 for changeset 4589b398ab03 ! .hgtags Changeset: 0e55a181cb08 Author: lana Date: 2013-10-28 12:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0e55a181cb08 Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java From lana.steuck at oracle.com Mon Oct 28 15:00:46 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 28 Oct 2013 22:00:46 +0000 Subject: hg: jdk8/tl/jdk: 17 new changesets Message-ID: <20131028220823.22094627AF@hg.openjdk.java.net> Changeset: 01b81253f2d5 Author: dcubed Date: 2013-10-15 08:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01b81253f2d5 7165611: implement Full Debug Symbols on MacOS X hotspot Summary: Add MacOS X FDS support to hotspot; add minimal MacOS X FDS import support to jdk; add MacOS X FDS support to install; add MacOS X FDS support to root. Reviewed-by: erikj, sla, dholmes, rdurbin, tbell, ihse ! make/common/Defs-macosx.gmk ! make/common/Defs.gmk ! make/java/redist/Makefile ! makefiles/Import.gmk ! makefiles/Tools.gmk Changeset: 969e8c6c26cc Author: amurillo Date: 2013-10-19 08:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/969e8c6c26cc Merge ! makefiles/Import.gmk ! makefiles/Tools.gmk Changeset: c4ab67d1e0ce Author: amurillo Date: 2013-10-22 13:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4ab67d1e0ce Merge ! makefiles/Tools.gmk Changeset: a5b57fca66da Author: ihse Date: 2013-10-16 20:24 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a5b57fca66da 8025715: Split CompileNativeLibraries.gmk Reviewed-by: erikj ! makefiles/CompileNativeLibraries.gmk + makefiles/lib/Awt2dLibraries.gmk + makefiles/lib/CoreLibraries.gmk + makefiles/lib/NetworkingLibraries.gmk + makefiles/lib/NioLibraries.gmk + makefiles/lib/PlatformLibraries.gmk + makefiles/lib/SecurityLibraries.gmk + makefiles/lib/ServiceabilityLibraries.gmk + makefiles/lib/SoundLibraries.gmk Changeset: 1e99d539088d Author: katleman Date: 2013-10-18 15:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1e99d539088d Merge Changeset: 7ec4ddc36ad6 Author: erikj Date: 2013-10-17 16:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ec4ddc36ad6 8019540: licensee reports a JDK8 build failure after 8005849/8005008 fixes integrated. Reviewed-by: dholmes, sla ! makefiles/CopyIntoClasses.gmk Changeset: 11e90e4167d4 Author: erikj Date: 2013-10-21 10:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11e90e4167d4 Merge Changeset: 3a6ac3484b05 Author: cl Date: 2013-10-21 23:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3a6ac3484b05 8026974: solaris build missing java-rmi.cgi Reviewed-by: ksrini ! makefiles/CompileLaunchers.gmk Changeset: b121e84392fa Author: erikj Date: 2013-10-22 11:59 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b121e84392fa 8026966: Most native libs broken on mac in jdk8/build Reviewed-by: ihse, anthony ! makefiles/lib/PlatformLibraries.gmk Changeset: 9850efaedc50 Author: katleman Date: 2013-10-22 16:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9850efaedc50 Merge ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk + makefiles/lib/Awt2dLibraries.gmk + makefiles/lib/CoreLibraries.gmk + makefiles/lib/NetworkingLibraries.gmk + makefiles/lib/NioLibraries.gmk + makefiles/lib/PlatformLibraries.gmk + makefiles/lib/SecurityLibraries.gmk + makefiles/lib/ServiceabilityLibraries.gmk + makefiles/lib/SoundLibraries.gmk Changeset: 698937f18761 Author: tbell Date: 2013-10-22 16:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/698937f18761 8027039: [jprt] Remove 32-bit Solaris from jprt.properties files Reviewed-by: mduigou, mchung ! make/jprt.properties ! makefiles/jprt.properties Changeset: 81431a7c17cf Author: tbell Date: 2013-10-22 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81431a7c17cf Merge - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m - src/share/classes/com/sun/jdi/connect/package.html - src/share/classes/com/sun/jdi/connect/spi/package.html - src/share/classes/com/sun/jdi/event/package.html - src/share/classes/com/sun/jdi/package.html - src/share/classes/com/sun/jdi/request/package.html - src/share/classes/com/sun/management/package.html - src/share/classes/com/sun/tools/attach/package.html - src/share/classes/com/sun/tools/attach/spi/package.html - src/share/classes/com/sun/tools/jconsole/package.html - src/share/classes/java/net/HttpURLPermission.java - test/com/oracle/security/ucrypto/TestAES.java - test/com/oracle/security/ucrypto/TestDigest.java - test/com/oracle/security/ucrypto/TestRSA.java - test/com/oracle/security/ucrypto/UcryptoTest.java - test/java/net/HttpURLPermission/HttpURLPermissionTest.java - test/java/net/HttpURLPermission/URLTest.java - test/java/net/HttpURLPermission/policy.1 - test/java/net/HttpURLPermission/policy.2 - test/java/net/HttpURLPermission/policy.3 Changeset: aabaae5de1ee Author: ihse Date: 2013-10-23 13:06 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aabaae5de1ee 8001922: Improve freetype handling. Reviewed-by: erikj ! makefiles/CopyFiles.gmk ! makefiles/lib/Awt2dLibraries.gmk Changeset: ab0e61a57df7 Author: chegar Date: 2013-10-23 13:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ab0e61a57df7 8027059: (sctp) fatal warnings overly restrictive with gcc 4.8.1 Reviewed-by: mduigou, dxu, erikj, ihse ! makefiles/lib/NioLibraries.gmk Changeset: 5b4261b4b72a Author: erikj Date: 2013-10-23 17:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5b4261b4b72a 8026888: Licensee build failure due to wrong libs being called Reviewed-by: tbell, ihse, simonis ! makefiles/lib/Awt2dLibraries.gmk Changeset: b88aa723a5fa Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b88aa723a5fa Added tag jdk8-b113 for changeset 5b4261b4b72a ! .hgtags Changeset: e7639b856256 Author: lana Date: 2013-10-28 12:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7639b856256 Merge From lana.steuck at oracle.com Mon Oct 28 14:57:39 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 28 Oct 2013 21:57:39 +0000 Subject: hg: jdk8/tl: 17 new changesets Message-ID: <20131028215745.39395627A6@hg.openjdk.java.net> Changeset: 22c6f0b7e2b5 Author: dcubed Date: 2013-10-15 08:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/22c6f0b7e2b5 7165611: implement Full Debug Symbols on MacOS X hotspot Summary: Add MacOS X FDS support to hotspot; add minimal MacOS X FDS import support to jdk; add MacOS X FDS support to install; add MacOS X FDS support to root. Reviewed-by: erikj, sla, dholmes, rdurbin, tbell, ihse ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/makefiles/NativeCompilation.gmk Changeset: ac09e62d5e6b Author: amurillo Date: 2013-10-19 08:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ac09e62d5e6b Merge ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/makefiles/NativeCompilation.gmk Changeset: 9d5284dfc00d Author: amurillo Date: 2013-10-22 13:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/9d5284dfc00d Merge Changeset: 5b4f14990dd1 Author: ihse Date: 2013-10-18 10:41 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/5b4f14990dd1 8001912: Improve detection of msvcr100.dll Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 ! common/autoconf/toolchain_windows.m4 Changeset: 65c1752b4c38 Author: katleman Date: 2013-10-18 15:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/65c1752b4c38 Merge Changeset: 17d195bd56fc Author: erikj Date: 2013-10-18 11:34 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/17d195bd56fc 8025869: make docs doesn't regenerate docs correctly after changing API doc comments in jaxp sources Reviewed-by: ihse, tbell ! common/makefiles/JavaCompilation.gmk Changeset: e27dda53d4f5 Author: erikj Date: 2013-10-21 10:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e27dda53d4f5 Merge Changeset: 1a853fac18ff Author: erikj Date: 2013-10-21 11:59 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1a853fac18ff 8026528: [build] configure does not recognize newer make in cygwin Reviewed-by: tbell, ksrini, ihse ! NewMakefile.gmk ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: dffe654ab24c Author: ihse Date: 2013-10-22 11:12 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/dffe654ab24c 8001925: Add useful help messages if freetype is not found on Windows Reviewed-by: erikj, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 Changeset: 56db38956113 Author: ihse Date: 2013-10-22 12:29 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/56db38956113 8026864: Deprecate --disable-macosx-runtime-support. Reviewed-by: erikj ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: 9e177e7fc438 Author: katleman Date: 2013-10-22 14:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/9e177e7fc438 Merge ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/makefiles/JavaCompilation.gmk Changeset: 4293401d683b Author: katleman Date: 2013-10-22 16:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4293401d683b 8027068: Update to NewMakefile.gmk check of MAKE_VERSION broke jdk8-build nightly builds on windows, saying 3.82.90 is too low Reviewed-by: ihse, tbell, wetmore ! NewMakefile.gmk Changeset: 269497597620 Author: tbell Date: 2013-10-22 16:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/269497597620 8027039: [jprt] Remove 32-bit Solaris from jprt.properties files Reviewed-by: mduigou, mchung ! make/jprt.properties Changeset: 2cc1a52d37ef Author: tbell Date: 2013-10-22 16:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2cc1a52d37ef Merge Changeset: 6f19b2440412 Author: ihse Date: 2013-10-23 13:05 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6f19b2440412 8001922: Improve freetype handling. Reviewed-by: erikj ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/libraries.m4 ! common/autoconf/spec.gmk.in Changeset: 6ba4c7cb623e Author: erikj Date: 2013-10-23 17:03 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6ba4c7cb623e 8026888: Licensee build failure due to wrong libs being called Reviewed-by: tbell, ihse, simonis ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: a36df87b3901 Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/a36df87b3901 Added tag jdk8-b113 for changeset 6ba4c7cb623e ! .hgtags From staffan.larsen at oracle.com Tue Oct 29 00:03:10 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 29 Oct 2013 08:03:10 +0100 Subject: RFR: JDK-8027371 Add JDI tests for breakpointing and stepping in lambda code In-Reply-To: <526ED2B5.5030102@oracle.com> References: <526ED2B5.5030102@oracle.com> Message-ID: Mandy, Serguei: Thanks for the reviews! On 28 okt 2013, at 22:10, serguei.spitsyn at oracle.com wrote: > These are nice to have tests. > They look good. > > Thanks, > Serguei > > On 10/28/13 4:10 AM, Staffan Larsen wrote: >> We currently don't have any debugger tests that explicitly exercises lambdas. I have created two tests that at least provide some kind of red-face testing. They aren't very comprehensive, but I still think they add value. >> >> webrev: http://cr.openjdk.java.net/~sla/8027371/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8027371 >> >> Thanks, >> /Staffan > From staffan.larsen at oracle.com Tue Oct 29 00:11:10 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Tue, 29 Oct 2013 07:11:10 +0000 Subject: hg: jdk8/tl/jdk: 8027371: Add JDI tests for breakpointing and stepping in lambda code Message-ID: <20131029071153.B9D09627D3@hg.openjdk.java.net> Changeset: ecba02f6be31 Author: sla Date: 2013-10-29 08:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ecba02f6be31 8027371: Add JDI tests for breakpointing and stepping in lambda code Reviewed-by: mchung, sspitsyn + test/com/sun/jdi/LambdaBreakpointTest.java + test/com/sun/jdi/LambdaStepTest.java From sean.coffey at oracle.com Tue Oct 29 05:05:11 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Tue, 29 Oct 2013 12:05:11 +0000 Subject: hg: jdk8/tl/jdk: 8026772: test/sun/util/resources/TimeZone/Bug6317929.java failing Message-ID: <20131029120539.8C2F6627D9@hg.openjdk.java.net> Changeset: d34c5e860d5f Author: aefimov Date: 2013-10-24 17:23 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d34c5e860d5f 8026772: test/sun/util/resources/TimeZone/Bug6317929.java failing Reviewed-by: okutsu, mfang, alanb ! test/ProblemList.txt ! test/sun/util/resources/TimeZone/Bug6317929.java From james.laskey at oracle.com Tue Oct 29 07:40:02 2013 From: james.laskey at oracle.com (james.laskey at oracle.com) Date: Tue, 29 Oct 2013 14:40:02 +0000 Subject: hg: jdk8/tl/nashorn: 3 new changesets Message-ID: <20131029144010.7ED48627E6@hg.openjdk.java.net> Changeset: 7985ec3782b5 Author: hannesw Date: 2013-10-25 10:20 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/7985ec3782b5 8027042: Evaluation order for binary operators can be improved Reviewed-by: lagergren, jlaskey, attila ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk/nashorn/internal/ir/Expression.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/ir/UnaryNode.java + test/script/basic/JDK-8027042.js + test/script/basic/JDK-8027042.js.EXPECTED Changeset: 71cfb21c68dc Author: hannesw Date: 2013-10-25 15:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/71cfb21c68dc 8027301: Optimizations for Function.prototype.apply Reviewed-by: jlaskey ! src/jdk/nashorn/internal/runtime/CompiledFunctions.java ! src/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java Changeset: 406f2b672937 Author: jlaskey Date: 2013-10-29 10:40 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/406f2b672937 Merge From staffan.larsen at oracle.com Tue Oct 29 07:41:50 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 29 Oct 2013 15:41:50 +0100 Subject: RFR(S): 7145419 com/sun/jdi/JdbMethodExitTest.sh fails when a background thread is generating events. Message-ID: This test fails if there are background threads that run while the test is running. I've modified the test to use the "trace" commands in jdb with the extra thread parameter. I have assumed that the main thread has thread id 1. "trace" with thread id behaves a little bit different so a couple of extra "cont" were needed. webrev: http://cr.openjdk.java.net/~sla/7145419/webrev.00/ Thanks, /Staffan From james.laskey at oracle.com Tue Oct 29 07:48:40 2013 From: james.laskey at oracle.com (james.laskey at oracle.com) Date: Tue, 29 Oct 2013 14:48:40 +0000 Subject: hg: jdk8/tl: 26 new changesets Message-ID: <20131029144841.CDF68627EA@hg.openjdk.java.net> Changeset: 3dc55f0c1b6f Author: jlaskey Date: 2013-01-28 16:29 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3dc55f0c1b6f 8006676: Integrate Nashorn into new build system Reviewed-by: jlaskey Contributed-by: james.laskey at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/bin/compare.sh ! common/makefiles/Main.gmk ! common/makefiles/MakeBase.gmk + make/nashorn-rules.gmk ! make/scripts/hgforest.sh Changeset: ecd447139a39 Author: jlaskey Date: 2013-02-04 17:30 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ecd447139a39 Merge ! common/autoconf/generated-configure.sh Changeset: 9ed388a04fa7 Author: jlaskey Date: 2013-02-06 13:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/9ed388a04fa7 8007666: nashorn missing from hgforest.sh Reviewed-by: jlaskey Contributed-by: james.laskey at oracle.com ! common/bin/hgforest.sh Changeset: 8b19b55f695d Author: jlaskey Date: 2013-02-18 19:01 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8b19b55f695d 8008420: Fix Nashorn forest to build with NEWBUILD=false Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! Makefile ! make/nashorn-rules.gmk Changeset: f9a1cb245484 Author: jlaskey Date: 2013-02-19 10:02 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f9a1cb245484 8008446: Tweaks to make all NEWBUILD=false round 2 Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! make/Defs-internal.gmk Changeset: 887fde71977e Author: jlaskey Date: 2013-02-21 15:25 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/887fde71977e 8008447: Tweaks to make all NEWBUILD=false round 3 Reviewed-by: jjh, sundar Contributed-by: james.laskey at oracle.com ! make/jdk-rules.gmk ! make/sanity-rules.gmk Changeset: e877cb3eb4d6 Author: jlaskey Date: 2013-02-22 13:09 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e877cb3eb4d6 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/bin/hgforest.sh ! common/makefiles/Main.gmk Changeset: 528a9984198f Author: jlaskey Date: 2013-02-22 22:58 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/528a9984198f 8008774: nashorn missing from dependencies after merge with tl Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! common/makefiles/Main.gmk Changeset: 13ddc5c3ebfc Author: jlaskey Date: 2013-03-02 10:28 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/13ddc5c3ebfc Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/bin/hgforest.sh ! common/makefiles/Main.gmk ! make/nashorn-rules.gmk Changeset: 1d38d30196be Author: jlaskey Date: 2013-03-08 14:44 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1d38d30196be Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: b938d5ee29c3 Author: jlaskey Date: 2013-03-15 11:50 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b938d5ee29c3 Merge Changeset: fe5a388bf8fe Author: jlaskey Date: 2013-03-26 09:13 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/rev/fe5a388bf8fe Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: 1378ccca1c79 Author: jlaskey Date: 2013-04-09 08:35 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1378ccca1c79 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/bin/hgforest.sh ! common/makefiles/Main.gmk Changeset: 8a7e97848471 Author: jlaskey Date: 2013-04-15 08:06 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8a7e97848471 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: 6316aefcf716 Author: jlaskey Date: 2013-04-17 08:47 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6316aefcf716 Merge Changeset: dd81e9b5fb38 Author: jlaskey Date: 2013-04-22 13:59 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/rev/dd81e9b5fb38 Merge Changeset: 431d16ddfcd9 Author: jlaskey Date: 2013-04-29 21:37 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/rev/431d16ddfcd9 Merge Changeset: 1fca390200c1 Author: jlaskey Date: 2013-05-14 09:04 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1fca390200c1 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: 67b5cbe55744 Author: jlaskey Date: 2013-05-23 09:48 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/rev/67b5cbe55744 Merge Changeset: de886178f8e6 Author: jlaskey Date: 2013-06-05 13:08 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/rev/de886178f8e6 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in Changeset: 520fd54a7c43 Author: jlaskey Date: 2013-07-16 09:08 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/rev/520fd54a7c43 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: 67dc3d7d5b5f Author: jlaskey Date: 2013-07-24 08:23 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/rev/67dc3d7d5b5f Merge ! common/autoconf/generated-configure.sh Changeset: 96f207364e46 Author: jlaskey Date: 2013-08-27 16:05 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/rev/96f207364e46 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: ddf76977d04a Author: jlaskey Date: 2013-09-13 10:14 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ddf76977d04a Merge ! common/autoconf/generated-configure.sh ! common/bin/hgforest.sh ! common/makefiles/Main.gmk Changeset: 8b92b08993a8 Author: jlaskey Date: 2013-09-30 10:23 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8b92b08993a8 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in Changeset: d832f6171acd Author: jlaskey Date: 2013-10-29 11:48 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d832f6171acd Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/bin/hgforest.sh ! common/makefiles/Main.gmk From alex.schenkman at oracle.com Tue Oct 29 07:53:54 2013 From: alex.schenkman at oracle.com (Alex Schenkman) Date: Tue, 29 Oct 2013 15:53:54 +0100 Subject: RFR 8014506: Test for Jdp (Java Discovery Protocol) feature In-Reply-To: <4EDB8911-E772-4B13-B0EB-AA90C729A49A@oracle.com> References: <51A31867.9080602@oracle.com> <51CAC09B.7070706@oracle.com> <7E2E50A8-1FB1-429B-8AAB-94863C215623@oracle.com> <51D56A11.5030600@oracle.com> <5214AC0A.4010603@oracle.com> <70F043F0-9F19-4761-B175-1D6652B5A146@oracle.com> <3B20B5DC-9E92-4EB6-97FF-0F2D2B4E1E10@oracle.com> <52244497.8010902@oracle.com> <5267C65A.9060602@oracle.com> <4EDB8911-E772-4B13-B0EB-AA90C729A49A@oracle.com> Message-ID: <526FCC02.3050308@oracle.com> Hi Staffan, There is a new webrev here [1], addressing your comments. The Jdp specs have changed a bit, adding three optional fields to the Jdp packet [2]. The JEP-168 [3] is not updated yet, but Dmitry will do it soon. This enhancement request is tracking the changes needed for SQE [4]. See inlined answers for details on your previos comments, please. Thanks! [1] http://cr.openjdk.java.net/~dsamersoff/sponsorship/aschenkman/8014506/webrev.04/ [2] https://bugs.openjdk.java.net/browse/JDK-8004213 [3] http://openjdk.java.net/jeps/168 [4] https://bugs.openjdk.java.net/browse/JDK-8027436 On 2013-10-24 10:54, Staffan Larsen wrote: > Alex, > > test/sun/management/jdp/README > Thanks for providing a README! > References to JDK-7169888 seem incorrect to me. > L8: "written by" appears twice. > L11: "defautl" -> "default" > Fixed. > test/lib/testlibrary/jdk/testlibrary/PortFinder.java > This should be coordinated with the review for 8022229 which > contains the same code in a different testlibrary class: > http://cr.openjdk.java.net/~ykantser/8022229/webrev.01/test/lib/testlibrary/jdk/testlibrary/Utils.java.html > > I made a private copy of this function, and have marked it as deprecated. As soon as ykanster's code is merged I can delete my private function and use the library. The reason for this is to get this patch pushed without further delay. > test/sun/management/jdp/7169888/JdpClient.java > test/sun/management/jdp/7169888/JdpDoSomething.java > test/sun/management/jdp/7169888/JdpTest.sh > test/sun/management/jdp/7169888/JdpUnitTest.java > These were moved to a subdirectory, but these tests have nothing to > do with bug 7169888, so why that name? In any case we should avoid > naming test directories after bug ids, and instead use a descriptive name. > This bug number was wrong. These tests were now moved back to the jdp folder. I have expanded the README file with some details about these tests. Dmitry's shell-based are as follows: test_01 - basic test, check if JDP packet assembler and other parts of JDP is not broken test_02 - test if JDP starts with custom parameters. test_03 - test if jcmd is able to start jdp with custom parameters (disabled) test_04 - test if JDP starts with default parameters test_05 - test if jcmd is able to start jdp with default parameters (disabled) test_03 and test_05 are diabled becuase there is a mismatch between hotsport and jdk repos, according to Dmitry. These cases (jcmd) are not covered by this patch, and are part of the test enhacements [4]. test_01 does partly overlap with the Java-based tests, but we should keep it until we implement the latest enhacements [4]. > test/sun/management/jdp/ClientConnection.java > No comments. > > test/sun/management/jdp/DefaultLauncher.java > Can "@library ../../../lib/testlibrary" be replaced by "@library > /lib/testlibrary" ? > Fixed. > test/sun/management/jdp/OffLauncher.java > Can "@library ../../../lib/testlibrary" be replaced by "@library > /lib/testlibrary" ? > Fixed. > test/sun/management/jdp/SpecificJdpAddressLauncher.java > Can "@library ../../../lib/testlibrary" be replaced by "@library > /lib/testlibrary" ? > Fixed. > test/sun/management/jdp/DynamicLauncher.java > No comments. > Fixed. > test/sun/management/jdp/JdpOffTest.java > For the future: it is customary that the file containing the jtreg > directives be named xxxTest.java, and supporting files not ending in Test. > I have renamed the tests following your recomendation. Jtreg tests have now the test suffix. > test/sun/management/jdp/JdpOnTest.java > For the future: it is customary that the file containing the jtreg > directives be named xxxTest.java, and supporting files not ending in Test. > Same as above. > test/sun/management/jdp/JdpTest.java > No comments. > > test/sun/management/jdp/JdpTestUtil.java > No comments. > > test/sun/management/jdp/JdpTestUtilTest.java > test/sun/management/jdp/PacketTest.java > test/sun/management/jdp/PortAlreadyInUseTest.java > These are tests for the tests. But where are the tests for the tests > for the tests? :) > Not reviewed. > > > Thanks, > /Staffan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131029/08873859/attachment.html From james.laskey at oracle.com Tue Oct 29 07:32:16 2013 From: james.laskey at oracle.com (james.laskey at oracle.com) Date: Tue, 29 Oct 2013 14:32:16 +0000 Subject: hg: jdk8/tl/jdk: 27 new changesets Message-ID: <20131029143925.61F19627E4@hg.openjdk.java.net> Changeset: a8bbd962f34a Author: jlaskey Date: 2013-01-28 16:29 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8bbd962f34a 8006676: Integrate Nashorn into new build system Reviewed-by: jlaskey Contributed-by: james.laskey at oracle.com ! THIRD_PARTY_README ! make/launchers/Makefile ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk ! test/tools/launcher/VersionCheck.java Changeset: 41654275896d Author: jlaskey Date: 2013-02-04 17:29 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/41654275896d Merge ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java - test/java/net/URL/abnormal_http_urls - test/java/net/URL/ftp_urls - test/java/net/URL/jar_urls - test/java/net/URL/normal_http_urls - test/java/net/URL/runconstructor.sh - test/java/net/URL/share_file_urls - test/java/net/URL/win32_file_urls - test/sun/net/www/EncDec.doc - test/sun/net/www/MarkResetTest.java - test/sun/net/www/MarkResetTest.sh - test/sun/security/util/Oid/S11N.sh - test/sun/security/util/Oid/SerialTest.java ! test/tools/launcher/VersionCheck.java Changeset: a174944b0c00 Author: jlaskey Date: 2013-02-21 15:25 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a174944b0c00 8008447: Tweaks to make all NEWBUILD=false round 3 Reviewed-by: jjh, sundar Contributed-by: james.laskey at oracle.com ! make/launchers/Makefile Changeset: 25db7658a063 Author: jlaskey Date: 2013-02-22 10:23 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/25db7658a063 8008721: Tweaks to make all NEWBUILD=false round 4 Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! make/launchers/Makefile Changeset: ea22045ce09b Author: jlaskey Date: 2013-02-22 14:05 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ea22045ce09b Merge ! makefiles/CreateJars.gmk Changeset: ff68fafd6302 Author: jlaskey Date: 2013-02-22 17:45 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff68fafd6302 8008756: THIRD_PARTY_README contains Unicode Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! THIRD_PARTY_README Changeset: ce82a0ee7735 Author: jlaskey Date: 2013-02-22 18:03 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce82a0ee7735 8008757: NEWBUILD=true has separate launcher code for jjs Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! makefiles/CompileLaunchers.gmk Changeset: 20a827b22a2e Author: jlaskey Date: 2013-02-22 23:36 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/20a827b22a2e 8008775: Remove non-ascii from jdk/THIRD_PARTY_README Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! THIRD_PARTY_README Changeset: 364e0871f7a3 Author: jlaskey Date: 2013-03-02 11:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/364e0871f7a3 Merge ! make/launchers/Makefile ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java - test/javax/script/RhinoExceptionTest.java ! test/tools/launcher/VersionCheck.java Changeset: 3565c755c49f Author: jlaskey Date: 2013-03-15 11:51 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3565c755c49f Merge ! makefiles/CreateJars.gmk Changeset: 8c223a4f906a Author: jlaskey Date: 2013-03-26 09:12 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8c223a4f906a Merge ! makefiles/CreateJars.gmk Changeset: efbbcd5848cf Author: jlaskey Date: 2013-04-01 10:09 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/efbbcd5848cf Merge Changeset: 39ce82dad57d Author: jlaskey Date: 2013-04-09 08:36 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39ce82dad57d Merge Changeset: ff9683b6854c Author: jlaskey Date: 2013-04-15 08:27 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff9683b6854c Merge ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk Changeset: 1cdf20da340b Author: jlaskey Date: 2013-04-17 08:47 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1cdf20da340b Merge Changeset: 72fa581a83a4 Author: jlaskey Date: 2013-04-22 14:00 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72fa581a83a4 Merge Changeset: ead9944bbb3b Author: jlaskey Date: 2013-04-29 21:37 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ead9944bbb3b Merge Changeset: 5bde43b1e463 Author: jlaskey Date: 2013-05-14 09:04 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bde43b1e463 Merge Changeset: efd620f8963f Author: jlaskey Date: 2013-05-23 09:48 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/efd620f8963f Merge ! makefiles/CreateJars.gmk Changeset: 193652dff077 Author: jlaskey Date: 2013-05-29 13:22 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/193652dff077 Merge Changeset: 733713d7517c Author: jlaskey Date: 2013-06-05 13:10 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/733713d7517c Merge ! makefiles/CompileLaunchers.gmk Changeset: 3b464e13a776 Author: jlaskey Date: 2013-07-16 09:09 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b464e13a776 Merge ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk ! test/tools/launcher/VersionCheck.java Changeset: c0a2094aaafd Author: jlaskey Date: 2013-07-24 08:22 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0a2094aaafd Merge - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html Changeset: 528fc8f4281b Author: jlaskey Date: 2013-08-27 16:06 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/528fc8f4281b Merge ! makefiles/CompileLaunchers.gmk Changeset: be6ca7197e0e Author: jlaskey Date: 2013-09-13 10:15 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/be6ca7197e0e Merge ! makefiles/CreateJars.gmk - src/share/classes/java/util/stream/CloseableStream.java - src/share/classes/java/util/stream/DelegatingStream.java - test/java/util/Map/CheckRandomHashSeed.java - test/java/util/Map/TreeBinSplitBackToEntries.java - test/sun/tools/jconsole/ImmutableResourceTest.java - test/sun/tools/jconsole/ImmutableResourceTest.sh Changeset: 74b1eb493407 Author: jlaskey Date: 2013-09-30 10:24 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74b1eb493407 Merge ! makefiles/CreateJars.gmk Changeset: f5c9333b6129 Author: jlaskey Date: 2013-10-29 10:40 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f5c9333b6129 Merge ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk ! test/tools/launcher/VersionCheck.java From erik.gahlin at oracle.com Tue Oct 29 08:52:20 2013 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 29 Oct 2013 16:52:20 +0100 Subject: RFR(S): 7145419 com/sun/jdi/JdbMethodExitTest.sh fails when a background thread is generating events. In-Reply-To: References: Message-ID: <526FD9B4.5070903@oracle.com> Looks good, if we can assume main thread has id = 1 (main thread must use first j.l.Thread object that is created) /Erik Staffan Larsen skrev 2013-10-29 15:41: > This test fails if there are background threads that run while the test is running. I've modified the test to use the "trace" commands in jdb with the extra thread parameter. I have assumed that the main thread has thread id 1. "trace" with thread id behaves a little bit different so a couple of extra "cont" were needed. > > webrev: http://cr.openjdk.java.net/~sla/7145419/webrev.00/ > > Thanks, > /Staffan From chris.hegarty at oracle.com Tue Oct 29 10:25:02 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 29 Oct 2013 17:25:02 +0000 Subject: hg: jdk8/tl/jdk: 8027466: Revert jdk/THIRD_PARTY_README to known good version Message-ID: <20131029172537.44C10627F7@hg.openjdk.java.net> Changeset: 121c34517841 Author: chegar Date: 2013-10-29 17:21 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/121c34517841 8027466: Revert jdk/THIRD_PARTY_README to known good version Reviewed-by: alanb ! THIRD_PARTY_README From jaroslav.bachorik at oracle.com Tue Oct 29 10:28:37 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 29 Oct 2013 18:28:37 +0100 Subject: RFR 8027358: sun/management/jmxremote/bootstrap/LocalManagementTest.java failing since JDK-8004926 Message-ID: <526FF045.9060803@oracle.com> Please, review this test fix. In agentvm mode the test can not rely on the co-location of the test class and the auxiliary classes the test class wants to start. It is necessary to explicitly provide the test class path when starting an external java process. Issue : https://bugs.openjdk.java.net/browse/JDK-8027358 Webrev: http://cr.openjdk.java.net/~jbachorik/8027358/webrev.00/ Thanks, -JB- From michael.fang at oracle.com Tue Oct 29 11:36:22 2013 From: michael.fang at oracle.com (michael.fang at oracle.com) Date: Tue, 29 Oct 2013 18:36:22 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20131029183706.98C25627FC@hg.openjdk.java.net> Changeset: 6fc2889fe7d0 Author: mfang Date: 2013-10-29 11:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6fc2889fe7d0 8026108: [it, ja, zh_CN] wrong translation in jar example. Reviewed-by: okutsu, yhuang ! src/share/classes/sun/tools/jar/resources/jar_it.properties ! src/share/classes/sun/tools/jar/resources/jar_ja.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties Changeset: 0cc9bdb22911 Author: mfang Date: 2013-10-29 11:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0cc9bdb22911 8008437: [sv] over-translation in java command line outputs Reviewed-by: okutsu, yhuang ! src/share/classes/sun/tools/jar/resources/jar_sv.properties Changeset: 331d8ced56dc Author: mfang Date: 2013-10-29 11:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/331d8ced56dc 8025646: [pt_BR] overtranslation of option in java command line output Reviewed-by: naoto, yhuang ! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties From erik.gahlin at oracle.com Tue Oct 29 12:31:43 2013 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 29 Oct 2013 20:31:43 +0100 Subject: RFR 8027358: sun/management/jmxremote/bootstrap/LocalManagementTest.java failing since JDK-8004926 In-Reply-To: <526FF045.9060803@oracle.com> References: <526FF045.9060803@oracle.com> Message-ID: <52700D1F.6060501@oracle.com> Looks good. /Erik Jaroslav Bachorik skrev 2013-10-29 18:28: > Please, review this test fix. > > In agentvm mode the test can not rely on the co-location of the test > class and the auxiliary classes the test class wants to start. It is > necessary to explicitly provide the test class path when starting an > external java process. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8027358 > Webrev: http://cr.openjdk.java.net/~jbachorik/8027358/webrev.00/ > > Thanks, > > -JB- From Alan.Bateman at oracle.com Tue Oct 29 13:35:07 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 Oct 2013 20:35:07 +0000 Subject: RFR 8027358: sun/management/jmxremote/bootstrap/LocalManagementTest.java failing since JDK-8004926 In-Reply-To: <526FF045.9060803@oracle.com> References: <526FF045.9060803@oracle.com> Message-ID: <52701BFB.1030107@oracle.com> On 29/10/2013 17:28, Jaroslav Bachorik wrote: > Please, review this test fix. > > In agentvm mode the test can not rely on the co-location of the test > class and the auxiliary classes the test class wants to start. It is > necessary to explicitly provide the test class path when starting an > external java process. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8027358 > Webrev: http://cr.openjdk.java.net/~jbachorik/8027358/webrev.00/ This looks okay to me. -Alan. From jaroslav.bachorik at oracle.com Tue Oct 29 14:03:06 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Tue, 29 Oct 2013 21:03:06 +0000 Subject: hg: jdk8/tl/jdk: 8027358: sun/management/jmxremote/bootstrap/LocalManagementTest.java failing since JDK-8004926 Message-ID: <20131029210417.D498C62801@hg.openjdk.java.net> Changeset: a3ac9c0b19a9 Author: jbachorik Date: 2013-10-29 21:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a3ac9c0b19a9 8027358: sun/management/jmxremote/bootstrap/LocalManagementTest.java failing since JDK-8004926 Reviewed-by: alanb, egahlin ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java ! test/sun/management/jmxremote/bootstrap/LocalManagementTest.java From huizhe.wang at oracle.com Tue Oct 29 14:58:38 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Tue, 29 Oct 2013 21:58:38 +0000 Subject: hg: jdk8/tl/jaxp: 8027484: Implementation error in SAX2DOM.java Message-ID: <20131029215845.C5DA662808@hg.openjdk.java.net> Changeset: 1af33ab1bc58 Author: joehw Date: 2013-10-29 14:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/1af33ab1bc58 8027484: Implementation error in SAX2DOM.java Reviewed-by: alanb, lancea ! src/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2DOM.java From michael.fang at oracle.com Tue Oct 29 15:33:39 2013 From: michael.fang at oracle.com (michael.fang at oracle.com) Date: Tue, 29 Oct 2013 22:33:39 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131029223451.443006280B@hg.openjdk.java.net> Changeset: 8cfc73ad9f31 Author: mfang Date: 2013-10-29 15:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8cfc73ad9f31 8008647: [es] minor cosmetic issues in translated java command line outputs Reviewed-by: naoto ! src/share/classes/sun/tools/jar/resources/jar_es.properties Changeset: 4071c853edff Author: mfang Date: 2013-10-29 15:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4071c853edff Merge From michael.fang at oracle.com Tue Oct 29 17:01:11 2013 From: michael.fang at oracle.com (michael.fang at oracle.com) Date: Wed, 30 Oct 2013 00:01:11 +0000 Subject: hg: jdk8/tl/jdk: 8025521: [de] mnemonic conflict in FileChooser for GTK Style feel&look Message-ID: <20131030000215.4EA766280F@hg.openjdk.java.net> Changeset: bede752d1e3c Author: mfang Date: 2013-10-29 16:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bede752d1e3c 8025521: [de] mnemonic conflict in FileChooser for GTK Style feel&look Reviewed-by: naoto ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_de.properties From yekaterina.kantserova at oracle.com Wed Oct 30 02:27:41 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 30 Oct 2013 10:27:41 +0100 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <0C3DC4C9-53EF-46BD-8733-5851B6D60F4E@oracle.com> References: <4e22dbcf-e8f1-47e6-8f43-1d7047811528@default> <0C3DC4C9-53EF-46BD-8733-5851B6D60F4E@oracle.com> Message-ID: <5270D10D.1060201@oracle.com> http://cr.openjdk.java.net/~ykantser/8022229/webrev.04/ Fixed your points and changed ./test/sun/tools/jstatd/TestJstatdUsage.java to use JDKToolLauncher instead of JDKFinder. Thanks, Katja On 10/28/2013 07:02 PM, Staffan Larsen wrote: > Rename JstatdTest.getToolOptions() to JstatdTest.getDestination(). > > nit: JstatdTest.cleanUpThread() shouldn't be static. > > Thanks, > /Staffan > > On 28 okt 2013, at 17:12, Yekaterina Kantserova > > wrote: > >> Hi, >> >> http://cr.openjdk.java.net/~ykantser/8022229/webrev.03/ >> >> Moved ToolConfig functionality to JstatdTest (renamed JstatdHelper) >> and deleted ToolConfig. The tests are also changed a little: >> >> public class TestJstatdDefaults { >> >> public static void main(String[] args) throws Throwable { >> JstatdTest test = new JstatdTest(); >> test.doTest(); >> } >> >> } >> >> Hope it looks better now. >> >> Thanks, >> Katja >> >> ----- Ursprungligt meddelande ----- >> Fr?n:staffan.larsen at oracle.com >> Till:yekaterina.kantserova at oracle.com >> >> Kopia: serviceability-dev at openjdk.java.net >> ,david.holmes at oracle.com >> ,jaroslav.bachorik at oracle.com >> ,christian.tornqvist at oracle.com >> , hotspot-dev at openjdk.java.net >> ,mattis.castegren at oracle.com >> >> Skickat: m?ndag, 28 okt 2013 12:57:38 GMT +01:00 >> Amsterdam/Berlin/Bern/Rom/Stockholm/Wien >> ?mne: Re: RFR (S): 8022229: Intermittent test failures in >> sun/tools/jstatd >> >> This looks a lot better. Just few more comments: >> >> ToolConfig.java >> L72 - "getToolOptins" -> "getToolOptions" >> L35 - why is port stored as a String? Also, could be renamed to >> rmiRegistryPort to clarify what it is for. >> >> Why are some tool-specific options added in getToolOptins() and >> some in the getJpsCmd()/getJstatdCmd()/... methods? Maybe >> changing getToolOptins() to only return the host part of the options >> and moving the rest of the setup to getJpsCmd()/getJstatdCmd()/...? >> >> >> Thanks, >> /Staffan >> >> >> On 24 okt 2013, at 15:57, Yekaterina Kantserova >> > > wrote: >> >> Hi, >> >> I've done following big changes after the Staffan's review: >> - ported JDKToolLauncher, JDKToolFinder, Plattform from hotspot >> testlibrary (http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot) >> for re-using in ToolConfig >> - changed "verifiy output form jps, jstat"-methods to ignore >> warnings from VM >> - tools will be launched without -vmoptions >> >> plusmade fixes for all minorcomments. >> >> If it's a good idea to push testlibrary changes separately I can >> make a separate patch for them. >> >> Webrev: >> http://cr.openjdk.java.net/~ykantser/8022229/webrev.02/ >> >> Primal bug: >> https://bugs.openjdk.java.net/browse/JDK-8022229 >> >> Similarbugs: >> https://bugs.openjdk.java.net/browse/JDK-8019630 >> https://bugs.openjdk.java.net/browse/JDK-6636094 >> https://bugs.openjdk.java.net/browse/JDK-6543979 >> >> Thanks, >> Katja >> >> >> >> On 10/23/2013 12:55 PM, Staffan Larsen wrote: >> >> test/lib/testlibrary/jdk/testlibrary/Asserts.java >> Same code as already exists in the hotspot testlibrary. >> No further comments. >> >> >> test/lib/testlibrary/jdk/testlibrary/ProcessThread.java >> L33: stating -> starting >> L66: staring -> starting >> >> >> test/lib/testlibrary/jdk/testlibrary/TestThread.java >> This code comes from an internal test library. >> No further comments. >> >> >> test/lib/testlibrary/jdk/testlibrary/Utils.java >> No comments. >> >> >> test/lib/testlibrary/jdk/testlibrary/XRun.java >> This code comes from an internal test library. >> No further comments. >> >> >> test/sun/tools/jstatd/JstatGcutilParser.java >> The parse() method could be made more robust by discarding >> any lines that come before the header lines. This can happen >> if the JVM outputs a warning message for some reason before >> running jstat. >> I don't like the special-case for the CCS column in >> verify() - took me a while to find it. Should we add a new >> enum called PERCENTAGE_OR_DASH to handle that instead? >> >> L67: getType() should be private. >> >> >> test/sun/tools/jstatd/JstatdHelper.java: >> L54: Does verifyJpsOutput() work correctly with output of >> the form: >> >> 1234 -- main class information unavailable >> 1235 -- process information unavailable >> >> Also: same comment here as for JstatGcutilParser.java: >> sometimes the JVM outputs warning messages before the output >> from the tool. >> >> L46: "attach" is probably not the best way to describe the >> operation of jps. It does not attach to the process, it >> merely lists the running processes. Perhaps runJps() is a >> better name? >> >> >> test/sun/tools/jstatd/TestJstatdDefaults.java >> test/sun/tools/jstatd/TestJstatdExternalRegistry.java >> test/sun/tools/jstatd/TestJstatdPort.java >> test/sun/tools/jstatd/TestJstatdPortAndServer.java >> test/sun/tools/jstatd/TestJstatdServer.java >> No comments. >> >> >> test/sun/tools/jstatd/TestJstatdUsage.java >> Same comment here as for JstatGcutilParser.java: sometimes >> the JVM outputs warning messages before the output from the tool. >> >> >> test/sun/tools/jstatd/ToolConfig.java >> ToolConfig + Utils.get(Forward)VmOptions() seem to be doing >> similar things to JDKToolLauncher in the hotspot testlibrary. >> It is unfortunate if we have two ways to do similar things in >> the two different testlibraries. Would it be possible to >> reuse the hotspot code here instead? >> >> You have also changed the test. Previously the tools were >> not launched with the jtreg -vmoptions (test.vm.opts), >> whereas now they will be. Is this intentional? >> >> >> General comments: >> >> Can't we do: >> * @library /lib/testlibrary >> instead of >> * @library ../../../lib/testlibrary >> ? >> >> It seems that at least some of the functionality should be >> reused for re-writing the jstat and jps tests as well. I >> guess we can look at that at a later time, though. >> >> While I applaud the move from shell scripts to Java code, I >> can't shake the feeling that the shell scripts were easier to >> read and follow. The Java code is much more verbose and >> spread out over multiple helpers and libraries, making it >> harder to grasp. That may be the price we have to pay, though. >> >> >> Thanks, >> /Staffan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131030/82400703/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 8022229.4.patch Type: text/x-patch Size: 91461 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131030/82400703/8022229.4-0001.patch From staffan.larsen at oracle.com Wed Oct 30 02:56:36 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 30 Oct 2013 10:56:36 +0100 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <5270D10D.1060201@oracle.com> References: <4e22dbcf-e8f1-47e6-8f43-1d7047811528@default> <0C3DC4C9-53EF-46BD-8733-5851B6D60F4E@oracle.com> <5270D10D.1060201@oracle.com> Message-ID: <43432737-E1A3-433D-B2BD-3A7A07B57485@oracle.com> Looks good! Reviewed. Thanks, /Staffan On 30 okt 2013, at 10:27, Yekaterina Kantserova wrote: > > http://cr.openjdk.java.net/~ykantser/8022229/webrev.04/ > > Fixed your points and changed ./test/sun/tools/jstatd/TestJstatdUsage.java to use JDKToolLauncher instead of JDKFinder. > > Thanks, > Katja > > > On 10/28/2013 07:02 PM, Staffan Larsen wrote: >> Rename JstatdTest.getToolOptions() to JstatdTest.getDestination(). >> >> nit: JstatdTest.cleanUpThread() shouldn't be static. >> >> Thanks, >> /Staffan >> >> On 28 okt 2013, at 17:12, Yekaterina Kantserova wrote: >> >>> Hi, >>> >>> http://cr.openjdk.java.net/~ykantser/8022229/webrev.03/ >>> >>> Moved ToolConfig functionality to JstatdTest (renamed JstatdHelper) and deleted ToolConfig. The tests are also changed a little: >>> >>> public class TestJstatdDefaults { >>> >>> public static void main(String[] args) throws Throwable { >>> JstatdTest test = new JstatdTest(); >>> test.doTest(); >>> } >>> >>> } >>> >>> Hope it looks better now. >>> >>> Thanks, >>> Katja >>> >>> ----- Ursprungligt meddelande ----- >>> Fr?n: staffan.larsen at oracle.com >>> Till: yekaterina.kantserova at oracle.com >>> Kopia: serviceability-dev at openjdk.java.net, david.holmes at oracle.com, jaroslav.bachorik at oracle.com,christian.tornqvist at oracle.com, hotspot-dev at openjdk.java.net, mattis.castegren at oracle.com >>> Skickat: m?ndag, 28 okt 2013 12:57:38 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien >>> ?mne: Re: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd >>> >>> This looks a lot better. Just few more comments: >>> >>> ToolConfig.java >>> L72 - "getToolOptins" -> "getToolOptions" >>> L35 - why is port stored as a String? Also, could be renamed to rmiRegistryPort to clarify what it is for. >>> >>> Why are some tool-specific options added in getToolOptins() and some in the getJpsCmd()/getJstatdCmd()/... methods? Maybe changing getToolOptins() to only return the host part of the options and moving the rest of the setup to getJpsCmd()/getJstatdCmd()/...? >>> >>> >>> Thanks, >>> /Staffan >>> >>> >>> On 24 okt 2013, at 15:57, Yekaterina Kantserova wrote: >>> >>> Hi, >>> >>> I've done following big changes after the Staffan's review: >>> - ported JDKToolLauncher, JDKToolFinder, Plattform from hotspot testlibrary (http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot) for re-using in ToolConfig >>> - changed "verifiy output form jps, jstat"-methods to ignore warnings from VM >>> - tools will be launched without -vmoptions >>> >>> plus made fixes for all minor comments. >>> >>> If it's a good idea to push testlibrary changes separately I can make a separate patch for them. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ykantser/8022229/webrev.02/ >>> >>> Primal bug: >>> https://bugs.openjdk.java.net/browse/JDK-8022229 >>> >>> Similar bugs: >>> https://bugs.openjdk.java.net/browse/JDK-8019630 >>> https://bugs.openjdk.java.net/browse/JDK-6636094 >>> https://bugs.openjdk.java.net/browse/JDK-6543979 >>> >>> Thanks, >>> Katja >>> >>> >>> >>> On 10/23/2013 12:55 PM, Staffan Larsen wrote: >>> test/lib/testlibrary/jdk/testlibrary/Asserts.java >>> Same code as already exists in the hotspot testlibrary. >>> No further comments. >>> >>> >>> test/lib/testlibrary/jdk/testlibrary/ProcessThread.java >>> L33: stating -> starting >>> L66: staring -> starting >>> >>> >>> test/lib/testlibrary/jdk/testlibrary/TestThread.java >>> This code comes from an internal test library. >>> No further comments. >>> >>> >>> test/lib/testlibrary/jdk/testlibrary/Utils.java >>> No comments. >>> >>> >>> test/lib/testlibrary/jdk/testlibrary/XRun.java >>> This code comes from an internal test library. >>> No further comments. >>> >>> >>> test/sun/tools/jstatd/JstatGcutilParser.java >>> The parse() method could be made more robust by discarding any lines that come before the header lines. This can happen if the JVM outputs a warning message for some reason before running jstat. >>> >>> I don't like the special-case for the CCS column in verify() - took me a while to find it. Should we add a new enum called PERCENTAGE_OR_DASH to handle that instead? >>> >>> L67: getType() should be private. >>> >>> >>> test/sun/tools/jstatd/JstatdHelper.java: >>> L54: Does verifyJpsOutput() work correctly with output of the form: >>> >>> 1234 -- main class information unavailable >>> 1235 -- process information unavailable >>> >>> Also: same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. >>> >>> L46: "attach" is probably not the best way to describe the operation of jps. It does not attach to the process, it merely lists the running processes. Perhaps runJps() is a better name? >>> >>> >>> test/sun/tools/jstatd/TestJstatdDefaults.java >>> test/sun/tools/jstatd/TestJstatdExternalRegistry.java >>> test/sun/tools/jstatd/TestJstatdPort.java >>> test/sun/tools/jstatd/TestJstatdPortAndServer.java >>> test/sun/tools/jstatd/TestJstatdServer.java >>> No comments. >>> >>> >>> test/sun/tools/jstatd/TestJstatdUsage.java >>> Same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. >>> >>> >>> test/sun/tools/jstatd/ToolConfig.java >>> ToolConfig + Utils.get(Forward)VmOptions() seem to be doing similar things to JDKToolLauncher in the hotspot testlibrary. It is unfortunate if we have two ways to do similar things in the two different testlibraries. Would it be possible to reuse the hotspot code here instead? >>> >>> You have also changed the test. Previously the tools were not launched with the jtreg -vmoptions (test.vm.opts), whereas now they will be. Is this intentional? >>> >>> >>> General comments: >>> >>> Can't we do: >>> * @library /lib/testlibrary >>> instead of >>> * @library ../../../lib/testlibrary >>> ? >>> >>> It seems that at least some of the functionality should be reused for re-writing the jstat and jps tests as well. I guess we can look at that at a later time, though. >>> >>> While I applaud the move from shell scripts to Java code, I can't shake the feeling that the shell scripts were easier to read and follow. The Java code is much more verbose and spread out over multiple helpers and libraries, making it harder to grasp. That may be the price we have to pay, though. >>> >>> >>> Thanks, >>> /Staffan >> > > <8022229.4.patch> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131030/fdee80ba/attachment.html From mikael.auno at oracle.com Wed Oct 30 03:17:15 2013 From: mikael.auno at oracle.com (Mikael Auno) Date: Wed, 30 Oct 2013 11:17:15 +0100 Subject: RFR(S): 7145419 com/sun/jdi/JdbMethodExitTest.sh fails when a background thread is generating events. In-Reply-To: References: Message-ID: <5270DCAB.6060608@oracle.com> On 2013-10-29 15:41, Staffan Larsen wrote: > This test fails if there are background threads that run while the > test is running. I've modified the test to use the "trace" commands > in jdb with the extra thread parameter. I have assumed that the main > thread has thread id 1. "trace" with thread id behaves a little bit > different so a couple of extra "cont" were needed. > > webrev: http://cr.openjdk.java.net/~sla/7145419/webrev.00/ Would it be possible to set a breakpoint in main (or some other known location) to determine the thread id (as we do in some of the JDI tests) to make sure we have the right one before continuing with the rest of the test? Mikael From staffan.larsen at oracle.com Wed Oct 30 04:10:36 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 30 Oct 2013 12:10:36 +0100 Subject: RFR(S): 7145419 com/sun/jdi/JdbMethodExitTest.sh fails when a background thread is generating events. In-Reply-To: <5270DCAB.6060608@oracle.com> References: <5270DCAB.6060608@oracle.com> Message-ID: I tried, that, but couldn't find what the jdb command for getting the current thread is. Anyone? /Staffan On 30 okt 2013, at 11:17, Mikael Auno wrote: > On 2013-10-29 15:41, Staffan Larsen wrote: >> This test fails if there are background threads that run while the >> test is running. I've modified the test to use the "trace" commands >> in jdb with the extra thread parameter. I have assumed that the main >> thread has thread id 1. "trace" with thread id behaves a little bit >> different so a couple of extra "cont" were needed. >> >> webrev: http://cr.openjdk.java.net/~sla/7145419/webrev.00/ > > Would it be possible to set a breakpoint in main (or some other known location) to determine the thread id (as we do in some of the JDI tests) to make sure we have the right one before continuing with the rest of the test? > > Mikael From jaroslav.bachorik at oracle.com Wed Oct 30 04:23:55 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 30 Oct 2013 12:23:55 +0100 Subject: jmx-dev RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: <526975F4.8060707@oracle.com> References: <526681FD.90604@oracle.com> <5266DA56.6050609@oracle.com> <52678280.1070004@oracle.com> <4972770C-A8BB-40A0-9BB8-885AA6B707BC@oracle.com> <52678509.2020002@oracle.com> <68F92D47-E916-426B-8D6A-2EA48302053D@oracle.com> <5267C3AD.5050306@oracle.com> <5267C74F.2010302@oracle.com> <5267CC00.7080509@oracle.com> <5267DDFC.4060607@oracle.com> <52685571.1090407@oracle.com> <52692847.1030806@oracle.com> <526975F4.8060707@oracle.com> Message-ID: <5270EC4B.9080205@oracle.com> On 24.10.2013 21:33, Mandy Chung wrote: > > On 10/24/2013 7:01 AM, Jaroslav Bachorik wrote: >> Hi Mandy, >> >> On 24.10.2013 01:02, Mandy Chung wrote: >>> >>> On 10/23/2013 7:32 AM, Jaroslav Bachorik wrote: >>>> I've updated the patch. The GC is called even before the first attempt >>>> to get the pool memory usage and System.gc() is used to perform GC (no >>>> MXBean checks). This should simplify the change a bit. >>>> >>>> http://cr.openjdk.java.net/~jbachorik/8020467/webrev.02 >>> >>> This change is okay. It will force GC once per each memory pool that >>> supports usage threshold (I think 3 memory pools) which is not a huge >>> issue. Perhaps a more reliable option is to make it an othervm test and >>> allocating large object and calling GC once before the verification. >> >> Running it as othervm might improve repeatbility but I don't quite >> follow the trick with large object. That would be effective for the >> oldgen pools only, I suppose? There were concerns raised during the >> review that other pools might be susceptible to the same timing >> related problems (theoretically). > > This test was written before the samevm/agentvm support. In general we > want the tests to be reliable. You want the System.gc() call to reduce > the probability of the race such that the initially empty pool is being > filled with objects between getUsage() and isUsageThresholdExceeded() > methods are called but this has the assumption that there is some large > object allocated and get promoted to the old gen (not done in this test > though). The other possibility is that the old gen is cleared although > it might be rare in practice? Holding on a large object will ensure > that the old gen is always filled with something to make it more reliable. > >> So, if you don't feel strongy about it I would leave the rest of the >> test as it is - that is calling System.gc() before checking the pool >> thresholds. > > I just worry that this test will fail some day intermittently again. > Since in practice the runtime has space allocated, I think running it in > othervm would be adequate. Ok. I've added a big object and an initial call to System.gc(). But I'm leaving the calls to System.gc() right before checking the pools as well - just to be sure. http://cr.openjdk.java.net/~jbachorik/8020467/webrev.04 -JB- > > Mandy From jaroslav.bachorik at oracle.com Wed Oct 30 04:27:29 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 30 Oct 2013 12:27:29 +0100 Subject: [ping] Re: RFR 8027058: sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh Failed to initialize connector In-Reply-To: <5267F6C0.3020606@oracle.com> References: <5267E862.1020804@oracle.com> <5267EC04.9010108@oracle.com> <5267ECD9.20304@oracle.com> <5267F008.808@oracle.com> <5267F5B2.7090807@oracle.com> <5267F6C0.3020606@oracle.com> Message-ID: <5270ED21.6010106@oracle.com> Could I have a reviewer to take a look at this, please? Thanks, -JB- On 23.10.2013 18:18, Daniel Fuchs wrote: > Looks good to me! > > -- daniel > > On 10/23/13 6:13 PM, Jaroslav Bachorik wrote: >> On 23.10.2013 17:49, Daniel Fuchs wrote: >>> On 10/23/13 5:35 PM, Jaroslav Bachorik wrote: >>>> On 23.10.2013 17:32, Daniel Fuchs wrote: >>>>> Hi Jaroslav, >>>>> >>>>> Have you considered setting a limit on the number of tries you >>>>> will attempt, rather than just 'while (true)'? >>>>> It might avoid creating a busy while loop in case there's some global >>>>> networking issue. >>>> >>>> It might be difficult to come up with the right number. Probably a few >>>> hundred could be enough even for cases when you hit a contiguous range >>>> of ports occupied by different applications. >>> >>> Instead of using an arbitrary 12424 as the default starting point >>> it could be interesting to try with the first available port + 1; >>> >>> something like: >>> >>> final int startPort; >>> try (ServerSocket s = new ServerSocket(0)) { >>> startPort = s.getLocalPort() + 1; >>> } >>> System.out.println("startPort: "+startPort); >>> >>> But maybe that's what the test that calls the code is already doing? >> >> Nope, it's hardcoded. >> >> I've added the cap for the number of consecutive checks for a port being >> available and dynamic lookup of the first available port (if it's not >> specified by the system property "rmi.port"). >> >> http://cr.openjdk.java.net/~jbachorik/8027058/webrev.01 >> >> Thanks for the additional ideas! >> >> -JB- >> >> >>> >>> -- daniel >>> >>> >>>> >>>> -JB- >>>> >>>>> >>>>> -- daniel >>>>> >>>>> On 10/23/13 5:16 PM, Jaroslav Bachorik wrote: >>>>>> Please, review the following test change: >>>>>> >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8027058 >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8027058/webrev.00 >>>>>> >>>>>> The test fails when the requested port is unavailable. The test logic >>>>>> already runs the subtests with different port numbers (increasing the >>>>>> port number for each subtest) and this patch adds the logic to >>>>>> increase >>>>>> the port number in case of the subtest failure caused by >>>>>> BindException. >>>>>> This way the test is able to "autodiscover" free ports and run the >>>>>> bootstrap subtests successfully. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>>> >>>> >>> >> > From chris.hegarty at oracle.com Wed Oct 30 04:45:02 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 30 Oct 2013 11:45:02 +0000 Subject: [ping] Re: RFR 8027058: sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh Failed to initialize connector In-Reply-To: <5270ED21.6010106@oracle.com> References: <5267E862.1020804@oracle.com> <5267EC04.9010108@oracle.com> <5267ECD9.20304@oracle.com> <5267F008.808@oracle.com> <5267F5B2.7090807@oracle.com> <5267F6C0.3020606@oracle.com> <5270ED21.6010106@oracle.com> Message-ID: <5270F13E.7030803@oracle.com> It is not nice to have to deal with these unused ports, but I have seen a similar technique used elsewhere in rmi code, so it looks ok to me. -Chris. On 30/10/2013 11:27, Jaroslav Bachorik wrote: > Could I have a reviewer to take a look at this, please? > > Thanks, > > -JB- > > On 23.10.2013 18:18, Daniel Fuchs wrote: >> Looks good to me! >> >> -- daniel >> >> On 10/23/13 6:13 PM, Jaroslav Bachorik wrote: >>> On 23.10.2013 17:49, Daniel Fuchs wrote: >>>> On 10/23/13 5:35 PM, Jaroslav Bachorik wrote: >>>>> On 23.10.2013 17:32, Daniel Fuchs wrote: >>>>>> Hi Jaroslav, >>>>>> >>>>>> Have you considered setting a limit on the number of tries you >>>>>> will attempt, rather than just 'while (true)'? >>>>>> It might avoid creating a busy while loop in case there's some global >>>>>> networking issue. >>>>> >>>>> It might be difficult to come up with the right number. Probably a few >>>>> hundred could be enough even for cases when you hit a contiguous range >>>>> of ports occupied by different applications. >>>> >>>> Instead of using an arbitrary 12424 as the default starting point >>>> it could be interesting to try with the first available port + 1; >>>> >>>> something like: >>>> >>>> final int startPort; >>>> try (ServerSocket s = new ServerSocket(0)) { >>>> startPort = s.getLocalPort() + 1; >>>> } >>>> System.out.println("startPort: "+startPort); >>>> >>>> But maybe that's what the test that calls the code is already doing? >>> >>> Nope, it's hardcoded. >>> >>> I've added the cap for the number of consecutive checks for a port being >>> available and dynamic lookup of the first available port (if it's not >>> specified by the system property "rmi.port"). >>> >>> http://cr.openjdk.java.net/~jbachorik/8027058/webrev.01 >>> >>> Thanks for the additional ideas! >>> >>> -JB- >>> >>> >>>> >>>> -- daniel >>>> >>>> >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> -- daniel >>>>>> >>>>>> On 10/23/13 5:16 PM, Jaroslav Bachorik wrote: >>>>>>> Please, review the following test change: >>>>>>> >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8027058 >>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8027058/webrev.00 >>>>>>> >>>>>>> The test fails when the requested port is unavailable. The test >>>>>>> logic >>>>>>> already runs the subtests with different port numbers (increasing >>>>>>> the >>>>>>> port number for each subtest) and this patch adds the logic to >>>>>>> increase >>>>>>> the port number in case of the subtest failure caused by >>>>>>> BindException. >>>>>>> This way the test is able to "autodiscover" free ports and run the >>>>>>> bootstrap subtests successfully. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>>> >>>>> >>>> >>> >> > From staffan.larsen at oracle.com Wed Oct 30 04:50:25 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 30 Oct 2013 12:50:25 +0100 Subject: [ping] RFR 8027058: sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh Failed to initialize connector In-Reply-To: <5270ED21.6010106@oracle.com> References: <5267E862.1020804@oracle.com> <5267EC04.9010108@oracle.com> <5267ECD9.20304@oracle.com> <5267F008.808@oracle.com> <5267F5B2.7090807@oracle.com> <5267F6C0.3020606@oracle.com> <5270ED21.6010106@oracle.com> Message-ID: Looks good! Thanks, /Staffan On 30 okt 2013, at 12:27, Jaroslav Bachorik wrote: > Could I have a reviewer to take a look at this, please? > > Thanks, > > -JB- > > On 23.10.2013 18:18, Daniel Fuchs wrote: >> Looks good to me! >> >> -- daniel >> >> On 10/23/13 6:13 PM, Jaroslav Bachorik wrote: >>> On 23.10.2013 17:49, Daniel Fuchs wrote: >>>> On 10/23/13 5:35 PM, Jaroslav Bachorik wrote: >>>>> On 23.10.2013 17:32, Daniel Fuchs wrote: >>>>>> Hi Jaroslav, >>>>>> >>>>>> Have you considered setting a limit on the number of tries you >>>>>> will attempt, rather than just 'while (true)'? >>>>>> It might avoid creating a busy while loop in case there's some global >>>>>> networking issue. >>>>> >>>>> It might be difficult to come up with the right number. Probably a few >>>>> hundred could be enough even for cases when you hit a contiguous range >>>>> of ports occupied by different applications. >>>> >>>> Instead of using an arbitrary 12424 as the default starting point >>>> it could be interesting to try with the first available port + 1; >>>> >>>> something like: >>>> >>>> final int startPort; >>>> try (ServerSocket s = new ServerSocket(0)) { >>>> startPort = s.getLocalPort() + 1; >>>> } >>>> System.out.println("startPort: "+startPort); >>>> >>>> But maybe that's what the test that calls the code is already doing? >>> >>> Nope, it's hardcoded. >>> >>> I've added the cap for the number of consecutive checks for a port being >>> available and dynamic lookup of the first available port (if it's not >>> specified by the system property "rmi.port"). >>> >>> http://cr.openjdk.java.net/~jbachorik/8027058/webrev.01 >>> >>> Thanks for the additional ideas! >>> >>> -JB- >>> >>> >>>> >>>> -- daniel >>>> >>>> >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> -- daniel >>>>>> >>>>>> On 10/23/13 5:16 PM, Jaroslav Bachorik wrote: >>>>>>> Please, review the following test change: >>>>>>> >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8027058 >>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8027058/webrev.00 >>>>>>> >>>>>>> The test fails when the requested port is unavailable. The test logic >>>>>>> already runs the subtests with different port numbers (increasing the >>>>>>> port number for each subtest) and this patch adds the logic to >>>>>>> increase >>>>>>> the port number in case of the subtest failure caused by >>>>>>> BindException. >>>>>>> This way the test is able to "autodiscover" free ports and run the >>>>>>> bootstrap subtests successfully. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>>> >>>>> >>>> >>> >> > From daniel.daugherty at oracle.com Wed Oct 30 05:10:17 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 30 Oct 2013 08:10:17 -0400 Subject: RFR(S): 7145419 com/sun/jdi/JdbMethodExitTest.sh fails when a background thread is generating events. In-Reply-To: References: <5270DCAB.6060608@oracle.com> Message-ID: <5270F729.2030501@oracle.com> The current thread number is part of the jdb prompt. So something like this: $ jdb Hello Initializing jdb ... > stop in Hello.main Deferring breakpoint Hello.main. It will be set after the class is loaded. > run run Hello Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable > VM Started: Set deferred breakpoint Hello.main Breakpoint hit: "thread=main", Hello.main(), line=3 bci=0 3 System.out.println("Hello World!"); main[1] where you feed these cmds to jdb: stop in Hello.main run and your script checks for Breakpoint hit: "thread=main" and then pulls the number out of the prompt that follows: main[1] Dan On 10/30/13 7:10 AM, Staffan Larsen wrote: > I tried, that, but couldn't find what the jdb command for getting the current thread is. Anyone? > > /Staffan > > On 30 okt 2013, at 11:17, Mikael Auno wrote: > >> On 2013-10-29 15:41, Staffan Larsen wrote: >>> This test fails if there are background threads that run while the >>> test is running. I've modified the test to use the "trace" commands >>> in jdb with the extra thread parameter. I have assumed that the main >>> thread has thread id 1. "trace" with thread id behaves a little bit >>> different so a couple of extra "cont" were needed. >>> >>> webrev: http://cr.openjdk.java.net/~sla/7145419/webrev.00/ >> Would it be possible to set a breakpoint in main (or some other known location) to determine the thread id (as we do in some of the JDI tests) to make sure we have the right one before continuing with the rest of the test? >> >> Mikael From staffan.larsen at oracle.com Wed Oct 30 05:26:40 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 30 Oct 2013 13:26:40 +0100 Subject: RFR(S): 7145419 com/sun/jdi/JdbMethodExitTest.sh fails when a background thread is generating events. In-Reply-To: <5270F729.2030501@oracle.com> References: <5270DCAB.6060608@oracle.com> <5270F729.2030501@oracle.com> Message-ID: <4F85D8F8-9E95-41D9-832F-2A9AB92CD5EE@oracle.com> But that does not seem to work correctly: Initializing jdb ... > stop in JdbMethodExitTest.bkpt() Deferring breakpoint JdbMethodExitTest.bkpt(). It will be set after the class is loaded. > run run JdbMethodExitTest Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable > VM Started: Set deferred breakpoint JdbMethodExitTest.bkpt() Breakpoint hit: "thread=main", JdbMethodExitTest.bkpt(), line=84 bci=0 84 int i = 0; //@1 breakpoint main[1] threads Group system: (java.lang.ref.Reference$ReferenceHandler)0x17c Reference Handler cond. waiting (java.lang.ref.Finalizer$FinalizerThread)0x17b Finalizer cond. waiting (java.lang.Thread)0x17a Signal Dispatcher running Group main: (java.lang.Thread)0x1 main running (at breakpoint) main[1] thread 0x17a Signal Dispatcher[1] If the thread number was part of the prompt, I would have expected that last line to say "Signal Dispatcher[17a]". /Staffan On 30 okt 2013, at 13:10, Daniel D. Daugherty wrote: > The current thread number is part of the jdb prompt. > So something like this: > > $ jdb Hello > Initializing jdb ... > > stop in Hello.main > Deferring breakpoint Hello.main. > It will be set after the class is loaded. > > run > run Hello > Set uncaught java.lang.Throwable > Set deferred uncaught java.lang.Throwable > > > VM Started: Set deferred breakpoint Hello.main > > Breakpoint hit: "thread=main", Hello.main(), line=3 bci=0 > 3 System.out.println("Hello World!"); > > main[1] > > where you feed these cmds to jdb: > > stop in Hello.main > run > > and your script checks for > > Breakpoint hit: "thread=main" > > and then pulls the number out of the prompt that follows: > > main[1] > > Dan > > > > On 10/30/13 7:10 AM, Staffan Larsen wrote: >> I tried, that, but couldn't find what the jdb command for getting the current thread is. Anyone? >> >> /Staffan >> >> On 30 okt 2013, at 11:17, Mikael Auno wrote: >> >>> On 2013-10-29 15:41, Staffan Larsen wrote: >>>> This test fails if there are background threads that run while the >>>> test is running. I've modified the test to use the "trace" commands >>>> in jdb with the extra thread parameter. I have assumed that the main >>>> thread has thread id 1. "trace" with thread id behaves a little bit >>>> different so a couple of extra "cont" were needed. >>>> >>>> webrev: http://cr.openjdk.java.net/~sla/7145419/webrev.00/ >>> Would it be possible to set a breakpoint in main (or some other known location) to determine the thread id (as we do in some of the JDI tests) to make sure we have the right one before continuing with the rest of the test? >>> >>> Mikael > From staffan.larsen at oracle.com Wed Oct 30 05:53:23 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 30 Oct 2013 13:53:23 +0100 Subject: RFR(S): 7145419 com/sun/jdi/JdbMethodExitTest.sh fails when a background thread is generating events. In-Reply-To: <4F85D8F8-9E95-41D9-832F-2A9AB92CD5EE@oracle.com> References: <5270DCAB.6060608@oracle.com> <5270F729.2030501@oracle.com> <4F85D8F8-9E95-41D9-832F-2A9AB92CD5EE@oracle.com> Message-ID: <471CCA60-8F04-4C29-BBC4-80AD5DEA085B@oracle.com> I think the number in the prompt is the current frame number: main[1] where [1] JdbMethodExitTest.bkpt (JdbMethodExitTest.java:84) [2] JdbMethodExitTest.main (JdbMethodExitTest.java:118) main[1] up main[2] where [2] JdbMethodExitTest.main (JdbMethodExitTest.java:118) On 30 okt 2013, at 13:26, Staffan Larsen wrote: > But that does not seem to work correctly: > > Initializing jdb ... >> stop in JdbMethodExitTest.bkpt() > Deferring breakpoint JdbMethodExitTest.bkpt(). > It will be set after the class is loaded. >> run > run JdbMethodExitTest > Set uncaught java.lang.Throwable > Set deferred uncaught java.lang.Throwable >> > VM Started: Set deferred breakpoint JdbMethodExitTest.bkpt() > > Breakpoint hit: "thread=main", JdbMethodExitTest.bkpt(), line=84 bci=0 > 84 int i = 0; //@1 breakpoint > > main[1] threads > Group system: > (java.lang.ref.Reference$ReferenceHandler)0x17c Reference Handler cond. waiting > (java.lang.ref.Finalizer$FinalizerThread)0x17b Finalizer cond. waiting > (java.lang.Thread)0x17a Signal Dispatcher running > Group main: > (java.lang.Thread)0x1 main running (at breakpoint) > main[1] thread 0x17a > Signal Dispatcher[1] > > > If the thread number was part of the prompt, I would have expected that last line to say "Signal Dispatcher[17a]". > > /Staffan > > > On 30 okt 2013, at 13:10, Daniel D. Daugherty wrote: > >> The current thread number is part of the jdb prompt. >> So something like this: >> >> $ jdb Hello >> Initializing jdb ... >>> stop in Hello.main >> Deferring breakpoint Hello.main. >> It will be set after the class is loaded. >>> run >> run Hello >> Set uncaught java.lang.Throwable >> Set deferred uncaught java.lang.Throwable >>> >> VM Started: Set deferred breakpoint Hello.main >> >> Breakpoint hit: "thread=main", Hello.main(), line=3 bci=0 >> 3 System.out.println("Hello World!"); >> >> main[1] >> >> where you feed these cmds to jdb: >> >> stop in Hello.main >> run >> >> and your script checks for >> >> Breakpoint hit: "thread=main" >> >> and then pulls the number out of the prompt that follows: >> >> main[1] >> >> Dan >> >> >> >> On 10/30/13 7:10 AM, Staffan Larsen wrote: >>> I tried, that, but couldn't find what the jdb command for getting the current thread is. Anyone? >>> >>> /Staffan >>> >>> On 30 okt 2013, at 11:17, Mikael Auno wrote: >>> >>>> On 2013-10-29 15:41, Staffan Larsen wrote: >>>>> This test fails if there are background threads that run while the >>>>> test is running. I've modified the test to use the "trace" commands >>>>> in jdb with the extra thread parameter. I have assumed that the main >>>>> thread has thread id 1. "trace" with thread id behaves a little bit >>>>> different so a couple of extra "cont" were needed. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~sla/7145419/webrev.00/ >>>> Would it be possible to set a breakpoint in main (or some other known location) to determine the thread id (as we do in some of the JDI tests) to make sure we have the right one before continuing with the rest of the test? >>>> >>>> Mikael >> > From yekaterina.kantserova at oracle.com Wed Oct 30 06:31:38 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 30 Oct 2013 14:31:38 +0100 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <5270D10D.1060201@oracle.com> References: <4e22dbcf-e8f1-47e6-8f43-1d7047811528@default> <0C3DC4C9-53EF-46BD-8733-5851B6D60F4E@oracle.com> <5270D10D.1060201@oracle.com> Message-ID: <52710A3A.8070409@oracle.com> I've forgot to mention one more fix. I've renamed JstatGcutilParser to JstatGCUtilParser (a tip from Erik), to follow standards in testlibrary (JDKToolLauncher, not JdkToolLauncher). Here is a new webrev: http://cr.openjdk.java.net/~ykantser/8022229/webrev.05/ The tests have passed in JPRT run: http://sthjprt.se.oracle.com/archives/2013/10/2013-10-30-120951.ykantser.tl/ The attached patch is ready to be pushed. Staffan, Erik, Jaroslav, Peter: thanks a lot for your time and patient, Katja On 10/30/2013 10:27 AM, Yekaterina Kantserova wrote: > > http://cr.openjdk.java.net/~ykantser/8022229/webrev.04/ > > Fixed your points and changed > ./test/sun/tools/jstatd/TestJstatdUsage.java to use JDKToolLauncher > instead of JDKFinder. > > Thanks, > Katja > > > On 10/28/2013 07:02 PM, Staffan Larsen wrote: >> Rename JstatdTest.getToolOptions() to JstatdTest.getDestination(). >> >> nit: JstatdTest.cleanUpThread() shouldn't be static. >> >> Thanks, >> /Staffan >> >> On 28 okt 2013, at 17:12, Yekaterina Kantserova >> > > wrote: >> >>> Hi, >>> >>> http://cr.openjdk.java.net/~ykantser/8022229/webrev.03/ >>> >>> Moved ToolConfig functionality to JstatdTest (renamed JstatdHelper) >>> and deleted ToolConfig. The tests are also changed a little: >>> >>> public class TestJstatdDefaults { >>> >>> public static void main(String[] args) throws Throwable { >>> JstatdTest test = new JstatdTest(); >>> test.doTest(); >>> } >>> >>> } >>> >>> Hope it looks better now. >>> >>> Thanks, >>> Katja >>> >>> ----- Ursprungligt meddelande ----- >>> Fr?n:staffan.larsen at oracle.com >>> Till:yekaterina.kantserova at oracle.com >>> >>> Kopia: serviceability-dev at openjdk.java.net >>> ,david.holmes at oracle.com >>> ,jaroslav.bachorik at oracle.com >>> ,christian.tornqvist at oracle.com >>> , >>> hotspot-dev at openjdk.java.net >>> ,mattis.castegren at oracle.com >>> >>> Skickat: m?ndag, 28 okt 2013 12:57:38 GMT +01:00 >>> Amsterdam/Berlin/Bern/Rom/Stockholm/Wien >>> ?mne: Re: RFR (S): 8022229: Intermittent test failures in >>> sun/tools/jstatd >>> >>> This looks a lot better. Just few more comments: >>> >>> ToolConfig.java >>> L72 - "getToolOptins" -> "getToolOptions" >>> L35 - why is port stored as a String? Also, could be renamed to >>> rmiRegistryPort to clarify what it is for. >>> >>> Why are some tool-specific options added in getToolOptins() and >>> some in the getJpsCmd()/getJstatdCmd()/... methods? Maybe >>> changing getToolOptins() to only return the host part of the options >>> and moving the rest of the setup to getJpsCmd()/getJstatdCmd()/...? >>> >>> >>> Thanks, >>> /Staffan >>> >>> >>> On 24 okt 2013, at 15:57, Yekaterina Kantserova >>> >> > wrote: >>> >>> Hi, >>> >>> I've done following big changes after the Staffan's review: >>> - ported JDKToolLauncher, JDKToolFinder, Plattform from hotspot >>> testlibrary (http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot) >>> for re-using in ToolConfig >>> - changed "verifiy output form jps, jstat"-methods to ignore >>> warnings from VM >>> - tools will be launched without -vmoptions >>> >>> plusmade fixes for all minorcomments. >>> >>> If it's a good idea to push testlibrary changes separately I can >>> make a separate patch for them. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ykantser/8022229/webrev.02/ >>> >>> Primal bug: >>> https://bugs.openjdk.java.net/browse/JDK-8022229 >>> >>> Similarbugs: >>> https://bugs.openjdk.java.net/browse/JDK-8019630 >>> https://bugs.openjdk.java.net/browse/JDK-6636094 >>> https://bugs.openjdk.java.net/browse/JDK-6543979 >>> >>> Thanks, >>> Katja >>> >>> >>> >>> On 10/23/2013 12:55 PM, Staffan Larsen wrote: >>> >>> test/lib/testlibrary/jdk/testlibrary/Asserts.java >>> Same code as already exists in the hotspot testlibrary. >>> No further comments. >>> >>> >>> test/lib/testlibrary/jdk/testlibrary/ProcessThread.java >>> L33: stating -> starting >>> L66: staring -> starting >>> >>> >>> test/lib/testlibrary/jdk/testlibrary/TestThread.java >>> This code comes from an internal test library. >>> No further comments. >>> >>> >>> test/lib/testlibrary/jdk/testlibrary/Utils.java >>> No comments. >>> >>> >>> test/lib/testlibrary/jdk/testlibrary/XRun.java >>> This code comes from an internal test library. >>> No further comments. >>> >>> >>> test/sun/tools/jstatd/JstatGcutilParser.java >>> The parse() method could be made more robust by discarding >>> any lines that come before the header lines. This can happen >>> if the JVM outputs a warning message for some reason before >>> running jstat. >>> I don't like the special-case for the CCS column in >>> verify() - took me a while to find it. Should we add a new >>> enum called PERCENTAGE_OR_DASH to handle that instead? >>> >>> L67: getType() should be private. >>> >>> >>> test/sun/tools/jstatd/JstatdHelper.java: >>> L54: Does verifyJpsOutput() work correctly with output of >>> the form: >>> >>> 1234 -- main class information unavailable >>> 1235 -- process information unavailable >>> >>> Also: same comment here as for JstatGcutilParser.java: >>> sometimes the JVM outputs warning messages before the output >>> from the tool. >>> >>> L46: "attach" is probably not the best way to describe the >>> operation of jps. It does not attach to the process, it >>> merely lists the running processes. Perhaps runJps() is a >>> better name? >>> >>> >>> test/sun/tools/jstatd/TestJstatdDefaults.java >>> test/sun/tools/jstatd/TestJstatdExternalRegistry.java >>> test/sun/tools/jstatd/TestJstatdPort.java >>> test/sun/tools/jstatd/TestJstatdPortAndServer.java >>> test/sun/tools/jstatd/TestJstatdServer.java >>> No comments. >>> >>> >>> test/sun/tools/jstatd/TestJstatdUsage.java >>> Same comment here as for JstatGcutilParser.java: sometimes >>> the JVM outputs warning messages before the output from the >>> tool. >>> >>> >>> test/sun/tools/jstatd/ToolConfig.java >>> ToolConfig + Utils.get(Forward)VmOptions() seem to be >>> doing similar things to JDKToolLauncher in the hotspot >>> testlibrary. It is unfortunate if we have two ways to do >>> similar things in the two different testlibraries. Would it >>> be possible to reuse the hotspot code here instead? >>> >>> You have also changed the test. Previously the tools were >>> not launched with the jtreg -vmoptions (test.vm.opts), >>> whereas now they will be. Is this intentional? >>> >>> >>> General comments: >>> >>> Can't we do: >>> * @library /lib/testlibrary >>> instead of >>> * @library ../../../lib/testlibrary >>> ? >>> >>> It seems that at least some of the functionality should be >>> reused for re-writing the jstat and jps tests as well. I >>> guess we can look at that at a later time, though. >>> >>> While I applaud the move from shell scripts to Java code, I >>> can't shake the feeling that the shell scripts were easier >>> to read and follow. The Java code is much more verbose and >>> spread out over multiple helpers and libraries, making it >>> harder to grasp. That may be the price we have to pay, though. >>> >>> >>> Thanks, >>> /Staffan >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131030/95d69ad7/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 8022229.5.patch Type: text/x-patch Size: 91312 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131030/95d69ad7/8022229.5-0001.patch From jaroslav.bachorik at oracle.com Wed Oct 30 06:51:44 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Wed, 30 Oct 2013 13:51:44 +0000 Subject: hg: jdk8/tl/jdk: 8027058: sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh Failed to initialize connector Message-ID: <20131030135216.319FA62826@hg.openjdk.java.net> Changeset: 5d1bda6c1fe3 Author: jbachorik Date: 2013-10-30 14:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d1bda6c1fe3 8027058: sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh Failed to initialize connector Summary: Dynamically discover the first available port instead of hard-coding one Reviewed-by: sla, chegar, dfuchs ! test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java From erik.gahlin at oracle.com Wed Oct 30 07:13:48 2013 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 30 Oct 2013 15:13:48 +0100 Subject: RFR: 8027209: javax/management/monitor/ThreadPoolAccTest.java fails intermittently Message-ID: <5271141C.3030400@oracle.com> Could I have a review of this intermittently failing test. Instead of doing Thread.sleep(2000) and assume principal is visible/set the test now spins until principal is available. I also cleaned up code to avoid warnings. Thanks Erik Webrev: http://cr.openjdk.java.net/~egahlin/8027209_2/ Bug: https://bugs.openjdk.java.net/browse/JDK-8027209 From yekaterina.kantserova at oracle.com Wed Oct 30 07:40:05 2013 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 30 Oct 2013 15:40:05 +0100 Subject: RFR: 8027209: javax/management/monitor/ThreadPoolAccTest.java fails intermittently In-Reply-To: <5271141C.3030400@oracle.com> References: <5271141C.3030400@oracle.com> Message-ID: <52711A45.7090000@oracle.com> Not a reviewer, so just en observation. Seems like there are 2 jtreg headers now: 24 /* 25 * @test 26 * @bug 6222826 27 * @summary Test that each thread in the thread pool runs 28 * in the context of the monitor.start() caller. 29 * @author Luis-Miguel Alventosa 30 * @run clean ThreadPoolAccTest 31 * @run build ThreadPoolAccTest 32 * @run main ThreadPoolAccTest 33 */ and 49 /* 50 * @test 51 * 52 * @run main/othervm ThreadPoolAccTest 53 */ The original one does not use "other" in @run. Thanks, Katja On 10/30/2013 03:13 PM, Erik Gahlin wrote: > Could I have a review of this intermittently failing test. > > Instead of doing Thread.sleep(2000) and assume principal is > visible/set the test now spins until principal is available. I also > cleaned up code to avoid warnings. > > Thanks > Erik > > Webrev: > http://cr.openjdk.java.net/~egahlin/8027209_2/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8027209 > From erik.gahlin at oracle.com Wed Oct 30 07:45:04 2013 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 30 Oct 2013 15:45:04 +0100 Subject: RFR: 6849945: VM Periodic Task Thread CPU time = -1ns in HotspotThreadMBean.getInternalThreadCpuTimes Message-ID: <52711B70.6050107@oracle.com> Could I have a review of this intermittently failing test. There is a race between a thread being created and the request to get its CPU time. The "/proc/..." structure might not be ready at that time and the routine will return -1. Fix is to spin in test until we get a CPU time that is not -1. I also added types for Map to avoid warnings. Thanks Erik Bug: https://bugs.openjdk.java.net/browse/JDK-6849945 Webrev: http://cr.openjdk.java.net/~egahlin/6849945_1/ From erik.gahlin at oracle.com Wed Oct 30 07:50:09 2013 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 30 Oct 2013 15:50:09 +0100 Subject: RFR: 8027209: javax/management/monitor/ThreadPoolAccTest.java fails intermittently In-Reply-To: <52711A45.7090000@oracle.com> References: <5271141C.3030400@oracle.com> <52711A45.7090000@oracle.com> Message-ID: <52711CA1.1040607@oracle.com> Will fix, not used to see @test before imports. Same problem with 6849945. Erik Yekaterina Kantserova skrev 2013-10-30 15:40: > Not a reviewer, so just en observation. Seems like there are 2 jtreg > headers now: > > 24 /* > 25 * @test > 26 * @bug 6222826 > 27 * @summary Test that each thread in the thread pool runs > 28 * in the context of the monitor.start() caller. > 29 * @author Luis-Miguel Alventosa > 30 * @run clean ThreadPoolAccTest > 31 * @run build ThreadPoolAccTest > 32 * @run main ThreadPoolAccTest > 33 */ > > and > > > 49 /* > 50 * @test > 51 * > 52 * @run main/othervm ThreadPoolAccTest > 53 */ > > The original one does not use "other" in @run. > > Thanks, > Katja > > > On 10/30/2013 03:13 PM, Erik Gahlin wrote: >> Could I have a review of this intermittently failing test. >> >> Instead of doing Thread.sleep(2000) and assume principal is >> visible/set the test now spins until principal is available. I also >> cleaned up code to avoid warnings. >> >> Thanks >> Erik >> >> Webrev: >> http://cr.openjdk.java.net/~egahlin/8027209_2/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8027209 >> > From chris.hegarty at oracle.com Wed Oct 30 07:44:31 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 30 Oct 2013 14:44:31 +0000 Subject: hg: jdk8/tl/jdk: 8026880: NetworkInterface native initializing code should check fieldID values Message-ID: <20131030144518.931296282A@hg.openjdk.java.net> Changeset: 9a5048dc7c0d Author: chegar Date: 2013-10-30 14:41 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9a5048dc7c0d 8026880: NetworkInterface native initializing code should check fieldID values Reviewed-by: alanb ! src/solaris/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface.c From staffan.larsen at oracle.com Wed Oct 30 08:01:30 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 30 Oct 2013 16:01:30 +0100 Subject: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd In-Reply-To: <52710A3A.8070409@oracle.com> References: <4e22dbcf-e8f1-47e6-8f43-1d7047811528@default> <0C3DC4C9-53EF-46BD-8733-5851B6D60F4E@oracle.com> <5270D10D.1060201@oracle.com> <52710A3A.8070409@oracle.com> Message-ID: Looks good. I will sponsor the commit. Thanks, /Staffan On 30 okt 2013, at 14:31, Yekaterina Kantserova wrote: > I've forgot to mention one more fix. I've renamed JstatGcutilParser to JstatGCUtilParser (a tip from Erik), to follow standards in testlibrary (JDKToolLauncher, not JdkToolLauncher). > > Here is a new webrev: > http://cr.openjdk.java.net/~ykantser/8022229/webrev.05/ > > The tests have passed in JPRT run: > http://sthjprt.se.oracle.com/archives/2013/10/2013-10-30-120951.ykantser.tl/ > > The attached patch is ready to be pushed. > > > Staffan, Erik, Jaroslav, Peter: thanks a lot for your time and patient, > Katja > > > > On 10/30/2013 10:27 AM, Yekaterina Kantserova wrote: >> >> http://cr.openjdk.java.net/~ykantser/8022229/webrev.04/ >> >> Fixed your points and changed ./test/sun/tools/jstatd/TestJstatdUsage.java to use JDKToolLauncher instead of JDKFinder. >> >> Thanks, >> Katja >> >> >> On 10/28/2013 07:02 PM, Staffan Larsen wrote: >>> Rename JstatdTest.getToolOptions() to JstatdTest.getDestination(). >>> >>> nit: JstatdTest.cleanUpThread() shouldn't be static. >>> >>> Thanks, >>> /Staffan >>> >>> On 28 okt 2013, at 17:12, Yekaterina Kantserova wrote: >>> >>>> Hi, >>>> >>>> http://cr.openjdk.java.net/~ykantser/8022229/webrev.03/ >>>> >>>> Moved ToolConfig functionality to JstatdTest (renamed JstatdHelper) and deleted ToolConfig. The tests are also changed a little: >>>> >>>> public class TestJstatdDefaults { >>>> >>>> public static void main(String[] args) throws Throwable { >>>> JstatdTest test = new JstatdTest(); >>>> test.doTest(); >>>> } >>>> >>>> } >>>> >>>> Hope it looks better now. >>>> >>>> Thanks, >>>> Katja >>>> >>>> ----- Ursprungligt meddelande ----- >>>> Fr?n: staffan.larsen at oracle.com >>>> Till: yekaterina.kantserova at oracle.com >>>> Kopia: serviceability-dev at openjdk.java.net, david.holmes at oracle.com, jaroslav.bachorik at oracle.com,christian.tornqvist at oracle.com, hotspot-dev at openjdk.java.net, mattis.castegren at oracle.com >>>> Skickat: m?ndag, 28 okt 2013 12:57:38 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien >>>> ?mne: Re: RFR (S): 8022229: Intermittent test failures in sun/tools/jstatd >>>> >>>> This looks a lot better. Just few more comments: >>>> >>>> ToolConfig.java >>>> L72 - "getToolOptins" -> "getToolOptions" >>>> L35 - why is port stored as a String? Also, could be renamed to rmiRegistryPort to clarify what it is for. >>>> >>>> Why are some tool-specific options added in getToolOptins() and some in the getJpsCmd()/getJstatdCmd()/... methods? Maybe changing getToolOptins() to only return the host part of the options and moving the rest of the setup to getJpsCmd()/getJstatdCmd()/...? >>>> >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>> On 24 okt 2013, at 15:57, Yekaterina Kantserova wrote: >>>> >>>> Hi, >>>> >>>> I've done following big changes after the Staffan's review: >>>> - ported JDKToolLauncher, JDKToolFinder, Plattform from hotspot testlibrary (http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot) for re-using in ToolConfig >>>> - changed "verifiy output form jps, jstat"-methods to ignore warnings from VM >>>> - tools will be launched without -vmoptions >>>> >>>> plus made fixes for all minor comments. >>>> >>>> If it's a good idea to push testlibrary changes separately I can make a separate patch for them. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ykantser/8022229/webrev.02/ >>>> >>>> Primal bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8022229 >>>> >>>> Similar bugs: >>>> https://bugs.openjdk.java.net/browse/JDK-8019630 >>>> https://bugs.openjdk.java.net/browse/JDK-6636094 >>>> https://bugs.openjdk.java.net/browse/JDK-6543979 >>>> >>>> Thanks, >>>> Katja >>>> >>>> >>>> >>>> On 10/23/2013 12:55 PM, Staffan Larsen wrote: >>>> test/lib/testlibrary/jdk/testlibrary/Asserts.java >>>> Same code as already exists in the hotspot testlibrary. >>>> No further comments. >>>> >>>> >>>> test/lib/testlibrary/jdk/testlibrary/ProcessThread.java >>>> L33: stating -> starting >>>> L66: staring -> starting >>>> >>>> >>>> test/lib/testlibrary/jdk/testlibrary/TestThread.java >>>> This code comes from an internal test library. >>>> No further comments. >>>> >>>> >>>> test/lib/testlibrary/jdk/testlibrary/Utils.java >>>> No comments. >>>> >>>> >>>> test/lib/testlibrary/jdk/testlibrary/XRun.java >>>> This code comes from an internal test library. >>>> No further comments. >>>> >>>> >>>> test/sun/tools/jstatd/JstatGcutilParser.java >>>> The parse() method could be made more robust by discarding any lines that come before the header lines. This can happen if the JVM outputs a warning message for some reason before running jstat. >>>> >>>> I don't like the special-case for the CCS column in verify() - took me a while to find it. Should we add a new enum called PERCENTAGE_OR_DASH to handle that instead? >>>> >>>> L67: getType() should be private. >>>> >>>> >>>> test/sun/tools/jstatd/JstatdHelper.java: >>>> L54: Does verifyJpsOutput() work correctly with output of the form: >>>> >>>> 1234 -- main class information unavailable >>>> 1235 -- process information unavailable >>>> >>>> Also: same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. >>>> >>>> L46: "attach" is probably not the best way to describe the operation of jps. It does not attach to the process, it merely lists the running processes. Perhaps runJps() is a better name? >>>> >>>> >>>> test/sun/tools/jstatd/TestJstatdDefaults.java >>>> test/sun/tools/jstatd/TestJstatdExternalRegistry.java >>>> test/sun/tools/jstatd/TestJstatdPort.java >>>> test/sun/tools/jstatd/TestJstatdPortAndServer.java >>>> test/sun/tools/jstatd/TestJstatdServer.java >>>> No comments. >>>> >>>> >>>> test/sun/tools/jstatd/TestJstatdUsage.java >>>> Same comment here as for JstatGcutilParser.java: sometimes the JVM outputs warning messages before the output from the tool. >>>> >>>> >>>> test/sun/tools/jstatd/ToolConfig.java >>>> ToolConfig + Utils.get(Forward)VmOptions() seem to be doing similar things to JDKToolLauncher in the hotspot testlibrary. It is unfortunate if we have two ways to do similar things in the two different testlibraries. Would it be possible to reuse the hotspot code here instead? >>>> >>>> You have also changed the test. Previously the tools were not launched with the jtreg -vmoptions (test.vm.opts), whereas now they will be. Is this intentional? >>>> >>>> >>>> General comments: >>>> >>>> Can't we do: >>>> * @library /lib/testlibrary >>>> instead of >>>> * @library ../../../lib/testlibrary >>>> ? >>>> >>>> It seems that at least some of the functionality should be reused for re-writing the jstat and jps tests as well. I guess we can look at that at a later time, though. >>>> >>>> While I applaud the move from shell scripts to Java code, I can't shake the feeling that the shell scripts were easier to read and follow. The Java code is much more verbose and spread out over multiple helpers and libraries, making it harder to grasp. That may be the price we have to pay, though. >>>> >>>> >>>> Thanks, >>>> /Staffan >>> >> > > <8022229.5.patch> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131030/1e1906bf/attachment-0001.html From staffan.larsen at oracle.com Wed Oct 30 08:03:29 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 30 Oct 2013 16:03:29 +0100 Subject: RFR 8014506: Test for Jdp (Java Discovery Protocol) feature In-Reply-To: <526FCC02.3050308@oracle.com> References: <51A31867.9080602@oracle.com> <51CAC09B.7070706@oracle.com> <7E2E50A8-1FB1-429B-8AAB-94863C215623@oracle.com> <51D56A11.5030600@oracle.com> <5214AC0A.4010603@oracle.com> <70F043F0-9F19-4761-B175-1D6652B5A146@oracle.com> <3B20B5DC-9E92-4EB6-97FF-0F2D2B4E1E10@oracle.com> <52244497.8010902@oracle.com> <5267C65A.9060602@oracle.com> <4EDB8911-E772-4B13-B0EB-AA90C729A49A@oracle.com> <526FCC02.3050308@oracle.com> Message-ID: Alex, This looks much better! Thanks for spending the time. README: nit: contribuited -> contributed JdpTestUtilTest.java: Can you add a comment saying this is a test for the tests - just like PacketTest.java and PortAlreadyInUseTest.java? PortFinder.java: Please remove this and use Utils.getFreePort() since ykantser's fix is now pushed. Thanks, /Staffan On 29 okt 2013, at 15:53, Alex Schenkman wrote: > Hi Staffan, > > There is a new webrev here [1], addressing your comments. > > The Jdp specs have changed a bit, adding three optional fields to the Jdp packet [2]. > The JEP-168 [3] is not updated yet, but Dmitry will do it soon. > This enhancement request is tracking the changes needed for SQE [4]. > > See inlined answers for details on your previos comments, please. > > Thanks! > > > [1] http://cr.openjdk.java.net/~dsamersoff/sponsorship/aschenkman/8014506/webrev.04/ > [2] https://bugs.openjdk.java.net/browse/JDK-8004213 > [3] http://openjdk.java.net/jeps/168 > [4] https://bugs.openjdk.java.net/browse/JDK-8027436 > > On 2013-10-24 10:54, Staffan Larsen wrote: >> Alex, >> >> test/sun/management/jdp/README >> Thanks for providing a README! >> References to JDK-7169888 seem incorrect to me. >> L8: "written by" appears twice. >> L11: "defautl" -> "default" >> > Fixed. >> test/lib/testlibrary/jdk/testlibrary/PortFinder.java >> This should be coordinated with the review for 8022229 which contains the same code in a different testlibrary class: >> http://cr.openjdk.java.net/~ykantser/8022229/webrev.01/test/lib/testlibrary/jdk/testlibrary/Utils.java.html >> > I made a private copy of this function, and have marked it as deprecated. > As soon as ykanster's code is merged I can delete my private function and use the library. > The reason for this is to get this patch pushed without further delay. > >> test/sun/management/jdp/7169888/JdpClient.java >> test/sun/management/jdp/7169888/JdpDoSomething.java >> test/sun/management/jdp/7169888/JdpTest.sh >> test/sun/management/jdp/7169888/JdpUnitTest.java >> These were moved to a subdirectory, but these tests have nothing to do with bug 7169888, so why that name? In any case we should avoid naming test directories after bug ids, and instead use a descriptive name. >> > This bug number was wrong. These tests were now moved back to the jdp folder. > I have expanded the README file with some details about these tests. > > Dmitry's shell-based are as follows: > test_01 - basic test, check if JDP packet assembler and other > parts of JDP is not broken > > test_02 - test if JDP starts with custom parameters. > > test_03 - test if jcmd is able to start jdp with > custom parameters (disabled) > > test_04 - test if JDP starts with default parameters > > test_05 - test if jcmd is able to start jdp with default > parameters (disabled) > > > test_03 and test_05 are diabled becuase there is a mismatch between hotsport and jdk repos, according to Dmitry. These cases (jcmd) are not covered by this patch, and are part of the test enhacements [4]. > > test_01 does partly overlap with the Java-based tests, but we should keep it until we implement the latest enhacements [4]. > > >> test/sun/management/jdp/ClientConnection.java >> No comments. >> >> test/sun/management/jdp/DefaultLauncher.java >> Can "@library ../../../lib/testlibrary" be replaced by "@library /lib/testlibrary" ? >> > Fixed. >> test/sun/management/jdp/OffLauncher.java >> Can "@library ../../../lib/testlibrary" be replaced by "@library /lib/testlibrary" ? >> > Fixed. > >> test/sun/management/jdp/SpecificJdpAddressLauncher.java >> Can "@library ../../../lib/testlibrary" be replaced by "@library /lib/testlibrary" ? >> > Fixed. >> test/sun/management/jdp/DynamicLauncher.java >> No comments. >> > Fixed. > >> test/sun/management/jdp/JdpOffTest.java >> For the future: it is customary that the file containing the jtreg directives be named xxxTest.java, and supporting files not ending in Test. >> > I have renamed the tests following your recomendation. > Jtreg tests have now the test suffix. > >> test/sun/management/jdp/JdpOnTest.java >> For the future: it is customary that the file containing the jtreg directives be named xxxTest.java, and supporting files not ending in Test. >> > Same as above. >> test/sun/management/jdp/JdpTest.java >> No comments. >> >> test/sun/management/jdp/JdpTestUtil.java >> No comments. >> >> test/sun/management/jdp/JdpTestUtilTest.java >> test/sun/management/jdp/PacketTest.java >> test/sun/management/jdp/PortAlreadyInUseTest.java >> These are tests for the tests. But where are the tests for the tests for the tests? :) >> Not reviewed. >> >> >> Thanks, >> /Staffan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131030/8237b069/attachment.html From staffan.larsen at oracle.com Wed Oct 30 08:02:35 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Wed, 30 Oct 2013 15:02:35 +0000 Subject: hg: jdk8/tl/jdk: 8022229: Intermittent test failures in sun/tools/jstatd Message-ID: <20131030150308.90CDE6282B@hg.openjdk.java.net> Changeset: b04b124418d8 Author: ykantser Date: 2013-10-30 13:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b04b124418d8 8022229: Intermittent test failures in sun/tools/jstatd Reviewed-by: sla, egahlin, jbachorik, allwin + test/lib/testlibrary/jdk/testlibrary/Asserts.java + test/lib/testlibrary/jdk/testlibrary/JDKToolFinder.java + test/lib/testlibrary/jdk/testlibrary/JDKToolLauncher.java + test/lib/testlibrary/jdk/testlibrary/Platform.java + test/lib/testlibrary/jdk/testlibrary/ProcessThread.java + test/lib/testlibrary/jdk/testlibrary/TestThread.java + test/lib/testlibrary/jdk/testlibrary/Utils.java + test/lib/testlibrary/jdk/testlibrary/XRun.java + test/sun/tools/jstatd/JstatGCUtilParser.java + test/sun/tools/jstatd/JstatdTest.java + test/sun/tools/jstatd/TestJstatdDefaults.java + test/sun/tools/jstatd/TestJstatdExternalRegistry.java + test/sun/tools/jstatd/TestJstatdPort.java + test/sun/tools/jstatd/TestJstatdPortAndServer.java + test/sun/tools/jstatd/TestJstatdServer.java + test/sun/tools/jstatd/TestJstatdUsage.java - test/sun/tools/jstatd/jpsOutput1.awk - test/sun/tools/jstatd/jstatGcutilOutput1.awk - test/sun/tools/jstatd/jstatdDefaults.sh - test/sun/tools/jstatd/jstatdExternalRegistry.sh - test/sun/tools/jstatd/jstatdPort.sh - test/sun/tools/jstatd/jstatdServerName.sh - test/sun/tools/jstatd/jstatdUsage1.sh - test/sun/tools/jstatd/usage.out From staffan.larsen at oracle.com Wed Oct 30 08:08:18 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 30 Oct 2013 16:08:18 +0100 Subject: RFR: 6849945: VM Periodic Task Thread CPU time = -1ns in HotspotThreadMBean.getInternalThreadCpuTimes In-Reply-To: <52711B70.6050107@oracle.com> References: <52711B70.6050107@oracle.com> Message-ID: Looks good, minus the extra @test tag. /Staffan On 30 okt 2013, at 15:45, Erik Gahlin wrote: > Could I have a review of this intermittently failing test. > > There is a race between a thread being created and the request to get its CPU time. The "/proc/..." structure might not be ready at that time and the routine will return -1. > > Fix is to spin in test until we get a CPU time that is not -1. I also added types for Map to avoid warnings. > > Thanks > Erik > > Bug: > https://bugs.openjdk.java.net/browse/JDK-6849945 > > Webrev: > http://cr.openjdk.java.net/~egahlin/6849945_1/ > > From mandy.chung at oracle.com Wed Oct 30 08:37:06 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 30 Oct 2013 15:37:06 +0000 Subject: hg: jdk8/tl/langtools: 8027481: jdeps to handle classes with the same package name and correct profile for javax.crypto.* Message-ID: <20131030153721.0710C6282D@hg.openjdk.java.net> Changeset: aa91bc6e8480 Author: mchung Date: 2013-10-30 08:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/aa91bc6e8480 8027481: jdeps to handle classes with the same package name and correct profile for javax.crypto.* Reviewed-by: alanb, dfuchs ! src/share/classes/com/sun/tools/jdeps/Analyzer.java ! src/share/classes/com/sun/tools/jdeps/Archive.java ! src/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/share/classes/com/sun/tools/jdeps/Profile.java ! test/tools/jdeps/Basic.java ! test/tools/jdeps/Test.java + test/tools/jdeps/javax/activity/NotCompactProfile.java + test/tools/jdeps/p/Bar.java From huizhe.wang at oracle.com Wed Oct 30 08:59:44 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Wed, 30 Oct 2013 15:59:44 +0000 Subject: hg: jdk8/tl/jaxp: 8024378: StAX parser shall support JAXP properties Message-ID: <20131030160009.AA6AD62830@hg.openjdk.java.net> Changeset: 04778b00286a Author: joehw Date: 2013-10-30 08:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/04778b00286a 8024378: StAX parser shall support JAXP properties Reviewed-by: dfuchs, lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java From mikael.gerdin at oracle.com Wed Oct 30 08:57:16 2013 From: mikael.gerdin at oracle.com (mikael.gerdin at oracle.com) Date: Wed, 30 Oct 2013 15:57:16 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes Message-ID: <20131030155728.A0F8E6282E@hg.openjdk.java.net> Changeset: ea79ab313e98 Author: mgerdin Date: 2013-10-30 15:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ea79ab313e98 8027252: Crash in interpreter because get_unsigned_2_byte_index_at_bcp reads 4 bytes Summary: Use 2-byte loads to load indexes from the byte code stream to avoid out of bounds reads. Reviewed-by: coleenp, sspitsyn ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp From mandy.chung at oracle.com Wed Oct 30 09:30:17 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 30 Oct 2013 09:30:17 -0700 Subject: jmx-dev RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: <5270EC4B.9080205@oracle.com> References: <526681FD.90604@oracle.com> <5266DA56.6050609@oracle.com> <52678280.1070004@oracle.com> <4972770C-A8BB-40A0-9BB8-885AA6B707BC@oracle.com> <52678509.2020002@oracle.com> <68F92D47-E916-426B-8D6A-2EA48302053D@oracle.com> <5267C3AD.5050306@oracle.com> <5267C74F.2010302@oracle.com> <5267CC00.7080509@oracle.com> <5267DDFC.4060607@oracle.com> <52685571.1090407@oracle.com> <52692847.1030806@oracle.com> <526975F4.8060707@oracle.com> <5270EC4B.9080205@oracle.com> Message-ID: <52713419.5040809@oracle.com> On 10/30/2013 4:23 AM, Jaroslav Bachorik wrote: > Ok. I've added a big object and an initial call to System.gc(). But > I'm leaving the calls to System.gc() right before checking the pools > as well - just to be sure. > > http://cr.openjdk.java.net/~jbachorik/8020467/webrev.04 > The update looks okay and I think System.gc() at line 90 is no longer needed as the failure was due to the empty old gen. thanks for the update. Mandy From michael.fang at oracle.com Wed Oct 30 09:39:32 2013 From: michael.fang at oracle.com (michael.fang at oracle.com) Date: Wed, 30 Oct 2013 16:39:32 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131030164115.C0F1062835@hg.openjdk.java.net> Changeset: 550244957351 Author: mfang Date: 2013-10-30 09:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/550244957351 6192407: s10_70, ko, s1/dvd, minor misspelling under "Select Software Localizations" Reviewed-by: yhuang ! src/share/classes/sun/util/resources/ko/LocaleNames_ko.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: e45b48874ba9 Author: mfang Date: 2013-10-30 09:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e45b48874ba9 6931564: Incorrect display name of Locale for south africa Reviewed-by: yhuang ! src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java From jaroslav.bachorik at oracle.com Wed Oct 30 09:58:13 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 30 Oct 2013 17:58:13 +0100 Subject: jmx-dev RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: <52713419.5040809@oracle.com> References: <526681FD.90604@oracle.com> <5266DA56.6050609@oracle.com> <52678280.1070004@oracle.com> <4972770C-A8BB-40A0-9BB8-885AA6B707BC@oracle.com> <52678509.2020002@oracle.com> <68F92D47-E916-426B-8D6A-2EA48302053D@oracle.com> <5267C3AD.5050306@oracle.com> <5267C74F.2010302@oracle.com> <5267CC00.7080509@oracle.com> <5267DDFC.4060607@oracle.com> <52685571.1090407@oracle.com> <52692847.1030806@oracle.com> <526975F4.8060707@oracle.com> <5270EC4B.9080205@oracle.com> <52713419.5040809@oracle.com> Message-ID: <52713AA5.3050102@oracle.com> On 30.10.2013 17:30, Mandy Chung wrote: > > On 10/30/2013 4:23 AM, Jaroslav Bachorik wrote: >> Ok. I've added a big object and an initial call to System.gc(). But >> I'm leaving the calls to System.gc() right before checking the pools >> as well - just to be sure. >> >> http://cr.openjdk.java.net/~jbachorik/8020467/webrev.04 >> > > The update looks okay and I think System.gc() at line 90 is no longer > needed as the failure was due to the empty old gen. > > thanks for the update. Thanks for the review. I've left the System.gc() at line 90 intact - when discussing this with Bengt during the review he was concerned that other pools might be susceptible to this kind of problem and having a full GC right before the check could lessen the probability of running into the data races described in this issue. -JB- > Mandy From jaroslav.bachorik at oracle.com Wed Oct 30 09:56:50 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Wed, 30 Oct 2013 16:56:50 +0000 Subject: hg: jdk8/tl/jdk: 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool Message-ID: <20131030165725.8FCDA62837@hg.openjdk.java.net> Changeset: 2a714dabb624 Author: jbachorik Date: 2013-10-30 17:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a714dabb624 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool Reviewed-by: mchung, brutisso ! test/java/lang/management/MemoryPoolMXBean/ThresholdTest.java From vincent.x.ryan at oracle.com Wed Oct 30 10:56:14 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Wed, 30 Oct 2013 17:56:14 +0000 Subject: hg: jdk8/tl: 8027567: JDK 8 build failure: the correct version of GNU make is being rejected Message-ID: <20131030175615.20F536283E@hg.openjdk.java.net> Changeset: 067355edfbf8 Author: vinnie Date: 2013-10-30 17:31 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/rev/067355edfbf8 8027567: JDK 8 build failure: the correct version of GNU make is being rejected Reviewed-by: chegar, erikj ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh From vicente.romero at oracle.com Wed Oct 30 11:11:40 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 30 Oct 2013 18:11:40 +0000 Subject: hg: jdk8/tl/langtools: 8027327: jar files related to test test/tools/javac/ExtDirs/ExtDirTest.java should be removed from the repo Message-ID: <20131030181143.3E96662841@hg.openjdk.java.net> Changeset: 537fa895fd74 Author: vromero Date: 2013-10-30 18:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/537fa895fd74 8027327: jar files related to test test/tools/javac/ExtDirs/ExtDirTest.java should be removed from the repo Reviewed-by: ksrini ! test/tools/javac/ExtDirs/ExtDirTest.java - test/tools/javac/ExtDirs/ext1/pkg1.jar - test/tools/javac/ExtDirs/ext2/pkg2.jar - test/tools/javac/ExtDirs/ext3/pkg1.jar - test/tools/javac/ExtDirs/ext3/pkg2.jar From brian.goetz at oracle.com Wed Oct 30 11:21:21 2013 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 30 Oct 2013 18:21:21 +0000 Subject: hg: jdk8/tl/langtools: 8024930: Re-enable disabled bridging tests Message-ID: <20131030182131.EB59462842@hg.openjdk.java.net> Changeset: 62a67e0875ff Author: briangoetz Date: 2013-10-30 14:12 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/62a67e0875ff 8024930: Re-enable disabled bridging tests Reviewed-by: psandoz, rfield ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/SourceModel.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java From michael.x.mcmahon at oracle.com Wed Oct 30 11:41:41 2013 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Wed, 30 Oct 2013 18:41:41 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20131030184313.1141862843@hg.openjdk.java.net> Changeset: 7bc67bed3c14 Author: michaelm Date: 2013-10-30 18:37 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bc67bed3c14 8027570: NullPointerException in URLPermission.hashCode() Reviewed-by: chegar ! src/share/classes/java/net/URLPermission.java ! test/java/net/URLPermission/URLPermissionTest.java Changeset: 281e26d7f325 Author: michaelm Date: 2013-10-30 18:38 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/281e26d7f325 Merge - make/sun/awt/FILES_c_macosx.gmk - make/sun/awt/FILES_export_macosx.gmk - makefiles/GendataBreakIterator.gmk - makefiles/GendataFontConfig.gmk - makefiles/GendataHtml32dtd.gmk - makefiles/GendataTZDB.gmk - makefiles/GendataTimeZone.gmk - makefiles/GenerateJavaSources.gmk - makefiles/GensrcBuffer.gmk - makefiles/GensrcCLDR.gmk - makefiles/GensrcCharacterData.gmk - makefiles/GensrcCharsetCoder.gmk - makefiles/GensrcCharsetMapping.gmk - makefiles/GensrcExceptions.gmk - makefiles/GensrcIcons.gmk - makefiles/GensrcJDWP.gmk - makefiles/GensrcJObjC.gmk - makefiles/GensrcLocaleDataMetaInfo.gmk - makefiles/GensrcMisc.gmk - makefiles/GensrcProperties.gmk - makefiles/GensrcSwing.gmk - makefiles/GensrcX11Wrappers.gmk - src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java - src/macosx/native/com/apple/resources/MacOSXResourceBundle.m - src/share/classes/java/lang/invoke/MagicLambdaImpl.java ! src/share/classes/java/net/URLPermission.java - src/share/demo/jfc/Notepad/resources/Notepad_fr.properties - src/share/demo/jfc/Notepad/resources/Notepad_sv.properties - src/solaris/doc/sun/man/man1/ja/javaws.1 - src/solaris/doc/sun/man/man1/javaws.1 - test/java/net/NetworkInterface/MemLeakTest.java - test/jdk/lambda/vm/DefaultMethodsTest.java - test/sun/management/jmxremote/bootstrap/CustomLauncherTest.sh - test/sun/management/jmxremote/bootstrap/LocalManagementTest.sh - test/sun/tools/jstatd/jpsOutput1.awk - test/sun/tools/jstatd/jstatGcutilOutput1.awk - test/sun/tools/jstatd/jstatdDefaults.sh - test/sun/tools/jstatd/jstatdExternalRegistry.sh - test/sun/tools/jstatd/jstatdPort.sh - test/sun/tools/jstatd/jstatdServerName.sh - test/sun/tools/jstatd/jstatdUsage1.sh - test/sun/tools/jstatd/usage.out From karen.kinnear at oracle.com Wed Oct 30 11:47:10 2013 From: karen.kinnear at oracle.com (karen.kinnear at oracle.com) Date: Wed, 30 Oct 2013 18:47:10 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20131030184719.3261462844@hg.openjdk.java.net> Changeset: fdd464c8d62e Author: acorn Date: 2013-10-30 09:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/fdd464c8d62e 8027304: Lambda: inheriting abstract + 1 default -> default, not ICCE Reviewed-by: hseigel, zgu ! src/share/vm/classfile/defaultMethods.cpp Changeset: 4fe7815b04f5 Author: acorn Date: 2013-10-30 09:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4fe7815b04f5 Merge From martinrb at google.com Wed Oct 30 13:02:23 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 30 Oct 2013 13:02:23 -0700 Subject: jmx-dev RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: <52713AA5.3050102@oracle.com> References: <526681FD.90604@oracle.com> <5266DA56.6050609@oracle.com> <52678280.1070004@oracle.com> <4972770C-A8BB-40A0-9BB8-885AA6B707BC@oracle.com> <52678509.2020002@oracle.com> <68F92D47-E916-426B-8D6A-2EA48302053D@oracle.com> <5267C3AD.5050306@oracle.com> <5267C74F.2010302@oracle.com> <5267CC00.7080509@oracle.com> <5267DDFC.4060607@oracle.com> <52685571.1090407@oracle.com> <52692847.1030806@oracle.com> <526975F4.8060707@oracle.com> <5270EC4B.9080205@oracle.com> <52713419.5040809@oracle.com> <52713AA5.3050102@oracle.com> Message-ID: Technically, System.gc() doesn't promise anything. I believe it may merely initiate a gc if the gc implementation is concurrent. Check out awaitFullGc in my beloved GcFinalization https://code.google.com/p/guava-libraries/source/browse/guava-testlib/src/com/google/common/testing/GcFinalization.java?spec=svn196edb139d49d373abbce013008da0206b83f0ca&r=ae6bc9be431d7601b1f4713679efea126673378e On Wed, Oct 30, 2013 at 9:58 AM, Jaroslav Bachorik < jaroslav.bachorik at oracle.com> wrote: > On 30.10.2013 17:30, Mandy Chung wrote: > >> >> On 10/30/2013 4:23 AM, Jaroslav Bachorik wrote: >> >>> Ok. I've added a big object and an initial call to System.gc(). But >>> I'm leaving the calls to System.gc() right before checking the pools >>> as well - just to be sure. >>> >>> http://cr.openjdk.java.net/~**jbachorik/8020467/webrev.04 >>> >>> >> The update looks okay and I think System.gc() at line 90 is no longer >> needed as the failure was due to the empty old gen. >> >> thanks for the update. >> > > Thanks for the review. I've left the System.gc() at line 90 intact - when > discussing this with Bengt during the review he was concerned that other > pools might be susceptible to this kind of problem and having a full GC > right before the check could lessen the probability of running into the > data races described in this issue. > > -JB- > > Mandy >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131030/adb1cf70/attachment.html From lana.steuck at oracle.com Wed Oct 30 15:48:25 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 30 Oct 2013 22:48:25 +0000 Subject: hg: jdk8/tl: 6 new changesets Message-ID: <20131030224827.5C29D6284C@hg.openjdk.java.net> Changeset: b098ee22aa97 Author: erikj Date: 2013-10-24 10:43 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b098ee22aa97 8009280: JCE jurisdiction policy files not copied into jdk/lib/security Reviewed-by: tbell, ihse ! common/makefiles/JavaCompilation.gmk Changeset: 3c48e11c3901 Author: dholmes Date: 2013-10-24 20:45 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3c48e11c3901 8016096: [macosx] jawt_md.h shipped with jdk is outdated Summary: Revised build system and added platform specific headers for Mac OS X Reviewed-by: ihse, erikj Contributed-by: david.dehaven at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: 72ef61df77e5 Author: ihse Date: 2013-10-25 13:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/72ef61df77e5 8027300: configure should use LIBS instead of LDFLAGS when testing freetype Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: dfbc93f26f38 Author: dcubed Date: 2013-10-25 10:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/dfbc93f26f38 8027117: adapt JDK-7165611 to new build-infra whitespace/indent policy Summary: Fix whitespace/indent issues. Reviewed-by: hseigel, coleenp, erikj, ihse ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/makefiles/NativeCompilation.gmk Changeset: 4f2011496393 Author: katleman Date: 2013-10-28 16:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4f2011496393 Merge Changeset: 37d2736caf46 Author: lana Date: 2013-10-30 13:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/37d2736caf46 Merge ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in From lana.steuck at oracle.com Wed Oct 30 15:50:56 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 30 Oct 2013 22:50:56 +0000 Subject: hg: jdk8/tl/hotspot: 67 new changesets Message-ID: <20131030225901.85A9E62850@hg.openjdk.java.net> Changeset: d6d8aeb2c2d4 Author: amurillo Date: 2013-10-19 08:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d6d8aeb2c2d4 8026928: new hotspot build - hs25-b56 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 384c92148c68 Author: amurillo Date: 2013-10-21 14:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/384c92148c68 8023496: [jprt] build and test solaris 64-bits only Reviewed-by: tbell, jcoomes ! make/jprt.properties Changeset: f9d4ed6c88dd Author: dholmes Date: 2013-10-21 20:51 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f9d4ed6c88dd 8026872: [TESTBUG] Classes OOMCrashClass4000_1.class and OOMCrashClass1960_2.class from runtime/ClassFile/ tests won't run on compact profiles Reviewed-by: sla, sspitsyn ! test/TEST.groups Changeset: 8cd1abf3ecab Author: dholmes Date: 2013-10-21 21:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8cd1abf3ecab Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! test/TEST.groups - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: 2036c97e3af0 Author: dholmes Date: 2013-10-21 22:36 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2036c97e3af0 Merge Changeset: 7fe6ef09d242 Author: farvidsson Date: 2013-10-16 09:20 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7fe6ef09d242 8025638: jmap returns 0 instead of 1 when it fails. Summary: Re-factored some code handling return values and fails/errors during tool execution. Reviewed-by: sla, kevinw Contributed-by: fredrik.arvidsson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FlagDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JSnap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/ObjectHistogram.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/StackTrace.java ! agent/src/share/classes/sun/jvm/hotspot/tools/SysPropsDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/JSDB.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java Changeset: 042cf42c72bd Author: simonis Date: 2013-10-16 15:06 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/042cf42c72bd 8026703: Wrongly placed element in Event-Based JVM Tracing .xsl files Reviewed-by: sla, kamg ! src/share/vm/trace/traceEventClasses.xsl ! src/share/vm/trace/traceEventIds.xsl ! src/share/vm/trace/traceTypes.xsl Changeset: d248425bcfe8 Author: hseigel Date: 2013-10-16 14:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d248425bcfe8 8024804: Crash when InterfaceMethodref resolves to Object.registerNatives Summary: Added check for NULL prior to continuation of method look up to avoid runtime crash during look up of Object's superclass' methods. Reviewed-by: coleenp, hseigel Contributed-by: lois.foltan at oracle.com ! src/share/vm/interpreter/linkResolver.cpp + test/runtime/8024804/RegisterNatives.java Changeset: 9e0ef3f02648 Author: hseigel Date: 2013-10-16 15:26 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9e0ef3f02648 Merge Changeset: 1bee3014cf2a Author: dsamersoff Date: 2013-10-17 16:08 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1bee3014cf2a 8025812: tmtools/jmap/heap_config tests fail on Linux-ia32 because it Cant attach to the core file Summary: Coredump store memsz elf field rounded up to page Reviewed-by: dholmes, sla ! agent/src/os/linux/ps_core.c Changeset: ffb471203842 Author: erikj Date: 2013-10-17 16:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ffb471203842 8026792: HOTSPOT: licensee reports a JDK8 build failure after 8005849/8005008 fixes integrated. Reviewed-by: dholmes, sla ! make/windows/makefiles/trace.make Changeset: ad8e901ca2e1 Author: sla Date: 2013-10-17 12:15 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ad8e901ca2e1 Merge Changeset: d2db09f281ca Author: dsamersoff Date: 2013-10-17 16:45 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d2db09f281ca 8005810: Update Hotspot Serviceability Agent for Method Parameter Reflection and Generic Type Signature Data Summary: Hotspot was updated to store method parameter reflection and generic type signature data at runtime. Serviceability agent support was updated for this data Reviewed-by: coleenp, minqi, sla Contributed-by: eric.mccorkle at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! src/share/vm/runtime/vmStructs.cpp Changeset: b942ac65ac86 Author: dsamersoff Date: 2013-10-17 17:01 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b942ac65ac86 Merge Changeset: d0453d2fd045 Author: dsamersoff Date: 2013-10-18 10:37 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d0453d2fd045 Merge Changeset: ee99e1a7c5fb Author: ccheung Date: 2013-10-18 19:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ee99e1a7c5fb Merge ! src/share/vm/interpreter/linkResolver.cpp - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! src/share/vm/runtime/vmStructs.cpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: 996d1f2f056f Author: dsamersoff Date: 2013-10-19 21:29 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/996d1f2f056f 8026930: In ManagementAgent.start it should be possible to set the jdp.name parameter (hotspot part) Summary: Pass one more property from Agent to JdpController Reviewed-by: jbachorik, sla ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: 1327b7f85503 Author: ccheung Date: 2013-10-21 17:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1327b7f85503 Merge Changeset: 662c154d2749 Author: hseigel Date: 2013-10-22 14:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/662c154d2749 8026394: Eclipse fails with JDK8 build 111 Summary: If the resolved interface does not itself contain "clone" or "finalize" methods, the method/interface method resolution looks to the interface's super class, java.lang.Object. With the JDK 8 interface method accessability check requirement, since these two methods are declared within Object as protected, they must be special cased in LinkResolver::check_method_accessability() in order to avoid an IAE. Reviewed-by: acorn, dholmes Contributed-by: lois.foltan at oracle.com ! src/share/vm/interpreter/linkResolver.cpp + test/runtime/8026394/InterfaceObjectTest.java Changeset: b8860472c377 Author: iklam Date: 2013-10-22 14:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b8860472c377 8014910: deadlock between JVM/TI ClassPrepare event handler and CompilerThread Summary: Revert changes in JDK-8008962 Reviewed-by: coleenp, sspitsyn ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiEnv.cpp Changeset: 28be4c586b70 Author: iklam Date: 2013-10-22 16:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/28be4c586b70 Merge Changeset: a997d762fa20 Author: hseigel Date: 2013-10-22 15:54 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a997d762fa20 8026809: [TESTBUG] Create regression test for JDK-8026041 Summary: Created simple regression test for the bug Reviewed-by: hseigel, lfoltan, zgu Contributed-by: mikhailo.seledtsov at oracle.com + test/runtime/CommandLine/PrintGCApplicationConcurrentTime.java Changeset: c183576a2dd1 Author: hseigel Date: 2013-10-22 22:14 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c183576a2dd1 Merge Changeset: b658cfe35857 Author: farvidsson Date: 2013-10-23 10:24 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b658cfe35857 8026808: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failed with unexpected exit value Summary: Fixes a bug with vmArgs when using JDKToolLauncher Reviewed-by: sla, dholmes ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: b3a4d4279fa3 Author: ccheung Date: 2013-10-24 17:20 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b3a4d4279fa3 Merge Changeset: 74e00b98d5dd Author: anoll Date: 2013-10-17 19:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/74e00b98d5dd 8026708: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation Summary: Increase size for the template interpreter accordingly Reviewed-by: kvn, twisti ! src/cpu/x86/vm/templateInterpreter_x86.hpp Changeset: 1856ea98184a Author: adlertz Date: 2013-10-18 10:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1856ea98184a 8022783: Nashorn test fails with: assert(!def_outside->member(r)) Summary: Enables private copies of inputs for recent spill copies as well Reviewed-by: kvn, twisti ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/reg_split.cpp Changeset: e3b736cf4fa3 Author: adlertz Date: 2013-10-18 09:36 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e3b736cf4fa3 Merge Changeset: 252d541466ea Author: morris Date: 2013-10-18 12:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/252d541466ea 8008242: VerifyOops is broken on SPARC Summary: Fixed displacement issues in SPARC macroassembler and ensure that getClass intrinsic temporary result is T_METADATA Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 3213ba4d3dff Author: roland Date: 2013-10-19 12:16 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3213ba4d3dff 8024069: replace_in_map() should operate on parent maps Summary: type information gets lost because replace_in_map() doesn't update parent maps Reviewed-by: kvn, twisti ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/multnode.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp Changeset: 19c5a042b0b3 Author: iignatyev Date: 2013-10-19 21:54 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/19c5a042b0b3 8026414: [TESTBUG] Tests for Tiered/NonTiered levels Reviewed-by: twisti, iveresov + test/compiler/tiered/CompLevelsTest.java + test/compiler/tiered/NonTieredLevelsTest.java + test/compiler/tiered/TieredLevelsTest.java Changeset: 600c83f8e6a5 Author: iignatyev Date: 2013-10-19 21:54 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/600c83f8e6a5 8023318: compiler/whitebox tests timeout with enabled TieredCompilation Reviewed-by: kvn, twisti ! test/compiler/whitebox/CompilerWhiteBoxTest.java Changeset: e842cc2d2dfb Author: iveresov Date: 2013-10-19 22:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e842cc2d2dfb Merge Changeset: 52575a17a36c Author: iignatyev Date: 2013-10-21 09:21 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/52575a17a36c 8026865: [TESTBUG] 'compiler/print/PrintInlining.java' should specify -XX:+UnlockDiagnosticVMOptions Reviewed-by: twisti, iveresov ! test/compiler/print/PrintInlining.java Changeset: 4748b3308cda Author: iveresov Date: 2013-10-21 17:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4748b3308cda Merge Changeset: 5ccbab1c69f3 Author: roland Date: 2013-10-22 09:51 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ccbab1c69f3 8026251: New type profiling points: parameters to methods Summary: x86 interpreter and c1 type profiling for parameters on method entries Reviewed-by: kvn, twisti ! src/cpu/x86/vm/bytecodeInterpreter_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp + src/cpu/x86/vm/interp_masm_x86.cpp + src/cpu/x86/vm/interp_masm_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp Changeset: 435c7b4577cd Author: rbackman Date: 2013-10-21 15:31 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/435c7b4577cd 8026959: assert(!n->pinned() || n->is_MachConstantBase()) failed: only pinned MachConstantBase node is expected here Reviewed-by: iveresov, roland ! src/share/vm/opto/compile.cpp Changeset: 36e17466dd39 Author: rbackman Date: 2013-10-22 14:02 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/36e17466dd39 Merge Changeset: 8b4bbba322d3 Author: anoll Date: 2013-10-23 10:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8b4bbba322d3 8026407: VM crashes on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified Summary: Ensure currently required generation of AdapterHandlerLibrary::create_native_wrapper() Reviewed-by: roland, iveresov ! src/share/vm/compiler/compileBroker.cpp Changeset: b2ee5dc63353 Author: roland Date: 2013-10-23 12:40 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b2ee5dc63353 8024070: C2 needs some form of type speculation Summary: record unused type profile information with type system, propagate and use it. Reviewed-by: kvn, twisti ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/arguments.cpp + test/compiler/types/TypeSpeculation.java Changeset: 4c9115774c8e Author: adlertz Date: 2013-10-23 10:44 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4c9115774c8e 8026939: assert(Reachblock != NULL) failed: Reachblock must be non-NULL Summary: We can reach this state from phi input rematerialization, so pass in the Reaches of the predecessor Reviewed-by: roland, twisti ! src/share/vm/opto/reg_split.cpp Changeset: 97d400662426 Author: adlertz Date: 2013-10-23 19:22 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/97d400662426 Merge Changeset: 9acbfe04b5c3 Author: iveresov Date: 2013-10-23 11:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9acbfe04b5c3 8026495: JVM Crashes when started with -XX:+DTraceMethodProbes on Solaris x86_64 Summary: Fix wrong calling convention in LIR_Assembler::emit_unwind_handler(), T_METADATA support in calling convention generator, C1 register allocator Reviewed-by: twisti, jrose ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp Changeset: 1c90f0072f0d Author: twisti Date: 2013-10-23 15:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1c90f0072f0d 8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms Reviewed-by: iveresov, jrose ! src/share/vm/classfile/systemDictionary.cpp Changeset: 3a04e444da6d Author: iveresov Date: 2013-10-23 16:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3a04e444da6d Merge Changeset: 59e8ad757e19 Author: rbackman Date: 2013-10-18 10:41 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/59e8ad757e19 8026844: Various Math functions needs intrinsification Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/mathexactnode.cpp ! src/share/vm/opto/mathexactnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/intrinsics/mathexact/AddExactICondTest.java + test/compiler/intrinsics/mathexact/AddExactIConstantTest.java + test/compiler/intrinsics/mathexact/AddExactILoadTest.java + test/compiler/intrinsics/mathexact/AddExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/AddExactINonConstantTest.java + test/compiler/intrinsics/mathexact/AddExactIRepeatTest.java + test/compiler/intrinsics/mathexact/AddExactLConstantTest.java + test/compiler/intrinsics/mathexact/AddExactLNonConstantTest.java - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java + test/compiler/intrinsics/mathexact/DecExactITest.java + test/compiler/intrinsics/mathexact/DecExactLTest.java + test/compiler/intrinsics/mathexact/IncExactITest.java + test/compiler/intrinsics/mathexact/IncExactLTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java + test/compiler/intrinsics/mathexact/MulExactICondTest.java + test/compiler/intrinsics/mathexact/MulExactIConstantTest.java + test/compiler/intrinsics/mathexact/MulExactILoadTest.java + test/compiler/intrinsics/mathexact/MulExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/MulExactINonConstantTest.java + test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java + test/compiler/intrinsics/mathexact/MulExactLConstantTest.java + test/compiler/intrinsics/mathexact/MulExactLNonConstantTest.java + test/compiler/intrinsics/mathexact/NegExactIConstantTest.java + test/compiler/intrinsics/mathexact/NegExactILoadTest.java + test/compiler/intrinsics/mathexact/NegExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/NegExactINonConstantTest.java + test/compiler/intrinsics/mathexact/NegExactLConstantTest.java + test/compiler/intrinsics/mathexact/NegExactLNonConstantTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java + test/compiler/intrinsics/mathexact/SubExactICondTest.java + test/compiler/intrinsics/mathexact/SubExactIConstantTest.java + test/compiler/intrinsics/mathexact/SubExactILoadTest.java + test/compiler/intrinsics/mathexact/SubExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/SubExactINonConstantTest.java + test/compiler/intrinsics/mathexact/SubExactIRepeatTest.java + test/compiler/intrinsics/mathexact/SubExactLConstantTest.java + test/compiler/intrinsics/mathexact/SubExactLNonConstantTest.java ! test/compiler/intrinsics/mathexact/Verify.java Changeset: 68f07c29521b Author: anoll Date: 2013-10-15 08:38 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/68f07c29521b 8025740: Typo. Error line for wrong ReservedCodeCacheSize value is printed twice Summary: Remove duplicate print Reviewed-by: kvn, twisti ! src/share/vm/runtime/arguments.cpp Changeset: d95eca175eff Author: sspitsyn Date: 2013-10-23 20:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d95eca175eff 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. Reviewed-by: jrose ! src/share/vm/prims/methodHandles.cpp Changeset: 0d1661d63d70 Author: vlivanov Date: 2013-10-23 20:20 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0d1661d63d70 8012941: JSR 292: too deep inlining might crash compiler because of stack overflow Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_globals.hpp Changeset: f7d928a3181c Author: roland Date: 2013-10-24 19:32 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f7d928a3181c 8026978: JSR292: fatal error: Type profiling not implemented on this platform Summary: force TypeProfileLevel to 0 on non x86 Reviewed-by: twisti ! src/share/vm/runtime/arguments.cpp Changeset: 395499125cb0 Author: iveresov Date: 2013-10-24 16:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/395499125cb0 Merge - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 6b32b911d723 Author: iveresov Date: 2013-10-24 16:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6b32b911d723 Merge ! src/share/vm/runtime/vmStructs.cpp - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 1d1ea10fe09f Author: mgerdin Date: 2013-10-15 13:56 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1d1ea10fe09f 8015255: NPG: Don't waste fragment at the end of a VirtualSpaceNode before retiring it. Summary: Chunk up the last piece of committed memory in a VSN when getting a new one. Reviewed-by: stefank, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/prims/jni.cpp Changeset: 91a88c8450f4 Author: mgerdin Date: 2013-10-18 09:31 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/91a88c8450f4 8026698: Incorrect error handling in Metaspace::allocate Reviewed-by: stefank, jwilhelm ! src/share/vm/memory/metaspace.cpp Changeset: a1b05d4a6fd0 Author: stefank Date: 2013-10-21 09:34 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a1b05d4a6fd0 8026781: Add missing test to exercise -XX:+UseLargePagesInMetaspace Reviewed-by: mgerdin, brutisso + test/gc/TestSystemGC.java Changeset: 3dd24766da44 Author: stefank Date: 2013-10-21 01:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3dd24766da44 Merge Changeset: 2fab5b7e6140 Author: ehelin Date: 2013-10-21 14:20 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2fab5b7e6140 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops Reviewed-by: coleenp, mgerdin, sspitsyn ! src/share/vm/prims/jvmtiImpl.cpp Changeset: c7f403b05168 Author: sjohanss Date: 2013-10-22 11:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c7f403b05168 8026848: -XX:+G1SummarizeRSetStats can result in wrong exit code and crash Summary: Changed the use of %d to SIZE_FORMAT macro in format string when printing size_t values. Reviewed-by: stefank, ehelin ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp Changeset: 0823c8bac468 Author: jcoomes Date: 2013-10-22 12:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0823c8bac468 Merge Changeset: 1b422ef5288a Author: tschatzl Date: 2013-10-23 10:23 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1b422ef5288a 8025728: Missing volatile specifier for field G1AllocRegion::_alloc_region Summary: The field G1AllocRegion::_alloc_region needs to be declared volatile as it is used with that intention. Otherwise the compiler may generate the code that reloads the value which might have changed in the meantime, leading to spurious crashes. Reviewed-by: iveresov, simonis, tschatzl Contributed-by: Axel Siebenborn ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp Changeset: 0dcdec729cda Author: jcoomes Date: 2013-10-25 08:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0dcdec729cda Merge Changeset: 82a9cdbf683e Author: amurillo Date: 2013-10-25 13:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/82a9cdbf683e Merge ! src/share/vm/services/diagnosticCommand.cpp - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: bde83ddf920c Author: amurillo Date: 2013-10-25 13:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bde83ddf920c Added tag hs25-b56 for changeset 82a9cdbf683e ! .hgtags Changeset: e006d2e25bc7 Author: dholmes Date: 2013-10-24 20:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e006d2e25bc7 8025673: [macosx] Disable X11 AWT toolkit Summary: Disable but not completely remove the XAWT and headless toolkits on Mac OS X Reviewed-by: dholmes Contributed-by: david.dehaven at oracle.com ! src/os/bsd/vm/os_bsd.cpp Changeset: 913a35723a0a Author: katleman Date: 2013-10-28 16:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/913a35723a0a Merge Changeset: 7fd913010dbb Author: katleman Date: 2013-10-29 14:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7fd913010dbb Merge Changeset: ea1b8c643fc8 Author: lana Date: 2013-10-30 13:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ea1b8c643fc8 Merge - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java From lana.steuck at oracle.com Wed Oct 30 15:49:43 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 30 Oct 2013 22:49:43 +0000 Subject: hg: jdk8/tl/jdk: 7 new changesets Message-ID: <20131030225652.23DDB6284E@hg.openjdk.java.net> Changeset: 110c4fe4c354 Author: erikj Date: 2013-10-24 10:43 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/110c4fe4c354 8009280: JCE jurisdiction policy files not copied into jdk/lib/security Reviewed-by: tbell, ihse ! makefiles/BuildJdk.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk + makefiles/CreateSecurityJars.gmk ! makefiles/SignJars.gmk Changeset: f40f639e1f52 Author: dholmes Date: 2013-10-24 20:46 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f40f639e1f52 8016096: [macosx] jawt_md.h shipped with jdk is outdated Summary: Revised build system and added platform specific headers for Mac OS X Reviewed-by: anthony, art, ihse, erikj Contributed-by: david.dehaven at oracle.com ! makefiles/CopyFiles.gmk ! makefiles/gensrc/GensrcX11Wrappers.gmk + src/macosx/javavm/export/jawt_md.h + src/macosx/javavm/export/jni_md.h + src/macosx/javavm/export/jvm_md.h ! src/macosx/native/sun/awt/AWTSurfaceLayers.h ! src/macosx/native/sun/awt/CMenuComponent.h ! src/macosx/native/sun/awt/jawt.m ! src/macosx/native/sun/font/CoreTextSupport.h ! src/share/javavm/export/jawt.h Changeset: f3c95d961557 Author: dholmes Date: 2013-10-24 20:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f3c95d961557 8025673: [macosx] Disable X11 AWT toolkit Summary: Disable but not completely remove the XAWT and headless toolkits on Mac OS X Reviewed-by: anthony, art, ihse, erikj Contributed-by: david.dehaven at oracle.com ! makefiles/CompileJavaClasses.gmk ! makefiles/GenerateSources.gmk ! makefiles/Tools.gmk ! makefiles/lib/Awt2dLibraries.gmk ! src/share/native/java/lang/System.c ! src/share/native/java/lang/java_props.h ! src/solaris/native/java/lang/java_props_macosx.c ! src/solaris/native/java/lang/java_props_macosx.h ! src/solaris/native/java/lang/java_props_md.c ! src/solaris/native/sun/awt/fontpath.c ! test/java/awt/Toolkit/Headless/WrappedToolkitTest/WrappedToolkitTest.sh Changeset: 5813af4c02e4 Author: dcubed Date: 2013-10-25 10:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5813af4c02e4 8027117: adapt JDK-7165611 to new build-infra whitespace/indent policy Summary: Fix whitespace/indent issues. Reviewed-by: hseigel, coleenp, erikj, ihse ! makefiles/Import.gmk Changeset: 1628a137edca Author: katleman Date: 2013-10-28 16:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1628a137edca Merge Changeset: f26a0c8071bd Author: erikj Date: 2013-10-29 15:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f26a0c8071bd 8027298: broken link in jdk8b113 macosx binaries Reviewed-by: dcubed, ihse ! makefiles/Import.gmk Changeset: 348ffbd19feb Author: lana Date: 2013-10-30 13:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/348ffbd19feb Merge ! makefiles/CreateJars.gmk + makefiles/CreateSecurityJars.gmk From brian.goetz at oracle.com Wed Oct 30 16:37:05 2013 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 30 Oct 2013 23:37:05 +0000 Subject: hg: jdk8/tl/jdk: 8027318: Lambda Metafactory: generate serialization-hostile read/writeObject methods for non-serializable lambdas Message-ID: <20131030233742.12BDF62854@hg.openjdk.java.net> Changeset: ddb0b681654a Author: briangoetz Date: 2013-10-29 12:31 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ddb0b681654a 8027318: Lambda Metafactory: generate serialization-hostile read/writeObject methods for non-serializable lambdas Reviewed-by: rfield, psandoz ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! test/java/util/stream/test/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java From bradford.wetmore at oracle.com Wed Oct 30 16:53:42 2013 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Wed, 30 Oct 2013 23:53:42 +0000 Subject: hg: jdk8/tl/jdk: 8027526: CheckTipsAndVersions.java failing occasionally Message-ID: <20131030235426.0554C62855@hg.openjdk.java.net> Changeset: f731d096530f Author: wetmore Date: 2013-10-30 16:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f731d096530f 8027526: CheckTipsAndVersions.java failing occasionally Reviewed-by: mullan, mchung ! test/java/security/Signature/SignatureGetAlgorithm.java From joe.darcy at oracle.com Wed Oct 30 17:33:16 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 31 Oct 2013 00:33:16 +0000 Subject: hg: jdk8/tl/jdk: 8005294: Consider default methods for additions to AnnotatedElement Message-ID: <20131031003400.8C14062856@hg.openjdk.java.net> Changeset: e8894e3224d9 Author: darcy Date: 2013-10-30 17:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8894e3224d9 8005294: Consider default methods for additions to AnnotatedElement Reviewed-by: jfranck, plevart, mchung, abuckley, sogoel ! src/share/classes/java/lang/reflect/AnnotatedElement.java + test/java/lang/reflect/AnnotatedElement/TestAnnotatedElementDefaults.java From stuart.marks at oracle.com Wed Oct 30 18:41:36 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Thu, 31 Oct 2013 01:41:36 +0000 Subject: hg: jdk8/tl/jdk: 8023863: deprecate support for statically-generated stubs from RMI (JRMP); ... Message-ID: <20131031014252.633DA6285E@hg.openjdk.java.net> Changeset: 1ea1b24c1a04 Author: smarks Date: 2013-10-30 18:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ea1b24c1a04 8023863: deprecate support for statically-generated stubs from RMI (JRMP) 4449028: exportObject() javadoc should specify behavior for null socket factories Reviewed-by: dfuchs, darcy ! src/share/classes/java/rmi/server/RemoteStub.java ! src/share/classes/java/rmi/server/UnicastRemoteObject.java ! src/share/classes/java/rmi/server/package.html From brian.burkhalter at oracle.com Wed Oct 30 17:47:15 2013 From: brian.burkhalter at oracle.com (brian.burkhalter at oracle.com) Date: Thu, 31 Oct 2013 00:47:15 +0000 Subject: hg: jdk8/tl/jdk: 6910473: java.math.BigInteger.bitLength() may return negative "int" on large numbers; ... Message-ID: <20131031004802.2EF9262857@hg.openjdk.java.net> Changeset: 0734e1584d9d Author: bpb Date: 2013-10-30 17:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0734e1584d9d 6910473: java.math.BigInteger.bitLength() may return negative "int" on large numbers 8021203: BigInteger.doubleValue/floatValue returns 0.0 instead of Infinity 8021204: Constructor BigInteger(String val, int radix) doesn't detect overflow 8022780: Incorrect BigInteger division because of MutableBigInteger.bitLength() overflow Summary: Prevent construction of overflowed BigIntegers. Reviewed-by: bpb, darcy, psandoz Contributed-by: Dmitry Nadezhin ! src/share/classes/java/math/BigInteger.java ! src/share/classes/java/math/MutableBigInteger.java + test/java/math/BigInteger/BitLengthOverflow.java + test/java/math/BigInteger/DivisionOverflow.java + test/java/math/BigInteger/DoubleValueOverflow.java ! test/java/math/BigInteger/ExtremeShiftingTests.java + test/java/math/BigInteger/StringConstructorOverflow.java + test/java/math/BigInteger/SymmetricRangeTests.java From coleen.phillimore at oracle.com Wed Oct 30 19:54:02 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 30 Oct 2013 22:54:02 -0400 Subject: RFR 8026946: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint should use MethodH,andle Message-ID: <5271C64A.8010001@oracle.com> 8026948: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint might not work with anonymous classes Summary: Walk methods in breakpoints for marking on stack so they aren't deallocated by redefine classes. Use class_holder rather than class_loader to keep GC from reclaiming class owning the method. This is two bug fixes to the same code. open webrev at http://cr.openjdk.java.net/~coleenp/8026946_8026948/ bug link https://bugs.openjdk.java.net/browse/JDK-8026946 https://bugs.openjdk.java.net/browse/JDK-8026948 Tested with vm.quick.testlist - and verified the jdi tests eg nsk/jdi/BScenarios/hotswap/tc01x001 test this path. Thanks, Coleen From staffan.larsen at oracle.com Wed Oct 30 23:32:28 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 31 Oct 2013 07:32:28 +0100 Subject: jmx-dev RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: References: <526681FD.90604@oracle.com> <5266DA56.6050609@oracle.com> <52678280.1070004@oracle.com> <4972770C-A8BB-40A0-9BB8-885AA6B707BC@oracle.com> <52678509.2020002@oracle.com> <68F92D47-E916-426B-8D6A-2EA48302053D@oracle.com> <5267C3AD.5050306@oracle.com> <5267C74F.2010302@oracle.com> <5267CC00.7080509@oracle.com> <5267DDFC.4060607@oracle.com> <52685571.1090407@oracle.com> <52692847.1030806@oracle.com> <526975F4.8060707@oracle.com> <5270EC4B.9080205@oracle.com> <52713419.5040809@oracle.com> <52713AA5.3050102@oracle.com> Message-ID: <9C102C02-3375-4F93-9969-432431DCBE7B@oracle.com> Quoting Bengt from earlier in this conversation: "As for just doing a System.gc() to force a GC I think you can rely on that System.gc() does a full GC in Hotspot unless someone sets -XX:+DisableExplicitGC on the command line. Considering that you are relying on Hotspot specifc names for pools I don't think it is a limitation to the test to rely on the Hotspot implementatoin of System.gc()." The spec for System.gc() doesn't promising anything, but all the collectors in Hotspot are implemented to do a full GC when System.gc() is called. Thanks, /Staffan On 30 okt 2013, at 21:02, Martin Buchholz wrote: > Technically, System.gc() doesn't promise anything. I believe it may merely initiate a gc if the gc implementation is concurrent. Check out awaitFullGc in my beloved GcFinalization > > https://code.google.com/p/guava-libraries/source/browse/guava-testlib/src/com/google/common/testing/GcFinalization.java?spec=svn196edb139d49d373abbce013008da0206b83f0ca&r=ae6bc9be431d7601b1f4713679efea126673378e > > > On Wed, Oct 30, 2013 at 9:58 AM, Jaroslav Bachorik wrote: > On 30.10.2013 17:30, Mandy Chung wrote: > > On 10/30/2013 4:23 AM, Jaroslav Bachorik wrote: > Ok. I've added a big object and an initial call to System.gc(). But > I'm leaving the calls to System.gc() right before checking the pools > as well - just to be sure. > > http://cr.openjdk.java.net/~jbachorik/8020467/webrev.04 > > > The update looks okay and I think System.gc() at line 90 is no longer > needed as the failure was due to the empty old gen. > > thanks for the update. > > Thanks for the review. I've left the System.gc() at line 90 intact - when discussing this with Bengt during the review he was concerned that other pools might be susceptible to this kind of problem and having a full GC right before the check could lessen the probability of running into the data races described in this issue. > > -JB- > > Mandy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131031/13793423/attachment.html From martinrb at google.com Thu Oct 31 00:08:31 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 31 Oct 2013 00:08:31 -0700 Subject: jmx-dev RFR 8020467: Inconsistency between usage.getUsed() and isUsageThresholdExceeded() with CMS Old Gen pool In-Reply-To: <9C102C02-3375-4F93-9969-432431DCBE7B@oracle.com> References: <526681FD.90604@oracle.com> <5266DA56.6050609@oracle.com> <52678280.1070004@oracle.com> <4972770C-A8BB-40A0-9BB8-885AA6B707BC@oracle.com> <52678509.2020002@oracle.com> <68F92D47-E916-426B-8D6A-2EA48302053D@oracle.com> <5267C3AD.5050306@oracle.com> <5267C74F.2010302@oracle.com> <5267CC00.7080509@oracle.com> <5267DDFC.4060607@oracle.com> <52685571.1090407@oracle.com> <52692847.1030806@oracle.com> <526975F4.8060707@oracle.com> <5270EC4B.9080205@oracle.com> <52713419.5040809@oracle.com> <52713AA5.3050102@oracle.com> <9C102C02-3375-4F93-9969-432431DCBE7B@oracle.com> Message-ID: On Wed, Oct 30, 2013 at 11:32 PM, Staffan Larsen wrote: > Quoting Bengt from earlier in this conversation: > > "As for just doing a System.gc() to force a GC I think you can rely on > that System.gc() does a full GC in Hotspot unless someone sets > -XX:+DisableExplicitGC on the command line. Considering that you are > relying on Hotspot specifc names for pools I don't think it is a limitation > to the test to rely on the Hotspot implementatoin of System.gc()." > > A full synchronous gc is a stronger condition than a full gc. > The spec for System.gc() doesn't promising anything, but all the > collectors in Hotspot are implemented to do a full GC when System.gc() is > called. > > I'm not a GC expert and I have no proof, but that is not my understanding. I believe that a concurrent gc (CMS) remains concurrent even if initiated by System.gc(). Hmmm.... checking hotspot flags I see: java -XX:+PrintFlagsFinal bool ExplicitGCInvokesConcurrent = false {product} bool ExplicitGCInvokesConcurrentAndUnloadsClasses = false {product} which suggests you are right for default gc operation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131031/bc3723e0/attachment-0001.html From sundararajan.athijegannathan at oracle.com Thu Oct 31 01:52:59 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 31 Oct 2013 08:52:59 +0000 Subject: hg: jdk8/tl/nashorn: 4 new changesets Message-ID: <20131031085308.7E9D96286F@hg.openjdk.java.net> Changeset: adab2c628923 Author: jlaskey Date: 2013-10-29 14:22 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/adab2c628923 8027447: The wrong string buffer is specified for stderr in $EXEC Reviewed-by: lagergren, sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java Changeset: 645197151cc3 Author: jlaskey Date: 2013-10-30 11:28 -0300 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/645197151cc3 8027532: nashorn should only use jdk8 apis in the compact1 profile Reviewed-by: sundar, lagergren, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java Changeset: a002c1bb88f9 Author: sundar Date: 2013-10-30 20:09 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a002c1bb88f9 8027562: eval should load second and subsequent arguments for side effect Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8027562.js + test/script/basic/JDK-8027562.js.EXPECTED Changeset: 5ce78473d6c3 Author: sundar Date: 2013-10-31 12:50 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/5ce78473d6c3 Merge From jaroslav.bachorik at oracle.com Thu Oct 31 03:27:04 2013 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 31 Oct 2013 11:27:04 +0100 Subject: RFR 7144200: java/lang/management/ClassLoadingMXBean/LoadCounts.java failed with JFR enabled In-Reply-To: References: <5252BE3B.5020607@oracle.com> Message-ID: <52723078.2010507@oracle.com> On 7.10.2013 16:35, Staffan Larsen wrote: > This will make it less likely for the test to fail, but does not guarantee it since there is nothing that says classloading will be done in 300 ms. Any failures will unfortunately be harder to reproduce. (And the test is now 300 ms slower to run.) > > A different solution is to only allow the number of classes to increase, but not be strict about the increase being exactly 4. That would of course make the test less stringent, but very stable. I've implemented the check for non-decrementing class count. I talked to SQE about not running this test with JFR but it seems that it is not currently possible to exclude single tests from parametrized runs. Also, the test is marked as /othervm http://cr.openjdk.java.net/~jbachorik/7144200/webrev.02 Cheers, -JB- > > In any case, I think the test has to be marked as /othervm since running other tests simultaneously will impact this test. > > S/taffan > > On 7 okt 2013, at 15:59, Jaroslav Bachorik wrote: > >> The test captures the number of loaded classes right at the start and then checks the diffs when it's finished. However, it seems that there might by some async class loading still going on, initiated by JFR. >> >> The patch simply adds a loop to wait for the number of loaded classes to settle before continuing. This should prevent the test failing with JFR intermittently. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-7144200 >> Webrev: http://cr.openjdk.java.net/~jbachorik/7144200/webrev.00/ >> >> Cheers, >> >> -JB- > From staffan.larsen at oracle.com Thu Oct 31 03:43:29 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 31 Oct 2013 11:43:29 +0100 Subject: RFR 7144200: java/lang/management/ClassLoadingMXBean/LoadCounts.java failed with JFR enabled In-Reply-To: <52723078.2010507@oracle.com> References: <5252BE3B.5020607@oracle.com> <52723078.2010507@oracle.com> Message-ID: <7B3294CA-2BA9-458E-82D8-6491306B8392@oracle.com> Looks good! Thanks, /Staffan On 31 okt 2013, at 11:27, Jaroslav Bachorik wrote: > On 7.10.2013 16:35, Staffan Larsen wrote: >> This will make it less likely for the test to fail, but does not guarantee it since there is nothing that says classloading will be done in 300 ms. Any failures will unfortunately be harder to reproduce. (And the test is now 300 ms slower to run.) >> >> A different solution is to only allow the number of classes to increase, but not be strict about the increase being exactly 4. That would of course make the test less stringent, but very stable. > > I've implemented the check for non-decrementing class count. > > I talked to SQE about not running this test with JFR but it seems that it is not currently possible to exclude single tests from parametrized runs. > > Also, the test is marked as /othervm > > http://cr.openjdk.java.net/~jbachorik/7144200/webrev.02 > > Cheers, > > -JB- > >> >> In any case, I think the test has to be marked as /othervm since running other tests simultaneously will impact this test. >> >> S/taffan >> >> On 7 okt 2013, at 15:59, Jaroslav Bachorik wrote: >> >>> The test captures the number of loaded classes right at the start and then checks the diffs when it's finished. However, it seems that there might by some async class loading still going on, initiated by JFR. >>> >>> The patch simply adds a loop to wait for the number of loaded classes to settle before continuing. This should prevent the test failing with JFR intermittently. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-7144200 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/7144200/webrev.00/ >>> >>> Cheers, >>> >>> -JB- >> > From paul.sandoz at oracle.com Thu Oct 31 04:03:16 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 31 Oct 2013 11:03:16 +0000 Subject: hg: jdk8/tl/jdk: 8027316: Distinct operation on an unordered stream should not be a barrier Message-ID: <20131031110754.2866B62875@hg.openjdk.java.net> Changeset: 18c111c17231 Author: psandoz Date: 2013-10-31 11:59 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/18c111c17231 8027316: Distinct operation on an unordered stream should not be a barrier Reviewed-by: henryjen, mduigou, briangoetz ! src/share/classes/java/util/stream/DistinctOps.java ! src/share/classes/java/util/stream/StreamSpliterators.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java From jaroslav.bachorik at oracle.com Thu Oct 31 04:14:55 2013 From: jaroslav.bachorik at oracle.com (jaroslav.bachorik at oracle.com) Date: Thu, 31 Oct 2013 11:14:55 +0000 Subject: hg: jdk8/tl/jdk: 7144200: java/lang/management/ClassLoadingMXBean/LoadCounts.java failed with JFR enabled Message-ID: <20131031111541.D248862876@hg.openjdk.java.net> Changeset: bb4b1e1e390d Author: jbachorik Date: 2013-10-31 11:59 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb4b1e1e390d 7144200: java/lang/management/ClassLoadingMXBean/LoadCounts.java failed with JFR enabled Summary: Make the test less stringent by not requiring the number of loaded classes to increase by a specific number Reviewed-by: sla ! test/ProblemList.txt ! test/java/lang/management/ClassLoadingMXBean/LoadCounts.java From daniel.daugherty at oracle.com Thu Oct 31 05:39:26 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 31 Oct 2013 08:39:26 -0400 Subject: RFR(S): 7145419 com/sun/jdi/JdbMethodExitTest.sh fails when a background thread is generating events. In-Reply-To: <471CCA60-8F04-4C29-BBC4-80AD5DEA085B@oracle.com> References: <5270DCAB.6060608@oracle.com> <5270F729.2030501@oracle.com> <4F85D8F8-9E95-41D9-832F-2A9AB92CD5EE@oracle.com> <471CCA60-8F04-4C29-BBC4-80AD5DEA085B@oracle.com> Message-ID: <52724F7E.1020100@oracle.com> I stand corrected. Only the thread name is in the prompt. I think I've been away from 'jdb' too long... Filtering the output of this might help: $ jdb Hello Initializing jdb ... > stop in Hello.main Deferring breakpoint Hello.main. It will be set after the class is loaded. > run run Hello Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable > VM Started: Set deferred breakpoint Hello.main Breakpoint hit: "thread=main", Hello.main(), line=3 bci=0 3 System.out.println("Hello World!"); main[1] threads Group system: (java.lang.ref.Reference$ReferenceHandler)0x141 Reference Handler cond. waiting (java.lang.ref.Finalizer$FinalizerThread)0x140 Finalizer cond. waiting (java.lang.Thread)0x13f Signal Dispatcher running Group main: (java.lang.Thread)0x1 main running (at breakpoint) (java.lang.Thread)0x260 Thread-1 running main[1] but is definitely more work. Dan On 10/30/13 8:53 AM, Staffan Larsen wrote: > I think the number in the prompt is the current frame number: > > main[1] where > [1] JdbMethodExitTest.bkpt (JdbMethodExitTest.java:84) > [2] JdbMethodExitTest.main (JdbMethodExitTest.java:118) > main[1] up > main[2] where > [2] JdbMethodExitTest.main (JdbMethodExitTest.java:118) > > > On 30 okt 2013, at 13:26, Staffan Larsen wrote: > >> But that does not seem to work correctly: >> >> Initializing jdb ... >>> stop in JdbMethodExitTest.bkpt() >> Deferring breakpoint JdbMethodExitTest.bkpt(). >> It will be set after the class is loaded. >>> run >> run JdbMethodExitTest >> Set uncaught java.lang.Throwable >> Set deferred uncaught java.lang.Throwable >> VM Started: Set deferred breakpoint JdbMethodExitTest.bkpt() >> >> Breakpoint hit: "thread=main", JdbMethodExitTest.bkpt(), line=84 bci=0 >> 84 int i = 0; //@1 breakpoint >> >> main[1] threads >> Group system: >> (java.lang.ref.Reference$ReferenceHandler)0x17c Reference Handler cond. waiting >> (java.lang.ref.Finalizer$FinalizerThread)0x17b Finalizer cond. waiting >> (java.lang.Thread)0x17a Signal Dispatcher running >> Group main: >> (java.lang.Thread)0x1 main running (at breakpoint) >> main[1] thread 0x17a >> Signal Dispatcher[1] >> >> >> If the thread number was part of the prompt, I would have expected that last line to say "Signal Dispatcher[17a]". >> >> /Staffan >> >> >> On 30 okt 2013, at 13:10, Daniel D. Daugherty wrote: >> >>> The current thread number is part of the jdb prompt. >>> So something like this: >>> >>> $ jdb Hello >>> Initializing jdb ... >>>> stop in Hello.main >>> Deferring breakpoint Hello.main. >>> It will be set after the class is loaded. >>>> run >>> run Hello >>> Set uncaught java.lang.Throwable >>> Set deferred uncaught java.lang.Throwable >>> VM Started: Set deferred breakpoint Hello.main >>> >>> Breakpoint hit: "thread=main", Hello.main(), line=3 bci=0 >>> 3 System.out.println("Hello World!"); >>> >>> main[1] >>> >>> where you feed these cmds to jdb: >>> >>> stop in Hello.main >>> run >>> >>> and your script checks for >>> >>> Breakpoint hit: "thread=main" >>> >>> and then pulls the number out of the prompt that follows: >>> >>> main[1] >>> >>> Dan >>> >>> >>> >>> On 10/30/13 7:10 AM, Staffan Larsen wrote: >>>> I tried, that, but couldn't find what the jdb command for getting the current thread is. Anyone? >>>> >>>> /Staffan >>>> >>>> On 30 okt 2013, at 11:17, Mikael Auno wrote: >>>> >>>>> On 2013-10-29 15:41, Staffan Larsen wrote: >>>>>> This test fails if there are background threads that run while the >>>>>> test is running. I've modified the test to use the "trace" commands >>>>>> in jdb with the extra thread parameter. I have assumed that the main >>>>>> thread has thread id 1. "trace" with thread id behaves a little bit >>>>>> different so a couple of extra "cont" were needed. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~sla/7145419/webrev.00/ >>>>> Would it be possible to set a breakpoint in main (or some other known location) to determine the thread id (as we do in some of the JDI tests) to make sure we have the right one before continuing with the rest of the test? >>>>> >>>>> Mikael From brian.goetz at oracle.com Thu Oct 31 08:01:04 2013 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 31 Oct 2013 15:01:04 +0000 Subject: hg: jdk8/tl/jdk: 8024633: Lambda linkage performance - initialize generated class earlier Message-ID: <20131031150144.7E52862880@hg.openjdk.java.net> Changeset: 9732816c9d17 Author: briangoetz Date: 2013-10-29 12:45 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9732816c9d17 8024633: Lambda linkage performance - initialize generated class earlier Reviewed-by: briangoetz, rfield Contributed-by: sergey.kuksenko at oracle.com ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java From serguei.spitsyn at oracle.com Thu Oct 31 09:43:30 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 31 Oct 2013 09:43:30 -0700 Subject: RFR 8026946: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint should use MethodH,andle In-Reply-To: <5271C64A.8010001@oracle.com> References: <5271C64A.8010001@oracle.com> Message-ID: <527288B2.2030407@oracle.com> Coleen, It looks good, thank you for fixing it! Thanks, Serguei On 10/30/13 7:54 PM, Coleen Phillimore wrote: > 8026948: JvmtiEnv::SetBreakpoint and JvmtiEnv::ClearBreakpoint might > not work with anonymous classes > Summary: Walk methods in breakpoints for marking on stack so they > aren't deallocated by redefine classes. Use class_holder rather than > class_loader to keep GC from reclaiming class owning the method. > > This is two bug fixes to the same code. > > open webrev at http://cr.openjdk.java.net/~coleenp/8026946_8026948/ > bug link https://bugs.openjdk.java.net/browse/JDK-8026946 > https://bugs.openjdk.java.net/browse/JDK-8026948 > > Tested with vm.quick.testlist - and verified the jdi tests eg > nsk/jdi/BScenarios/hotswap/tc01x001 test this path. > > Thanks, > Coleen From brian.goetz at oracle.com Thu Oct 31 07:49:05 2013 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 31 Oct 2013 14:49:05 +0000 Subject: hg: jdk8/tl/jdk: 8024637: Lambda linkage performance - use reflection instead of ASM to manipulate parameter types; ... Message-ID: <20131031145701.89E916287E@hg.openjdk.java.net> Changeset: 82ee370c3d7e Author: briangoetz Date: 2013-10-31 10:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82ee370c3d7e 8024637: Lambda linkage performance - use reflection instead of ASM to manipulate parameter types 8023984: Lambda linkage performance - use a method ref to a static factory instead of a ctor ref Reviewed-by: briangoetz, rfield Contributed-by: sergey.kuksenko at oracle.com ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java From mandy.chung at oracle.com Thu Oct 31 10:53:05 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 31 Oct 2013 10:53:05 -0700 Subject: Review request for 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java Message-ID: <52729901.8070604@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8022208 Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.00/ The retry loop in checking the thread state assumes that the thread state is in RUNNABLE state which isn't always the case (it could be any other state). The fix is to remove that check and the thread should be a daemon thread so that the test can terminate if any exception is thrown. jdk/test/java/lang/management/ThreadMXBean/ThreadStateTest.java is a similar test that performs additional validation on the ThreadMXBean API. It should also be fixed as a daemon thread I take the opportunity to change it to use java.util.concurrent.Phaser instead of the utility class. Mandy From martinrb at google.com Thu Oct 31 11:01:11 2013 From: martinrb at google.com (Martin Buchholz) Date: Thu, 31 Oct 2013 11:01:11 -0700 Subject: Review request for 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java In-Reply-To: <52729901.8070604@oracle.com> References: <52729901.8070604@oracle.com> Message-ID: + iterations++; Using ++ on a volatile int looks racy. Using an AtomicInteger is strictly more reliable. On Thu, Oct 31, 2013 at 10:53 AM, Mandy Chung wrote: > https://bugs.openjdk.java.net/browse/JDK-8022208 > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.00/ > > The retry loop in checking the thread state assumes that the thread state > is in RUNNABLE state which isn't always the case (it could be any other > state). The fix is to remove that check and the thread should be a daemon > thread so that the test can terminate if any exception is thrown. > > jdk/test/java/lang/management/ThreadMXBean/ThreadStateTest.java is a > similar test that performs additional validation on the ThreadMXBean API. > It should also be fixed as a daemon thread I take the opportunity to > change it to use java.util.concurrent.Phaser instead of the utility class. > > Mandy > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131031/8fdc8116/attachment.html From mandy.chung at oracle.com Thu Oct 31 11:22:43 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 31 Oct 2013 11:22:43 -0700 Subject: Review request for 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java In-Reply-To: References: <52729901.8070604@oracle.com> Message-ID: <52729FF3.4020506@oracle.com> On 10/31/2013 11:01 AM, Martin Buchholz wrote: > + iterations++; > > Using ++ on a volatile int looks racy. Using an AtomicInteger is > strictly more reliable. > Oh that's right. Will fix that. I don't really like duplicating the code in these 2 tests and I am going to refactor it and add the shared code in the testlibrary. Will send out a revised webrev. Mandy > > On Thu, Oct 31, 2013 at 10:53 AM, Mandy Chung > wrote: > > https://bugs.openjdk.java.net/browse/JDK-8022208 > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.00/ > > > The retry loop in checking the thread state assumes that the > thread state is in RUNNABLE state which isn't always the case (it > could be any other state). The fix is to remove that check and > the thread should be a daemon thread so that the test can > terminate if any exception is thrown. > > jdk/test/java/lang/management/ThreadMXBean/ThreadStateTest.java is > a similar test that performs additional validation on the > ThreadMXBean API. It should also be fixed as a daemon thread I > take the opportunity to change it to use > java.util.concurrent.Phaser instead of the utility class. > > Mandy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131031/d20acef6/attachment.html From mandy.chung at oracle.com Thu Oct 31 12:11:40 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 31 Oct 2013 12:11:40 -0700 Subject: Review request for 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java In-Reply-To: <52729FF3.4020506@oracle.com> References: <52729901.8070604@oracle.com> <52729FF3.4020506@oracle.com> Message-ID: <5272AB6C.5030300@oracle.com> Updated webrev that has a new test/lib/testlibrary/ThreadStateController.java and also change to use AtomicInteger: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.01/ Mandy On 10/31/2013 11:22 AM, Mandy Chung wrote: > > On 10/31/2013 11:01 AM, Martin Buchholz wrote: >> + iterations++; >> >> Using ++ on a volatile int looks racy. Using an AtomicInteger is >> strictly more reliable. >> > > Oh that's right. Will fix that. I don't really like duplicating the > code in these 2 tests and I am going to refactor it and add the shared > code in the testlibrary. Will send out a revised webrev. > > Mandy > >> >> On Thu, Oct 31, 2013 at 10:53 AM, Mandy Chung > > wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8022208 >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.00/ >> >> The retry loop in checking the thread state assumes that the >> thread state is in RUNNABLE state which isn't always the case (it >> could be any other state). The fix is to remove that check and >> the thread should be a daemon thread so that the test can >> terminate if any exception is thrown. >> >> jdk/test/java/lang/management/ThreadMXBean/ThreadStateTest.java >> is a similar test that performs additional validation on the >> ThreadMXBean API. It should also be fixed as a daemon thread I >> take the opportunity to change it to use >> java.util.concurrent.Phaser instead of the utility class. >> >> Mandy >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131031/1c444f12/attachment.html From dan.xu at oracle.com Thu Oct 31 11:57:40 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Thu, 31 Oct 2013 18:57:40 +0000 Subject: hg: jdk8/tl/jdk: 8027155: test/java/io/File/NulFile.java failing when test run in othervm mode Message-ID: <20131031185812.6E5166288F@hg.openjdk.java.net> Changeset: e93de88661ab Author: dxu Date: 2013-10-31 11:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e93de88661ab 8027155: test/java/io/File/NulFile.java failing when test run in othervm mode Reviewed-by: mchung, alanb ! test/java/io/File/NulFile.java From Alan.Bateman at oracle.com Thu Oct 31 12:34:24 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 31 Oct 2013 19:34:24 +0000 Subject: Review request for 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java In-Reply-To: <5272AB6C.5030300@oracle.com> References: <52729901.8070604@oracle.com> <52729FF3.4020506@oracle.com> <5272AB6C.5030300@oracle.com> Message-ID: <5272B0C0.4070608@oracle.com> On 31/10/2013 19:11, Mandy Chung wrote: > Updated webrev that has a new > test/lib/testlibrary/ThreadStateController.java and also change to use > AtomicInteger: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.01/ > > Mandy Is ThreadStateController general enough for the unname package in /lib/testlibrary? Just wondering if it should be moved down into a package (I like using testlibrary, just wonder how it will scale if we make over-use of it). Also does the refactoring mean that methods can be removed from ThreadMXBean/Utils.java? I realize this is expanding your scope a bit and maybe changing SynchronizationStatistics (which appears to be the user other of Utils). -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131031/d4bbbc4f/attachment.html From mandy.chung at oracle.com Thu Oct 31 13:41:59 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 31 Oct 2013 13:41:59 -0700 Subject: Review request for 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java In-Reply-To: <5272B0C0.4070608@oracle.com> References: <52729901.8070604@oracle.com> <52729FF3.4020506@oracle.com> <5272AB6C.5030300@oracle.com> <5272B0C0.4070608@oracle.com> Message-ID: <5272C097.2060106@oracle.com> On 10/31/2013 12:34 PM, Alan Bateman wrote: > On 31/10/2013 19:11, Mandy Chung wrote: >> Updated webrev that has a new >> test/lib/testlibrary/ThreadStateController.java and also change to >> use AtomicInteger: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.01/ >> >> Mandy > Is ThreadStateController general enough for the unname package in > /lib/testlibrary? Just wondering if it should be moved down into a > package (I like using testlibrary, just wonder how it will scale if we > make over-use of it). > I was also wondering how testlibrary is currently structured. While ThreadStateController can be for general use, I would think that this class would be more specific for these tests and other ThreadMXBean tests to use. Having a second thought, it may be better to move it under jdk/test/java/lang/Thread/testlibrary? Any opinion? > Also does the refactoring mean that methods can be removed from > ThreadMXBean/Utils.java? I realize this is expanding your scope a bit > and maybe changing SynchronizationStatistics (which appears to be the > user other of Utils). > I looked at them and I decide to leave it as a separate task. ThreadMXBean/Utils and ThreadExecutionSynchronizer are currently used by a few other ThreadMXBean tests that are intermittent test failures (I am responsible for them :). Jarsolav has fixed several of them and he has also filed a bug to remove ThreadExecutionSynchronizer and use java.util.concurrent where appropriate. https://bugs.openjdk.java.net/browse/JDK-8024326 I may spare some time to help clean them up but no promise :) Mandy Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20131031/81bafcc5/attachment.html From huizhe.wang at oracle.com Thu Oct 31 13:53:14 2013 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Thu, 31 Oct 2013 20:53:14 +0000 Subject: hg: jdk8/tl/jdk: 8024876: [TEST_BUG] javax/xml/jaxp/parsers/8022548/XOMParserTest.java failed when testbase dir has read only permissions Message-ID: <20131031205326.E49F9628B5@hg.openjdk.java.net> Changeset: c4bbd5963f9c Author: joehw Date: 2013-10-31 13:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4bbd5963f9c 8024876: [TEST_BUG] javax/xml/jaxp/parsers/8022548/XOMParserTest.java failed when testbase dir has read only permissions Reviewed-by: chegar ! test/javax/xml/jaxp/parsers/8022548/XOMParserTest.java From coleen.phillimore at oracle.com Thu Oct 31 14:23:37 2013 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 31 Oct 2013 21:23:37 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 8027616: Off by one error in putback for compressed oops nashorn performance improvement Message-ID: <20131031212346.B75D9628B7@hg.openjdk.java.net> Changeset: c8fc12209830 Author: coleenp Date: 2013-10-31 14:11 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c8fc12209830 8027616: Off by one error in putback for compressed oops nashorn performance improvement Summary: Should compare bounds greater than or equal 4G when deciding if shift is needed or CDS area + compressed class space are within 4G of each other. Reviewed-by: stefank, hseigel, zgu ! src/share/vm/memory/metaspace.cpp From david.holmes at oracle.com Thu Oct 31 17:38:39 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Nov 2013 10:38:39 +1000 Subject: Review request for 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java In-Reply-To: <5272AB6C.5030300@oracle.com> References: <52729901.8070604@oracle.com> <52729FF3.4020506@oracle.com> <5272AB6C.5030300@oracle.com> Message-ID: <5272F80F.4070006@oracle.com> Hi Mandy, On 1/11/2013 5:11 AM, Mandy Chung wrote: > Updated webrev that has a new > test/lib/testlibrary/ThreadStateController.java and also change to use > AtomicInteger: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.01/ Sorry but I don't see how this works - and that applies to the old version too! (Which I know I've looked at before so this is somewhat unsettling for me :( ). First I found it confusing to track which thread was which in the refactoring (which in itself is a good idea). Inside ThreadStateController "myThread" doesn't mean anything - that comes from the calling context - I suggest changing to refer to "this thread" or "the current thread" as appropriate. eg "Have the current thread wait until this thread is about to block" or whatever is needed. Looking at an actual test we have eg: myThread.goWaiting(); ThreadStateController.checkThreadState(myThread, Thread.State.WAITING); First: why is checkThreadState static rather than just an instance method? So goWaiting is supposed to tell myThread to go to a "waiting" state so that the main thread can then verify that. Lets assume for arguments sake that the thread is currently RUNNABLE so it is currently looping around in run() doing the little math exercise. goWaiting does: public void goWaiting() { System.out.println("Waiting myThread to go waiting."); setState(WAITING); // wait for MyThread to get to just before wait on object. phaser.arriveAndAwaitAdvance(); } and setState does: case WAITING: case TIMED_WAITING: state = newState; synchronized (lock) { lock.notify(); } break; so as soon as we update "state" myThread is capable of changing what it is doing in run() to: case WAITING: { synchronized (lock) { // signal main thread. phaser.arrive(); System.out.println(" myThread is going to wait."); try { lock.wait(); } catch (InterruptedException e) { // ignore interrupted.incrementAndGet(); } } break; so now we have a race between the two threads to see who can grab the lock first. If it is the main thread then we issue a notify when nothing is waiting and so the subsequent wait() by myThread will potentially wait forever. At least in that case the main thread will see that it is waiting! If "myThread" wins the race it will wait after signalling the phaser and the main thread will then issue the notify allowing myThread to proceed (and do what? process the WAITING case again??). So there is no guarantee that myThread will be waiting when the main thread checks the state! Similarly for issuing the unpark in the parking cases. AFAICS the basic approach here should be: - tell myThread to go to state X - wait until myThread should be in state X - verify myThread is in state X - allow myThread to escape from state X but this code does the last step second. ??? David ----- > Mandy > > On 10/31/2013 11:22 AM, Mandy Chung wrote: >> >> On 10/31/2013 11:01 AM, Martin Buchholz wrote: >>> + iterations++; >>> >>> Using ++ on a volatile int looks racy. Using an AtomicInteger is >>> strictly more reliable. >>> >> >> Oh that's right. Will fix that. I don't really like duplicating the >> code in these 2 tests and I am going to refactor it and add the shared >> code in the testlibrary. Will send out a revised webrev. >> >> Mandy >> >>> >>> On Thu, Oct 31, 2013 at 10:53 AM, Mandy Chung >> > wrote: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8022208 >>> >>> Webrev at: >>> >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.00/ >>> >>> >>> The retry loop in checking the thread state assumes that the >>> thread state is in RUNNABLE state which isn't always the case (it >>> could be any other state). The fix is to remove that check and >>> the thread should be a daemon thread so that the test can >>> terminate if any exception is thrown. >>> >>> jdk/test/java/lang/management/ThreadMXBean/ThreadStateTest.java >>> is a similar test that performs additional validation on the >>> ThreadMXBean API. It should also be fixed as a daemon thread I >>> take the opportunity to change it to use >>> java.util.concurrent.Phaser instead of the utility class. >>> >>> Mandy >>> >>> >> > From mandy.chung at oracle.com Thu Oct 31 20:32:06 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 31 Oct 2013 20:32:06 -0700 Subject: Review request for 8022208: Intermittent test failures in java/lang/Thread/ThreadStateTest.java In-Reply-To: <5272F80F.4070006@oracle.com> References: <52729901.8070604@oracle.com> <52729FF3.4020506@oracle.com> <5272AB6C.5030300@oracle.com> <5272F80F.4070006@oracle.com> Message-ID: <527320B6.50008@oracle.com> On 10/31/2013 5:38 PM, David Holmes wrote: > Hi Mandy, > > On 1/11/2013 5:11 AM, Mandy Chung wrote: >> Updated webrev that has a new >> test/lib/testlibrary/ThreadStateController.java and also change to use >> AtomicInteger: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8022208/webrev.01/ > > Sorry but I don't see how this works - and that applies to the old > version too! (Which I know I've looked at before so this is somewhat > unsettling for me :( ). > > First I found it confusing to track which thread was which in the > refactoring (which in itself is a good idea). Inside > ThreadStateController "myThread" doesn't mean anything - that comes > from the calling context - I suggest changing to refer to "this > thread" or "the current thread" as appropriate. eg "Have the current > thread wait until this thread is about to block" or whatever is needed. > I wasn't happy with "myThread" too and should rename it. > Looking at an actual test we have eg: > > myThread.goWaiting(); > ThreadStateController.checkThreadState(myThread, Thread.State.WAITING); > > First: why is checkThreadState static rather than just an instance > method? > Yes it can. > So goWaiting is supposed to tell myThread to go to a "waiting" state > so that the main thread can then verify that. Lets assume for > arguments sake that the thread is currently RUNNABLE so it is > currently looping around in run() doing the little math exercise. > goWaiting does: > > public void goWaiting() { > System.out.println("Waiting myThread to go waiting."); > setState(WAITING); > // wait for MyThread to get to just before wait on object. > phaser.arriveAndAwaitAdvance(); > } > > and setState does: > > case WAITING: > case TIMED_WAITING: > state = newState; > synchronized (lock) { > lock.notify(); > } > break; > > > so as soon as we update "state" myThread is capable of changing what > it is doing in run() to: > > case WAITING: { > synchronized (lock) { > // signal main thread. > phaser.arrive(); > System.out.println(" myThread is going to wait."); > try { > lock.wait(); > } catch (InterruptedException e) { > // ignore > interrupted.incrementAndGet(); > } > } > break; > > so now we have a race between the two threads to see who can grab the > lock first. If it is the main thread then we issue a notify when > nothing is waiting and so the subsequent wait() by myThread will > potentially wait forever. At least in that case the main thread will > see that it is waiting! > > If "myThread" wins the race it will wait after signalling the phaser > and the main thread will then issue the notify allowing myThread to > proceed (and do what? process the WAITING case again??). So there is > no guarantee that myThread will be waiting when the main thread checks > the state! > > Similarly for issuing the unpark in the parking cases. > > AFAICS the basic approach here should be: > - tell myThread to go to state X > - wait until myThread should be in state X > - verify myThread is in state X > - allow myThread to escape from state X > > but this code does the last step second. > > ??? > I was looking at the intermittent failures and fix the problem I identified. What you said above is definitely potential race that I didn't have analyzed the waiting state thoroughly. It's time to revisit the whole test and see if there is a better way to code this. thanks for the review. Mandy