From markus.gronlund at oracle.com Fri Feb 1 00:20:43 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Fri, 1 Feb 2013 00:20:43 -0800 (PST) Subject: RFR(XXS): 8007312: Signal Dispatcher thread to start and register ctrl-break handler before TRACE_INITIALIZE In-Reply-To: <510B48A6.7060500@oracle.com> References: <092ccf0f-36a6-4e5b-aa73-e06bff290585@default> <510B48A6.7060500@oracle.com> Message-ID: <9fa18ccc-b229-47c0-b7e6-5b988903c1b6@default> Hi David, Many thanks for your input. I do acknowledge the startup sequence is fragile, and this is quite tricky business - you raise good points. >From what I can read/test/trace, we are ready to start up the Signal Dispatcher Java thread at an earlier point (technically from a VM perspective), but as you say, this is mainly based on the best (worst?) theoretical case (and a bit of hands on a few different platforms) - in addition, if we take into account what expectations current testing has in this area (which I am unsure of at this point), there is now a change introduced between JVMTI_EVENT_VM_START and JVMTI_EVENT_JVMTI_PHASE_LIVE - and who knows what kind of test issues this might be causing...could be found out, but with a lot of effort... I see that the only OS:s where the correct behavior is actually checked are Solaris and Windows (asserts). I think we need the first stage TRACE_INITIALIZE before set_init_completed() and JVMTI_EVENT_JVMTI_PHASE_LIVE (don't remember the actual rationale off the top of my head), but I can verify if it can move later... Since this is a very hard area to get right, as you say, there will always be window where this is always an issue...I was considering a more pragmatic means just to resolve this particular issue in a somewhat timely manner (even though it's not my preferred choice): If we lax up (remove) the asserts os::signal_notify() on the return from semaphore signaling (sema_post() solaris and ReleaseSemaphore() windows), this should cease being an issue (we then get the same behavior as PRODUCT builds for non-product builds (do nothing)). ( btw it's not an error to close a NULL handle on Windows, but if you do it in debug mode you get told about it). I never like removing asserts however, but this seems like a feasible (time/effort/risk) resolution to this problem. Appreciate your comments as always, let me know what you think of this. Cheers Markus -----Original Message----- From: David Holmes Sent: den 1 februari 2013 05:47 To: Markus Gr?nlund Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR(XXS): 8007312: Signal Dispatcher thread to start and register ctrl-break handler before TRACE_INITIALIZE Hi Markus, I understand that there is a bug if ctrl-C is pressed before we have initalized the signal handler. I also realize that normally the chance of hitting that window is negligible, but with TRACE_INITIALIZE active the window becomes much larger. But as I wrote in the bug report the VM initialization sequence is very fragile and changes to it have to be made with great care. Basic tests only test the normal startup path. Problems arise where we use specific VM flags (eg tracing) with specific VM services (specific GC) and even a specific VM (fastdebug). In this case I can't convince myself it is safe for the ctrl-C handler to be setup at this earlier point in time. We are still in the initialization phase of the VM and the handler code has to make Java calls to create and start a Java signal handling thread. Are we ready to execute that Java code at this point in time - before set_init_completed()? What might go wrong? What if the Java code hits an exception? Can you test your fix by adding a sleep after os::signal_init and sending ctrl-C? Can you emulate this problem on Linux/Solaris by adding a sleep before the original os::signal_init() ? Does it crash there too, or is this a problem limited to Windows? If so the fix should be limited to Windows. Can you consider moving TRACE_INITIALIZE instead? Thanks, David On 1/02/2013 7:22 AM, Markus Gr?nlund wrote: > Greetings, > > > > Can I kindly ask for a few reviews and a putback sponsorship for the following change: > > > > Bugid: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007312 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8007312/webrev01/ > > Hotspot JPRT builds/tests : completed successfully > > > > Comment on issue/fix: > > > > (windows analysis) > > > > Pressing ctrl-c before Hotspot signal/console handler has been registered actually asserts/stops the VM (which to the user appears like a crash) on non-product builds. > > > > Before Hotspot registers its own jvm!consoleHandler with kernel32!CtrlRoutine, the C runtime default msvcr100!ctrlevent_capture is implicitly used - this calls back into jvm!UserHandler, which forwards into os::signal_notify() which uses uninitialized variables. > > > > // on Windows this creates the following issue when closing a NULL > handle to a semaphore > > > > void os::signal_notify(int signal_number) { > > BOOL ret; > > > > Atomic::inc(&pending_signals[signal_number]); > > ret = ::ReleaseSemaphore(sig_sem, 1, NULL);<<--- call > ReleaseSemaphore on global handle sig_sem which has not been > setup/created yet == is NULL (is created in os::signal_init_pd()) > > assert(ret != 0, "ReleaseSemaphore() failed");<<-- assert traps > here (GetLastError() == 0xc0000008 - An invalid HANDLE was specified) > > > > } > > > > The short initial tests I have done locally so far on moving the signal handler registration earlier as suggested in this patch makes it very hard to issue crtl-c before Hotspot signal handler has been setup. > > > > Thanks > > Markus From john.coomes at oracle.com Fri Feb 1 01:32:09 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Feb 2013 09:32:09 +0000 Subject: hg: hsx/hotspot-main: 54 new changesets Message-ID: <20130201093212.29BF94773D@hg.openjdk.java.net> Changeset: c37401e77c80 Author: mchung Date: 2012-12-28 22:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/c37401e77c80 8003562: Provide a CLI tool to analyze class dependencies Reviewed-by: jjg, alanb, ulfzibis, erikj ! common/bin/compare_exceptions.sh.incl Changeset: b845a2494261 Author: lana Date: 2013-01-01 12:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/b845a2494261 Merge Changeset: 93b9664f97ee Author: lana Date: 2013-01-10 15:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/93b9664f97ee Merge Changeset: 4090847a5444 Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/4090847a5444 Added tag jdk8-b73 for changeset 93b9664f97ee ! .hgtags Changeset: 77f062a41850 Author: erikj Date: 2012-12-27 20:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/77f062a41850 8001942: build-infra: General permission problems on Windows/cygwin Summary: Added sanity check for file permissions in configure Reviewed-by: tbell, ohair ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: d2c1f80118de Author: erikj Date: 2012-12-27 20:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/d2c1f80118de 8005540: build-infra: Improve incremental build speed on windows by caching find results Reviewed-by: ohair ! common/makefiles/IdlCompilation.gmk ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/NativeCompilation.gmk Changeset: d5f3a6f60d51 Author: erikj Date: 2012-12-27 20:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/d5f3a6f60d51 8005548: build-infra: Fix docs target on windows Summary: Fix path sep variable Reviewed-by: tbell ! common/makefiles/javadoc/Javadoc.gmk Changeset: ef6adbf511cc Author: erikj Date: 2012-12-28 09:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ef6adbf511cc 8005549: build-infra: Merge NewMakefile.gmk and common/makefiles/Makefile Reviewed-by: ohair, tbell ! NewMakefile.gmk ! common/autoconf/Makefile.in ! common/autoconf/generated-configure.sh + common/makefiles/Jprt.gmk ! common/makefiles/Main.gmk ! common/makefiles/MakeHelpers.gmk ! common/makefiles/Makefile Changeset: 2d9bb72b4e34 Author: erikj Date: 2012-12-30 12:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/2d9bb72b4e34 8004490: build-infra: mac: hotspot is always built in product, regardless of --with-debug-level setting Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: abc8078e070b Author: erikj Date: 2013-01-01 14:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/abc8078e070b 8001895: build-infra: Make JDK_BUILD_NUMBER and MILESTONE customizable Summary: Added configure params Reviewed-by: ohair ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/version.numbers Changeset: 14d7ebe42c8d Author: erikj Date: 2013-01-02 11:29 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/14d7ebe42c8d 8005347: build-infra: Verify 'gnumake source' at the top level works ok Reviewed-by: tbell, ohair, dholmes ! common/autoconf/basics.m4 - common/autoconf/closed.version.numbers ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in = common/autoconf/version-numbers < common/autoconf/version.numbers Changeset: 348a881c6da0 Author: erikj Date: 2013-01-02 15:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/348a881c6da0 8005355: build-infra: Java security signing (need a top-level make target). Reviewed-by: tbell, ohair ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: befbad2e4d87 Author: erikj Date: 2013-01-03 20:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/befbad2e4d87 8005635: build-infra: Support building install in jprt Reviewed-by: ohair Contributed-by: tim.bell at oracle.com, erik.joelsson at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/bin/compare.sh ! common/bin/compare_exceptions.sh.incl ! common/makefiles/Jprt.gmk ! common/src/fixpath.c Changeset: 39194e004ade Author: erikj Date: 2013-01-04 11:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/39194e004ade 8005575: build-infra: Three JCK tests fails on Solaris with new RE Autoconf-Based build Reviewed-by: ohair ! common/autoconf/compare.sh.in ! common/bin/compare.sh Changeset: 9263657c2756 Author: erikj Date: 2013-01-04 16:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/9263657c2756 8005692: build-infra: Target "all" should do the right thing Reviewed-by: tbell ! common/makefiles/Main.gmk Changeset: c874a8a27933 Author: erikj Date: 2013-01-04 17:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/c874a8a27933 8005597: build-infra: bridgeBuild broken for pure openjdk build Reviewed-by: tbell ! common/makefiles/Jprt.gmk Changeset: 7b9c42f14281 Author: erikj Date: 2013-01-04 17:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/7b9c42f14281 8005654: build-infra: Create sec-bin.zip Reviewed-by: tbell ! common/bin/compare.sh ! common/makefiles/JavaCompilation.gmk Changeset: 2597feac57c0 Author: erikj Date: 2013-01-04 22:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/2597feac57c0 8005723: build-infra: in new infra build, sec-windows-bin-zip and jgss-windows-*-bin.zip are missing Reviewed-by: tbell ! common/bin/compare.sh ! common/bin/compare_exceptions.sh.incl Changeset: 5cf7750c8c43 Author: ohair Date: 2013-01-04 21:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/5cf7750c8c43 8004229: build-infra: Umbrella for switch of default "make" to new makefiles Reviewed-by: erikj, tbell ! Makefile ! make/jprt.properties Changeset: 7a3c6ffdf1fb Author: tbell Date: 2013-01-07 14:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/7a3c6ffdf1fb 8005442: autogen.sh sets DATE_WHEN_GENERATED to empty string on Solaris version 11 or later Reviewed-by: ohair ! common/autoconf/autogen.sh Changeset: 64a9ebad39fe Author: katleman Date: 2013-01-08 13:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/64a9ebad39fe Merge - common/autoconf/closed.version.numbers - common/autoconf/version.numbers Changeset: b284980b7d9a Author: tbell Date: 2013-01-08 16:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/b284980b7d9a 8005794: in new infra, how do we change java -version? Summary: Added configure parameter --with-user-release-suffix Reviewed-by: ohair, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: db3984e4eb97 Author: erikj Date: 2013-01-10 12:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/db3984e4eb97 8005858: build-infra: Add missed comparison of sec-windows-bin.zip and friends to compare.sh Reviewed-by: tbell, ohair ! common/bin/compare.sh Changeset: 6f8f7a5449f6 Author: erikj Date: 2013-01-11 10:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/6f8f7a5449f6 8005850: build-infra: Make --enable-openjdk-only really disable custom Reviewed-by: ohair, dholmes ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: b66c81dfa291 Author: ohair Date: 2013-01-14 16:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/b66c81dfa291 8005284: build-infra: nonstandard copyright headers under common/autoconf/build-aux Reviewed-by: katleman ! common/autoconf/build-aux/autoconf-config.guess ! common/autoconf/build-aux/config.sub ! common/autoconf/build-aux/pkg.m4 Changeset: 3540aa40c868 Author: erikj Date: 2013-01-14 13:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/3540aa40c868 8006074: build-infra: Configure fails to find SetEnv.Cmd in microsoft sdk Reviewed-by: tbell, ohair ! common/autoconf/basics_windows.m4 ! common/autoconf/generated-configure.sh Changeset: 6e822b534678 Author: erikj Date: 2013-01-14 15:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/6e822b534678 8006100: build-infra: Bundle up the correct images in jprt Reviewed-by: tbell ! NewMakefile.gmk ! common/makefiles/Jprt.gmk Changeset: 52cce3326649 Author: erikj Date: 2013-01-15 09:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/52cce3326649 Merge Changeset: fe1c94aca5a8 Author: katleman Date: 2013-01-15 10:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/fe1c94aca5a8 Merge - common/autoconf/closed.version.numbers - common/autoconf/version.numbers Changeset: dc84b505b408 Author: katleman Date: 2013-01-16 22:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/dc84b505b408 Merge - common/autoconf/closed.version.numbers - common/autoconf/version.numbers ! common/bin/compare_exceptions.sh.incl Changeset: 50307da0149e Author: jqzuo Date: 2012-12-31 14:52 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/50307da0149e 8005583: Install build(gnumake all) failed preventing RE from doing JDK8 combo builds Reviewed-by: paulk, billyh ! make/install-rules.gmk Changeset: e5664599a127 Author: cgruszka Date: 2013-01-02 14:54 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/e5664599a127 Merge Changeset: 75634cbeab47 Author: cgruszka Date: 2013-01-04 13:11 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/75634cbeab47 Merge Changeset: 61d7e2971723 Author: cgruszka Date: 2013-01-14 14:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/61d7e2971723 Merge Changeset: f9163f9cb1da Author: cgruszka Date: 2013-01-23 08:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/f9163f9cb1da Merge Changeset: 5a5e97f9ac0a Author: erikj Date: 2013-01-18 09:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/5a5e97f9ac0a 8006520: build-infra: Fix sparkle-framework configure parameter Reviewed-by: tbell, ohair ! common/autoconf/generated-configure.sh ! common/makefiles/Jprt.gmk Changeset: edad83acbd46 Author: erikj Date: 2013-01-18 16:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/edad83acbd46 8003693: build-infra: bridgeBuild should allow for partial build (no hotspot) Reviewed-by: tbell ! common/makefiles/Jprt.gmk Changeset: c3bf62746a80 Author: tbell Date: 2013-01-23 13:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/c3bf62746a80 8006797: build-infra JPRT builds need JPRT_ARCHIVE_INSTALL_BUNDLE in common/makefiles/Jprt.gmk Reviewed-by: ohair ! common/makefiles/Jprt.gmk Changeset: b43aa5bd8ca5 Author: katleman Date: 2013-01-23 15:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/b43aa5bd8ca5 Merge Changeset: cd2fa0d0ed3d Author: katleman Date: 2013-01-24 16:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/cd2fa0d0ed3d Added tag jdk8-b74 for changeset b43aa5bd8ca5 ! .hgtags Changeset: 1129fb75f611 Author: jjg Date: 2013-01-10 19:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/1129fb75f611 8004834: Add doclint support into javadoc Reviewed-by: erikj, tbell ! common/makefiles/javadoc/Javadoc.gmk Changeset: cecfba251e4a Author: lana Date: 2013-01-16 11:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/cecfba251e4a Merge Changeset: 2e12a508d7ae Author: lana Date: 2013-01-20 23:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/2e12a508d7ae Merge - common/autoconf/closed.version.numbers - common/autoconf/version.numbers ! common/makefiles/javadoc/Javadoc.gmk Changeset: 8209c91b751d Author: sherman Date: 2013-01-22 21:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/8209c91b751d 8003680: JSR 310 Date/Time API Summary: Integration of JSR310 Date/Time API for M6 Reviewed-by: alanb, naoto, dholmes Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, richard.warburton at gmail.com, misterm at gmail.com ! common/makefiles/javadoc/CORE_PKGS.gmk ! make/jprt.properties ! test/Makefile Changeset: 039783b67959 Author: lana Date: 2013-01-26 18:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/039783b67959 Merge Changeset: e28985c549aa Author: raginip Date: 2013-01-18 11:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/e28985c549aa 8000839: Integrate the Java Access Bridge with Java Runtime Reviewed-by: ptbrunet, erikj ! common/bin/compare_exceptions.sh.incl Changeset: db46b1c27a93 Author: erikj Date: 2013-01-28 14:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/db46b1c27a93 Merge - common/autoconf/closed.version.numbers ! common/autoconf/generated-configure.sh - common/autoconf/version.numbers ! common/bin/compare_exceptions.sh.incl Changeset: 8baaaba2ee6b Author: lana Date: 2013-01-29 20:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/8baaaba2ee6b Merge Changeset: 0d4b0a13adb2 Author: erikj Date: 2013-01-23 11:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/0d4b0a13adb2 8005855: build-infra: Remove -R flag when cross compiling Reviewed-by: dholmes, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: ea6379d4624f Author: erikj Date: 2013-01-23 11:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ea6379d4624f 8006663: build-infra: Compare two arbitrary zip/jar files with compare.sh Reviewed-by: tbell ! common/bin/compare.sh Changeset: 0d46733cfffb Author: erikj Date: 2013-01-23 11:42 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/0d46733cfffb 8006658: build-infra: Make MILESTONE behave the same as JDK_BUILD_NUMBER Reviewed-by: ohrstrom, dholmes, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: 9e5847257731 Author: erikj Date: 2013-01-24 09:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/9e5847257731 Merge Changeset: 2a713921952c Author: katleman Date: 2013-01-30 13:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/2a713921952c Merge ! common/autoconf/generated-configure.sh Changeset: 5b19cef637a6 Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/5b19cef637a6 Added tag jdk8-b75 for changeset 2a713921952c ! .hgtags From john.coomes at oracle.com Fri Feb 1 01:32:31 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Feb 2013 09:32:31 +0000 Subject: hg: hsx/hotspot-main/jaxp: 11 new changesets Message-ID: <20130201093305.A34B74773F@hg.openjdk.java.net> Changeset: cf0917c0d771 Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/cf0917c0d771 Added tag jdk8-b73 for changeset 84946404d1e1 ! .hgtags Changeset: 278a2f60c55b Author: erikj Date: 2013-01-04 11:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/278a2f60c55b 8005575: build-infra: Three JCK tests fails on Solaris with new RE Autoconf-Based build Reviewed-by: ohair ! makefiles/BuildJaxp.gmk Changeset: 2e4d87e6662e Author: katleman Date: 2013-01-08 13:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/2e4d87e6662e Merge Changeset: a317d3e1bbac Author: katleman Date: 2013-01-15 10:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/a317d3e1bbac Merge Changeset: 2087e24a4357 Author: katleman Date: 2013-01-16 22:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/2087e24a4357 Merge Changeset: 69bc57b1ebdd Author: katleman Date: 2013-01-24 16:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/69bc57b1ebdd Added tag jdk8-b74 for changeset 2087e24a4357 ! .hgtags Changeset: 47738fa4d411 Author: dbuck Date: 2013-01-10 20:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/47738fa4d411 8003147: port fix for BCEL bug 39695 Summary: Added support for Local Variable Type Table so that BCEL library can be used to modify methods with generics-related debug data without violating class file format Reviewed-by: lancea ! src/com/sun/org/apache/bcel/internal/Constants.java ! src/com/sun/org/apache/bcel/internal/classfile/Attribute.java ! src/com/sun/org/apache/bcel/internal/classfile/DescendingVisitor.java ! src/com/sun/org/apache/bcel/internal/classfile/EmptyVisitor.java + src/com/sun/org/apache/bcel/internal/classfile/LocalVariableTypeTable.java ! src/com/sun/org/apache/bcel/internal/classfile/Visitor.java ! src/com/sun/org/apache/bcel/internal/generic/MethodGen.java Changeset: 06827097cdd3 Author: lana Date: 2013-01-16 12:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/06827097cdd3 Merge Changeset: 4e049aa2495f Author: lana Date: 2013-01-20 23:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/4e049aa2495f Merge Changeset: ff0b73a6b3f6 Author: lana Date: 2013-01-26 18:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/ff0b73a6b3f6 Merge Changeset: 8d65b381880b Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/8d65b381880b Added tag jdk8-b75 for changeset ff0b73a6b3f6 ! .hgtags From john.coomes at oracle.com Fri Feb 1 01:32:18 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Feb 2013 09:32:18 +0000 Subject: hg: hsx/hotspot-main/corba: 3 new changesets Message-ID: <20130201093223.47F594773E@hg.openjdk.java.net> Changeset: 2132845cf5f7 Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/2132845cf5f7 Added tag jdk8-b73 for changeset 191afde59e7b ! .hgtags Changeset: d4e68ce17795 Author: katleman Date: 2013-01-24 16:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/d4e68ce17795 Added tag jdk8-b74 for changeset 2132845cf5f7 ! .hgtags Changeset: 4a6be02e66a3 Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/4a6be02e66a3 Added tag jdk8-b75 for changeset d4e68ce17795 ! .hgtags From john.coomes at oracle.com Fri Feb 1 01:33:09 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Feb 2013 09:33:09 +0000 Subject: hg: hsx/hotspot-main/jaxws: 7 new changesets Message-ID: <20130201093327.DBD9647740@hg.openjdk.java.net> Changeset: 68f508979ffe Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/68f508979ffe Added tag jdk8-b73 for changeset c606f644a5d9 ! .hgtags Changeset: 51f3117e2b75 Author: erikj Date: 2013-01-04 11:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/51f3117e2b75 8005575: build-infra: Three JCK tests fails on Solaris with new RE Autoconf-Based build Reviewed-by: ohair ! makefiles/BuildJaxws.gmk Changeset: dd7473082690 Author: katleman Date: 2013-01-08 13:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/dd7473082690 Merge Changeset: b8fd32e44c26 Author: katleman Date: 2013-01-15 10:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/b8fd32e44c26 Merge Changeset: 12db3c5a3393 Author: katleman Date: 2013-01-16 22:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/12db3c5a3393 Merge Changeset: 966bf9f3c41a Author: katleman Date: 2013-01-24 16:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/966bf9f3c41a Added tag jdk8-b74 for changeset 12db3c5a3393 ! .hgtags Changeset: a63ef2391c20 Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/a63ef2391c20 Added tag jdk8-b75 for changeset 966bf9f3c41a ! .hgtags From john.coomes at oracle.com Fri Feb 1 01:37:17 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Feb 2013 09:37:17 +0000 Subject: hg: hsx/hotspot-main/jdk: 147 new changesets Message-ID: <20130201100832.0F38F47741@hg.openjdk.java.net> Changeset: d54922883f4c Author: alexsch Date: 2013-01-09 16:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d54922883f4c 8005019: JTable passes row index instead of length when inserts selection interval Reviewed-by: serb, denis ! src/share/classes/javax/swing/JTable.java + test/javax/swing/JTable/8005019/bug8005019.java Changeset: b2c425d7e5be Author: lana Date: 2013-01-10 15:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b2c425d7e5be Merge Changeset: 28b47ed08c63 Author: mchung Date: 2012-12-28 22:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/28b47ed08c63 8003562: Provide a CLI tool to analyze class dependencies Reviewed-by: jjg, alanb, ulfzibis, erikj ! make/common/Release.gmk ! make/docs/NON_CORE_PKGS.gmk ! make/launchers/Makefile ! make/launchers/Makefile.launcher ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk ! makefiles/Images.gmk Changeset: 3cc25d0e3bb0 Author: chegar Date: 2012-12-29 11:00 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3cc25d0e3bb0 8005556: java/net/Socks/SocksV4Test.java is missing @run tag Reviewed-by: alanb ! test/java/net/Socks/SocksV4Test.java Changeset: 38b9a7646093 Author: lana Date: 2013-01-01 17:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/38b9a7646093 Merge ! makefiles/CreateJars.gmk Changeset: cc78ceb99284 Author: jgish Date: 2012-12-28 16:56 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cc78ceb99284 8005118: Javadoc styles are inconsistent Summary: use a common javadoc style in the String classes Reviewed-by: darcy ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/StringBuffer.java ! src/share/classes/java/lang/StringBuilder.java ! src/share/classes/java/lang/StringIndexOutOfBoundsException.java Changeset: 21708d15553b Author: chegar Date: 2013-01-03 10:00 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/21708d15553b 8005634: tools/launcher/VersionCheck.java fails version check on jdeps Summary: add jdeps to the list of tools that do not support '-version' Reviewed-by: mchung ! test/tools/launcher/VersionCheck.java Changeset: 438d37d16417 Author: chegar Date: 2013-01-04 11:18 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/438d37d16417 8005659: Add tools/pack200/AttributeTests.java to exclude list (ProblemList.txt) until pack200 updated to support method parameters Reviewed-by: mchung, ksrini ! test/ProblemList.txt Changeset: 6d814b2f9112 Author: chegar Date: 2013-01-04 11:34 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6d814b2f9112 8005638: Less secure Authentication schemes should work when more secure schemes are not available Reviewed-by: alanb ! src/share/classes/sun/net/www/protocol/http/AuthenticationHeader.java Changeset: 92c3b24a8e9a Author: smarks Date: 2013-01-04 16:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/92c3b24a8e9a 8005683: ProblemList.txt updates (01/2013) Reviewed-by: mchung, alanb Contributed-by: amy.lu at oracle.com ! test/ProblemList.txt Changeset: 0c89465b656a Author: chegar Date: 2013-01-05 17:06 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0c89465b656a 8005709: Add at since tags to new FJP getCommonPoolParallelism and commonPool Reviewed-by: dl ! src/share/classes/java/util/concurrent/ForkJoinPool.java Changeset: 1d9638ba5202 Author: ksrini Date: 2013-01-07 09:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1d9638ba5202 8004547: Extend JavaFX launcher support to allow full JavaFX launch feature set Reviewed-by: mchung, kcr, ksrini Contributed-by: david.dehaven at oracle.com ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! test/tools/launcher/FXLauncherTest.java Changeset: dbc692ea3f0a Author: bchristi Date: 2013-01-07 13:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dbc692ea3f0a 8003228: (props) sun.jnu.encoding should be set to UTF-8 [macosx] Summary: Hard-code sun.jnu.encoding to UTF-8 on Mac Reviewed-by: naoto ! src/share/native/java/lang/System.c ! src/solaris/native/java/lang/java_props_md.c + test/java/util/Properties/MacJNUEncoding/ExpectedEncoding.java + test/java/util/Properties/MacJNUEncoding/MacJNUEncoding.sh Changeset: 797e8a3dcd51 Author: smarks Date: 2013-01-07 18:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/797e8a3dcd51 7187882: TEST_BUG: java/rmi/activation/checkusage/CheckUsage.java fails intermittently Summary: Tighten up JavaVM test library API, and adjust tests to match. Reviewed-by: mchung, dmocek ! test/ProblemList.txt ! test/java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java ! test/java/rmi/activation/checkusage/CheckUsage.java ! test/java/rmi/registry/altSecurityManager/AltSecurityManager.java ! test/java/rmi/registry/checkusage/CheckUsage.java ! test/java/rmi/registry/reexport/Reexport.java ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/testlibrary/RMID.java ! test/java/rmi/transport/checkFQDN/CheckFQDN.java ! test/java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java ! test/sun/rmi/runtime/Log/4504153/Test4504153.java ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java ! test/sun/rmi/transport/tcp/DeadCachedConnection.java Changeset: 98935c514de4 Author: weijun Date: 2013-01-08 14:54 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/98935c514de4 8005447: default principal should act as anyone Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/InitSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java + src/share/classes/sun/security/jgss/krb5/ServiceCreds.java ! src/share/classes/sun/security/jgss/krb5/SubjectComber.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java + test/sun/security/krb5/ServiceCredsCombination.java + test/sun/security/krb5/auto/AcceptPermissions.java ! test/sun/security/krb5/auto/CleanState.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/DiffNameSameKey.java ! test/sun/security/krb5/auto/DynamicKeytab.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/KeyTabCompat.java + test/sun/security/krb5/auto/TwoOrThree.java Changeset: d29a7ce28189 Author: dxu Date: 2013-01-08 20:37 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d29a7ce28189 8002306: (se) Selector.open fails if invoked with thread interrupt status set [win] Reviewed-by: alanb ! src/windows/classes/sun/nio/ch/PipeImpl.java + test/java/nio/channels/Pipe/PipeInterrupt.java Changeset: 46e6a4b7ca26 Author: valeriep Date: 2013-01-07 11:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/46e6a4b7ca26 6996769: support AEAD cipher Summary: Added implementation for GCM mode under AES cipher Reviewed-by: weijun ! src/share/classes/com/sun/crypto/provider/AESCipher.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/CipherTextStealing.java ! src/share/classes/com/sun/crypto/provider/FeedbackCipher.java + src/share/classes/com/sun/crypto/provider/GCMParameters.java + src/share/classes/com/sun/crypto/provider/GCTR.java + src/share/classes/com/sun/crypto/provider/GHASH.java + src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/spec/GCMParameterSpec.java ! test/com/sun/crypto/provider/Cipher/AES/Test4512524.java ! test/com/sun/crypto/provider/Cipher/AES/Test4512704.java ! test/com/sun/crypto/provider/Cipher/AES/Test4517355.java ! test/com/sun/crypto/provider/Cipher/AES/Test4626070.java + test/com/sun/crypto/provider/Cipher/AES/TestGCMKeyAndIvCheck.java + test/com/sun/crypto/provider/Cipher/AES/TestKATForGCM.java ! test/javax/crypto/Cipher/GCMAPI.java Changeset: 5333a4c8cade Author: valeriep Date: 2013-01-07 14:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5333a4c8cade Merge Changeset: 3c5a62290939 Author: valeriep Date: 2013-01-08 11:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3c5a62290939 8004044: Lazily instantiate SunJCE.RANDOM Summary: Replace the static initialization of SunJCE.RANDOM object w/ lazy initialization Reviewed-by: mchung ! src/share/classes/com/sun/crypto/provider/AESKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/BlowfishKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/DESKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESedeKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java ! src/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java ! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java ! src/share/classes/com/sun/crypto/provider/HmacMD5KeyGenerator.java ! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java ! src/share/classes/com/sun/crypto/provider/HmacSHA1KeyGenerator.java ! src/share/classes/com/sun/crypto/provider/ISO10126Padding.java ! src/share/classes/com/sun/crypto/provider/KeyGeneratorCore.java ! src/share/classes/com/sun/crypto/provider/KeyProtector.java ! src/share/classes/com/sun/crypto/provider/PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/PBES1Core.java ! src/share/classes/com/sun/crypto/provider/PBES2Core.java ! src/share/classes/com/sun/crypto/provider/PBMAC1Core.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java Changeset: 9b6a29cb04ac Author: valeriep Date: 2013-01-08 13:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9b6a29cb04ac Merge Changeset: ac5fd681a7a2 Author: darcy Date: 2013-01-08 16:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ac5fd681a7a2 8005298: Add FunctionalInterface type to the core libraries Reviewed-by: mduigou + src/share/classes/java/lang/FunctionalInterface.java Changeset: 86828e84654f Author: mullan Date: 2013-01-08 19:00 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/86828e84654f 7019834: Eliminate dependency from PolicyFile to com.sun.security.auth.PrincipalComparator Summary: Add new java.security.Principal.implies method Reviewed-by: alanb ! src/share/classes/java/security/Principal.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/provider/PolicyParser.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java + test/java/security/Principal/Implies.java ! test/sun/security/provider/PolicyFile/Comparator.java Changeset: bf6d0bca5ea7 Author: mullan Date: 2013-01-08 19:02 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bf6d0bca5ea7 Merge - make/jdk/asm/Makefile - src/share/classes/sun/awt/TextureSizeConstraining.java - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: f0ed9ef84637 Author: mullan Date: 2013-01-09 08:59 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f0ed9ef84637 Merge Changeset: 4c8b37f159f9 Author: mchung Date: 2013-01-09 16:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4c8b37f159f9 7103957: NegativeArraySizeException while initializing class IntegerCache Reviewed-by: darcy, mchung Contributed-by: brian.burkhalter at oracle.com ! src/share/classes/java/lang/Integer.java Changeset: 4176e6cc499e Author: darcy Date: 2013-01-09 20:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4176e6cc499e 8005713: Simplify library support for repeating annotations in java.lang.annotation Reviewed-by: abuckley + src/share/classes/java/lang/annotation/Repeatable.java Changeset: c622df692bfb Author: bchristi Date: 2013-01-10 10:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c622df692bfb 8005962: TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments Summary: Test script now sets LC_ALL, other small changes, relocate test Reviewed-by: naoto, alanb + test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java + test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh - test/java/util/Properties/MacJNUEncoding/ExpectedEncoding.java - test/java/util/Properties/MacJNUEncoding/MacJNUEncoding.sh Changeset: 13ff1089e625 Author: jgish Date: 2013-01-10 15:09 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/13ff1089e625 8005582: java/lang/Runtime/exec/WinCommand.java intermittent test failures Summary: Remove file-deletion code at cleanup which conflicts with jtreg cleanup Reviewed-by: chegar ! test/java/lang/Runtime/exec/WinCommand.java Changeset: 3e906ccad412 Author: chegar Date: 2013-01-10 21:52 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3e906ccad412 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898 Reviewed-by: dl, shade ! src/share/classes/java/util/concurrent/atomic/AtomicBoolean.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java Changeset: 733885f57e14 Author: lana Date: 2013-01-10 15:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/733885f57e14 Merge Changeset: 965e89e2abd3 Author: katleman Date: 2013-01-16 12:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/965e89e2abd3 Added tag jdk8-b73 for changeset 733885f57e14 ! .hgtags Changeset: e91caf05f441 Author: erikj Date: 2012-12-27 20:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e91caf05f441 8005540: build-infra: Improve incremental build speed on windows by caching find results Reviewed-by: ohair ! makefiles/BuildJdk.gmk ! makefiles/CompileDemos.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcProperties.gmk ! makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk ! makefiles/Tools.gmk Changeset: 368fa50469da Author: erikj Date: 2012-12-28 09:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/368fa50469da 8005549: build-infra: Merge NewMakefile.gmk and common/makefiles/Makefile Reviewed-by: ohair, tbell ! makefiles/BuildJdk.gmk Changeset: 461b069100fa Author: erikj Date: 2013-01-02 15:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/461b069100fa 8005355: build-infra: Java security signing (need a top-level make target). Reviewed-by: tbell, ohair ! makefiles/BuildJdk.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk + makefiles/SignJars.gmk Changeset: 3841da683703 Author: erikj Date: 2013-01-03 20:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3841da683703 8005635: build-infra: Support building install in jprt Reviewed-by: ohair Contributed-by: tim.bell at oracle.com, erik.joelsson at oracle.com ! make/common/shared/Defs-windows.gmk ! makefiles/BuildJdk.gmk ! makefiles/Bundles.gmk ! makefiles/Images.gmk ! makefiles/Tools.gmk Changeset: a8d25b689563 Author: erikj Date: 2013-01-04 16:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a8d25b689563 8005694: build-infra: Cleanup of misc changes in build-infra Reviewed-by: tbell ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk Changeset: 3824d8469dcf Author: erikj Date: 2013-01-04 17:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3824d8469dcf 8005654: build-infra: Create sec-bin.zip Reviewed-by: tbell ! makefiles/CreateJars.gmk Changeset: d98e73b7bc78 Author: erikj Date: 2013-01-04 22:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d98e73b7bc78 8005723: build-infra: in new infra build, sec-windows-bin-zip and jgss-windows-*-bin.zip are missing Reviewed-by: tbell ! makefiles/CreateJars.gmk Changeset: 244e481f538b Author: katleman Date: 2013-01-08 13:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/244e481f538b Merge ! makefiles/CreateJars.gmk Changeset: 1868bde529b8 Author: ohrstrom Date: 2013-01-09 13:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1868bde529b8 8005096: Move a few source files in swing/beaninfo and in a demo. Reviewed-by: ohair, erikj, malenkov ! make/javax/swing/beaninfo/SwingBeans.gmk - make/tools/swing-beans/beaninfo/BeanInfoUtils.java - make/tools/swing-beans/beaninfo/SwingBeanInfoBase.java + make/tools/swing-beans/javax/swing/SwingBeanInfoBase.java + make/tools/swing-beans/sun/swing/BeanInfoUtils.java ! makefiles/CompileJavaClasses.gmk ! makefiles/GensrcSwing.gmk - src/share/demo/jfc/CodePointIM/CodePointInputMethod.java - src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java + src/share/demo/jfc/CodePointIM/com/sun/inputmethods/internal/codepointim/CodePointInputMethod.java + src/share/demo/jfc/CodePointIM/com/sun/inputmethods/internal/codepointim/CodePointInputMethodDescriptor.java Changeset: 2cc29d0b9eaf Author: erikj Date: 2013-01-09 16:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2cc29d0b9eaf 8005903: build-infra: bad symlink: j2sdk-bundle/jdk1.8.0.jdk/Contents/MacOS/libjli.dylib Reviewed-by: tbell ! makefiles/Bundles.gmk Changeset: f92ab6dbbff8 Author: erikj Date: 2013-01-10 12:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f92ab6dbbff8 8005856: build-infra: Remove special handling of base module classes header generation Reviewed-by: alanb, tbell, ohair Contributed-by: fredrik.ohrstrom at oracle.com ! makefiles/CompileJavaClasses.gmk ! src/share/classes/java/io/FileSystem.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/net/SocketOptions.java ! src/share/classes/sun/nio/ch/IOStatus.java ! src/windows/classes/sun/nio/ch/PollArrayWrapper.java Changeset: 4d80ab394efa Author: erikj Date: 2013-01-15 16:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4d80ab394efa 8006296: build-infra: Unsigned sunmscapi.jar is missing manifest. Reviewed-by: alanb, tbell ! makefiles/CreateJars.gmk Changeset: 6d1a3d43851d Author: katleman Date: 2013-01-15 10:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6d1a3d43851d Merge - make/tools/swing-beans/beaninfo/BeanInfoUtils.java - make/tools/swing-beans/beaninfo/SwingBeanInfoBase.java - src/share/demo/jfc/CodePointIM/CodePointInputMethod.java - src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java Changeset: 3eef1e0540c4 Author: erikj Date: 2013-01-16 16:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3eef1e0540c4 8006385: build-infra: linux and solaris *-debuginfo-*.zip file created from the new makefile has extra HUDSON direcotry in jre/lib/i386/server Reviewed-by: tbell ! makefiles/Import.gmk Changeset: 54bbeb149525 Author: katleman Date: 2013-01-16 22:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/54bbeb149525 Merge - make/tools/swing-beans/beaninfo/BeanInfoUtils.java - make/tools/swing-beans/beaninfo/SwingBeanInfoBase.java ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk ! makefiles/Images.gmk ! src/share/classes/java/lang/Integer.java - src/share/demo/jfc/CodePointIM/CodePointInputMethod.java - src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java Changeset: 6d849e883c40 Author: yhuang Date: 2013-01-13 18:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6d849e883c40 7114053: [sq] Inproper tanslation for iso lanugage of Albanian Reviewed-by: naoto ! src/share/classes/sun/util/resources/sq/LocaleNames_sq.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 2de23975ee10 Author: yhuang Date: 2013-01-15 19:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2de23975ee10 Merge Changeset: 68fc838d5e89 Author: yhuang Date: 2013-01-16 19:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/68fc838d5e89 Merge Changeset: 595baf3cc781 Author: yhuang Date: 2013-01-16 23:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/595baf3cc781 Merge Changeset: 478d8354285a Author: erikj Date: 2013-01-18 16:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/478d8354285a 8006567: jre/lib/applet missing from Mac JDK installation Reviewed-by: tbell ! makefiles/Bundles.gmk Changeset: 92d8880d5406 Author: erikj Date: 2013-01-21 11:42 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/92d8880d5406 8006583: build-infra: Remove /javax/swing/SwingBeanInfoBase.java from src.zip Reviewed-by: tbell ! makefiles/GensrcSwing.gmk Changeset: a9839ed93340 Author: erikj Date: 2013-01-21 11:42 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a9839ed93340 Merge Changeset: 506bf3d23f06 Author: erikj Date: 2013-01-21 14:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/506bf3d23f06 8006579: build-infra: In jvm.cfg, alias -server to -client when no server jvm is built. Reviewed-by: tbell ! makefiles/CopyFiles.gmk Changeset: 57d5d9544628 Author: erikj Date: 2013-01-22 09:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/57d5d9544628 8004151: build-infra: Generating X11 wrapper offset file is not cross compilable Reviewed-by: dholmes, ohrstrom ! makefiles/GensrcX11Wrappers.gmk + src/solaris/classes/sun/awt/X11/generator/sizes.32 + src/solaris/classes/sun/awt/X11/generator/sizes.64 Changeset: ef592aceb40e Author: katleman Date: 2013-01-24 16:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ef592aceb40e Added tag jdk8-b74 for changeset 57d5d9544628 ! .hgtags Changeset: c6e8a518c3cd Author: jjg Date: 2013-01-10 19:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c6e8a518c3cd 8004834: Add doclint support into javadoc Reviewed-by: erikj, tbell ! make/docs/Makefile Changeset: c9308137ad9e Author: jjg Date: 2013-01-10 19:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c9308137ad9e Merge - test/java/util/Properties/MacJNUEncoding/ExpectedEncoding.java - test/java/util/Properties/MacJNUEncoding/MacJNUEncoding.sh Changeset: 86c563dc70ca Author: darcy Date: 2013-01-10 21:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/86c563dc70ca 8006062: Add @Repeatable to repeating annotations regression tests in JDK repo Reviewed-by: jjg ! test/java/lang/annotation/repeatingAnnotations/subpackage/Containee.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainee.java Changeset: 0ca2e39a110d Author: alanb Date: 2013-01-11 12:27 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0ca2e39a110d 8005566: (fs) test/java/nio/file/Files/Misc.java failing (sol) Reviewed-by: chegar ! src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java ! test/java/nio/file/Files/Misc.java Changeset: 7da291690aa0 Author: alanb Date: 2013-01-11 20:19 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7da291690aa0 8005978: shell tests need to use the $COMPILEJDK for javac, jar and other tools Reviewed-by: chegar ! test/ProblemList.txt ! test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetMaxFileDescriptorCount.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh ! test/java/io/FileOutputStream/FileOpen.sh ! test/java/io/Serializable/class/run.sh ! test/java/io/Serializable/evolution/RenamePackage/run.sh ! test/java/io/Serializable/maskSyntheticModifier/run.sh ! test/java/io/Serializable/packageAccess/run.sh ! test/java/io/Serializable/resolveClass/consTest/run.sh ! test/java/io/Serializable/resolveClass/deserializeButton/run.sh ! test/java/io/Serializable/superclassDataLoss/run.sh ! test/java/io/Serializable/unnamedPackageSwitch/run.sh ! test/java/lang/Class/getEnclosingClass/build.sh ! test/java/lang/ClassLoader/Assert.sh ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh ! test/java/lang/Thread/UncaughtExceptions.sh ! test/java/lang/annotation/loaderLeak/LoaderLeak.sh ! test/java/lang/instrument/AppendToBootstrapClassPathSetUp.sh ! test/java/lang/instrument/AppendToClassPathSetUp.sh ! test/java/lang/instrument/BootClassPath/BootClassPathTest.sh ! test/java/lang/instrument/MakeJAR.sh ! test/java/lang/instrument/MakeJAR2.sh ! test/java/lang/instrument/MakeJAR3.sh ! test/java/lang/instrument/MakeJAR4.sh ! test/java/lang/instrument/ManifestTest.sh ! test/java/lang/instrument/ParallelTransformerLoader.sh ! test/java/lang/instrument/PremainClass/NoPremainAgent.sh ! test/java/lang/instrument/PremainClass/PremainClassTest.sh ! test/java/lang/instrument/PremainClass/ZeroArgPremainAgent.sh ! test/java/lang/instrument/RedefineBigClass.sh ! test/java/lang/instrument/RedefineClassWithNativeMethod.sh ! test/java/lang/instrument/RedefineMethodAddInvoke.sh ! test/java/lang/instrument/RedefineSetUp.sh ! test/java/lang/instrument/RetransformBigClass.sh ! test/java/lang/instrument/appendToClassLoaderSearch/CircularityErrorTest.sh ! test/java/lang/instrument/appendToClassLoaderSearch/ClassUnloadTest.sh ! test/java/lang/instrument/appendToClassLoaderSearch/CommonSetup.sh ! test/java/lang/instrument/appendToClassLoaderSearch/run_tests.sh ! test/java/net/Authenticator/B4933582.sh ! test/java/net/URL/B5086147.sh ! test/java/net/URL/runconstructor.sh ! test/java/net/URLClassLoader/B5077773.sh ! test/java/net/URLClassLoader/closetest/build.sh ! test/java/net/URLClassLoader/getresourceasstream/test.sh ! test/java/net/URLClassLoader/sealing/checksealed.sh ! test/java/net/URLConnection/6212146/test.sh ! test/java/net/URLConnection/UNCTest.sh ! test/java/nio/charset/spi/basic.sh ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/registry/readTest/readTest.sh ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh ! test/java/security/Security/signedfirst/Dyn.sh ! test/java/security/Security/signedfirst/Static.sh ! test/java/security/cert/CertificateFactory/slowstream.sh ! test/java/util/Formatter/Basic.sh ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/ServiceLoader/basic.sh ! test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh ! test/java/util/prefs/PrefsSpi.sh ! test/javax/crypto/SecretKeyFactory/FailOverTest.sh ! test/javax/script/CommonSetup.sh ! test/javax/script/ProviderTest.sh ! test/javax/security/auth/Subject/doAs/Test.sh ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/management/jmxremote/bootstrap/PasswordFilePermissionTest.sh ! test/sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.sh ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh ! test/sun/net/www/MarkResetTest.sh ! test/sun/net/www/http/HttpClient/RetryPost.sh ! test/sun/net/www/protocol/jar/B5105410.sh ! test/sun/net/www/protocol/jar/jarbug/run.sh ! test/sun/security/krb5/config/dns.sh ! test/sun/security/krb5/runNameEquals.sh ! test/sun/security/mscapi/IsSunMSCAPIAvailable.sh ! test/sun/security/pkcs11/KeyStore/Basic.sh ! test/sun/security/pkcs11/KeyStore/ClientAuth.sh ! test/sun/security/pkcs11/KeyStore/Solaris.sh ! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh ! test/sun/security/pkcs11/Provider/Login.sh ! test/sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.sh ! test/sun/security/provider/PolicyFile/getinstance/getinstance.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh ! test/sun/security/tools/keytool/autotest.sh ! test/sun/security/tools/keytool/printssl.sh ! test/sun/security/tools/keytool/readjar.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/util/Oid/S11N.sh ! test/sun/security/validator/certreplace.sh ! test/sun/security/validator/samedn.sh ! test/tools/launcher/ClassPathWildCard.sh ! test/tools/launcher/MultipleJRE.sh Changeset: bc1f16f5566f Author: darcy Date: 2013-01-11 15:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bc1f16f5566f 7131459: [Fmt-De] DecimalFormat produces wrong format() results when close to a tie Reviewed-by: darcy Contributed-by: olivier.lagneau at oracle.com ! src/share/classes/java/text/DigitList.java ! src/share/classes/sun/misc/FloatingDecimal.java + test/java/text/Format/DecimalFormat/TieRoundingTest.java Changeset: 6f6246aced89 Author: sherman Date: 2013-01-11 22:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6f6246aced89 8005466: JAR file entry hash table uses too much memory (zlib_util.c) Summary: realign the fields of jzcell struct Reviewed-by: sherman Contributed-by: ioi.lam at oracle.com ! src/share/native/java/util/zip/zip_util.h Changeset: 8009c7e3899e Author: sherman Date: 2013-01-11 22:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8009c7e3899e Merge Changeset: 7db04ae3378f Author: chegar Date: 2013-01-13 22:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7db04ae3378f 8006153: HTTP protocol handler authenication should use Base64 API Reviewed-by: chegar, alanb Contributed-by: Mark Sheppard ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java Changeset: 1109bfff4e92 Author: dholmes Date: 2013-01-13 19:57 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1109bfff4e92 8005232: (JEP-149) Class Instance size reduction Summary: Moved the fields for cached reflection objects into a seperate ReflectionData object to reduce dynamic footprint. Reviewed-by: dholmes, mchung, shade Contributed-by: Peter Levart ! src/share/classes/java/lang/Class.java Changeset: 1d7a6adf499f Author: naoto Date: 2013-01-14 11:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1d7a6adf499f 7162007: Clean up i18n related caches Reviewed-by: okutsu, ohair ! make/java/java/FILES_java.gmk ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/DecimalFormatSymbols.java ! src/share/classes/java/text/NumberFormat.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/sun/text/resources/zh/CollationData_zh_HK.java ! src/share/classes/sun/text/resources/zh/FormatData_zh_HK.java ! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java ! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/CollatorProviderImpl.java ! src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleResources.java + src/share/classes/sun/util/locale/provider/ResourceBundleBasedAdapter.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java ! src/share/classes/sun/util/resources/LocaleData.java ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_HK.java ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_SG.java ! src/share/classes/sun/util/resources/zh/LocaleNames_zh_HK.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_HK.java ! test/java/util/PluggableLocale/BreakIteratorProviderTest.java ! test/java/util/PluggableLocale/CollatorProviderTest.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/DateFormatProviderTest.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.java ! test/java/util/PluggableLocale/NumberFormatProviderTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java Changeset: dcb64d498d5b Author: ksrini Date: 2013-01-14 15:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dcb64d498d5b 8005252: pack200 should support MethodParameters Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/constants.h ! src/share/native/com/sun/java/util/jar/pack/main.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! test/ProblemList.txt ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java Changeset: edb7e34a0531 Author: xuelei Date: 2013-01-14 18:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/edb7e34a0531 8006265: Add test SSLEngineDeadlock.java to ProblemList Reviewed-by: weijun ! test/ProblemList.txt Changeset: a40052a54801 Author: uta Date: 2013-01-15 14:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a40052a54801 8005250: Downgrade normative references to ${java.home}/lib folder from Java client code. Summary: Javadoc was changed in accordance with CCC-8005250 request. Reviewed-by: alanb, amenkov ! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java ! src/share/classes/javax/imageio/spi/IIORegistry.java ! src/share/classes/javax/sound/midi/MidiSystem.java ! src/share/classes/javax/sound/sampled/AudioSystem.java ! src/share/classes/javax/swing/UIManager.java Changeset: 4b012af44f24 Author: chegar Date: 2013-01-15 11:44 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4b012af44f24 8005406: HTTP server implementation should use Base64 API Reviewed-by: khazra, alanb, chegar Contributed-by: Mark Sheppard ! src/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java Changeset: 44d6cabc9a3f Author: robm Date: 2013-01-15 19:58 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/44d6cabc9a3f 8005618: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently Reviewed-by: alanb, martin, dholmes ! test/java/lang/ProcessBuilder/Basic.java Changeset: 9d8ef6174cfd Author: dl Date: 2013-01-16 10:14 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9d8ef6174cfd 8005926: Merge ThreadLocalRandom state into java.lang.Thread Reviewed-by: shade, chegar ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java Changeset: a546d8897e0d Author: dl Date: 2013-01-16 12:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a546d8897e0d 8001666: Add lambda-compatible atomics and accumulators to the ActomicXXX classes Reviewed-by: dl, chegar, darcy, goetz Contributed-by: dl at cs.oswego.edu, chris.hegarty at oracle.com ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java Changeset: c7d54f93d3e5 Author: juh Date: 2013-01-16 09:51 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c7d54f93d3e5 8005389: Backout fix for JDK-6500133 Reviewed-by: mullan ! src/share/classes/sun/security/x509/URIName.java ! test/sun/security/x509/URIName/Parse.java Changeset: f7f77bdf248b Author: juh Date: 2013-01-16 13:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f7f77bdf248b 8005939: sun/security/x509/{X509CRLImplX509CertImpl}/Verify.java fail in confusing way when some providers not present Reviewed-by: mullan, weijun ! test/sun/security/x509/X509CRLImpl/Verify.java ! test/sun/security/x509/X509CertImpl/Verify.java Changeset: 9fed48caac80 Author: lana Date: 2013-01-16 12:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9fed48caac80 Merge Changeset: 787c7c1c210f Author: sherman Date: 2013-01-17 12:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/787c7c1c210f 8006090: Formatter asserts with -esa Summary: removed the offending assert Reviewed-by: alanb, darcy Contributed-by: brian.burkhalter at oracle.com ! src/share/classes/java/util/Formatter.java ! test/ProblemList.txt Changeset: e8414d69692c Author: khazra Date: 2013-01-17 14:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e8414d69692c 7171415: java.net.URI.equals/hashCode not consistent for some URIs Summary: Rewrite URI.hashCode() to consider encoded characters, also reviewed by vitalyd at gmail.com, schlosna at gmail.com Reviewed-by: chegar ! src/share/classes/java/net/URI.java ! test/java/net/URI/Test.java Changeset: 79fed1733d4a Author: jgish Date: 2013-01-17 15:09 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/79fed1733d4a 8006534: CLONE - TestLibrary.getUnusedRandomPort() fails intermittently-doesn't retry enough times Summary: Increase number of retries to twice the number of ports in the reserved range Reviewed-by: mduigou ! test/java/rmi/testlibrary/TestLibrary.java Changeset: f88e963960ae Author: jzavgren Date: 2013-01-18 17:34 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f88e963960ae 8005120: Compiler warnings in socket transport native code Reviewed-by: chegar, dsamersoff ! src/share/transport/socket/socketTransport.c ! src/share/transport/socket/sysSocket.h ! src/solaris/transport/socket/socket_md.c ! src/windows/transport/socket/socket_md.c Changeset: 06da87777d0e Author: alanb Date: 2013-01-18 18:48 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/06da87777d0e 6939260: (fs) BasicFileAttributes.lastModifiedTime() should return last modified time with higher precision Reviewed-by: chegar ! src/solaris/classes/sun/nio/fs/UnixFileAttributes.java ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c ! test/java/nio/file/attribute/BasicFileAttributeView/Basic.java Changeset: 33d0175ea8d9 Author: msheppar Date: 2013-01-19 08:39 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/33d0175ea8d9 8006568: HTTP protocol handler NLTM Authentication should use Base64 API Reviewed-by: chegar, alanb ! src/solaris/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.java ! test/sun/net/www/protocol/http/ProxyTunnelServer.java Changeset: 78514544980d Author: lancea Date: 2013-01-19 10:11 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/78514544980d 8006139: add missing methods to javax.sql.rowset.serial.SQLInputImpl, SQLOutputImpl Reviewed-by: naoto, ulfzibis, alanb ! src/share/classes/javax/sql/rowset/serial/SQLInputImpl.java ! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java Changeset: d3da0d29d7cd Author: lancea Date: 2013-01-19 10:53 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d3da0d29d7cd 8005080: JDBC 4.2 Core changes Reviewed-by: naoto ! src/share/classes/java/sql/BatchUpdateException.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/DatabaseMetaData.java ! src/share/classes/java/sql/Driver.java ! src/share/classes/java/sql/DriverManager.java + src/share/classes/java/sql/JDBCType.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/SQLTimeoutException.java + src/share/classes/java/sql/SQLType.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/java/sql/Types.java ! src/share/classes/java/sql/package.html ! src/share/classes/javax/sql/DataSource.java ! src/share/classes/javax/sql/XADataSource.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java Changeset: bb2ed83676d2 Author: chegar Date: 2013-01-20 09:37 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bb2ed83676d2 8006560: java/net/ipv6tests/B6521014.java fails intermittently Reviewed-by: khazra, wetmore ! test/java/net/ipv6tests/B6521014.java Changeset: 6ca6b6f07653 Author: okutsu Date: 2013-01-21 12:04 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6ca6b6f07653 4745761: (cal) RFE: Support builder for constructing Calendar Reviewed-by: peytoia ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/JapaneseImperialCalendar.java + test/java/util/Calendar/Builder/BuilderTest.java ! test/java/util/Calendar/CalendarTypeTest.java Changeset: 3c1a440a1e12 Author: okutsu Date: 2013-01-21 15:41 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3c1a440a1e12 8004489: Add support for Minguo and Hijrah calendars to CalendarNameProvider SPI 8006509: Add more calendar symbol names from CLDR Reviewed-by: peytoia ! make/tools/src/build/tools/cldrconverter/Bundle.java ! make/tools/src/build/tools/cldrconverter/CLDRConverter.java ! make/tools/src/build/tools/cldrconverter/CalendarType.java ! make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java ! src/share/classes/java/util/spi/CalendarNameProvider.java ! src/share/classes/sun/text/resources/FormatData.java ! src/share/classes/sun/text/resources/ar/FormatData_ar.java ! src/share/classes/sun/text/resources/be/FormatData_be.java ! src/share/classes/sun/text/resources/bg/FormatData_bg.java ! src/share/classes/sun/text/resources/ca/FormatData_ca.java ! src/share/classes/sun/text/resources/cs/FormatData_cs.java ! src/share/classes/sun/text/resources/da/FormatData_da.java ! src/share/classes/sun/text/resources/de/FormatData_de.java ! src/share/classes/sun/text/resources/el/FormatData_el.java ! src/share/classes/sun/text/resources/es/FormatData_es.java ! src/share/classes/sun/text/resources/et/FormatData_et.java ! src/share/classes/sun/text/resources/fi/FormatData_fi.java ! src/share/classes/sun/text/resources/fr/FormatData_fr.java ! src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java ! src/share/classes/sun/text/resources/hr/FormatData_hr.java ! src/share/classes/sun/text/resources/hu/FormatData_hu.java ! src/share/classes/sun/text/resources/is/FormatData_is.java ! src/share/classes/sun/text/resources/it/FormatData_it.java ! src/share/classes/sun/text/resources/iw/FormatData_iw.java ! src/share/classes/sun/text/resources/ja/FormatData_ja.java ! src/share/classes/sun/text/resources/ko/FormatData_ko.java ! src/share/classes/sun/text/resources/lt/FormatData_lt.java ! src/share/classes/sun/text/resources/lv/FormatData_lv.java ! src/share/classes/sun/text/resources/mk/FormatData_mk.java ! src/share/classes/sun/text/resources/ms/FormatData_ms.java ! src/share/classes/sun/text/resources/mt/FormatData_mt.java ! src/share/classes/sun/text/resources/nl/FormatData_nl.java ! src/share/classes/sun/text/resources/pl/FormatData_pl.java ! src/share/classes/sun/text/resources/pt/FormatData_pt.java ! src/share/classes/sun/text/resources/ro/FormatData_ro.java ! src/share/classes/sun/text/resources/ru/FormatData_ru.java ! src/share/classes/sun/text/resources/sk/FormatData_sk.java ! src/share/classes/sun/text/resources/sl/FormatData_sl.java ! src/share/classes/sun/text/resources/sr/FormatData_sr.java ! src/share/classes/sun/text/resources/sv/FormatData_sv.java ! src/share/classes/sun/text/resources/th/FormatData_th.java ! src/share/classes/sun/text/resources/tr/FormatData_tr.java ! src/share/classes/sun/text/resources/uk/FormatData_uk.java ! src/share/classes/sun/text/resources/vi/FormatData_vi.java ! src/share/classes/sun/text/resources/zh/FormatData_zh.java ! src/share/classes/sun/text/resources/zh/FormatData_zh_TW.java ! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleResources.java + test/java/util/Calendar/CldrFormatNamesTest.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: bb940b2107bd Author: juh Date: 2013-01-21 15:05 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bb940b2107bd 8006092: SecurityPermission: printIdentity doesn't exist Reviewed-by: weijun ! test/sun/security/tools/policytool/UpdatePermissions.html Changeset: f21a3c273fb2 Author: dl Date: 2013-01-21 13:50 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f21a3c273fb2 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder Reviewed-by: chegar, darcy, goetz ! make/java/java/FILES_java.gmk + 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 + src/share/classes/java/util/concurrent/atomic/Striped64.java + test/java/util/concurrent/atomic/DoubleAdderDemo.java + test/java/util/concurrent/atomic/LongAdderDemo.java Changeset: de30e46250c5 Author: lancea Date: 2013-01-21 14:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/de30e46250c5 8006642: Fix javadoc warnings due to Integer.MAX_VALUE Reviewed-by: alanb ! src/share/classes/java/sql/BatchUpdateException.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/Statement.java Changeset: 8b1857409159 Author: lana Date: 2013-01-20 23:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8b1857409159 Merge - make/tools/swing-beans/beaninfo/BeanInfoUtils.java - make/tools/swing-beans/beaninfo/SwingBeanInfoBase.java - src/share/demo/jfc/CodePointIM/CodePointInputMethod.java - src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java Changeset: 7f4e3da76ec1 Author: lana Date: 2013-01-21 11:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7f4e3da76ec1 Merge Changeset: 8ee6d45348ba Author: vinnie Date: 2013-01-22 23:32 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8ee6d45348ba 6263419: No way to clean the memory for a java.security.Key Reviewed-by: mullan ! src/share/classes/java/security/PrivateKey.java ! src/share/classes/javax/crypto/SecretKey.java ! src/share/classes/javax/security/auth/Destroyable.java + test/javax/security/auth/Destroyable/KeyDestructionTest.java Changeset: c18f28312c49 Author: smarks Date: 2013-01-22 18:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c18f28312c49 8005646: TEST_BUG: java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup leaves process running Reviewed-by: mchung ! test/java/rmi/activation/ActivationSystem/unregisterGroup/ActivateMe.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/CallbackInterface.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/Callback_Stub.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup_Stub.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/rmid.security.policy Changeset: 919afffa70b0 Author: sherman Date: 2013-01-22 20:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/919afffa70b0 8003680: JSR 310 Date/Time API Summary: Integration of JSR310 Date/Time API for M6 Reviewed-by: alanb, naoto, dholmes Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, richard.warburton at gmail.com, misterm at gmail.com ! make/docs/CORE_PKGS.gmk ! make/java/Makefile + make/java/time/Makefile ! make/jprt.properties ! make/sun/Makefile + make/sun/tzdb/Makefile ! make/tools/Makefile + make/tools/src/build/tools/tzdb/ChronoField.java + make/tools/src/build/tools/tzdb/DateTimeException.java + make/tools/src/build/tools/tzdb/LocalDate.java + make/tools/src/build/tools/tzdb/LocalDateTime.java + make/tools/src/build/tools/tzdb/LocalTime.java + make/tools/src/build/tools/tzdb/TimeDefinition.java + make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java + make/tools/src/build/tools/tzdb/Utils.java + make/tools/src/build/tools/tzdb/ZoneOffset.java + make/tools/src/build/tools/tzdb/ZoneOffsetTransition.java + make/tools/src/build/tools/tzdb/ZoneOffsetTransitionRule.java + make/tools/src/build/tools/tzdb/ZoneRules.java + make/tools/src/build/tools/tzdb/ZoneRulesBuilder.java + make/tools/tzdb/Makefile ! makefiles/CreateJars.gmk + makefiles/GendataTZDB.gmk ! makefiles/GenerateData.gmk ! makefiles/Tools.gmk + src/share/classes/java/time/Clock.java + src/share/classes/java/time/DateTimeException.java + src/share/classes/java/time/DayOfWeek.java + 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/Month.java + src/share/classes/java/time/Period.java + src/share/classes/java/time/PeriodParser.java + src/share/classes/java/time/Ser.java + src/share/classes/java/time/ZoneId.java + src/share/classes/java/time/ZoneOffset.java + src/share/classes/java/time/ZoneRegion.java + src/share/classes/java/time/ZonedDateTime.java + src/share/classes/java/time/calendar/ChronoDateImpl.java + src/share/classes/java/time/calendar/HijrahChrono.java + src/share/classes/java/time/calendar/HijrahDate.java + src/share/classes/java/time/calendar/HijrahDeviationReader.java + src/share/classes/java/time/calendar/HijrahEra.java + src/share/classes/java/time/calendar/JapaneseChrono.java + src/share/classes/java/time/calendar/JapaneseDate.java + src/share/classes/java/time/calendar/JapaneseEra.java + src/share/classes/java/time/calendar/MinguoChrono.java + src/share/classes/java/time/calendar/MinguoDate.java + src/share/classes/java/time/calendar/MinguoEra.java + src/share/classes/java/time/calendar/Ser.java + src/share/classes/java/time/calendar/ThaiBuddhistChrono.java + src/share/classes/java/time/calendar/ThaiBuddhistDate.java + src/share/classes/java/time/calendar/ThaiBuddhistEra.java + src/share/classes/java/time/calendar/package-info.java + src/share/classes/java/time/format/DateTimeBuilder.java + src/share/classes/java/time/format/DateTimeFormatStyleProvider.java + src/share/classes/java/time/format/DateTimeFormatSymbols.java + src/share/classes/java/time/format/DateTimeFormatter.java + src/share/classes/java/time/format/DateTimeFormatterBuilder.java + src/share/classes/java/time/format/DateTimeFormatters.java + src/share/classes/java/time/format/DateTimeParseContext.java + src/share/classes/java/time/format/DateTimeParseException.java + src/share/classes/java/time/format/DateTimePrintContext.java + src/share/classes/java/time/format/DateTimePrintException.java + src/share/classes/java/time/format/DateTimeTextProvider.java + src/share/classes/java/time/format/FormatStyle.java + src/share/classes/java/time/format/SignStyle.java + src/share/classes/java/time/format/TextStyle.java + src/share/classes/java/time/format/package-info.java + src/share/classes/java/time/overview.html + src/share/classes/java/time/package-info.java + src/share/classes/java/time/temporal/Adjusters.java + src/share/classes/java/time/temporal/Chrono.java + src/share/classes/java/time/temporal/ChronoField.java + src/share/classes/java/time/temporal/ChronoLocalDate.java + src/share/classes/java/time/temporal/ChronoLocalDateTime.java + src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java + src/share/classes/java/time/temporal/ChronoUnit.java + src/share/classes/java/time/temporal/ChronoZonedDateTime.java + src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java + src/share/classes/java/time/temporal/Era.java + src/share/classes/java/time/temporal/ISOChrono.java + src/share/classes/java/time/temporal/ISOEra.java + src/share/classes/java/time/temporal/ISOFields.java + src/share/classes/java/time/temporal/JulianFields.java + src/share/classes/java/time/temporal/MonthDay.java + src/share/classes/java/time/temporal/OffsetDate.java + src/share/classes/java/time/temporal/OffsetDateTime.java + src/share/classes/java/time/temporal/OffsetTime.java + src/share/classes/java/time/temporal/Queries.java + src/share/classes/java/time/temporal/Ser.java + src/share/classes/java/time/temporal/SimplePeriod.java + src/share/classes/java/time/temporal/Temporal.java + src/share/classes/java/time/temporal/TemporalAccessor.java + src/share/classes/java/time/temporal/TemporalAdder.java + src/share/classes/java/time/temporal/TemporalAdjuster.java + src/share/classes/java/time/temporal/TemporalField.java + src/share/classes/java/time/temporal/TemporalQuery.java + src/share/classes/java/time/temporal/TemporalSubtractor.java + src/share/classes/java/time/temporal/TemporalUnit.java + src/share/classes/java/time/temporal/ValueRange.java + src/share/classes/java/time/temporal/WeekFields.java + src/share/classes/java/time/temporal/Year.java + src/share/classes/java/time/temporal/YearMonth.java + src/share/classes/java/time/temporal/package-info.java + src/share/classes/java/time/zone/Ser.java + src/share/classes/java/time/zone/TzdbZoneRulesProvider.java + src/share/classes/java/time/zone/ZoneOffsetTransition.java + src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java + src/share/classes/java/time/zone/ZoneRules.java + src/share/classes/java/time/zone/ZoneRulesException.java + src/share/classes/java/time/zone/ZoneRulesProvider.java + src/share/classes/java/time/zone/package-info.java ! src/share/classes/java/util/Formatter.java ! test/Makefile + test/java/time/META-INF/services/java.time.temporal.Chrono + test/java/time/TEST.properties + test/java/time/tck/java/time/AbstractDateTimeTest.java + test/java/time/tck/java/time/AbstractTCKTest.java + test/java/time/tck/java/time/TCKClock.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/TCKDayOfWeek.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/TCKMonth.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/calendar/CopticChrono.java + test/java/time/tck/java/time/calendar/CopticDate.java + test/java/time/tck/java/time/calendar/CopticEra.java + test/java/time/tck/java/time/calendar/TestChronoLocalDate.java + test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java + test/java/time/tck/java/time/calendar/TestHijrahChrono.java + test/java/time/tck/java/time/calendar/TestJapaneseChrono.java + test/java/time/tck/java/time/calendar/TestMinguoChrono.java + test/java/time/tck/java/time/calendar/TestServiceLoader.java + test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java + test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java + test/java/time/tck/java/time/format/TCKDateTimeFormatter.java + test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java + test/java/time/tck/java/time/format/TCKDateTimeFormatters.java + test/java/time/tck/java/time/format/TCKDateTimePrintException.java + test/java/time/tck/java/time/format/TCKDateTimeTextPrinting.java + test/java/time/tck/java/time/format/TCKLocalizedFieldParser.java + test/java/time/tck/java/time/format/TCKLocalizedFieldPrinter.java + test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java + test/java/time/tck/java/time/temporal/TCKISOFields.java + test/java/time/tck/java/time/temporal/TCKJulianFields.java + test/java/time/tck/java/time/temporal/TCKMonthDay.java + test/java/time/tck/java/time/temporal/TCKOffsetDate.java + test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java + test/java/time/tck/java/time/temporal/TCKOffsetTime.java + test/java/time/tck/java/time/temporal/TCKSimplePeriod.java + test/java/time/tck/java/time/temporal/TCKWeekFields.java + test/java/time/tck/java/time/temporal/TCKYear.java + test/java/time/tck/java/time/temporal/TCKYearMonth.java + test/java/time/tck/java/time/temporal/TestChrono.java + test/java/time/tck/java/time/temporal/TestChronoLocalDate.java + test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java + test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java + test/java/time/tck/java/time/temporal/TestISOChrono.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/TCKZoneRulesProvider.java + test/java/time/test/java/time/AbstractTest.java + test/java/time/test/java/time/MockSimplePeriod.java + test/java/time/test/java/time/TestClock_Fixed.java + test/java/time/test/java/time/TestClock_Offset.java + test/java/time/test/java/time/TestClock_System.java + test/java/time/test/java/time/TestClock_Tick.java + test/java/time/test/java/time/TestDuration.java + test/java/time/test/java/time/TestInstant.java + test/java/time/test/java/time/TestLocalDate.java + test/java/time/test/java/time/TestLocalDateTime.java + test/java/time/test/java/time/TestLocalTime.java + test/java/time/test/java/time/TestPeriod.java + test/java/time/test/java/time/TestPeriodParser.java + test/java/time/test/java/time/TestZoneId.java + test/java/time/test/java/time/TestZoneOffset.java + test/java/time/test/java/time/TestZonedDateTime.java + test/java/time/test/java/time/format/AbstractTestPrinterParser.java + test/java/time/test/java/time/format/MockIOExceptionAppendable.java + test/java/time/test/java/time/format/TestCharLiteralParser.java + test/java/time/test/java/time/format/TestCharLiteralPrinter.java + test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java + test/java/time/test/java/time/format/TestDateTimeFormatter.java + test/java/time/test/java/time/format/TestDateTimeFormatters.java + test/java/time/test/java/time/format/TestDateTimePrintException.java + test/java/time/test/java/time/format/TestDateTimeTextProvider.java + test/java/time/test/java/time/format/TestFractionPrinterParser.java + test/java/time/test/java/time/format/TestNumberParser.java + test/java/time/test/java/time/format/TestNumberPrinter.java + test/java/time/test/java/time/format/TestPadParserDecorator.java + test/java/time/test/java/time/format/TestPadPrinterDecorator.java + test/java/time/test/java/time/format/TestReducedParser.java + test/java/time/test/java/time/format/TestReducedPrinter.java + test/java/time/test/java/time/format/TestSettingsParser.java + test/java/time/test/java/time/format/TestStringLiteralParser.java + test/java/time/test/java/time/format/TestStringLiteralPrinter.java + test/java/time/test/java/time/format/TestTextParser.java + test/java/time/test/java/time/format/TestTextPrinter.java + test/java/time/test/java/time/format/TestZoneIdParser.java + test/java/time/test/java/time/format/TestZoneOffsetParser.java + test/java/time/test/java/time/format/TestZoneOffsetPrinter.java + test/java/time/test/java/time/format/TestZoneTextPrinterParser.java + test/java/time/test/java/time/temporal/MockFieldNoValue.java + test/java/time/test/java/time/temporal/MockFieldValue.java + test/java/time/test/java/time/temporal/TestChronoUnit.java + test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java + test/java/time/test/java/time/temporal/TestDateTimeBuilderCombinations.java + test/java/time/test/java/time/temporal/TestDateTimeValueRange.java + test/java/time/test/java/time/temporal/TestISOChronoImpl.java + test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java + test/java/time/test/java/time/temporal/TestMonthDay.java + test/java/time/test/java/time/temporal/TestOffsetDate.java + test/java/time/test/java/time/temporal/TestOffsetDateTime.java + test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java + test/java/time/test/java/time/temporal/TestOffsetTime.java + test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java + test/java/time/test/java/time/temporal/TestYear.java + test/java/time/test/java/time/temporal/TestYearMonth.java + test/java/time/test/java/time/zone/TestFixedZoneRules.java + test/java/time/test/java/util/TestFormatter.java Changeset: 71691b9d45ab Author: vinnie Date: 2013-01-23 09:49 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/71691b9d45ab 8006741: javadoc cleanup for 6263419 Reviewed-by: alanb ! src/share/classes/java/security/PrivateKey.java ! src/share/classes/javax/crypto/SecretKey.java Changeset: 01b36b400145 Author: uta Date: 2013-01-23 15:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/01b36b400145 6519127: user.home property not set correctly Summary: Registry-based approach was changed to SHGetKnownFolderPath/SHGetFolderPathW Reviewed-by: alanb, anthony ! src/windows/native/java/lang/java_props_md.c Changeset: bf2a14ebb6e9 Author: chegar Date: 2013-01-23 14:45 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bf2a14ebb6e9 8006669: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh fails on mac Reviewed-by: alanb ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.java Changeset: 53064bbaeec5 Author: alanb Date: 2013-01-23 15:12 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/53064bbaeec5 8006764: FunctionalInterface missing from rt.jar (old build) Reviewed-by: lancea, forax ! make/java/java/FILES_java.gmk Changeset: c9eb1d3ef37f Author: robm Date: 2013-01-23 17:54 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c9eb1d3ef37f 8004729: Add java.lang.reflect.Parameter and related changes for parameter reflection Reviewed-by: darcy, forax, psandoz, dholmes, tbell ! make/java/java/Exportedfiles.gmk ! make/java/java/FILES_c.gmk ! make/java/java/mapfile-vers ! makefiles/mapfiles/libjava/mapfile-vers ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Modifier.java + src/share/classes/java/lang/reflect/Parameter.java ! src/share/javavm/export/jvm.h + src/share/native/java/lang/reflect/Executable.c + test/java/lang/reflect/Parameter/WithParameters.java + test/java/lang/reflect/Parameter/WithoutParameters.java Changeset: e0552f13f4a2 Author: sherman Date: 2013-01-23 10:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e0552f13f4a2 8006773: test/java/util/zip/ZipFile/FinalizeZipFile.java failing intermittently Summary: fixed the test case Reviewed-by: alanb ! test/java/util/zip/ZipFile/FinalizeZipFile.java Changeset: 87f5569effdd Author: sherman Date: 2013-01-23 10:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/87f5569effdd Merge Changeset: 0c86df653029 Author: vinnie Date: 2013-01-23 21:25 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0c86df653029 8006591: Protect keystore entries using stronger PBE algorithms Reviewed-by: mullan ! src/share/classes/java/security/KeyStore.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java + test/java/security/KeyStore/PBETest.java Changeset: 1da93663f8f3 Author: vinnie Date: 2013-01-23 23:13 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1da93663f8f3 8005408: KeyStore API enhancements Reviewed-by: mullan ! src/share/classes/java/security/KeyStore.java + src/share/classes/java/security/PKCS12Attribute.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/share/classes/sun/security/x509/AlgorithmId.java + test/sun/security/pkcs12/StorePasswordTest.java + test/sun/security/pkcs12/StoreSecretKeyTest.java + test/sun/security/pkcs12/StoreTrustedCertTest.java + test/sun/security/pkcs12/trusted.pem Changeset: 89f37f7188df Author: mullan Date: 2013-01-23 20:46 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/89f37f7188df 8006813: Compilation error in PKCS12KeyStore.java Reviewed-by: valeriep ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java Changeset: b68ac92d0b2a Author: alanb Date: 2013-01-24 09:47 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b68ac92d0b2a 8006524: JSR-3: Allows java.beans to be optional Reviewed-by: dfuchs, mchung ! src/share/classes/javax/management/MXBean.java ! src/share/classes/javax/management/monitor/package.html Changeset: 943af87e0269 Author: vinnie Date: 2013-01-24 16:44 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/943af87e0269 8006855: PKCS12 test failures due to unsupported algorithm Reviewed-by: mullan ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! test/java/security/KeyStore/PBETest.java ! test/sun/security/pkcs12/StoreSecretKeyTest.java Changeset: 1fd613016ad9 Author: ksrini Date: 2013-01-24 09:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1fd613016ad9 8006850: [pack200] disable pack200 tests until JSR-308 is implemented Reviewed-by: alanb ! test/ProblemList.txt Changeset: b3f0e0c79bcc Author: vinnie Date: 2013-01-24 18:21 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b3f0e0c79bcc 8006863: javadoc cleanup for 8005408 Reviewed-by: alanb ! src/share/classes/java/security/PKCS12Attribute.java Changeset: 4d3c05cc21d5 Author: darcy Date: 2013-01-24 16:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4d3c05cc21d5 8006895: Clarify that FunctionalInferface is only informative Reviewed-by: briangoetz ! src/share/classes/java/lang/FunctionalInterface.java Changeset: 4c9fcb5cbc07 Author: dingxmin Date: 2013-01-25 17:00 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4c9fcb5cbc07 7183373: URLClassloader.close() does not close JAR files whose resources have been loaded via getResource() Reviewed-by: chegar ! src/share/classes/sun/misc/URLClassPath.java + test/sun/misc/URLClassPath/JarLoaderTest.java Changeset: 4a4b97f7f83b Author: alanb Date: 2013-01-25 13:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4a4b97f7f83b 8006565: java.lang.instrument specification should make it clear that -javaagent is optional Reviewed-by: sla, dcubed, mchung ! src/share/classes/java/lang/instrument/package.html Changeset: c6ea84a629db Author: vinnie Date: 2013-01-25 16:19 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c6ea84a629db 8006946: PKCS12 test failure due to incorrect alias name Reviewed-by: mullan ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java Changeset: 117491dd58c2 Author: vinnie Date: 2013-01-25 17:47 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/117491dd58c2 8006951: Avoid storing duplicate PKCS12 attributes Reviewed-by: mullan ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java Changeset: 77bde15bc6a9 Author: khazra Date: 2013-01-25 11:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/77bde15bc6a9 7017962: Obsolete link is used in URL class level spec Summary: Change the link to an archived document Reviewed-by: chegar, mduigou ! src/share/classes/java/net/URL.java Changeset: 4209b3936a7f Author: mduigou Date: 2013-01-25 16:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4209b3936a7f 8005632: Extend java.util.Logger to use Supplier for messages Reviewed-by: briangoetz, mduigou Contributed-by: henry.jen at oracle.com ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/LoggerSupplierAPIsTest.java Changeset: 1d918647332e Author: mduigou Date: 2013-01-25 16:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1d918647332e 8004201: Add static utility methods to primitives to be used for redution operations. Reviewed-by: darcy, mduigou, briangoetz, dholmes Contributed-by: akhil.arora at oracle.com ! src/share/classes/java/lang/Boolean.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/Long.java + test/java/lang/PrimitiveSumMinMaxTest.java Changeset: 86a5b435c928 Author: jgish Date: 2013-01-22 11:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/86a5b435c928 4247235: (spec str) StringBuffer.insert(int, char[]) specification is inconsistent Summary: Add blanket null-handling statement to StringBuilder and StringBuffer Reviewed-by: mduigou ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/StringBuffer.java ! src/share/classes/java/lang/StringBuilder.java Changeset: e96577d82cbb Author: alanb Date: 2013-01-26 16:57 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e96577d82cbb 8006503: JVM_PrintStackTrace is not used in JDK Reviewed-by: alanb, darcy Contributed-by: eric.mccorkle at oracle.com ! src/share/javavm/export/jvm.h Changeset: 57561ea851d2 Author: lana Date: 2013-01-26 19:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/57561ea851d2 Merge - test/java/rmi/activation/ActivationSystem/unregisterGroup/CallbackInterface.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/Callback_Stub.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup_Stub.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 4faaaf5027a5 Author: alexsch Date: 2013-01-14 08:32 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4faaaf5027a5 7166409: bug4331515.java fail with NullPointerException on ubuntu10.04-x86 for JDK8 Reviewed-by: serb ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java Changeset: 9c6ca265b4a1 Author: alexsch Date: 2013-01-15 12:49 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9c6ca265b4a1 8003978: closed/javax/swing/JRootPane/bug4670486.java fails since jdk7u12b01 on macosx Reviewed-by: serb, leonidr ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java ! src/share/classes/sun/swing/SwingUtilities2.java ! test/java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.java Changeset: 1b886bd5e5bf Author: serb Date: 2013-01-15 21:57 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1b886bd5e5bf 7124525: [macosx] No animation on certain Swing components in Aqua LaF Reviewed-by: alexsch, swingler ! src/macosx/classes/com/apple/laf/AquaPainter.java ! src/macosx/classes/com/apple/laf/ImageCache.java Changeset: 7ea1372be2fe Author: mcherkas Date: 2013-01-16 17:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7ea1372be2fe 8005492: Reduce number of warnings in sun/awt/* classes Reviewed-by: art, anthony ! src/share/classes/java/awt/Button.java ! src/share/classes/java/awt/Checkbox.java ! src/share/classes/java/awt/Choice.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/Scrollbar.java ! src/share/classes/java/awt/TextArea.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java ! src/share/classes/sun/awt/image/SurfaceManager.java Changeset: 23f9955ae34a Author: lana Date: 2013-01-16 15:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/23f9955ae34a Merge Changeset: 47243a4efb8b Author: kshefov Date: 2013-01-17 15:08 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/47243a4efb8b 7124209: [macosx] SpringLayout issue. BASELINE is not in the range: [NORTH, SOUTH] Reviewed-by: serb, alexsch + test/javax/swing/SpringLayout/4726194/bug4726194.java Changeset: 035f87fc9f74 Author: anthony Date: 2013-01-18 14:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/035f87fc9f74 8005465: [macosx] Evaluate if checking for the -XstartOnFirstThread is still needed in awt.m Summary: Allow one to start AWT on the main thread w/o exceptions Reviewed-by: art, serb ! src/macosx/native/sun/awt/awt.m Changeset: 5309fed435b5 Author: serb Date: 2013-01-18 18:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5309fed435b5 7179050: [macosx] Make LWAWT be able to run on AppKit thread Summary: Removed irrelevant assertions from the LWAWT native methods Reviewed-by: serb, anthony Contributed-by: petr.pchelko at oracle.com ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTSurfaceLayers.m ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.m ! src/macosx/native/sun/awt/ApplicationDelegate.m ! src/macosx/native/sun/awt/CClipboard.m ! src/macosx/native/sun/awt/CCursorManager.m ! src/macosx/native/sun/awt/CDesktopPeer.m ! src/macosx/native/sun/awt/CDragSourceContextPeer.m ! src/macosx/native/sun/awt/CImage.m ! src/macosx/native/sun/awt/CInputMethod.m ! src/macosx/native/sun/awt/CMenu.m ! src/macosx/native/sun/awt/CMenuComponent.m ! src/macosx/native/sun/awt/CMenuItem.m ! src/macosx/native/sun/awt/CPopupMenu.m ! src/macosx/native/sun/awt/CTrayIcon.m ! src/macosx/native/sun/awt/CWrapper.m ! src/macosx/native/sun/awt/JavaComponentAccessibility.m ! src/macosx/native/sun/awt/LWCToolkit.m ! src/macosx/native/sun/awt/awt.m ! src/macosx/native/sun/osxapp/ThreadUtilities.h ! src/macosx/native/sun/osxapp/ThreadUtilities.m Changeset: 112c08b41ca2 Author: alitvinov Date: 2013-01-18 18:34 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/112c08b41ca2 8006417: JComboBox.showPopup(), hidePopup() fails in JRE 1.7 on OS X Reviewed-by: art, serb ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java + test/javax/swing/JComboBox/ShowPopupAfterHidePopupTest/ShowPopupAfterHidePopupTest.java Changeset: b4131358120a Author: raginip Date: 2013-01-18 11:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b4131358120a 8000839: Integrate the Java Access Bridge with Java Runtime Reviewed-by: ptbrunet, erikj ! make/Makefile + make/bridge/AccessBridgeJava/Makefile + make/bridge/JAWTAccessBridge/Files_cpp.gmk + make/bridge/JAWTAccessBridge/Makefile + make/bridge/Jabswitch/Makefile + make/bridge/Jaccess/Makefile + make/bridge/JavaAccessBridge/Files_cpp.gmk + make/bridge/JavaAccessBridge/Makefile + make/bridge/Makefile + make/bridge/WindowsAccessBridge/Files_cpp.gmk + make/bridge/WindowsAccessBridge/Makefile ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcMisc.gmk Changeset: f55d869052dd Author: alexsch Date: 2013-01-21 17:55 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f55d869052dd 8004298: NPE in WindowsTreeUI.ensureRowsAreVisible Reviewed-by: serb ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTreeUI.java + test/javax/swing/JTree/8004298/bug8004298.java Changeset: dd7e1cc4253c Author: alexp Date: 2013-01-24 15:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dd7e1cc4253c 7147078: [macosx] Echo char set in TextField doesn't prevent word jumping Reviewed-by: art ! src/macosx/classes/com/apple/laf/AquaKeyBindings.java ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java Changeset: 04d2005fa178 Author: alexp Date: 2013-01-24 15:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/04d2005fa178 7132793: [macosx] setWheelScrollEnabled action reversed Reviewed-by: serb, art ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWScrollPanePeer.java Changeset: 40a45a72a120 Author: serb Date: 2013-01-24 15:55 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/40a45a72a120 8005997: [macosx] Printer Dialog opens an additional title bar Reviewed-by: anthony, art Contributed-by: petr.pchelko at oracle.com ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java Changeset: fab11b21ee6e Author: kizune Date: 2013-01-24 16:09 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fab11b21ee6e 7143768: [macosx] Unexpected NullPointerException and java.io.IOException during DnD Reviewed-by: alexp ! src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java Changeset: 7dd1896b37c8 Author: malenkov Date: 2013-01-24 17:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7dd1896b37c8 6817933: Setting the background of an HTML Widget changes the native Windows JFileChooser Reviewed-by: alexsch ! src/share/classes/sun/swing/WindowsPlacesBar.java + test/javax/swing/JFileChooser/6817933/Test6817933.java Changeset: f8526b99b825 Author: serb Date: 2013-01-24 17:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f8526b99b825 8003173: [macosx] Fullscreen on Mac leaves an empty rectangle Reviewed-by: anthony, alexsch ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java + test/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java Changeset: 32721a1a8da8 Author: malenkov Date: 2013-01-24 17:57 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/32721a1a8da8 8005138: test/java/beans/Introspector/TestTypeResolver.java fails Reviewed-by: alexsch ! test/java/beans/Introspector/TestTypeResolver.java Changeset: 7cda96a78260 Author: malenkov Date: 2013-01-24 18:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7cda96a78260 8003400: JTree scrolling problem when using large model in WindowsLookAndFeel Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java + test/javax/swing/JTree/8003400/Test8003400.java Changeset: e616c28c5120 Author: erikj Date: 2013-01-28 14:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e616c28c5120 Merge - make/tools/swing-beans/beaninfo/BeanInfoUtils.java - make/tools/swing-beans/beaninfo/SwingBeanInfoBase.java ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CreateJars.gmk - src/share/demo/jfc/CodePointIM/CodePointInputMethod.java - src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java Changeset: a1a55db02f34 Author: lana Date: 2013-01-29 20:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a1a55db02f34 Merge ! makefiles/CreateJars.gmk Changeset: e9d00d30fcca Author: amurillo Date: 2013-01-25 03:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e9d00d30fcca Merge Changeset: ac286bf65242 Author: amurillo Date: 2013-01-30 10:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ac286bf65242 Merge - test/java/rmi/activation/ActivationSystem/unregisterGroup/CallbackInterface.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/Callback_Stub.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup_Stub.java Changeset: 3c499051a5df Author: erikj Date: 2013-01-29 16:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3c499051a5df 8006873: SWAT-b74 msvcr100.dll does not have the permission for all Reviewed-by: alanb, tbell ! makefiles/CopyFiles.gmk Changeset: 4a67fdb752b7 Author: katleman Date: 2013-01-30 13:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4a67fdb752b7 Merge ! makefiles/CopyFiles.gmk Changeset: 6ba6353ab42c Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6ba6353ab42c Added tag jdk8-b75 for changeset 4a67fdb752b7 ! .hgtags From john.coomes at oracle.com Fri Feb 1 02:12:34 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Feb 2013 10:12:34 +0000 Subject: hg: hsx/hotspot-main/langtools: 53 new changesets Message-ID: <20130201101514.13D1C47744@hg.openjdk.java.net> Changeset: 0c244701188e Author: mchung Date: 2012-12-28 22:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/0c244701188e 8003562: Provide a CLI tool to analyze class dependencies Reviewed-by: jjg, alanb, ulfzibis, erikj ! make/build.properties ! makefiles/BuildLangtools.gmk ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/com/sun/tools/classfile/Dependency.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/Main.java + src/share/classes/com/sun/tools/jdeps/PlatformClassPath.java + src/share/classes/com/sun/tools/jdeps/resources/jdeps.properties + src/share/classes/com/sun/tools/jdeps/resources/jdk.properties + src/share/classes/com/sun/tools/jdeps/resources/version.properties-template ! test/Makefile + test/tools/jdeps/Basic.java + test/tools/jdeps/Test.java + test/tools/jdeps/p/Foo.java Changeset: 31780dd06ec7 Author: jjg Date: 2012-12-29 17:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/31780dd06ec7 8004727: Add compiler support for parameter reflection Reviewed-by: jjg Contributed-by: eric.mccorkle at oracle.com ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java + src/share/classes/com/sun/tools/classfile/MethodParameters_attribute.java ! src/share/classes/com/sun/tools/javac/code/Symbol.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/main/Option.java ! src/share/classes/com/sun/tools/javac/resources/javac.properties ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java + test/tools/javac/MethodParameters.java + test/tools/javap/MethodParameters.java Changeset: 383bc0fbd759 Author: jjg Date: 2012-12-30 06:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/383bc0fbd759 8005195: Doclint regression tests fail on windows Reviewed-by: mcimadamore ! test/tools/doclint/DocLintTester.java Changeset: 1d8438db45f2 Author: lana Date: 2013-01-01 17:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1d8438db45f2 Merge Changeset: 0e17c3c23e3b Author: bpatel Date: 2013-01-04 23:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/0e17c3c23e3b 8004891: Check for abstract method in javadoc does not conform to the language model Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java + test/com/sun/javadoc/testAbstractMethod/TestAbstractMethod.java + test/com/sun/javadoc/testAbstractMethod/pkg/A.java + test/com/sun/javadoc/testAbstractMethod/pkg/B.java + test/com/sun/javadoc/testAbstractMethod/pkg/C.java Changeset: 8c0c63a6e3b7 Author: bpatel Date: 2013-01-05 00:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8c0c63a6e3b7 8005092: javadoc should check for synthesized bit on an annotation Reviewed-by: jjg ! src/share/classes/com/sun/javadoc/AnnotationDesc.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java + test/com/sun/javadoc/testRepeatedAnnotations/TestRepeatedAnnotations.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/C.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContaineeRegDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContaineeSynthDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerRegDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerRegNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerSynthDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/D.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/NonSynthDocContainer.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegArryDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContaineeDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContaineeNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContainerDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContainerNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/C.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContaineeNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContaineeSynthDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerSynthNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerValDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerValNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContaineeDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContaineeNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContainerValDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContainerValNotDoc.java Changeset: a9cb93cca229 Author: jjh Date: 2013-01-07 17:51 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a9cb93cca229 8005647: langtools/test/tools/javap/MethodParameters.java fails on windows Summary: Fix javap to not output \r\r\n Reviewed-by: jjg ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! test/tools/javac/MethodParameters.java ! test/tools/javap/MethodParameters.java Changeset: 38d3d1027f5a Author: mcimadamore Date: 2013-01-08 10:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/38d3d1027f5a 8005243: Restructure method check code to allow pluggable checkers Summary: Add interface to perform a method check - to be implemented by helper classes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java Changeset: db91d860156a Author: mcimadamore Date: 2013-01-08 10:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/db91d860156a 8005179: Cleanup Resolve.AmbiguityError Summary: Linearize nested ambiguity errors Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/lambda/TargetType21.java ! test/tools/javac/lambda/TargetType21.out Changeset: d07340b61e6a Author: mcimadamore Date: 2013-01-08 10:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d07340b61e6a 8005184: Restructure DeferredAttr to allow pluggable deferred type completers Summary: Add hooks to generalize deferred type completion via custom helper objects Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java Changeset: 954541f13717 Author: vromero Date: 2013-01-08 13:47 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/954541f13717 8005167: execution time of combo tests in javac should be improved Reviewed-by: jjg, jjh ! test/tools/javac/Diagnostics/6769027/T6769027.java ! test/tools/javac/T7093325.java ! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java ! test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java ! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java ! test/tools/javac/lambda/FunctionalInterfaceConversionTest.java ! test/tools/javac/lambda/LambdaParserTest.java ! test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/lambda/TestInvokeDynamic.java ! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java ! test/tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java + test/tools/javac/lib/JavacTestingAbstractThreadedTest.java ! test/tools/javac/multicatch/7030606/DisjunctiveTypeWellFormednessTest.java ! test/tools/javac/varargs/7042566/T7042566.java ! test/tools/javac/varargs/warning/Warn4.java ! test/tools/javac/varargs/warning/Warn5.java Changeset: d2eb08b3f64f Author: jjg Date: 2013-01-09 10:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d2eb08b3f64f 8005644: set default max errs and max warns Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/Messager.java + test/tools/javadoc/MaxWarns.java Changeset: 7612fe48be90 Author: darcy Date: 2013-01-09 20:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7612fe48be90 8004730: Add language model support for parameter reflection Reviewed-by: abuckley ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/VariableElement.java ! src/share/classes/javax/lang/model/element/package-info.java Changeset: d462da465da6 Author: jjg Date: 2013-01-10 14:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d462da465da6 8006037: extra space in javac -help for -J and @ options Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/Option.java + test/tools/javac/main/Option_J_At_Test.java Changeset: 7d2f628f04f1 Author: jjg Date: 2013-01-10 15:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7d2f628f04f1 8006033: bug in Pretty.toSimpleString Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/tree/Pretty.java + test/tools/javac/tree/PrettySimpleStringTest.java Changeset: 8d0baee36c71 Author: lana Date: 2013-01-10 15:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8d0baee36c71 Merge Changeset: 56c97aff46bb Author: katleman Date: 2013-01-16 12:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/56c97aff46bb Added tag jdk8-b73 for changeset 8d0baee36c71 ! .hgtags Changeset: 54e4ba223319 Author: katleman Date: 2013-01-24 16:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/54e4ba223319 Added tag jdk8-b74 for changeset 56c97aff46bb ! .hgtags Changeset: fc4cb1577ad6 Author: jjg Date: 2013-01-10 19:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/fc4cb1577ad6 8004834: Add doclint support into javadoc Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java ! test/com/sun/javadoc/5093723/T5093723.java ! test/com/sun/javadoc/testBadSourceFile/TestBadSourceFile.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testReturnTag/TestReturnTag.java ! test/com/sun/javadoc/testTagInheritence/TestTagInheritence.java ! test/com/sun/javadoc/testTagMisuse/TestTagMisuse.java ! test/com/sun/javadoc/testValueTag/TestValueTag.java ! test/com/sun/javadoc/testWarnBadParamNames/TestWarnBadParamNames.java ! test/com/sun/javadoc/testWarnings/TestWarnings.java ! test/tools/javadoc/6958836/Test.java ! test/tools/javadoc/6964914/Test.java ! test/tools/javadoc/6964914/TestStdDoclet.java ! test/tools/javadoc/MaxWarns.java ! test/tools/javadoc/T6551367.java + test/tools/javadoc/doclint/DocLintTest.java Changeset: 9f42a06a49c0 Author: jfranck Date: 2013-01-14 19:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/9f42a06a49c0 7193719: Support repeating annotations in javax.lang.model Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/javax/lang/model/element/Element.java Changeset: df694c775e8a Author: jjg Date: 2013-01-14 13:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/df694c775e8a 8006119: update javac to follow latest spec for repeatable annotations Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/Symtab.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/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContaineeSynthDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerSynthDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContaineeSynthDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerSynthNotDoc.java ! test/tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.java ! test/tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.out ! test/tools/javac/annotations/repeatingAnnotations/BasicRepeatingAnnotations.java ! test/tools/javac/annotations/repeatingAnnotations/CheckTargets.java ! test/tools/javac/annotations/repeatingAnnotations/ClassReaderDefault.java ! test/tools/javac/annotations/repeatingAnnotations/ContainerHasRepeatedContained.java ! test/tools/javac/annotations/repeatingAnnotations/CyclicAnnotation.java ! test/tools/javac/annotations/repeatingAnnotations/CyclicAnnotation.out ! test/tools/javac/annotations/repeatingAnnotations/DefaultCasePresent.java ! test/tools/javac/annotations/repeatingAnnotations/DelayRepeatedContainer.java ! test/tools/javac/annotations/repeatingAnnotations/DocumentedContainerAnno.java ! test/tools/javac/annotations/repeatingAnnotations/DocumentedContainerAnno.out ! test/tools/javac/annotations/repeatingAnnotations/InheritedContainerAnno.java ! test/tools/javac/annotations/repeatingAnnotations/InheritedContainerAnno.out ! test/tools/javac/annotations/repeatingAnnotations/InvalidTarget.java - test/tools/javac/annotations/repeatingAnnotations/MissingContainedBy.java ! test/tools/javac/annotations/repeatingAnnotations/MissingContainer.java ! test/tools/javac/annotations/repeatingAnnotations/MissingContainer.out - test/tools/javac/annotations/repeatingAnnotations/MissingContainerFor.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.out ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.out ! test/tools/javac/annotations/repeatingAnnotations/MissingValueMethod.java ! test/tools/javac/annotations/repeatingAnnotations/MissingValueMethod.out ! test/tools/javac/annotations/repeatingAnnotations/MultiLevelRepeatableAnno.java ! test/tools/javac/annotations/repeatingAnnotations/MultipleAnnoMixedOrder.java ! test/tools/javac/annotations/repeatingAnnotations/NestedContainers.java ! test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.out ! test/tools/javac/annotations/repeatingAnnotations/RepMemberAnno.java ! test/tools/javac/annotations/repeatingAnnotations/RepSelfMemberAnno.java ! test/tools/javac/annotations/repeatingAnnotations/RepeatingAndContainerPresent.java ! test/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.java ! test/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.out ! test/tools/javac/annotations/repeatingAnnotations/SelfRepeatingAnnotations.java ! test/tools/javac/annotations/repeatingAnnotations/SingleRepeatingAndContainer.java - test/tools/javac/annotations/repeatingAnnotations/UseWrongContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/UseWrongContainerFor.java + test/tools/javac/annotations/repeatingAnnotations/UseWrongRepeatable.java - test/tools/javac/annotations/repeatingAnnotations/WrongContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/WrongContainerFor.java ! test/tools/javac/annotations/repeatingAnnotations/WrongReturnTypeForValue.java ! test/tools/javac/annotations/repeatingAnnotations/WrongReturnTypeForValue.out ! test/tools/javac/annotations/repeatingAnnotations/combo/BasicSyntaxCombo.java ! test/tools/javac/annotations/repeatingAnnotations/combo/DeprecatedAnnoCombo.java ! test/tools/javac/annotations/repeatingAnnotations/combo/DocumentedAnnoCombo.java ! test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java ! test/tools/javac/annotations/repeatingAnnotations/combo/InheritedAnnoCombo.java ! test/tools/javac/annotations/repeatingAnnotations/combo/RetentionAnnoCombo.java ! test/tools/javac/diags/examples.not-yet.txt - test/tools/javac/diags/examples/ContainedByDocumentedMismatch.java - test/tools/javac/diags/examples/ContainedByInheritedMismatch.java - test/tools/javac/diags/examples/ContainedByNoValue.java - test/tools/javac/diags/examples/ContainedByNonDefault.java - test/tools/javac/diags/examples/ContainedByRetentionMismatch.java - test/tools/javac/diags/examples/ContainedByTargetMismatch.java - test/tools/javac/diags/examples/ContainedByWrongValueType.java ! test/tools/javac/diags/examples/InvalidDuplicateAnnotation.java + test/tools/javac/diags/examples/RepeatableDocumentedMismatch.java + test/tools/javac/diags/examples/RepeatableInheritedMismatch.java + test/tools/javac/diags/examples/RepeatableNoValue.java + test/tools/javac/diags/examples/RepeatableNonDefault.java + test/tools/javac/diags/examples/RepeatableRetentionMismatch.java + test/tools/javac/diags/examples/RepeatableTargetMismatch.java + test/tools/javac/diags/examples/RepeatableWrongValueType.java ! test/tools/javac/diags/examples/RepeatingAnnotationAndContainer.java - test/tools/javac/diags/examples/WrongContainedBy.java - test/tools/javac/diags/examples/WrongContainerFor.java Changeset: d54b4a091450 Author: jjg Date: 2013-01-14 14:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d54b4a091450 8006241: Test DocRootSlash.java fails Reviewed-by: darcy ! test/com/sun/javadoc/DocRootSlash/DocRootSlash.java Changeset: f805b5e3c9d1 Author: chegar Date: 2013-01-15 20:38 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f805b5e3c9d1 8006344: Broken javadoc link in javax.lang.model.element.Element Reviewed-by: lancea, alanb, jfranck ! src/share/classes/javax/lang/model/element/Element.java Changeset: bc1023e0e533 Author: jjg Date: 2013-01-15 13:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bc1023e0e533 8006224: Doclint NPE for attribute with no value Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties + test/tools/doclint/AnchorTest.java + test/tools/doclint/AnchorTest.out Changeset: f785dcac17b7 Author: mcimadamore Date: 2013-01-16 16:27 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f785dcac17b7 8005854: Add support for array constructor references Summary: Support constructor references of the kind int[]::new Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/lambda/MethodReference59.java + test/tools/javac/lambda/MethodReference60.java + test/tools/javac/lambda/MethodReference60.out Changeset: 7aa2025bbb7b Author: mcimadamore Date: 2013-01-16 16:30 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7aa2025bbb7b 8005299: Add FunctionalInterface checking to javac Summary: Javac should check that types annotated with @FunctionalInterface are indeed functional interfaces Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/BadFunctionalIntfAnno.java ! test/tools/javac/lambda/BadConv03.out ! test/tools/javac/lambda/BadLambdaPos.out ! test/tools/javac/lambda/BadTargetType.out + test/tools/javac/lambda/FunctionalInterfaceAnno.java + test/tools/javac/lambda/FunctionalInterfaceAnno.out ! test/tools/javac/lambda/Intersection01.out ! test/tools/javac/lambda/LambdaConv09.out ! test/tools/javac/lambda/LambdaExpr10.out ! test/tools/javac/lambda/MethodReference04.out ! test/tools/javac/lambda/TargetType17.out ! test/tools/javac/lambda/TargetType43.out ! test/tools/javac/lambda/funcInterfaces/LambdaTest2_neg1.out ! test/tools/javac/lambda/funcInterfaces/NonSAM1.out ! test/tools/javac/lambda/funcInterfaces/NonSAM3.out ! test/tools/javac/lambda/lambdaExpression/AbstractClass_neg.out ! test/tools/javac/lambda/lambdaExpression/InvalidExpression5.out Changeset: 1afdf1f1472b Author: mcimadamore Date: 2013-01-16 17:40 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1afdf1f1472b 8005964: Regression: difference in error recovery after ambiguity causes JCK test failure Summary: Wrong implementation of ResolveError.access in AmbiguityError Reviewed-by: jjh ! src/share/classes/com/sun/tools/javac/comp/Resolve.java Changeset: 6b6311a8c9cc Author: jjg Date: 2013-01-16 10:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6b6311a8c9cc 8006236: doclint: structural issue hidden Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java + test/tools/doclint/EndTagsTest.java + test/tools/doclint/EndTagsTest.out Changeset: 63b20bde7cd6 Author: lana Date: 2013-01-16 12:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/63b20bde7cd6 Merge Changeset: 8b749558767b Author: darcy Date: 2013-01-16 13:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8b749558767b 8006283: Change to Class.cast() in javax.lang.model implementation for repeating annotations Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/model/JavacElements.java Changeset: 916143318f10 Author: jjg Date: 2013-01-16 20:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/916143318f10 8006228: Doclint doesn't detect {@code nested inline} Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties + test/tools/doclint/LiteralTest.java + test/tools/doclint/LiteralTest.out Changeset: 2d2b2be57c78 Author: mcimadamore Date: 2013-01-17 18:15 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2d2b2be57c78 8005852: Treatment of '_' as identifier Summary: warn when '_' is found in an identifier position Reviewed-by: jjg ! 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/resources/compiler.properties ! test/tools/javac/lambda/LambdaParserTest.java Changeset: 22e417cdddee Author: ohrstrom Date: 2013-01-18 00:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/22e417cdddee 8004658: Add internal smart javac wrapper to solve JEP 139 Reviewed-by: jjg ! make/build.properties ! make/build.xml + src/share/classes/com/sun/tools/sjavac/BuildState.java + src/share/classes/com/sun/tools/sjavac/CleanProperties.java + src/share/classes/com/sun/tools/sjavac/CompileChunk.java + src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java + src/share/classes/com/sun/tools/sjavac/CompileProperties.java + src/share/classes/com/sun/tools/sjavac/CopyFile.java + src/share/classes/com/sun/tools/sjavac/JavacState.java + src/share/classes/com/sun/tools/sjavac/Log.java + src/share/classes/com/sun/tools/sjavac/Main.java + src/share/classes/com/sun/tools/sjavac/Module.java + src/share/classes/com/sun/tools/sjavac/Package.java + src/share/classes/com/sun/tools/sjavac/ProblemException.java + src/share/classes/com/sun/tools/sjavac/Source.java + src/share/classes/com/sun/tools/sjavac/Transformer.java + src/share/classes/com/sun/tools/sjavac/Util.java + src/share/classes/com/sun/tools/sjavac/comp/Dependencies.java + src/share/classes/com/sun/tools/sjavac/comp/JavaCompilerWithDeps.java + src/share/classes/com/sun/tools/sjavac/comp/PubapiVisitor.java + src/share/classes/com/sun/tools/sjavac/comp/ResolveWithDeps.java + src/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java + src/share/classes/com/sun/tools/sjavac/comp/SmartFileObject.java + src/share/classes/com/sun/tools/sjavac/comp/SmartWriter.java + src/share/classes/com/sun/tools/sjavac/server/CompilerPool.java + src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java + src/share/classes/com/sun/tools/sjavac/server/JavacServer.java + src/share/classes/com/sun/tools/sjavac/server/PortFile.java + src/share/classes/com/sun/tools/sjavac/server/SysInfo.java + test/tools/sjavac/SJavac.java Changeset: 3d84ae209919 Author: mcimadamore Date: 2013-01-18 15:38 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3d84ae209919 8006561: Langtools test failure: missing diags/examples Summary: forgot to hg add tests Reviewed-by: jjg + test/tools/javac/diags/examples/UnderscoreAsIdentifier.java + test/tools/javac/lambda/WarnUnderscoreAsIdent.java + test/tools/javac/lambda/WarnUnderscoreAsIdent.out Changeset: 4a3cfc970c6f Author: jjg Date: 2013-01-21 10:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4a3cfc970c6f 8006263: Supplementary test cases needed for doclint Reviewed-by: mcimadamore Contributed-by: peter.jensen at oracle.com ! 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/Entity.java ! src/share/classes/com/sun/tools/doclint/HtmlTag.java + test/tools/doclint/CoverageExtras.java ! test/tools/doclint/DocLintTester.java + test/tools/doclint/html/EntitiesTest.java + test/tools/doclint/html/EntitiesTest.out + test/tools/doclint/tool/HelpTest.java + test/tools/doclint/tool/HelpTest.out + test/tools/doclint/tool/MaxDiagsTest.java + test/tools/doclint/tool/MaxDiagsTest.out + test/tools/doclint/tool/PathsTest.java + test/tools/doclint/tool/RunTest.java + test/tools/doclint/tool/StatsTest.java + test/tools/doclint/tool/StatsTest.out Changeset: 967052c425a1 Author: jjg Date: 2013-01-21 10:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/967052c425a1 8006251: doclint: incorrect position for diagnostic for illegal text in tags Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/HtmlTag.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! test/tools/doclint/HtmlTagsTest.java ! test/tools/doclint/HtmlTagsTest.out + test/tools/doclint/html/BlockTagsTest.java + test/tools/doclint/html/InlineTagsTest.java + test/tools/doclint/html/ListTagsTest.java + test/tools/doclint/html/OtherTagsTest.java + test/tools/doclint/html/OtherTagsTest.out + test/tools/doclint/html/TableTagsTest.java + test/tools/doclint/html/TagNotAllowed.java + test/tools/doclint/html/TagNotAllowed.out + test/tools/doclint/html/TextNotAllowed.java + test/tools/doclint/html/TextNotAllowed.out ! test/tools/doclint/tidy/ParaInPre.out ! test/tools/doclint/tidy/TextNotAllowed.out Changeset: b450959b42ff Author: lana Date: 2013-01-20 23:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b450959b42ff Merge Changeset: 1985e35e97b2 Author: lana Date: 2013-01-21 11:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1985e35e97b2 Merge Changeset: 7873d37f5b37 Author: mcimadamore Date: 2013-01-21 20:13 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7873d37f5b37 8005244: Implement overload resolution as per latest spec EDR Summary: Add support for stuck expressions and provisional applicability Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.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/Infer.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.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/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/tools/javac/Diagnostics/6722234/T6722234d_1.out ! test/tools/javac/Diagnostics/6722234/T6722234d_2.out ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/CyclicInference.java - test/tools/javac/diags/examples/InferredDoNotConformToLower.java - test/tools/javac/diags/examples/NoUniqueMaximalInstance.java ! test/tools/javac/diags/examples/WhereIntersection.java ! test/tools/javac/generics/diamond/T6939780.out ! test/tools/javac/generics/diamond/neg/Neg05.out ! test/tools/javac/generics/diamond/neg/Neg10.java ! test/tools/javac/generics/diamond/neg/Neg10.out ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6650759/T6650759m.out ! test/tools/javac/lambda/MethodReference25.java + test/tools/javac/lambda/MethodReference25.out ! test/tools/javac/lambda/MethodReference26.java - test/tools/javac/lambda/MethodReference26.out ! test/tools/javac/lambda/MethodReference43.java ! test/tools/javac/lambda/TargetType01.java + test/tools/javac/lambda/TargetType01.out ! test/tools/javac/lambda/TargetType06.java - test/tools/javac/lambda/TargetType06.out ! test/tools/javac/lambda/TargetType10.out ! test/tools/javac/lambda/TargetType11.java - test/tools/javac/lambda/TargetType11.out ! test/tools/javac/lambda/TargetType14.out ! test/tools/javac/lambda/TargetType21.java ! test/tools/javac/lambda/TargetType21.out ! test/tools/javac/lambda/TargetType26.out ! test/tools/javac/lambda/TargetType27.out ! test/tools/javac/lambda/TargetType28.out ! test/tools/javac/lambda/TargetType39.out ! test/tools/javac/lambda/TargetType45.java - test/tools/javac/lambda/TargetType45.out ! test/tools/javac/lambda/TargetType50.out + test/tools/javac/lambda/TargetType51.java + test/tools/javac/lambda/TargetType52.java + test/tools/javac/lambda/TargetType52.out ! test/tools/javac/lambda/VoidCompatibility.java - test/tools/javac/lambda/VoidCompatibility.out ! test/tools/javac/lambda/lambdaExpression/SamConversionComboTest.java ! test/tools/javac/lambda/methodReference/SamConversion.java ! test/tools/javac/lambda/methodReference/SamConversionComboTest.java ! test/tools/javac/lambda/typeInference/InferenceTest_neg5.out ! test/tools/javac/resolve/tests/PrimitiveOverReferenceVarargsAmbiguous.java Changeset: c7c41a044e7c Author: mcimadamore Date: 2013-01-21 20:14 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c7c41a044e7c 8006566: Remove transient lambda-related guards from JavacParser Summary: Remove transitional internal flag for allowing intersection types in cast Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java ! test/tools/javac/cast/intersection/IntersectionTypeParserTest.java ! test/tools/javac/cast/intersection/model/Model01.java ! test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java ! test/tools/javac/lambda/Intersection01.java ! test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java Changeset: b12ffdfa1341 Author: mcimadamore Date: 2013-01-21 20:15 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b12ffdfa1341 8005851: Remove support for synchronized interface methods Summary: Synchronized default methods are no longer supported Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java Changeset: cf84b07a82db Author: mcimadamore Date: 2013-01-21 20:19 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/cf84b07a82db 8005166: Add support for static interface methods Summary: Support public static interface methods Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.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/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/defaultMethods/static/Static01.java + test/tools/javac/defaultMethods/static/Static02.java + test/tools/javac/defaultMethods/static/Static02.out + test/tools/javac/defaultMethods/static/hiding/InterfaceMethodHidingTest.java + test/tools/javac/defaultMethods/static/import/StaticImport1.java + test/tools/javac/defaultMethods/static/import/StaticImport2.java + test/tools/javac/defaultMethods/static/import/StaticImport2.out + test/tools/javac/defaultMethods/static/import/StaticImport3.java + test/tools/javac/defaultMethods/static/import/StaticImport3.out + test/tools/javac/defaultMethods/static/import/pkg/A.java + test/tools/javac/defaultMethods/static/import/pkg/B.java + test/tools/javac/defaultMethods/static/import/pkg/C.java ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java + test/tools/javac/diags/examples/IllegalStaticIntfMethCall.java + test/tools/javac/diags/examples/StaticIntfMethodNotSupported.java Changeset: be443002e970 Author: mcimadamore Date: 2013-01-22 16:23 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/be443002e970 8006673: TargetType52 fails because of bad golden file Summary: Fix golden file in negative test Reviewed-by: jjg ! test/tools/javac/lambda/TargetType52.out Changeset: b61e5f801f7c Author: mcimadamore Date: 2013-01-22 16:39 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b61e5f801f7c 8006684: Compiler produces java.lang.VerifyError: Bad type on operand stack Summary: Lambda desugaring generates spurious references to 'this' in static contexts Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/LambdaExpr21.java Changeset: 8943b4213f59 Author: jjg Date: 2013-01-22 18:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8943b4213f59 8006723: sjavac test fails to compile on clean build Reviewed-by: ksrini ! test/tools/sjavac/SJavac.java + test/tools/sjavac/SJavacWrapper.java Changeset: f5b70712e0d5 Author: jjg Date: 2013-01-22 19:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f5b70712e0d5 8006728: temporarily workaround jtreg problems for doclint tests in othervm Reviewed-by: jjh + test/tools/doclint/html/AAA.java + test/tools/doclint/tidy/AAA.java + test/tools/doclint/tool/AAA.java Changeset: 385828dd5604 Author: jjg Date: 2013-01-22 19:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/385828dd5604 Merge Changeset: 97bd5e7151bc Author: mcimadamore Date: 2013-01-23 15:08 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/97bd5e7151bc 8006692: jdk/test/java/util/Collections/BigBinarySearch.java fails to compile Summary: Missing boxing cause spurious inference failure Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/8006692/T8006692.java Changeset: 5c956be64b9e Author: vromero Date: 2013-01-23 20:57 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/5c956be64b9e 8006694: temporarily workaround combo tests are causing time out in several platforms Reviewed-by: jjg Contributed-by: maurizio.cimadamore at oracle.com ! test/Makefile ! test/tools/javac/Diagnostics/6769027/T6769027.java ! test/tools/javac/T7093325.java ! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java ! test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java ! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java ! test/tools/javac/lambda/FunctionalInterfaceConversionTest.java ! test/tools/javac/lambda/LambdaParserTest.java ! test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/lambda/TestInvokeDynamic.java ! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java ! test/tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/FDSeparateCompilationTest.java ! test/tools/javac/lib/JavacTestingAbstractThreadedTest.java ! test/tools/javac/multicatch/7030606/DisjunctiveTypeWellFormednessTest.java ! test/tools/javac/varargs/7042566/T7042566.java ! test/tools/javac/varargs/warning/Warn4.java ! test/tools/javac/varargs/warning/Warn5.java Changeset: 71f35e4b93a5 Author: jjg Date: 2013-01-23 13:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/71f35e4b93a5 8006775: JSR 308: Compiler changes in JDK8 Reviewed-by: jjg Contributed-by: mernst at cs.washington.edu, wmdietl at cs.washington.edu, mpapi at csail.mit.edu, mahmood at notnoop.com + src/share/classes/com/sun/javadoc/AnnotatedType.java ! src/share/classes/com/sun/javadoc/ExecutableMemberDoc.java ! src/share/classes/com/sun/javadoc/Type.java ! src/share/classes/com/sun/javadoc/TypeVariable.java + src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java ! src/share/classes/com/sun/source/tree/MethodTree.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/TypeParameterTree.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TaskEvent.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java + src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java + src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java + src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java + src/share/classes/com/sun/tools/classfile/TypeAnnotation.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java ! src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/TargetType.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/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/ConstFold.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.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/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.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/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java + src/share/classes/com/sun/tools/javadoc/AnnotatedTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/PrimitiveType.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java ! src/share/classes/com/sun/tools/javap/AnnotationWriter.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/InstructionDetailWriter.java + src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java ! src/share/classes/javax/lang/model/SourceVersion.java + src/share/classes/javax/lang/model/type/AnnotatedType.java ! src/share/classes/javax/lang/model/type/ExecutableType.java ! src/share/classes/javax/lang/model/type/TypeKind.java ! src/share/classes/javax/lang/model/type/TypeVisitor.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/Types.java + test/com/sun/javadoc/testAnnotationOptional/TestAnnotationOptional.java + test/com/sun/javadoc/testAnnotationOptional/pkg/AnnotationOptional.java + test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java + test/com/sun/javadoc/typeAnnotations/smoke/pkg/TargetTypes.java ! test/tools/javac/7129225/TestImportStar.java ! test/tools/javac/7129225/TestImportStar.ref ! test/tools/javac/T6873845.java + test/tools/javac/T6985181.java ! test/tools/javac/annotations/6881115/T6881115.java ! test/tools/javac/annotations/6881115/T6881115.out + test/tools/javac/annotations/typeAnnotations/6967002/T6967002.java + test/tools/javac/annotations/typeAnnotations/6967002/T6967002.out + test/tools/javac/annotations/typeAnnotations/InnerClass.java + test/tools/javac/annotations/typeAnnotations/MultipleTargets.java + test/tools/javac/annotations/typeAnnotations/TargetTypes.java + test/tools/javac/annotations/typeAnnotations/TypeParameterTarget.java + test/tools/javac/annotations/typeAnnotations/TypeProcOnly.java + test/tools/javac/annotations/typeAnnotations/TypeUseTarget.java + test/tools/javac/annotations/typeAnnotations/api/AnnotatedArrayOrder.java + test/tools/javac/annotations/typeAnnotations/api/ArrayCreationTree.java + test/tools/javac/annotations/typeAnnotations/api/ArrayPositionConsistency.java + test/tools/javac/annotations/typeAnnotations/attribution/Scopes.java + test/tools/javac/annotations/typeAnnotations/classfile/ClassfileTestHelper.java + test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java + test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java + test/tools/javac/annotations/typeAnnotations/classfile/DeadCode.java + test/tools/javac/annotations/typeAnnotations/classfile/NewTypeArguments.java + test/tools/javac/annotations/typeAnnotations/classfile/NoTargetAnnotations.java + test/tools/javac/annotations/typeAnnotations/classfile/TypeCasts.java + test/tools/javac/annotations/typeAnnotations/classfile/Wildcards.java + test/tools/javac/annotations/typeAnnotations/failures/AnnotatedImport.java + test/tools/javac/annotations/typeAnnotations/failures/AnnotatedImport.out + 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/AnnotatedPackage2.out + 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/CantAnnotateStaticClass.java + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.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.java + test/tools/javac/annotations/typeAnnotations/failures/LintCast.out + test/tools/javac/annotations/typeAnnotations/failures/OldArray.java + 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/TypeAndField.java + test/tools/javac/annotations/typeAnnotations/failures/VoidGenericMethod.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/BrokenAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/BrokenAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/Nesting.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/StaticThings.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/StaticThings.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.out + test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/rest/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/rest/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/rest/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/rest/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/target/Constructor.java + test/tools/javac/annotations/typeAnnotations/failures/target/Constructor.out + test/tools/javac/annotations/typeAnnotations/failures/target/DotClass.java + test/tools/javac/annotations/typeAnnotations/failures/target/DotClass.out + test/tools/javac/annotations/typeAnnotations/failures/target/IncompleteArray.java + test/tools/javac/annotations/typeAnnotations/failures/target/IncompleteArray.out + test/tools/javac/annotations/typeAnnotations/failures/target/NotTypeParameter.java + test/tools/javac/annotations/typeAnnotations/failures/target/NotTypeParameter.out + test/tools/javac/annotations/typeAnnotations/failures/target/NotTypeUse.java + test/tools/javac/annotations/typeAnnotations/failures/target/NotTypeUse.out + test/tools/javac/annotations/typeAnnotations/failures/target/VoidMethod.java + test/tools/javac/annotations/typeAnnotations/failures/target/VoidMethod.out + test/tools/javac/annotations/typeAnnotations/newlocations/BasicTest.java + test/tools/javac/annotations/typeAnnotations/newlocations/ClassExtends.java + test/tools/javac/annotations/typeAnnotations/newlocations/ClassParameters.java + test/tools/javac/annotations/typeAnnotations/newlocations/ConstructorTypeArgs.java + test/tools/javac/annotations/typeAnnotations/newlocations/ExceptionParameters.java + test/tools/javac/annotations/typeAnnotations/newlocations/Expressions.java + test/tools/javac/annotations/typeAnnotations/newlocations/Fields.java + test/tools/javac/annotations/typeAnnotations/newlocations/LocalVariables.java + test/tools/javac/annotations/typeAnnotations/newlocations/MethodReturnType.java + test/tools/javac/annotations/typeAnnotations/newlocations/MethodTypeArgs.java + test/tools/javac/annotations/typeAnnotations/newlocations/MethodTypeParameters.java + test/tools/javac/annotations/typeAnnotations/newlocations/MultiCatch.java + test/tools/javac/annotations/typeAnnotations/newlocations/NestedTypes.java + test/tools/javac/annotations/typeAnnotations/newlocations/Parameters.java + test/tools/javac/annotations/typeAnnotations/newlocations/Receivers.java + test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.java + test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.out + test/tools/javac/annotations/typeAnnotations/newlocations/ResourceVariables.java + test/tools/javac/annotations/typeAnnotations/newlocations/Throws.java + test/tools/javac/annotations/typeAnnotations/newlocations/TopLevelBlocks.java + test/tools/javac/annotations/typeAnnotations/newlocations/TypeCasts.java + test/tools/javac/annotations/typeAnnotations/newlocations/TypeParameters.java + test/tools/javac/annotations/typeAnnotations/newlocations/Varargs.java + test/tools/javac/annotations/typeAnnotations/newlocations/Wildcards.java + test/tools/javac/annotations/typeAnnotations/packageanno/PackageProcessor.java + test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/Anno.java + test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/MyClass.java + test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/package-info.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassExtends.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassTypeParam.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/Driver.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/ExceptionParameters.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/Fields.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/FromSpecification.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodParameters.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReceivers.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReturns.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodThrows.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodTypeParam.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/NestedTypes.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/NewObjects.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/ReferenceInfoUtil.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/RepeatingTypeAnnotations.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeCasts.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeTests.java ! test/tools/javac/api/EndPositions.java ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/CantAnnotateNestedType.java + test/tools/javac/diags/examples/CantAnnotateStaticClass.java + test/tools/javac/diags/examples/IncorrectReceiverType.java + test/tools/javac/diags/examples/NoAnnotationsOnDotClass.java + test/tools/javac/diags/examples/ThisAsIdentifier.java + test/tools/javac/diags/examples/TypeAnnotationsNotSupported.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/processing/6994946/SemanticErrorTest.2.out ! test/tools/javac/processing/model/element/TestAnonClassNames.java ! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java + test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.ref ! test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.java + test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.ref ! test/tools/javac/tree/TreeKindTest.java ! test/tools/javac/tree/TreePosTest.java + test/tools/javac/treeannotests/AnnoTreeTests.java ! test/tools/javac/treeannotests/TestProcessor.java - test/tools/javac/typeAnnotations/newlocations/BasicTest.java - test/tools/javac/typeAnnotations/newlocations/BasicTest.out + test/tools/javap/typeAnnotations/JSR175Annotations.java + test/tools/javap/typeAnnotations/NewArray.java + test/tools/javap/typeAnnotations/Presence.java + test/tools/javap/typeAnnotations/PresenceInner.java + test/tools/javap/typeAnnotations/T6855990.java + test/tools/javap/typeAnnotations/TypeCasts.java + test/tools/javap/typeAnnotations/Visibility.java + test/tools/javap/typeAnnotations/Wildcards.java Changeset: 09f65aad4759 Author: darcy Date: 2013-01-23 20:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/09f65aad4759 8006264: Add explanation of why default methods cannot be used in JDK 8 javax.lang.model Reviewed-by: jjg ! src/share/classes/javax/lang/model/element/AnnotationValueVisitor.java ! src/share/classes/javax/lang/model/element/ElementVisitor.java ! src/share/classes/javax/lang/model/type/TypeVisitor.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor8.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor8.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor6.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor7.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor8.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor8.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor8.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor8.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor6.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor7.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor8.java Changeset: c2e11e2ec4a3 Author: lana Date: 2013-01-26 19:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c2e11e2ec4a3 Merge - test/tools/javac/annotations/repeatingAnnotations/MissingContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/MissingContainerFor.java - test/tools/javac/annotations/repeatingAnnotations/UseWrongContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/UseWrongContainerFor.java - test/tools/javac/annotations/repeatingAnnotations/WrongContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/WrongContainerFor.java - test/tools/javac/diags/examples/ContainedByDocumentedMismatch.java - test/tools/javac/diags/examples/ContainedByInheritedMismatch.java - test/tools/javac/diags/examples/ContainedByNoValue.java - test/tools/javac/diags/examples/ContainedByNonDefault.java - test/tools/javac/diags/examples/ContainedByRetentionMismatch.java - test/tools/javac/diags/examples/ContainedByTargetMismatch.java - test/tools/javac/diags/examples/ContainedByWrongValueType.java - test/tools/javac/diags/examples/InferredDoNotConformToLower.java - test/tools/javac/diags/examples/NoUniqueMaximalInstance.java - test/tools/javac/diags/examples/WrongContainedBy.java - test/tools/javac/diags/examples/WrongContainerFor.java - test/tools/javac/lambda/MethodReference26.out - test/tools/javac/lambda/TargetType06.out - test/tools/javac/lambda/TargetType11.out - test/tools/javac/lambda/TargetType45.out - test/tools/javac/lambda/VoidCompatibility.out - test/tools/javac/typeAnnotations/newlocations/BasicTest.java - test/tools/javac/typeAnnotations/newlocations/BasicTest.out Changeset: 716935fec613 Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/716935fec613 Added tag jdk8-b75 for changeset c2e11e2ec4a3 ! .hgtags From david.holmes at oracle.com Fri Feb 1 03:32:25 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Feb 2013 21:32:25 +1000 Subject: RFR(XXS): 8007312: Signal Dispatcher thread to start and register ctrl-break handler before TRACE_INITIALIZE In-Reply-To: <9fa18ccc-b229-47c0-b7e6-5b988903c1b6@default> References: <092ccf0f-36a6-4e5b-aa73-e06bff290585@default> <510B48A6.7060500@oracle.com> <9fa18ccc-b229-47c0-b7e6-5b988903c1b6@default> Message-ID: <510BA7C9.1020000@oracle.com> Hi Markus, I appreciate the change of approach. Can we not check if the initialization has occurred and so keep the assert where it already exists eg: void os::signal_notify(int signal_number) { BOOL ret; + if (sig_sem != NULL) { Atomic::inc(&pending_signals[signal_number]); ret = ::ReleaseSemaphore(sig_sem, 1, NULL); assert(ret != 0, "ReleaseSemaphore() failed"); + } } ? That said I'm unclear how on Solaris we get into this code. You said on Windows the C runtime fault handler causes things to get directed back to UserHandler. But on linux/Solaris I did not expect any VM handler to be installed at this point so the default signal response would occur - to kill the process. The shared code does this at the end of os::signal_init() os::signal(SIGBREAK, os::user_handler()) So I'm not sure how we end up in UserHandler() ?? David On 1/02/2013 6:20 PM, Markus Gr?nlund wrote: > Hi David, > > Many thanks for your input. > > I do acknowledge the startup sequence is fragile, and this is quite tricky business - you raise good points. > > From what I can read/test/trace, we are ready to start up the Signal Dispatcher Java thread at an earlier point (technically from a VM perspective), but as you say, this is mainly based on the best (worst?) theoretical case (and a bit of hands on a few different platforms) - in addition, if we take into account what expectations current testing has in this area (which I am unsure of at this point), there is now a change introduced between JVMTI_EVENT_VM_START and JVMTI_EVENT_JVMTI_PHASE_LIVE - and who knows what kind of test issues this might be causing...could be found out, but with a lot of effort... > > I see that the only OS:s where the correct behavior is actually checked are Solaris and Windows (asserts). > > I think we need the first stage TRACE_INITIALIZE before set_init_completed() and JVMTI_EVENT_JVMTI_PHASE_LIVE (don't remember the actual rationale off the top of my head), but I can verify if it can move later... > > Since this is a very hard area to get right, as you say, there will always be window where this is always an issue...I was considering a more pragmatic means just to resolve this particular issue in a somewhat timely manner (even though it's not my preferred choice): > > If we lax up (remove) the asserts os::signal_notify() on the return from semaphore signaling (sema_post() solaris and ReleaseSemaphore() windows), this should cease being an issue (we then get the same behavior as PRODUCT builds for non-product builds (do nothing)). ( btw it's not an error to close a NULL handle on Windows, but if you do it in debug mode you get told about it). > > I never like removing asserts however, but this seems like a feasible (time/effort/risk) resolution to this problem. > > Appreciate your comments as always, let me know what you think of this. > > Cheers > Markus > > > > > > -----Original Message----- > From: David Holmes > Sent: den 1 februari 2013 05:47 > To: Markus Gr?nlund > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR(XXS): 8007312: Signal Dispatcher thread to start and register ctrl-break handler before TRACE_INITIALIZE > > Hi Markus, > > I understand that there is a bug if ctrl-C is pressed before we have initalized the signal handler. I also realize that normally the chance of hitting that window is negligible, but with TRACE_INITIALIZE active the window becomes much larger. > > But as I wrote in the bug report the VM initialization sequence is very fragile and changes to it have to be made with great care. Basic tests only test the normal startup path. Problems arise where we use specific VM flags (eg tracing) with specific VM services (specific GC) and even a specific VM (fastdebug). > > In this case I can't convince myself it is safe for the ctrl-C handler to be setup at this earlier point in time. We are still in the initialization phase of the VM and the handler code has to make Java calls to create and start a Java signal handling thread. Are we ready to execute that Java code at this point in time - before set_init_completed()? What might go wrong? What if the Java code hits an exception? > > Can you test your fix by adding a sleep after os::signal_init and sending ctrl-C? > > Can you emulate this problem on Linux/Solaris by adding a sleep before the original os::signal_init() ? Does it crash there too, or is this a problem limited to Windows? If so the fix should be limited to Windows. > > Can you consider moving TRACE_INITIALIZE instead? > > Thanks, > David > > On 1/02/2013 7:22 AM, Markus Gr?nlund wrote: >> Greetings, >> >> >> >> Can I kindly ask for a few reviews and a putback sponsorship for the following change: >> >> >> >> Bugid: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007312 >> >> Webrev: http://cr.openjdk.java.net/~mgronlun/8007312/webrev01/ >> >> Hotspot JPRT builds/tests : completed successfully >> >> >> >> Comment on issue/fix: >> >> >> >> (windows analysis) >> >> >> >> Pressing ctrl-c before Hotspot signal/console handler has been registered actually asserts/stops the VM (which to the user appears like a crash) on non-product builds. >> >> >> >> Before Hotspot registers its own jvm!consoleHandler with kernel32!CtrlRoutine, the C runtime default msvcr100!ctrlevent_capture is implicitly used - this calls back into jvm!UserHandler, which forwards into os::signal_notify() which uses uninitialized variables. >> >> >> >> // on Windows this creates the following issue when closing a NULL >> handle to a semaphore >> >> >> >> void os::signal_notify(int signal_number) { >> >> BOOL ret; >> >> >> >> Atomic::inc(&pending_signals[signal_number]); >> >> ret = ::ReleaseSemaphore(sig_sem, 1, NULL);<<--- call >> ReleaseSemaphore on global handle sig_sem which has not been >> setup/created yet == is NULL (is created in os::signal_init_pd()) >> >> assert(ret != 0, "ReleaseSemaphore() failed");<<-- assert traps >> here (GetLastError() == 0xc0000008 - An invalid HANDLE was specified) >> >> >> >> } >> >> >> >> The short initial tests I have done locally so far on moving the signal handler registration earlier as suggested in this patch makes it very hard to issue crtl-c before Hotspot signal handler has been setup. >> >> >> >> Thanks >> >> Markus From markus.gronlund at oracle.com Fri Feb 1 03:56:51 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Fri, 1 Feb 2013 03:56:51 -0800 (PST) Subject: RFR(XXS): 8007312: Signal Dispatcher thread to start and register ctrl-break handler before TRACE_INITIALIZE In-Reply-To: <510BA7C9.1020000@oracle.com> References: <092ccf0f-36a6-4e5b-aa73-e06bff290585@default> <510B48A6.7060500@oracle.com> <9fa18ccc-b229-47c0-b7e6-5b988903c1b6@default> <510BA7C9.1020000@oracle.com> Message-ID: <513992b6-653b-4c3a-a605-73a8db5b8d8f@default> Thanks David. Inline. -----Original Message----- From: David Holmes Sent: den 1 februari 2013 12:32 To: Markus Gr?nlund Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR(XXS): 8007312: Signal Dispatcher thread to start and register ctrl-break handler before TRACE_INITIALIZE Hi Markus, I appreciate the change of approach. Can we not check if the initialization has occurred and so keep the assert where it already exists eg: void os::signal_notify(int signal_number) { BOOL ret; + if (sig_sem != NULL) { Atomic::inc(&pending_signals[signal_number]); ret = ::ReleaseSemaphore(sig_sem, 1, NULL); assert(ret != 0, "ReleaseSemaphore() failed"); + } } [MG] We could absolutely do this for Windows (a handle NULL check is easy to do). More unsure how to validate an eventual uninitialized semaphore of the assert for Solaris though where I would need more state tracking to keep track of the initialization state of the sema_t. That said, I am not even sure this is a real issue on Solaris, because I haven't been able to test with a debug build there yet. Let's take Solaris as a separate step, and resolve the Windows issue first. That said I'm unclear how on Solaris we get into this code. You said on Windows the C runtime fault handler causes things to get directed back to UserHandler. But on linux/Solaris I did not expect any VM handler to be installed at this point so the default signal response would occur - to kill the process. The shared code does this at the end of os::signal_init() os::signal(SIGBREAK, os::user_handler()) So I'm not sure how we end up in UserHandler() ?? [MG] You put your finger on the spot here - this is actually my main confusion at this point as well (and I agree with you description, I wonder how we can ever end up in UserHandler() even though we haven't called SetConsoleCtrlHandler() on it....apparently its registered: 04a4fdd0 07b2242c 00000002 04a4fe18 7851afbb jvm!os::signal_notify+0x4 [d:\hotspot_src\hsx\24\hotspot_31_jan\src\os\windows\vm\os_windows.cpp @ 1961] 04a4fddc 7851afbb 00000002 a0bf8b55 00000000 jvm!UserHandler+0xc [d:\hotspot_src\hsx\24\hotspot_31_jan\src\os\windows\vm\os_windows.cpp @ 1845] 04a4fe18 764ae3d8 00000000 aa5b288e 00000000 msvcr100!ctrlevent_capture+0x90 [f:\dd\vctools\crt_bld\self_x86\crt\src\winsig.c @ 130] <<-- get the C Runtime default ctrlevent_capture to call us back (I guess this is normal linked list of signal handlers passing down), but our callback has not been setup up proper yet? At least not from the VM. I 04a4fea4 7647ed6c 00000000 04a4fef0 7793377b kernel32!CtrlRoutine+0x126 04a4feb0 7793377b 00000000 769482db 00000000 kernel32!BaseThreadInitThunk+0xe 04a4fef0 7793374e 76494a03 00000000 00000000 ntdll!__RtlUserThreadStart+0x70 04a4ff08 00000000 76494a03 00000000 00000000 ntdll!_RtlUserThreadStart+0x1b I only find a single call to SetConsoleCtrlHandler() but that does not register UserHandler(), it registers consoleHandler() Unless...maybe the java.exe launcher is doing some signal registration here? But how would it be possible to register a callback in the jvm.dll? hmm...Very interesting, I'm going to find out.. stay tuned... Cheers Markus David On 1/02/2013 6:20 PM, Markus Gr?nlund wrote: > Hi David, > > Many thanks for your input. > > I do acknowledge the startup sequence is fragile, and this is quite tricky business - you raise good points. > > From what I can read/test/trace, we are ready to start up the Signal Dispatcher Java thread at an earlier point (technically from a VM perspective), but as you say, this is mainly based on the best (worst?) theoretical case (and a bit of hands on a few different platforms) - in addition, if we take into account what expectations current testing has in this area (which I am unsure of at this point), there is now a change introduced between JVMTI_EVENT_VM_START and JVMTI_EVENT_JVMTI_PHASE_LIVE - and who knows what kind of test issues this might be causing...could be found out, but with a lot of effort... > > I see that the only OS:s where the correct behavior is actually checked are Solaris and Windows (asserts). > > I think we need the first stage TRACE_INITIALIZE before set_init_completed() and JVMTI_EVENT_JVMTI_PHASE_LIVE (don't remember the actual rationale off the top of my head), but I can verify if it can move later... > > Since this is a very hard area to get right, as you say, there will always be window where this is always an issue...I was considering a more pragmatic means just to resolve this particular issue in a somewhat timely manner (even though it's not my preferred choice): > > If we lax up (remove) the asserts os::signal_notify() on the return from semaphore signaling (sema_post() solaris and ReleaseSemaphore() windows), this should cease being an issue (we then get the same behavior as PRODUCT builds for non-product builds (do nothing)). ( btw it's not an error to close a NULL handle on Windows, but if you do it in debug mode you get told about it). > > I never like removing asserts however, but this seems like a feasible (time/effort/risk) resolution to this problem. > > Appreciate your comments as always, let me know what you think of this. > > Cheers > Markus > > > > > > -----Original Message----- > From: David Holmes > Sent: den 1 februari 2013 05:47 > To: Markus Gr?nlund > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR(XXS): 8007312: Signal Dispatcher thread to start and > register ctrl-break handler before TRACE_INITIALIZE > > Hi Markus, > > I understand that there is a bug if ctrl-C is pressed before we have initalized the signal handler. I also realize that normally the chance of hitting that window is negligible, but with TRACE_INITIALIZE active the window becomes much larger. > > But as I wrote in the bug report the VM initialization sequence is very fragile and changes to it have to be made with great care. Basic tests only test the normal startup path. Problems arise where we use specific VM flags (eg tracing) with specific VM services (specific GC) and even a specific VM (fastdebug). > > In this case I can't convince myself it is safe for the ctrl-C handler to be setup at this earlier point in time. We are still in the initialization phase of the VM and the handler code has to make Java calls to create and start a Java signal handling thread. Are we ready to execute that Java code at this point in time - before set_init_completed()? What might go wrong? What if the Java code hits an exception? > > Can you test your fix by adding a sleep after os::signal_init and sending ctrl-C? > > Can you emulate this problem on Linux/Solaris by adding a sleep before the original os::signal_init() ? Does it crash there too, or is this a problem limited to Windows? If so the fix should be limited to Windows. > > Can you consider moving TRACE_INITIALIZE instead? > > Thanks, > David > > On 1/02/2013 7:22 AM, Markus Gr?nlund wrote: >> Greetings, >> >> >> >> Can I kindly ask for a few reviews and a putback sponsorship for the following change: >> >> >> >> Bugid: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007312 >> >> Webrev: http://cr.openjdk.java.net/~mgronlun/8007312/webrev01/ >> >> Hotspot JPRT builds/tests : completed successfully >> >> >> >> Comment on issue/fix: >> >> >> >> (windows analysis) >> >> >> >> Pressing ctrl-c before Hotspot signal/console handler has been registered actually asserts/stops the VM (which to the user appears like a crash) on non-product builds. >> >> >> >> Before Hotspot registers its own jvm!consoleHandler with kernel32!CtrlRoutine, the C runtime default msvcr100!ctrlevent_capture is implicitly used - this calls back into jvm!UserHandler, which forwards into os::signal_notify() which uses uninitialized variables. >> >> >> >> // on Windows this creates the following issue when closing a NULL >> handle to a semaphore >> >> >> >> void os::signal_notify(int signal_number) { >> >> BOOL ret; >> >> >> >> Atomic::inc(&pending_signals[signal_number]); >> >> ret = ::ReleaseSemaphore(sig_sem, 1, NULL);<<--- call >> ReleaseSemaphore on global handle sig_sem which has not been >> setup/created yet == is NULL (is created in os::signal_init_pd()) >> >> assert(ret != 0, "ReleaseSemaphore() failed");<<-- assert traps >> here (GetLastError() == 0xc0000008 - An invalid HANDLE was specified) >> >> >> >> } >> >> >> >> The short initial tests I have done locally so far on moving the signal handler registration earlier as suggested in this patch makes it very hard to issue crtl-c before Hotspot signal handler has been setup. >> >> >> >> Thanks >> >> Markus From david.holmes at oracle.com Fri Feb 1 04:03:54 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Feb 2013 22:03:54 +1000 Subject: RFR(XXS): 8007312: Signal Dispatcher thread to start and register ctrl-break handler before TRACE_INITIALIZE In-Reply-To: <513992b6-653b-4c3a-a605-73a8db5b8d8f@default> References: <092ccf0f-36a6-4e5b-aa73-e06bff290585@default> <510B48A6.7060500@oracle.com> <9fa18ccc-b229-47c0-b7e6-5b988903c1b6@default> <510BA7C9.1020000@oracle.com> <513992b6-653b-4c3a-a605-73a8db5b8d8f@default> Message-ID: <510BAF2A.4080502@oracle.com> I think java.lang.Terminator installs the handler sometime during class library initialization. This in itself seems wrong, if that is happening before the VM has initialized the signal handling subsystem. David On 1/02/2013 9:56 PM, Markus Gr?nlund wrote: > Thanks David. Inline. > > -----Original Message----- > From: David Holmes > Sent: den 1 februari 2013 12:32 > To: Markus Gr?nlund > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR(XXS): 8007312: Signal Dispatcher thread to start and register ctrl-break handler before TRACE_INITIALIZE > > Hi Markus, > > I appreciate the change of approach. Can we not check if the initialization has occurred and so keep the assert where it already exists eg: > > void os::signal_notify(int signal_number) { > BOOL ret; > + if (sig_sem != NULL) { > Atomic::inc(&pending_signals[signal_number]); > ret = ::ReleaseSemaphore(sig_sem, 1, NULL); > assert(ret != 0, "ReleaseSemaphore() failed"); > + } > } > [MG] > We could absolutely do this for Windows (a handle NULL check is easy to do). More unsure how to validate an eventual uninitialized semaphore of the assert for Solaris though where I would need more state tracking to keep track of the initialization state of the sema_t. That said, I am not even sure this is a real issue on Solaris, because I haven't been able to test with a debug build there yet. Let's take Solaris as a separate step, and resolve the Windows issue first. > > That said I'm unclear how on Solaris we get into this code. You said on Windows the C runtime fault handler causes things to get directed back to UserHandler. But on linux/Solaris I did not expect any VM handler to be installed at this point so the default signal response would occur - to kill the process. The shared code does this at the end of > os::signal_init() > > os::signal(SIGBREAK, os::user_handler()) > > So I'm not sure how we end up in UserHandler() ?? > [MG] > You put your finger on the spot here - this is actually my main confusion at this point as well (and I agree with you description, I wonder how we can ever end up in UserHandler() even though we haven't called SetConsoleCtrlHandler() on it....apparently its registered: > > 04a4fdd0 07b2242c 00000002 04a4fe18 7851afbb jvm!os::signal_notify+0x4 [d:\hotspot_src\hsx\24\hotspot_31_jan\src\os\windows\vm\os_windows.cpp @ 1961] > 04a4fddc 7851afbb 00000002 a0bf8b55 00000000 jvm!UserHandler+0xc [d:\hotspot_src\hsx\24\hotspot_31_jan\src\os\windows\vm\os_windows.cpp @ 1845] > 04a4fe18 764ae3d8 00000000 aa5b288e 00000000 msvcr100!ctrlevent_capture+0x90 [f:\dd\vctools\crt_bld\self_x86\crt\src\winsig.c @ 130]<<-- get the C Runtime default ctrlevent_capture to call us back (I guess this is normal linked list of signal handlers passing down), but our callback has not been setup up proper yet? At least not from the VM. I > > 04a4fea4 7647ed6c 00000000 04a4fef0 7793377b kernel32!CtrlRoutine+0x126 > 04a4feb0 7793377b 00000000 769482db 00000000 kernel32!BaseThreadInitThunk+0xe > 04a4fef0 7793374e 76494a03 00000000 00000000 ntdll!__RtlUserThreadStart+0x70 > 04a4ff08 00000000 76494a03 00000000 00000000 ntdll!_RtlUserThreadStart+0x1b > > I only find a single call to SetConsoleCtrlHandler() but that does not register UserHandler(), it registers consoleHandler() > > Unless...maybe the java.exe launcher is doing some signal registration here? But how would it be possible to register a callback in the jvm.dll? hmm...Very interesting, I'm going to find out.. stay tuned... > > Cheers > Markus > > David > > On 1/02/2013 6:20 PM, Markus Gr?nlund wrote: >> Hi David, >> >> Many thanks for your input. >> >> I do acknowledge the startup sequence is fragile, and this is quite tricky business - you raise good points. >> >> From what I can read/test/trace, we are ready to start up the Signal Dispatcher Java thread at an earlier point (technically from a VM perspective), but as you say, this is mainly based on the best (worst?) theoretical case (and a bit of hands on a few different platforms) - in addition, if we take into account what expectations current testing has in this area (which I am unsure of at this point), there is now a change introduced between JVMTI_EVENT_VM_START and JVMTI_EVENT_JVMTI_PHASE_LIVE - and who knows what kind of test issues this might be causing...could be found out, but with a lot of effort... >> >> I see that the only OS:s where the correct behavior is actually checked are Solaris and Windows (asserts). >> >> I think we need the first stage TRACE_INITIALIZE before set_init_completed() and JVMTI_EVENT_JVMTI_PHASE_LIVE (don't remember the actual rationale off the top of my head), but I can verify if it can move later... >> >> Since this is a very hard area to get right, as you say, there will always be window where this is always an issue...I was considering a more pragmatic means just to resolve this particular issue in a somewhat timely manner (even though it's not my preferred choice): >> >> If we lax up (remove) the asserts os::signal_notify() on the return from semaphore signaling (sema_post() solaris and ReleaseSemaphore() windows), this should cease being an issue (we then get the same behavior as PRODUCT builds for non-product builds (do nothing)). ( btw it's not an error to close a NULL handle on Windows, but if you do it in debug mode you get told about it). >> >> I never like removing asserts however, but this seems like a feasible (time/effort/risk) resolution to this problem. >> >> Appreciate your comments as always, let me know what you think of this. >> >> Cheers >> Markus >> >> >> >> >> >> -----Original Message----- >> From: David Holmes >> Sent: den 1 februari 2013 05:47 >> To: Markus Gr?nlund >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: RFR(XXS): 8007312: Signal Dispatcher thread to start and >> register ctrl-break handler before TRACE_INITIALIZE >> >> Hi Markus, >> >> I understand that there is a bug if ctrl-C is pressed before we have initalized the signal handler. I also realize that normally the chance of hitting that window is negligible, but with TRACE_INITIALIZE active the window becomes much larger. >> >> But as I wrote in the bug report the VM initialization sequence is very fragile and changes to it have to be made with great care. Basic tests only test the normal startup path. Problems arise where we use specific VM flags (eg tracing) with specific VM services (specific GC) and even a specific VM (fastdebug). >> >> In this case I can't convince myself it is safe for the ctrl-C handler to be setup at this earlier point in time. We are still in the initialization phase of the VM and the handler code has to make Java calls to create and start a Java signal handling thread. Are we ready to execute that Java code at this point in time - before set_init_completed()? What might go wrong? What if the Java code hits an exception? >> >> Can you test your fix by adding a sleep after os::signal_init and sending ctrl-C? >> >> Can you emulate this problem on Linux/Solaris by adding a sleep before the original os::signal_init() ? Does it crash there too, or is this a problem limited to Windows? If so the fix should be limited to Windows. >> >> Can you consider moving TRACE_INITIALIZE instead? >> >> Thanks, >> David >> >> On 1/02/2013 7:22 AM, Markus Gr?nlund wrote: >>> Greetings, >>> >>> >>> >>> Can I kindly ask for a few reviews and a putback sponsorship for the following change: >>> >>> >>> >>> Bugid: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007312 >>> >>> Webrev: http://cr.openjdk.java.net/~mgronlun/8007312/webrev01/ >>> >>> Hotspot JPRT builds/tests : completed successfully >>> >>> >>> >>> Comment on issue/fix: >>> >>> >>> >>> (windows analysis) >>> >>> >>> >>> Pressing ctrl-c before Hotspot signal/console handler has been registered actually asserts/stops the VM (which to the user appears like a crash) on non-product builds. >>> >>> >>> >>> Before Hotspot registers its own jvm!consoleHandler with kernel32!CtrlRoutine, the C runtime default msvcr100!ctrlevent_capture is implicitly used - this calls back into jvm!UserHandler, which forwards into os::signal_notify() which uses uninitialized variables. >>> >>> >>> >>> // on Windows this creates the following issue when closing a NULL >>> handle to a semaphore >>> >>> >>> >>> void os::signal_notify(int signal_number) { >>> >>> BOOL ret; >>> >>> >>> >>> Atomic::inc(&pending_signals[signal_number]); >>> >>> ret = ::ReleaseSemaphore(sig_sem, 1, NULL);<<--- call >>> ReleaseSemaphore on global handle sig_sem which has not been >>> setup/created yet == is NULL (is created in os::signal_init_pd()) >>> >>> assert(ret != 0, "ReleaseSemaphore() failed");<<-- assert traps >>> here (GetLastError() == 0xc0000008 - An invalid HANDLE was specified) >>> >>> >>> >>> } >>> >>> >>> >>> The short initial tests I have done locally so far on moving the signal handler registration earlier as suggested in this patch makes it very hard to issue crtl-c before Hotspot signal handler has been setup. >>> >>> >>> >>> Thanks >>> >>> Markus From markus.gronlund at oracle.com Fri Feb 1 04:27:50 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Fri, 1 Feb 2013 04:27:50 -0800 (PST) Subject: RFR(XXS): 8007312: Signal Dispatcher thread to start and register ctrl-break handler before TRACE_INITIALIZE In-Reply-To: <510BAF2A.4080502@oracle.com> References: <092ccf0f-36a6-4e5b-aa73-e06bff290585@default> <510B48A6.7060500@oracle.com> <9fa18ccc-b229-47c0-b7e6-5b988903c1b6@default> <510BA7C9.1020000@oracle.com> <513992b6-653b-4c3a-a605-73a8db5b8d8f@default> <510BAF2A.4080502@oracle.com> Message-ID: <0198a899-c8a8-4fa0-8232-bd2464be599e@default> David, 0171f3a0 56bdb160 56bdaf2b 00000001 3dd4dde1 kernel32!SetConsoleCtrlHandler 0171f3e0 074b248c 00000002 074b2420 00000000 msvcr100!signal+0x125 [f:\dd\vctools\crt_bld\self_x86\crt\src\winsig.c @ 256] 0171f3f4 074af2a7 00000002 074b2420 00000000 jvm!os::signal+0x3c [d:\hotspot_src\hsx\24\hotspot_31_jan\src\os\windows\vm\os_windows.cpp @ 1860] 0171f44c 6a0b4748 00000002 00000002 0193de46 jvm!JVM_RegisterSignal+0x1b7 [d:\hotspot_src\hsx\24\hotspot_31_jan\src\os\windows\vm\jvm_windows.cpp @ 68] WARNING: Stack unwind information not available. Following frames may be wrong. 0171f58c 078f860d 0171f5ec 0171f760 0000000a java_6a0b0000!Java_sun_misc_Signal_handle0+0xd 0171f630 074bb2ef 0171f758 0171f6a0 0171f6f0 jvm!JavaCalls::call_helper+0x3dd [d:\hotspot_src\hsx\24\hotspot_31_jan\src\share\vm\runtime\javacalls.cpp @ 415] 0171f678 078f8222 078f8230 0171f758 0171f6a0 jvm!os::os_exception_wrapper+0x9f [d:\hotspot_src\hsx\24\hotspot_31_jan\src\os_cpu\windows_x86\vm\os_windows_x86.cpp @ 113] 0171f694 078f80db 0171f758 0173f6d0 0171f6f0 jvm!JavaCalls::call+0x52 [d:\hotspot_src\hsx\24\hotspot_31_jan\src\share\vm\runtime\javacalls.cpp @ 320] 0171f6d0 078f811b 0171f758 0173f6d4 05fa6aa8 jvm!JavaCalls::call_static+0x9b [d:\hotspot_src\hsx\24\hotspot_31_jan\src\share\vm\runtime\javacalls.cpp @ 286] 0171f738 07936ccb 0171f758 0173f6cc 05fa6aa8 jvm!JavaCalls::call_static+0x2b [d:\hotspot_src\hsx\24\hotspot_31_jan\src\share\vm\runtime\javacalls.cpp @ 292] 0171f770 079361bd 0173ec00 7ffde000 77d37894 jvm!call_initializeSystemClass+0x6b [d:\hotspot_src\hsx\24\hotspot_31_jan\src\share\vm\runtime\thread.cpp @ 1022] 0171f974 0785232f 0171f9d4 0171f9bb 00000000 jvm!Threads::create_vm+0xcdd [d:\hotspot_src\hsx\24\hotspot_31_jan\src\share\vm\runtime\thread.cpp @ 3497] 0171f9bc 011713c1 0171fa28 0171fa34 0171f9d4 jvm!JNI_CreateJavaVM+0x7f [d:\hotspot_src\hsx\24\hotspot_31_jan\src\share\vm\prims\jni.cpp @ 5134] Registration of UserHandler() actually comes in as an effect of call_initializeSystemClass() during VM startup... I agree this seems wrong as we are not ready at this point. /Markus -----Original Message----- From: David Holmes Sent: den 1 februari 2013 13:04 To: Markus Gr?nlund Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR(XXS): 8007312: Signal Dispatcher thread to start and register ctrl-break handler before TRACE_INITIALIZE I think java.lang.Terminator installs the handler sometime during class library initialization. This in itself seems wrong, if that is happening before the VM has initialized the signal handling subsystem. David On 1/02/2013 9:56 PM, Markus Gr?nlund wrote: > Thanks David. Inline. > > -----Original Message----- > From: David Holmes > Sent: den 1 februari 2013 12:32 > To: Markus Gr?nlund > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR(XXS): 8007312: Signal Dispatcher thread to start and > register ctrl-break handler before TRACE_INITIALIZE > > Hi Markus, > > I appreciate the change of approach. Can we not check if the initialization has occurred and so keep the assert where it already exists eg: > > void os::signal_notify(int signal_number) { > BOOL ret; > + if (sig_sem != NULL) { > Atomic::inc(&pending_signals[signal_number]); > ret = ::ReleaseSemaphore(sig_sem, 1, NULL); > assert(ret != 0, "ReleaseSemaphore() failed"); > + } > } > [MG] > We could absolutely do this for Windows (a handle NULL check is easy to do). More unsure how to validate an eventual uninitialized semaphore of the assert for Solaris though where I would need more state tracking to keep track of the initialization state of the sema_t. That said, I am not even sure this is a real issue on Solaris, because I haven't been able to test with a debug build there yet. Let's take Solaris as a separate step, and resolve the Windows issue first. > > That said I'm unclear how on Solaris we get into this code. You said > on Windows the C runtime fault handler causes things to get directed > back to UserHandler. But on linux/Solaris I did not expect any VM > handler to be installed at this point so the default signal response > would occur - to kill the process. The shared code does this at the > end of > os::signal_init() > > os::signal(SIGBREAK, os::user_handler()) > > So I'm not sure how we end up in UserHandler() ?? > [MG] > You put your finger on the spot here - this is actually my main confusion at this point as well (and I agree with you description, I wonder how we can ever end up in UserHandler() even though we haven't called SetConsoleCtrlHandler() on it....apparently its registered: > > 04a4fdd0 07b2242c 00000002 04a4fe18 7851afbb jvm!os::signal_notify+0x4 > [d:\hotspot_src\hsx\24\hotspot_31_jan\src\os\windows\vm\os_windows.cpp > @ 1961] 04a4fddc 7851afbb 00000002 a0bf8b55 00000000 > jvm!UserHandler+0xc > [d:\hotspot_src\hsx\24\hotspot_31_jan\src\os\windows\vm\os_windows.cpp > @ 1845] > 04a4fe18 764ae3d8 00000000 aa5b288e 00000000 > msvcr100!ctrlevent_capture+0x90 > [f:\dd\vctools\crt_bld\self_x86\crt\src\winsig.c @ 130]<<-- get the C > Runtime default ctrlevent_capture to call us back (I guess this is > normal linked list of signal handlers passing down), but our callback > has not been setup up proper yet? At least not from the VM. I > > 04a4fea4 7647ed6c 00000000 04a4fef0 7793377b > kernel32!CtrlRoutine+0x126 > 04a4feb0 7793377b 00000000 769482db 00000000 > kernel32!BaseThreadInitThunk+0xe > 04a4fef0 7793374e 76494a03 00000000 00000000 > ntdll!__RtlUserThreadStart+0x70 > 04a4ff08 00000000 76494a03 00000000 00000000 > ntdll!_RtlUserThreadStart+0x1b > > I only find a single call to SetConsoleCtrlHandler() but that does not > register UserHandler(), it registers consoleHandler() > > Unless...maybe the java.exe launcher is doing some signal registration here? But how would it be possible to register a callback in the jvm.dll? hmm...Very interesting, I'm going to find out.. stay tuned... > > Cheers > Markus > > David > > On 1/02/2013 6:20 PM, Markus Gr?nlund wrote: >> Hi David, >> >> Many thanks for your input. >> >> I do acknowledge the startup sequence is fragile, and this is quite tricky business - you raise good points. >> >> From what I can read/test/trace, we are ready to start up the Signal Dispatcher Java thread at an earlier point (technically from a VM perspective), but as you say, this is mainly based on the best (worst?) theoretical case (and a bit of hands on a few different platforms) - in addition, if we take into account what expectations current testing has in this area (which I am unsure of at this point), there is now a change introduced between JVMTI_EVENT_VM_START and JVMTI_EVENT_JVMTI_PHASE_LIVE - and who knows what kind of test issues this might be causing...could be found out, but with a lot of effort... >> >> I see that the only OS:s where the correct behavior is actually checked are Solaris and Windows (asserts). >> >> I think we need the first stage TRACE_INITIALIZE before set_init_completed() and JVMTI_EVENT_JVMTI_PHASE_LIVE (don't remember the actual rationale off the top of my head), but I can verify if it can move later... >> >> Since this is a very hard area to get right, as you say, there will always be window where this is always an issue...I was considering a more pragmatic means just to resolve this particular issue in a somewhat timely manner (even though it's not my preferred choice): >> >> If we lax up (remove) the asserts os::signal_notify() on the return from semaphore signaling (sema_post() solaris and ReleaseSemaphore() windows), this should cease being an issue (we then get the same behavior as PRODUCT builds for non-product builds (do nothing)). ( btw it's not an error to close a NULL handle on Windows, but if you do it in debug mode you get told about it). >> >> I never like removing asserts however, but this seems like a feasible (time/effort/risk) resolution to this problem. >> >> Appreciate your comments as always, let me know what you think of this. >> >> Cheers >> Markus >> >> >> >> >> >> -----Original Message----- >> From: David Holmes >> Sent: den 1 februari 2013 05:47 >> To: Markus Gr?nlund >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: RFR(XXS): 8007312: Signal Dispatcher thread to start and >> register ctrl-break handler before TRACE_INITIALIZE >> >> Hi Markus, >> >> I understand that there is a bug if ctrl-C is pressed before we have initalized the signal handler. I also realize that normally the chance of hitting that window is negligible, but with TRACE_INITIALIZE active the window becomes much larger. >> >> But as I wrote in the bug report the VM initialization sequence is very fragile and changes to it have to be made with great care. Basic tests only test the normal startup path. Problems arise where we use specific VM flags (eg tracing) with specific VM services (specific GC) and even a specific VM (fastdebug). >> >> In this case I can't convince myself it is safe for the ctrl-C handler to be setup at this earlier point in time. We are still in the initialization phase of the VM and the handler code has to make Java calls to create and start a Java signal handling thread. Are we ready to execute that Java code at this point in time - before set_init_completed()? What might go wrong? What if the Java code hits an exception? >> >> Can you test your fix by adding a sleep after os::signal_init and sending ctrl-C? >> >> Can you emulate this problem on Linux/Solaris by adding a sleep before the original os::signal_init() ? Does it crash there too, or is this a problem limited to Windows? If so the fix should be limited to Windows. >> >> Can you consider moving TRACE_INITIALIZE instead? >> >> Thanks, >> David >> >> On 1/02/2013 7:22 AM, Markus Gr?nlund wrote: >>> Greetings, >>> >>> >>> >>> Can I kindly ask for a few reviews and a putback sponsorship for the following change: >>> >>> >>> >>> Bugid: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007312 >>> >>> Webrev: http://cr.openjdk.java.net/~mgronlun/8007312/webrev01/ >>> >>> Hotspot JPRT builds/tests : completed successfully >>> >>> >>> >>> Comment on issue/fix: >>> >>> >>> >>> (windows analysis) >>> >>> >>> >>> Pressing ctrl-c before Hotspot signal/console handler has been registered actually asserts/stops the VM (which to the user appears like a crash) on non-product builds. >>> >>> >>> >>> Before Hotspot registers its own jvm!consoleHandler with kernel32!CtrlRoutine, the C runtime default msvcr100!ctrlevent_capture is implicitly used - this calls back into jvm!UserHandler, which forwards into os::signal_notify() which uses uninitialized variables. >>> >>> >>> >>> // on Windows this creates the following issue when closing a NULL >>> handle to a semaphore >>> >>> >>> >>> void os::signal_notify(int signal_number) { >>> >>> BOOL ret; >>> >>> >>> >>> Atomic::inc(&pending_signals[signal_number]); >>> >>> ret = ::ReleaseSemaphore(sig_sem, 1, NULL);<<--- call >>> ReleaseSemaphore on global handle sig_sem which has not been >>> setup/created yet == is NULL (is created in os::signal_init_pd()) >>> >>> assert(ret != 0, "ReleaseSemaphore() failed");<<-- assert traps >>> here (GetLastError() == 0xc0000008 - An invalid HANDLE was >>> specified) >>> >>> >>> >>> } >>> >>> >>> >>> The short initial tests I have done locally so far on moving the signal handler registration earlier as suggested in this patch makes it very hard to issue crtl-c before Hotspot signal handler has been setup. >>> >>> >>> >>> Thanks >>> >>> Markus From oehrstroem at gmail.com Fri Feb 1 04:58:56 2013 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Fri, 1 Feb 2013 13:58:56 +0100 Subject: This simple patch doubles the compile-speed of the hotspot repo on Windows Message-ID: ie. use /MP on the cl.exe command line. On the build machine (Windows Server 2007, Visual Studio 2010, 32 HT cores, 64GB ram) configuring with: sh configure --enable-sjavac --with-freetype=/cygdrive/d/tools/freetype-amd64 --with-boot-jdk=/cygdrive/d/java/jdk-7-fcs-bin-b147/ (You need to patch src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java line 256, change equals("windows)" to startswith("windows), this fix is going into tl soon.) Without MP ----- Build times ------- Start 2013-02-01 12:23:50 End 2013-02-01 12:35:20 00:00:32 corba 00:04:43 hotspot 00:00:15 jaxp 00:00:24 jaxws 00:04:49 jdk 00:00:46 langtools 00:11:30 TOTAL ------------------------- With MP ----- Build times ------- Start 2013-02-01 12:54:54 End 2013-02-01 13:03:56 00:00:31 corba 00:02:20 hotspot 00:00:14 jaxp 00:00:22 jaxws 00:04:44 jdk 00:00:46 langtools 00:09:02 TOTAL ------------------------- For such a simple patch it is a nice speedup. Please test and see if it improves the speed on your multi core machines. //Fredrik Oh, and for reference this is the speed without sjavac but with /MP. ----- Build times ------- Start 2013-02-01 13:39:38 End 2013-02-01 13:51:46 00:00:35 corba 00:02:24 hotspot 00:00:28 jaxp 00:00:36 jaxws 00:07:11 jdk 00:00:48 langtools 00:12:08 TOTAL ------------------------- $ hg diff diff -r 67498c863813 make/windows/makefiles/compile.make --- a/make/windows/makefiles/compile.make Thu Jan 17 12:16:06 2013 +0100 +++ b/make/windows/makefiles/compile.make Fri Feb 01 13:05:08 2013 +0100 @@ -44,6 +44,7 @@ # /GS Inserts security stack checks in some functions (VS2005 default) # /Oi Use intrinsics (in /O2) # /Od Disable all optimizations +# /MP Use multiple cores for compilation # # NOTE: Normally following any of the above with a '-' will turn off that flag # @@ -52,7 +53,7 @@ # improving the quality of crash log stack traces involving jvm.dll. # These are always used in all compiles -CXX_FLAGS=/nologo /W3 /WX +CXX_FLAGS=/nologo /W3 /WX /MP # Let's add debug information when Full Debug Symbols is enabled !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" diff -r 67498c863813 make/windows/makefiles/sa.make --- a/make/windows/makefiles/sa.make Thu Jan 17 12:16:06 2013 +0100 +++ b/make/windows/makefiles/sa.make Fri Feb 01 13:05:08 2013 +0100 @@ -108,6 +108,8 @@ SA_LFLAGS = $(SA_LFLAGS) -map -debug !endif +SA_CFLAGS = $(SA_CFLAGS) -MP + # Note that we do not keep sawindbj.obj around as it would then # get included in the dumpbin command in build_vm_def.sh From david.holmes at oracle.com Fri Feb 1 05:40:55 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Feb 2013 23:40:55 +1000 Subject: RFR(XXS): 8007312: Signal Dispatcher thread to start and register ctrl-break handler before TRACE_INITIALIZE In-Reply-To: <0198a899-c8a8-4fa0-8232-bd2464be599e@default> References: <092ccf0f-36a6-4e5b-aa73-e06bff290585@default> <510B48A6.7060500@oracle.com> <9fa18ccc-b229-47c0-b7e6-5b988903c1b6@default> <510BA7C9.1020000@oracle.com> <513992b6-653b-4c3a-a605-73a8db5b8d8f@default> <510BAF2A.4080502@oracle.com> <0198a899-c8a8-4fa0-8232-bd2464be599e@default> Message-ID: <510BC5E7.7040001@oracle.com> On 1/02/2013 10:27 PM, Markus Gr?nlund wrote: > David, > > 0171f3a0 56bdb160 56bdaf2b 00000001 3dd4dde1 kernel32!SetConsoleCtrlHandler > 0171f3e0 074b248c 00000002 074b2420 00000000 msvcr100!signal+0x125 [f:\dd\vctools\crt_bld\self_x86\crt\src\winsig.c @ 256] > 0171f3f4 074af2a7 00000002 074b2420 00000000 jvm!os::signal+0x3c [d:\hotspot_src\hsx\24\hotspot_31_jan\src\os\windows\vm\os_windows.cpp @ 1860] > 0171f44c 6a0b4748 00000002 00000002 0193de46 jvm!JVM_RegisterSignal+0x1b7 [d:\hotspot_src\hsx\24\hotspot_31_jan\src\os\windows\vm\jvm_windows.cpp @ 68] > WARNING: Stack unwind information not available. Following frames may be wrong. > 0171f58c 078f860d 0171f5ec 0171f760 0000000a java_6a0b0000!Java_sun_misc_Signal_handle0+0xd > 0171f630 074bb2ef 0171f758 0171f6a0 0171f6f0 jvm!JavaCalls::call_helper+0x3dd [d:\hotspot_src\hsx\24\hotspot_31_jan\src\share\vm\runtime\javacalls.cpp @ 415] > 0171f678 078f8222 078f8230 0171f758 0171f6a0 jvm!os::os_exception_wrapper+0x9f [d:\hotspot_src\hsx\24\hotspot_31_jan\src\os_cpu\windows_x86\vm\os_windows_x86.cpp @ 113] > 0171f694 078f80db 0171f758 0173f6d0 0171f6f0 jvm!JavaCalls::call+0x52 [d:\hotspot_src\hsx\24\hotspot_31_jan\src\share\vm\runtime\javacalls.cpp @ 320] > 0171f6d0 078f811b 0171f758 0173f6d4 05fa6aa8 jvm!JavaCalls::call_static+0x9b [d:\hotspot_src\hsx\24\hotspot_31_jan\src\share\vm\runtime\javacalls.cpp @ 286] > 0171f738 07936ccb 0171f758 0173f6cc 05fa6aa8 jvm!JavaCalls::call_static+0x2b [d:\hotspot_src\hsx\24\hotspot_31_jan\src\share\vm\runtime\javacalls.cpp @ 292] > 0171f770 079361bd 0173ec00 7ffde000 77d37894 jvm!call_initializeSystemClass+0x6b [d:\hotspot_src\hsx\24\hotspot_31_jan\src\share\vm\runtime\thread.cpp @ 1022] > 0171f974 0785232f 0171f9d4 0171f9bb 00000000 jvm!Threads::create_vm+0xcdd [d:\hotspot_src\hsx\24\hotspot_31_jan\src\share\vm\runtime\thread.cpp @ 3497] > 0171f9bc 011713c1 0171fa28 0171fa34 0171f9d4 jvm!JNI_CreateJavaVM+0x7f [d:\hotspot_src\hsx\24\hotspot_31_jan\src\share\vm\prims\jni.cpp @ 5134] > > Registration of UserHandler() actually comes in as an effect of call_initializeSystemClass() during VM startup... Yes via Terminator: // Setup Java signal handlers for HUP, TERM, and INT (where available). Terminator.setup(); > I agree this seems wrong as we are not ready at this point. Not sure we can really do anything about it though - we'd need to split the Java level initialization into two steps at least. Even then it may be impossible to get rid of all cycles in the initialization dependencies. So I guess the VM can only note that the handler can be installed before it is ready and watch for these early invocations. Or (more complex) the VM could simply note the request to install the signal handler and defer the actual installation to a later point. But all that is again disruptive to the initialization process. Which brings us back to simply checking for not being initialized. David > > /Markus > > > -----Original Message----- > From: David Holmes > Sent: den 1 februari 2013 13:04 > To: Markus Gr?nlund > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR(XXS): 8007312: Signal Dispatcher thread to start and register ctrl-break handler before TRACE_INITIALIZE > > I think java.lang.Terminator installs the handler sometime during class library initialization. This in itself seems wrong, if that is happening before the VM has initialized the signal handling subsystem. > > David > > On 1/02/2013 9:56 PM, Markus Gr?nlund wrote: >> Thanks David. Inline. >> >> -----Original Message----- >> From: David Holmes >> Sent: den 1 februari 2013 12:32 >> To: Markus Gr?nlund >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: RFR(XXS): 8007312: Signal Dispatcher thread to start and >> register ctrl-break handler before TRACE_INITIALIZE >> >> Hi Markus, >> >> I appreciate the change of approach. Can we not check if the initialization has occurred and so keep the assert where it already exists eg: >> >> void os::signal_notify(int signal_number) { >> BOOL ret; >> + if (sig_sem != NULL) { >> Atomic::inc(&pending_signals[signal_number]); >> ret = ::ReleaseSemaphore(sig_sem, 1, NULL); >> assert(ret != 0, "ReleaseSemaphore() failed"); >> + } >> } >> [MG] >> We could absolutely do this for Windows (a handle NULL check is easy to do). More unsure how to validate an eventual uninitialized semaphore of the assert for Solaris though where I would need more state tracking to keep track of the initialization state of the sema_t. That said, I am not even sure this is a real issue on Solaris, because I haven't been able to test with a debug build there yet. Let's take Solaris as a separate step, and resolve the Windows issue first. >> >> That said I'm unclear how on Solaris we get into this code. You said >> on Windows the C runtime fault handler causes things to get directed >> back to UserHandler. But on linux/Solaris I did not expect any VM >> handler to be installed at this point so the default signal response >> would occur - to kill the process. The shared code does this at the >> end of >> os::signal_init() >> >> os::signal(SIGBREAK, os::user_handler()) >> >> So I'm not sure how we end up in UserHandler() ?? >> [MG] >> You put your finger on the spot here - this is actually my main confusion at this point as well (and I agree with you description, I wonder how we can ever end up in UserHandler() even though we haven't called SetConsoleCtrlHandler() on it....apparently its registered: >> >> 04a4fdd0 07b2242c 00000002 04a4fe18 7851afbb jvm!os::signal_notify+0x4 >> [d:\hotspot_src\hsx\24\hotspot_31_jan\src\os\windows\vm\os_windows.cpp >> @ 1961] 04a4fddc 7851afbb 00000002 a0bf8b55 00000000 >> jvm!UserHandler+0xc >> [d:\hotspot_src\hsx\24\hotspot_31_jan\src\os\windows\vm\os_windows.cpp >> @ 1845] >> 04a4fe18 764ae3d8 00000000 aa5b288e 00000000 >> msvcr100!ctrlevent_capture+0x90 >> [f:\dd\vctools\crt_bld\self_x86\crt\src\winsig.c @ 130]<<-- get the C >> Runtime default ctrlevent_capture to call us back (I guess this is >> normal linked list of signal handlers passing down), but our callback >> has not been setup up proper yet? At least not from the VM. I >> >> 04a4fea4 7647ed6c 00000000 04a4fef0 7793377b >> kernel32!CtrlRoutine+0x126 >> 04a4feb0 7793377b 00000000 769482db 00000000 >> kernel32!BaseThreadInitThunk+0xe >> 04a4fef0 7793374e 76494a03 00000000 00000000 >> ntdll!__RtlUserThreadStart+0x70 >> 04a4ff08 00000000 76494a03 00000000 00000000 >> ntdll!_RtlUserThreadStart+0x1b >> >> I only find a single call to SetConsoleCtrlHandler() but that does not >> register UserHandler(), it registers consoleHandler() >> >> Unless...maybe the java.exe launcher is doing some signal registration here? But how would it be possible to register a callback in the jvm.dll? hmm...Very interesting, I'm going to find out.. stay tuned... >> >> Cheers >> Markus >> >> David >> >> On 1/02/2013 6:20 PM, Markus Gr?nlund wrote: >>> Hi David, >>> >>> Many thanks for your input. >>> >>> I do acknowledge the startup sequence is fragile, and this is quite tricky business - you raise good points. >>> >>> From what I can read/test/trace, we are ready to start up the Signal Dispatcher Java thread at an earlier point (technically from a VM perspective), but as you say, this is mainly based on the best (worst?) theoretical case (and a bit of hands on a few different platforms) - in addition, if we take into account what expectations current testing has in this area (which I am unsure of at this point), there is now a change introduced between JVMTI_EVENT_VM_START and JVMTI_EVENT_JVMTI_PHASE_LIVE - and who knows what kind of test issues this might be causing...could be found out, but with a lot of effort... >>> >>> I see that the only OS:s where the correct behavior is actually checked are Solaris and Windows (asserts). >>> >>> I think we need the first stage TRACE_INITIALIZE before set_init_completed() and JVMTI_EVENT_JVMTI_PHASE_LIVE (don't remember the actual rationale off the top of my head), but I can verify if it can move later... >>> >>> Since this is a very hard area to get right, as you say, there will always be window where this is always an issue...I was considering a more pragmatic means just to resolve this particular issue in a somewhat timely manner (even though it's not my preferred choice): >>> >>> If we lax up (remove) the asserts os::signal_notify() on the return from semaphore signaling (sema_post() solaris and ReleaseSemaphore() windows), this should cease being an issue (we then get the same behavior as PRODUCT builds for non-product builds (do nothing)). ( btw it's not an error to close a NULL handle on Windows, but if you do it in debug mode you get told about it). >>> >>> I never like removing asserts however, but this seems like a feasible (time/effort/risk) resolution to this problem. >>> >>> Appreciate your comments as always, let me know what you think of this. >>> >>> Cheers >>> Markus >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes >>> Sent: den 1 februari 2013 05:47 >>> To: Markus Gr?nlund >>> Cc: hotspot-dev at openjdk.java.net >>> Subject: Re: RFR(XXS): 8007312: Signal Dispatcher thread to start and >>> register ctrl-break handler before TRACE_INITIALIZE >>> >>> Hi Markus, >>> >>> I understand that there is a bug if ctrl-C is pressed before we have initalized the signal handler. I also realize that normally the chance of hitting that window is negligible, but with TRACE_INITIALIZE active the window becomes much larger. >>> >>> But as I wrote in the bug report the VM initialization sequence is very fragile and changes to it have to be made with great care. Basic tests only test the normal startup path. Problems arise where we use specific VM flags (eg tracing) with specific VM services (specific GC) and even a specific VM (fastdebug). >>> >>> In this case I can't convince myself it is safe for the ctrl-C handler to be setup at this earlier point in time. We are still in the initialization phase of the VM and the handler code has to make Java calls to create and start a Java signal handling thread. Are we ready to execute that Java code at this point in time - before set_init_completed()? What might go wrong? What if the Java code hits an exception? >>> >>> Can you test your fix by adding a sleep after os::signal_init and sending ctrl-C? >>> >>> Can you emulate this problem on Linux/Solaris by adding a sleep before the original os::signal_init() ? Does it crash there too, or is this a problem limited to Windows? If so the fix should be limited to Windows. >>> >>> Can you consider moving TRACE_INITIALIZE instead? >>> >>> Thanks, >>> David >>> >>> On 1/02/2013 7:22 AM, Markus Gr?nlund wrote: >>>> Greetings, >>>> >>>> >>>> >>>> Can I kindly ask for a few reviews and a putback sponsorship for the following change: >>>> >>>> >>>> >>>> Bugid: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007312 >>>> >>>> Webrev: http://cr.openjdk.java.net/~mgronlun/8007312/webrev01/ >>>> >>>> Hotspot JPRT builds/tests : completed successfully >>>> >>>> >>>> >>>> Comment on issue/fix: >>>> >>>> >>>> >>>> (windows analysis) >>>> >>>> >>>> >>>> Pressing ctrl-c before Hotspot signal/console handler has been registered actually asserts/stops the VM (which to the user appears like a crash) on non-product builds. >>>> >>>> >>>> >>>> Before Hotspot registers its own jvm!consoleHandler with kernel32!CtrlRoutine, the C runtime default msvcr100!ctrlevent_capture is implicitly used - this calls back into jvm!UserHandler, which forwards into os::signal_notify() which uses uninitialized variables. >>>> >>>> >>>> >>>> // on Windows this creates the following issue when closing a NULL >>>> handle to a semaphore >>>> >>>> >>>> >>>> void os::signal_notify(int signal_number) { >>>> >>>> BOOL ret; >>>> >>>> >>>> >>>> Atomic::inc(&pending_signals[signal_number]); >>>> >>>> ret = ::ReleaseSemaphore(sig_sem, 1, NULL);<<--- call >>>> ReleaseSemaphore on global handle sig_sem which has not been >>>> setup/created yet == is NULL (is created in os::signal_init_pd()) >>>> >>>> assert(ret != 0, "ReleaseSemaphore() failed");<<-- assert traps >>>> here (GetLastError() == 0xc0000008 - An invalid HANDLE was >>>> specified) >>>> >>>> >>>> >>>> } >>>> >>>> >>>> >>>> The short initial tests I have done locally so far on moving the signal handler registration earlier as suggested in this patch makes it very hard to issue crtl-c before Hotspot signal handler has been setup. >>>> >>>> >>>> >>>> Thanks >>>> >>>> Markus From nils.loodin at oracle.com Fri Feb 1 06:20:51 2013 From: nils.loodin at oracle.com (nils.loodin at oracle.com) Date: Fri, 01 Feb 2013 14:20:51 +0000 Subject: hg: hsx/hsx24/hotspot: 8007005: JEP 167 tracing gives negative time stamps for certain event fields Message-ID: <20130201142058.A742047752@hg.openjdk.java.net> Changeset: a7ffe4177db0 Author: nloodin Date: 2013-01-31 16:07 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a7ffe4177db0 8007005: JEP 167 tracing gives negative time stamps for certain event fields Reviewed-by: brutisso Contributed-by: markus.gronlund at oracle.com ! src/share/vm/trace/trace.xml ! src/share/vm/trace/traceEventClasses.xsl ! src/share/vm/trace/traceTime.hpp ! src/share/vm/trace/tracetypes.xml From markus.gronlund at oracle.com Fri Feb 1 06:49:47 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Fri, 1 Feb 2013 06:49:47 -0800 (PST) Subject: RFR(XXS): 8007312: null check signal semaphore in os::signal_notify windows In-Reply-To: <510BC5E7.7040001@oracle.com> References: <092ccf0f-36a6-4e5b-aa73-e06bff290585@default> <510B48A6.7060500@oracle.com> <9fa18ccc-b229-47c0-b7e6-5b988903c1b6@default> <510BA7C9.1020000@oracle.com> <513992b6-653b-4c3a-a605-73a8db5b8d8f@default> <510BAF2A.4080502@oracle.com> <0198a899-c8a8-4fa0-8232-bd2464be599e@default> <510BC5E7.7040001@oracle.com> Message-ID: <7705a335-1d80-4ac8-a32b-94dea26ccf30@default> Thanks David, Ok, so based on our discussions, we'll narrow this to only do a null check on the signal semaphore handle on Windows. I have updated the webrev, here: http://cr.openjdk.java.net/~mgronlun/8007312/webrev02/ Also I changed the bug description to reflect the updated information (to the updated subject in the mail above): http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007312 With this change we don't trap on the assert when pressing ctrl-c if the hotspot signal handler is not setup. Thanks a lot for your help David, have a great weekend. Cheers Markus -----Original Message----- From: David Holmes Sent: den 1 februari 2013 14:41 To: Markus Gr?nlund Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR(XXS): 8007312: Signal Dispatcher thread to start and register ctrl-break handler before TRACE_INITIALIZE Which brings us back to simply checking for not being initialized. David >>>> >>>> >>>> >>>> (windows analysis) >>>> >>>> >>>> >>>> Pressing ctrl-c before Hotspot signal/console handler has been registered actually asserts/stops the VM (which to the user appears like a crash) on non-product builds. >>>> >>>> >>>> >>>> Before Hotspot registers its own jvm!consoleHandler with kernel32!CtrlRoutine, the C runtime default msvcr100!ctrlevent_capture is implicitly used - this calls back into jvm!UserHandler, which forwards into os::signal_notify() which uses uninitialized variables. >>>> >>>> >>>> >>>> // on Windows this creates the following issue when closing a NULL >>>> handle to a semaphore >>>> >>>> >>>> >>>> void os::signal_notify(int signal_number) { >>>> >>>> BOOL ret; >>>> >>>> >>>> Atomic::inc(&pending_signals[signal_number]); >>>> >>>> ret = ::ReleaseSemaphore(sig_sem, 1, NULL);<<--- call >>>> ReleaseSemaphore on global handle sig_sem which has not been >>>> setup/created yet == is NULL (is created in os::signal_init_pd()) >>>> >>>> assert(ret != 0, "ReleaseSemaphore() failed");<<-- assert >>>> traps here (GetLastError() == 0xc0000008 - An invalid HANDLE was >>>> specified) >>>> >>>> >>>> >>>> } >>> >>>> >>>> >>>> Thanks >>>> >>>> Markus From mikael.vidstedt at oracle.com Fri Feb 1 11:35:18 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 01 Feb 2013 11:35:18 -0800 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <50A59010.5040001@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> <50A24E00.3070200@oracle.com> <50A25720.1040405@oracle.com> <50A59010.5040001@oracle.com> Message-ID: <510C18F6.6010305@oracle.com> All, I finally found some time to update the webrev: http://cr.openjdk.java.net/~mikael/8003310/webrev.03/webrev/ Not much has changes since the first webrev. I played around with turning the #ifdef in constantPool.cpp into a const bool = false, but one of the downsides I noticed with that is that the code will still be compiled into product and especially for this type of function with a relatively large number of constant strings in it it unnecessarily adds to the footprint. This does not invalidate the const bool = false idiom, but there may be cases where it is beneficial to use alternatives to it. Cheers, Mikael On 11/15/2012 5:00 PM, Mikael Vidstedt wrote: > On 2012-11-13 06:20, Coleen Phillimore wrote: >> On 11/13/2012 8:41 AM, Coleen Phillimore wrote: >>> >>> Hi Mikael, This is good! I have the same comments as David. >>> >>> For constantPool.cpp can you add #undef DBG after that code. >>> >>> Maybe there should be a new convention for DEBUG_ >>> for unused code that people want to leave around for debugging. I >>> don't recommend we add a lot of code like this, but having such an >>> ifdef would differentiate code that was just left in unintentionally >>> from code that we want to be left in (occasionally). >> >> Actually, I want to revise this. We had this discussion about this >> recently rwt metaspace debugging and favored a const static variable >> = false; under #ifdef DEBUG or ASSERT and the debugging code under >> DEBUG/ASSERT so that it doesn't bit rot. This is for the code left >> in intentionally. Which makes me wonder why print_cpool_bytes() is >> there under DEBUG_CPOOL claiming to be "temporary" when there is >> another printing function in that file already. > > The reason why I moved it under DBG was because it is only ever called > wrapped with a DBG(). I can play around with making it a const static > = false as you outlined. > > The other print functions in constantPool.cpp are implementations of > the virtual functions inherited from Metadata, so they are not quite > as temporary as print_cpool_bytes, if that makes sense. > > Cheers, > Mikael > >> >> Coleen >> >>> >>> Thanks, >>> Coleen >>> >>> On 11/13/2012 12:47 AM, David Holmes wrote: >>>> Hi Mikael, >>>> >>>> A couple of general observations as really the "owners" of each >>>> file needs to assess the changes: >>>> >>>> - sometimes functions exist for debugging/tracing and calls will be >>>> added to the code by engineers as they debug. For example MBFence >>>> in synchronizer.cpp allows you to add fences into expressions. >>>> >>>> - why was the "static" removed from a number functions. They now >>>> have global visibility rather than being restricted to their files? >>>> >>>> >>>> In globaleDefinitions.cpp: >>>> >>>> + void GlobalDefinitions::test_globals() { >>>> + intptr_t page_size = 4096; >>>> >>>> Page size may not be 4K - will the test still be valid? >>>> >>>> >>>> The comments describing clamp_address_in_page don't need to be on >>>> both the declaration and definition. >>>> >>>> Cheers, >>>> David >>>> ------ >>>> >>>> On 13/11/2012 1:59 PM, Mikael Vidstedt wrote: >>>>> >>>>> All, >>>>> >>>>> Please review the below change. The change adds the -Wunused flag >>>>> when >>>>> compiling with GCC and removes a number of unused functions/dead >>>>> code. >>>>> >>>>> In the process I found one function (same_page) which was >>>>> duplicated in >>>>> four different places. I merged it to a single function, renamed >>>>> it to >>>>> clamp_address_in_page, added some comments and refactored it to be >>>>> slightly easier to understand. I also added unit tests for it. >>>>> Feedback >>>>> appreciated (especially on the name). >>>>> >>>>> http://cr.openjdk.java.net/~mikael/8003310/webrev.00/ >>>>> >>>>> Passes JPRT and the built-in unit tests >>>>> (-XX:+ExecuteInternalVMTests). >>>>> >>>>> Thanks, >>>>> Mikael >>>>> >>> >> > From jon.masamitsu at oracle.com Fri Feb 1 11:53:22 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 01 Feb 2013 11:53:22 -0800 Subject: CFV: New HSX Committer: Erik Helin In-Reply-To: <50FD2B07.7030802@oracle.com> References: <50FD2B07.7030802@oracle.com> Message-ID: <510C1D32.3050003@oracle.com> Vote: yes On 1/21/2013 3:48 AM, Bengt Rutisson wrote: > > I hereby nominate Erik Helin (OpenJDK user name: ehelin) to HSX > Committer. > > Erik is a member of the Hotspot GC team. He has contributed 8 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.helin at oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.x.helin at oracle.com > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=erik.helin at oracle.com > > > Votes are due by February 4, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From John.Coomes at oracle.com Fri Feb 1 13:43:15 2013 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 1 Feb 2013 13:43:15 -0800 Subject: CFV: New HSX Committer: Erik Helin In-Reply-To: <50FD2B07.7030802@oracle.com> References: <50FD2B07.7030802@oracle.com> Message-ID: <20748.14067.996022.593025@oracle.com> Vote: yes -John From david.holmes at oracle.com Fri Feb 1 14:44:54 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 02 Feb 2013 08:44:54 +1000 Subject: RFR(XXS): 8007312: null check signal semaphore in os::signal_notify windows In-Reply-To: <7705a335-1d80-4ac8-a32b-94dea26ccf30@default> References: <092ccf0f-36a6-4e5b-aa73-e06bff290585@default> <510B48A6.7060500@oracle.com> <9fa18ccc-b229-47c0-b7e6-5b988903c1b6@default> <510BA7C9.1020000@oracle.com> <513992b6-653b-4c3a-a605-73a8db5b8d8f@default> <510BAF2A.4080502@oracle.com> <0198a899-c8a8-4fa0-8232-bd2464be599e@default> <510BC5E7.7040001@oracle.com> <7705a335-1d80-4ac8-a32b-94dea26ccf30@default> Message-ID: <510C4566.2000401@oracle.com> On 2/02/2013 12:49 AM, Markus Gr?nlund wrote: > Thanks David, > > Ok, so based on our discussions, we'll narrow this to only do a null check on the signal semaphore handle on Windows. > > I have updated the webrev, here: > http://cr.openjdk.java.net/~mgronlun/8007312/webrev02/ Looks okay to me. I'll try to test out what happens on Solaris/Linux if you manage to sneak in a very early ctrl-C. Thanks, David > > Also I changed the bug description to reflect the updated information (to the updated subject in the mail above): > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007312 > > > With this change we don't trap on the assert when pressing ctrl-c if the hotspot signal handler is not setup. > > Thanks a lot for your help David, have a great weekend. > > Cheers > Markus > > > > -----Original Message----- > From: David Holmes > Sent: den 1 februari 2013 14:41 > To: Markus Gr?nlund > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR(XXS): 8007312: Signal Dispatcher thread to start and register ctrl-break handler before TRACE_INITIALIZE > > Which brings us back to simply checking for not being initialized. > > David > >>>>> >>>>> >>>>> >>>>> (windows analysis) >>>>> >>>>> >>>>> >>>>> Pressing ctrl-c before Hotspot signal/console handler has been registered actually asserts/stops the VM (which to the user appears like a crash) on non-product builds. >>>>> >>>>> >>>>> >>>>> Before Hotspot registers its own jvm!consoleHandler with kernel32!CtrlRoutine, the C runtime default msvcr100!ctrlevent_capture is implicitly used - this calls back into jvm!UserHandler, which forwards into os::signal_notify() which uses uninitialized variables. >>>>> >>>>> >>>>> >>>>> // on Windows this creates the following issue when closing a NULL >>>>> handle to a semaphore >>>>> >>>>> >>>>> >>>>> void os::signal_notify(int signal_number) { >>>>> >>>>> BOOL ret; >>>>> >>>>> >>>>> Atomic::inc(&pending_signals[signal_number]); >>>>> >>>>> ret = ::ReleaseSemaphore(sig_sem, 1, NULL);<<--- call >>>>> ReleaseSemaphore on global handle sig_sem which has not been >>>>> setup/created yet == is NULL (is created in os::signal_init_pd()) >>>>> >>>>> assert(ret != 0, "ReleaseSemaphore() failed");<<-- assert >>>>> traps here (GetLastError() == 0xc0000008 - An invalid HANDLE was >>>>> specified) >>>>> >>>>> >>>>> >>>>> } >>>> >>>>> >>>>> >>>>> Thanks >>>>> >>>>> Markus From alejandro.murillo at oracle.com Fri Feb 1 15:44:20 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 01 Feb 2013 23:44:20 +0000 Subject: hg: hsx/hsx24/hotspot: 10 new changesets Message-ID: <20130201234443.8456047793@hg.openjdk.java.net> Changeset: 7a2cf85fc36e Author: katleman Date: 2013-01-11 09:00 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7a2cf85fc36e Added tag jdk7u11-b20 for changeset 25a92b94ad53 ! .hgtags Changeset: b6d58acbaf5d Author: katleman Date: 2013-01-12 14:42 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b6d58acbaf5d Added tag jdk7u11-b21 for changeset 7a2cf85fc36e ! .hgtags Changeset: 5226f8fd82ab Author: coffeys Date: 2013-01-14 07:36 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5226f8fd82ab Merge ! .hgtags Changeset: 4a2a9ea97db1 Author: amurillo Date: 2013-01-15 15:05 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4a2a9ea97db1 Merge ! .hgtags Changeset: a110c1abdbe8 Author: lana Date: 2013-01-15 19:34 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a110c1abdbe8 Merge ! .hgtags Changeset: f26397ddd13b Author: lana Date: 2013-01-22 22:45 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f26397ddd13b Merge ! .hgtags - src/share/vm/trace/traceEventTypes.hpp Changeset: bfa88fb4cb01 Author: lana Date: 2013-01-28 11:12 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bfa88fb4cb01 Merge ! .hgtags Changeset: acf5f0fbba89 Author: katleman Date: 2013-02-01 09:56 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/acf5f0fbba89 Added tag jdk7u14-b12 for changeset bfa88fb4cb01 ! .hgtags Changeset: 88f46d208452 Author: amurillo Date: 2013-02-01 12:36 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/88f46d208452 Merge ! .hgtags - make/solaris/makefiles/kernel.make Changeset: 38b173289e57 Author: amurillo Date: 2013-02-01 12:36 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/38b173289e57 Added tag hs24-b32 for changeset 88f46d208452 ! .hgtags From kelly.ohair at oracle.com Fri Feb 1 16:42:15 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 1 Feb 2013 16:42:15 -0800 Subject: This simple patch doubles the compile-speed of the hotspot repo on Windows In-Reply-To: References: Message-ID: <76DC1CA3-E0C7-4A2D-9E3D-4523C6A3D536@oracle.com> Great stuff. Have you filed an issue on this? Or shall I? -kto On Feb 1, 2013, at 4:58 AM, Fredrik ?hrstr?m wrote: > ie. use /MP on the cl.exe command line. > > On the build machine (Windows Server 2007, Visual Studio 2010, 32 HT > cores, 64GB ram) configuring with: > > sh configure --enable-sjavac > --with-freetype=/cygdrive/d/tools/freetype-amd64 > --with-boot-jdk=/cygdrive/d/java/jdk-7-fcs-bin-b147/ > > (You need to patch > src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java > line 256, change equals("windows)" to startswith("windows), this fix > is going into tl soon.) > > Without MP > ----- Build times ------- > Start 2013-02-01 12:23:50 > End 2013-02-01 12:35:20 > 00:00:32 corba > 00:04:43 hotspot > 00:00:15 jaxp > 00:00:24 jaxws > 00:04:49 jdk > 00:00:46 langtools > 00:11:30 TOTAL > ------------------------- > > With MP > ----- Build times ------- > Start 2013-02-01 12:54:54 > End 2013-02-01 13:03:56 > 00:00:31 corba > 00:02:20 hotspot > 00:00:14 jaxp > 00:00:22 jaxws > 00:04:44 jdk > 00:00:46 langtools > 00:09:02 TOTAL > ------------------------- > > For such a simple patch it is a nice speedup. Please test and see if > it improves the speed on your multi core machines. > > //Fredrik > > Oh, and for reference this is the speed without sjavac but with /MP. > > ----- Build times ------- > Start 2013-02-01 13:39:38 > End 2013-02-01 13:51:46 > 00:00:35 corba > 00:02:24 hotspot > 00:00:28 jaxp > 00:00:36 jaxws > 00:07:11 jdk > 00:00:48 langtools > 00:12:08 TOTAL > ------------------------- > > $ hg diff > diff -r 67498c863813 make/windows/makefiles/compile.make > --- a/make/windows/makefiles/compile.make Thu Jan 17 12:16:06 2013 +0100 > +++ b/make/windows/makefiles/compile.make Fri Feb 01 13:05:08 2013 +0100 > @@ -44,6 +44,7 @@ > # /GS Inserts security stack checks in some functions (VS2005 default) > # /Oi Use intrinsics (in /O2) > # /Od Disable all optimizations > +# /MP Use multiple cores for compilation > # > # NOTE: Normally following any of the above with a '-' will turn off that flag > # > @@ -52,7 +53,7 @@ > # improving the quality of crash log stack traces involving jvm.dll. > > # These are always used in all compiles > -CXX_FLAGS=/nologo /W3 /WX > +CXX_FLAGS=/nologo /W3 /WX /MP > > # Let's add debug information when Full Debug Symbols is enabled > !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" > diff -r 67498c863813 make/windows/makefiles/sa.make > --- a/make/windows/makefiles/sa.make Thu Jan 17 12:16:06 2013 +0100 > +++ b/make/windows/makefiles/sa.make Fri Feb 01 13:05:08 2013 +0100 > @@ -108,6 +108,8 @@ > SA_LFLAGS = $(SA_LFLAGS) -map -debug > !endif > > +SA_CFLAGS = $(SA_CFLAGS) -MP > + > # Note that we do not keep sawindbj.obj around as it would then > # get included in the dumpbin command in build_vm_def.sh From zhengyu.gu at oracle.com Fri Feb 1 16:56:11 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 1 Feb 2013 19:56:11 -0500 Subject: CFV: New HSX Committer: Erik Helin In-Reply-To: <510C1D32.3050003@oracle.com> References: <50FD2B07.7030802@oracle.com> <510C1D32.3050003@oracle.com> Message-ID: <184F3A45-E060-4ED8-A186-569CEB2753FE@oracle.com> Vote: yes -Zhengyu On Feb 1, 2013, at 2:53 PM, Jon Masamitsu wrote: > Vote: yes > > On 1/21/2013 3:48 AM, Bengt Rutisson wrote: >> >> I hereby nominate Erik Helin (OpenJDK user name: ehelin) to HSX Committer. >> >> Erik is a member of the Hotspot GC team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: >> >> http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.helin at oracle.com >> http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.x.helin at oracle.com >> http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=erik.helin at oracle.com >> >> Votes are due by February 4, 2013. >> >> Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [3]. >> >> Thanks, >> Bengt >> >> [1]http://openjdk.java.net/projects/#project-committer >> [2]http://openjdk.java.net/census#hsx >> [3]http://openjdk.java.net/projects#committer-vote >> From christian.thalinger at oracle.com Fri Feb 1 18:15:33 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 1 Feb 2013 18:15:33 -0800 Subject: RFC: deprecating SPARC V8 support? Message-ID: <78B9ADEE-9C1F-4EF3-9961-9781B45640FE@oracle.com> Hello Community! We are playing with the idea to deprecate SPARC V8 support in HotSpot and I would like to get some input from the OpenJDK community (especially from the usual suspects: SAP, RedHat, Debian, ...). Is anyone out there still using SPARC V8 hardware or is supporting it? -- Chris From alejandro.murillo at oracle.com Sat Feb 2 01:17:36 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 02 Feb 2013 09:17:36 +0000 Subject: hg: hsx/hsx24/hotspot: 8007394: new hotspot build - hs24-b33 Message-ID: <20130202091741.21F40477A5@hg.openjdk.java.net> Changeset: 607dd575f464 Author: amurillo Date: 2013-02-01 12:49 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/607dd575f464 8007394: new hotspot build - hs24-b33 Reviewed-by: jcoomes ! make/hotspot_version From david.holmes at oracle.com Sat Feb 2 05:00:27 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 02 Feb 2013 23:00:27 +1000 Subject: RFR(XXS): 8007312: null check signal semaphore in os::signal_notify windows In-Reply-To: <510C4566.2000401@oracle.com> References: <092ccf0f-36a6-4e5b-aa73-e06bff290585@default> <510B48A6.7060500@oracle.com> <9fa18ccc-b229-47c0-b7e6-5b988903c1b6@default> <510BA7C9.1020000@oracle.com> <513992b6-653b-4c3a-a605-73a8db5b8d8f@default> <510BAF2A.4080502@oracle.com> <0198a899-c8a8-4fa0-8232-bd2464be599e@default> <510BC5E7.7040001@oracle.com> <7705a335-1d80-4ac8-a32b-94dea26ccf30@default> <510C4566.2000401@oracle.com> Message-ID: <510D0DEB.50808@oracle.com> On 2/02/2013 8:44 AM, David Holmes wrote: > On 2/02/2013 12:49 AM, Markus Gr?nlund wrote: >> Thanks David, >> >> Ok, so based on our discussions, we'll narrow this to only do a null >> check on the signal semaphore handle on Windows. >> >> I have updated the webrev, here: >> http://cr.openjdk.java.net/~mgronlun/8007312/webrev02/ > > Looks okay to me. > > I'll try to test out what happens on Solaris/Linux if you manage to > sneak in a very early ctrl-C. Curiously nothing. I put an infinite_sleep at the start of os::signal_init. On both linux and solaris ctrl-c did nothing while ctrl-/ (SIGQUIT) induced a core dump - as expected. No assertions triggered. It did show UserHandler was installed though. Can't test windows. David ----- > Thanks, > David > >> >> Also I changed the bug description to reflect the updated information >> (to the updated subject in the mail above): >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007312 >> >> >> With this change we don't trap on the assert when pressing ctrl-c if >> the hotspot signal handler is not setup. >> >> Thanks a lot for your help David, have a great weekend. >> >> Cheers >> Markus >> >> >> >> -----Original Message----- >> From: David Holmes >> Sent: den 1 februari 2013 14:41 >> To: Markus Gr?nlund >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: RFR(XXS): 8007312: Signal Dispatcher thread to start and >> register ctrl-break handler before TRACE_INITIALIZE >> >> Which brings us back to simply checking for not being initialized. >> >> David >> >>>>>> >>>>>> >>>>>> >>>>>> (windows analysis) >>>>>> >>>>>> >>>>>> >>>>>> Pressing ctrl-c before Hotspot signal/console handler has been >>>>>> registered actually asserts/stops the VM (which to the user >>>>>> appears like a crash) on non-product builds. >>>>>> >>>>>> >>>>>> >>>>>> Before Hotspot registers its own jvm!consoleHandler with >>>>>> kernel32!CtrlRoutine, the C runtime default >>>>>> msvcr100!ctrlevent_capture is implicitly used - this calls back >>>>>> into jvm!UserHandler, which forwards into os::signal_notify() >>>>>> which uses uninitialized variables. >>>>>> >>>>>> >>>>>> >>>>>> // on Windows this creates the following issue when closing a NULL >>>>>> handle to a semaphore >>>>>> >>>>>> >>>>>> >>>>>> void os::signal_notify(int signal_number) { >>>>>> >>>>>> BOOL ret; >>>>>> >>>>>> >>>>>> Atomic::inc(&pending_signals[signal_number]); >>>>>> >>>>>> ret = ::ReleaseSemaphore(sig_sem, 1, NULL);<<--- call >>>>>> ReleaseSemaphore on global handle sig_sem which has not been >>>>>> setup/created yet == is NULL (is created in os::signal_init_pd()) >>>>>> >>>>>> assert(ret != 0, "ReleaseSemaphore() failed");<<-- assert >>>>>> traps here (GetLastError() == 0xc0000008 - An invalid HANDLE was >>>>>> specified) >>>>>> >>>>>> >>>>>> >>>>>> } >>>>> >>>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> Markus From markus.gronlund at oracle.com Sat Feb 2 07:02:57 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Sat, 2 Feb 2013 07:02:57 -0800 (PST) Subject: RFR(XXS): 8007312: null check signal semaphore in os::signal_notify windows In-Reply-To: <510D0DEB.50808@oracle.com> References: <092ccf0f-36a6-4e5b-aa73-e06bff290585@default> <510B48A6.7060500@oracle.com> <9fa18ccc-b229-47c0-b7e6-5b988903c1b6@default> <510BA7C9.1020000@oracle.com> <513992b6-653b-4c3a-a605-73a8db5b8d8f@default> <510BAF2A.4080502@oracle.com> <0198a899-c8a8-4fa0-8232-bd2464be599e@default> <510BC5E7.7040001@oracle.com> <7705a335-1d80-4ac8-a32b-94dea26ccf30@default> <510C4566.2000401@oracle.com> <510D0DEB.50808@oracle.com> Message-ID: <9ec0522f-2a50-45e3-890c-381221ef7749@default> Thanks for checking. This matches the initial quick tests I did on Solaris as well. "Curiously nothing. I put an infinite_sleep at the start of os::signal_init. On both linux and solaris ctrl-c did nothing while ctrl-/ (SIGQUIT) induced a core dump - as expected. No assertions triggered. It did show UserHandler was installed though. Maybe the ::sema_post(&sig_sem); is not issuing a non-zero return value when called on an non-sema_init:ed sema_t? (this is where I would expect something to happen, linux or bsd does not have any asserts on this). Thanks for verifying UserHandler() installation here. Cheers Markus -----Original Message----- From: David Holmes Sent: den 2 februari 2013 14:00 To: Markus Gr?nlund Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR(XXS): 8007312: null check signal semaphore in os::signal_notify windows On 2/02/2013 8:44 AM, David Holmes wrote: > On 2/02/2013 12:49 AM, Markus Gr?nlund wrote: >> Thanks David, >> >> Ok, so based on our discussions, we'll narrow this to only do a null >> check on the signal semaphore handle on Windows. >> >> I have updated the webrev, here: >> http://cr.openjdk.java.net/~mgronlun/8007312/webrev02/ > > Looks okay to me. > > I'll try to test out what happens on Solaris/Linux if you manage to > sneak in a very early ctrl-C. Curiously nothing. I put an infinite_sleep at the start of os::signal_init. On both linux and solaris ctrl-c did nothing while ctrl-/ (SIGQUIT) induced a core dump - as expected. No assertions triggered. It did show UserHandler was installed though. Can't test windows. David ----- > Thanks, > David > >> >> Also I changed the bug description to reflect the updated information >> (to the updated subject in the mail above): >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007312 >> >> >> With this change we don't trap on the assert when pressing ctrl-c if >> the hotspot signal handler is not setup. >> >> Thanks a lot for your help David, have a great weekend. >> >> Cheers >> Markus >> >> >> >> -----Original Message----- >> From: David Holmes >> Sent: den 1 februari 2013 14:41 >> To: Markus Gr?nlund >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: RFR(XXS): 8007312: Signal Dispatcher thread to start and >> register ctrl-break handler before TRACE_INITIALIZE >> >> Which brings us back to simply checking for not being initialized. >> >> David >> >>>>>> >>>>>> >>>>>> >>>>>> (windows analysis) >>>>>> >>>>>> >>>>>> >>>>>> Pressing ctrl-c before Hotspot signal/console handler has been >>>>>> registered actually asserts/stops the VM (which to the user >>>>>> appears like a crash) on non-product builds. >>>>>> >>>>>> >>>>>> >>>>>> Before Hotspot registers its own jvm!consoleHandler with >>>>>> kernel32!CtrlRoutine, the C runtime default >>>>>> msvcr100!ctrlevent_capture is implicitly used - this calls back >>>>>> into jvm!UserHandler, which forwards into os::signal_notify() >>>>>> which uses uninitialized variables. >>>>>> >>>>>> >>>>>> >>>>>> // on Windows this creates the following issue when closing a >>>>>> NULL handle to a semaphore >>>>>> >>>>>> >>>>>> >>>>>> void os::signal_notify(int signal_number) { >>>>>> >>>>>> BOOL ret; >>>>>> >>>>>> >>>>>> Atomic::inc(&pending_signals[signal_number]); >>>>>> >>>>>> ret = ::ReleaseSemaphore(sig_sem, 1, NULL);<<--- call >>>>>> ReleaseSemaphore on global handle sig_sem which has not been >>>>>> setup/created yet == is NULL (is created in os::signal_init_pd()) >>>>>> >>>>>> assert(ret != 0, "ReleaseSemaphore() failed");<<-- assert traps >>>>>> here (GetLastError() == 0xc0000008 - An invalid HANDLE was >>>>>> specified) >>>>>> >>>>>> >>>>>> >>>>>> } >>>>> >>>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> Markus From markus.gronlund at oracle.com Sat Feb 2 07:25:37 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Sat, 2 Feb 2013 07:25:37 -0800 (PST) Subject: RFR(XXS): 8007312: null check signal semaphore in os::signal_notify windows In-Reply-To: <9ec0522f-2a50-45e3-890c-381221ef7749@default> References: <092ccf0f-36a6-4e5b-aa73-e06bff290585@default> <510B48A6.7060500@oracle.com> <9fa18ccc-b229-47c0-b7e6-5b988903c1b6@default> <510BA7C9.1020000@oracle.com> <513992b6-653b-4c3a-a605-73a8db5b8d8f@default> <510BAF2A.4080502@oracle.com> <0198a899-c8a8-4fa0-8232-bd2464be599e@default> <510BC5E7.7040001@oracle.com> <7705a335-1d80-4ac8-a32b-94dea26ccf30@default> <510C4566.2000401@oracle.com> <510D0DEB.50808@oracle.com> <9ec0522f-2a50-45e3-890c-381221ef7749@default> Message-ID: <6eb127b1-4422-4889-91db-e2ecbf11b942@default> And it doesn't look like sema_post() do check for it (it only checks to see if the semaphore value pointed to by sp exceeds SEM_VALUE_MAX). http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/threads/sema.c#297 sema_post() could probably be extended to also check for sp->magic == SEMA_MAGIC to ensure that the call is on a valid (initialized), semaphore. Cheers Markus -----Original Message----- From: Markus Gr?nlund Sent: den 2 februari 2013 16:03 To: David Holmes Cc: hotspot-dev at openjdk.java.net Subject: RE: RFR(XXS): 8007312: null check signal semaphore in os::signal_notify windows Thanks for checking. This matches the initial quick tests I did on Solaris as well. "Curiously nothing. I put an infinite_sleep at the start of os::signal_init. On both linux and solaris ctrl-c did nothing while ctrl-/ (SIGQUIT) induced a core dump - as expected. No assertions triggered. It did show UserHandler was installed though. Maybe the ::sema_post(&sig_sem); is not issuing a non-zero return value when called on an non-sema_init:ed sema_t? (this is where I would expect something to happen, linux or bsd does not have any asserts on this). Thanks for verifying UserHandler() installation here. Cheers Markus -----Original Message----- From: David Holmes Sent: den 2 februari 2013 14:00 To: Markus Gr?nlund Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR(XXS): 8007312: null check signal semaphore in os::signal_notify windows On 2/02/2013 8:44 AM, David Holmes wrote: > On 2/02/2013 12:49 AM, Markus Gr?nlund wrote: >> Thanks David, >> >> Ok, so based on our discussions, we'll narrow this to only do a null >> check on the signal semaphore handle on Windows. >> >> I have updated the webrev, here: >> http://cr.openjdk.java.net/~mgronlun/8007312/webrev02/ > > Looks okay to me. > > I'll try to test out what happens on Solaris/Linux if you manage to > sneak in a very early ctrl-C. Curiously nothing. I put an infinite_sleep at the start of os::signal_init. On both linux and solaris ctrl-c did nothing while ctrl-/ (SIGQUIT) induced a core dump - as expected. No assertions triggered. It did show UserHandler was installed though. Can't test windows. David ----- > Thanks, > David > >> >> Also I changed the bug description to reflect the updated information >> (to the updated subject in the mail above): >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007312 >> >> >> With this change we don't trap on the assert when pressing ctrl-c if >> the hotspot signal handler is not setup. >> >> Thanks a lot for your help David, have a great weekend. >> >> Cheers >> Markus >> >> >> >> -----Original Message----- >> From: David Holmes >> Sent: den 1 februari 2013 14:41 >> To: Markus Gr?nlund >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: RFR(XXS): 8007312: Signal Dispatcher thread to start and >> register ctrl-break handler before TRACE_INITIALIZE >> >> Which brings us back to simply checking for not being initialized. >> >> David >> >>>>>> >>>>>> >>>>>> >>>>>> (windows analysis) >>>>>> >>>>>> >>>>>> >>>>>> Pressing ctrl-c before Hotspot signal/console handler has been >>>>>> registered actually asserts/stops the VM (which to the user >>>>>> appears like a crash) on non-product builds. >>>>>> >>>>>> >>>>>> >>>>>> Before Hotspot registers its own jvm!consoleHandler with >>>>>> kernel32!CtrlRoutine, the C runtime default >>>>>> msvcr100!ctrlevent_capture is implicitly used - this calls back >>>>>> into jvm!UserHandler, which forwards into os::signal_notify() >>>>>> which uses uninitialized variables. >>>>>> >>>>>> >>>>>> >>>>>> // on Windows this creates the following issue when closing a >>>>>> NULL handle to a semaphore >>>>>> >>>>>> >>>>>> >>>>>> void os::signal_notify(int signal_number) { >>>>>> >>>>>> BOOL ret; >>>>>> >>>>>> >>>>>> Atomic::inc(&pending_signals[signal_number]); >>>>>> >>>>>> ret = ::ReleaseSemaphore(sig_sem, 1, NULL);<<--- call >>>>>> ReleaseSemaphore on global handle sig_sem which has not been >>>>>> setup/created yet == is NULL (is created in os::signal_init_pd()) >>>>>> >>>>>> assert(ret != 0, "ReleaseSemaphore() failed");<<-- assert traps >>>>>> here (GetLastError() == 0xc0000008 - An invalid HANDLE was >>>>>> specified) >>>>>> >>>>>> >>>>>> >>>>>> } >>>>> >>>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> Markus From lists at intricatesoftware.com Sat Feb 2 09:30:53 2013 From: lists at intricatesoftware.com (Kurt Miller) Date: Sat, 2 Feb 2013 12:30:53 -0500 Subject: OpenJDK6 20.0-b12 intermittent crash Message-ID: <201302021230.54300.lists@intricatesoftware.com> Hi, I recently finished porting OpenJDK6 to OpenBSD. For the most part everything is working well, however on x86-32 using the client vm I am experiencing an intermittent crash when using OpenJDK6 to bootstrap the OpenJDK7 build. I have rebuilt OpenJDK6 using the fastdebug target and reproduced the problem. I don't know the internals of hotstop well enough to find the root cause. Could someone take a look at the following crash report and provide some feedback. In particular I'd like to know if this crash is related to os specific porting issues or a general hotspot problem. If os specific what areas should I focus my attention on. I also have the core file for this crash and can provide additional information from the core upon request. Thank you for your help with this issue. Regards, -Kurt # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x8c19aeb5, pid=29475, tid=2171990272 # # JRE version: 6.0_32-b27 # Java VM: OpenJDK Client VM (20.0-b12-fastdebug mixed mode bsd-x86 ) # Problematic frame: # v ~BufferBlob::vtable chunks # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x8925cc00): JavaThread "main" [_thread_in_Java, id=-2122977024, stack(0x88a6b000,0x88abc000)] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x8c19aeb5 Registers: EAX=0xae312ca8, EBX=0xae30f7a0, ECX=0x9b5f7338, EDX=0x9a5c77e0 ESP=0x88abb50c, EBP=0x88abba70, ESI=0x9b5f7338, EDI=0x9b5f7338 EIP=0x8c19aeb5, EFLAGS=0x00010282 Top of Stack: (sp=0x88abb50c) 0x88abb50c: 8c2d2a3c 88abba70 8c380a3c 9a4e7260 0x88abb51c: 9b5f7338 9b5f7338 9b380a40 88abba70 0x88abb52c: 8c36ab78 9a37f698 9b5f6d90 88abba70 0x88abb53c: 8c17b884 8df8bcf0 8df8bd10 9b3aa628 0x88abb54c: ae420fb0 88abb63c 8df88380 9b5f7338 0x88abb55c: 9a4e7280 8df8bba8 8df8bc10 8df8bb98 0x88abb56c: ae420fb0 88abbd40 7da8cb18 88abba70 0x88abb57c: 8c21e87c 88abb65c 8df88380 9a4905e8 Instructions: (pc=0x8c19aeb5) 0x8c19ae95: a8 01 00 00 ff 63 44 cc cc cc cc 00 00 00 00 28 0x8c19aea5: 00 09 00 00 00 01 cc 8b 41 04 8b 98 d0 01 00 00 0x8c19aeb5: ff 63 44 cc cc cc cc 00 00 00 00 25 00 09 00 00 0x8c19aec5: 00 01 cc 8b 41 04 8b 98 c4 01 00 00 ff 63 44 cc Register to memory mapping: EAX=0xae312ca8 is an oop {instance class} - klass: {other class} - instance size: 28 - klass size: 164 - access: public synchronized - state: fully_initialized - name: 'com/sun/tools/javac/comp/Flow' - super: 'com/sun/tools/javac/tree/TreeScanner' - sub: - arrays: NULL - methods: a 'java/lang/Object'[56] - method ordering: [I - local interfaces: a 'java/lang/Object'[0] - trans. interfaces: a 'java/lang/Object'[0] - constants: constant pool [1131] for 'com/sun/tools/javac/comp/Flow' cache=0xae313760 - class loader: NULL - protection domain: NULL - host class: NULL - signers: NULL - source file: 'Flow.java' - inner classes: [S - java mirror: a 'java/lang/Class' = 'com/sun/tools/javac/comp/Flow' - vtable length 82 (start addr: 0xae312dd8) - itable length 2 (start addr: 0xae312f20) - ---- static fields (1 words): - protected static final 'flowKey' 'Lcom/sun/tools/javac/util/Context$Key;' @640 - ---- non-static fields (26 words): - 'firstadr' 'I' @8 - 'nextadr' 'I' @12 - private final 'allowImprovedRethrowAnalysis' 'Z' @16 - private final 'allowImprovedCatchAnalysis' 'Z' @17 - private 'alive' 'Z' @18 - 'loopPassTwo' 'Z' @19 - private final 'names' 'Lcom/sun/tools/javac/util/Names;' @20 - private final 'log' 'Lcom/sun/tools/javac/util/Log;' @24 - private final 'syms' 'Lcom/sun/tools/javac/code/Symtab;' @28 - private final 'types' 'Lcom/sun/tools/javac/code/Types;' @32 - private final 'chk' 'Lcom/sun/tools/javac/comp/Check;' @36 - private 'make' 'Lcom/sun/tools/javac/tree/TreeMaker;' @40 - private final 'rs' 'Lcom/sun/tools/javac/comp/Resolve;' @44 - private 'attrEnv' 'Lcom/sun/tools/javac/comp/Env;' @48 - private 'lint' 'Lcom/sun/tools/javac/code/Lint;' @52 - 'inits' 'Lcom/sun/tools/javac/util/Bits;' @56 - 'uninits' 'Lcom/sun/tools/javac/util/Bits;' @60 - 'preciseRethrowTypes' 'Ljava/util/HashMap;' @64 - 'uninitsTry' 'Lcom/sun/tools/javac/util/Bits;' @68 - 'initsWhenTrue' 'Lcom/sun/tools/javac/util/Bits;' @72 - 'initsWhenFalse' 'Lcom/sun/tools/javac/util/Bits;' @76 - 'uninitsWhenTrue' 'Lcom/sun/tools/javac/util/Bits;' @80 - 'uninitsWhenFalse' 'Lcom/sun/tools/javac/util/Bits;' @84 - 'vars' '[Lcom/sun/tools/javac/code/Symbol$VarSymbol;' @88 - 'classDef' 'Lcom/sun/tools/javac/tree/JCTree$JCClassDecl;' @92 - 'thrown' 'Lcom/sun/tools/javac/util/List;' @96 - 'caught' 'Lcom/sun/tools/javac/util/List;' @100 - 'unrefdResources' 'Lcom/sun/tools/javac/code/Scope;' @104 - 'pendingExits' 'Lcom/sun/tools/javac/util/ListBuffer;' @108 - static oop maps: 640-640 - non-static oop maps: 20-108 EBX=0xae30f7a0 is an oop {method} - klass: {other class} - this oop: 0xae30f7a0 - method holder: 'com/sun/tools/javac/comp/Flow' - constants: 0xae309148 constant pool [1131] for 'com/sun/tools/javac/comp/Flow' cache=0xae313760 - access: 0x1 public - name: 'visitTypeCast' - signature: '(Lcom/sun/tools/javac/tree/JCTree$JCTypeCast;)V' - max stack: 8 - max locals: 2 - size of params: 2 - method size: 20 - vtable index: 40 - i2i entry: 0x8bf6f6d0 - adapter: 0x7ed5909c - compiled entry 0x8c43c050 - code size: 92 - code start: 0xae30f738 - code end (excl): 0xae30f794 - checked ex length: 0 - linenumber start: 0xae30f794 - localvar length: 0 - compiled code: 24095 1648 nmethod com.sun.tools.javac.comp.Flow::visitTypeCast (92 bytes) ECX=0x9b5f7338 is an oop com.sun.tools.javac.comp.Flow - klass: 'com/sun/tools/javac/comp/Flow' - ---- fields (total size 28 words): - 'firstadr' 'I' @8 0 - 'nextadr' 'I' @12 0 - private final 'allowImprovedRethrowAnalysis' 'Z' @16 true - private final 'allowImprovedCatchAnalysis' 'Z' @17 true - private 'alive' 'Z' @18 true - 'loopPassTwo' 'Z' @19 false - private final 'names' 'Lcom/sun/tools/javac/util/Names;' @20 a 'com/sun/tools/javac/util/Names' (9b5f6ac0) - private final 'log' 'Lcom/sun/tools/javac/util/Log;' @24 a 'com/sun/tools/javac/util/Log' (9b37cd60) - private final 'syms' 'Lcom/sun/tools/javac/code/Symtab;' @28 a 'com/sun/tools/javac/code/Symtab' (9b5f6c68) - private final 'types' 'Lcom/sun/tools/javac/code/Types;' @32 a 'com/sun/tools/javac/code/Types' (9b5f6df8) - private final 'chk' 'Lcom/sun/tools/javac/comp/Check;' @36 a 'com/sun/tools/javac/comp/Check' (9b5f6d90) - private 'make' 'Lcom/sun/tools/javac/tree/TreeMaker;' @40 a 'com/sun/tools/javac/tree/TreeMaker' (8df8b970) - private final 'rs' 'Lcom/sun/tools/javac/comp/Resolve;' @44 a 'com/sun/tools/javac/comp/Resolve' (9b37c900) - private 'attrEnv' 'Lcom/sun/tools/javac/comp/Env;' @48 a 'com/sun/tools/javac/comp/Env' (9b44b520) - private 'lint' 'Lcom/sun/tools/javac/code/Lint;' @52 a 'com/sun/tools/javac/code/Lint' (9b37caf0) - 'inits' 'Lcom/sun/tools/javac/util/Bits;' @56 a 'com/sun/tools/javac/util/Bits' (8df8bbe0) - 'uninits' 'Lcom/sun/tools/javac/util/Bits;' @60 a 'com/sun/tools/javac/util/Bits' (8df8bc00) - 'preciseRethrowTypes' 'Ljava/util/HashMap;' @64 a 'java/util/HashMap' (8df8ba28) - 'uninitsTry' 'Lcom/sun/tools/javac/util/Bits;' @68 a 'com/sun/tools/javac/util/Bits' (8df8b9e0) - 'initsWhenTrue' 'Lcom/sun/tools/javac/util/Bits;' @72 a 'com/sun/tools/javac/util/Bits' (8df8bbe0) - 'initsWhenFalse' 'Lcom/sun/tools/javac/util/Bits;' @76 a 'com/sun/tools/javac/util/Bits' (8df8bcf0) - 'uninitsWhenTrue' 'Lcom/sun/tools/javac/util/Bits;' @80 a 'com/sun/tools/javac/util/Bits' (8df8bc00) - 'uninitsWhenFalse' 'Lcom/sun/tools/javac/util/Bits;' @84 a 'com/sun/tools/javac/util/Bits' (8df8bd10) - 'vars' '[Lcom/sun/tools/javac/code/Symbol$VarSymbol;' @88 a 'com/sun/tools/javac/code/Symbol$VarSymbol'[32] (9cd5a4b8) - 'classDef' 'Lcom/sun/tools/javac/tree/JCTree$JCClassDecl;' @92 a 'com/sun/tools/javac/tree/JCTree$JCClassDecl' (9b4a3fb0) - 'thrown' 'Lcom/sun/tools/javac/util/List;' @96 a 'com/sun/tools/javac/util/List$1' (9b37cdb0) - 'caught' 'Lcom/sun/tools/javac/util/List;' @100 a 'com/sun/tools/javac/util/List' (99cf7b38) - 'unrefdResources' 'Lcom/sun/tools/javac/code/Scope;' @104 a 'com/sun/tools/javac/code/Scope' (8df8baa0) - 'pendingExits' 'Lcom/sun/tools/javac/util/ListBuffer;' @108 a 'com/sun/tools/javac/util/ListBuffer' (8df8bc78) EDX=0x9a5c77e0 is an oop com.sun.tools.javac.tree.JCTree$JCTypeCast - klass: 'com/sun/tools/javac/tree/JCTree$JCTypeCast' - ---- fields (total size 6 words): - public 'pos' 'I' @8 3613 (e1d) - public 'type' 'Lcom/sun/tools/javac/code/Type;' @12 a 'com/sun/tools/javac/code/Type$TypeVar' (991f2310) - public 'clazz' 'Lcom/sun/tools/javac/tree/JCTree;' @16 a 'com/sun/tools/javac/tree/JCTree$JCIdent' (9a692230) - public 'expr' 'Lcom/sun/tools/javac/tree/JCTree$JCExpression;' @20 a 'com/sun/tools/javac/tree/JCTree$JCArrayAccess' (9a692248) ESP=0x88abb50c is pointing into the stack for thread: 0x8925cc00 EBP=0x88abba70 is pointing into the stack for thread: 0x8925cc00 ESI=0x9b5f7338 is an oop com.sun.tools.javac.comp.Flow - klass: 'com/sun/tools/javac/comp/Flow' - ---- fields (total size 28 words): - 'firstadr' 'I' @8 0 - 'nextadr' 'I' @12 0 - private final 'allowImprovedRethrowAnalysis' 'Z' @16 true - private final 'allowImprovedCatchAnalysis' 'Z' @17 true - private 'alive' 'Z' @18 true - 'loopPassTwo' 'Z' @19 false - private final 'names' 'Lcom/sun/tools/javac/util/Names;' @20 a 'com/sun/tools/javac/util/Names' (9b5f6ac0) - private final 'log' 'Lcom/sun/tools/javac/util/Log;' @24 a 'com/sun/tools/javac/util/Log' (9b37cd60) - private final 'syms' 'Lcom/sun/tools/javac/code/Symtab;' @28 a 'com/sun/tools/javac/code/Symtab' (9b5f6c68) - private final 'types' 'Lcom/sun/tools/javac/code/Types;' @32 a 'com/sun/tools/javac/code/Types' (9b5f6df8) - private final 'chk' 'Lcom/sun/tools/javac/comp/Check;' @36 a 'com/sun/tools/javac/comp/Check' (9b5f6d90) - private 'make' 'Lcom/sun/tools/javac/tree/TreeMaker;' @40 a 'com/sun/tools/javac/tree/TreeMaker' (8df8b970) - private final 'rs' 'Lcom/sun/tools/javac/comp/Resolve;' @44 a 'com/sun/tools/javac/comp/Resolve' (9b37c900) - private 'attrEnv' 'Lcom/sun/tools/javac/comp/Env;' @48 a 'com/sun/tools/javac/comp/Env' (9b44b520) - private 'lint' 'Lcom/sun/tools/javac/code/Lint;' @52 a 'com/sun/tools/javac/code/Lint' (9b37caf0) - 'inits' 'Lcom/sun/tools/javac/util/Bits;' @56 a 'com/sun/tools/javac/util/Bits' (8df8bbe0) - 'uninits' 'Lcom/sun/tools/javac/util/Bits;' @60 a 'com/sun/tools/javac/util/Bits' (8df8bc00) - 'preciseRethrowTypes' 'Ljava/util/HashMap;' @64 a 'java/util/HashMap' (8df8ba28) - 'uninitsTry' 'Lcom/sun/tools/javac/util/Bits;' @68 a 'com/sun/tools/javac/util/Bits' (8df8b9e0) - 'initsWhenTrue' 'Lcom/sun/tools/javac/util/Bits;' @72 a 'com/sun/tools/javac/util/Bits' (8df8bbe0) - 'initsWhenFalse' 'Lcom/sun/tools/javac/util/Bits;' @76 a 'com/sun/tools/javac/util/Bits' (8df8bcf0) - 'uninitsWhenTrue' 'Lcom/sun/tools/javac/util/Bits;' @80 a 'com/sun/tools/javac/util/Bits' (8df8bc00) - 'uninitsWhenFalse' 'Lcom/sun/tools/javac/util/Bits;' @84 a 'com/sun/tools/javac/util/Bits' (8df8bd10) - 'vars' '[Lcom/sun/tools/javac/code/Symbol$VarSymbol;' @88 a 'com/sun/tools/javac/code/Symbol$VarSymbol'[32] (9cd5a4b8) - 'classDef' 'Lcom/sun/tools/javac/tree/JCTree$JCClassDecl;' @92 a 'com/sun/tools/javac/tree/JCTree$JCClassDecl' (9b4a3fb0) - 'thrown' 'Lcom/sun/tools/javac/util/List;' @96 a 'com/sun/tools/javac/util/List$1' (9b37cdb0) - 'caught' 'Lcom/sun/tools/javac/util/List;' @100 a 'com/sun/tools/javac/util/List' (99cf7b38) - 'unrefdResources' 'Lcom/sun/tools/javac/code/Scope;' @104 a 'com/sun/tools/javac/code/Scope' (8df8baa0) - 'pendingExits' 'Lcom/sun/tools/javac/util/ListBuffer;' @108 a 'com/sun/tools/javac/util/ListBuffer' (8df8bc78) EDI=0x9b5f7338 is an oop com.sun.tools.javac.comp.Flow - klass: 'com/sun/tools/javac/comp/Flow' - ---- fields (total size 28 words): - 'firstadr' 'I' @8 0 - 'nextadr' 'I' @12 0 - private final 'allowImprovedRethrowAnalysis' 'Z' @16 true - private final 'allowImprovedCatchAnalysis' 'Z' @17 true - private 'alive' 'Z' @18 true - 'loopPassTwo' 'Z' @19 false - private final 'names' 'Lcom/sun/tools/javac/util/Names;' @20 a 'com/sun/tools/javac/util/Names' (9b5f6ac0) - private final 'log' 'Lcom/sun/tools/javac/util/Log;' @24 a 'com/sun/tools/javac/util/Log' (9b37cd60) - private final 'syms' 'Lcom/sun/tools/javac/code/Symtab;' @28 a 'com/sun/tools/javac/code/Symtab' (9b5f6c68) - private final 'types' 'Lcom/sun/tools/javac/code/Types;' @32 a 'com/sun/tools/javac/code/Types' (9b5f6df8) - private final 'chk' 'Lcom/sun/tools/javac/comp/Check;' @36 a 'com/sun/tools/javac/comp/Check' (9b5f6d90) - private 'make' 'Lcom/sun/tools/javac/tree/TreeMaker;' @40 a 'com/sun/tools/javac/tree/TreeMaker' (8df8b970) - private final 'rs' 'Lcom/sun/tools/javac/comp/Resolve;' @44 a 'com/sun/tools/javac/comp/Resolve' (9b37c900) - private 'attrEnv' 'Lcom/sun/tools/javac/comp/Env;' @48 a 'com/sun/tools/javac/comp/Env' (9b44b520) - private 'lint' 'Lcom/sun/tools/javac/code/Lint;' @52 a 'com/sun/tools/javac/code/Lint' (9b37caf0) - 'inits' 'Lcom/sun/tools/javac/util/Bits;' @56 a 'com/sun/tools/javac/util/Bits' (8df8bbe0) - 'uninits' 'Lcom/sun/tools/javac/util/Bits;' @60 a 'com/sun/tools/javac/util/Bits' (8df8bc00) - 'preciseRethrowTypes' 'Ljava/util/HashMap;' @64 a 'java/util/HashMap' (8df8ba28) - 'uninitsTry' 'Lcom/sun/tools/javac/util/Bits;' @68 a 'com/sun/tools/javac/util/Bits' (8df8b9e0) - 'initsWhenTrue' 'Lcom/sun/tools/javac/util/Bits;' @72 a 'com/sun/tools/javac/util/Bits' (8df8bbe0) - 'initsWhenFalse' 'Lcom/sun/tools/javac/util/Bits;' @76 a 'com/sun/tools/javac/util/Bits' (8df8bcf0) - 'uninitsWhenTrue' 'Lcom/sun/tools/javac/util/Bits;' @80 a 'com/sun/tools/javac/util/Bits' (8df8bc00) - 'uninitsWhenFalse' 'Lcom/sun/tools/javac/util/Bits;' @84 a 'com/sun/tools/javac/util/Bits' (8df8bd10) - 'vars' '[Lcom/sun/tools/javac/code/Symbol$VarSymbol;' @88 a 'com/sun/tools/javac/code/Symbol$VarSymbol'[32] (9cd5a4b8) - 'classDef' 'Lcom/sun/tools/javac/tree/JCTree$JCClassDecl;' @92 a 'com/sun/tools/javac/tree/JCTree$JCClassDecl' (9b4a3fb0) - 'thrown' 'Lcom/sun/tools/javac/util/List;' @96 a 'com/sun/tools/javac/util/List$1' (9b37cdb0) - 'caught' 'Lcom/sun/tools/javac/util/List;' @100 a 'com/sun/tools/javac/util/List' (99cf7b38) - 'unrefdResources' 'Lcom/sun/tools/javac/code/Scope;' @104 a 'com/sun/tools/javac/code/Scope' (8df8baa0) - 'pendingExits' 'Lcom/sun/tools/javac/util/ListBuffer;' @108 a 'com/sun/tools/javac/util/ListBuffer' (8df8bc78) Stack: [0x88a6b000,0x88abc000], sp=0x88abb50c, free space=321k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) v ~BufferBlob::vtable chunks j com.sun.tools.javac.main.JavaCompiler.flow(Lcom/sun/tools/javac/comp/Env;)Ljava/util/Queue;+7 j com.sun.tools.javac.main.JavaCompiler.compile2()V+180 j com.sun.tools.javac.main.JavaCompiler.compile(Lcom/sun/tools/javac/util/List;Lcom/sun/tools/javac/util/List;Ljava/lang/Iterable;)V+159 j com.sun.tools.javac.main.Main.compile([Ljava/lang/String;[Ljava/lang/String;Lcom/sun/tools/javac/util/Context;Lcom/sun/tools/javac/util/List;Ljava/lang/Iterable;)I+761 j com.sun.tools.javac.main.Main.compile([Ljava/lang/String;Lcom/sun/tools/javac/util/Context;Lcom/sun/tools/javac/util/List;Ljava/lang/Iterable;)I+7 j com.sun.tools.javac.main.Main.compile([Ljava/lang/String;Lcom/sun/tools/javac/util/Context;)I+7 j com.sun.tools.javac.main.Main.compile([Ljava/lang/String;)I+15 j com.sun.tools.javac.Main.compile([Ljava/lang/String;)I+12 j com.sun.tools.javac.Main.main([Ljava/lang/String;)V+97 v ~StubRoutines::call_stub V [libjvm.so+0x455857] AsyncGetCallTrace+0xd0e77 V [libjvm.so+0x6c0a59] JVM_RegisterSignal+0x18aca9 V [libjvm.so+0x453e47] AsyncGetCallTrace+0xcf467 V [libjvm.so+0x46d556] JNI_CreateJavaVM+0x4c6 V [libjvm.so+0x476d8b] JNI_CreateJavaVM+0x9cfb C [java+0x5997] JavaMain+0xe07 C [libpthread.so.17.0+0x610e] pthread_testcancel+0xbe --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x895bac00 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=2093874176, stack(0x7ea45000,0x7ea96000)] 0x891d6400 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=2131537152, stack(0x8053f000,0x805c0000)] 0x82c14c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2131536128, stack(0x85039000,0x8508a000)] 0x8b22bc00 JavaThread "Finalizer" daemon [_thread_blocked, id=2131534592, stack(0x81526000,0x81577000)] 0x819d0c00 JavaThread "Reference Handler" daemon [_thread_blocked, id=2131517440, stack(0x7e24d000,0x7e29e000)] =>0x8925cc00 JavaThread "main" [_thread_in_Java, id=-2122977024, stack(0x88a6b000,0x88abc000)] Other Threads: 0x7efba400 VMThread [stack: 0x810de000,0x8115f000] [id=2131518208] 0x7c50c400 WatcherThread [stack: 0x83407000,0x83488000] [id=-2106322944] VM state:synchronizing (normal execution) VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) [0x8209ac18] Safepoint_lock - owner thread: 0x7efba400 [0x8209a418] Threads_lock - owner thread: 0x7efba400 Heap def new generation total 157248K, used 10586K [0x8df70000, 0x98a10000, 0x98a10000) eden space 139776K, 2% used [0x8df70000, 0x8e23bcb0, 0x967f0000) from space 17472K, 44% used [0x97900000, 0x9808af08, 0x98a10000) to space 17472K, 0% used [0x967f0000, 0x967f0000, 0x97900000) tenured generation total 349568K, used 84379K [0x98a10000, 0xadf70000, 0xadf70000) the space 349568K, 24% used [0x98a10000, 0x9dc76dc8, 0x9dc76e00, 0xadf70000) compacting perm gen total 32768K, used 5458K [0xadf70000, 0xaff70000, 0xb7f70000) the space 32768K, 16% used [0xadf70000, 0xae4c4958, 0xae4c4a00, 0xaff70000) No shared spaces configured. Code Cache [0x8bf64000, 0x8c444000, 0x8df64000) total_blobs=1761 nmethods=1636 adapters=68 free_code_cache=28473664 largest_free_block=448 Dynamic libraries: Error: Cannot print dynamic libraries. VM Arguments: jvm_args: -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m -Xbootclasspath/p:/usr/obj/i386/ports/jdk-1.7.0.11/openjdk/build/bsd-i586/langtools/dist/bootstrap/lib/javac.jar java_command: /usr/obj/i386/ports/jdk-1.7.0.11/openjdk/build/bsd-i586/langtools/dist/bootstrap/lib/javac.jar -source 7 -target 7 -encoding ascii -Xbootclasspath:/usr/obj/i386/ports/jdk-1.7.0.11/openjdk/build/bsd-i586/classes -sourcepath /usr/obj/i386/ports/jdk-1.7.0.11/openjdk/build/bsd-i586/gensrc:::/usr/obj/i386/ports/jdk-1.7.0.11/openjdk/jdk/src/macosx/classes:/usr/obj/i386/ports/jdk-1.7.0.11/openjdk/jdk/src/solaris/classes:/usr/obj/i386/ports/jdk-1.7.0.11/openjdk/jdk/src/share/classes -d /usr/obj/i386/ports/jdk-1.7.0.11/openjdk/build/bsd-i586/classes @/usr/obj/i386/ports/jdk-1.7.0.11/openjdk/build/bsd-i586/tmp/java/java.lang/java/.classes.list.filtered Launcher Type: SUN_STANDARD Environment Variables: PATH=/usr/obj/i386/ports/jdk-1.7.0.11/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/bin:/usr/X11R6/bin USERNAME=truk LD_LIBRARY_PATH=/usr/local/jdk-1.6.0/jre/lib/i386/client:/usr/local/jdk-1.6.0/jre/lib/i386:/usr/local/jdk-1.6.0/jre/../lib/i386 Signal Handlers: SIGSEGV: [libjvm.so+0x839cb0], sa_mask[0]=0x7ffefaff, sa_flags=0x00000042 SIGBUS: [libjvm.so+0x839cb0], sa_mask[0]=0x7ffefcff, sa_flags=0x00000042 SIGFPE: [libjvm.so+0x6c2140], sa_mask[0]=0x7ffefe7f, sa_flags=0x00000042 SIGPIPE: [libjvm.so+0x6c2140], sa_mask[0]=0x7ffeeeff, sa_flags=0x00000042 SIGXFSZ: [libjvm.so+0x6c2140], sa_mask[0]=0x7efefeff, sa_flags=0x00000042 SIGILL: [libjvm.so+0x6c2140], sa_mask[0]=0x7ffefef7, sa_flags=0x00000042 SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000002 SIGUSR2: [libjvm.so+0x6c5df0], sa_mask[0]=0x00000000, sa_flags=0x00000042 SIGHUP: [libjvm.so+0x6c5870], sa_mask[0]=0x7ffefefe, sa_flags=0x00000042 SIGINT: [libjvm.so+0x6c5870], sa_mask[0]=0x7ffefefd, sa_flags=0x00000042 SIGTERM: [libjvm.so+0x6c5870], sa_mask[0]=0x7ffebeff, sa_flags=0x00000042 SIGQUIT: [libjvm.so+0x6c5870], sa_mask[0]=0x7ffefefb, sa_flags=0x00000042 --------------- S Y S T E M --------------- OS:Bsd uname:OpenBSD 5.2 GENERIC.MP#20 i386 rlimit: STACK 4096k, CORE infinity, NPROC 1310, NOFILE 1024 CPU:total 4 (2 cores per cpu, 1 threads per core) family 15 model 65 stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3, mmxext, 3dnowpref Memory: 4k page, physical 2097152k(524288k free) vm_info: OpenJDK Client VM (20.0-b12-fastdebug) for bsd-x86 JRE (1.6.0_32-fastdebug-b27), built on Feb 1 2013 15:49:17 by "truk" with gcc 4.2.1 20070719 time: Fri Feb 1 18:02:25 2013 elapsed time: 24 seconds From david.holmes at oracle.com Sat Feb 2 20:53:43 2013 From: david.holmes at oracle.com (David Holmes) Date: Sun, 03 Feb 2013 14:53:43 +1000 Subject: RFR(XXS): 8007312: null check signal semaphore in os::signal_notify windows In-Reply-To: <6eb127b1-4422-4889-91db-e2ecbf11b942@default> References: <092ccf0f-36a6-4e5b-aa73-e06bff290585@default> <510B48A6.7060500@oracle.com> <9fa18ccc-b229-47c0-b7e6-5b988903c1b6@default> <510BA7C9.1020000@oracle.com> <513992b6-653b-4c3a-a605-73a8db5b8d8f@default> <510BAF2A.4080502@oracle.com> <0198a899-c8a8-4fa0-8232-bd2464be599e@default> <510BC5E7.7040001@oracle.com> <7705a335-1d80-4ac8-a32b-94dea26ccf30@default> <510C4566.2000401@oracle.com> <510D0DEB.50808@oracle.com> <9ec0522f-2a50-45e3-890c-381221ef7749@default> <6eb127b1-4422-4889-91db-e2ecbf11b942@default> Message-ID: <510DED57.8010404@oracle.com> Thanks for looking that up :) I think we've gone way beyond due diligence on this one. FYI in my testing the other thing I saw was that by this stage both the ReferenceHandler thread and the Finalizer thread, are created and running. So creating the Signal handler thread earlier - if in the future it should seem necessary - seems reasonably safe. Thanks, David On 3/02/2013 1:25 AM, Markus Gr?nlund wrote: > And it doesn't look like sema_post() do check for it (it only checks to see if the semaphore value pointed to by sp exceeds SEM_VALUE_MAX). > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/threads/sema.c#297 > > sema_post() could probably be extended to also check for sp->magic == SEMA_MAGIC to ensure that the call is on a valid (initialized), semaphore. > > Cheers > Markus > > > -----Original Message----- > From: Markus Gr?nlund > Sent: den 2 februari 2013 16:03 > To: David Holmes > Cc: hotspot-dev at openjdk.java.net > Subject: RE: RFR(XXS): 8007312: null check signal semaphore in os::signal_notify windows > > Thanks for checking. This matches the initial quick tests I did on Solaris as well. > > "Curiously nothing. I put an infinite_sleep at the start of os::signal_init. On both linux and solaris ctrl-c did nothing while ctrl-/ (SIGQUIT) induced a core dump - as expected. No assertions triggered. It did show UserHandler was installed though. > > Maybe the ::sema_post(&sig_sem); is not issuing a non-zero return value when called on an non-sema_init:ed sema_t? (this is where I would expect something to happen, linux or bsd does not have any asserts on this). > > Thanks for verifying UserHandler() installation here. > > Cheers > Markus > > -----Original Message----- > From: David Holmes > Sent: den 2 februari 2013 14:00 > To: Markus Gr?nlund > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR(XXS): 8007312: null check signal semaphore in os::signal_notify windows > > On 2/02/2013 8:44 AM, David Holmes wrote: >> On 2/02/2013 12:49 AM, Markus Gr?nlund wrote: >>> Thanks David, >>> >>> Ok, so based on our discussions, we'll narrow this to only do a null >>> check on the signal semaphore handle on Windows. >>> >>> I have updated the webrev, here: >>> http://cr.openjdk.java.net/~mgronlun/8007312/webrev02/ >> >> Looks okay to me. >> >> I'll try to test out what happens on Solaris/Linux if you manage to >> sneak in a very early ctrl-C. > > Curiously nothing. I put an infinite_sleep at the start of os::signal_init. On both linux and solaris ctrl-c did nothing while ctrl-/ (SIGQUIT) induced a core dump - as expected. No assertions triggered. It did show UserHandler was installed though. > > Can't test windows. > > David > ----- > >> Thanks, >> David >> >>> >>> Also I changed the bug description to reflect the updated information >>> (to the updated subject in the mail above): >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007312 >>> >>> >>> With this change we don't trap on the assert when pressing ctrl-c if >>> the hotspot signal handler is not setup. >>> >>> Thanks a lot for your help David, have a great weekend. >>> >>> Cheers >>> Markus >>> >>> >>> >>> -----Original Message----- >>> From: David Holmes >>> Sent: den 1 februari 2013 14:41 >>> To: Markus Gr?nlund >>> Cc: hotspot-dev at openjdk.java.net >>> Subject: Re: RFR(XXS): 8007312: Signal Dispatcher thread to start and >>> register ctrl-break handler before TRACE_INITIALIZE >>> >>> Which brings us back to simply checking for not being initialized. >>> >>> David >>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> (windows analysis) >>>>>>> >>>>>>> >>>>>>> >>>>>>> Pressing ctrl-c before Hotspot signal/console handler has been >>>>>>> registered actually asserts/stops the VM (which to the user >>>>>>> appears like a crash) on non-product builds. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Before Hotspot registers its own jvm!consoleHandler with >>>>>>> kernel32!CtrlRoutine, the C runtime default >>>>>>> msvcr100!ctrlevent_capture is implicitly used - this calls back >>>>>>> into jvm!UserHandler, which forwards into os::signal_notify() >>>>>>> which uses uninitialized variables. >>>>>>> >>>>>>> >>>>>>> >>>>>>> // on Windows this creates the following issue when closing a >>>>>>> NULL handle to a semaphore >>>>>>> >>>>>>> >>>>>>> >>>>>>> void os::signal_notify(int signal_number) { >>>>>>> >>>>>>> BOOL ret; >>>>>>> >>>>>>> >>>>>>> Atomic::inc(&pending_signals[signal_number]); >>>>>>> >>>>>>> ret = ::ReleaseSemaphore(sig_sem, 1, NULL);<<--- call >>>>>>> ReleaseSemaphore on global handle sig_sem which has not been >>>>>>> setup/created yet == is NULL (is created in os::signal_init_pd()) >>>>>>> >>>>>>> assert(ret != 0, "ReleaseSemaphore() failed");<<-- assert traps >>>>>>> here (GetLastError() == 0xc0000008 - An invalid HANDLE was >>>>>>> specified) >>>>>>> >>>>>>> >>>>>>> >>>>>>> } >>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Markus From oehrstroem at gmail.com Mon Feb 4 01:04:30 2013 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Mon, 4 Feb 2013 10:04:30 +0100 Subject: This simple patch doubles the compile-speed of the hotspot repo on Windows In-Reply-To: <76DC1CA3-E0C7-4A2D-9E3D-4523C6A3D536@oracle.com> References: <76DC1CA3-E0C7-4A2D-9E3D-4523C6A3D536@oracle.com> Message-ID: Issue filed, on its way in: http://cr.openjdk.java.net/~ohrstrom/webrev-8007446-add-MP/ //Fredrik 2013/2/2 Kelly O'Hair : > Great stuff. Have you filed an issue on this? Or shall I? > > > -kto > > On Feb 1, 2013, at 4:58 AM, Fredrik ?hrstr?m wrote: > >> ie. use /MP on the cl.exe command line. >> >> On the build machine (Windows Server 2007, Visual Studio 2010, 32 HT >> cores, 64GB ram) configuring with: >> >> sh configure --enable-sjavac >> --with-freetype=/cygdrive/d/tools/freetype-amd64 >> --with-boot-jdk=/cygdrive/d/java/jdk-7-fcs-bin-b147/ >> >> (You need to patch >> src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java >> line 256, change equals("windows)" to startswith("windows), this fix >> is going into tl soon.) >> >> Without MP >> ----- Build times ------- >> Start 2013-02-01 12:23:50 >> End 2013-02-01 12:35:20 >> 00:00:32 corba >> 00:04:43 hotspot >> 00:00:15 jaxp >> 00:00:24 jaxws >> 00:04:49 jdk >> 00:00:46 langtools >> 00:11:30 TOTAL >> ------------------------- >> >> With MP >> ----- Build times ------- >> Start 2013-02-01 12:54:54 >> End 2013-02-01 13:03:56 >> 00:00:31 corba >> 00:02:20 hotspot >> 00:00:14 jaxp >> 00:00:22 jaxws >> 00:04:44 jdk >> 00:00:46 langtools >> 00:09:02 TOTAL >> ------------------------- >> >> For such a simple patch it is a nice speedup. Please test and see if >> it improves the speed on your multi core machines. >> >> //Fredrik >> >> Oh, and for reference this is the speed without sjavac but with /MP. >> >> ----- Build times ------- >> Start 2013-02-01 13:39:38 >> End 2013-02-01 13:51:46 >> 00:00:35 corba >> 00:02:24 hotspot >> 00:00:28 jaxp >> 00:00:36 jaxws >> 00:07:11 jdk >> 00:00:48 langtools >> 00:12:08 TOTAL >> ------------------------- >> >> $ hg diff >> diff -r 67498c863813 make/windows/makefiles/compile.make >> --- a/make/windows/makefiles/compile.make Thu Jan 17 12:16:06 2013 +0100 >> +++ b/make/windows/makefiles/compile.make Fri Feb 01 13:05:08 2013 +0100 >> @@ -44,6 +44,7 @@ >> # /GS Inserts security stack checks in some functions (VS2005 default) >> # /Oi Use intrinsics (in /O2) >> # /Od Disable all optimizations >> +# /MP Use multiple cores for compilation >> # >> # NOTE: Normally following any of the above with a '-' will turn off that flag >> # >> @@ -52,7 +53,7 @@ >> # improving the quality of crash log stack traces involving jvm.dll. >> >> # These are always used in all compiles >> -CXX_FLAGS=/nologo /W3 /WX >> +CXX_FLAGS=/nologo /W3 /WX /MP >> >> # Let's add debug information when Full Debug Symbols is enabled >> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >> diff -r 67498c863813 make/windows/makefiles/sa.make >> --- a/make/windows/makefiles/sa.make Thu Jan 17 12:16:06 2013 +0100 >> +++ b/make/windows/makefiles/sa.make Fri Feb 01 13:05:08 2013 +0100 >> @@ -108,6 +108,8 @@ >> SA_LFLAGS = $(SA_LFLAGS) -map -debug >> !endif >> >> +SA_CFLAGS = $(SA_CFLAGS) -MP >> + >> # Note that we do not keep sawindbj.obj around as it would then >> # get included in the dumpbin command in build_vm_def.sh > From volker.simonis at gmail.com Mon Feb 4 01:44:10 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 4 Feb 2013 10:44:10 +0100 Subject: RFC: deprecating SPARC V8 support? In-Reply-To: <78B9ADEE-9C1F-4EF3-9961-9781B45640FE@oracle.com> References: <78B9ADEE-9C1F-4EF3-9961-9781B45640FE@oracle.com> Message-ID: We (i.e. SAP) don't use it. Regards, Volker On Sat, Feb 2, 2013 at 3:15 AM, Christian Thalinger < christian.thalinger at oracle.com> wrote: > Hello Community! > > We are playing with the idea to deprecate SPARC V8 support in HotSpot and > I would like to get some input from the OpenJDK community (especially from > the usual suspects: SAP, RedHat, Debian, ...). > > Is anyone out there still using SPARC V8 hardware or is supporting it? > > -- Chris From mikael.gerdin at oracle.com Mon Feb 4 05:59:39 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 04 Feb 2013 14:59:39 +0100 Subject: Review request: JDK-8006753 fix failed for JDK-8002415 White box testing API for HotSpot Message-ID: <510FBECB.6050903@oracle.com> Hi, Background: Even from the beginning of the WhiteBox testing API implementation the tests have not worked on builds promoted by release engineering due to the fact that the wb.jar file containing the Java classes was not imported by the JDK-level makefiles. On one level this was ok since we didn't want to ship the classes to end users and we worked around the complexity of somehow post-processing the RE bundles to remove them. The problem is that we aren't able to run the WhiteBox tests in promotion testing, or to verify fixes against earlier builds. Solution: The solution suggested here is to put the WhiteBox helper classes in the testlibrary directory under test/ and * tell jtreg to first compile the classes * run a special Java program to copy the classes to the test work directory * run the white box test with -Xbootclasspath/a:. to pick up the copied classes. The solution is kind-of hackish but I've been unable to come up with a better solution without performing complex surgery on jtreg. The changes to the make/ directory should basically revert the makefile changes that were added to support this API. Webrev: http://cr.openjdk.java.net/~mgerdin/8006753/webrev.0/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006753 Note about renamed/moved files: I will try to make sure that the moved/renamed files will be tracked properly by mercurial, but I think that using patch files and MQ breaks this so I'll do this after the review is done. Thanks /Mikael From christian.tornqvist at oracle.com Mon Feb 4 06:19:54 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Mon, 4 Feb 2013 06:19:54 -0800 (PST) Subject: Review request: JDK-8006753 fix failed for JDK-8002415 White box testing API for HotSpot In-Reply-To: <510FBECB.6050903@oracle.com> References: <510FBECB.6050903@oracle.com> Message-ID: <11c637c3-cb38-4388-844e-29f0402a751f@default> Looks good! Thanks, Christian -----Original Message----- From: Mikael Gerdin Sent: den 4 februari 2013 15:00 To: hotspot-dev at openjdk.java.net Subject: Review request: JDK-8006753 fix failed for JDK-8002415 White box testing API for HotSpot Hi, Background: Even from the beginning of the WhiteBox testing API implementation the tests have not worked on builds promoted by release engineering due to the fact that the wb.jar file containing the Java classes was not imported by the JDK-level makefiles. On one level this was ok since we didn't want to ship the classes to end users and we worked around the complexity of somehow post-processing the RE bundles to remove them. The problem is that we aren't able to run the WhiteBox tests in promotion testing, or to verify fixes against earlier builds. Solution: The solution suggested here is to put the WhiteBox helper classes in the testlibrary directory under test/ and * tell jtreg to first compile the classes * run a special Java program to copy the classes to the test work directory * run the white box test with -Xbootclasspath/a:. to pick up the copied classes. The solution is kind-of hackish but I've been unable to come up with a better solution without performing complex surgery on jtreg. The changes to the make/ directory should basically revert the makefile changes that were added to support this API. Webrev: http://cr.openjdk.java.net/~mgerdin/8006753/webrev.0/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006753 Note about renamed/moved files: I will try to make sure that the moved/renamed files will be tracked properly by mercurial, but I think that using patch files and MQ breaks this so I'll do this after the review is done. Thanks /Mikael From rickard.backman at oracle.com Mon Feb 4 06:25:36 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Mon, 04 Feb 2013 14:25:36 +0000 Subject: hg: hsx/hsx24/hotspot: 8006563: Remove unused ProfileVM_lock Message-ID: <20130204142541.4472B477E1@hg.openjdk.java.net> Changeset: a47566645421 Author: rbackman Date: 2013-01-18 13:43 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a47566645421 8006563: Remove unused ProfileVM_lock Reviewed-by: dholmes, sla ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp From christian.thalinger at oracle.com Mon Feb 4 08:31:04 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 4 Feb 2013 08:31:04 -0800 Subject: RFC: deprecating SPARC V8 support? In-Reply-To: References: <78B9ADEE-9C1F-4EF3-9961-9781B45640FE@oracle.com> Message-ID: Thanks for confirming, Volker. -- Chris On Feb 4, 2013, at 1:44 AM, Volker Simonis wrote: > We (i.e. SAP) don't use it. > > Regards, > Volker > > > > On Sat, Feb 2, 2013 at 3:15 AM, Christian Thalinger wrote: >> Hello Community! >> >> We are playing with the idea to deprecate SPARC V8 support in HotSpot and I would like to get some input from the OpenJDK community (especially from the usual suspects: SAP, RedHat, Debian, ...). >> >> Is anyone out there still using SPARC V8 hardware or is supporting it? >> >> -- Chris > From staffan.larsen at oracle.com Mon Feb 4 10:25:43 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 4 Feb 2013 19:25:43 +0100 Subject: CFV: New HSX Committer: Serguei Spitsyn Message-ID: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> I hereby nominate Serguei Spitsyn (OpenJDK user name: sspitsyn) to HSX Committer. Serguei is a member of the Hotspot Serviceability team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=serguei.spitsyn at oracle.com Votes are due by February 18, 2013. Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Staffan [1]http://openjdk.java.net/projects/#project-committer [2]http://openjdk.java.net/census#hsx [3]http://openjdk.java.net/projects#committer-vote From coleen.phillimore at oracle.com Mon Feb 4 10:35:45 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 04 Feb 2013 13:35:45 -0500 Subject: CFV: New HSX Committer: Serguei Spitsyn In-Reply-To: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> References: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> Message-ID: <510FFF81.2010704@oracle.com> Vote: yes On 2/4/2013 1:25 PM, Staffan Larsen wrote: > I hereby nominate Serguei Spitsyn (OpenJDK user name: sspitsyn) to HSX Committer. > > Serguei is a member of the Hotspot Serviceability team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=serguei.spitsyn at oracle.com > > Votes are due by February 18, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Staffan > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote From daniel.daugherty at oracle.com Mon Feb 4 10:37:16 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 04 Feb 2013 11:37:16 -0700 Subject: CFV: New HSX Committer: Serguei Spitsyn In-Reply-To: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> References: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> Message-ID: <510FFFDC.70608@oracle.com> Vote: yes Dan On 2/4/13 11:25 AM, Staffan Larsen wrote: > I hereby nominate Serguei Spitsyn (OpenJDK user name: sspitsyn) to HSX Committer. > > Serguei is a member of the Hotspot Serviceability team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=serguei.spitsyn at oracle.com > > Votes are due by February 18, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Staffan > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote From karen.kinnear at oracle.com Mon Feb 4 10:41:33 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 4 Feb 2013 13:41:33 -0500 Subject: CFV: New HSX Committer: Serguei Spitsyn In-Reply-To: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> References: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> Message-ID: Vote: yes On Feb 4, 2013, at 1:25 PM, Staffan Larsen wrote: > I hereby nominate Serguei Spitsyn (OpenJDK user name: sspitsyn) to HSX Committer. > > Serguei is a member of the Hotspot Serviceability team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=serguei.spitsyn at oracle.com > > Votes are due by February 18, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Staffan > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote From zhengyu.gu at oracle.com Mon Feb 4 10:49:18 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Mon, 04 Feb 2013 13:49:18 -0500 Subject: CFV: New HSX Committer: Serguei Spitsyn In-Reply-To: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> References: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> Message-ID: <511002AE.1060109@oracle.com> Vote: yes -Zhengyu On 2/4/2013 1:25 PM, Staffan Larsen wrote: > I hereby nominate Serguei Spitsyn (OpenJDK user name: sspitsyn) to HSX Committer. > > Serguei is a member of the Hotspot Serviceability team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=serguei.spitsyn at oracle.com > > Votes are due by February 18, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Staffan > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote From christian.tornqvist at oracle.com Mon Feb 4 10:51:11 2013 From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com) Date: Mon, 04 Feb 2013 18:51:11 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130204185118.5C333477F4@hg.openjdk.java.net> Changeset: 1689a0912ebe Author: ctornqvi Date: 2013-02-04 08:40 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1689a0912ebe 8006413: Add utility classes for writing better multiprocess tests in jtreg Summary: Add a few utility classes to test/testlibrary to support multi process testing in jtreg tests. Added a test case for one of the utility classes. Also reviewed by Vitaly Davidovich Reviewed-by: brutisso, dholmes, vlivanov, nloodin, mgerdin + test/testlibrary/OutputAnalyzerTest.java + test/testlibrary/com/oracle/java/testlibrary/JDKToolFinder.java + test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java + test/testlibrary/com/oracle/java/testlibrary/OutputBuffer.java + test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java + test/testlibrary/com/oracle/java/testlibrary/StreamPumper.java Changeset: 77726262b76f Author: ctornqvi Date: 2013-02-04 09:28 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/77726262b76f Merge From kelly.ohair at oracle.com Mon Feb 4 11:16:11 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 4 Feb 2013 11:16:11 -0800 Subject: CFV: New HSX Committer: Serguei Spitsyn In-Reply-To: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> References: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> Message-ID: Vote: yes -kto On Feb 4, 2013, at 10:25 AM, Staffan Larsen wrote: > I hereby nominate Serguei Spitsyn (OpenJDK user name: sspitsyn) to HSX Committer. > > Serguei is a member of the Hotspot Serviceability team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=serguei.spitsyn at oracle.com > > Votes are due by February 18, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Staffan > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote From dmitry.samersoff at oracle.com Mon Feb 4 11:26:14 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 04 Feb 2013 23:26:14 +0400 Subject: CFV: New HSX Committer: Serguei Spitsyn In-Reply-To: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> References: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> Message-ID: <51100B56.80008@oracle.com> Vote: yes On 2013-02-04 22:25, Staffan Larsen wrote: > I hereby nominate Serguei Spitsyn (OpenJDK user name: sspitsyn) to HSX Committer. > > Serguei is a member of the Hotspot Serviceability team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=serguei.spitsyn at oracle.com > > Votes are due by February 18, 2013. > ote > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Staffan > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From vladimir.kozlov at oracle.com Mon Feb 4 11:49:31 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 04 Feb 2013 11:49:31 -0800 Subject: CFV: New HSX Committer: Serguei Spitsyn In-Reply-To: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> References: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> Message-ID: <511010CB.5080600@oracle.com> Vote: yes On 2/4/13 10:25 AM, Staffan Larsen wrote: > I hereby nominate Serguei Spitsyn (OpenJDK user name: sspitsyn) to HSX Committer. > > Serguei is a member of the Hotspot Serviceability team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=serguei.spitsyn at oracle.com > > Votes are due by February 18, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Staffan > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From vladimir.x.ivanov at oracle.com Mon Feb 4 12:53:32 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 04 Feb 2013 23:53:32 +0300 Subject: CFV: New HSX Committer: Serguei Spitsyn In-Reply-To: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> References: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> Message-ID: <51101FCC.5070304@oracle.com> Vote: yes On 2/4/13 9:25 PM, Staffan Larsen wrote: > I hereby nominate Serguei Spitsyn (OpenJDK user name: sspitsyn) to HSX Committer. > > Serguei is a member of the Hotspot Serviceability team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=serguei.spitsyn at oracle.com > > Votes are due by February 18, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Staffan > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From alejandro.murillo at oracle.com Mon Feb 4 12:21:05 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 04 Feb 2013 13:21:05 -0700 Subject: CFV: New HSX Committer: Serguei Spitsyn In-Reply-To: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> References: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> Message-ID: <51101831.2000308@oracle.com> vote: yes -- Alejandro From david.holmes at oracle.com Mon Feb 4 12:51:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 05 Feb 2013 06:51:01 +1000 Subject: Request for review: JDK-8003581, , UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS In-Reply-To: <51100159.6010103@oracle.com> References: <51100159.6010103@oracle.com> Message-ID: <51101F35.3070402@oracle.com> On 5/02/2013 4:43 AM, Chris Plummer wrote: > Hi David, > > It's not the case that only serialGC is available on embedded or ARM. Thanks. In that case it is not right to treat UseG1Gc the same as the other flags and this code is incorrect: 3168 #if (defined JAVASE_EMBEDDED || defined ARM || !INCLUDE_ALL_GCS) 3169 if (UseG1GC) { 3170 UNSUPPORTED_GC_OPTION(UseG1GC); 3171 } 3172 #endif This needs to be broken into two cases, the original 3153 #if (defined JAVASE_EMBEDDED || defined ARM) 3154 UNSUPPORTED_OPTION(UseG1GC, "G1 GC"); 3155 #endif plus the missing case: 3174 #if !INCLUDE_ALL_GCS if (UseG1GC) { UNSUPPORTED_GC_OPTION(UseG1GC); } ... > Here's the breakdown of which GCs are available for each supported build: > > * JDK builds (except ARM) > o Detected with "#if !defined(JAVASE_EMBEDDED) && !defined(ARM)" > o All GCs available > * ARM JDK Build > o Detected with "#if !defined(JAVASE_EMBEDDED) && defined(ARM)" > o All GCs except G1 > * Embedded Builds (except MinimalVM) > o Detected with "#if defined(JAVASE_EMBEDDED) && INCLUDE_ALL_GCS" > o All GCs except G1 > * Embedded MinimalVM Builds > o Detected with "#if defined(JAVASE_EMBEDDED) && !INCLUDE_ALL_GCS" > o Only SerialGC > > Other combinations are possible (for example, a MinimalVM JDK build), > but the above are the supported builds. However, there are probably > better ways of checking the above flags to determine which GCs are > available, and also capture the unsupported builds. I think the > following is probably the simplest: > > #if INCLUDE_ALL_GCS > #if defined(JAVASE_EMBEDDED) || defined(ARM) > all GC's except G1 supported > #else > all GC's support > #endif > #else > only SerialGC supported. > #endif Yes, where the only serialGC supported could be a call to force_serial_gc() which in turn calls the UNSUPPORTED_GC_OPTION as below. David ------ > Chris > > > On 2/1/13 12:17 AM, David Holmes wrote: >> Hi Joe, >> >> I think you could simplify this further by deleting lines 3168 - 3186 >> and change force_serial_gc() to do: >> >> static void force_serial_gc() { >> FLAG_SET_DEFAULT(UseSerialGC, true); >> UNSUPPORTED_GC_OPTION(UseG1GC); >> UNSUPPORTED_GC_OPTION(UseParallelGC); >> UNSUPPORTED_GC_OPTION(UseParallelOldGC); >> UNSUPPORTED_GC_OPTION(UseConcMarkSweepGC); >> UNSUPPORTED_GC_OPTION(UseParNewGC); >> FLAG_SET_DEFAULT(CMSIncrementalMode, false); // special CMS suboption >> } >> >> and then: >> >> 3221 #if (!INCLUDE_ALL_GCS || defined JAVASE_EMBEDDED || defined ARM) >> 3222 force_serial_gc(); >> 3223 #endif >> >> Assuming only serialGC is available on embedded or ARM. >> >> David >> ----- >> >> On 26/01/2013 2:25 AM, Joe Provino wrote: >>> > With changes from Bob and David, here is a new webrev: >>> > >>> > http://cr.openjdk.java.net/~jprovino/8003581/webrev.01 >>> > >>> > joe >>> > >>> > On 1/25/2013 12:44 AM, David Holmes wrote: >>>> >> On 25/01/2013 4:45 AM, Bob Vandette wrote: >>>>> >>> You claim to be defaulting to SerialGC but you don't set UseG1GC to >>>>> >>> false? >>>> >> >>>> >> The UNSUPPORTED_OPTION macro does that. >>>> >> >>>> >> But I don't see anything forcing use of serialGC. And >>>> >> force_serial_gc() should not be altered. >>>> >> >>>>> >>> If you build with INCLUDE_ALL_GCS=1, the G1 code will be available >>>>> >>> and be used. >>>> >> >>>> >> Only on those platforms that support it. >>>> >> >>>> >> David >>>> >> >>>>> >>> Bob. >>>>> >>> >>>>> >>> On Jan 24, 2013, at 1:38 PM, Joe Provino wrote: >>>>> >>> >>>>>> >>>> Webrev is here:http://cr.openjdk.java.net/~jprovino/8003581/webrev.00 >>>>>> >>>> >>>>>> >>>> It's a change to one file: arguments.cpp. >>>>>> >>>> >>>>>> >>>> thanks. >>>>>> >>>> >>>>>> >>>> joe >>>>> >>> > From dmitry.samersoff at oracle.com Mon Feb 4 13:03:06 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 05 Feb 2013 01:03:06 +0400 Subject: Review request: JDK-8006753 fix failed for JDK-8002415 White box testing API for HotSpot In-Reply-To: <510FBECB.6050903@oracle.com> References: <510FBECB.6050903@oracle.com> Message-ID: <5110220A.20703@oracle.com> Mikael, Looks good for me. -Dmitry On 2013-02-04 17:59, Mikael Gerdin wrote: > Hi, > > Background: > Even from the beginning of the WhiteBox testing API implementation the > tests have not worked on builds promoted by release engineering due to > the fact that the wb.jar file containing the Java classes was not > imported by the JDK-level makefiles. > On one level this was ok since we didn't want to ship the classes to end > users and we worked around the complexity of somehow post-processing the > RE bundles to remove them. > > The problem is that we aren't able to run the WhiteBox tests in > promotion testing, or to verify fixes against earlier builds. > > Solution: > The solution suggested here is to put the WhiteBox helper classes in the > testlibrary directory under test/ and > * tell jtreg to first compile the classes > * run a special Java program to copy the classes to the test work directory > * run the white box test with -Xbootclasspath/a:. to pick up the copied > classes. > > The solution is kind-of hackish but I've been unable to come up with a > better solution without performing complex surgery on jtreg. > > The changes to the make/ directory should basically revert the makefile > changes that were added to support this API. > > Webrev: > http://cr.openjdk.java.net/~mgerdin/8006753/webrev.0/ > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006753 > > Note about renamed/moved files: > I will try to make sure that the moved/renamed files will be tracked > properly by mercurial, but I think that using patch files and MQ breaks > this so I'll do this after the review is done. > > Thanks > /Mikael -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From chris.plummer at oracle.com Mon Feb 4 13:27:32 2013 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 04 Feb 2013 13:27:32 -0800 Subject: Request for review: JDK-8003581, , UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS In-Reply-To: <51101F35.3070402@oracle.com> References: <51100159.6010103@oracle.com> <51101F35.3070402@oracle.com> Message-ID: <511027C4.9040106@oracle.com> On 2/4/13 12:51 PM, David Holmes wrote: > On 5/02/2013 4:43 AM, Chris Plummer wrote: >> Hi David, >> >> It's not the case that only serialGC is available on embedded or ARM. > > Thanks. In that case it is not right to treat UseG1Gc the same as the > other flags and this code is incorrect: > > 3168 #if (defined JAVASE_EMBEDDED || defined ARM || !INCLUDE_ALL_GCS) > 3169 if (UseG1GC) { > 3170 UNSUPPORTED_GC_OPTION(UseG1GC); > 3171 } > 3172 #endif > > This needs to be broken into two cases, the original > > 3153 #if (defined JAVASE_EMBEDDED || defined ARM) > 3154 UNSUPPORTED_OPTION(UseG1GC, "G1 GC"); > 3155 #endif > > plus the missing case: > > 3174 #if !INCLUDE_ALL_GCS > if (UseG1GC) { > UNSUPPORTED_GC_OPTION(UseG1GC); > } > ... > I guess I don't see the significance of this different handling for the two cases. Chris >> Here's the breakdown of which GCs are available for each supported >> build: >> >> * JDK builds (except ARM) >> o Detected with "#if !defined(JAVASE_EMBEDDED) && !defined(ARM)" >> o All GCs available >> * ARM JDK Build >> o Detected with "#if !defined(JAVASE_EMBEDDED) && defined(ARM)" >> o All GCs except G1 >> * Embedded Builds (except MinimalVM) >> o Detected with "#if defined(JAVASE_EMBEDDED) && INCLUDE_ALL_GCS" >> o All GCs except G1 >> * Embedded MinimalVM Builds >> o Detected with "#if defined(JAVASE_EMBEDDED) && !INCLUDE_ALL_GCS" >> o Only SerialGC >> >> Other combinations are possible (for example, a MinimalVM JDK build), >> but the above are the supported builds. However, there are probably >> better ways of checking the above flags to determine which GCs are >> available, and also capture the unsupported builds. I think the >> following is probably the simplest: >> >> #if INCLUDE_ALL_GCS >> #if defined(JAVASE_EMBEDDED) || defined(ARM) >> all GC's except G1 supported >> #else >> all GC's support >> #endif >> #else >> only SerialGC supported. >> #endif > > Yes, where the only serialGC supported could be a call to > force_serial_gc() which in turn calls the UNSUPPORTED_GC_OPTION as below. > > David > ------ > >> Chris >> >> >> On 2/1/13 12:17 AM, David Holmes wrote: >>> Hi Joe, >>> >>> I think you could simplify this further by deleting lines 3168 - 3186 >>> and change force_serial_gc() to do: >>> >>> static void force_serial_gc() { >>> FLAG_SET_DEFAULT(UseSerialGC, true); >>> UNSUPPORTED_GC_OPTION(UseG1GC); >>> UNSUPPORTED_GC_OPTION(UseParallelGC); >>> UNSUPPORTED_GC_OPTION(UseParallelOldGC); >>> UNSUPPORTED_GC_OPTION(UseConcMarkSweepGC); >>> UNSUPPORTED_GC_OPTION(UseParNewGC); >>> FLAG_SET_DEFAULT(CMSIncrementalMode, false); // special CMS >>> suboption >>> } >>> >>> and then: >>> >>> 3221 #if (!INCLUDE_ALL_GCS || defined JAVASE_EMBEDDED || defined ARM) >>> 3222 force_serial_gc(); >>> 3223 #endif >>> >>> Assuming only serialGC is available on embedded or ARM. >>> >>> David >>> ----- >>> >>> On 26/01/2013 2:25 AM, Joe Provino wrote: >>>> > With changes from Bob and David, here is a new webrev: >>>> > >>>> > http://cr.openjdk.java.net/~jprovino/8003581/webrev.01 >>>> > >>>> > joe >>>> > >>>> > On 1/25/2013 12:44 AM, David Holmes wrote: >>>>> >> On 25/01/2013 4:45 AM, Bob Vandette wrote: >>>>>> >>> You claim to be defaulting to SerialGC but you don't set >>>>>> UseG1GC to >>>>>> >>> false? >>>>> >> >>>>> >> The UNSUPPORTED_OPTION macro does that. >>>>> >> >>>>> >> But I don't see anything forcing use of serialGC. And >>>>> >> force_serial_gc() should not be altered. >>>>> >> >>>>>> >>> If you build with INCLUDE_ALL_GCS=1, the G1 code will be >>>>>> available >>>>>> >>> and be used. >>>>> >> >>>>> >> Only on those platforms that support it. >>>>> >> >>>>> >> David >>>>> >> >>>>>> >>> Bob. >>>>>> >>> >>>>>> >>> On Jan 24, 2013, at 1:38 PM, Joe Provino wrote: >>>>>> >>> >>>>>>> >>>> Webrev is >>>>>>> here:http://cr.openjdk.java.net/~jprovino/8003581/webrev.00 >>>>>>> >>>> >>>>>>> >>>> It's a change to one file: arguments.cpp. >>>>>>> >>>> >>>>>>> >>>> thanks. >>>>>>> >>>> >>>>>>> >>>> joe >>>>>> >>> >> From John.Coomes at oracle.com Mon Feb 4 13:55:15 2013 From: John.Coomes at oracle.com (John Coomes) Date: Mon, 4 Feb 2013 13:55:15 -0800 Subject: CFV: New HSX Reviewer: Zhengyu Gu In-Reply-To: <5102ACAB.8020705@oracle.com> References: <5102ACAB.8020705@oracle.com> Message-ID: <20752.11843.833943.538843@oracle.com> Vote: yes -John From kelly.ohair at oracle.com Mon Feb 4 14:20:37 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 4 Feb 2013 14:20:37 -0800 Subject: This simple patch doubles the compile-speed of the hotspot repo on Windows In-Reply-To: References: <76DC1CA3-E0C7-4A2D-9E3D-4523C6A3D536@oracle.com> Message-ID: <1F65A118-150F-4CAD-B06E-99223F64FEB3@oracle.com> Got it. Thanks for this. -kto On Feb 4, 2013, at 1:04 AM, Fredrik ?hrstr?m wrote: > Issue filed, on its way in: > http://cr.openjdk.java.net/~ohrstrom/webrev-8007446-add-MP/ > > //Fredrik > > 2013/2/2 Kelly O'Hair : >> Great stuff. Have you filed an issue on this? Or shall I? >> >> >> -kto >> >> On Feb 1, 2013, at 4:58 AM, Fredrik ?hrstr?m wrote: >> >>> ie. use /MP on the cl.exe command line. >>> >>> On the build machine (Windows Server 2007, Visual Studio 2010, 32 HT >>> cores, 64GB ram) configuring with: >>> >>> sh configure --enable-sjavac >>> --with-freetype=/cygdrive/d/tools/freetype-amd64 >>> --with-boot-jdk=/cygdrive/d/java/jdk-7-fcs-bin-b147/ >>> >>> (You need to patch >>> src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java >>> line 256, change equals("windows)" to startswith("windows), this fix >>> is going into tl soon.) >>> >>> Without MP >>> ----- Build times ------- >>> Start 2013-02-01 12:23:50 >>> End 2013-02-01 12:35:20 >>> 00:00:32 corba >>> 00:04:43 hotspot >>> 00:00:15 jaxp >>> 00:00:24 jaxws >>> 00:04:49 jdk >>> 00:00:46 langtools >>> 00:11:30 TOTAL >>> ------------------------- >>> >>> With MP >>> ----- Build times ------- >>> Start 2013-02-01 12:54:54 >>> End 2013-02-01 13:03:56 >>> 00:00:31 corba >>> 00:02:20 hotspot >>> 00:00:14 jaxp >>> 00:00:22 jaxws >>> 00:04:44 jdk >>> 00:00:46 langtools >>> 00:09:02 TOTAL >>> ------------------------- >>> >>> For such a simple patch it is a nice speedup. Please test and see if >>> it improves the speed on your multi core machines. >>> >>> //Fredrik >>> >>> Oh, and for reference this is the speed without sjavac but with /MP. >>> >>> ----- Build times ------- >>> Start 2013-02-01 13:39:38 >>> End 2013-02-01 13:51:46 >>> 00:00:35 corba >>> 00:02:24 hotspot >>> 00:00:28 jaxp >>> 00:00:36 jaxws >>> 00:07:11 jdk >>> 00:00:48 langtools >>> 00:12:08 TOTAL >>> ------------------------- >>> >>> $ hg diff >>> diff -r 67498c863813 make/windows/makefiles/compile.make >>> --- a/make/windows/makefiles/compile.make Thu Jan 17 12:16:06 2013 +0100 >>> +++ b/make/windows/makefiles/compile.make Fri Feb 01 13:05:08 2013 +0100 >>> @@ -44,6 +44,7 @@ >>> # /GS Inserts security stack checks in some functions (VS2005 default) >>> # /Oi Use intrinsics (in /O2) >>> # /Od Disable all optimizations >>> +# /MP Use multiple cores for compilation >>> # >>> # NOTE: Normally following any of the above with a '-' will turn off that flag >>> # >>> @@ -52,7 +53,7 @@ >>> # improving the quality of crash log stack traces involving jvm.dll. >>> >>> # These are always used in all compiles >>> -CXX_FLAGS=/nologo /W3 /WX >>> +CXX_FLAGS=/nologo /W3 /WX /MP >>> >>> # Let's add debug information when Full Debug Symbols is enabled >>> !if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1" >>> diff -r 67498c863813 make/windows/makefiles/sa.make >>> --- a/make/windows/makefiles/sa.make Thu Jan 17 12:16:06 2013 +0100 >>> +++ b/make/windows/makefiles/sa.make Fri Feb 01 13:05:08 2013 +0100 >>> @@ -108,6 +108,8 @@ >>> SA_LFLAGS = $(SA_LFLAGS) -map -debug >>> !endif >>> >>> +SA_CFLAGS = $(SA_CFLAGS) -MP >>> + >>> # Note that we do not keep sawindbj.obj around as it would then >>> # get included in the dumpbin command in build_vm_def.sh >> From david.holmes at oracle.com Mon Feb 4 14:31:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 05 Feb 2013 08:31:49 +1000 Subject: Request for review: JDK-8003581, , UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS In-Reply-To: <511027C4.9040106@oracle.com> References: <51100159.6010103@oracle.com> <51101F35.3070402@oracle.com> <511027C4.9040106@oracle.com> Message-ID: <511036D5.1090004@oracle.com> On 5/02/2013 7:27 AM, Chris Plummer wrote: > On 2/4/13 12:51 PM, David Holmes wrote: >> On 5/02/2013 4:43 AM, Chris Plummer wrote: >>> Hi David, >>> >>> It's not the case that only serialGC is available on embedded or ARM. >> >> Thanks. In that case it is not right to treat UseG1Gc the same as the >> other flags and this code is incorrect: >> >> 3168 #if (defined JAVASE_EMBEDDED || defined ARM || !INCLUDE_ALL_GCS) >> 3169 if (UseG1GC) { >> 3170 UNSUPPORTED_GC_OPTION(UseG1GC); >> 3171 } >> 3172 #endif >> >> This needs to be broken into two cases, the original >> >> 3153 #if (defined JAVASE_EMBEDDED || defined ARM) >> 3154 UNSUPPORTED_OPTION(UseG1GC, "G1 GC"); >> 3155 #endif >> >> plus the missing case: >> >> 3174 #if !INCLUDE_ALL_GCS >> if (UseG1GC) { >> UNSUPPORTED_GC_OPTION(UseG1GC); >> } >> ... >> > I guess I don't see the significance of this different handling for the > two cases. In the first case we don't default to serialGC - at least not explicitly. David ----- > Chris >>> Here's the breakdown of which GCs are available for each supported >>> build: >>> >>> * JDK builds (except ARM) >>> o Detected with "#if !defined(JAVASE_EMBEDDED) && !defined(ARM)" >>> o All GCs available >>> * ARM JDK Build >>> o Detected with "#if !defined(JAVASE_EMBEDDED) && defined(ARM)" >>> o All GCs except G1 >>> * Embedded Builds (except MinimalVM) >>> o Detected with "#if defined(JAVASE_EMBEDDED) && INCLUDE_ALL_GCS" >>> o All GCs except G1 >>> * Embedded MinimalVM Builds >>> o Detected with "#if defined(JAVASE_EMBEDDED) && !INCLUDE_ALL_GCS" >>> o Only SerialGC >>> >>> Other combinations are possible (for example, a MinimalVM JDK build), >>> but the above are the supported builds. However, there are probably >>> better ways of checking the above flags to determine which GCs are >>> available, and also capture the unsupported builds. I think the >>> following is probably the simplest: >>> >>> #if INCLUDE_ALL_GCS >>> #if defined(JAVASE_EMBEDDED) || defined(ARM) >>> all GC's except G1 supported >>> #else >>> all GC's support >>> #endif >>> #else >>> only SerialGC supported. >>> #endif >> >> Yes, where the only serialGC supported could be a call to >> force_serial_gc() which in turn calls the UNSUPPORTED_GC_OPTION as below. >> >> David >> ------ >> >>> Chris >>> >>> >>> On 2/1/13 12:17 AM, David Holmes wrote: >>>> Hi Joe, >>>> >>>> I think you could simplify this further by deleting lines 3168 - 3186 >>>> and change force_serial_gc() to do: >>>> >>>> static void force_serial_gc() { >>>> FLAG_SET_DEFAULT(UseSerialGC, true); >>>> UNSUPPORTED_GC_OPTION(UseG1GC); >>>> UNSUPPORTED_GC_OPTION(UseParallelGC); >>>> UNSUPPORTED_GC_OPTION(UseParallelOldGC); >>>> UNSUPPORTED_GC_OPTION(UseConcMarkSweepGC); >>>> UNSUPPORTED_GC_OPTION(UseParNewGC); >>>> FLAG_SET_DEFAULT(CMSIncrementalMode, false); // special CMS suboption >>>> } >>>> >>>> and then: >>>> >>>> 3221 #if (!INCLUDE_ALL_GCS || defined JAVASE_EMBEDDED || defined ARM) >>>> 3222 force_serial_gc(); >>>> 3223 #endif >>>> >>>> Assuming only serialGC is available on embedded or ARM. >>>> >>>> David >>>> ----- >>>> >>>> On 26/01/2013 2:25 AM, Joe Provino wrote: >>>>> > With changes from Bob and David, here is a new webrev: >>>>> > >>>>> > http://cr.openjdk.java.net/~jprovino/8003581/webrev.01 >>>>> > >>>>> > joe >>>>> > >>>>> > On 1/25/2013 12:44 AM, David Holmes wrote: >>>>>> >> On 25/01/2013 4:45 AM, Bob Vandette wrote: >>>>>>> >>> You claim to be defaulting to SerialGC but you don't set >>>>>>> UseG1GC to >>>>>>> >>> false? >>>>>> >> >>>>>> >> The UNSUPPORTED_OPTION macro does that. >>>>>> >> >>>>>> >> But I don't see anything forcing use of serialGC. And >>>>>> >> force_serial_gc() should not be altered. >>>>>> >> >>>>>>> >>> If you build with INCLUDE_ALL_GCS=1, the G1 code will be >>>>>>> available >>>>>>> >>> and be used. >>>>>> >> >>>>>> >> Only on those platforms that support it. >>>>>> >> >>>>>> >> David >>>>>> >> >>>>>>> >>> Bob. >>>>>>> >>> >>>>>>> >>> On Jan 24, 2013, at 1:38 PM, Joe Provino wrote: >>>>>>> >>> >>>>>>>> >>>> Webrev is >>>>>>>> here:http://cr.openjdk.java.net/~jprovino/8003581/webrev.00 >>>>>>>> >>>> >>>>>>>> >>>> It's a change to one file: arguments.cpp. >>>>>>>> >>>> >>>>>>>> >>>> thanks. >>>>>>>> >>>> >>>>>>>> >>>> joe >>>>>>> >>> >>> > From John.Coomes at oracle.com Mon Feb 4 14:46:37 2013 From: John.Coomes at oracle.com (John Coomes) Date: Mon, 4 Feb 2013 14:46:37 -0800 Subject: CFV: New HSX Committer: Serguei Spitsyn In-Reply-To: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> References: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> Message-ID: <20752.14925.783092.234867@oracle.com> Vote: yes -John From david.holmes at oracle.com Mon Feb 4 16:47:38 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 05 Feb 2013 10:47:38 +1000 Subject: CFV: New HSX Committer: Serguei Spitsyn In-Reply-To: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> References: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> Message-ID: <511056AA.6020002@oracle.com> Vote: yes David On 5/02/2013 4:25 AM, Staffan Larsen wrote: > I hereby nominate Serguei Spitsyn (OpenJDK user name: sspitsyn) to HSX Committer. > > Serguei is a member of the Hotspot Serviceability team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=serguei.spitsyn at oracle.com > > Votes are due by February 18, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Staffan > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote From david.holmes at oracle.com Mon Feb 4 17:06:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 05 Feb 2013 11:06:01 +1000 Subject: Request for review: JDK-8003581, , UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS In-Reply-To: <511058E4.8090900@oracle.com> References: <51100159.6010103@oracle.com> <51101F35.3070402@oracle.com> <511027C4.9040106@oracle.com> <511036D5.1090004@oracle.com> <511058E4.8090900@oracle.com> Message-ID: <51105AF9.3060703@oracle.com> On 5/02/2013 10:57 AM, Chris Plummer wrote: > On 2/4/13 2:31 PM, David Holmes wrote: >> On 5/02/2013 7:27 AM, Chris Plummer wrote: >>> On 2/4/13 12:51 PM, David Holmes wrote: >>>> On 5/02/2013 4:43 AM, Chris Plummer wrote: >>>>> Hi David, >>>>> >>>>> It's not the case that only serialGC is available on embedded or ARM. >>>> >>>> Thanks. In that case it is not right to treat UseG1Gc the same as the >>>> other flags and this code is incorrect: >>>> >>>> 3168 #if (defined JAVASE_EMBEDDED || defined ARM || !INCLUDE_ALL_GCS) >>>> 3169 if (UseG1GC) { >>>> 3170 UNSUPPORTED_GC_OPTION(UseG1GC); >>>> 3171 } >>>> 3172 #endif >>>> >>>> This needs to be broken into two cases, the original >>>> >>>> 3153 #if (defined JAVASE_EMBEDDED || defined ARM) >>>> 3154 UNSUPPORTED_OPTION(UseG1GC, "G1 GC"); >>>> 3155 #endif >>>> >>>> plus the missing case: >>>> >>>> 3174 #if !INCLUDE_ALL_GCS >>>> if (UseG1GC) { >>>> UNSUPPORTED_GC_OPTION(UseG1GC); >>>> } >>>> ... >>>> >>> I guess I don't see the significance of this different handling for the >>> two cases. >> >> In the first case we don't default to serialGC - at least not explicitly. > As far as I can see, UNSUPPORTED_OPTION and UNSUPPORTED_GC_OPTION do the > same thing, except for a slightly different warning message. Neither of > them explicitly set the default to SerialGC. Also, with your approach > you'll get two warnings with minimalVM builds done for embedded and for ARM. When !INCLUDE_ALL_GCS we call force_serial_gc() later on, forcing the use of serial GC. Hence under !INCLUDE_ALL_GCS UNSUPPORTED_GC_OPTION reports "defaulting to serial GC". But when we are simply embedded or ARM and INCLUDE_ALL_GCS is true, we simply ignore UseG1GC. We do not force the use of serial GC in that case, so it is wrong to use UNSUPPORTED_GC_OPTION for that case. > Also, I don't see why the "if (UseG1GC) { " is needed since Agreed - my suggestion removes it too. > UNSUPPORTED_GC_OPTION already does the "if". This is a also pre-existing > problem in the webrev. It got created when changing the calls from > "warning" to instead call UNSUPPORTED_GC_OPTION. I think all that is > needed is: > > #if (defined JAVASE_EMBEDDED || defined ARM || !INCLUDE_ALL_GCS) > UNSUPPORTED_GC_OPTION(UseG1GC); > #endif This bit is wrong as per the above. > #if !INCLUDE_ALL_GCS > UNSUPPORTED_GC_OPTION(UseParallelGC); > UNSUPPORTED_GC_OPTION(UseParallelOldGC); > UNSUPPORTED_GC_OPTION(UseConcMarkSweepGC); > UNSUPPORTED_GC_OPTION(UseParNewGC); > #endif // INCLUDE_ALL_GCS This can all be moved to force_serial_gc() as I suggested. David ----- > > Chris >> >> David >> ----- >> >>> Chris >>>>> Here's the breakdown of which GCs are available for each supported >>>>> build: >>>>> >>>>> * JDK builds (except ARM) >>>>> o Detected with "#if !defined(JAVASE_EMBEDDED) && !defined(ARM)" >>>>> o All GCs available >>>>> * ARM JDK Build >>>>> o Detected with "#if !defined(JAVASE_EMBEDDED) && defined(ARM)" >>>>> o All GCs except G1 >>>>> * Embedded Builds (except MinimalVM) >>>>> o Detected with "#if defined(JAVASE_EMBEDDED) && INCLUDE_ALL_GCS" >>>>> o All GCs except G1 >>>>> * Embedded MinimalVM Builds >>>>> o Detected with "#if defined(JAVASE_EMBEDDED) && !INCLUDE_ALL_GCS" >>>>> o Only SerialGC >>>>> >>>>> Other combinations are possible (for example, a MinimalVM JDK build), >>>>> but the above are the supported builds. However, there are probably >>>>> better ways of checking the above flags to determine which GCs are >>>>> available, and also capture the unsupported builds. I think the >>>>> following is probably the simplest: >>>>> >>>>> #if INCLUDE_ALL_GCS >>>>> #if defined(JAVASE_EMBEDDED) || defined(ARM) >>>>> all GC's except G1 supported >>>>> #else >>>>> all GC's support >>>>> #endif >>>>> #else >>>>> only SerialGC supported. >>>>> #endif >>>> >>>> Yes, where the only serialGC supported could be a call to >>>> force_serial_gc() which in turn calls the UNSUPPORTED_GC_OPTION as >>>> below. >>>> >>>> David >>>> ------ >>>> >>>>> Chris >>>>> >>>>> >>>>> On 2/1/13 12:17 AM, David Holmes wrote: >>>>>> Hi Joe, >>>>>> >>>>>> I think you could simplify this further by deleting lines 3168 - 3186 >>>>>> and change force_serial_gc() to do: >>>>>> >>>>>> static void force_serial_gc() { >>>>>> FLAG_SET_DEFAULT(UseSerialGC, true); >>>>>> UNSUPPORTED_GC_OPTION(UseG1GC); >>>>>> UNSUPPORTED_GC_OPTION(UseParallelGC); >>>>>> UNSUPPORTED_GC_OPTION(UseParallelOldGC); >>>>>> UNSUPPORTED_GC_OPTION(UseConcMarkSweepGC); >>>>>> UNSUPPORTED_GC_OPTION(UseParNewGC); >>>>>> FLAG_SET_DEFAULT(CMSIncrementalMode, false); // special CMS suboption >>>>>> } >>>>>> >>>>>> and then: >>>>>> >>>>>> 3221 #if (!INCLUDE_ALL_GCS || defined JAVASE_EMBEDDED || defined ARM) >>>>>> 3222 force_serial_gc(); >>>>>> 3223 #endif >>>>>> >>>>>> Assuming only serialGC is available on embedded or ARM. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> On 26/01/2013 2:25 AM, Joe Provino wrote: >>>>>>> > With changes from Bob and David, here is a new webrev: >>>>>>> > >>>>>>> > http://cr.openjdk.java.net/~jprovino/8003581/webrev.01 >>>>>>> > >>>>>>> > joe >>>>>>> > >>>>>>> > On 1/25/2013 12:44 AM, David Holmes wrote: >>>>>>>> >> On 25/01/2013 4:45 AM, Bob Vandette wrote: >>>>>>>>> >>> You claim to be defaulting to SerialGC but you don't set >>>>>>>>> UseG1GC to >>>>>>>>> >>> false? >>>>>>>> >> >>>>>>>> >> The UNSUPPORTED_OPTION macro does that. >>>>>>>> >> >>>>>>>> >> But I don't see anything forcing use of serialGC. And >>>>>>>> >> force_serial_gc() should not be altered. >>>>>>>> >> >>>>>>>>> >>> If you build with INCLUDE_ALL_GCS=1, the G1 code will be >>>>>>>>> available >>>>>>>>> >>> and be used. >>>>>>>> >> >>>>>>>> >> Only on those platforms that support it. >>>>>>>> >> >>>>>>>> >> David >>>>>>>> >> >>>>>>>>> >>> Bob. >>>>>>>>> >>> >>>>>>>>> >>> On Jan 24, 2013, at 1:38 PM, Joe Provino wrote: >>>>>>>>> >>> >>>>>>>>>> >>>> Webrev is >>>>>>>>>> here:http://cr.openjdk.java.net/~jprovino/8003581/webrev.00 >>>>>>>>>> >>>> >>>>>>>>>> >>>> It's a change to one file: arguments.cpp. >>>>>>>>>> >>>> >>>>>>>>>> >>>> thanks. >>>>>>>>>> >>>> >>>>>>>>>> >>>> joe >>>>>>>>> >>> >>>>> >>> > From chris.plummer at oracle.com Mon Feb 4 17:27:35 2013 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 04 Feb 2013 17:27:35 -0800 Subject: Request for review: JDK-8003581, , UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS In-Reply-To: <51105AF9.3060703@oracle.com> References: <51100159.6010103@oracle.com> <51101F35.3070402@oracle.com> <511027C4.9040106@oracle.com> <511036D5.1090004@oracle.com> <511058E4.8090900@oracle.com> <51105AF9.3060703@oracle.com> Message-ID: <51106007.8020105@oracle.com> On 2/4/13 5:06 PM, David Holmes wrote: > On 5/02/2013 10:57 AM, Chris Plummer wrote: >> On 2/4/13 2:31 PM, David Holmes wrote: >>> On 5/02/2013 7:27 AM, Chris Plummer wrote: >>>> On 2/4/13 12:51 PM, David Holmes wrote: >>>>> On 5/02/2013 4:43 AM, Chris Plummer wrote: >>>>>> Hi David, >>>>>> >>>>>> It's not the case that only serialGC is available on embedded or >>>>>> ARM. >>>>> >>>>> Thanks. In that case it is not right to treat UseG1Gc the same as the >>>>> other flags and this code is incorrect: >>>>> >>>>> 3168 #if (defined JAVASE_EMBEDDED || defined ARM || !INCLUDE_ALL_GCS) >>>>> 3169 if (UseG1GC) { >>>>> 3170 UNSUPPORTED_GC_OPTION(UseG1GC); >>>>> 3171 } >>>>> 3172 #endif >>>>> >>>>> This needs to be broken into two cases, the original >>>>> >>>>> 3153 #if (defined JAVASE_EMBEDDED || defined ARM) >>>>> 3154 UNSUPPORTED_OPTION(UseG1GC, "G1 GC"); >>>>> 3155 #endif >>>>> >>>>> plus the missing case: >>>>> >>>>> 3174 #if !INCLUDE_ALL_GCS >>>>> if (UseG1GC) { >>>>> UNSUPPORTED_GC_OPTION(UseG1GC); >>>>> } >>>>> ... >>>>> >>>> I guess I don't see the significance of this different handling for >>>> the >>>> two cases. >>> >>> In the first case we don't default to serialGC - at least not >>> explicitly. >> As far as I can see, UNSUPPORTED_OPTION and UNSUPPORTED_GC_OPTION do the >> same thing, except for a slightly different warning message. Neither of >> them explicitly set the default to SerialGC. Also, with your approach >> you'll get two warnings with minimalVM builds done for embedded and >> for ARM. > > When !INCLUDE_ALL_GCS we call force_serial_gc() later on, forcing the > use of serial GC. Hence under !INCLUDE_ALL_GCS UNSUPPORTED_GC_OPTION > reports "defaulting to serial GC". > > But when we are simply embedded or ARM and INCLUDE_ALL_GCS is true, we > simply ignore UseG1GC. We do not force the use of serial GC in that > case, so it is wrong to use UNSUPPORTED_GC_OPTION for that case. Ok, to this has to do with having the warning message match what we are actually going to do. > >> Also, I don't see why the "if (UseG1GC) { " is needed since > > Agreed - my suggestion removes it too. > >> UNSUPPORTED_GC_OPTION already does the "if". This is a also pre-existing >> problem in the webrev. It got created when changing the calls from >> "warning" to instead call UNSUPPORTED_GC_OPTION. I think all that is >> needed is: >> >> #if (defined JAVASE_EMBEDDED || defined ARM || !INCLUDE_ALL_GCS) >> UNSUPPORTED_GC_OPTION(UseG1GC); >> #endif > > This bit is wrong as per the above. I think what we actually need then is: #if INCLUDE_ALL_GCS #if (defined JAVASE_EMBEDDED || defined ARM) UNSUPPORTED_OPTION(UseG1GC, "G1 GC"); #endif #endif This solves both my concern about the double warning and your concern about the incorrect "defaulting to Serial GC" message when other GCs are supported. > >> #if !INCLUDE_ALL_GCS >> UNSUPPORTED_GC_OPTION(UseParallelGC); >> UNSUPPORTED_GC_OPTION(UseParallelOldGC); >> UNSUPPORTED_GC_OPTION(UseConcMarkSweepGC); >> UNSUPPORTED_GC_OPTION(UseParNewGC); >> #endif // INCLUDE_ALL_GCS > And here we need to add the following within the above #if: UNSUPPORTED_GC_OPTION(UseG1GC); > This can all be moved to force_serial_gc() as I suggested. Ok. Chris > > David > ----- > >> >> Chris >>> >>> David >>> ----- >>> >>>> Chris >>>>>> Here's the breakdown of which GCs are available for each supported >>>>>> build: >>>>>> >>>>>> * JDK builds (except ARM) >>>>>> o Detected with "#if !defined(JAVASE_EMBEDDED) && !defined(ARM)" >>>>>> o All GCs available >>>>>> * ARM JDK Build >>>>>> o Detected with "#if !defined(JAVASE_EMBEDDED) && defined(ARM)" >>>>>> o All GCs except G1 >>>>>> * Embedded Builds (except MinimalVM) >>>>>> o Detected with "#if defined(JAVASE_EMBEDDED) && INCLUDE_ALL_GCS" >>>>>> o All GCs except G1 >>>>>> * Embedded MinimalVM Builds >>>>>> o Detected with "#if defined(JAVASE_EMBEDDED) && !INCLUDE_ALL_GCS" >>>>>> o Only SerialGC >>>>>> >>>>>> Other combinations are possible (for example, a MinimalVM JDK >>>>>> build), >>>>>> but the above are the supported builds. However, there are probably >>>>>> better ways of checking the above flags to determine which GCs are >>>>>> available, and also capture the unsupported builds. I think the >>>>>> following is probably the simplest: >>>>>> >>>>>> #if INCLUDE_ALL_GCS >>>>>> #if defined(JAVASE_EMBEDDED) || defined(ARM) >>>>>> all GC's except G1 supported >>>>>> #else >>>>>> all GC's support >>>>>> #endif >>>>>> #else >>>>>> only SerialGC supported. >>>>>> #endif >>>>> >>>>> Yes, where the only serialGC supported could be a call to >>>>> force_serial_gc() which in turn calls the UNSUPPORTED_GC_OPTION as >>>>> below. >>>>> >>>>> David >>>>> ------ >>>>> >>>>>> Chris >>>>>> >>>>>> >>>>>> On 2/1/13 12:17 AM, David Holmes wrote: >>>>>>> Hi Joe, >>>>>>> >>>>>>> I think you could simplify this further by deleting lines 3168 - >>>>>>> 3186 >>>>>>> and change force_serial_gc() to do: >>>>>>> >>>>>>> static void force_serial_gc() { >>>>>>> FLAG_SET_DEFAULT(UseSerialGC, true); >>>>>>> UNSUPPORTED_GC_OPTION(UseG1GC); >>>>>>> UNSUPPORTED_GC_OPTION(UseParallelGC); >>>>>>> UNSUPPORTED_GC_OPTION(UseParallelOldGC); >>>>>>> UNSUPPORTED_GC_OPTION(UseConcMarkSweepGC); >>>>>>> UNSUPPORTED_GC_OPTION(UseParNewGC); >>>>>>> FLAG_SET_DEFAULT(CMSIncrementalMode, false); // special CMS >>>>>>> suboption >>>>>>> } >>>>>>> >>>>>>> and then: >>>>>>> >>>>>>> 3221 #if (!INCLUDE_ALL_GCS || defined JAVASE_EMBEDDED || defined >>>>>>> ARM) >>>>>>> 3222 force_serial_gc(); >>>>>>> 3223 #endif >>>>>>> >>>>>>> Assuming only serialGC is available on embedded or ARM. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> On 26/01/2013 2:25 AM, Joe Provino wrote: >>>>>>>> > With changes from Bob and David, here is a new webrev: >>>>>>>> > >>>>>>>> > http://cr.openjdk.java.net/~jprovino/8003581/webrev.01 >>>>>>>> > >>>>>>>> > joe >>>>>>>> > >>>>>>>> > On 1/25/2013 12:44 AM, David Holmes wrote: >>>>>>>>> >> On 25/01/2013 4:45 AM, Bob Vandette wrote: >>>>>>>>>> >>> You claim to be defaulting to SerialGC but you don't set >>>>>>>>>> UseG1GC to >>>>>>>>>> >>> false? >>>>>>>>> >> >>>>>>>>> >> The UNSUPPORTED_OPTION macro does that. >>>>>>>>> >> >>>>>>>>> >> But I don't see anything forcing use of serialGC. And >>>>>>>>> >> force_serial_gc() should not be altered. >>>>>>>>> >> >>>>>>>>>> >>> If you build with INCLUDE_ALL_GCS=1, the G1 code will be >>>>>>>>>> available >>>>>>>>>> >>> and be used. >>>>>>>>> >> >>>>>>>>> >> Only on those platforms that support it. >>>>>>>>> >> >>>>>>>>> >> David >>>>>>>>> >> >>>>>>>>>> >>> Bob. >>>>>>>>>> >>> >>>>>>>>>> >>> On Jan 24, 2013, at 1:38 PM, Joe Provino wrote: >>>>>>>>>> >>> >>>>>>>>>>> >>>> Webrev is >>>>>>>>>>> here:http://cr.openjdk.java.net/~jprovino/8003581/webrev.00 >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> It's a change to one file: arguments.cpp. >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> thanks. >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> joe >>>>>>>>>> >>> >>>>>> >>>> >> From david.holmes at oracle.com Mon Feb 4 17:35:51 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 05 Feb 2013 11:35:51 +1000 Subject: Request for review: JDK-8003581, , UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS In-Reply-To: <51106007.8020105@oracle.com> References: <51100159.6010103@oracle.com> <51101F35.3070402@oracle.com> <511027C4.9040106@oracle.com> <511036D5.1090004@oracle.com> <511058E4.8090900@oracle.com> <51105AF9.3060703@oracle.com> <51106007.8020105@oracle.com> Message-ID: <511061F7.9050600@oracle.com> On 5/02/2013 11:27 AM, Chris Plummer wrote: > On 2/4/13 5:06 PM, David Holmes wrote: >> On 5/02/2013 10:57 AM, Chris Plummer wrote: >>> On 2/4/13 2:31 PM, David Holmes wrote: >>>> On 5/02/2013 7:27 AM, Chris Plummer wrote: >>>>> On 2/4/13 12:51 PM, David Holmes wrote: >>>>>> On 5/02/2013 4:43 AM, Chris Plummer wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> It's not the case that only serialGC is available on embedded or >>>>>>> ARM. >>>>>> >>>>>> Thanks. In that case it is not right to treat UseG1Gc the same as the >>>>>> other flags and this code is incorrect: >>>>>> >>>>>> 3168 #if (defined JAVASE_EMBEDDED || defined ARM || !INCLUDE_ALL_GCS) >>>>>> 3169 if (UseG1GC) { >>>>>> 3170 UNSUPPORTED_GC_OPTION(UseG1GC); >>>>>> 3171 } >>>>>> 3172 #endif >>>>>> >>>>>> This needs to be broken into two cases, the original >>>>>> >>>>>> 3153 #if (defined JAVASE_EMBEDDED || defined ARM) >>>>>> 3154 UNSUPPORTED_OPTION(UseG1GC, "G1 GC"); >>>>>> 3155 #endif >>>>>> >>>>>> plus the missing case: >>>>>> >>>>>> 3174 #if !INCLUDE_ALL_GCS >>>>>> if (UseG1GC) { >>>>>> UNSUPPORTED_GC_OPTION(UseG1GC); >>>>>> } >>>>>> ... >>>>>> >>>>> I guess I don't see the significance of this different handling for >>>>> the >>>>> two cases. >>>> >>>> In the first case we don't default to serialGC - at least not >>>> explicitly. >>> As far as I can see, UNSUPPORTED_OPTION and UNSUPPORTED_GC_OPTION do the >>> same thing, except for a slightly different warning message. Neither of >>> them explicitly set the default to SerialGC. Also, with your approach >>> you'll get two warnings with minimalVM builds done for embedded and >>> for ARM. >> >> When !INCLUDE_ALL_GCS we call force_serial_gc() later on, forcing the >> use of serial GC. Hence under !INCLUDE_ALL_GCS UNSUPPORTED_GC_OPTION >> reports "defaulting to serial GC". >> >> But when we are simply embedded or ARM and INCLUDE_ALL_GCS is true, we >> simply ignore UseG1GC. We do not force the use of serial GC in that >> case, so it is wrong to use UNSUPPORTED_GC_OPTION for that case. > Ok, to this has to do with having the warning message match what we are > actually going to do. Right. >> >>> Also, I don't see why the "if (UseG1GC) { " is needed since >> >> Agreed - my suggestion removes it too. >> >>> UNSUPPORTED_GC_OPTION already does the "if". This is a also pre-existing >>> problem in the webrev. It got created when changing the calls from >>> "warning" to instead call UNSUPPORTED_GC_OPTION. I think all that is >>> needed is: >>> >>> #if (defined JAVASE_EMBEDDED || defined ARM || !INCLUDE_ALL_GCS) >>> UNSUPPORTED_GC_OPTION(UseG1GC); >>> #endif >> >> This bit is wrong as per the above. > I think what we actually need then is: > > #if INCLUDE_ALL_GCS > #if (defined JAVASE_EMBEDDED || defined ARM) > UNSUPPORTED_OPTION(UseG1GC, "G1 GC"); > #endif > #endif > > This solves both my concern about the double warning and your concern > about the incorrect "defaulting to Serial GC" message when other GCs are > supported. Looks good to me. >> >>> #if !INCLUDE_ALL_GCS >>> UNSUPPORTED_GC_OPTION(UseParallelGC); >>> UNSUPPORTED_GC_OPTION(UseParallelOldGC); >>> UNSUPPORTED_GC_OPTION(UseConcMarkSweepGC); >>> UNSUPPORTED_GC_OPTION(UseParNewGC); >>> #endif // INCLUDE_ALL_GCS >> > And here we need to add the following within the above #if: > > UNSUPPORTED_GC_OPTION(UseG1GC); >> This can all be moved to force_serial_gc() as I suggested. > Ok. Thanks, David > > Chris >> >> David >> ----- >> >>> >>> Chris >>>> >>>> David >>>> ----- >>>> >>>>> Chris >>>>>>> Here's the breakdown of which GCs are available for each supported >>>>>>> build: >>>>>>> >>>>>>> * JDK builds (except ARM) >>>>>>> o Detected with "#if !defined(JAVASE_EMBEDDED) && !defined(ARM)" >>>>>>> o All GCs available >>>>>>> * ARM JDK Build >>>>>>> o Detected with "#if !defined(JAVASE_EMBEDDED) && defined(ARM)" >>>>>>> o All GCs except G1 >>>>>>> * Embedded Builds (except MinimalVM) >>>>>>> o Detected with "#if defined(JAVASE_EMBEDDED) && INCLUDE_ALL_GCS" >>>>>>> o All GCs except G1 >>>>>>> * Embedded MinimalVM Builds >>>>>>> o Detected with "#if defined(JAVASE_EMBEDDED) && !INCLUDE_ALL_GCS" >>>>>>> o Only SerialGC >>>>>>> >>>>>>> Other combinations are possible (for example, a MinimalVM JDK >>>>>>> build), >>>>>>> but the above are the supported builds. However, there are probably >>>>>>> better ways of checking the above flags to determine which GCs are >>>>>>> available, and also capture the unsupported builds. I think the >>>>>>> following is probably the simplest: >>>>>>> >>>>>>> #if INCLUDE_ALL_GCS >>>>>>> #if defined(JAVASE_EMBEDDED) || defined(ARM) >>>>>>> all GC's except G1 supported >>>>>>> #else >>>>>>> all GC's support >>>>>>> #endif >>>>>>> #else >>>>>>> only SerialGC supported. >>>>>>> #endif >>>>>> >>>>>> Yes, where the only serialGC supported could be a call to >>>>>> force_serial_gc() which in turn calls the UNSUPPORTED_GC_OPTION as >>>>>> below. >>>>>> >>>>>> David >>>>>> ------ >>>>>> >>>>>>> Chris >>>>>>> >>>>>>> >>>>>>> On 2/1/13 12:17 AM, David Holmes wrote: >>>>>>>> Hi Joe, >>>>>>>> >>>>>>>> I think you could simplify this further by deleting lines 3168 - >>>>>>>> 3186 >>>>>>>> and change force_serial_gc() to do: >>>>>>>> >>>>>>>> static void force_serial_gc() { >>>>>>>> FLAG_SET_DEFAULT(UseSerialGC, true); >>>>>>>> UNSUPPORTED_GC_OPTION(UseG1GC); >>>>>>>> UNSUPPORTED_GC_OPTION(UseParallelGC); >>>>>>>> UNSUPPORTED_GC_OPTION(UseParallelOldGC); >>>>>>>> UNSUPPORTED_GC_OPTION(UseConcMarkSweepGC); >>>>>>>> UNSUPPORTED_GC_OPTION(UseParNewGC); >>>>>>>> FLAG_SET_DEFAULT(CMSIncrementalMode, false); // special CMS >>>>>>>> suboption >>>>>>>> } >>>>>>>> >>>>>>>> and then: >>>>>>>> >>>>>>>> 3221 #if (!INCLUDE_ALL_GCS || defined JAVASE_EMBEDDED || defined >>>>>>>> ARM) >>>>>>>> 3222 force_serial_gc(); >>>>>>>> 3223 #endif >>>>>>>> >>>>>>>> Assuming only serialGC is available on embedded or ARM. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> On 26/01/2013 2:25 AM, Joe Provino wrote: >>>>>>>>> > With changes from Bob and David, here is a new webrev: >>>>>>>>> > >>>>>>>>> > http://cr.openjdk.java.net/~jprovino/8003581/webrev.01 >>>>>>>>> > >>>>>>>>> > joe >>>>>>>>> > >>>>>>>>> > On 1/25/2013 12:44 AM, David Holmes wrote: >>>>>>>>>> >> On 25/01/2013 4:45 AM, Bob Vandette wrote: >>>>>>>>>>> >>> You claim to be defaulting to SerialGC but you don't set >>>>>>>>>>> UseG1GC to >>>>>>>>>>> >>> false? >>>>>>>>>> >> >>>>>>>>>> >> The UNSUPPORTED_OPTION macro does that. >>>>>>>>>> >> >>>>>>>>>> >> But I don't see anything forcing use of serialGC. And >>>>>>>>>> >> force_serial_gc() should not be altered. >>>>>>>>>> >> >>>>>>>>>>> >>> If you build with INCLUDE_ALL_GCS=1, the G1 code will be >>>>>>>>>>> available >>>>>>>>>>> >>> and be used. >>>>>>>>>> >> >>>>>>>>>> >> Only on those platforms that support it. >>>>>>>>>> >> >>>>>>>>>> >> David >>>>>>>>>> >> >>>>>>>>>>> >>> Bob. >>>>>>>>>>> >>> >>>>>>>>>>> >>> On Jan 24, 2013, at 1:38 PM, Joe Provino wrote: >>>>>>>>>>> >>> >>>>>>>>>>>> >>>> Webrev is >>>>>>>>>>>> here:http://cr.openjdk.java.net/~jprovino/8003581/webrev.00 >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> It's a change to one file: arguments.cpp. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> thanks. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> joe >>>>>>>>>>> >>> >>>>>>> >>>>> >>> > From jon.masamitsu at oracle.com Mon Feb 4 18:04:07 2013 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Tue, 05 Feb 2013 02:04:07 +0000 Subject: hg: hsx/hotspot-main/hotspot: 2 new changesets Message-ID: <20130205020413.CF7344780D@hg.openjdk.java.net> Changeset: 3c327c2b6782 Author: jmasa Date: 2013-01-03 15:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3c327c2b6782 8004895: NPG: JMapPermCore test failure caused by warnings about missing field Reviewed-by: johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ef1e11845e18 Author: jmasa Date: 2013-02-04 12:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ef1e11845e18 Merge ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/runtime/vmStructs.cpp From christian.thalinger at oracle.com Mon Feb 4 18:13:41 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 4 Feb 2013 18:13:41 -0800 Subject: CFV: New HSX Committer: Serguei Spitsyn In-Reply-To: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> References: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> Message-ID: <5E78F0F1-5102-4212-90C2-D1B7AA8623CA@oracle.com> Vote: yes -- Chris On Feb 4, 2013, at 10:25 AM, Staffan Larsen wrote: > I hereby nominate Serguei Spitsyn (OpenJDK user name: sspitsyn) to HSX Committer. > > Serguei is a member of the Hotspot Serviceability team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=serguei.spitsyn at oracle.com > > Votes are due by February 18, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Staffan > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote From krystal.mo at oracle.com Mon Feb 4 19:09:58 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Mon, 04 Feb 2013 19:09:58 -0800 Subject: CFV: New HSX Committer: Serguei Spitsyn In-Reply-To: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> References: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> Message-ID: <51107806.5040302@oracle.com> Vote: yes - Kris On 2013/2/4 10:25, Staffan Larsen wrote: > I hereby nominate Serguei Spitsyn (OpenJDK user name: sspitsyn) to HSX Committer. > > Serguei is a member of the Hotspot Serviceability team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=serguei.spitsyn at oracle.com > > Votes are due by February 18, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Staffan > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote From john.r.rose at oracle.com Mon Feb 4 21:44:04 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 4 Feb 2013 21:44:04 -0800 Subject: CFV: New HSX Committer: Serguei Spitsyn In-Reply-To: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> References: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> Message-ID: Vote: yes From david.holmes at oracle.com Mon Feb 4 22:00:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 05 Feb 2013 16:00:21 +1000 Subject: RFR (XXS) CR 8006997: ContendedPaddingWidth should be uintx In-Reply-To: <510668D1.5070002@oracle.com> References: <510668D1.5070002@oracle.com> Message-ID: <51109FF5.6020804@oracle.com> Aleksey, On 28/01/2013 10:02 PM, Aleksey Shipilev wrote: > Hi guys, > > This is the tiny correction it would be nice to have: > http://cr.openjdk.java.net/~shade/8006997/ > > Negative values make no sense (and also can ruin the classloading with > the fields overlapping each other), so it would better to be uintx. I > would need a sponsor to push this. You also need to change all the expressions using this value to use unsigned types and update all the printfs to use an unsigned format specifier. David ----- > grepsrc.sh ContendedPaddingWidth ./share/vm/classfile/classFileParser.cpp: int pad_size = ContendedPaddingWidth; ./cpu/sparc/vm/vm_version_sparc.cpp: if (FLAG_IS_DEFAULT(ContendedPaddingWidth) && ./cpu/sparc/vm/vm_version_sparc.cpp: (cache_line_size > ContendedPaddingWidth)) ./cpu/sparc/vm/vm_version_sparc.cpp: ContendedPaddingWidth = cache_line_size; ./cpu/sparc/vm/vm_version_sparc.cpp: if (ContendedPaddingWidth > 0) { ./cpu/sparc/vm/vm_version_sparc.cpp: tty->print_cr("ContendedPaddingWidth %d", ContendedPaddingWidth); ./cpu/x86/vm/vm_version_x86.cpp: if (FLAG_IS_DEFAULT(ContendedPaddingWidth) && ./cpu/x86/vm/vm_version_x86.cpp: (cache_line_size > ContendedPaddingWidth)) ./cpu/x86/vm/vm_version_x86.cpp: ContendedPaddingWidth = cache_line_size; ./cpu/x86/vm/vm_version_x86.cpp: if (ContendedPaddingWidth > 0) { ./cpu/x86/vm/vm_version_x86.cpp: tty->print_cr("ContendedPaddingWidth %d", ContendedPaddingWidth); From bengt.rutisson at oracle.com Mon Feb 4 22:22:09 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 05 Feb 2013 07:22:09 +0100 Subject: CFV: New HSX Committer: Serguei Spitsyn In-Reply-To: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> References: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> Message-ID: <5110A511.3080502@oracle.com> Vote: yes On 2/4/13 7:25 PM, Staffan Larsen wrote: > I hereby nominate Serguei Spitsyn (OpenJDK user name: sspitsyn) to HSX Committer. > > Serguei is a member of the Hotspot Serviceability team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=serguei.spitsyn at oracle.com > > Votes are due by February 18, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Staffan > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote From bengt.rutisson at oracle.com Mon Feb 4 22:25:49 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 05 Feb 2013 07:25:49 +0100 Subject: Result: CFV: New HSX Committer: Erik Helin In-Reply-To: <50FD2B07.7030802@oracle.com> References: <50FD2B07.7030802@oracle.com> Message-ID: <5110A5ED.7090502@oracle.com> Voting for Erik Helin is now closed. Yes: 13 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Bengt On 1/21/13 12:48 PM, Bengt Rutisson wrote: > > I hereby nominate Erik Helin (OpenJDK user name: ehelin) to HSX > Committer. > > Erik is a member of the Hotspot GC team. He has contributed 8 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.helin at oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/log?rev=erik.x.helin at oracle.com > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=erik.helin at oracle.com > > > Votes are due by February 4, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From stefan.karlsson at oracle.com Tue Feb 5 01:20:44 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 05 Feb 2013 10:20:44 +0100 Subject: CFV: New HSX Committer: Serguei Spitsyn In-Reply-To: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> References: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> Message-ID: <5110CEEC.6090806@oracle.com> vote: yes StefanK On 02/04/2013 07:25 PM, Staffan Larsen wrote: > I hereby nominate Serguei Spitsyn (OpenJDK user name: sspitsyn) to HSX Committer. > > Serguei is a member of the Hotspot Serviceability team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=serguei.spitsyn at oracle.com > > Votes are due by February 18, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Staffan > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote From joseph.provino at oracle.com Tue Feb 5 06:22:26 2013 From: joseph.provino at oracle.com (Joe Provino) Date: Tue, 05 Feb 2013 09:22:26 -0500 Subject: Request for review: JDK-8003581, , UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS In-Reply-To: <5102B1DC.4050409@oracle.com> References: <51017FBE.1060106@oracle.com> <51021BA4.9000203@oracle.com> <5102B1DC.4050409@oracle.com> Message-ID: <511115A2.4090900@oracle.com> Would anyone have time to review this updated change. It's one file -- arguments.cpp. thanks. joe On 1/25/2013 11:25 AM, Joe Provino wrote: > With changes from Bob and David, here is a new webrev: > > http://cr.openjdk.java.net/~jprovino/8003581/webrev.01 > > joe > > On 1/25/2013 12:44 AM, David Holmes wrote: >> On 25/01/2013 4:45 AM, Bob Vandette wrote: >>> You claim to be defaulting to SerialGC but you don't set UseG1GC to >>> false? >> >> The UNSUPPORTED_OPTION macro does that. >> >> But I don't see anything forcing use of serialGC. And >> force_serial_gc() should not be altered. >> >>> If you build with INCLUDE_ALL_GCS=1, the G1 code will be available >>> and be used. >> >> Only on those platforms that support it. >> >> David >> >>> Bob. >>> >>> On Jan 24, 2013, at 1:38 PM, Joe Provino wrote: >>> >>>> Webrev is here: >>>> http://cr.openjdk.java.net/~jprovino/8003581/webrev.00 >>>> >>>> It's a change to one file: arguments.cpp. >>>> >>>> thanks. >>>> >>>> joe >>> From joseph.provino at oracle.com Tue Feb 5 06:24:42 2013 From: joseph.provino at oracle.com (Joe Provino) Date: Tue, 05 Feb 2013 09:24:42 -0500 Subject: Review request: 7118588 Profiled JVM needs to be linked statically for gprof to profile libjvm.so In-Reply-To: <5105397E.5030203@oracle.com> References: <5102B3EC.80305@oracle.com> <51038C5F.8060902@oracle.com> <5105397E.5030203@oracle.com> Message-ID: <5111162A.5020104@oracle.com> Would anyone have time to review this after reading the discussion below? Webrev is here: http://cr.openjdk.java.net/~jprovino/7118588/webrev.00 thanks. joe On 1/27/2013 9:28 AM, Joe Provino wrote: > > > On 1/26/2013 2:57 AM, David Holmes wrote: >> On 26/01/2013 2:33 AM, Joe Provino wrote: >>> Webrev is here: http://cr.openjdk.java.net/~jprovino/7118588/webrev.00 >> >> The bug synopsis is confusing - seems to me it is the launcher your >> are changing not the VM. > > I agree. A better synopsis would be "Unable to link gamma launcher > statically with the VM object files." > >> Do we have gprof on Solaris? Does this change fix or break other >> profiling tools ? > > I think these are actually unrelated to the problem once the problem > is stated correctly. > >> I don't grok the actual changes > > The problem is that if you attempt to build the gamma launcher > statically with the VM object files > by setting LINK_INTO=AOUT on the make command line, the launcher will > get undefined symbols. > > The handling of LINK_INTO in launcher.make is incorrect. > > ifeq ($(LINK_INTO),AOUT) > LAUNCHER.o = launcher.o $(JVM_OBJ_FILES) > LIBS_LAUNCHER += $(STATIC_STDCXX) $(LIBS) > else > LAUNCHER.o = launcher.o > LIBS_LAUNCHER += -l$(JVM) $(LIBS) > endif > > launcher.o is undefined. That isn't a problem in itself because > LAUNCHER.o is never used. > > This is the line that links the launcher: > > $(LINK_LAUNCHER) $(LFLAGS_LAUNCHER) -o $@ $(sort $(OBJS)) > $(LIBS_LAUNCHER) > > The simple fix is to add $(LAUNCHER.o): > > $(LINK_LAUNCHER) $(LFLAGS_LAUNCHER) -o $@ $(sort $(OBJS)) > $(LAUNCHER.o) $(LIBS_LAUNCHER) > > I also got rid of launcher.o since it's not used. > > I think to clean this up, I'd define LAUNCHER.o to be the launcher > object files plus the JVM object files > if LINK_INTO is AOUT and the launcher object files plus -ljvm > otherwise. Then to link the launcher, > I'd use $(LAUNCHER.o) $(LIBS). > > Should I do something like this or just the minimal fix? > > joe > > >> but there is a typo in the bsd file: >> >> + # profiledminimal1 minimal1 __shark/profiled >> >> shark? :) > > fixed. > >> >> David >> >>> >>> joe From joseph.provino at oracle.com Tue Feb 5 06:26:13 2013 From: joseph.provino at oracle.com (Joe Provino) Date: Tue, 05 Feb 2013 09:26:13 -0500 Subject: Review request: 8006878 Some non-existent GC source files are in the minimalVM exclude list In-Reply-To: <5102B299.5020605@oracle.com> References: <5102B299.5020605@oracle.com> Message-ID: <51111685.10208@oracle.com> Would anyone have time to review this? It's very short. thanks. joe On 1/25/2013 11:28 AM, Joe Provino wrote: > 2 files changed. > > Webrev is here: http://cr.openjdk.java.net/~jprovino/8006878/webrev.00 > > joe From jon.masamitsu at oracle.com Tue Feb 5 07:36:06 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 05 Feb 2013 07:36:06 -0800 Subject: Review request: 8006878 Some non-existent GC source files are in the minimalVM exclude list In-Reply-To: <51111685.10208@oracle.com> References: <5102B299.5020605@oracle.com> <51111685.10208@oracle.com> Message-ID: <511126E6.7040300@oracle.com> Joe, Changes look good. Jon On 2/5/2013 6:26 AM, Joe Provino wrote: > Would anyone have time to review this? It's very short. > > thanks. > > joe > > On 1/25/2013 11:28 AM, Joe Provino wrote: >> 2 files changed. >> >> Webrev is here: http://cr.openjdk.java.net/~jprovino/8006878/webrev.00 >> >> joe From joseph.provino at oracle.com Tue Feb 5 07:46:34 2013 From: joseph.provino at oracle.com (Joe Provino) Date: Tue, 05 Feb 2013 10:46:34 -0500 Subject: Request for review: JDK-8003581, , UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS In-Reply-To: <511125C8.4030405@oracle.com> References: <511125C8.4030405@oracle.com> Message-ID: <5111295A.3020106@oracle.com> On 2/5/2013 10:31 AM, Chris Plummer wrote: > Hi Joe, > > David and I made quite a few comments over the past few days. Did you > not see them? Somehow I missed them yesterday. > I believe the conclusion is that this is what you need: > > #if INCLUDE_ALL_GCS > #if (defined JAVASE_EMBEDDED || defined ARM) > UNSUPPORTED_OPTION(UseG1GC, "G1 GC"); > #endif > #endif > > #if !INCLUDE_ALL_GCS > UNSUPPORTED_GC_OPTION(UseG1GC); > UNSUPPORTED_GC_OPTION(UseParallelGC); > UNSUPPORTED_GC_OPTION(UseParallelOldGC); > UNSUPPORTED_GC_OPTION(UseConcMarkSweepGC); > UNSUPPORTED_GC_OPTION(UseParNewGC); > #endif // INCLUDE_ALL_GCS > > David also suggested that the 2nd part above be moved to > force_serial_gc(). Okay, sounds good to me. I'll make those changes. joe > > Chris > > On 2/5/13 6:22 AM, Joe Provino wrote: >> Would anyone have time to review this updated change. It's one file -- >> arguments.cpp. >> >> thanks. >> >> joe >> >> On 1/25/2013 11:25 AM, Joe Provino wrote: >>> > With changes from Bob and David, here is a new webrev: >>> > >>> > http://cr.openjdk.java.net/~jprovino/8003581/webrev.01 >>> > >>> > joe >>> > >>> > On 1/25/2013 12:44 AM, David Holmes wrote: >>>> >> On 25/01/2013 4:45 AM, Bob Vandette wrote: >>>>> >>> You claim to be defaulting to SerialGC but you don't set UseG1GC to >>>>> >>> false? >>>> >> >>>> >> The UNSUPPORTED_OPTION macro does that. >>>> >> >>>> >> But I don't see anything forcing use of serialGC. And >>>> >> force_serial_gc() should not be altered. >>>> >> >>>>> >>> If you build with INCLUDE_ALL_GCS=1, the G1 code will be available >>>>> >>> and be used. >>>> >> >>>> >> Only on those platforms that support it. >>>> >> >>>> >> David >>>> >> >>>>> >>> Bob. >>>>> >>> >>>>> >>> On Jan 24, 2013, at 1:38 PM, Joe Provino wrote: >>>>> >>> >>>>>> >>>> Webrev is here: >>>>>> >>>> http://cr.openjdk.java.net/~jprovino/8003581/webrev.00 >>>>>> >>>> >>>>>> >>>> It's a change to one file: arguments.cpp. >>>>>> >>>> >>>>>> >>>> thanks. >>>>>> >>>> >>>>>> >>>> joe >>>>> >>> > From mikael.gerdin at oracle.com Tue Feb 5 08:16:17 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 05 Feb 2013 17:16:17 +0100 Subject: Review request: 7118588 Profiled JVM needs to be linked statically for gprof to profile libjvm.so In-Reply-To: <5111162A.5020104@oracle.com> References: <5102B3EC.80305@oracle.com> <51038C5F.8060902@oracle.com> <5105397E.5030203@oracle.com> <5111162A.5020104@oracle.com> Message-ID: <51113051.9050806@oracle.com> Joe, On 2013-02-05 15:24, Joe Provino wrote: > Would anyone have time to review this after reading the discussion below? > > Webrev is here: http://cr.openjdk.java.net/~jprovino/7118588/webrev.00 Looks good to me. I remember writing exactly this patch when I wanted to run with gprof a while back and ran into the same problem. /Mikael > > thanks. > > joe > > > On 1/27/2013 9:28 AM, Joe Provino wrote: >> >> >> On 1/26/2013 2:57 AM, David Holmes wrote: >>> On 26/01/2013 2:33 AM, Joe Provino wrote: >>>> Webrev is here: http://cr.openjdk.java.net/~jprovino/7118588/webrev.00 >>> >>> The bug synopsis is confusing - seems to me it is the launcher your >>> are changing not the VM. >> >> I agree. A better synopsis would be "Unable to link gamma launcher >> statically with the VM object files." >> >>> Do we have gprof on Solaris? Does this change fix or break other >>> profiling tools ? >> >> I think these are actually unrelated to the problem once the problem >> is stated correctly. >> >>> I don't grok the actual changes >> >> The problem is that if you attempt to build the gamma launcher >> statically with the VM object files >> by setting LINK_INTO=AOUT on the make command line, the launcher will >> get undefined symbols. >> >> The handling of LINK_INTO in launcher.make is incorrect. >> >> ifeq ($(LINK_INTO),AOUT) >> LAUNCHER.o = launcher.o $(JVM_OBJ_FILES) >> LIBS_LAUNCHER += $(STATIC_STDCXX) $(LIBS) >> else >> LAUNCHER.o = launcher.o >> LIBS_LAUNCHER += -l$(JVM) $(LIBS) >> endif >> >> launcher.o is undefined. That isn't a problem in itself because >> LAUNCHER.o is never used. >> >> This is the line that links the launcher: >> >> $(LINK_LAUNCHER) $(LFLAGS_LAUNCHER) -o $@ $(sort $(OBJS)) >> $(LIBS_LAUNCHER) >> >> The simple fix is to add $(LAUNCHER.o): >> >> $(LINK_LAUNCHER) $(LFLAGS_LAUNCHER) -o $@ $(sort $(OBJS)) >> $(LAUNCHER.o) $(LIBS_LAUNCHER) >> >> I also got rid of launcher.o since it's not used. >> >> I think to clean this up, I'd define LAUNCHER.o to be the launcher >> object files plus the JVM object files >> if LINK_INTO is AOUT and the launcher object files plus -ljvm >> otherwise. Then to link the launcher, >> I'd use $(LAUNCHER.o) $(LIBS). >> >> Should I do something like this or just the minimal fix? >> >> joe >> >> >>> but there is a typo in the bsd file: >>> >>> + # profiledminimal1 minimal1 __shark/profiled >>> >>> shark? :) >> >> fixed. >> >>> >>> David >>> >>>> >>>> joe -- Mikael Gerdin Java SE VM SQE Stockholm From joseph.provino at oracle.com Tue Feb 5 08:17:20 2013 From: joseph.provino at oracle.com (Joe Provino) Date: Tue, 05 Feb 2013 11:17:20 -0500 Subject: Review request: 7118588 Profiled JVM needs to be linked statically for gprof to profile libjvm.so In-Reply-To: <51113051.9050806@oracle.com> References: <5102B3EC.80305@oracle.com> <51038C5F.8060902@oracle.com> <5105397E.5030203@oracle.com> <5111162A.5020104@oracle.com> <51113051.9050806@oracle.com> Message-ID: <51113090.8020703@oracle.com> thanks. joe On 2/5/2013 11:16 AM, Mikael Gerdin wrote: > Joe, > > On 2013-02-05 15:24, Joe Provino wrote: >> Would anyone have time to review this after reading the discussion >> below? >> >> Webrev is here: http://cr.openjdk.java.net/~jprovino/7118588/webrev.00 > > Looks good to me. I remember writing exactly this patch when I wanted > to run with gprof a while back and ran into the same problem. > > /Mikael > >> >> thanks. >> >> joe >> >> >> On 1/27/2013 9:28 AM, Joe Provino wrote: >>> >>> >>> On 1/26/2013 2:57 AM, David Holmes wrote: >>>> On 26/01/2013 2:33 AM, Joe Provino wrote: >>>>> Webrev is here: >>>>> http://cr.openjdk.java.net/~jprovino/7118588/webrev.00 >>>> >>>> The bug synopsis is confusing - seems to me it is the launcher your >>>> are changing not the VM. >>> >>> I agree. A better synopsis would be "Unable to link gamma launcher >>> statically with the VM object files." >>> >>>> Do we have gprof on Solaris? Does this change fix or break other >>>> profiling tools ? >>> >>> I think these are actually unrelated to the problem once the problem >>> is stated correctly. >>> >>>> I don't grok the actual changes >>> >>> The problem is that if you attempt to build the gamma launcher >>> statically with the VM object files >>> by setting LINK_INTO=AOUT on the make command line, the launcher will >>> get undefined symbols. >>> >>> The handling of LINK_INTO in launcher.make is incorrect. >>> >>> ifeq ($(LINK_INTO),AOUT) >>> LAUNCHER.o = launcher.o $(JVM_OBJ_FILES) >>> LIBS_LAUNCHER += $(STATIC_STDCXX) $(LIBS) >>> else >>> LAUNCHER.o = launcher.o >>> LIBS_LAUNCHER += -l$(JVM) $(LIBS) >>> endif >>> >>> launcher.o is undefined. That isn't a problem in itself because >>> LAUNCHER.o is never used. >>> >>> This is the line that links the launcher: >>> >>> $(LINK_LAUNCHER) $(LFLAGS_LAUNCHER) -o $@ $(sort $(OBJS)) >>> $(LIBS_LAUNCHER) >>> >>> The simple fix is to add $(LAUNCHER.o): >>> >>> $(LINK_LAUNCHER) $(LFLAGS_LAUNCHER) -o $@ $(sort $(OBJS)) >>> $(LAUNCHER.o) $(LIBS_LAUNCHER) >>> >>> I also got rid of launcher.o since it's not used. >>> >>> I think to clean this up, I'd define LAUNCHER.o to be the launcher >>> object files plus the JVM object files >>> if LINK_INTO is AOUT and the launcher object files plus -ljvm >>> otherwise. Then to link the launcher, >>> I'd use $(LAUNCHER.o) $(LIBS). >>> >>> Should I do something like this or just the minimal fix? >>> >>> joe >>> >>> >>>> but there is a typo in the bsd file: >>>> >>>> + # profiledminimal1 minimal1 __shark/profiled >>>> >>>> shark? :) >>> >>> fixed. >>> >>>> >>>> David >>>> >>>>> >>>>> joe > From joseph.provino at oracle.com Tue Feb 5 09:12:05 2013 From: joseph.provino at oracle.com (Joe Provino) Date: Tue, 05 Feb 2013 12:12:05 -0500 Subject: Request for review: JDK-8003581, , UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS In-Reply-To: <511125C8.4030405@oracle.com> References: <511125C8.4030405@oracle.com> Message-ID: <51113D65.1030600@oracle.com> Here's the latest webrev after Chris and David's comments: http://cr.openjdk.java.net/~jprovino/8003581/webrev.02/ joe On 2/5/2013 10:31 AM, Chris Plummer wrote: > Hi Joe, > > David and I made quite a few comments over the past few days. Did you > not see them? I believe the conclusion is that this is what you need: > > #if INCLUDE_ALL_GCS > #if (defined JAVASE_EMBEDDED || defined ARM) > UNSUPPORTED_OPTION(UseG1GC, "G1 GC"); > #endif > #endif > > #if !INCLUDE_ALL_GCS > UNSUPPORTED_GC_OPTION(UseG1GC); > UNSUPPORTED_GC_OPTION(UseParallelGC); > UNSUPPORTED_GC_OPTION(UseParallelOldGC); > UNSUPPORTED_GC_OPTION(UseConcMarkSweepGC); > UNSUPPORTED_GC_OPTION(UseParNewGC); > #endif // INCLUDE_ALL_GCS > > David also suggested that the 2nd part above be moved to > force_serial_gc(). > > Chris > > On 2/5/13 6:22 AM, Joe Provino wrote: >> Would anyone have time to review this updated change. It's one file -- >> arguments.cpp. >> >> thanks. >> >> joe >> >> On 1/25/2013 11:25 AM, Joe Provino wrote: >>> > With changes from Bob and David, here is a new webrev: >>> > >>> > http://cr.openjdk.java.net/~jprovino/8003581/webrev.01 >>> > >>> > joe >>> > >>> > On 1/25/2013 12:44 AM, David Holmes wrote: >>>> >> On 25/01/2013 4:45 AM, Bob Vandette wrote: >>>>> >>> You claim to be defaulting to SerialGC but you don't set UseG1GC to >>>>> >>> false? >>>> >> >>>> >> The UNSUPPORTED_OPTION macro does that. >>>> >> >>>> >> But I don't see anything forcing use of serialGC. And >>>> >> force_serial_gc() should not be altered. >>>> >> >>>>> >>> If you build with INCLUDE_ALL_GCS=1, the G1 code will be available >>>>> >>> and be used. >>>> >> >>>> >> Only on those platforms that support it. >>>> >> >>>> >> David >>>> >> >>>>> >>> Bob. >>>>> >>> >>>>> >>> On Jan 24, 2013, at 1:38 PM, Joe Provino wrote: >>>>> >>> >>>>>> >>>> Webrev is here: >>>>>> >>>> http://cr.openjdk.java.net/~jprovino/8003581/webrev.00 >>>>>> >>>> >>>>>> >>>> It's a change to one file: arguments.cpp. >>>>>> >>>> >>>>>> >>>> thanks. >>>>>> >>>> >>>>>> >>>> joe >>>>> >>> > From mikael.gerdin at oracle.com Tue Feb 5 10:52:08 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 05 Feb 2013 19:52:08 +0100 Subject: Review request: JDK-8006753 fix failed for JDK-8002415 White box testing API for HotSpot In-Reply-To: <5110220A.20703@oracle.com> References: <510FBECB.6050903@oracle.com> <5110220A.20703@oracle.com> Message-ID: <511154D8.3060306@oracle.com> Thanks Dmitry and Christian for the reviews. Can someone with Reviewer status please have a look at this? /Mikael On 2013-02-04 22:03, Dmitry Samersoff wrote: > Mikael, > > Looks good for me. > > -Dmitry > > On 2013-02-04 17:59, Mikael Gerdin wrote: >> Hi, >> >> Background: >> Even from the beginning of the WhiteBox testing API implementation the >> tests have not worked on builds promoted by release engineering due to >> the fact that the wb.jar file containing the Java classes was not >> imported by the JDK-level makefiles. >> On one level this was ok since we didn't want to ship the classes to end >> users and we worked around the complexity of somehow post-processing the >> RE bundles to remove them. >> >> The problem is that we aren't able to run the WhiteBox tests in >> promotion testing, or to verify fixes against earlier builds. >> >> Solution: >> The solution suggested here is to put the WhiteBox helper classes in the >> testlibrary directory under test/ and >> * tell jtreg to first compile the classes >> * run a special Java program to copy the classes to the test work directory >> * run the white box test with -Xbootclasspath/a:. to pick up the copied >> classes. >> >> The solution is kind-of hackish but I've been unable to come up with a >> better solution without performing complex surgery on jtreg. >> >> The changes to the make/ directory should basically revert the makefile >> changes that were added to support this API. >> >> Webrev: >> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.0/ >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006753 >> >> Note about renamed/moved files: >> I will try to make sure that the moved/renamed files will be tracked >> properly by mercurial, but I think that using patch files and MQ breaks >> this so I'll do this after the review is done. >> >> Thanks >> /Mikael > > From coleen.phillimore at oracle.com Tue Feb 5 11:10:49 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 05 Feb 2013 14:10:49 -0500 Subject: Review request: JDK-8006753 fix failed for JDK-8002415 White box testing API for HotSpot In-Reply-To: <511154D8.3060306@oracle.com> References: <510FBECB.6050903@oracle.com> <5110220A.20703@oracle.com> <511154D8.3060306@oracle.com> Message-ID: <51115939.3020302@oracle.com> I've looked at this. It seems very reasonable and not hacky to me to have the whitebox api built in the jtreg test/library directory. Thanks, Coleen On 02/05/2013 01:52 PM, Mikael Gerdin wrote: > Thanks Dmitry and Christian for the reviews. > Can someone with Reviewer status please have a look at this? > > /Mikael > > On 2013-02-04 22:03, Dmitry Samersoff wrote: >> Mikael, >> >> Looks good for me. >> >> -Dmitry >> >> On 2013-02-04 17:59, Mikael Gerdin wrote: >>> Hi, >>> >>> Background: >>> Even from the beginning of the WhiteBox testing API implementation the >>> tests have not worked on builds promoted by release engineering due to >>> the fact that the wb.jar file containing the Java classes was not >>> imported by the JDK-level makefiles. >>> On one level this was ok since we didn't want to ship the classes to >>> end >>> users and we worked around the complexity of somehow post-processing >>> the >>> RE bundles to remove them. >>> >>> The problem is that we aren't able to run the WhiteBox tests in >>> promotion testing, or to verify fixes against earlier builds. >>> >>> Solution: >>> The solution suggested here is to put the WhiteBox helper classes in >>> the >>> testlibrary directory under test/ and >>> * tell jtreg to first compile the classes >>> * run a special Java program to copy the classes to the test work >>> directory >>> * run the white box test with -Xbootclasspath/a:. to pick up the copied >>> classes. >>> >>> The solution is kind-of hackish but I've been unable to come up with a >>> better solution without performing complex surgery on jtreg. >>> >>> The changes to the make/ directory should basically revert the makefile >>> changes that were added to support this API. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.0/ >>> Bug: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006753 >>> >>> Note about renamed/moved files: >>> I will try to make sure that the moved/renamed files will be tracked >>> properly by mercurial, but I think that using patch files and MQ breaks >>> this so I'll do this after the review is done. >>> >>> Thanks >>> /Mikael >> >> From mikael.gerdin at oracle.com Tue Feb 5 11:25:49 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 05 Feb 2013 20:25:49 +0100 Subject: Review request: JDK-8006753 fix failed for JDK-8002415 White box testing API for HotSpot In-Reply-To: <51115939.3020302@oracle.com> References: <510FBECB.6050903@oracle.com> <5110220A.20703@oracle.com> <511154D8.3060306@oracle.com> <51115939.3020302@oracle.com> Message-ID: <51115CBD.4050904@oracle.com> Coleen, On 2013-02-05 20:10, Coleen Phillimore wrote: > > I've looked at this. It seems very reasonable and not hacky to me to > have the whitebox api built in the jtreg test/library directory. Right. The hacky bit is not to put the api in that directory, the "hacky" bit is: - * @run compile -J-XX:+UnlockDiagnosticVMOptions -J-XX:+WhiteBoxAPI WBApi.java - * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI WBApi + * @library /testlibrary /testlibrary/whitebox + * @build WBApi + * @run main ClassFileDumper sun.hotspot.WhiteBox + * @run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI WBApi that is: running the class ClassFileDumper to copy the class sun.hotspot.WhiteBox to the test execution's current working directory. /Mikael > > Thanks, > Coleen > > On 02/05/2013 01:52 PM, Mikael Gerdin wrote: >> Thanks Dmitry and Christian for the reviews. >> Can someone with Reviewer status please have a look at this? >> >> /Mikael >> >> On 2013-02-04 22:03, Dmitry Samersoff wrote: >>> Mikael, >>> >>> Looks good for me. >>> >>> -Dmitry >>> >>> On 2013-02-04 17:59, Mikael Gerdin wrote: >>>> Hi, >>>> >>>> Background: >>>> Even from the beginning of the WhiteBox testing API implementation the >>>> tests have not worked on builds promoted by release engineering due to >>>> the fact that the wb.jar file containing the Java classes was not >>>> imported by the JDK-level makefiles. >>>> On one level this was ok since we didn't want to ship the classes to >>>> end >>>> users and we worked around the complexity of somehow post-processing >>>> the >>>> RE bundles to remove them. >>>> >>>> The problem is that we aren't able to run the WhiteBox tests in >>>> promotion testing, or to verify fixes against earlier builds. >>>> >>>> Solution: >>>> The solution suggested here is to put the WhiteBox helper classes in >>>> the >>>> testlibrary directory under test/ and >>>> * tell jtreg to first compile the classes >>>> * run a special Java program to copy the classes to the test work >>>> directory >>>> * run the white box test with -Xbootclasspath/a:. to pick up the copied >>>> classes. >>>> >>>> The solution is kind-of hackish but I've been unable to come up with a >>>> better solution without performing complex surgery on jtreg. >>>> >>>> The changes to the make/ directory should basically revert the makefile >>>> changes that were added to support this API. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.0/ >>>> Bug: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006753 >>>> >>>> Note about renamed/moved files: >>>> I will try to make sure that the moved/renamed files will be tracked >>>> properly by mercurial, but I think that using patch files and MQ breaks >>>> this so I'll do this after the review is done. >>>> >>>> Thanks >>>> /Mikael >>> >>> > From igor.ignatyev at oracle.com Tue Feb 5 11:51:22 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 05 Feb 2013 23:51:22 +0400 Subject: Review request: JDK-8006753 fix failed for JDK-8002415 White box testing API for HotSpot In-Reply-To: <510FBECB.6050903@oracle.com> References: <510FBECB.6050903@oracle.com> Message-ID: <511162BA.60301@oracle.com> Hi Mikael, I think this will make more uncomfortable to use WhiteBox with harnesses other than jtreg. e.g. for tonga: now we can just put wb.jar to classpath and use it. but after your changes we will need to build it ourselves before running tests. Best regards, Igor Ignatyev On 02/04/2013 05:59 PM, Mikael Gerdin wrote: > Hi, > > Background: > Even from the beginning of the WhiteBox testing API implementation the > tests have not worked on builds promoted by release engineering due to > the fact that the wb.jar file containing the Java classes was not > imported by the JDK-level makefiles. > On one level this was ok since we didn't want to ship the classes to end > users and we worked around the complexity of somehow post-processing the > RE bundles to remove them. > > The problem is that we aren't able to run the WhiteBox tests in > promotion testing, or to verify fixes against earlier builds. > > Solution: > The solution suggested here is to put the WhiteBox helper classes in the > testlibrary directory under test/ and > * tell jtreg to first compile the classes > * run a special Java program to copy the classes to the test work directory > * run the white box test with -Xbootclasspath/a:. to pick up the copied > classes. > > The solution is kind-of hackish but I've been unable to come up with a > better solution without performing complex surgery on jtreg. > > The changes to the make/ directory should basically revert the makefile > changes that were added to support this API. > > Webrev: > http://cr.openjdk.java.net/~mgerdin/8006753/webrev.0/ > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006753 > > Note about renamed/moved files: > I will try to make sure that the moved/renamed files will be tracked > properly by mercurial, but I think that using patch files and MQ breaks > this so I'll do this after the review is done. > > Thanks > /Mikael From dmitry.samersoff at oracle.com Tue Feb 5 11:59:57 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 05 Feb 2013 23:59:57 +0400 Subject: Review request: JDK-8006753 fix failed for JDK-8002415 White box testing API for HotSpot In-Reply-To: <511162BA.60301@oracle.com> References: <510FBECB.6050903@oracle.com> <511162BA.60301@oracle.com> Message-ID: <511164BD.4010706@oracle.com> Igor, I did couple of experiments by my self sometime ago and come to the same solution. So I'm not sure we have better options. -Dmitry On 2013-02-05 23:51, Igor Ignatyev wrote: > Hi Mikael, > > I think this will make more uncomfortable to use WhiteBox with harnesses > other than jtreg. e.g. for tonga: > now we can just put wb.jar to classpath and use it. but after your > changes we will need to build it ourselves before running tests. > > Best regards, > Igor Ignatyev > > On 02/04/2013 05:59 PM, Mikael Gerdin wrote: >> Hi, >> >> Background: >> Even from the beginning of the WhiteBox testing API implementation the >> tests have not worked on builds promoted by release engineering due to >> the fact that the wb.jar file containing the Java classes was not >> imported by the JDK-level makefiles. >> On one level this was ok since we didn't want to ship the classes to end >> users and we worked around the complexity of somehow post-processing the >> RE bundles to remove them. >> >> The problem is that we aren't able to run the WhiteBox tests in >> promotion testing, or to verify fixes against earlier builds. >> >> Solution: >> The solution suggested here is to put the WhiteBox helper classes in the >> testlibrary directory under test/ and >> * tell jtreg to first compile the classes >> * run a special Java program to copy the classes to the test work >> directory >> * run the white box test with -Xbootclasspath/a:. to pick up the copied >> classes. >> >> The solution is kind-of hackish but I've been unable to come up with a >> better solution without performing complex surgery on jtreg. >> >> The changes to the make/ directory should basically revert the makefile >> changes that were added to support this API. >> >> Webrev: >> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.0/ >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006753 >> >> Note about renamed/moved files: >> I will try to make sure that the moved/renamed files will be tracked >> properly by mercurial, but I think that using patch files and MQ breaks >> this so I'll do this after the review is done. >> >> Thanks >> /Mikael -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From daniel.daugherty at oracle.com Tue Feb 5 17:24:34 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 06 Feb 2013 01:24:34 +0000 Subject: hg: hsx/hsx24/hotspot: 7182152: Instrumentation hot swap test incorrect monitor count Message-ID: <20130206012438.B740F47860@hg.openjdk.java.net> Changeset: fe6cd8dd4080 Author: dcubed Date: 2013-02-05 14:58 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/fe6cd8dd4080 7182152: Instrumentation hot swap test incorrect monitor count Summary: Remove optimization that allowed for old and/or obsolete methods in an itable; add new tracing support using -XX:TraceRedefineClasses=16384. Reviewed-by: coleenp, acorn, sspitsyn ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/prims/jvmtiRedefineClassesTrace.hpp ! src/share/vm/utilities/accessFlags.cpp ! src/share/vm/utilities/accessFlags.hpp From david.holmes at oracle.com Tue Feb 5 18:10:30 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Feb 2013 12:10:30 +1000 Subject: Review request: 8006878 Some non-existent GC source files are in the minimalVM exclude list In-Reply-To: <51111685.10208@oracle.com> References: <5102B299.5020605@oracle.com> <51111685.10208@oracle.com> Message-ID: <5111BB96.5050805@oracle.com> Joe, You never responded to my review question. David On 6/02/2013 12:26 AM, Joe Provino wrote: > Would anyone have time to review this? It's very short. > > thanks. > > joe > > On 1/25/2013 11:28 AM, Joe Provino wrote: >> 2 files changed. >> >> Webrev is here: http://cr.openjdk.java.net/~jprovino/8006878/webrev.00 >> >> joe From david.holmes at oracle.com Tue Feb 5 18:41:36 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Feb 2013 12:41:36 +1000 Subject: Request for review: JDK-8003581, , UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS In-Reply-To: <51113D65.1030600@oracle.com> References: <511125C8.4030405@oracle.com> <51113D65.1030600@oracle.com> Message-ID: <5111C2E0.1050602@oracle.com> On 6/02/2013 3:12 AM, Joe Provino wrote: > Here's the latest webrev after Chris and David's comments: > > http://cr.openjdk.java.net/~jprovino/8003581/webrev.02/ Almost there - this: ! #if INCLUDE_ALL_GCS ! #if (defined JAVASE_EMBEDDED || defined ARM) ! UNSUPPORTED_GC_OPTION(UseG1GC); ! #endif ! #endif should use: UNSUPPORTED_OPTION(UseG1GC, "G1 GC"); David > joe > > On 2/5/2013 10:31 AM, Chris Plummer wrote: >> Hi Joe, >> >> David and I made quite a few comments over the past few days. Did you >> not see them? I believe the conclusion is that this is what you need: >> >> #if INCLUDE_ALL_GCS >> #if (defined JAVASE_EMBEDDED || defined ARM) >> UNSUPPORTED_OPTION(UseG1GC, "G1 GC"); >> #endif >> #endif >> >> #if !INCLUDE_ALL_GCS >> UNSUPPORTED_GC_OPTION(UseG1GC); >> UNSUPPORTED_GC_OPTION(UseParallelGC); >> UNSUPPORTED_GC_OPTION(UseParallelOldGC); >> UNSUPPORTED_GC_OPTION(UseConcMarkSweepGC); >> UNSUPPORTED_GC_OPTION(UseParNewGC); >> #endif // INCLUDE_ALL_GCS >> >> David also suggested that the 2nd part above be moved to >> force_serial_gc(). >> >> Chris >> >> On 2/5/13 6:22 AM, Joe Provino wrote: >>> Would anyone have time to review this updated change. It's one file -- >>> arguments.cpp. >>> >>> thanks. >>> >>> joe >>> >>> On 1/25/2013 11:25 AM, Joe Provino wrote: >>>> > With changes from Bob and David, here is a new webrev: >>>> > >>>> > http://cr.openjdk.java.net/~jprovino/8003581/webrev.01 >>>> > >>>> > joe >>>> > >>>> > On 1/25/2013 12:44 AM, David Holmes wrote: >>>>> >> On 25/01/2013 4:45 AM, Bob Vandette wrote: >>>>>> >>> You claim to be defaulting to SerialGC but you don't set >>>>>> UseG1GC to >>>>>> >>> false? >>>>> >> >>>>> >> The UNSUPPORTED_OPTION macro does that. >>>>> >> >>>>> >> But I don't see anything forcing use of serialGC. And >>>>> >> force_serial_gc() should not be altered. >>>>> >> >>>>>> >>> If you build with INCLUDE_ALL_GCS=1, the G1 code will be >>>>>> available >>>>>> >>> and be used. >>>>> >> >>>>> >> Only on those platforms that support it. >>>>> >> >>>>> >> David >>>>> >> >>>>>> >>> Bob. >>>>>> >>> >>>>>> >>> On Jan 24, 2013, at 1:38 PM, Joe Provino wrote: >>>>>> >>> >>>>>>> >>>> Webrev is here: >>>>>>> >>>> http://cr.openjdk.java.net/~jprovino/8003581/webrev.00 >>>>>>> >>>> >>>>>>> >>>> It's a change to one file: arguments.cpp. >>>>>>> >>>> >>>>>>> >>>> thanks. >>>>>>> >>>> >>>>>>> >>>> joe >>>>>> >>> >> From vladimir.kozlov at oracle.com Tue Feb 5 19:52:20 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 05 Feb 2013 19:52:20 -0800 Subject: CFV: New HSX Committer: Bharadwaj Yadavalli In-Reply-To: <5074D97C.2000604@oracle.com> References: <5074D97C.2000604@oracle.com> Message-ID: <5111D374.2090101@oracle.com> I hereby nominate Bharadwaj Yadavalli (OpenJDK user name: bharadwaj) to HSX Committer. Bharadwaj is a member of the Hotspot Compiler group. He is working on Sumatra Project. He contributed 8 changesets to HSX project and he is qualified to be committer [1]: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=Bharadwaj Votes are due by Feb 19, 2013. Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Vladimir Kozlov [1] http://openjdk.java.net/projects/#project-committer [2] http://openjdk.java.net/census#hsx [3] http://openjdk.java.net/projects#committer-vote From vladimir.kozlov at oracle.com Tue Feb 5 20:15:08 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 05 Feb 2013 20:15:08 -0800 Subject: CFV: New HSX Committer: Bharadwaj Yadavalli In-Reply-To: <5111D374.2090101@oracle.com> References: <5074D97C.2000604@oracle.com> <5111D374.2090101@oracle.com> Message-ID: <5111D8CC.6050602@oracle.com> Vote: yes On 2/5/13 7:52 PM, Vladimir Kozlov wrote: > I hereby nominate Bharadwaj Yadavalli (OpenJDK user name: bharadwaj) to > HSX Committer. > > Bharadwaj is a member of the Hotspot Compiler group. He is working on > Sumatra Project. He contributed 8 changesets to HSX project and he is > qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=Bharadwaj > > Votes are due by Feb 19, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > From bengt.rutisson at oracle.com Tue Feb 5 20:41:22 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 06 Feb 2013 05:41:22 +0100 Subject: Result: CFV: New HSX Committer: Mikael Gerdin In-Reply-To: <50FEDDBC.9090100@oracle.com> References: <50FEDDBC.9090100@oracle.com> Message-ID: <5111DEF2.6040805@oracle.com> Voting for Erik Mikael Gerdin is now closed. Yes: 16 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Bengt On 1/22/13 7:43 PM, Bengt Rutisson wrote: > > I hereby nominate Mikael Gerdin (OpenJDK user name: mgerdin) to HSX > Committer. > > Mikael is a member of the Hotspot GC team. He has contributed 8 > changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/bf8c2b2c8cfa > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6bc207d87e5d > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a297b0e14605 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0e9e3cecdc81 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/2d503de963b3 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/04155d9c8c76 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/da91efe96a93 > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/730cc4ddd550 > > The last change does not list Mikael as a contributor, but this was > due to a mistake on my side. He was definitely a large contributor to > that fix. See: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-December/005030.html > > > Votes are due by February 5, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Bengt > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > From bengt.rutisson at oracle.com Tue Feb 5 20:42:17 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 06 Feb 2013 05:42:17 +0100 Subject: CFV: New HSX Committer: Bharadwaj Yadavalli In-Reply-To: <5111D374.2090101@oracle.com> References: <5074D97C.2000604@oracle.com> <5111D374.2090101@oracle.com> Message-ID: <5111DF29.9080703@oracle.com> Vote: yes On 2/6/13 4:52 AM, Vladimir Kozlov wrote: > I hereby nominate Bharadwaj Yadavalli (OpenJDK user name: bharadwaj) > to HSX Committer. > > Bharadwaj is a member of the Hotspot Compiler group. He is working on > Sumatra Project. He contributed 8 changesets to HSX project and he is > qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=Bharadwaj > > Votes are due by Feb 19, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > From daniel.daugherty at oracle.com Tue Feb 5 20:43:12 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 05 Feb 2013 21:43:12 -0700 Subject: CFV: New HSX Committer: Bharadwaj Yadavalli In-Reply-To: <5111D374.2090101@oracle.com> References: <5074D97C.2000604@oracle.com> <5111D374.2090101@oracle.com> Message-ID: <5111DF60.8080208@oracle.com> Vote: yes Dan On 2/5/13 8:52 PM, Vladimir Kozlov wrote: > I hereby nominate Bharadwaj Yadavalli (OpenJDK user name: bharadwaj) > to HSX Committer. > > Bharadwaj is a member of the Hotspot Compiler group. He is working on > Sumatra Project. He contributed 8 changesets to HSX project and he is > qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=Bharadwaj > > Votes are due by Feb 19, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > From john.r.rose at oracle.com Tue Feb 5 21:05:20 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 5 Feb 2013 21:05:20 -0800 Subject: CFV: New HSX Committer: Bharadwaj Yadavalli In-Reply-To: <5111D374.2090101@oracle.com> References: <5074D97C.2000604@oracle.com> <5111D374.2090101@oracle.com> Message-ID: <96929BBF-3740-43C1-B885-4BFDDC17F9C9@oracle.com> Vote: yes From rickard.backman at oracle.com Tue Feb 5 22:57:52 2013 From: rickard.backman at oracle.com (=?utf-8?Q?Rickard_B=C3=A4ckman?=) Date: Wed, 6 Feb 2013 07:57:52 +0100 Subject: CFV: New HSX Committer: Bharadwaj Yadavalli In-Reply-To: <5111D374.2090101@oracle.com> References: <5074D97C.2000604@oracle.com> <5111D374.2090101@oracle.com> Message-ID: <1462FBA0-A949-4458-B9DD-CCC6DA31316F@oracle.com> Vote: yes /R 6 feb 2013 kl. 04:52 skrev Vladimir Kozlov : > I hereby nominate Bharadwaj Yadavalli (OpenJDK user name: bharadwaj) to HSX Committer. > > Bharadwaj is a member of the Hotspot Compiler group. He is working on Sumatra Project. He contributed 8 changesets to HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=Bharadwaj > > Votes are due by Feb 19, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > From vladimir.x.ivanov at oracle.com Wed Feb 6 00:52:32 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 06 Feb 2013 11:52:32 +0300 Subject: CFV: New HSX Committer: Bharadwaj Yadavalli In-Reply-To: <5111D374.2090101@oracle.com> References: <5074D97C.2000604@oracle.com> <5111D374.2090101@oracle.com> Message-ID: <511219D0.3040402@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 2/6/13 6:52 AM, Vladimir Kozlov wrote: > I hereby nominate Bharadwaj Yadavalli (OpenJDK user name: bharadwaj) to > HSX Committer. > > Bharadwaj is a member of the Hotspot Compiler group. He is working on > Sumatra Project. He contributed 8 changesets to HSX project and he is > qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=Bharadwaj > > Votes are due by Feb 19, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > From roland.westrelin at oracle.com Wed Feb 6 00:30:51 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 6 Feb 2013 09:30:51 +0100 Subject: CFV: New HSX Committer: Bharadwaj Yadavalli In-Reply-To: <5111D374.2090101@oracle.com> References: <5074D97C.2000604@oracle.com> <5111D374.2090101@oracle.com> Message-ID: <97E5A220-2C82-4F3E-B753-927E4188C95A@oracle.com> Vote: yes Roland. From frederic.parain at oracle.com Wed Feb 6 01:42:54 2013 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 06 Feb 2013 10:42:54 +0100 Subject: CFV: New HSX Committer: Serguei Spitsyn In-Reply-To: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> References: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> Message-ID: <5112259E.7000705@oracle.com> Vote: yes Fred On 02/ 4/13 07:25 PM, Staffan Larsen wrote: > I hereby nominate Serguei Spitsyn (OpenJDK user name: sspitsyn) to HSX Committer. > > Serguei is a member of the Hotspot Serviceability team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=serguei.spitsyn at oracle.com > > Votes are due by February 18, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Staffan > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From christian.tornqvist at oracle.com Wed Feb 6 01:58:27 2013 From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com) Date: Wed, 06 Feb 2013 09:58:27 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130206095833.B82EB4787F@hg.openjdk.java.net> Changeset: e4634e41d7a6 Author: ctornqvi Date: 2013-02-05 19:28 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e4634e41d7a6 8005012: Add WB APIs to better support NMT testing Summary: Add WB API functions to enable better NMT testing Reviewed-by: dholmes, zgu ! src/share/tools/whitebox/sun/hotspot/WhiteBox.java ! src/share/vm/memory/allocation.hpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memPtr.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 2793d96a0acf Author: ctornqvi Date: 2013-02-05 22:01 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2793d96a0acf Merge From krystal.mo at oracle.com Wed Feb 6 03:16:20 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Wed, 06 Feb 2013 19:16:20 +0800 Subject: CFV: New HSX Committer: Bharadwaj Yadavalli In-Reply-To: <5111D374.2090101@oracle.com> References: <5074D97C.2000604@oracle.com> <5111D374.2090101@oracle.com> Message-ID: <51123B84.7060706@oracle.com> Vote: yes - Kris On 02/06/2013 11:52 AM, Vladimir Kozlov wrote: > I hereby nominate Bharadwaj Yadavalli (OpenJDK user name: bharadwaj) > to HSX Committer. > > Bharadwaj is a member of the Hotspot Compiler group. He is working on > Sumatra Project. He contributed 8 changesets to HSX project and he is > qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=Bharadwaj > > Votes are due by Feb 19, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > From christian.tornqvist at oracle.com Wed Feb 6 03:43:52 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Wed, 6 Feb 2013 03:43:52 -0800 (PST) Subject: CFV: New HSX Committer: Bharadwaj Yadavalli In-Reply-To: <5111D374.2090101@oracle.com> References: <5074D97C.2000604@oracle.com> <5111D374.2090101@oracle.com> Message-ID: Vote: yes -----Original Message----- From: Vladimir Kozlov Sent: den 6 februari 2013 04:52 To: hotspot-dev at openjdk.java.net Subject: CFV: New HSX Committer: Bharadwaj Yadavalli I hereby nominate Bharadwaj Yadavalli (OpenJDK user name: bharadwaj) to HSX Committer. Bharadwaj is a member of the Hotspot Compiler group. He is working on Sumatra Project. He contributed 8 changesets to HSX project and he is qualified to be committer [1]: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=Bharadwaj Votes are due by Feb 19, 2013. Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Vladimir Kozlov [1] http://openjdk.java.net/projects/#project-committer [2] http://openjdk.java.net/census#hsx [3] http://openjdk.java.net/projects#committer-vote From coleen.phillimore at oracle.com Wed Feb 6 04:30:17 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 06 Feb 2013 07:30:17 -0500 Subject: CFV: New HSX Committer: Bharadwaj Yadavalli In-Reply-To: <5111D374.2090101@oracle.com> References: <5074D97C.2000604@oracle.com> <5111D374.2090101@oracle.com> Message-ID: <51124CD9.3040507@oracle.com> Vote: yes On 2/5/2013 10:52 PM, Vladimir Kozlov wrote: > I hereby nominate Bharadwaj Yadavalli (OpenJDK user name: bharadwaj) > to HSX Committer. > > Bharadwaj is a member of the Hotspot Compiler group. He is working on > Sumatra Project. He contributed 8 changesets to HSX project and he is > qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=Bharadwaj > > Votes are due by Feb 19, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > From aleksey.shipilev at oracle.com Wed Feb 6 05:33:04 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 06 Feb 2013 17:33:04 +0400 Subject: RFR (XXS) CR 8006997: ContendedPaddingWidth should be uintx In-Reply-To: <51109FF5.6020804@oracle.com> References: <510668D1.5070002@oracle.com> <51109FF5.6020804@oracle.com> Message-ID: <51125B90.6030404@oracle.com> Hi David, On 02/05/2013 10:00 AM, David Holmes wrote: > You also need to change all the expressions using this value to use > unsigned types and update all the printfs to use an unsigned format > specifier. Ah, yes, thanks! > > grepsrc.sh ContendedPaddingWidth > ./cpu/sparc/vm/vm_version_sparc.cpp: (cache_line_size > > ContendedPaddingWidth)) cache_line_size is signed (although semantically fits into unsigned) What's the usual convention around HotSpot to handle signed/unsigned comparisons like these? Use static_cast? if (static_cast(cache_line_size) > ContededPaddingWidth) Use the ordinary cast: if ((unsigned int)cache_line_size) > ContededPaddingWidth) ...or even push forward changing all the cache_line_size family to unsigned? Grepping the code, ordinary cast seems to be used the most. I can do either of three. Thoughts? -Aleksey. From zhengyu.gu at oracle.com Wed Feb 6 05:56:46 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 06 Feb 2013 08:56:46 -0500 Subject: CFV: New HSX Committer: Bharadwaj Yadavalli In-Reply-To: <51124CD9.3040507@oracle.com> References: <5074D97C.2000604@oracle.com> <5111D374.2090101@oracle.com> <51124CD9.3040507@oracle.com> Message-ID: <5112611E.4050508@oracle.com> Vote: yes -Zhengyu On 2/6/2013 7:30 AM, Coleen Phillimore wrote: > Vote: yes > > On 2/5/2013 10:52 PM, Vladimir Kozlov wrote: >> I hereby nominate Bharadwaj Yadavalli (OpenJDK user name: bharadwaj) >> to HSX Committer. >> >> Bharadwaj is a member of the Hotspot Compiler group. He is working on >> Sumatra Project. He contributed 8 changesets to HSX project and he is >> qualified to be committer [1]: >> >> http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=Bharadwaj >> >> Votes are due by Feb 19, 2013. >> >> Only current HSX Committers [2] are eligible to vote on this >> nomination. Votes must be cast in the open by replying to this >> mailing list. >> >> For Lazy Consensus voting instructions, see [3]. >> >> Thanks, >> Vladimir Kozlov >> >> [1] http://openjdk.java.net/projects/#project-committer >> [2] http://openjdk.java.net/census#hsx >> [3] http://openjdk.java.net/projects#committer-vote >> >> >> >> > From joseph.provino at oracle.com Wed Feb 6 06:23:56 2013 From: joseph.provino at oracle.com (Joe Provino) Date: Wed, 06 Feb 2013 09:23:56 -0500 Subject: Review request: 8006878 Some non-existent GC source files are in the minimalVM exclude list In-Reply-To: <510A2A95.5030209@oracle.com> References: <5102B299.5020605@oracle.com> <510A2A95.5030209@oracle.com> Message-ID: <5112677C.1000005@oracle.com> On 1/31/2013 3:25 AM, David Holmes wrote: > Joe, > > On 26/01/2013 2:28 AM, Joe Provino wrote: >> 2 ffiles changed. >> >> Webrev is here: http://cr.openjdk.java.net/~jprovino/8006878/webrev.00 > > This seems to mix fixes for two different issues. The removal of the > INCLUDE_ALL_GC guard would seem to indicate there is a problem if not > building all GCs ie with the minimal VM - is that the case? David, sorry, I don't know how I'm managing to miss responses. I think the problem in excludeSrc.make excluding the non-existent file "yieldWorkingGroup.cpp" instead of the correct file "yieldingWorkGroup.cpp" meant that yieldingWorkGroup.cpp wasn't being excluded and didn't compile so I put in the guard to fix it. However, that being said, I tried not removing yieldingWorkGroup.cpp when INCLUDE_ALL_GCS is 0 and it compiled. So if there was a problem it doesn't appear to be a problem any more. joe > > David > >> joe From joseph.provino at oracle.com Wed Feb 6 06:33:02 2013 From: joseph.provino at oracle.com (Joe Provino) Date: Wed, 06 Feb 2013 09:33:02 -0500 Subject: Request for review: JDK-8003581, , UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS In-Reply-To: <5111C2E0.1050602@oracle.com> References: <511125C8.4030405@oracle.com> <51113D65.1030600@oracle.com> <5111C2E0.1050602@oracle.com> Message-ID: <5112699E.2010400@oracle.com> New webrev is here: http://cr.openjdk.java.net/~jprovino/8003581/webrev.03 thanks! joe On 2/5/2013 9:41 PM, David Holmes wrote: > On 6/02/2013 3:12 AM, Joe Provino wrote: >> Here's the latest webrev after Chris and David's comments: >> >> http://cr.openjdk.java.net/~jprovino/8003581/webrev.02/ > > Almost there - this: > > ! #if INCLUDE_ALL_GCS > ! #if (defined JAVASE_EMBEDDED || defined ARM) > ! UNSUPPORTED_GC_OPTION(UseG1GC); > ! #endif > ! #endif > > should use: > > UNSUPPORTED_OPTION(UseG1GC, "G1 GC"); > > David > >> joe >> >> On 2/5/2013 10:31 AM, Chris Plummer wrote: >>> Hi Joe, >>> >>> David and I made quite a few comments over the past few days. Did you >>> not see them? I believe the conclusion is that this is what you need: >>> >>> #if INCLUDE_ALL_GCS >>> #if (defined JAVASE_EMBEDDED || defined ARM) >>> UNSUPPORTED_OPTION(UseG1GC, "G1 GC"); >>> #endif >>> #endif >>> >>> #if !INCLUDE_ALL_GCS >>> UNSUPPORTED_GC_OPTION(UseG1GC); >>> UNSUPPORTED_GC_OPTION(UseParallelGC); >>> UNSUPPORTED_GC_OPTION(UseParallelOldGC); >>> UNSUPPORTED_GC_OPTION(UseConcMarkSweepGC); >>> UNSUPPORTED_GC_OPTION(UseParNewGC); >>> #endif // INCLUDE_ALL_GCS >>> >>> David also suggested that the 2nd part above be moved to >>> force_serial_gc(). >>> >>> Chris >>> >>> On 2/5/13 6:22 AM, Joe Provino wrote: >>>> Would anyone have time to review this updated change. It's one file -- >>>> arguments.cpp. >>>> >>>> thanks. >>>> >>>> joe >>>> >>>> On 1/25/2013 11:25 AM, Joe Provino wrote: >>>>> > With changes from Bob and David, here is a new webrev: >>>>> > >>>>> > http://cr.openjdk.java.net/~jprovino/8003581/webrev.01 >>>>> > >>>>> > joe >>>>> > >>>>> > On 1/25/2013 12:44 AM, David Holmes wrote: >>>>>> >> On 25/01/2013 4:45 AM, Bob Vandette wrote: >>>>>>> >>> You claim to be defaulting to SerialGC but you don't set >>>>>>> UseG1GC to >>>>>>> >>> false? >>>>>> >> >>>>>> >> The UNSUPPORTED_OPTION macro does that. >>>>>> >> >>>>>> >> But I don't see anything forcing use of serialGC. And >>>>>> >> force_serial_gc() should not be altered. >>>>>> >> >>>>>>> >>> If you build with INCLUDE_ALL_GCS=1, the G1 code will be >>>>>>> available >>>>>>> >>> and be used. >>>>>> >> >>>>>> >> Only on those platforms that support it. >>>>>> >> >>>>>> >> David >>>>>> >> >>>>>>> >>> Bob. >>>>>>> >>> >>>>>>> >>> On Jan 24, 2013, at 1:38 PM, Joe Provino wrote: >>>>>>> >>> >>>>>>>> >>>> Webrev is here: >>>>>>>> >>>> http://cr.openjdk.java.net/~jprovino/8003581/webrev.00 >>>>>>>> >>>> >>>>>>>> >>>> It's a change to one file: arguments.cpp. >>>>>>>> >>>> >>>>>>>> >>>> thanks. >>>>>>>> >>>> >>>>>>>> >>>> joe >>>>>>> >>> >>> From christian.tornqvist at oracle.com Wed Feb 6 07:25:02 2013 From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com) Date: Wed, 06 Feb 2013 15:25:02 +0000 Subject: hg: hsx/hsx24/hotspot: 8005013: Add NMT tests Message-ID: <20130206152507.BD05047888@hg.openjdk.java.net> Changeset: 322a24bc2e99 Author: ctornqvi Date: 2013-02-06 11:04 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/322a24bc2e99 8005013: Add NMT tests Summary: Add tests for the Native Memory Tracking feature, includes regression tests for 8005936 and 8004802 Reviewed-by: zgu, coleenp ! test/TEST.ROOT + test/runtime/NMT/AllocTestType.java + test/runtime/NMT/BaselineWithParameter.java + test/runtime/NMT/CommandLineDetail.java + test/runtime/NMT/CommandLineEmptyArgument.java + test/runtime/NMT/CommandLineInvalidArgument.java + test/runtime/NMT/CommandLineSummary.java + test/runtime/NMT/CommandLineTurnOffNMT.java + test/runtime/NMT/JcmdScale.java + test/runtime/NMT/JcmdWithNMTDisabled.java + test/runtime/NMT/PrintNMTStatistics.java + test/runtime/NMT/PrintNMTStatisticsWithNMTDisabled.java + test/runtime/NMT/ShutdownTwice.java + test/runtime/NMT/SummaryAfterShutdown.java + test/runtime/NMT/SummarySanityCheck.java From christian.thalinger at oracle.com Wed Feb 6 08:30:10 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 6 Feb 2013 08:30:10 -0800 Subject: CFV: New HSX Committer: Bharadwaj Yadavalli In-Reply-To: <5111D374.2090101@oracle.com> References: <5074D97C.2000604@oracle.com> <5111D374.2090101@oracle.com> Message-ID: <79A8D4AA-4C66-465F-BFCD-8B863F6F7FEC@oracle.com> Vote: yes -- Chris On Feb 5, 2013, at 7:52 PM, Vladimir Kozlov wrote: > I hereby nominate Bharadwaj Yadavalli (OpenJDK user name: bharadwaj) to HSX Committer. > > Bharadwaj is a member of the Hotspot Compiler group. He is working on Sumatra Project. He contributed 8 changesets to HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=Bharadwaj > > Votes are due by Feb 19, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > From vladimir.kozlov at oracle.com Wed Feb 6 08:30:54 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Feb 2013 08:30:54 -0800 Subject: Review request: JDK-8006753 fix failed for JDK-8002415 White box testing API for HotSpot In-Reply-To: <510FBECB.6050903@oracle.com> References: <510FBECB.6050903@oracle.com> Message-ID: <5112853E.4010404@oracle.com> Mikael, I like that all WB functionality is moved to test directory. You missed Copyright header in all new files. Could you rename ClassFileDumper to ClassFileInstaller? It will be more clear what it does. Thanks, Vladimir On 2/4/13 5:59 AM, Mikael Gerdin wrote: > Hi, > > Background: > Even from the beginning of the WhiteBox testing API implementation the > tests have not worked on builds promoted by release engineering due to > the fact that the wb.jar file containing the Java classes was not > imported by the JDK-level makefiles. > On one level this was ok since we didn't want to ship the classes to end > users and we worked around the complexity of somehow post-processing the > RE bundles to remove them. > > The problem is that we aren't able to run the WhiteBox tests in > promotion testing, or to verify fixes against earlier builds. > > Solution: > The solution suggested here is to put the WhiteBox helper classes in the > testlibrary directory under test/ and > * tell jtreg to first compile the classes > * run a special Java program to copy the classes to the test work directory > * run the white box test with -Xbootclasspath/a:. to pick up the copied > classes. > > The solution is kind-of hackish but I've been unable to come up with a > better solution without performing complex surgery on jtreg. > > The changes to the make/ directory should basically revert the makefile > changes that were added to support this API. > > Webrev: > http://cr.openjdk.java.net/~mgerdin/8006753/webrev.0/ > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006753 > > Note about renamed/moved files: > I will try to make sure that the moved/renamed files will be tracked > properly by mercurial, but I think that using patch files and MQ breaks > this so I'll do this after the review is done. > > Thanks > /Mikael From vladimir.kozlov at oracle.com Wed Feb 6 08:47:02 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Feb 2013 08:47:02 -0800 Subject: RFR (XXS) CR 8006997: ContendedPaddingWidth should be uintx In-Reply-To: <51125B90.6030404@oracle.com> References: <510668D1.5070002@oracle.com> <51109FF5.6020804@oracle.com> <51125B90.6030404@oracle.com> Message-ID: <51128906.3000302@oracle.com> On 2/6/13 5:33 AM, Aleksey Shipilev wrote: > Hi David, > > On 02/05/2013 10:00 AM, David Holmes wrote: >> You also need to change all the expressions using this value to use >> unsigned types and update all the printfs to use an unsigned format >> specifier. > > Ah, yes, thanks! > >> > grepsrc.sh ContendedPaddingWidth >> ./cpu/sparc/vm/vm_version_sparc.cpp: (cache_line_size > >> ContendedPaddingWidth)) > > cache_line_size is signed (although semantically fits into unsigned) > What's the usual convention around HotSpot to handle signed/unsigned > comparisons like these? Use static_cast? > > if (static_cast(cache_line_size) > ContededPaddingWidth) > > Use the ordinary cast: > > if ((unsigned int)cache_line_size) > ContededPaddingWidth) > > ...or even push forward changing all the cache_line_size family to unsigned? > > Grepping the code, ordinary cast seems to be used the most. I can do > either of three. Thoughts? Ordinary cast is fine, and you can change cache_line_size type if you want (it is used only in few places). One note, we have internal type 'uint' defined for such cases. Thanks, Vladimir > > -Aleksey. > From alejandro.murillo at oracle.com Wed Feb 6 09:45:12 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 06 Feb 2013 10:45:12 -0700 Subject: CFV: New HSX Committer: Bharadwaj Yadavalli In-Reply-To: <5111D374.2090101@oracle.com> References: <5074D97C.2000604@oracle.com> <5111D374.2090101@oracle.com> Message-ID: <511296A8.1080404@oracle.com> vote: yes -- Alejandro From John.Coomes at oracle.com Wed Feb 6 10:09:48 2013 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 6 Feb 2013 10:09:48 -0800 Subject: CFV: New hsx Committer: Volker Simonis Message-ID: <20754.40044.626432.879954@oracle.com> I hereby nominate Volker Simonis to hsx Committer. Volker is an engineer at SAP directly involved in developing and porting HotSpot to the many platforms that they support and is also the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has contributed 10 HotSpot changesets [1]. Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. Only current hsx Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. For Lazy Consensus voting instructions, see [4]. John Coomes, hsx Project Lead [0] http://openjdk.java.net/projects/ppc-aix-port/ [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Volker+Simonis&iso=20130220T17 [3] http://openjdk.java.net/census/#hsx [4] http://openjdk.java.net/projects/#committer-vote From daniel.daugherty at oracle.com Wed Feb 6 10:16:21 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 06 Feb 2013 11:16:21 -0700 Subject: CFV: New hsx Committer: Volker Simonis In-Reply-To: <20754.40044.626432.879954@oracle.com> References: <20754.40044.626432.879954@oracle.com> Message-ID: <51129DF5.5000708@oracle.com> Vote: yes Dan On 2/6/13 11:09 AM, John Coomes wrote: > I hereby nominate Volker Simonis to hsx Committer. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed 10 HotSpot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote From mikael.gerdin at oracle.com Wed Feb 6 10:16:38 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 06 Feb 2013 19:16:38 +0100 Subject: Review request: JDK-8006753 fix failed for JDK-8002415 White box testing API for HotSpot In-Reply-To: <5112853E.4010404@oracle.com> References: <510FBECB.6050903@oracle.com> <5112853E.4010404@oracle.com> Message-ID: <51129E06.2020104@oracle.com> Vladimir, On 2013-02-06 17:30, Vladimir Kozlov wrote: > Mikael, > > I like that all WB functionality is moved to test directory. > > You missed Copyright header in all new files. Thanks for the reminder, I'm not used to creating new files :) > > Could you rename ClassFileDumper to ClassFileInstaller? It will be more > clear what it does. Done. Updated webrev at: http://cr.openjdk.java.net/~mgerdin/8006753/webrev.1/ /Mikael > > Thanks, > Vladimir > > On 2/4/13 5:59 AM, Mikael Gerdin wrote: >> Hi, >> >> Background: >> Even from the beginning of the WhiteBox testing API implementation the >> tests have not worked on builds promoted by release engineering due to >> the fact that the wb.jar file containing the Java classes was not >> imported by the JDK-level makefiles. >> On one level this was ok since we didn't want to ship the classes to end >> users and we worked around the complexity of somehow post-processing the >> RE bundles to remove them. >> >> The problem is that we aren't able to run the WhiteBox tests in >> promotion testing, or to verify fixes against earlier builds. >> >> Solution: >> The solution suggested here is to put the WhiteBox helper classes in the >> testlibrary directory under test/ and >> * tell jtreg to first compile the classes >> * run a special Java program to copy the classes to the test work >> directory >> * run the white box test with -Xbootclasspath/a:. to pick up the copied >> classes. >> >> The solution is kind-of hackish but I've been unable to come up with a >> better solution without performing complex surgery on jtreg. >> >> The changes to the make/ directory should basically revert the makefile >> changes that were added to support this API. >> >> Webrev: >> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.0/ >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006753 >> >> Note about renamed/moved files: >> I will try to make sure that the moved/renamed files will be tracked >> properly by mercurial, but I think that using patch files and MQ breaks >> this so I'll do this after the review is done. >> >> Thanks >> /Mikael From coleen.phillimore at oracle.com Wed Feb 6 10:21:07 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 06 Feb 2013 13:21:07 -0500 Subject: CFV: New hsx Committer: Volker Simonis In-Reply-To: <20754.40044.626432.879954@oracle.com> References: <20754.40044.626432.879954@oracle.com> Message-ID: <51129F13.1080002@oracle.com> Vote: yes On 2/6/2013 1:09 PM, John Coomes wrote: > I hereby nominate Volker Simonis to hsx Committer. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed 10 HotSpot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote From dmitry.samersoff at oracle.com Wed Feb 6 10:24:08 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 06 Feb 2013 22:24:08 +0400 Subject: CFV: New hsx Committer: Volker Simonis In-Reply-To: <20754.40044.626432.879954@oracle.com> References: <20754.40044.626432.879954@oracle.com> Message-ID: <51129FC8.7070105@oracle.com> Vote: yes On 2013-02-06 22:09, John Coomes wrote: > I hereby nominate Volker Simonis to hsx Committer. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed 10 HotSpot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From John.Coomes at oracle.com Wed Feb 6 10:27:16 2013 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 6 Feb 2013 10:27:16 -0800 Subject: CFV: New hotspot Group Member: Volker Simonis Message-ID: <20754.41092.522499.713645@oracle.com> I hereby nominate Volker Simonis to Membership in the hotspot Group. Volker is an engineer at SAP directly involved in developing and porting HotSpot to the many platforms that they support and is also the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has contributed a number of hotspot changesets [1]. Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. Only current Members of the hotspot Group [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [4]. John Coomes, hotspot Group Lead [0] http://openjdk.java.net/projects/ppc-aix-port/ [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Volker+Simonis&iso=20130220T17 [3] http://openjdk.java.net/census/#hotspot [4] http://openjdk.java.net/groups/#member-vote From john.r.rose at oracle.com Wed Feb 6 10:28:12 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 6 Feb 2013 10:28:12 -0800 Subject: CFV: New hsx Committer: Volker Simonis In-Reply-To: <20754.40044.626432.879954@oracle.com> References: <20754.40044.626432.879954@oracle.com> Message-ID: <96EA1333-C728-455A-8F7D-92D5DE41050A@oracle.com> Vote: yes -- John (on my iPhone) On Feb 6, 2013, at 10:09 AM, John Coomes wrote: > I hereby nominate Volker Simonis to hsx Committer. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed 10 HotSpot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote From daniel.daugherty at oracle.com Wed Feb 6 10:30:44 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 06 Feb 2013 11:30:44 -0700 Subject: CFV: New hotspot Group Member: Volker Simonis In-Reply-To: <20754.41092.522499.713645@oracle.com> References: <20754.41092.522499.713645@oracle.com> Message-ID: <5112A154.5030204@oracle.com> Vote: yes Dan On 2/6/13 11:27 AM, John Coomes wrote: > I hereby nominate Volker Simonis to Membership in the hotspot Group. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed a number of hotspot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current Members of the hotspot Group [3] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hotspot Group Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hotspot > [4] http://openjdk.java.net/groups/#member-vote From igor.ignatyev at oracle.com Wed Feb 6 10:36:07 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 06 Feb 2013 22:36:07 +0400 Subject: Review request: JDK-8006753 fix failed for JDK-8002415 White box testing API for HotSpot In-Reply-To: <51129E06.2020104@oracle.com> References: <510FBECB.6050903@oracle.com> <5112853E.4010404@oracle.com> <51129E06.2020104@oracle.com> Message-ID: <5112A297.8020202@oracle.com> Mikael, Looks like you have used version of sun.hotspot.WhiteBox which is different from the current version from the repository: 'test/testlibrary/whitebox/sun/hotspot/WhiteBox.java' (new file) contains NMT* methods, but they aren't in 'src/share/tools/whitebox/sun/hotspot/WhiteBox.java' (removed). Best regards, Igor Ignatyev On 02/06/2013 10:16 PM, Mikael Gerdin wrote: > Vladimir, > > On 2013-02-06 17:30, Vladimir Kozlov wrote: >> Mikael, >> >> I like that all WB functionality is moved to test directory. >> >> You missed Copyright header in all new files. > > Thanks for the reminder, I'm not used to creating new files :) > >> >> Could you rename ClassFileDumper to ClassFileInstaller? It will be more >> clear what it does. > > Done. Updated webrev at: > http://cr.openjdk.java.net/~mgerdin/8006753/webrev.1/ > > /Mikael > >> >> Thanks, >> Vladimir >> >> On 2/4/13 5:59 AM, Mikael Gerdin wrote: >>> Hi, >>> >>> Background: >>> Even from the beginning of the WhiteBox testing API implementation the >>> tests have not worked on builds promoted by release engineering due to >>> the fact that the wb.jar file containing the Java classes was not >>> imported by the JDK-level makefiles. >>> On one level this was ok since we didn't want to ship the classes to end >>> users and we worked around the complexity of somehow post-processing the >>> RE bundles to remove them. >>> >>> The problem is that we aren't able to run the WhiteBox tests in >>> promotion testing, or to verify fixes against earlier builds. >>> >>> Solution: >>> The solution suggested here is to put the WhiteBox helper classes in the >>> testlibrary directory under test/ and >>> * tell jtreg to first compile the classes >>> * run a special Java program to copy the classes to the test work >>> directory >>> * run the white box test with -Xbootclasspath/a:. to pick up the copied >>> classes. >>> >>> The solution is kind-of hackish but I've been unable to come up with a >>> better solution without performing complex surgery on jtreg. >>> >>> The changes to the make/ directory should basically revert the makefile >>> changes that were added to support this API. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.0/ >>> Bug: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006753 >>> >>> Note about renamed/moved files: >>> I will try to make sure that the moved/renamed files will be tracked >>> properly by mercurial, but I think that using patch files and MQ breaks >>> this so I'll do this after the review is done. >>> >>> Thanks >>> /Mikael From vladimir.kozlov at oracle.com Wed Feb 6 10:43:21 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Feb 2013 10:43:21 -0800 Subject: CFV: New hsx Committer: Volker Simonis In-Reply-To: <20754.40044.626432.879954@oracle.com> References: <20754.40044.626432.879954@oracle.com> Message-ID: <5112A449.9040901@oracle.com> Vote: yes On 2/6/13 10:09 AM, John Coomes wrote: > I hereby nominate Volker Simonis to hsx Committer. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed 10 HotSpot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote > From rasbold at google.com Wed Feb 6 10:44:23 2013 From: rasbold at google.com (Chuck Rasbold) Date: Wed, 6 Feb 2013 10:44:23 -0800 Subject: CFV: New hotspot Group Member: Volker Simonis In-Reply-To: <20754.41092.522499.713645@oracle.com> References: <20754.41092.522499.713645@oracle.com> Message-ID: Vote: yes On Wed, Feb 6, 2013 at 10:27 AM, John Coomes wrote: > I hereby nominate Volker Simonis to Membership in the hotspot Group. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed a number of hotspot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current Members of the hotspot Group [3] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hotspot Group Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] > http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hotspot > [4] http://openjdk.java.net/groups/#member-vote > From rasbold at google.com Wed Feb 6 10:45:33 2013 From: rasbold at google.com (Chuck Rasbold) Date: Wed, 6 Feb 2013 10:45:33 -0800 Subject: CFV: New hsx Committer: Volker Simonis In-Reply-To: <20754.40044.626432.879954@oracle.com> References: <20754.40044.626432.879954@oracle.com> Message-ID: Vote: yes On Wed, Feb 6, 2013 at 10:09 AM, John Coomes wrote: > I hereby nominate Volker Simonis to hsx Committer. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed 10 HotSpot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] > http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote > From mikael.gerdin at oracle.com Wed Feb 6 10:47:23 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 06 Feb 2013 19:47:23 +0100 Subject: Review request: JDK-8006753 fix failed for JDK-8002415 White box testing API for HotSpot In-Reply-To: <5112A297.8020202@oracle.com> References: <510FBECB.6050903@oracle.com> <5112853E.4010404@oracle.com> <51129E06.2020104@oracle.com> <5112A297.8020202@oracle.com> Message-ID: <5112A53B.90907@oracle.com> Igor, On 2013-02-06 19:36, Igor Ignatyev wrote: > Mikael, > > Looks like you have used version of sun.hotspot.WhiteBox which is > different from the current version from the repository: > 'test/testlibrary/whitebox/sun/hotspot/WhiteBox.java' (new file) > contains NMT* methods, but they aren't in > 'src/share/tools/whitebox/sun/hotspot/WhiteBox.java' (removed). You are correct. I haven't merged my changes with Christian's NMT stuff yet. I was actually planning on waiting for his changes and your changes to go in before merging them and pushing this. At this stage I was interested in getting people's opinions on the suggested solution. Sorry for not being clear about this earlier. /Mikael > > Best regards, > Igor Ignatyev > > On 02/06/2013 10:16 PM, Mikael Gerdin wrote: >> Vladimir, >> >> On 2013-02-06 17:30, Vladimir Kozlov wrote: >>> Mikael, >>> >>> I like that all WB functionality is moved to test directory. >>> >>> You missed Copyright header in all new files. >> >> Thanks for the reminder, I'm not used to creating new files :) >> >>> >>> Could you rename ClassFileDumper to ClassFileInstaller? It will be more >>> clear what it does. >> >> Done. Updated webrev at: >> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.1/ >> >> /Mikael >> >>> >>> Thanks, >>> Vladimir >>> >>> On 2/4/13 5:59 AM, Mikael Gerdin wrote: >>>> Hi, >>>> >>>> Background: >>>> Even from the beginning of the WhiteBox testing API implementation the >>>> tests have not worked on builds promoted by release engineering due to >>>> the fact that the wb.jar file containing the Java classes was not >>>> imported by the JDK-level makefiles. >>>> On one level this was ok since we didn't want to ship the classes to >>>> end >>>> users and we worked around the complexity of somehow post-processing >>>> the >>>> RE bundles to remove them. >>>> >>>> The problem is that we aren't able to run the WhiteBox tests in >>>> promotion testing, or to verify fixes against earlier builds. >>>> >>>> Solution: >>>> The solution suggested here is to put the WhiteBox helper classes in >>>> the >>>> testlibrary directory under test/ and >>>> * tell jtreg to first compile the classes >>>> * run a special Java program to copy the classes to the test work >>>> directory >>>> * run the white box test with -Xbootclasspath/a:. to pick up the copied >>>> classes. >>>> >>>> The solution is kind-of hackish but I've been unable to come up with a >>>> better solution without performing complex surgery on jtreg. >>>> >>>> The changes to the make/ directory should basically revert the makefile >>>> changes that were added to support this API. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.0/ >>>> Bug: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006753 >>>> >>>> Note about renamed/moved files: >>>> I will try to make sure that the moved/renamed files will be tracked >>>> properly by mercurial, but I think that using patch files and MQ breaks >>>> this so I'll do this after the review is done. >>>> >>>> Thanks >>>> /Mikael From karen.kinnear at oracle.com Wed Feb 6 10:53:46 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 6 Feb 2013 13:53:46 -0500 Subject: CFV: New hotspot Group Member: Volker Simonis In-Reply-To: <20754.41092.522499.713645@oracle.com> References: <20754.41092.522499.713645@oracle.com> Message-ID: Vote: yes On Feb 6, 2013, at 1:27 PM, John Coomes wrote: > I hereby nominate Volker Simonis to Membership in the hotspot Group. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed a number of hotspot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current Members of the hotspot Group [3] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hotspot Group Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hotspot > [4] http://openjdk.java.net/groups/#member-vote From vladimir.kozlov at oracle.com Wed Feb 6 10:55:59 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Feb 2013 10:55:59 -0800 Subject: Review request: JDK-8006753 fix failed for JDK-8002415 White box testing API for HotSpot In-Reply-To: <51129E06.2020104@oracle.com> References: <510FBECB.6050903@oracle.com> <5112853E.4010404@oracle.com> <51129E06.2020104@oracle.com> Message-ID: <5112A73F.5010105@oracle.com> On 2/6/13 10:16 AM, Mikael Gerdin wrote: > Vladimir, > > On 2013-02-06 17:30, Vladimir Kozlov wrote: >> Mikael, >> >> I like that all WB functionality is moved to test directory. >> >> You missed Copyright header in all new files. > > Thanks for the reminder, I'm not used to creating new files :) I still don't see it in DiagnosticCommand.java. Also old files WBApi.java and ParserTest.java do not have it. Mikael, we need Copyright header in all files we push into open sources. Thanks, Vladimir > >> >> Could you rename ClassFileDumper to ClassFileInstaller? It will be more >> clear what it does. > > Done. Updated webrev at: > http://cr.openjdk.java.net/~mgerdin/8006753/webrev.1/ > > /Mikael > >> >> Thanks, >> Vladimir >> >> On 2/4/13 5:59 AM, Mikael Gerdin wrote: >>> Hi, >>> >>> Background: >>> Even from the beginning of the WhiteBox testing API implementation the >>> tests have not worked on builds promoted by release engineering due to >>> the fact that the wb.jar file containing the Java classes was not >>> imported by the JDK-level makefiles. >>> On one level this was ok since we didn't want to ship the classes to end >>> users and we worked around the complexity of somehow post-processing the >>> RE bundles to remove them. >>> >>> The problem is that we aren't able to run the WhiteBox tests in >>> promotion testing, or to verify fixes against earlier builds. >>> >>> Solution: >>> The solution suggested here is to put the WhiteBox helper classes in the >>> testlibrary directory under test/ and >>> * tell jtreg to first compile the classes >>> * run a special Java program to copy the classes to the test work >>> directory >>> * run the white box test with -Xbootclasspath/a:. to pick up the copied >>> classes. >>> >>> The solution is kind-of hackish but I've been unable to come up with a >>> better solution without performing complex surgery on jtreg. >>> >>> The changes to the make/ directory should basically revert the makefile >>> changes that were added to support this API. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.0/ >>> Bug: >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006753 >>> >>> Note about renamed/moved files: >>> I will try to make sure that the moved/renamed files will be tracked >>> properly by mercurial, but I think that using patch files and MQ breaks >>> this so I'll do this after the review is done. >>> >>> Thanks >>> /Mikael From vladimir.kozlov at oracle.com Wed Feb 6 10:59:04 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Feb 2013 10:59:04 -0800 Subject: CFV: New hotspot Group Member: Volker Simonis In-Reply-To: <20754.41092.522499.713645@oracle.com> References: <20754.41092.522499.713645@oracle.com> Message-ID: <5112A7F8.8020500@oracle.com> Vote: yes On 2/6/13 10:27 AM, John Coomes wrote: > I hereby nominate Volker Simonis to Membership in the hotspot Group. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed a number of hotspot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current Members of the hotspot Group [3] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hotspot Group Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hotspot > [4] http://openjdk.java.net/groups/#member-vote > From zhengyu.gu at oracle.com Wed Feb 6 11:04:23 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 06 Feb 2013 14:04:23 -0500 Subject: CFV: New hsx Committer: Volker Simonis In-Reply-To: <20754.40044.626432.879954@oracle.com> References: <20754.40044.626432.879954@oracle.com> Message-ID: <5112A937.8060100@oracle.com> Vote: yes -Zhengyu On 2/6/2013 1:09 PM, John Coomes wrote: > I hereby nominate Volker Simonis to hsx Committer. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed 10 HotSpot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote From John.Coomes at oracle.com Wed Feb 6 11:14:18 2013 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 6 Feb 2013 11:14:18 -0800 Subject: CFV: New HSX Committer: Bharadwaj Yadavalli In-Reply-To: <5111D374.2090101@oracle.com> References: <5074D97C.2000604@oracle.com> <5111D374.2090101@oracle.com> Message-ID: <20754.43914.406292.262418@oracle.com> Vote: yes -John From John.Coomes at oracle.com Wed Feb 6 11:15:01 2013 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 6 Feb 2013 11:15:01 -0800 Subject: CFV: New hsx Committer: Volker Simonis In-Reply-To: <20754.40044.626432.879954@oracle.com> References: <20754.40044.626432.879954@oracle.com> Message-ID: <20754.43957.597658.463020@oracle.com> Vote: yes -John From John.Coomes at oracle.com Wed Feb 6 11:15:50 2013 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 6 Feb 2013 11:15:50 -0800 Subject: CFV: New hotspot Group Member: Volker Simonis In-Reply-To: <20754.41092.522499.713645@oracle.com> References: <20754.41092.522499.713645@oracle.com> Message-ID: <20754.44006.753794.721058@oracle.com> Vote: yes -John From harold.seigel at oracle.com Wed Feb 6 11:14:48 2013 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Wed, 06 Feb 2013 19:14:48 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130206191457.10C0647895@hg.openjdk.java.net> Changeset: 02b3e25dcc6b Author: hseigel Date: 2013-02-06 08:26 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/02b3e25dcc6b 8006298: Specifying malformed options outputs non-sensical error Summary: Change error messages for malformed options so the messages are more useful. Reviewed-by: mikael, kvn, nloodin, coleenp ! src/share/vm/runtime/arguments.cpp Changeset: 87cf402c32e4 Author: hseigel Date: 2013-02-06 08:41 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/87cf402c32e4 Merge Changeset: 62e7d37fe255 Author: hseigel Date: 2013-02-06 10:27 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/62e7d37fe255 Merge From ChrisPhi at LGonQn.Org Wed Feb 6 11:55:23 2013 From: ChrisPhi at LGonQn.Org (Chris Phillips @ T O) Date: Wed, 06 Feb 2013 14:55:23 -0500 Subject: CFV: New hotspot Group Member: Volker Simonis In-Reply-To: <20754.41092.522499.713645@oracle.com> References: <20754.41092.522499.713645@oracle.com> Message-ID: <5112B52B.30108@LGonQn.Org> Vote: yes Chris On 06/02/13 01:27 PM, John Coomes wrote: > I hereby nominate Volker Simonis to Membership in the hotspot Group. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed a number of hotspot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current Members of the hotspot Group [3] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hotspot Group Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hotspot > [4] http://openjdk.java.net/groups/#member-vote > > From coleen.phillimore at oracle.com Wed Feb 6 12:11:09 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 06 Feb 2013 15:11:09 -0500 Subject: CFV: New hotspot Group Member: Volker Simonis In-Reply-To: <20754.41092.522499.713645@oracle.com> References: <20754.41092.522499.713645@oracle.com> Message-ID: <5112B8DD.7020800@oracle.com> Vote: yes On 2/6/2013 1:27 PM, John Coomes wrote: > I hereby nominate Volker Simonis to Membership in the hotspot Group. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed a number of hotspot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current Members of the hotspot Group [3] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hotspot Group Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hotspot > [4] http://openjdk.java.net/groups/#member-vote From vladimir.x.ivanov at oracle.com Wed Feb 6 14:17:25 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 07 Feb 2013 01:17:25 +0300 Subject: CFV: New hsx Committer: Volker Simonis In-Reply-To: <20754.40044.626432.879954@oracle.com> References: <20754.40044.626432.879954@oracle.com> Message-ID: <5112D675.6000609@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 2/6/13 9:09 PM, John Coomes wrote: > I hereby nominate Volker Simonis to hsx Committer. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed 10 HotSpot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote > From christian.tornqvist at oracle.com Wed Feb 6 14:32:31 2013 From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com) Date: Wed, 06 Feb 2013 22:32:31 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130206223238.6D2F0478A0@hg.openjdk.java.net> Changeset: 2ee1591f14d0 Author: ctornqvi Date: 2013-02-06 16:27 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2ee1591f14d0 8000363: runtime/7158988/FieldMonitor.java fails with exception Summary: Removed unnecessary shell script in the test. Reviewed-by: coleenp, sla ! test/runtime/7158988/FieldMonitor.java - test/runtime/7158988/TestFieldMonitor.sh Changeset: 073e56606b4d Author: ctornqvi Date: 2013-02-06 11:20 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/073e56606b4d Merge - test/runtime/7158988/TestFieldMonitor.sh From david.holmes at oracle.com Wed Feb 6 15:43:28 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 07 Feb 2013 09:43:28 +1000 Subject: RFR (XXS) CR 8006997: ContendedPaddingWidth should be uintx In-Reply-To: <51128906.3000302@oracle.com> References: <510668D1.5070002@oracle.com> <51109FF5.6020804@oracle.com> <51125B90.6030404@oracle.com> <51128906.3000302@oracle.com> Message-ID: <5112EAA0.5050303@oracle.com> On 7/02/2013 2:47 AM, Vladimir Kozlov wrote: > On 2/6/13 5:33 AM, Aleksey Shipilev wrote: >> Hi David, >> >> On 02/05/2013 10:00 AM, David Holmes wrote: >>> You also need to change all the expressions using this value to use >>> unsigned types and update all the printfs to use an unsigned format >>> specifier. >> >> Ah, yes, thanks! >> >>> > grepsrc.sh ContendedPaddingWidth >>> ./cpu/sparc/vm/vm_version_sparc.cpp: (cache_line_size > >>> ContendedPaddingWidth)) >> >> cache_line_size is signed (although semantically fits into unsigned) >> What's the usual convention around HotSpot to handle signed/unsigned >> comparisons like these? Use static_cast? >> >> if (static_cast(cache_line_size) > ContededPaddingWidth) This is rarely ever used in hotspot. If you see one it is from someone relatively new to hotspot :) >> >> Use the ordinary cast: >> >> if ((unsigned int)cache_line_size) > ContededPaddingWidth) >> >> ...or even push forward changing all the cache_line_size family to >> unsigned? >> >> Grepping the code, ordinary cast seems to be used the most. I can do >> either of three. Thoughts? > > Ordinary cast is fine, and you can change cache_line_size type if you > want (it is used only in few places). One note, we have internal type > 'uint' defined for such cases. Grepping for cache_line_size I see a number of different uses and a mix of signed and unsigned definitions for it. But changing to uint would have a flow on affect to prefetch_data_size() which is signed too. I have to wonder whether leaving ContendedPaddingWidth as signed is not the simplest thing to do as it may be impractical, if not impossible, to get uniformity of the signed-ness of expressions across all platforms. David ----- > > Thanks, > Vladimir > >> >> -Aleksey. >> From david.holmes at oracle.com Wed Feb 6 15:56:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 07 Feb 2013 09:56:32 +1000 Subject: Review request: 8006878 Some non-existent GC source files are in the minimalVM exclude list In-Reply-To: <5112677C.1000005@oracle.com> References: <5102B299.5020605@oracle.com> <510A2A95.5030209@oracle.com> <5112677C.1000005@oracle.com> Message-ID: <5112EDB0.5070607@oracle.com> On 7/02/2013 12:23 AM, Joe Provino wrote: > On 1/31/2013 3:25 AM, David Holmes wrote: >> >> On 26/01/2013 2:28 AM, Joe Provino wrote: >>> 2 ffiles changed. >>> >>> Webrev is here: http://cr.openjdk.java.net/~jprovino/8006878/webrev.00 >> >> This seems to mix fixes for two different issues. The removal of the >> INCLUDE_ALL_GC guard would seem to indicate there is a problem if not >> building all GCs ie with the minimal VM - is that the case? > > David, sorry, I don't know how I'm managing to miss responses. > > I think the problem in excludeSrc.make excluding the non-existent file > "yieldWorkingGroup.cpp" > instead of the correct file "yieldingWorkGroup.cpp" meant that > yieldingWorkGroup.cpp > wasn't being excluded and didn't compile so I put in the guard to fix it. > > However, that being said, I tried not removing yieldingWorkGroup.cpp > when INCLUDE_ALL_GCS is 0 and it compiled. So if there was a problem it > doesn't appear to be a problem any more. Thanks Joe. Thumbs up! I had missed the fact that one of the changes was an error in the file name. Once it is properly excluded we certainly don't need the additional guard inside it, so that is fine. (Aside: did you try your experiment with precompiled headers disabled?) I wonder if we could add a validation check for those filelists? Probably tricky without the paths. Future work anyway not needed for this CR. David > > joe >> >> David >> >>> joe From david.holmes at oracle.com Wed Feb 6 15:58:17 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 07 Feb 2013 09:58:17 +1000 Subject: Request for review: JDK-8003581, , UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS In-Reply-To: <5112699E.2010400@oracle.com> References: <511125C8.4030405@oracle.com> <51113D65.1030600@oracle.com> <5111C2E0.1050602@oracle.com> <5112699E.2010400@oracle.com> Message-ID: <5112EE19.7000200@oracle.com> On 7/02/2013 12:33 AM, Joe Provino wrote: > New webrev is here: http://cr.openjdk.java.net/~jprovino/8003581/webrev.03 Looks good. Thanks, David > thanks! > > joe > > On 2/5/2013 9:41 PM, David Holmes wrote: >> On 6/02/2013 3:12 AM, Joe Provino wrote: >>> Here's the latest webrev after Chris and David's comments: >>> >>> http://cr.openjdk.java.net/~jprovino/8003581/webrev.02/ >> >> Almost there - this: >> >> ! #if INCLUDE_ALL_GCS >> ! #if (defined JAVASE_EMBEDDED || defined ARM) >> ! UNSUPPORTED_GC_OPTION(UseG1GC); >> ! #endif >> ! #endif >> >> should use: >> >> UNSUPPORTED_OPTION(UseG1GC, "G1 GC"); >> >> David >> >>> joe >>> >>> On 2/5/2013 10:31 AM, Chris Plummer wrote: >>>> Hi Joe, >>>> >>>> David and I made quite a few comments over the past few days. Did you >>>> not see them? I believe the conclusion is that this is what you need: >>>> >>>> #if INCLUDE_ALL_GCS >>>> #if (defined JAVASE_EMBEDDED || defined ARM) >>>> UNSUPPORTED_OPTION(UseG1GC, "G1 GC"); >>>> #endif >>>> #endif >>>> >>>> #if !INCLUDE_ALL_GCS >>>> UNSUPPORTED_GC_OPTION(UseG1GC); >>>> UNSUPPORTED_GC_OPTION(UseParallelGC); >>>> UNSUPPORTED_GC_OPTION(UseParallelOldGC); >>>> UNSUPPORTED_GC_OPTION(UseConcMarkSweepGC); >>>> UNSUPPORTED_GC_OPTION(UseParNewGC); >>>> #endif // INCLUDE_ALL_GCS >>>> >>>> David also suggested that the 2nd part above be moved to >>>> force_serial_gc(). >>>> >>>> Chris >>>> >>>> On 2/5/13 6:22 AM, Joe Provino wrote: >>>>> Would anyone have time to review this updated change. It's one file -- >>>>> arguments.cpp. >>>>> >>>>> thanks. >>>>> >>>>> joe >>>>> >>>>> On 1/25/2013 11:25 AM, Joe Provino wrote: >>>>>> > With changes from Bob and David, here is a new webrev: >>>>>> > >>>>>> > http://cr.openjdk.java.net/~jprovino/8003581/webrev.01 >>>>>> > >>>>>> > joe >>>>>> > >>>>>> > On 1/25/2013 12:44 AM, David Holmes wrote: >>>>>>> >> On 25/01/2013 4:45 AM, Bob Vandette wrote: >>>>>>>> >>> You claim to be defaulting to SerialGC but you don't set >>>>>>>> UseG1GC to >>>>>>>> >>> false? >>>>>>> >> >>>>>>> >> The UNSUPPORTED_OPTION macro does that. >>>>>>> >> >>>>>>> >> But I don't see anything forcing use of serialGC. And >>>>>>> >> force_serial_gc() should not be altered. >>>>>>> >> >>>>>>>> >>> If you build with INCLUDE_ALL_GCS=1, the G1 code will be >>>>>>>> available >>>>>>>> >>> and be used. >>>>>>> >> >>>>>>> >> Only on those platforms that support it. >>>>>>> >> >>>>>>> >> David >>>>>>> >> >>>>>>>> >>> Bob. >>>>>>>> >>> >>>>>>>> >>> On Jan 24, 2013, at 1:38 PM, Joe Provino wrote: >>>>>>>> >>> >>>>>>>>> >>>> Webrev is here: >>>>>>>>> >>>> http://cr.openjdk.java.net/~jprovino/8003581/webrev.00 >>>>>>>>> >>>> >>>>>>>>> >>>> It's a change to one file: arguments.cpp. >>>>>>>>> >>>> >>>>>>>>> >>>> thanks. >>>>>>>>> >>>> >>>>>>>>> >>>> joe >>>>>>>> >>> >>>> From david.holmes at oracle.com Wed Feb 6 16:04:23 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 07 Feb 2013 10:04:23 +1000 Subject: CFV: New hsx Committer: Volker Simonis In-Reply-To: <20754.40044.626432.879954@oracle.com> References: <20754.40044.626432.879954@oracle.com> Message-ID: <5112EF87.3040002@oracle.com> Vote: yes David On 7/02/2013 4:09 AM, John Coomes wrote: > I hereby nominate Volker Simonis to hsx Committer. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed 10 HotSpot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote From joseph.provino at oracle.com Wed Feb 6 16:06:37 2013 From: joseph.provino at oracle.com (Joseph Provino) Date: Wed, 06 Feb 2013 19:06:37 -0500 Subject: Review request: 8006878 Some non-existent GC source files are in the minimalVM exclude list In-Reply-To: <5112EDB0.5070607@oracle.com> References: <5102B299.5020605@oracle.com> <510A2A95.5030209@oracle.com> <5112677C.1000005@oracle.com> <5112EDB0.5070607@oracle.com> Message-ID: <5112F00D.50803@oracle.com> On 02/06/2013 06:56 PM, David Holmes wrote: > On 7/02/2013 12:23 AM, Joe Provino wrote: >> On 1/31/2013 3:25 AM, David Holmes wrote: >>> >>> On 26/01/2013 2:28 AM, Joe Provino wrote: >>>> 2 ffiles changed. >>>> >>>> Webrev is here: http://cr.openjdk.java.net/~jprovino/8006878/webrev.00 >>> >>> This seems to mix fixes for two different issues. The removal of the >>> INCLUDE_ALL_GC guard would seem to indicate there is a problem if not >>> building all GCs ie with the minimal VM - is that the case? >> >> David, sorry, I don't know how I'm managing to miss responses. >> >> I think the problem in excludeSrc.make excluding the non-existent file >> "yieldWorkingGroup.cpp" >> instead of the correct file "yieldingWorkGroup.cpp" meant that >> yieldingWorkGroup.cpp >> wasn't being excluded and didn't compile so I put in the guard to fix >> it. >> >> However, that being said, I tried not removing yieldingWorkGroup.cpp >> when INCLUDE_ALL_GCS is 0 and it compiled. So if there was a problem it >> doesn't appear to be a problem any more. > > Thanks Joe. Thumbs up! I had missed the fact that one of the changes > was an error in the file name. Once it is properly excluded we > certainly don't need the additional guard inside it, so that is fine. > (Aside: did you try your experiment with precompiled headers disabled?) I didn't. That might have been the problem. It might have failed with JPRT on a Solaris build which doesn't use precompiled headers. joe > > I wonder if we could add a validation check for those filelists? > Probably tricky without the paths. Future work anyway not needed for > this CR. > > David > > > >> >> joe >>> >>> David >>> >>>> joe From david.holmes at oracle.com Wed Feb 6 16:06:47 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 07 Feb 2013 10:06:47 +1000 Subject: How to commit ? ( was Re: CFV: New hsx Committer: Volker Simonis) In-Reply-To: <20754.40044.626432.879954@oracle.com> References: <20754.40044.626432.879954@oracle.com> Message-ID: <5112F017.50008@oracle.com> I've already voted for Volker to become a Committer. But without external access to JPRT he can't actually commit anything. :( David On 7/02/2013 4:09 AM, John Coomes wrote: > I hereby nominate Volker Simonis to hsx Committer. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed 10 HotSpot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote From david.holmes at oracle.com Wed Feb 6 16:08:10 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 07 Feb 2013 10:08:10 +1000 Subject: CFV: New hotspot Group Member: Volker Simonis In-Reply-To: <20754.41092.522499.713645@oracle.com> References: <20754.41092.522499.713645@oracle.com> Message-ID: <5112F06A.50102@oracle.com> Vote: yes David On 7/02/2013 4:27 AM, John Coomes wrote: > I hereby nominate Volker Simonis to Membership in the hotspot Group. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed a number of hotspot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current Members of the hotspot Group [3] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hotspot Group Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hotspot > [4] http://openjdk.java.net/groups/#member-vote From alejandro.murillo at oracle.com Wed Feb 6 16:54:28 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 06 Feb 2013 17:54:28 -0700 Subject: CFV: New hsx Committer: Volker Simonis In-Reply-To: <20754.40044.626432.879954@oracle.com> References: <20754.40044.626432.879954@oracle.com> Message-ID: <5112FB44.6030903@oracle.com> vote: yes -- Alejandro From alejandro.murillo at oracle.com Wed Feb 6 16:55:24 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 06 Feb 2013 17:55:24 -0700 Subject: CFV: New hotspot Group Member: Volker Simonis In-Reply-To: <20754.41092.522499.713645@oracle.com> References: <20754.41092.522499.713645@oracle.com> Message-ID: <5112FB7C.4050301@oracle.com> vote: yes -- Alejandro From joseph.provino at oracle.com Wed Feb 6 17:04:56 2013 From: joseph.provino at oracle.com (Joseph Provino) Date: Wed, 06 Feb 2013 20:04:56 -0500 Subject: Review request: 7118588 Profiled JVM needs to be linked statically for gprof to profile libjvm.so In-Reply-To: <51113051.9050806@oracle.com> References: <5102B3EC.80305@oracle.com> <51038C5F.8060902@oracle.com> <5105397E.5030203@oracle.com> <5111162A.5020104@oracle.com> <51113051.9050806@oracle.com> Message-ID: <5112FDB8.9000709@oracle.com> Does anyone else have a minute to review this? thanks. joe On 02/05/2013 11:16 AM, Mikael Gerdin wrote: > Joe, > > On 2013-02-05 15:24, Joe Provino wrote: >> Would anyone have time to review this after reading the discussion >> below? >> >> Webrev is here: http://cr.openjdk.java.net/~jprovino/7118588/webrev.00 > > Looks good to me. I remember writing exactly this patch when I wanted > to run with gprof a while back and ran into the same problem. > > /Mikael > >> >> thanks. >> >> joe >> >> >> On 1/27/2013 9:28 AM, Joe Provino wrote: >>> >>> >>> On 1/26/2013 2:57 AM, David Holmes wrote: >>>> On 26/01/2013 2:33 AM, Joe Provino wrote: >>>>> Webrev is here: >>>>> http://cr.openjdk.java.net/~jprovino/7118588/webrev.00 >>>> >>>> The bug synopsis is confusing - seems to me it is the launcher your >>>> are changing not the VM. >>> >>> I agree. A better synopsis would be "Unable to link gamma launcher >>> statically with the VM object files." >>> >>>> Do we have gprof on Solaris? Does this change fix or break other >>>> profiling tools ? >>> >>> I think these are actually unrelated to the problem once the problem >>> is stated correctly. >>> >>>> I don't grok the actual changes >>> >>> The problem is that if you attempt to build the gamma launcher >>> statically with the VM object files >>> by setting LINK_INTO=AOUT on the make command line, the launcher will >>> get undefined symbols. >>> >>> The handling of LINK_INTO in launcher.make is incorrect. >>> >>> ifeq ($(LINK_INTO),AOUT) >>> LAUNCHER.o = launcher.o $(JVM_OBJ_FILES) >>> LIBS_LAUNCHER += $(STATIC_STDCXX) $(LIBS) >>> else >>> LAUNCHER.o = launcher.o >>> LIBS_LAUNCHER += -l$(JVM) $(LIBS) >>> endif >>> >>> launcher.o is undefined. That isn't a problem in itself because >>> LAUNCHER.o is never used. >>> >>> This is the line that links the launcher: >>> >>> $(LINK_LAUNCHER) $(LFLAGS_LAUNCHER) -o $@ $(sort $(OBJS)) >>> $(LIBS_LAUNCHER) >>> >>> The simple fix is to add $(LAUNCHER.o): >>> >>> $(LINK_LAUNCHER) $(LFLAGS_LAUNCHER) -o $@ $(sort $(OBJS)) >>> $(LAUNCHER.o) $(LIBS_LAUNCHER) >>> >>> I also got rid of launcher.o since it's not used. >>> >>> I think to clean this up, I'd define LAUNCHER.o to be the launcher >>> object files plus the JVM object files >>> if LINK_INTO is AOUT and the launcher object files plus -ljvm >>> otherwise. Then to link the launcher, >>> I'd use $(LAUNCHER.o) $(LIBS). >>> >>> Should I do something like this or just the minimal fix? >>> >>> joe >>> >>> >>>> but there is a typo in the bsd file: >>>> >>>> + # profiledminimal1 minimal1 __shark/profiled >>>> >>>> shark? :) >>> >>> fixed. >>> >>>> >>>> David >>>> >>>>> >>>>> joe > From krystal.mo at oracle.com Wed Feb 6 17:29:10 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Thu, 07 Feb 2013 09:29:10 +0800 Subject: CFV: New hsx Committer: Volker Simonis In-Reply-To: <20754.40044.626432.879954@oracle.com> References: <20754.40044.626432.879954@oracle.com> Message-ID: <51130366.6060705@oracle.com> Vote: yes - Kris On 02/07/2013 02:09 AM, John Coomes wrote: > I hereby nominate Volker Simonis to hsx Committer. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed 10 HotSpot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote From lists at intricatesoftware.com Wed Feb 6 18:16:08 2013 From: lists at intricatesoftware.com (Kurt Miller) Date: Wed, 6 Feb 2013 21:16:08 -0500 Subject: OpenJDK6 20.0-b12 intermittent crash In-Reply-To: <201302021230.54300.lists@intricatesoftware.com> References: <201302021230.54300.lists@intricatesoftware.com> Message-ID: <201302062116.09569.lists@intricatesoftware.com> On Saturday 02 February 2013 12:30:53 pm Kurt Miller wrote: > Hi, > > I recently finished porting OpenJDK6 to OpenBSD. For the most part everything is working well, however on x86-32 using the client vm I am experiencing an intermittent crash when using OpenJDK6 to bootstrap the OpenJDK7 build. I have rebuilt OpenJDK6 using the fastdebug target and reproduced the problem. I don't know the internals of hotstop well enough to find the root cause. Could someone take a look at the following crash report and provide some feedback. In particular I'd like to know if this crash is related to os specific porting issues or a general hotspot problem. If os specific what areas should I focus my attention on. I also have the core file for this crash and can provide additional information from the core upon request. Further investigation into this problem revealed the segfaults were due to protection faults from trying to execute a non-executable page. OpenBSD uses the code segment on i386 to split the vm space into executable and non-executable areas. Looking at the kernels handling of the protection fault closely revealed a case where the code segment was set to a value that was unexpected. This lead to the kernel passing the execution protection fault through to userland when it shouldn't have. Regards, -Kurt From aleksey.shipilev at oracle.com Wed Feb 6 23:52:40 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 07 Feb 2013 11:52:40 +0400 Subject: RFR (XXS) CR 8006997: ContendedPaddingWidth should be uintx In-Reply-To: <5112EAA0.5050303@oracle.com> References: <510668D1.5070002@oracle.com> <51109FF5.6020804@oracle.com> <51125B90.6030404@oracle.com> <51128906.3000302@oracle.com> <5112EAA0.5050303@oracle.com> Message-ID: <51135D48.9040002@oracle.com> On 02/07/2013 03:43 AM, David Holmes wrote: > I have to wonder whether leaving ContendedPaddingWidth as signed is not > the simplest thing to do as it may be impractical, if not impossible, to > get uniformity of the signed-ness of expressions across all platforms. Well, Vladimir I. suggested we booby-trap against negative values with guarantee(...). Will that be sufficient? -Aleksey. From volker.simonis at gmail.com Thu Feb 7 00:35:47 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 Feb 2013 09:35:47 +0100 Subject: How to commit ? ( was Re: CFV: New hsx Committer: Volker Simonis) In-Reply-To: <5112F017.50008@oracle.com> References: <20754.40044.626432.879954@oracle.com> <5112F017.50008@oracle.com> Message-ID: Sadly, that's true. But at least it is a first (simple) step which may help to solve the "Chicken or the egg" problem of not not having external committers because they can not commit anyway on the one side and not providing the infrastructure for external committs because there aren?t any external committers :) On Thu, Feb 7, 2013 at 1:06 AM, David Holmes wrote: > I've already voted for Volker to become a Committer. But without external > access to JPRT he can't actually commit anything. :( > > David > > On 7/02/2013 4:09 AM, John Coomes wrote: >> >> I hereby nominate Volker Simonis to hsx Committer. >> >> Volker is an engineer at SAP directly involved in developing and >> porting HotSpot to the many platforms that they support and is also >> the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has >> contributed 10 HotSpot changesets [1]. >> >> Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. >> >> Only current hsx Committers [3] are eligible to vote on this >> nomination. Votes must be cast in the open by replying to to this >> mailing list. >> >> For Lazy Consensus voting instructions, see [4]. >> >> John Coomes, hsx Project Lead >> >> [0] http://openjdk.java.net/projects/ppc-aix-port/ >> [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis >> [2] >> http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Volker+Simonis&iso=20130220T17 >> [3] http://openjdk.java.net/census/#hsx >> [4] http://openjdk.java.net/projects/#committer-vote From david.holmes at oracle.com Thu Feb 7 00:55:30 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 07 Feb 2013 18:55:30 +1000 Subject: RFR (XXS) CR 8006997: ContendedPaddingWidth should be uintx In-Reply-To: <51135D48.9040002@oracle.com> References: <510668D1.5070002@oracle.com> <51109FF5.6020804@oracle.com> <51125B90.6030404@oracle.com> <51128906.3000302@oracle.com> <5112EAA0.5050303@oracle.com> <51135D48.9040002@oracle.com> Message-ID: <51136C02.3080700@oracle.com> On 7/02/2013 5:52 PM, Aleksey Shipilev wrote: > On 02/07/2013 03:43 AM, David Holmes wrote: >> I have to wonder whether leaving ContendedPaddingWidth as signed is not >> the simplest thing to do as it may be impractical, if not impossible, to >> get uniformity of the signed-ness of expressions across all platforms. > > Well, Vladimir I. suggested we booby-trap against negative values with > guarantee(...). Will that be sufficient? Sure - a number of flags get range checked. David > -Aleksey. > From staffan.larsen at oracle.com Thu Feb 7 01:27:50 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 7 Feb 2013 10:27:50 +0100 Subject: CFV: New hsx Committer: Volker Simonis In-Reply-To: <20754.40044.626432.879954@oracle.com> References: <20754.40044.626432.879954@oracle.com> Message-ID: <300AE3A1-AF2F-41B1-8DCF-3486CE3328BD@oracle.com> Vote: yes On 6 feb 2013, at 19:09, John Coomes wrote: > I hereby nominate Volker Simonis to hsx Committer. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed 10 HotSpot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote From nils.loodin at oracle.com Thu Feb 7 02:48:07 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Thu, 7 Feb 2013 11:48:07 +0100 Subject: CFV: New HSX Committer: Serguei Spitsyn In-Reply-To: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> References: <4C67B3CB-4688-4E97-A10B-9759FF3AC69D@oracle.com> Message-ID: Vote: yes /Nils Loodin On Feb 4, 2013, at 19:25 , Staffan Larsen wrote: > I hereby nominate Serguei Spitsyn (OpenJDK user name: sspitsyn) to HSX Committer. > > Serguei is a member of the Hotspot Serviceability team. He has contributed 8 changesets to the HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/log?rev=serguei.spitsyn at oracle.com > > Votes are due by February 18, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Staffan > > [1]http://openjdk.java.net/projects/#project-committer > [2]http://openjdk.java.net/census#hsx > [3]http://openjdk.java.net/projects#committer-vote From bengt.rutisson at oracle.com Thu Feb 7 05:43:11 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 07 Feb 2013 14:43:11 +0100 Subject: CFV: New hsx Committer: Volker Simonis In-Reply-To: <20754.40044.626432.879954@oracle.com> References: <20754.40044.626432.879954@oracle.com> Message-ID: <5113AF6F.2020201@oracle.com> vote: yes On 2/6/13 7:09 PM, John Coomes wrote: > I hereby nominate Volker Simonis to hsx Committer. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed 10 HotSpot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote From staffan.larsen at oracle.com Thu Feb 7 07:09:53 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 07 Feb 2013 15:09:53 +0000 Subject: hg: hsx/hsx24/hotspot: 8007134: Enable tracing asserts on missing ResourceMark Message-ID: <20130207150956.10BA5478E0@hg.openjdk.java.net> Changeset: 6538f0c1bd05 Author: mgronlun Date: 2013-02-07 11:03 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6538f0c1bd05 8007134: Enable tracing asserts on missing ResourceMark Reviewed-by: dholmes, sla ! src/share/vm/trace/traceEventClasses.xsl From christian.thalinger at oracle.com Thu Feb 7 10:36:36 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 7 Feb 2013 10:36:36 -0800 Subject: CFV: New hsx Committer: Volker Simonis In-Reply-To: <20754.40044.626432.879954@oracle.com> References: <20754.40044.626432.879954@oracle.com> Message-ID: <70F1338C-4AE8-41AB-AAD3-5F7004D8D7BD@oracle.com> Vote: yes On Feb 6, 2013, at 10:09 AM, John Coomes wrote: > I hereby nominate Volker Simonis to hsx Committer. > > Volker is an engineer at SAP directly involved in developing and > porting HotSpot to the many platforms that they support and is also > the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > contributed 10 HotSpot changesets [1]. > > Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > > Only current hsx Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. > > John Coomes, hsx Project Lead > > [0] http://openjdk.java.net/projects/ppc-aix-port/ > [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > [2] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Volker+Simonis&iso=20130220T17 > [3] http://openjdk.java.net/census/#hsx > [4] http://openjdk.java.net/projects/#committer-vote From John.Coomes at oracle.com Thu Feb 7 10:42:46 2013 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 7 Feb 2013 10:42:46 -0800 Subject: How to commit ? ( was Re: CFV: New hsx Committer: Volker Simonis) In-Reply-To: References: <20754.40044.626432.879954@oracle.com> <5112F017.50008@oracle.com> Message-ID: <20755.62886.344296.54333@oracle.com> Volker Simonis (volker.simonis at gmail.com) wrote: > Sadly, that's true. But at least it is a first (simple) step which > may help to solve the "Chicken or the egg" problem of not not > having external committers because they can not commit anyway > on the one side and not providing the infrastructure for external > committs because there aren$,1ry(Bt any external committers :) I agree; there's no point in waiting. We don't have an open bug database either (yet), but still want bug fixes and enhancements from outside Oracle. -John > On Thu, Feb 7, 2013 at 1:06 AM, David Holmes wrote: > > I've already voted for Volker to become a Committer. But without external > > access to JPRT he can't actually commit anything. :( > > > > David > > > > On 7/02/2013 4:09 AM, John Coomes wrote: > >> > >> I hereby nominate Volker Simonis to hsx Committer. > >> > >> Volker is an engineer at SAP directly involved in developing and > >> porting HotSpot to the many platforms that they support and is also > >> the Project Lead of the OpenJDK ppc-aix-port Project [0]. He has > >> contributed 10 HotSpot changesets [1]. > >> > >> Votes are due by 5:00 PM Wednesday, February 20, 2013 UTC [2]. > >> > >> Only current hsx Committers [3] are eligible to vote on this > >> nomination. Votes must be cast in the open by replying to to this > >> mailing list. > >> > >> For Lazy Consensus voting instructions, see [4]. > >> > >> John Coomes, hsx Project Lead > >> > >> [0] http://openjdk.java.net/projects/ppc-aix-port/ > >> [1] http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/log?rev=simonis > >> [2] > >> http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hsx+Committer%3A+Volker+Simonis&iso=20130220T17 > >> [3] http://openjdk.java.net/census/#hsx > >> [4] http://openjdk.java.net/projects/#committer-vote From daniel.daugherty at oracle.com Thu Feb 7 11:20:17 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 07 Feb 2013 19:20:17 +0000 Subject: hg: hsx/hotspot-main/hotspot: 41 new changesets Message-ID: <20130207192141.58D63478E6@hg.openjdk.java.net> Changeset: 5daaddd917a1 Author: coleenp Date: 2013-01-23 10:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5daaddd917a1 8006040: NPG: on_stack processing wastes space in ConstantPool Summary: Added on_stack bit to flags. Also MetadataMarkOnStack is used for more than JVMTI so had to be moved. Reviewed-by: dholmes, stefank ! src/share/vm/classfile/classLoaderData.cpp + src/share/vm/classfile/metadataOnStackMark.cpp + src/share/vm/classfile/metadataOnStackMark.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp Changeset: 6cf2530f7fd3 Author: minqi Date: 2013-01-24 23:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6cf2530f7fd3 8005278: Serviceability Agent: jmap -heap and jstack -m fail Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary in vmStructs and in SA we still use old name for that. FreeList now is a template based class which is not reflect in SA type library. When SA does calculation of heap for CMS, the former will cause failure to retrieve BinaryTreeDictionary sine the rename. The later will fail wherever it is used in SA. Reviewed-by: dholmes, sla, coleenp Contributed-by: yunda.mly at taobao.com + agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Changeset: 8b46b0196eb0 Author: zgu Date: 2013-01-25 10:04 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8b46b0196eb0 8000692: Remove old KERNEL code Summary: Removed depreciated kernel VM source code from hotspot VM Reviewed-by: dholmes, acorn ! make/Makefile ! make/bsd/makefiles/dtrace.make ! make/solaris/Makefile ! make/solaris/makefiles/dtrace.make - make/solaris/makefiles/kernel.make ! make/windows/build.bat ! make/windows/create_obj_files.sh ! make/windows/makefiles/defs.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! src/cpu/x86/vm/assembler_x86.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jniCheck.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.hpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExtensions.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiRawMonitor.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/attachListener.hpp Changeset: edd76a5856f7 Author: sspitsyn Date: 2013-01-24 22:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/edd76a5856f7 8005128: JSR 292: the mlvm redefineClassInBootstrap test crashes in ConstantPool::compare_entry_to Summary: When constant pool is copied in merge_constant_pools the invokedynamic operands must be copied before. Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 4a0dd3799a44 Author: minqi Date: 2013-01-25 04:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4a0dd3799a44 Merge Changeset: 8d1fb417a42d Author: minqi Date: 2013-01-25 13:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8d1fb417a42d Merge ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: cf8470eaf7e5 Author: acorn Date: 2013-01-27 21:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cf8470eaf7e5 Merge - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java - make/solaris/makefiles/kernel.make ! src/cpu/x86/vm/assembler_x86.hpp ! src/share/vm/classfile/vmSymbols.hpp Changeset: 16fb9f942703 Author: acorn Date: 2013-01-25 15:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/16fb9f942703 6479360: PrintClassHistogram improvements Summary: jcmd GC.class_stats (UnlockDiagnosticVMOptions) Reviewed-by: coleenp, hseigel, sla, acorn Contributed-by: ioi.lam at oracle.com ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/annotations.hpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: 0d26ce8e9251 Author: acorn Date: 2013-01-28 10:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0d26ce8e9251 Merge - make/solaris/makefiles/kernel.make ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp Changeset: 815957d0203e Author: acorn Date: 2013-01-28 10:55 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/815957d0203e 8004967: Default method cause VerifyError: Illegal use of nonvirtual Summary: Recognize VM generated method in old verifier Reviewed-by: acorn, coleenp Contributed-by: bharadwaj.yadavelli at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 7885e162c30f Author: acorn Date: 2013-01-28 09:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7885e162c30f Merge Changeset: 9be6cde7919d Author: ctornqvi Date: 2013-01-25 10:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9be6cde7919d 8006413: Add utility classes for writing better multiprocess tests in jtreg Summary: Add a few utility classes to test/testlibrary to support multi process testing in jtreg tests. Added a test case for one of the utility classes. Also reviewed by Vitaly Davidovich Reviewed-by: brutisso, dholmes, vlivanov, nloodin, mgerdin + test/testlibrary/OutputAnalyzerTest.java + test/testlibrary/com/oracle/java/testlibrary/JDKToolFinder.java + test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java + test/testlibrary/com/oracle/java/testlibrary/OutputBuffer.java + test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java + test/testlibrary/com/oracle/java/testlibrary/StreamPumper.java Changeset: baf7fac3167e Author: hseigel Date: 2013-02-01 14:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/baf7fac3167e 8006298: Specifying malformed JFR options (-XX:+FlightRecorderOptions) outputs non-sensical error Summary: Change error messages for malformed options so the messages are more useful. Reviewed-by: mikael, kvn, nloodin ! src/share/vm/runtime/arguments.cpp Changeset: 4c75576d18d0 Author: hseigel Date: 2013-02-01 13:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4c75576d18d0 Merge Changeset: 9bf5f643d1cf Author: sspitsyn Date: 2013-01-31 20:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9bf5f643d1cf 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds Summary: Need a support for invokedynamic entry kinds when new and old constant pools are merged. Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp Changeset: dc31f560d6e7 Author: sspitsyn Date: 2013-01-31 20:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dc31f560d6e7 8006546: JSR 292: typos in the ConstantPool::copy_cp_impl() Summary: Simple typos that need to be fixed Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/oops/constantPool.cpp Changeset: 79c1bb8fce5d Author: sspitsyn Date: 2013-01-31 20:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/79c1bb8fce5d 8006731: JSR 292: the VM_RedefineClasses::rewrite_cp_refs_in_method() must support invokedynamic Summary: The invokedynamic bytecode ref to a CP entry needs to be checked and fixed as well. Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 9a9f870325cf Author: minqi Date: 2013-02-01 10:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9a9f870325cf Merge Changeset: b935589d2807 Author: minqi Date: 2013-02-01 14:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b935589d2807 Merge Changeset: 44c5fcd9cb25 Author: iklam Date: 2013-01-24 10:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/44c5fcd9cb25 8006280: Need to reorder metadata structures to reduce size (64-bit) Summary: Reordered Klass, InstanceKlass and Method to save 8 bytes each Reviewed-by: coleenp, jiangli Contributed-by: ioi.lam at oracle.com ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.hpp Changeset: 1eae78177059 Author: jiangli Date: 2013-02-01 15:25 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1eae78177059 Merge - make/solaris/makefiles/kernel.make ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.hpp Changeset: dc8ad3fd7050 Author: jiangli Date: 2013-02-01 19:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dc8ad3fd7050 Merge Changeset: 4102b59539ce Author: ctornqvi Date: 2013-02-01 23:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4102b59539ce 8005012: Add WB APIs to better support NMT testing Summary: Add WB API functions to enable better NMT testing Reviewed-by: dholmes, zgu ! src/share/tools/whitebox/sun/hotspot/WhiteBox.java ! src/share/vm/memory/allocation.hpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memPtr.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 4460acf8687b Author: ctornqvi Date: 2013-02-02 07:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4460acf8687b Merge Changeset: 9fe95b01ad32 Author: ctornqvi Date: 2013-02-02 08:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9fe95b01ad32 Merge Changeset: 43badbe2717a Author: minqi Date: 2013-01-31 17:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/43badbe2717a 8000973: SA on windows thread inspection is broken Summary: After bug 7161732, On Windows SA could not find correct address of thread_id of OSThread since _thread_id moved to end of the class . The presupposition of the address is following thread handle no longer stands. Fix by adding thread_id field to OSThread and getting the address directly from OSThread. Reviewed-by: nloodin, sspitsyn Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/amd64/WindbgAMD64Thread.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/x86/WindbgX86Thread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/OSThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/win32_amd64/Win32AMD64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/win32_x86/Win32X86JavaThreadPDAccess.java Changeset: 65b632b77a97 Author: minqi Date: 2013-02-01 22:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/65b632b77a97 Merge Changeset: ff5401ad5635 Author: minqi Date: 2013-02-02 03:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ff5401ad5635 Merge Changeset: 879c6de913d6 Author: ctornqvi Date: 2013-02-02 16:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/879c6de913d6 8005013: Add NMT tests Summary: Add tests for the Native Memory Tracking feature, includes regression tests for 8005936 and 8004802 Reviewed-by: zgu, coleenp ! test/TEST.ROOT + test/runtime/NMT/AllocTestType.java + test/runtime/NMT/BaselineWithParameter.java + test/runtime/NMT/CommandLineDetail.java + test/runtime/NMT/CommandLineEmptyArgument.java + test/runtime/NMT/CommandLineInvalidArgument.java + test/runtime/NMT/CommandLineSummary.java + test/runtime/NMT/CommandLineTurnOffNMT.java + test/runtime/NMT/JcmdScale.java + test/runtime/NMT/JcmdWithNMTDisabled.java + test/runtime/NMT/PrintNMTStatistics.java + test/runtime/NMT/PrintNMTStatisticsWithNMTDisabled.java + test/runtime/NMT/ShutdownTwice.java + test/runtime/NMT/SummaryAfterShutdown.java + test/runtime/NMT/SummarySanityCheck.java Changeset: a7f9a1195d86 Author: ctornqvi Date: 2013-02-02 20:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a7f9a1195d86 8000363: runtime/7158988/FieldMonitor.java fails with exception Summary: Removed unnecessary shell script in the test. Reviewed-by: coleenp, sla ! test/runtime/7158988/FieldMonitor.java - test/runtime/7158988/TestFieldMonitor.sh Changeset: 8f696cf1a0fb Author: dsamersoff Date: 2013-02-03 22:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8f696cf1a0fb 8002048: Protocol to discovery of manageable Java processes on a network Summary: Introduce a protocol to discover manageble Java instances across a network subnet, JDP Reviewed-by: sla, dfuchs ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: c4ef3380a70b Author: hseigel Date: 2013-02-03 16:49 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c4ef3380a70b 7197672: There are issues with shared data on windows Summary: On Windows, set rw protection on the CDS file just before removing it. Reviewed-by: dcubed, iklam ! src/share/vm/memory/filemap.cpp Changeset: ce5467120c84 Author: hseigel Date: 2013-02-03 17:12 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ce5467120c84 Merge Changeset: 10d5f25a7c67 Author: hseigel Date: 2013-02-04 08:26 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/10d5f25a7c67 8000968: NPG: UseCompressedKlassPointers asserts with ObjectAlignmentInBytes for > 32G CompressedOops Summary: Pick a base that works for both CompressedOpps alignment and CompressedKlassPtrs alignment. Reviewed-by: kvn, roland ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/runtime/arguments.cpp + test/runtime/8000968/Test8000968.sh Changeset: 24a91505f9d5 Author: emc Date: 2013-02-04 13:05 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/24a91505f9d5 8006949: Update hotspot for MethodParameters format change 8006907: Hotspot should reject classfiles with multiple MethodParameters attributes Summary: Update to Hotspot's processing of MethodParameters attributes in classfiles Reviewed-by: coleenp, jrose ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/prims/jvm.cpp Changeset: 42ea5e1fad75 Author: coleenp Date: 2013-02-04 13:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/42ea5e1fad75 Merge Changeset: ab826603e572 Author: simonis Date: 2013-02-04 13:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ab826603e572 8007475: Memory stomp with UseMallocOnly Summary: Fix off-by-one error Reviewed-by: coleenp, hseigel ! src/share/vm/classfile/stackMapFrame.hpp + test/runtime/8007475/StackMapFrameTest.java Changeset: a401757763f9 Author: coleenp Date: 2013-02-04 22:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a401757763f9 Merge Changeset: 12285410684f Author: dholmes Date: 2013-02-04 23:53 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/12285410684f 8006508: Wrong frame constructor is called in os_linux_x86.cpp Reviewed-by: dholmes, coleenp Contributed-by: Jeremy Manson ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp Changeset: f3ea1af9207a Author: dholmes Date: 2013-02-05 00:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f3ea1af9207a Merge Changeset: 454d7cc622ab Author: dcubed Date: 2013-02-06 15:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/454d7cc622ab Merge - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java - make/solaris/makefiles/kernel.make ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp - test/runtime/7158988/TestFieldMonitor.sh From John.Coomes at oracle.com Thu Feb 7 12:02:15 2013 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 7 Feb 2013 12:02:15 -0800 Subject: CFV: New hotspot Group Member: Bengt Rutisson Message-ID: <20756.2119.61953.313096@oracle.com> I hereby nominate Bengt Rutisson to Membership in the hotspot Group. Bengt is an Oracle engineer and has been working on HotSpot for more than two years; prior to that he worked on the jrockit JVM. He is a Reviewer for the hsx Project and has contributed more than 50 HotSpot changes, primarily relating to the G1 collector. Votes are due by 7:00 PM Thursday, February 21, 2013 UTC [1]. Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. John Coomes, hotspot Group Lead [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Bengt+Rutisson&iso=20130221T19 [2] http://openjdk.java.net/census/#hotspot [3] http://openjdk.java.net/groups/#member-vote From John.Coomes at oracle.com Thu Feb 7 12:03:18 2013 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 7 Feb 2013 12:03:18 -0800 Subject: CFV: New hotspot Group Member: Stefan Karlsson Message-ID: <20756.2182.166418.194006@oracle.com> I hereby nominate Stefan Karlsson to Membership in the hotspot Group. In addition to his earlier experience developing the jrockit JVM, Stefan has been working on the HotSpot JVM at Oracle for more than two years. He has contributed several dozen HotSpot changes, and was a key contributor to the project to remove the permanent generation. He is a Reviewer for the hsx Project and a Committer for the jdk8, jdk7u and jdk6 Projects. Votes are due by 7:00 PM Thursday, February 21, 2013 UTC [1]. Only current Members of the hotspot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. John Coomes, hotspot Group Lead [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Stefan+Karlsson&iso=20130221T19 [2] http://openjdk.java.net/census/#hotspot [3] http://openjdk.java.net/groups/#member-vote From daniel.daugherty at oracle.com Thu Feb 7 12:33:29 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 07 Feb 2013 13:33:29 -0700 Subject: CFV: New hotspot Group Member: Bengt Rutisson In-Reply-To: <20756.2119.61953.313096@oracle.com> References: <20756.2119.61953.313096@oracle.com> Message-ID: <51140F99.2040203@oracle.com> Vote: yes Dan On 2/7/13 1:02 PM, John Coomes wrote: > I hereby nominate Bengt Rutisson to Membership in the hotspot Group. > > Bengt is an Oracle engineer and has been working on HotSpot for more > than two years; prior to that he worked on the jrockit JVM. He is a > Reviewer for the hsx Project and has contributed more than 50 HotSpot > changes, primarily relating to the G1 collector. > > Votes are due by 7:00 PM Thursday, February 21, 2013 UTC [1]. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > John Coomes, hotspot Group Lead > > [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Bengt+Rutisson&iso=20130221T19 > [2] http://openjdk.java.net/census/#hotspot > [3] http://openjdk.java.net/groups/#member-vote From daniel.daugherty at oracle.com Thu Feb 7 12:33:43 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 07 Feb 2013 13:33:43 -0700 Subject: CFV: New hotspot Group Member: Stefan Karlsson In-Reply-To: <20756.2182.166418.194006@oracle.com> References: <20756.2182.166418.194006@oracle.com> Message-ID: <51140FA7.1070706@oracle.com> Vote: yes Dan On 2/7/13 1:03 PM, John Coomes wrote: > I hereby nominate Stefan Karlsson to Membership in the hotspot Group. > > In addition to his earlier experience developing the jrockit JVM, > Stefan has been working on the HotSpot JVM at Oracle for more than two > years. He has contributed several dozen HotSpot changes, and was a > key contributor to the project to remove the permanent generation. He > is a Reviewer for the hsx Project and a Committer for the jdk8, jdk7u > and jdk6 Projects. > > Votes are due by 7:00 PM Thursday, February 21, 2013 UTC [1]. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > John Coomes, hotspot Group Lead > > [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Stefan+Karlsson&iso=20130221T19 > [2] http://openjdk.java.net/census/#hotspot > [3] http://openjdk.java.net/groups/#member-vote From coleen.phillimore at oracle.com Thu Feb 7 12:42:23 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 07 Feb 2013 15:42:23 -0500 Subject: CFV: New hotspot Group Member: Bengt Rutisson In-Reply-To: <20756.2119.61953.313096@oracle.com> References: <20756.2119.61953.313096@oracle.com> Message-ID: <511411AF.9060904@oracle.com> Vote: yes coleenp On 02/07/2013 03:02 PM, John Coomes wrote: > I hereby nominate Bengt Rutisson to Membership in the hotspot Group. > > Bengt is an Oracle engineer and has been working on HotSpot for more > than two years; prior to that he worked on the jrockit JVM. He is a > Reviewer for the hsx Project and has contributed more than 50 HotSpot > changes, primarily relating to the G1 collector. > > Votes are due by 7:00 PM Thursday, February 21, 2013 UTC [1]. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > John Coomes, hotspot Group Lead > > [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Bengt+Rutisson&iso=20130221T19 > [2] http://openjdk.java.net/census/#hotspot > [3] http://openjdk.java.net/groups/#member-vote From coleen.phillimore at oracle.com Thu Feb 7 12:42:35 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 07 Feb 2013 15:42:35 -0500 Subject: CFV: New hotspot Group Member: Stefan Karlsson In-Reply-To: <20756.2182.166418.194006@oracle.com> References: <20756.2182.166418.194006@oracle.com> Message-ID: <511411BB.9040800@oracle.com> Vote: yes coleenp On 02/07/2013 03:03 PM, John Coomes wrote: > I hereby nominate Stefan Karlsson to Membership in the hotspot Group. > > In addition to his earlier experience developing the jrockit JVM, > Stefan has been working on the HotSpot JVM at Oracle for more than two > years. He has contributed several dozen HotSpot changes, and was a > key contributor to the project to remove the permanent generation. He > is a Reviewer for the hsx Project and a Committer for the jdk8, jdk7u > and jdk6 Projects. > > Votes are due by 7:00 PM Thursday, February 21, 2013 UTC [1]. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > John Coomes, hotspot Group Lead > > [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Stefan+Karlsson&iso=20130221T19 > [2] http://openjdk.java.net/census/#hotspot > [3] http://openjdk.java.net/groups/#member-vote From vladimir.kozlov at oracle.com Thu Feb 7 12:54:57 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Feb 2013 12:54:57 -0800 Subject: CFV: New hotspot Group Member: Bengt Rutisson In-Reply-To: <20756.2119.61953.313096@oracle.com> References: <20756.2119.61953.313096@oracle.com> Message-ID: <511414A1.7030001@oracle.com> Vote: yes On 2/7/13 12:02 PM, John Coomes wrote: > I hereby nominate Bengt Rutisson to Membership in the hotspot Group. > > Bengt is an Oracle engineer and has been working on HotSpot for more > than two years; prior to that he worked on the jrockit JVM. He is a > Reviewer for the hsx Project and has contributed more than 50 HotSpot > changes, primarily relating to the G1 collector. > > Votes are due by 7:00 PM Thursday, February 21, 2013 UTC [1]. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > John Coomes, hotspot Group Lead > > [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Bengt+Rutisson&iso=20130221T19 > [2] http://openjdk.java.net/census/#hotspot > [3] http://openjdk.java.net/groups/#member-vote > From vladimir.kozlov at oracle.com Thu Feb 7 12:55:29 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Feb 2013 12:55:29 -0800 Subject: CFV: New hotspot Group Member: Stefan Karlsson In-Reply-To: <20756.2182.166418.194006@oracle.com> References: <20756.2182.166418.194006@oracle.com> Message-ID: <511414C1.1090605@oracle.com> Vote: yes On 2/7/13 12:03 PM, John Coomes wrote: > I hereby nominate Stefan Karlsson to Membership in the hotspot Group. > > In addition to his earlier experience developing the jrockit JVM, > Stefan has been working on the HotSpot JVM at Oracle for more than two > years. He has contributed several dozen HotSpot changes, and was a > key contributor to the project to remove the permanent generation. He > is a Reviewer for the hsx Project and a Committer for the jdk8, jdk7u > and jdk6 Projects. > > Votes are due by 7:00 PM Thursday, February 21, 2013 UTC [1]. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > John Coomes, hotspot Group Lead > > [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Stefan+Karlsson&iso=20130221T19 > [2] http://openjdk.java.net/census/#hotspot > [3] http://openjdk.java.net/groups/#member-vote > From zhengyu.gu at oracle.com Thu Feb 7 13:07:59 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 07 Feb 2013 16:07:59 -0500 Subject: CFV: New hotspot Group Member: Stefan Karlsson In-Reply-To: <20756.2182.166418.194006@oracle.com> References: <20756.2182.166418.194006@oracle.com> Message-ID: <511417AF.1090306@oracle.com> Vote: yes -Zhengyu On 2/7/2013 3:03 PM, John Coomes wrote: > I hereby nominate Stefan Karlsson to Membership in the hotspot Group. > > In addition to his earlier experience developing the jrockit JVM, > Stefan has been working on the HotSpot JVM at Oracle for more than two > years. He has contributed several dozen HotSpot changes, and was a > key contributor to the project to remove the permanent generation. He > is a Reviewer for the hsx Project and a Committer for the jdk8, jdk7u > and jdk6 Projects. > > Votes are due by 7:00 PM Thursday, February 21, 2013 UTC [1]. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > John Coomes, hotspot Group Lead > > [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Stefan+Karlsson&iso=20130221T19 > [2] http://openjdk.java.net/census/#hotspot > [3] http://openjdk.java.net/groups/#member-vote From zhengyu.gu at oracle.com Thu Feb 7 13:08:26 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 07 Feb 2013 16:08:26 -0500 Subject: CFV: New hotspot Group Member: Bengt Rutisson In-Reply-To: <20756.2119.61953.313096@oracle.com> References: <20756.2119.61953.313096@oracle.com> Message-ID: <511417CA.1000002@oracle.com> Vote: yes -Zhengyu On 2/7/2013 3:02 PM, John Coomes wrote: > I hereby nominate Bengt Rutisson to Membership in the hotspot Group. > > Bengt is an Oracle engineer and has been working on HotSpot for more > than two years; prior to that he worked on the jrockit JVM. He is a > Reviewer for the hsx Project and has contributed more than 50 HotSpot > changes, primarily relating to the G1 collector. > > Votes are due by 7:00 PM Thursday, February 21, 2013 UTC [1]. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > John Coomes, hotspot Group Lead > > [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Bengt+Rutisson&iso=20130221T19 > [2] http://openjdk.java.net/census/#hotspot > [3] http://openjdk.java.net/groups/#member-vote From karen.kinnear at oracle.com Thu Feb 7 13:19:03 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 7 Feb 2013 16:19:03 -0500 Subject: CFV: New hotspot Group Member: Bengt Rutisson In-Reply-To: <20756.2119.61953.313096@oracle.com> References: <20756.2119.61953.313096@oracle.com> Message-ID: Vote: yes On Feb 7, 2013, at 3:02 PM, John Coomes wrote: > I hereby nominate Bengt Rutisson to Membership in the hotspot Group. > > Bengt is an Oracle engineer and has been working on HotSpot for more > than two years; prior to that he worked on the jrockit JVM. He is a > Reviewer for the hsx Project and has contributed more than 50 HotSpot > changes, primarily relating to the G1 collector. > > Votes are due by 7:00 PM Thursday, February 21, 2013 UTC [1]. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > John Coomes, hotspot Group Lead > > [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Bengt+Rutisson&iso=20130221T19 > [2] http://openjdk.java.net/census/#hotspot > [3] http://openjdk.java.net/groups/#member-vote From karen.kinnear at oracle.com Thu Feb 7 13:19:13 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 7 Feb 2013 16:19:13 -0500 Subject: CFV: New hotspot Group Member: Stefan Karlsson In-Reply-To: <20756.2182.166418.194006@oracle.com> References: <20756.2182.166418.194006@oracle.com> Message-ID: <77542EBF-35A2-45C1-822E-FA8BD947C6A9@oracle.com> Vote: yes On Feb 7, 2013, at 3:03 PM, John Coomes wrote: > I hereby nominate Stefan Karlsson to Membership in the hotspot Group. > > In addition to his earlier experience developing the jrockit JVM, > Stefan has been working on the HotSpot JVM at Oracle for more than two > years. He has contributed several dozen HotSpot changes, and was a > key contributor to the project to remove the permanent generation. He > is a Reviewer for the hsx Project and a Committer for the jdk8, jdk7u > and jdk6 Projects. > > Votes are due by 7:00 PM Thursday, February 21, 2013 UTC [1]. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > John Coomes, hotspot Group Lead > > [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Stefan+Karlsson&iso=20130221T19 > [2] http://openjdk.java.net/census/#hotspot > [3] http://openjdk.java.net/groups/#member-vote From John.Coomes at oracle.com Thu Feb 7 14:56:34 2013 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 7 Feb 2013 14:56:34 -0800 Subject: CFV: New hotspot Group Member: Bengt Rutisson In-Reply-To: <20756.2119.61953.313096@oracle.com> References: <20756.2119.61953.313096@oracle.com> Message-ID: <20756.12578.866886.733306@oracle.com> Vote: yes -John From John.Coomes at oracle.com Thu Feb 7 14:57:54 2013 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 7 Feb 2013 14:57:54 -0800 Subject: CFV: New hotspot Group Member: Stefan Karlsson In-Reply-To: <20756.2182.166418.194006@oracle.com> References: <20756.2182.166418.194006@oracle.com> Message-ID: <20756.12658.156330.313632@oracle.com> Vote: yes -John From christian.thalinger at oracle.com Thu Feb 7 15:31:09 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 7 Feb 2013 15:31:09 -0800 Subject: CFV: New hotspot Group Member: Stefan Karlsson In-Reply-To: <20756.2182.166418.194006@oracle.com> References: <20756.2182.166418.194006@oracle.com> Message-ID: <4B881F42-64D0-4985-B453-CD77FAAD241C@oracle.com> Vote: yes On Feb 7, 2013, at 12:03 PM, John Coomes wrote: > I hereby nominate Stefan Karlsson to Membership in the hotspot Group. > > In addition to his earlier experience developing the jrockit JVM, > Stefan has been working on the HotSpot JVM at Oracle for more than two > years. He has contributed several dozen HotSpot changes, and was a > key contributor to the project to remove the permanent generation. He > is a Reviewer for the hsx Project and a Committer for the jdk8, jdk7u > and jdk6 Projects. > > Votes are due by 7:00 PM Thursday, February 21, 2013 UTC [1]. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > John Coomes, hotspot Group Lead > > [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Stefan+Karlsson&iso=20130221T19 > [2] http://openjdk.java.net/census/#hotspot > [3] http://openjdk.java.net/groups/#member-vote From christian.thalinger at oracle.com Thu Feb 7 15:31:59 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 7 Feb 2013 15:31:59 -0800 Subject: CFV: New hotspot Group Member: Bengt Rutisson In-Reply-To: <20756.2119.61953.313096@oracle.com> References: <20756.2119.61953.313096@oracle.com> Message-ID: <4A4A3231-BF31-4467-8C53-55D5D092D0CE@oracle.com> Vote: yes On Feb 7, 2013, at 12:02 PM, John Coomes wrote: > I hereby nominate Bengt Rutisson to Membership in the hotspot Group. > > Bengt is an Oracle engineer and has been working on HotSpot for more > than two years; prior to that he worked on the jrockit JVM. He is a > Reviewer for the hsx Project and has contributed more than 50 HotSpot > changes, primarily relating to the G1 collector. > > Votes are due by 7:00 PM Thursday, February 21, 2013 UTC [1]. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > John Coomes, hotspot Group Lead > > [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Bengt+Rutisson&iso=20130221T19 > [2] http://openjdk.java.net/census/#hotspot > [3] http://openjdk.java.net/groups/#member-vote From john.cuthbertson at oracle.com Thu Feb 7 15:54:07 2013 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Thu, 07 Feb 2013 23:54:07 +0000 Subject: hg: hsx/hsx24/hotspot: 4 new changesets Message-ID: <20130207235418.88C60478FB@hg.openjdk.java.net> Changeset: dd4950f173a5 Author: johnc Date: 2012-12-21 11:45 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/dd4950f173a5 8001424: G1: Rename certain G1-specific flags Summary: Rename G1DefaultMinNewGenPercent, G1DefaultMaxNewGenPercent, and G1OldCSetRegionLiveThresholdPercent to G1NewSizePercent, G1MaxNewSizePercent, and G1MixedGCLiveThresholdPercent respectively. The previous names are no longer accepted. Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: c537391c6153 Author: johnc Date: 2013-02-07 09:42 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c537391c6153 8004816: G1: Kitchensink failures after marking stack changes Summary: Reset the marking state, including the mark stack overflow flag, in the event of a marking stack overflow during serial reference processing. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: 2fe1685929bd Author: johnc Date: 2013-01-15 12:32 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2fe1685929bd 8001425: G1: Change the default values for certain G1 specific flags Summary: Changes to default and ergonomic flag values recommended by performance team. Changes were also reviewed by Monica Beckwith . Reviewed-by: brutisso, huntch ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: c9dbfdff5abf Author: johnc Date: 2013-01-31 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c9dbfdff5abf 8005875: G1: Kitchensink fails with ParallelGCThreads=0 Summary: Check that the concurrent marking worker gang exists in ConcurrentMark::print_worker_threads_on(). Changes were also reviewed by Vitaly Davidovich . Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp From david.holmes at oracle.com Thu Feb 7 16:26:25 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 08 Feb 2013 10:26:25 +1000 Subject: CFV: New hotspot Group Member: Bengt Rutisson In-Reply-To: <20756.2119.61953.313096@oracle.com> References: <20756.2119.61953.313096@oracle.com> Message-ID: <51144631.9050109@oracle.com> Vote: yes David On 8/02/2013 6:02 AM, John Coomes wrote: > I hereby nominate Bengt Rutisson to Membership in the hotspot Group. > > Bengt is an Oracle engineer and has been working on HotSpot for more > than two years; prior to that he worked on the jrockit JVM. He is a > Reviewer for the hsx Project and has contributed more than 50 HotSpot > changes, primarily relating to the G1 collector. > > Votes are due by 7:00 PM Thursday, February 21, 2013 UTC [1]. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > John Coomes, hotspot Group Lead > > [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Bengt+Rutisson&iso=20130221T19 > [2] http://openjdk.java.net/census/#hotspot > [3] http://openjdk.java.net/groups/#member-vote From david.holmes at oracle.com Thu Feb 7 16:27:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 08 Feb 2013 10:27:32 +1000 Subject: CFV: New hotspot Group Member: Stefan Karlsson In-Reply-To: <20756.2182.166418.194006@oracle.com> References: <20756.2182.166418.194006@oracle.com> Message-ID: <51144674.9070109@oracle.com> Vote: yes David On 8/02/2013 6:03 AM, John Coomes wrote: > I hereby nominate Stefan Karlsson to Membership in the hotspot Group. > > In addition to his earlier experience developing the jrockit JVM, > Stefan has been working on the HotSpot JVM at Oracle for more than two > years. He has contributed several dozen HotSpot changes, and was a > key contributor to the project to remove the permanent generation. He > is a Reviewer for the hsx Project and a Committer for the jdk8, jdk7u > and jdk6 Projects. > > Votes are due by 7:00 PM Thursday, February 21, 2013 UTC [1]. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > John Coomes, hotspot Group Lead > > [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Stefan+Karlsson&iso=20130221T19 > [2] http://openjdk.java.net/census/#hotspot > [3] http://openjdk.java.net/groups/#member-vote From sadhak001 at gmail.com Thu Feb 7 17:16:40 2013 From: sadhak001 at gmail.com (Mani Sarkar) Date: Fri, 8 Feb 2013 01:16:40 +0000 Subject: RFC: deprecating SPARC V8 support? Message-ID: Hi, I ran the below query to members of the Adopt-a-JSR, Adopt OpenJDK and the LJC mailing lists and no one came back with any feedback with regards to being impacted by the decision to deprecate SPACE V8 support. I hope this helps along with the other feedback you have received from your sources. Thanks. Regards, mani -- *Twitter:* @theNeomatrix369 *Blog:* http://neomatrix369.wordpress.com *JUG activity:* LJC Advocate *Meet-a-Project:* https://github.com/MutabilityDetector *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* * * Hello Community! We are playing with the idea to deprecate SPARC V8 support in HotSpot and I would like to get some input from the OpenJDK community (especially from the usual suspects: SAP, RedHat, Debian, ...). Is anyone out there still using SPARC V8 hardware or is supporting it? -- Chris From vladimir.x.ivanov at oracle.com Thu Feb 7 17:36:45 2013 From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com) Date: Fri, 08 Feb 2013 01:36:45 +0000 Subject: hg: hsx/hotspot-main/hotspot: 11 new changesets Message-ID: <20130208013709.DAF6547905@hg.openjdk.java.net> Changeset: fcc9e7681d63 Author: vlivanov Date: 2013-02-01 02:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fcc9e7681d63 8006410: allocating without ResourceMark when CompileCommand was specified Reviewed-by: kvn, vlivanov Contributed-by: Igor Ignatyev ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/oops/symbol.cpp Changeset: 60bba1398c51 Author: vlivanov Date: 2013-02-01 03:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/60bba1398c51 8005439: no message about inline method if it specifed by CompileCommand Reviewed-by: kvn, vlivanov Contributed-by: Igor Ignatyev ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/parse.hpp Changeset: e4bb0bda20a4 Author: morris Date: 2013-01-25 16:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e4bb0bda20a4 8005811: Turn off TierdCompilation in JDK8 trunk for all platforms Summary: Disable tiered compilation in jdk8 because of CodeCache and performance anomalies Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp Changeset: 76341426b645 Author: drchase Date: 2013-01-25 16:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/76341426b645 8006500: compiler/8004741/Test8004741.java fails intermediately Summary: rewrote the test to be more reliable, add test for invalid size exception Reviewed-by: kvn ! test/compiler/8004741/Test8004741.java Changeset: 9fae07c31641 Author: morris Date: 2013-01-25 16:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9fae07c31641 6518907: cleanup IA64 specific code in Hotspot Summary: removed unused IA64 specific code Reviewed-by: twisti, kvn, dholmes ! agent/src/os/linux/LinuxDebuggerLocal.c ! agent/src/os/linux/libproc.h ! agent/src/os/win32/windbg/sawindbg.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/vframeArray.cpp Changeset: 37c18711a0df Author: roland Date: 2013-02-04 09:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/37c18711a0df 8005114: VM is crashing in ciKlass*ciObjArrayKlass::element_klass() if metaspaces are full Summary: missing test for loaded klass in c1 Reviewed-by: kvn ! src/share/vm/c1/c1_Instruction.cpp Changeset: 39901f2f1abe Author: mikael Date: 2013-02-04 10:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/39901f2f1abe 8007403: Incorrect format arguments in adlparse.cpp Reviewed-by: kvn, twisti ! src/share/vm/adlc/adlparse.cpp Changeset: 8bd61471a109 Author: roland Date: 2013-02-04 11:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8bd61471a109 8007144: Incremental inlining mistakes some call sites for dead ones and doesn't inline them Summary: wrong detection for dead call sites. Reviewed-by: kvn ! src/share/vm/opto/callGenerator.cpp Changeset: 6a51fc70a15e Author: vlivanov Date: 2013-02-05 08:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6a51fc70a15e 8006613: adding reason to made_not_compilable Reviewed-by: kvn, vlivanov Contributed-by: Igor Ignatyev ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 4fcf990aa34a Author: drchase Date: 2013-02-06 11:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4fcf990aa34a 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray Summary: check ndimensions before accessing length[i] element Reviewed-by: kvn Contributed-by: volker.simonis at gmail.com ! src/share/vm/opto/parse3.cpp Changeset: d05ff4bf41b3 Author: vlivanov Date: 2013-02-07 12:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d05ff4bf41b3 Merge ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.hpp From john.coomes at oracle.com Thu Feb 7 20:31:51 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 08 Feb 2013 04:31:51 +0000 Subject: hg: hsx/hotspot-main/corba: 3 new changesets Message-ID: <20130208043155.F07EE4790E@hg.openjdk.java.net> Changeset: ce106b6b7394 Author: ohrstrom Date: 2013-01-31 14:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/ce106b6b7394 8006872: Stop creating four jars with identical content in the new build system. Reviewed-by: erikj ! makefiles/BuildCorba.gmk Changeset: 58be6ca3c060 Author: katleman Date: 2013-02-05 18:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/58be6ca3c060 Merge Changeset: 35684a40c584 Author: katleman Date: 2013-02-07 12:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/35684a40c584 Added tag jdk8-b76 for changeset 58be6ca3c060 ! .hgtags From john.coomes at oracle.com Thu Feb 7 20:32:00 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 08 Feb 2013 04:32:00 +0000 Subject: hg: hsx/hotspot-main/jaxp: 3 new changesets Message-ID: <20130208043215.834F64790F@hg.openjdk.java.net> Changeset: 8f6ca8755f46 Author: ohrstrom Date: 2013-01-31 14:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/8f6ca8755f46 8006872: Stop creating four jars with identical content in the new build system. Reviewed-by: erikj ! makefiles/BuildJaxp.gmk Changeset: 0c08593944d0 Author: katleman Date: 2013-02-05 18:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/0c08593944d0 Merge Changeset: 02195d0e96b9 Author: katleman Date: 2013-02-07 12:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/02195d0e96b9 Added tag jdk8-b76 for changeset 0c08593944d0 ! .hgtags From john.coomes at oracle.com Thu Feb 7 20:32:20 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 08 Feb 2013 04:32:20 +0000 Subject: hg: hsx/hotspot-main/jaxws: 3 new changesets Message-ID: <20130208043229.7462347910@hg.openjdk.java.net> Changeset: 54beebb17494 Author: ohrstrom Date: 2013-01-31 14:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/54beebb17494 8006872: Stop creating four jars with identical content in the new build system. Reviewed-by: erikj ! makefiles/BuildJaxws.gmk Changeset: c4853f3f0e89 Author: katleman Date: 2013-02-05 18:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/c4853f3f0e89 Merge Changeset: 64dfba1bad16 Author: katleman Date: 2013-02-07 12:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/64dfba1bad16 Added tag jdk8-b76 for changeset c4853f3f0e89 ! .hgtags From john.coomes at oracle.com Thu Feb 7 20:31:46 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 08 Feb 2013 04:31:46 +0000 Subject: hg: hsx/hotspot-main: 8 new changesets Message-ID: <20130208043147.31CFD4790D@hg.openjdk.java.net> Changeset: 6e296219633d Author: tbell Date: 2013-01-31 13:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/6e296219633d 8006933: Need to use nawk on Solaris to avoid awk limitations Reviewed-by: erikj, dholmes, dsamersoff ! common/makefiles/IdlCompilation.gmk Changeset: 12782ec1da5f Author: ohrstrom Date: 2013-01-31 14:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/12782ec1da5f 8006872: Stop creating four jars with identical content in the new build system. Reviewed-by: erikj ! common/autoconf/spec.gmk.in ! common/makefiles/JavaCompilation.gmk ! common/makefiles/javadoc/Javadoc.gmk Changeset: 7e584be2ee58 Author: ohrstrom Date: 2013-02-01 11:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/7e584be2ee58 Merge Changeset: 339e4df096a2 Author: erikj Date: 2013-02-04 10:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/339e4df096a2 8007093: build-infra: Make should fail if spec is older than configure files Reviewed-by: tbell ! common/makefiles/Main.gmk Changeset: dea045cc48ca Author: erikj Date: 2013-02-04 11:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/dea045cc48ca 8007275: build-infra: Create final-images target Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/makefiles/Jprt.gmk Changeset: d3d9ab8ee7b0 Author: erikj Date: 2013-02-05 16:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/d3d9ab8ee7b0 8007524: build-infra: Incremental build of tools.jar broken Reviewed-by: tbell ! common/makefiles/JavaCompilation.gmk Changeset: 278af9fc67e7 Author: katleman Date: 2013-02-05 18:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/278af9fc67e7 Merge Changeset: 3933eebc659d Author: katleman Date: 2013-02-07 12:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/3933eebc659d Added tag jdk8-b76 for changeset 278af9fc67e7 ! .hgtags From john.coomes at oracle.com Thu Feb 7 20:32:38 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 08 Feb 2013 04:32:38 +0000 Subject: hg: hsx/hotspot-main/jdk: 5 new changesets Message-ID: <20130208043427.DCEE347911@hg.openjdk.java.net> Changeset: c5a7ac2a721f Author: ohrstrom Date: 2013-01-31 14:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c5a7ac2a721f 8006872: Stop creating four jars with identical content in the new build system. Reviewed-by: erikj ! makefiles/CreateJars.gmk ! makefiles/GensrcSwing.gmk ! makefiles/Setup.gmk Changeset: 35cf77f633c9 Author: tbell Date: 2013-02-01 09:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/35cf77f633c9 8006808: mapfile use check in jdk/make/common/shared/Defs-solaris.gmk is throwing 'egrep: syntax error' Summary: Use a valid egrep expression in the non-SPARC case Reviewed-by: dholmes ! make/common/shared/Defs-solaris.gmk Changeset: 5692ebe15321 Author: erikj Date: 2013-02-04 10:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5692ebe15321 8007268: build-infra: configure reports Solaris needs gcc for deploy, but logs don't indicate it's used. Reviewed-by: tbell, katleman ! make/common/shared/Sanity.gmk Changeset: 3a2630528661 Author: katleman Date: 2013-02-05 18:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3a2630528661 Merge Changeset: 933742f4bb4c Author: katleman Date: 2013-02-07 12:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/933742f4bb4c Added tag jdk8-b76 for changeset 3a2630528661 ! .hgtags From john.coomes at oracle.com Thu Feb 7 20:35:50 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 08 Feb 2013 04:35:50 +0000 Subject: hg: hsx/hotspot-main/langtools: 3 new changesets Message-ID: <20130208043604.69B7447912@hg.openjdk.java.net> Changeset: 2d6789a725a4 Author: ohrstrom Date: 2013-01-31 14:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2d6789a725a4 8006872: Stop creating four jars with identical content in the new build system. Reviewed-by: erikj ! makefiles/BuildLangtools.gmk Changeset: e81839b32337 Author: katleman Date: 2013-02-05 18:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e81839b32337 Merge Changeset: 6fde20398015 Author: katleman Date: 2013-02-07 12:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6fde20398015 Added tag jdk8-b76 for changeset e81839b32337 ! .hgtags From vladimir.danushevsky at oracle.com Thu Feb 7 21:50:47 2013 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Fri, 08 Feb 2013 05:50:47 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130208055056.8A5634792F@hg.openjdk.java.net> Changeset: db9981fd3124 Author: jprovino Date: 2013-01-23 13:02 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/db9981fd3124 8005915: Unify SERIALGC and INCLUDE_ALTERNATE_GCS Summary: Rename INCLUDE_ALTERNATE_GCS to INCLUDE_ALL_GCS and replace SERIALGC with INCLUDE_ALL_GCS. Reviewed-by: coleenp, stefank ! make/bsd/makefiles/minimal1.make ! make/excludeSrc.make ! make/linux/makefiles/minimal1.make ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/shared/allocationStats.cpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/gcAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/immutableSpace.cpp ! src/share/vm/gc_implementation/shared/isGCActiveMark.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/generationSpec.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/specialized_oop_closures.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/tenuredGeneration.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceClassLoaderKlass.cpp ! src/share/vm/oops/instanceClassLoaderKlass.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceMirrorKlass.cpp ! src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/instanceRefKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassPS.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/objArrayKlass.inline.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp ! src/share/vm/oops/oop.psgc.inline.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/classLoadingService.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/g1MemoryPool.hpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/memReporter.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/psMemoryPool.hpp ! src/share/vm/services/runtimeService.cpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/top.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 8391fdd36e1f Author: dlong Date: 2013-01-27 01:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8391fdd36e1f Merge ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/heapDumper.cpp Changeset: 3c9bc17b9403 Author: bpittore Date: 2013-02-07 16:05 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3c9bc17b9403 Merge ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: df8462fbe585 Author: vladidan Date: 2013-02-07 20:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/df8462fbe585 Merge ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/runtime/sharedRuntime.cpp From aleksey.shipilev at oracle.com Fri Feb 8 02:39:36 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 08 Feb 2013 14:39:36 +0400 Subject: RFR (XXS) CR 8006997: ContendedPaddingWidth should be uintx In-Reply-To: <51136C02.3080700@oracle.com> References: <510668D1.5070002@oracle.com> <51109FF5.6020804@oracle.com> <51125B90.6030404@oracle.com> <51128906.3000302@oracle.com> <5112EAA0.5050303@oracle.com> <51135D48.9040002@oracle.com> <51136C02.3080700@oracle.com> Message-ID: <5114D5E8.90000@oracle.com> On 02/07/2013 12:55 PM, David Holmes wrote: > On 7/02/2013 5:52 PM, Aleksey Shipilev wrote: >> On 02/07/2013 03:43 AM, David Holmes wrote: >>> I have to wonder whether leaving ContendedPaddingWidth as signed is not >>> the simplest thing to do as it may be impractical, if not impossible, to >>> get uniformity of the signed-ness of expressions across all platforms. >> >> Well, Vladimir I. suggested we booby-trap against negative values with >> guarantee(...). Will that be sufficient? > > Sure - a number of flags get range checked. Ok then. This is the new webrev: http://cr.openjdk.java.net/~shade/8006997/webrev.01/ I haven't found another good place to stick the guarantee() to, so opted to stick it before the actual use. I would be happy to stick it somewhere else where the options are generally checked, but found no non-platform/non-OS specific location. Testing: - Ad-hoc: fastdebug/release builds with negative value - JPRT: full-cycle HotSpot testing -Aleksey. From bengt.rutisson at oracle.com Fri Feb 8 03:43:54 2013 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Fri, 08 Feb 2013 11:43:54 +0000 Subject: hg: hsx/hotspot-main/hotspot: 12 new changesets Message-ID: <20130208114420.35EFF47938@hg.openjdk.java.net> Changeset: ec0c4951286c Author: stefank Date: 2013-01-29 10:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ec0c4951286c 8004710: NPG: jmap could throw sun.jvm.hotspot.types.WrongTypeException after PermGen removal Summary: When calculating live object regions, make sure that the alignment reserve, at the end of a TLAB, is excluded. Reviewed-by: jmasa, brutisso ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/runtime/vmStructs.cpp Changeset: 4700e77d44c1 Author: johnc Date: 2013-02-01 13:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4700e77d44c1 8006894: G1: Number of marking threads missing from PrintFlagsFinal output Summary: Set ConcGCThreads to the calculated number of marking threads. Reviewed-by: jmasa, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: d9058e388631 Author: mikael Date: 2013-02-01 17:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d9058e388631 8007257: NPG: metaspace.cpp: Incorrect arguments in calls to err_msg Summary: Fix size checks in assert and corrected some print formats. Also reviewed by vitalyd at gmail.com. Reviewed-by: coleenp, sspitsyn ! src/share/vm/memory/metaspace.cpp Changeset: 256d3f43c177 Author: johnc Date: 2013-01-31 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/256d3f43c177 8005875: G1: Kitchensink fails with ParallelGCThreads=0 Summary: Check that the concurrent marking worker gang exists in ConcurrentMark::print_worker_threads_on(). Changes were also reviewed by Vitaly Davidovich . Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 80518f4ecf32 Author: jmasa Date: 2013-02-04 12:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/80518f4ecf32 Merge ! src/share/vm/runtime/vmStructs.cpp Changeset: f2f0cf0f5444 Author: jmasa Date: 2013-02-04 13:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f2f0cf0f5444 Merge Changeset: 06fd03af6ce4 Author: johnc Date: 2013-02-04 13:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/06fd03af6ce4 8001384: G1: assert(!is_null(v)) failed: narrow oop value can never be zero Summary: Flush any deferred card mark before a Java thread exits. Reviewed-by: brutisso, jmasa ! src/share/vm/runtime/thread.cpp Changeset: 84304a77c4e3 Author: johnc Date: 2013-02-04 19:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/84304a77c4e3 Merge Changeset: 95ccff9eee8e Author: jwilhelm Date: 2013-01-28 15:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/95ccff9eee8e 6348447: Specifying -XX:OldSize crashes 64-bit VMs Summary: Heap size will be set to allow for OldSize to fit. Also reviewed by vitalyd at gmail.com Reviewed-by: ehelin, jmasa ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp Changeset: f90b9bceb8e5 Author: johnc Date: 2013-02-05 09:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f90b9bceb8e5 8005032: G1: Cleanup serial reference processing closures in concurrent marking Summary: Reuse the parallel reference processing oop closures during serial reference processing. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 50d3b37d5bcd Author: johnc Date: 2013-02-05 22:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/50d3b37d5bcd Merge Changeset: 1135141fb97e Author: brutisso Date: 2013-02-08 10:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1135141fb97e Merge ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp From staffan.larsen at oracle.com Fri Feb 8 04:24:20 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 8 Feb 2013 13:24:20 +0100 Subject: RFR (S): 8007779: os::die() on solaris should generate core file Message-ID: This is a request for review of a small change to the crash reporting on solaris. When hotspot crashes during the writing of the hs_err file, we call os::die(). On linux and bsd this causes a core file to be written (by calling ::abort()). This is good since we then have some record of what went wrong. On solaris, we call _exit() and no core file is created. There are two cases during the hs_err writing where we call os::die(). First, if the writing hangs, the WatcherThread will call os::die(). Second, if we get too many errors during the writing we will call os::die(). In both these cases it would be very helpful to have a core file. Otherwise all you have to go on is something like this: # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xffffffff653848c0, pid=11823, tid=240 # # JRE version: Java(TM) SE Runtime Environment (7.0_12-b11) # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b24 mixed mode solaris-sparc compressed oops) # Problematic frame: # C [libc.so.1+0x848c0]# [ timer expired, abort... ] Below is the change I would like to do. Thanks, /Staffan diff --git a/src/os/solaris/vm/os_solaris.cpp b/src/os/solaris/vm/os_solaris.cpp --- a/src/os/solaris/vm/os_solaris.cpp +++ b/src/os/solaris/vm/os_solaris.cpp @@ -1865,7 +1865,7 @@ // Die immediately, no exit hook, no abort hook, no cleanup. void os::die() { - _exit(-1); + ::abort(); // dump core (for debugging) } From david.holmes at oracle.com Fri Feb 8 05:22:11 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 08 Feb 2013 23:22:11 +1000 Subject: RFR (XXS) CR 8006997: ContendedPaddingWidth should be uintx In-Reply-To: <5114D5E8.90000@oracle.com> References: <510668D1.5070002@oracle.com> <51109FF5.6020804@oracle.com> <51125B90.6030404@oracle.com> <51128906.3000302@oracle.com> <5112EAA0.5050303@oracle.com> <51135D48.9040002@oracle.com> <51136C02.3080700@oracle.com> <5114D5E8.90000@oracle.com> Message-ID: <5114FC03.8010906@oracle.com> On 8/02/2013 8:39 PM, Aleksey Shipilev wrote: > On 02/07/2013 12:55 PM, David Holmes wrote: >> On 7/02/2013 5:52 PM, Aleksey Shipilev wrote: >>> On 02/07/2013 03:43 AM, David Holmes wrote: >>>> I have to wonder whether leaving ContendedPaddingWidth as signed is not >>>> the simplest thing to do as it may be impractical, if not impossible, to >>>> get uniformity of the signed-ness of expressions across all platforms. >>> >>> Well, Vladimir I. suggested we booby-trap against negative values with >>> guarantee(...). Will that be sufficient? >> >> Sure - a number of flags get range checked. > > Ok then. This is the new webrev: > http://cr.openjdk.java.net/~shade/8006997/webrev.01/ > > I haven't found another good place to stick the guarantee() to, so opted > to stick it before the actual use. I would be happy to stick it > somewhere else where the options are generally checked, but found no > non-platform/non-OS specific location. arguments.cpp - Arguments::parse_each_vm_init_arg - see -XX:MaxDirectMemorySize as an example. Are there any other constraints on this value? Thanks, David > Testing: > - Ad-hoc: fastdebug/release builds with negative value > - JPRT: full-cycle HotSpot testing > > -Aleksey. > From aleksey.shipilev at oracle.com Fri Feb 8 05:30:27 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 08 Feb 2013 17:30:27 +0400 Subject: RFR (XXS) CR 8006997: ContendedPaddingWidth should be uintx In-Reply-To: <5114FC03.8010906@oracle.com> References: <510668D1.5070002@oracle.com> <51109FF5.6020804@oracle.com> <51125B90.6030404@oracle.com> <51128906.3000302@oracle.com> <5112EAA0.5050303@oracle.com> <51135D48.9040002@oracle.com> <51136C02.3080700@oracle.com> <5114D5E8.90000@oracle.com> <5114FC03.8010906@oracle.com> Message-ID: <5114FDF3.6040102@oracle.com> On 02/08/2013 05:22 PM, David Holmes wrote: > On 8/02/2013 8:39 PM, Aleksey Shipilev wrote: >> Ok then. This is the new webrev: >> http://cr.openjdk.java.net/~shade/8006997/webrev.01/ >> >> I haven't found another good place to stick the guarantee() to, so opted >> to stick it before the actual use. I would be happy to stick it >> somewhere else where the options are generally checked, but found no >> non-platform/non-OS specific location. > > arguments.cpp - Arguments::parse_each_vm_init_arg - see > -XX:MaxDirectMemorySize as an example. Ok, great, thanks! I will update the webrev and give it another jprt spin. > Are there any other constraints on this value? Nope. The upper bound makes no sense anyway, and only affects the instance size (which, I'd guess, should be checked on it's own?). Going over sensible padding width is not as catastrophic as going below zero. It might be even fun to allocate the object with field-per-page placement. -Aleksey. From david.holmes at oracle.com Fri Feb 8 05:35:29 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 08 Feb 2013 23:35:29 +1000 Subject: RFR (S): 8007779: os::die() on solaris should generate core file In-Reply-To: References: Message-ID: <5114FF21.3080708@oracle.com> Hi Staffan, I updated the bug report before seeing this (it is rather late here :) ) There is some history here that I need to uncover. As I recall when we changed the Linux code to create a core file there was a reason for not doing it on Solaris. Haven't been able to locate the CR for that yet. It may just have been something incidental at the time - like taking up too much disk space on test machines for tests that provoke errors. I can't recall. David On 8/02/2013 10:24 PM, Staffan Larsen wrote: > This is a request for review of a small change to the crash reporting on solaris. > > When hotspot crashes during the writing of the hs_err file, we call os::die(). On linux and bsd this causes a core file to be written (by calling ::abort()). This is good since we then have some record of what went wrong. On solaris, we call _exit() and no core file is created. > > There are two cases during the hs_err writing where we call os::die(). First, if the writing hangs, the WatcherThread will call os::die(). Second, if we get too many errors during the writing we will call os::die(). In both these cases it would be very helpful to have a core file. Otherwise all you have to go on is something like this: > > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0xffffffff653848c0, pid=11823, tid=240 > # > # JRE version: Java(TM) SE Runtime Environment (7.0_12-b11) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b24 mixed mode solaris-sparc compressed oops) > # Problematic frame: > # C [libc.so.1+0x848c0]# [ timer expired, abort... ] > > Below is the change I would like to do. > > Thanks, > /Staffan > > > diff --git a/src/os/solaris/vm/os_solaris.cpp b/src/os/solaris/vm/os_solaris.cpp > --- a/src/os/solaris/vm/os_solaris.cpp > +++ b/src/os/solaris/vm/os_solaris.cpp > @@ -1865,7 +1865,7 @@ > > // Die immediately, no exit hook, no abort hook, no cleanup. > void os::die() { > - _exit(-1); > + ::abort(); // dump core (for debugging) > } > > From david.holmes at oracle.com Fri Feb 8 05:54:04 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 08 Feb 2013 23:54:04 +1000 Subject: RFR (S): 8007779: os::die() on solaris should generate core file In-Reply-To: References: Message-ID: <5115037C.8090705@oracle.com> My other email hasn't turned up yet but I was confusing this with the change that added the dump_core flag to os::abort. It's only by "accident" that we use ::abort on linux - _exit didn't work back in the old days of LinuxThreads :) This seems like a simple and potentially useful change, but I have a feeling it may have some unexpected consequences somewhere. :) Actually one possible consequence - what return code will the process issue if it now hits this? Could this impact testing and failure matching ? David On 8/02/2013 10:24 PM, Staffan Larsen wrote: > This is a request for review of a small change to the crash reporting on solaris. > > When hotspot crashes during the writing of the hs_err file, we call os::die(). On linux and bsd this causes a core file to be written (by calling ::abort()). This is good since we then have some record of what went wrong. On solaris, we call _exit() and no core file is created. > > There are two cases during the hs_err writing where we call os::die(). First, if the writing hangs, the WatcherThread will call os::die(). Second, if we get too many errors during the writing we will call os::die(). In both these cases it would be very helpful to have a core file. Otherwise all you have to go on is something like this: > > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0xffffffff653848c0, pid=11823, tid=240 > # > # JRE version: Java(TM) SE Runtime Environment (7.0_12-b11) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b24 mixed mode solaris-sparc compressed oops) > # Problematic frame: > # C [libc.so.1+0x848c0]# [ timer expired, abort... ] > > Below is the change I would like to do. > > Thanks, > /Staffan > > > diff --git a/src/os/solaris/vm/os_solaris.cpp b/src/os/solaris/vm/os_solaris.cpp > --- a/src/os/solaris/vm/os_solaris.cpp > +++ b/src/os/solaris/vm/os_solaris.cpp > @@ -1865,7 +1865,7 @@ > > // Die immediately, no exit hook, no abort hook, no cleanup. > void os::die() { > - _exit(-1); > + ::abort(); // dump core (for debugging) > } > > From staffan.larsen at oracle.com Fri Feb 8 06:05:45 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 8 Feb 2013 15:05:45 +0100 Subject: RFR (S): 8007779: os::die() on solaris should generate core file In-Reply-To: <5115037C.8090705@oracle.com> References: <5115037C.8090705@oracle.com> Message-ID: The return code from the process seems to be 134 (after an experiment). This would be the same as after a successful printing of hs_err when we do manage to create a core dump. /Staffan On 8 feb 2013, at 14:54, David Holmes wrote: > My other email hasn't turned up yet but I was confusing this with the change that added the dump_core flag to os::abort. > > It's only by "accident" that we use ::abort on linux - _exit didn't work back in the old days of LinuxThreads :) > > This seems like a simple and potentially useful change, but I have a feeling it may have some unexpected consequences somewhere. :) > > Actually one possible consequence - what return code will the process issue if it now hits this? Could this impact testing and failure matching ? > > David > > On 8/02/2013 10:24 PM, Staffan Larsen wrote: >> This is a request for review of a small change to the crash reporting on solaris. >> >> When hotspot crashes during the writing of the hs_err file, we call os::die(). On linux and bsd this causes a core file to be written (by calling ::abort()). This is good since we then have some record of what went wrong. On solaris, we call _exit() and no core file is created. >> >> There are two cases during the hs_err writing where we call os::die(). First, if the writing hangs, the WatcherThread will call os::die(). Second, if we get too many errors during the writing we will call os::die(). In both these cases it would be very helpful to have a core file. Otherwise all you have to go on is something like this: >> >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0xffffffff653848c0, pid=11823, tid=240 >> # >> # JRE version: Java(TM) SE Runtime Environment (7.0_12-b11) >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b24 mixed mode solaris-sparc compressed oops) >> # Problematic frame: >> # C [libc.so.1+0x848c0]# [ timer expired, abort... ] >> >> Below is the change I would like to do. >> >> Thanks, >> /Staffan >> >> >> diff --git a/src/os/solaris/vm/os_solaris.cpp b/src/os/solaris/vm/os_solaris.cpp >> --- a/src/os/solaris/vm/os_solaris.cpp >> +++ b/src/os/solaris/vm/os_solaris.cpp >> @@ -1865,7 +1865,7 @@ >> >> // Die immediately, no exit hook, no abort hook, no cleanup. >> void os::die() { >> - _exit(-1); >> + ::abort(); // dump core (for debugging) >> } >> >> From jon.masamitsu at oracle.com Fri Feb 8 06:59:39 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 08 Feb 2013 06:59:39 -0800 Subject: CFV: New hotspot Group Member: Bengt Rutisson In-Reply-To: <20756.2119.61953.313096@oracle.com> References: <20756.2119.61953.313096@oracle.com> Message-ID: <511512DB.5090602@oracle.com> Vote: yes On 2/7/2013 12:02 PM, John Coomes wrote: > I hereby nominate Bengt Rutisson to Membership in the hotspot Group. > > Bengt is an Oracle engineer and has been working on HotSpot for more > than two years; prior to that he worked on the jrockit JVM. He is a > Reviewer for the hsx Project and has contributed more than 50 HotSpot > changes, primarily relating to the G1 collector. > > Votes are due by 7:00 PM Thursday, February 21, 2013 UTC [1]. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > John Coomes, hotspot Group Lead > > [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Bengt+Rutisson&iso=20130221T19 > [2] http://openjdk.java.net/census/#hotspot > [3] http://openjdk.java.net/groups/#member-vote From jon.masamitsu at oracle.com Fri Feb 8 06:59:58 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 08 Feb 2013 06:59:58 -0800 Subject: CFV: New hotspot Group Member: Stefan Karlsson In-Reply-To: <20756.2182.166418.194006@oracle.com> References: <20756.2182.166418.194006@oracle.com> Message-ID: <511512EE.1040906@oracle.com> Vote: yes On 2/7/2013 12:03 PM, John Coomes wrote: > I hereby nominate Stefan Karlsson to Membership in the hotspot Group. > > In addition to his earlier experience developing the jrockit JVM, > Stefan has been working on the HotSpot JVM at Oracle for more than two > years. He has contributed several dozen HotSpot changes, and was a > key contributor to the project to remove the permanent generation. He > is a Reviewer for the hsx Project and a Committer for the jdk8, jdk7u > and jdk6 Projects. > > Votes are due by 7:00 PM Thursday, February 21, 2013 UTC [1]. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > John Coomes, hotspot Group Lead > > [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Stefan+Karlsson&iso=20130221T19 > [2] http://openjdk.java.net/census/#hotspot > [3] http://openjdk.java.net/groups/#member-vote From mikael.gerdin at oracle.com Fri Feb 8 07:12:13 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 08 Feb 2013 16:12:13 +0100 Subject: RFR (S): 8007779: os::die() on solaris should generate core file In-Reply-To: References: <5115037C.8090705@oracle.com> Message-ID: <511515CD.2090406@oracle.com> On 2013-02-08 15:05, Staffan Larsen wrote: > The return code from the process seems to be 134 (after an experiment). This would be the same as after a successful printing of hs_err when we do manage to create a core dump. When a posix process is terminated by an uncaught fatal signal the exit code is usually 128 + SIGNAL Since SIGABRT == 6 you got 134 /Mikael > > /Staffan > > On 8 feb 2013, at 14:54, David Holmes wrote: > >> My other email hasn't turned up yet but I was confusing this with the change that added the dump_core flag to os::abort. >> >> It's only by "accident" that we use ::abort on linux - _exit didn't work back in the old days of LinuxThreads :) >> >> This seems like a simple and potentially useful change, but I have a feeling it may have some unexpected consequences somewhere. :) >> >> Actually one possible consequence - what return code will the process issue if it now hits this? Could this impact testing and failure matching ? >> >> David >> >> On 8/02/2013 10:24 PM, Staffan Larsen wrote: >>> This is a request for review of a small change to the crash reporting on solaris. >>> >>> When hotspot crashes during the writing of the hs_err file, we call os::die(). On linux and bsd this causes a core file to be written (by calling ::abort()). This is good since we then have some record of what went wrong. On solaris, we call _exit() and no core file is created. >>> >>> There are two cases during the hs_err writing where we call os::die(). First, if the writing hangs, the WatcherThread will call os::die(). Second, if we get too many errors during the writing we will call os::die(). In both these cases it would be very helpful to have a core file. Otherwise all you have to go on is something like this: >>> >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # SIGSEGV (0xb) at pc=0xffffffff653848c0, pid=11823, tid=240 >>> # >>> # JRE version: Java(TM) SE Runtime Environment (7.0_12-b11) >>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b24 mixed mode solaris-sparc compressed oops) >>> # Problematic frame: >>> # C [libc.so.1+0x848c0]# [ timer expired, abort... ] >>> >>> Below is the change I would like to do. >>> >>> Thanks, >>> /Staffan >>> >>> >>> diff --git a/src/os/solaris/vm/os_solaris.cpp b/src/os/solaris/vm/os_solaris.cpp >>> --- a/src/os/solaris/vm/os_solaris.cpp >>> +++ b/src/os/solaris/vm/os_solaris.cpp >>> @@ -1865,7 +1865,7 @@ >>> >>> // Die immediately, no exit hook, no abort hook, no cleanup. >>> void os::die() { >>> - _exit(-1); >>> + ::abort(); // dump core (for debugging) >>> } >>> >>> > From zhengyu.gu at oracle.com Fri Feb 8 08:00:17 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 08 Feb 2013 11:00:17 -0500 Subject: Code review request: 8006691: Remove jvm_version_info.is_kernel_jvm field Message-ID: <51152111.3030100@oracle.com> This is a simple change to remove is_kernel_jvm field in jvm_version_info structure. The CCC request has been approved, as KERNEL VM has been deprecated since JDK7. JBS: https://jbs.oracle.com/bugs/browse/JDK-8006691 Webrev: http://cr.openjdk.java.net/~zgu/8006691/webrev.00/ Thanks, -Zhengyu From mikael.vidstedt at oracle.com Fri Feb 8 08:04:54 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 08 Feb 2013 08:04:54 -0800 Subject: RFR (S): 8007779: os::die() on solaris should generate core file In-Reply-To: <511515CD.2090406@oracle.com> References: <5115037C.8090705@oracle.com> <511515CD.2090406@oracle.com> Message-ID: <51152226.7070608@oracle.com> On 2013-02-08 07:12, Mikael Gerdin wrote: > On 2013-02-08 15:05, Staffan Larsen wrote: >> The return code from the process seems to be 134 (after an >> experiment). This would be the same as after a successful printing of >> hs_err when we do manage to create a core dump. > > When a posix process is terminated by an uncaught fatal signal the > exit code is usually 128 + SIGNAL > Since SIGABRT == 6 you got 134 I believe the 128+n may be for bash specifically, not for general posix processes, but the same conclusion goes. /Another Mikael > > /Mikael > >> >> /Staffan >> >> On 8 feb 2013, at 14:54, David Holmes wrote: >> >>> My other email hasn't turned up yet but I was confusing this with >>> the change that added the dump_core flag to os::abort. >>> >>> It's only by "accident" that we use ::abort on linux - _exit didn't >>> work back in the old days of LinuxThreads :) >>> >>> This seems like a simple and potentially useful change, but I have a >>> feeling it may have some unexpected consequences somewhere. :) >>> >>> Actually one possible consequence - what return code will the >>> process issue if it now hits this? Could this impact testing and >>> failure matching ? >>> >>> David >>> >>> On 8/02/2013 10:24 PM, Staffan Larsen wrote: >>>> This is a request for review of a small change to the crash >>>> reporting on solaris. >>>> >>>> When hotspot crashes during the writing of the hs_err file, we call >>>> os::die(). On linux and bsd this causes a core file to be written >>>> (by calling ::abort()). This is good since we then have some record >>>> of what went wrong. On solaris, we call _exit() and no core file is >>>> created. >>>> >>>> There are two cases during the hs_err writing where we call >>>> os::die(). First, if the writing hangs, the WatcherThread will call >>>> os::die(). Second, if we get too many errors during the writing we >>>> will call os::die(). In both these cases it would be very helpful >>>> to have a core file. Otherwise all you have to go on is something >>>> like this: >>>> >>>> # A fatal error has been detected by the Java Runtime Environment: >>>> # >>>> # SIGSEGV (0xb) at pc=0xffffffff653848c0, pid=11823, tid=240 >>>> # >>>> # JRE version: Java(TM) SE Runtime Environment (7.0_12-b11) >>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b24 mixed mode >>>> solaris-sparc compressed oops) >>>> # Problematic frame: >>>> # C [libc.so.1+0x848c0]# [ timer expired, abort... ] >>>> >>>> Below is the change I would like to do. >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>> diff --git a/src/os/solaris/vm/os_solaris.cpp >>>> b/src/os/solaris/vm/os_solaris.cpp >>>> --- a/src/os/solaris/vm/os_solaris.cpp >>>> +++ b/src/os/solaris/vm/os_solaris.cpp >>>> @@ -1865,7 +1865,7 @@ >>>> >>>> // Die immediately, no exit hook, no abort hook, no cleanup. >>>> void os::die() { >>>> - _exit(-1); >>>> + ::abort(); // dump core (for debugging) >>>> } >>>> >>>> >> From nils.loodin at oracle.com Fri Feb 8 08:40:00 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Fri, 08 Feb 2013 17:40:00 +0100 Subject: RFR: JDK-8007804: Need to be able to access Performance counter by name from JVM Message-ID: <51152A60.8000004@oracle.com> Please review the following very small and insignificant change: Basically, I need to access a performance-counter by name from within the JVM. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007804 http://cr.openjdk.java.net/~nloodin/8007804/webrev.00/ Regards, Nils Loodin From aleksey.shipilev at oracle.com Fri Feb 8 08:45:38 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 08 Feb 2013 20:45:38 +0400 Subject: RFR (XXS) CR 8006997: ContendedPaddingWidth should be uintx In-Reply-To: <5114FDF3.6040102@oracle.com> References: <510668D1.5070002@oracle.com> <51109FF5.6020804@oracle.com> <51125B90.6030404@oracle.com> <51128906.3000302@oracle.com> <5112EAA0.5050303@oracle.com> <51135D48.9040002@oracle.com> <51136C02.3080700@oracle.com> <5114D5E8.90000@oracle.com> <5114FC03.8010906@oracle.com> <5114FDF3.6040102@oracle.com> Message-ID: <51152BB2.6060300@oracle.com> On 02/08/2013 05:30 PM, Aleksey Shipilev wrote: > On 02/08/2013 05:22 PM, David Holmes wrote: >> On 8/02/2013 8:39 PM, Aleksey Shipilev wrote: >>> Ok then. This is the new webrev: >>> http://cr.openjdk.java.net/~shade/8006997/webrev.01/ >>> >>> I haven't found another good place to stick the guarantee() to, so opted >>> to stick it before the actual use. I would be happy to stick it >>> somewhere else where the options are generally checked, but found no >>> non-platform/non-OS specific location. >> >> arguments.cpp - Arguments::parse_each_vm_init_arg - see >> -XX:MaxDirectMemorySize as an example. > > Ok, great, thanks! I will update the webrev and give it another jprt spin. Here's the update: http://cr.openjdk.java.net/~shade/8006997/webrev.02/ Testing: a) ad-hoc fastdebug build with negative value b) JPRT/Hotspot full cycle -Aleksey. From dean.long at oracle.com Fri Feb 8 10:21:56 2013 From: dean.long at oracle.com (Dean Long) Date: Fri, 08 Feb 2013 10:21:56 -0800 Subject: RFR (S): 8007779: os::die() on solaris should generate core file In-Reply-To: <51152226.7070608@oracle.com> References: <5115037C.8090705@oracle.com> <511515CD.2090406@oracle.com> <51152226.7070608@oracle.com> Message-ID: <51154244.8030209@oracle.com> The 0x80 bit should be part of the value returned by wait(2), but it may be shell-specific which bits are captured by $?. dl On 2/8/2013 8:04 AM, Mikael Vidstedt wrote: > On 2013-02-08 07:12, Mikael Gerdin wrote: >> On 2013-02-08 15:05, Staffan Larsen wrote: >>> The return code from the process seems to be 134 (after an >>> experiment). This would be the same as after a successful printing >>> of hs_err when we do manage to create a core dump. >> >> When a posix process is terminated by an uncaught fatal signal the >> exit code is usually 128 + SIGNAL >> Since SIGABRT == 6 you got 134 > > I believe the 128+n may be for bash specifically, not for general > posix processes, but the same conclusion goes. > > /Another Mikael > >> >> /Mikael >> >>> >>> /Staffan >>> >>> On 8 feb 2013, at 14:54, David Holmes wrote: >>> >>>> My other email hasn't turned up yet but I was confusing this with >>>> the change that added the dump_core flag to os::abort. >>>> >>>> It's only by "accident" that we use ::abort on linux - _exit didn't >>>> work back in the old days of LinuxThreads :) >>>> >>>> This seems like a simple and potentially useful change, but I have >>>> a feeling it may have some unexpected consequences somewhere. :) >>>> >>>> Actually one possible consequence - what return code will the >>>> process issue if it now hits this? Could this impact testing and >>>> failure matching ? >>>> >>>> David >>>> >>>> On 8/02/2013 10:24 PM, Staffan Larsen wrote: >>>>> This is a request for review of a small change to the crash >>>>> reporting on solaris. >>>>> >>>>> When hotspot crashes during the writing of the hs_err file, we >>>>> call os::die(). On linux and bsd this causes a core file to be >>>>> written (by calling ::abort()). This is good since we then have >>>>> some record of what went wrong. On solaris, we call _exit() and no >>>>> core file is created. >>>>> >>>>> There are two cases during the hs_err writing where we call >>>>> os::die(). First, if the writing hangs, the WatcherThread will >>>>> call os::die(). Second, if we get too many errors during the >>>>> writing we will call os::die(). In both these cases it would be >>>>> very helpful to have a core file. Otherwise all you have to go on >>>>> is something like this: >>>>> >>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>> # >>>>> # SIGSEGV (0xb) at pc=0xffffffff653848c0, pid=11823, tid=240 >>>>> # >>>>> # JRE version: Java(TM) SE Runtime Environment (7.0_12-b11) >>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b24 mixed mode >>>>> solaris-sparc compressed oops) >>>>> # Problematic frame: >>>>> # C [libc.so.1+0x848c0]# [ timer expired, abort... ] >>>>> >>>>> Below is the change I would like to do. >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> >>>>> diff --git a/src/os/solaris/vm/os_solaris.cpp >>>>> b/src/os/solaris/vm/os_solaris.cpp >>>>> --- a/src/os/solaris/vm/os_solaris.cpp >>>>> +++ b/src/os/solaris/vm/os_solaris.cpp >>>>> @@ -1865,7 +1865,7 @@ >>>>> >>>>> // Die immediately, no exit hook, no abort hook, no cleanup. >>>>> void os::die() { >>>>> - _exit(-1); >>>>> + ::abort(); // dump core (for debugging) >>>>> } >>>>> >>>>> >>> > From mikael.vidstedt at oracle.com Fri Feb 8 10:30:04 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 08 Feb 2013 10:30:04 -0800 Subject: RFR (S): 8007639: Workaround for ccache in vm.make is incorrect Message-ID: <5115442C.5030309@oracle.com> Please review the following change: Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8007639/webrev.00/webrev Bug: http://bugs.sun.com/view_bug.do?bug_id=8007639 This change corrects the workaround that was introduced in vm.make for enabling ccache for HotSpot builds. The change introduces a file specific makefile variable (CFLAGS/) which is used to only set the JRE_RELEASE_VERSION define when compiling vm_version.o. Verified manually by observing command lines with/without fix, also passes JPRT. Some additional background below, more information is available in the bug report: To enable the use of ccache 7132779 [1] introduced some new makefile logic in vm.make to only pass the JRE_RELEASE_VERSION define when compiling the vm_version.cpp file. The underlying reason for that is that the JRE_RELEASE_VERSION can in some cases contain a time stamp and since ccache checks that the defines match before reusing the cache version of the object file that would mean that if the time stamp changed all files would have to be recompiled. With the fix only vm_version.cpp needs to be recompiled. This almost works, but the logic introduced in the makefile is actually incorrect. Today it looks like this: # This is VERY important! The version define must only be supplied to vm_version.o # If not, ccache will not re-use the cache at all, since the version string might contain # a time and date. vm_version.o: CXXFLAGS += ${JRE_VERSION} However, the above syntax does not only add the ${JRE_VERSION} to the CXXFLAGS of vm_version.o as originally intended - it also /in some cases/ adds it to the CXXFLAGS for any and all prerequisites of vm_version.o. And vm_version.o depends on all other object files, which means in theory this actually passes in that potentially time stamped version string define to all object files anyway. For various reasons in reality it only passes it to files that are lexicographically after vm_version.o - see bug report for more background on why - but there's still a handful of files that will be recompiled unnecessarily. Cheers, Mikael [1] http://bugs.sun.com/view_bug.do?bug_id=7132779 From coleen.phillimore at oracle.com Fri Feb 8 10:42:56 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 08 Feb 2013 13:42:56 -0500 Subject: Result: New Hotspot Reviewer: Zhengyu Gu Message-ID: <51154730.7020908@oracle.com> | |Voting for Zhengyu Gu [1] is now closed. Yes: 8 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination.| Coleen Phillimore || [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-January/008111.html | From alejandro.murillo at oracle.com Fri Feb 8 11:15:16 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 08 Feb 2013 19:15:16 +0000 Subject: hg: hsx/hsx25/hotspot: 75 new changesets Message-ID: <20130208191742.E169047956@hg.openjdk.java.net> Changeset: 20b605466ccb Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/20b605466ccb Added tag jdk8-b75 for changeset 6778d0b16593 ! .hgtags Changeset: da53cb17186a Author: katleman Date: 2013-02-07 12:32 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/da53cb17186a Added tag jdk8-b76 for changeset 20b605466ccb ! .hgtags Changeset: 6fbe8a57549d Author: amurillo Date: 2013-01-25 03:03 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6fbe8a57549d 8006827: new hotspot build - hs25-b18 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 3c327c2b6782 Author: jmasa Date: 2013-01-03 15:03 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3c327c2b6782 8004895: NPG: JMapPermCore test failure caused by warnings about missing field Reviewed-by: johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ef1e11845e18 Author: jmasa Date: 2013-02-04 12:01 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ef1e11845e18 Merge ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 5daaddd917a1 Author: coleenp Date: 2013-01-23 10:34 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5daaddd917a1 8006040: NPG: on_stack processing wastes space in ConstantPool Summary: Added on_stack bit to flags. Also MetadataMarkOnStack is used for more than JVMTI so had to be moved. Reviewed-by: dholmes, stefank ! src/share/vm/classfile/classLoaderData.cpp + src/share/vm/classfile/metadataOnStackMark.cpp + src/share/vm/classfile/metadataOnStackMark.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp Changeset: 6cf2530f7fd3 Author: minqi Date: 2013-01-24 23:30 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6cf2530f7fd3 8005278: Serviceability Agent: jmap -heap and jstack -m fail Summary: BinaryTreeDictionary is typedef'ed as AFLBinaryTreeDictionary in vmStructs and in SA we still use old name for that. FreeList now is a template based class which is not reflect in SA type library. When SA does calculation of heap for CMS, the former will cause failure to retrieve BinaryTreeDictionary sine the rename. The later will fail wherever it is used in SA. Reviewed-by: dholmes, sla, coleenp Contributed-by: yunda.mly at taobao.com + agent/src/share/classes/sun/jvm/hotspot/memory/AFLBinaryTreeDictionary.java - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp Changeset: 8b46b0196eb0 Author: zgu Date: 2013-01-25 10:04 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8b46b0196eb0 8000692: Remove old KERNEL code Summary: Removed depreciated kernel VM source code from hotspot VM Reviewed-by: dholmes, acorn ! make/Makefile ! make/bsd/makefiles/dtrace.make ! make/solaris/Makefile ! make/solaris/makefiles/dtrace.make - make/solaris/makefiles/kernel.make ! make/windows/build.bat ! make/windows/create_obj_files.sh ! make/windows/makefiles/defs.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! src/cpu/x86/vm/assembler_x86.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jniCheck.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.hpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExtensions.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiRawMonitor.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/attachListener.hpp Changeset: edd76a5856f7 Author: sspitsyn Date: 2013-01-24 22:13 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/edd76a5856f7 8005128: JSR 292: the mlvm redefineClassInBootstrap test crashes in ConstantPool::compare_entry_to Summary: When constant pool is copied in merge_constant_pools the invokedynamic operands must be copied before. Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 4a0dd3799a44 Author: minqi Date: 2013-01-25 04:23 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4a0dd3799a44 Merge Changeset: 8d1fb417a42d Author: minqi Date: 2013-01-25 13:47 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8d1fb417a42d Merge ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: cf8470eaf7e5 Author: acorn Date: 2013-01-27 21:58 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cf8470eaf7e5 Merge - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java - make/solaris/makefiles/kernel.make ! src/cpu/x86/vm/assembler_x86.hpp ! src/share/vm/classfile/vmSymbols.hpp Changeset: 16fb9f942703 Author: acorn Date: 2013-01-25 15:06 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/16fb9f942703 6479360: PrintClassHistogram improvements Summary: jcmd GC.class_stats (UnlockDiagnosticVMOptions) Reviewed-by: coleenp, hseigel, sla, acorn Contributed-by: ioi.lam at oracle.com ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/annotations.hpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: 0d26ce8e9251 Author: acorn Date: 2013-01-28 10:34 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0d26ce8e9251 Merge - make/solaris/makefiles/kernel.make ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp Changeset: 815957d0203e Author: acorn Date: 2013-01-28 10:55 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/815957d0203e 8004967: Default method cause VerifyError: Illegal use of nonvirtual Summary: Recognize VM generated method in old verifier Reviewed-by: acorn, coleenp Contributed-by: bharadwaj.yadavelli at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 7885e162c30f Author: acorn Date: 2013-01-28 09:33 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7885e162c30f Merge Changeset: 9be6cde7919d Author: ctornqvi Date: 2013-01-25 10:14 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9be6cde7919d 8006413: Add utility classes for writing better multiprocess tests in jtreg Summary: Add a few utility classes to test/testlibrary to support multi process testing in jtreg tests. Added a test case for one of the utility classes. Also reviewed by Vitaly Davidovich Reviewed-by: brutisso, dholmes, vlivanov, nloodin, mgerdin + test/testlibrary/OutputAnalyzerTest.java + test/testlibrary/com/oracle/java/testlibrary/JDKToolFinder.java + test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java + test/testlibrary/com/oracle/java/testlibrary/OutputBuffer.java + test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java + test/testlibrary/com/oracle/java/testlibrary/StreamPumper.java Changeset: baf7fac3167e Author: hseigel Date: 2013-02-01 14:14 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/baf7fac3167e 8006298: Specifying malformed JFR options (-XX:+FlightRecorderOptions) outputs non-sensical error Summary: Change error messages for malformed options so the messages are more useful. Reviewed-by: mikael, kvn, nloodin ! src/share/vm/runtime/arguments.cpp Changeset: 4c75576d18d0 Author: hseigel Date: 2013-02-01 13:30 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4c75576d18d0 Merge Changeset: 9bf5f643d1cf Author: sspitsyn Date: 2013-01-31 20:07 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9bf5f643d1cf 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds Summary: Need a support for invokedynamic entry kinds when new and old constant pools are merged. Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp Changeset: dc31f560d6e7 Author: sspitsyn Date: 2013-01-31 20:09 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dc31f560d6e7 8006546: JSR 292: typos in the ConstantPool::copy_cp_impl() Summary: Simple typos that need to be fixed Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/oops/constantPool.cpp Changeset: 79c1bb8fce5d Author: sspitsyn Date: 2013-01-31 20:11 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/79c1bb8fce5d 8006731: JSR 292: the VM_RedefineClasses::rewrite_cp_refs_in_method() must support invokedynamic Summary: The invokedynamic bytecode ref to a CP entry needs to be checked and fixed as well. Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 9a9f870325cf Author: minqi Date: 2013-02-01 10:57 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9a9f870325cf Merge Changeset: b935589d2807 Author: minqi Date: 2013-02-01 14:42 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b935589d2807 Merge Changeset: 44c5fcd9cb25 Author: iklam Date: 2013-01-24 10:57 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/44c5fcd9cb25 8006280: Need to reorder metadata structures to reduce size (64-bit) Summary: Reordered Klass, InstanceKlass and Method to save 8 bytes each Reviewed-by: coleenp, jiangli Contributed-by: ioi.lam at oracle.com ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.hpp Changeset: 1eae78177059 Author: jiangli Date: 2013-02-01 15:25 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1eae78177059 Merge - make/solaris/makefiles/kernel.make ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.hpp Changeset: dc8ad3fd7050 Author: jiangli Date: 2013-02-01 19:36 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dc8ad3fd7050 Merge Changeset: 4102b59539ce Author: ctornqvi Date: 2013-02-01 23:48 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4102b59539ce 8005012: Add WB APIs to better support NMT testing Summary: Add WB API functions to enable better NMT testing Reviewed-by: dholmes, zgu ! src/share/tools/whitebox/sun/hotspot/WhiteBox.java ! src/share/vm/memory/allocation.hpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memPtr.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 4460acf8687b Author: ctornqvi Date: 2013-02-02 07:24 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4460acf8687b Merge Changeset: 9fe95b01ad32 Author: ctornqvi Date: 2013-02-02 08:46 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9fe95b01ad32 Merge Changeset: 43badbe2717a Author: minqi Date: 2013-01-31 17:43 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/43badbe2717a 8000973: SA on windows thread inspection is broken Summary: After bug 7161732, On Windows SA could not find correct address of thread_id of OSThread since _thread_id moved to end of the class . The presupposition of the address is following thread handle no longer stands. Fix by adding thread_id field to OSThread and getting the address directly from OSThread. Reviewed-by: nloodin, sspitsyn Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/amd64/WindbgAMD64Thread.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/x86/WindbgX86Thread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/OSThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/win32_amd64/Win32AMD64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/win32_x86/Win32X86JavaThreadPDAccess.java Changeset: 65b632b77a97 Author: minqi Date: 2013-02-01 22:41 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/65b632b77a97 Merge Changeset: ff5401ad5635 Author: minqi Date: 2013-02-02 03:51 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ff5401ad5635 Merge Changeset: 879c6de913d6 Author: ctornqvi Date: 2013-02-02 16:34 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/879c6de913d6 8005013: Add NMT tests Summary: Add tests for the Native Memory Tracking feature, includes regression tests for 8005936 and 8004802 Reviewed-by: zgu, coleenp ! test/TEST.ROOT + test/runtime/NMT/AllocTestType.java + test/runtime/NMT/BaselineWithParameter.java + test/runtime/NMT/CommandLineDetail.java + test/runtime/NMT/CommandLineEmptyArgument.java + test/runtime/NMT/CommandLineInvalidArgument.java + test/runtime/NMT/CommandLineSummary.java + test/runtime/NMT/CommandLineTurnOffNMT.java + test/runtime/NMT/JcmdScale.java + test/runtime/NMT/JcmdWithNMTDisabled.java + test/runtime/NMT/PrintNMTStatistics.java + test/runtime/NMT/PrintNMTStatisticsWithNMTDisabled.java + test/runtime/NMT/ShutdownTwice.java + test/runtime/NMT/SummaryAfterShutdown.java + test/runtime/NMT/SummarySanityCheck.java Changeset: a7f9a1195d86 Author: ctornqvi Date: 2013-02-02 20:13 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a7f9a1195d86 8000363: runtime/7158988/FieldMonitor.java fails with exception Summary: Removed unnecessary shell script in the test. Reviewed-by: coleenp, sla ! test/runtime/7158988/FieldMonitor.java - test/runtime/7158988/TestFieldMonitor.sh Changeset: 8f696cf1a0fb Author: dsamersoff Date: 2013-02-03 22:28 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8f696cf1a0fb 8002048: Protocol to discovery of manageable Java processes on a network Summary: Introduce a protocol to discover manageble Java instances across a network subnet, JDP Reviewed-by: sla, dfuchs ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: c4ef3380a70b Author: hseigel Date: 2013-02-03 16:49 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c4ef3380a70b 7197672: There are issues with shared data on windows Summary: On Windows, set rw protection on the CDS file just before removing it. Reviewed-by: dcubed, iklam ! src/share/vm/memory/filemap.cpp Changeset: ce5467120c84 Author: hseigel Date: 2013-02-03 17:12 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ce5467120c84 Merge Changeset: 10d5f25a7c67 Author: hseigel Date: 2013-02-04 08:26 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/10d5f25a7c67 8000968: NPG: UseCompressedKlassPointers asserts with ObjectAlignmentInBytes for > 32G CompressedOops Summary: Pick a base that works for both CompressedOpps alignment and CompressedKlassPtrs alignment. Reviewed-by: kvn, roland ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/runtime/arguments.cpp + test/runtime/8000968/Test8000968.sh Changeset: 24a91505f9d5 Author: emc Date: 2013-02-04 13:05 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/24a91505f9d5 8006949: Update hotspot for MethodParameters format change 8006907: Hotspot should reject classfiles with multiple MethodParameters attributes Summary: Update to Hotspot's processing of MethodParameters attributes in classfiles Reviewed-by: coleenp, jrose ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/prims/jvm.cpp Changeset: 42ea5e1fad75 Author: coleenp Date: 2013-02-04 13:51 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/42ea5e1fad75 Merge Changeset: ab826603e572 Author: simonis Date: 2013-02-04 13:14 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ab826603e572 8007475: Memory stomp with UseMallocOnly Summary: Fix off-by-one error Reviewed-by: coleenp, hseigel ! src/share/vm/classfile/stackMapFrame.hpp + test/runtime/8007475/StackMapFrameTest.java Changeset: a401757763f9 Author: coleenp Date: 2013-02-04 22:59 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a401757763f9 Merge Changeset: 12285410684f Author: dholmes Date: 2013-02-04 23:53 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/12285410684f 8006508: Wrong frame constructor is called in os_linux_x86.cpp Reviewed-by: dholmes, coleenp Contributed-by: Jeremy Manson ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp Changeset: f3ea1af9207a Author: dholmes Date: 2013-02-05 00:59 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f3ea1af9207a Merge Changeset: 454d7cc622ab Author: dcubed Date: 2013-02-06 15:22 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/454d7cc622ab Merge - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java - make/solaris/makefiles/kernel.make ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp - test/runtime/7158988/TestFieldMonitor.sh Changeset: fcc9e7681d63 Author: vlivanov Date: 2013-02-01 02:50 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fcc9e7681d63 8006410: allocating without ResourceMark when CompileCommand was specified Reviewed-by: kvn, vlivanov Contributed-by: Igor Ignatyev ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/oops/symbol.cpp Changeset: 60bba1398c51 Author: vlivanov Date: 2013-02-01 03:02 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/60bba1398c51 8005439: no message about inline method if it specifed by CompileCommand Reviewed-by: kvn, vlivanov Contributed-by: Igor Ignatyev ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/parse.hpp Changeset: e4bb0bda20a4 Author: morris Date: 2013-01-25 16:31 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e4bb0bda20a4 8005811: Turn off TierdCompilation in JDK8 trunk for all platforms Summary: Disable tiered compilation in jdk8 because of CodeCache and performance anomalies Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp Changeset: 76341426b645 Author: drchase Date: 2013-01-25 16:09 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/76341426b645 8006500: compiler/8004741/Test8004741.java fails intermediately Summary: rewrote the test to be more reliable, add test for invalid size exception Reviewed-by: kvn ! test/compiler/8004741/Test8004741.java Changeset: 9fae07c31641 Author: morris Date: 2013-01-25 16:50 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9fae07c31641 6518907: cleanup IA64 specific code in Hotspot Summary: removed unused IA64 specific code Reviewed-by: twisti, kvn, dholmes ! agent/src/os/linux/LinuxDebuggerLocal.c ! agent/src/os/linux/libproc.h ! agent/src/os/win32/windbg/sawindbg.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/vframeArray.cpp Changeset: 37c18711a0df Author: roland Date: 2013-02-04 09:11 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/37c18711a0df 8005114: VM is crashing in ciKlass*ciObjArrayKlass::element_klass() if metaspaces are full Summary: missing test for loaded klass in c1 Reviewed-by: kvn ! src/share/vm/c1/c1_Instruction.cpp Changeset: 39901f2f1abe Author: mikael Date: 2013-02-04 10:28 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/39901f2f1abe 8007403: Incorrect format arguments in adlparse.cpp Reviewed-by: kvn, twisti ! src/share/vm/adlc/adlparse.cpp Changeset: 8bd61471a109 Author: roland Date: 2013-02-04 11:30 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8bd61471a109 8007144: Incremental inlining mistakes some call sites for dead ones and doesn't inline them Summary: wrong detection for dead call sites. Reviewed-by: kvn ! src/share/vm/opto/callGenerator.cpp Changeset: 6a51fc70a15e Author: vlivanov Date: 2013-02-05 08:25 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6a51fc70a15e 8006613: adding reason to made_not_compilable Reviewed-by: kvn, vlivanov Contributed-by: Igor Ignatyev ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 4fcf990aa34a Author: drchase Date: 2013-02-06 11:33 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4fcf990aa34a 8006807: C2 crash due to out of bounds array access in Parse::do_multianewarray Summary: check ndimensions before accessing length[i] element Reviewed-by: kvn Contributed-by: volker.simonis at gmail.com ! src/share/vm/opto/parse3.cpp Changeset: d05ff4bf41b3 Author: vlivanov Date: 2013-02-07 12:23 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d05ff4bf41b3 Merge ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.hpp Changeset: db9981fd3124 Author: jprovino Date: 2013-01-23 13:02 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/db9981fd3124 8005915: Unify SERIALGC and INCLUDE_ALTERNATE_GCS Summary: Rename INCLUDE_ALTERNATE_GCS to INCLUDE_ALL_GCS and replace SERIALGC with INCLUDE_ALL_GCS. Reviewed-by: coleenp, stefank ! make/bsd/makefiles/minimal1.make ! make/excludeSrc.make ! make/linux/makefiles/minimal1.make ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/shared/allocationStats.cpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/gcAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/immutableSpace.cpp ! src/share/vm/gc_implementation/shared/isGCActiveMark.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/generationSpec.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/specialized_oop_closures.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/tenuredGeneration.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceClassLoaderKlass.cpp ! src/share/vm/oops/instanceClassLoaderKlass.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceMirrorKlass.cpp ! src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/instanceRefKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassPS.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/objArrayKlass.inline.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp ! src/share/vm/oops/oop.psgc.inline.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/classLoadingService.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/g1MemoryPool.hpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/memReporter.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/psMemoryPool.hpp ! src/share/vm/services/runtimeService.cpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/top.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 8391fdd36e1f Author: dlong Date: 2013-01-27 01:07 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8391fdd36e1f Merge ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/heapDumper.cpp Changeset: 3c9bc17b9403 Author: bpittore Date: 2013-02-07 16:05 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3c9bc17b9403 Merge ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: df8462fbe585 Author: vladidan Date: 2013-02-07 20:40 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/df8462fbe585 Merge ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: ec0c4951286c Author: stefank Date: 2013-01-29 10:51 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ec0c4951286c 8004710: NPG: jmap could throw sun.jvm.hotspot.types.WrongTypeException after PermGen removal Summary: When calculating live object regions, make sure that the alignment reserve, at the end of a TLAB, is excluded. Reviewed-by: jmasa, brutisso ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/runtime/vmStructs.cpp Changeset: 4700e77d44c1 Author: johnc Date: 2013-02-01 13:17 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4700e77d44c1 8006894: G1: Number of marking threads missing from PrintFlagsFinal output Summary: Set ConcGCThreads to the calculated number of marking threads. Reviewed-by: jmasa, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: d9058e388631 Author: mikael Date: 2013-02-01 17:21 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d9058e388631 8007257: NPG: metaspace.cpp: Incorrect arguments in calls to err_msg Summary: Fix size checks in assert and corrected some print formats. Also reviewed by vitalyd at gmail.com. Reviewed-by: coleenp, sspitsyn ! src/share/vm/memory/metaspace.cpp Changeset: 256d3f43c177 Author: johnc Date: 2013-01-31 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/256d3f43c177 8005875: G1: Kitchensink fails with ParallelGCThreads=0 Summary: Check that the concurrent marking worker gang exists in ConcurrentMark::print_worker_threads_on(). Changes were also reviewed by Vitaly Davidovich . Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 80518f4ecf32 Author: jmasa Date: 2013-02-04 12:51 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/80518f4ecf32 Merge ! src/share/vm/runtime/vmStructs.cpp Changeset: f2f0cf0f5444 Author: jmasa Date: 2013-02-04 13:26 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f2f0cf0f5444 Merge Changeset: 06fd03af6ce4 Author: johnc Date: 2013-02-04 13:24 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/06fd03af6ce4 8001384: G1: assert(!is_null(v)) failed: narrow oop value can never be zero Summary: Flush any deferred card mark before a Java thread exits. Reviewed-by: brutisso, jmasa ! src/share/vm/runtime/thread.cpp Changeset: 84304a77c4e3 Author: johnc Date: 2013-02-04 19:40 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/84304a77c4e3 Merge Changeset: 95ccff9eee8e Author: jwilhelm Date: 2013-01-28 15:41 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/95ccff9eee8e 6348447: Specifying -XX:OldSize crashes 64-bit VMs Summary: Heap size will be set to allow for OldSize to fit. Also reviewed by vitalyd at gmail.com Reviewed-by: ehelin, jmasa ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp Changeset: f90b9bceb8e5 Author: johnc Date: 2013-02-05 09:13 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f90b9bceb8e5 8005032: G1: Cleanup serial reference processing closures in concurrent marking Summary: Reuse the parallel reference processing oop closures during serial reference processing. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 50d3b37d5bcd Author: johnc Date: 2013-02-05 22:24 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/50d3b37d5bcd Merge Changeset: 1135141fb97e Author: brutisso Date: 2013-02-08 10:08 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1135141fb97e Merge ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 412d722168bc Author: amurillo Date: 2013-02-08 08:07 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/412d722168bc Merge - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java - make/solaris/makefiles/kernel.make - test/runtime/7158988/TestFieldMonitor.sh Changeset: cdb46031e718 Author: amurillo Date: 2013-02-08 08:07 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cdb46031e718 Added tag hs25-b18 for changeset 412d722168bc ! .hgtags From vladimir.kozlov at oracle.com Fri Feb 8 11:35:23 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 08 Feb 2013 11:35:23 -0800 Subject: RFR (XXS) CR 8006997: ContendedPaddingWidth should be uintx In-Reply-To: <51152BB2.6060300@oracle.com> References: <510668D1.5070002@oracle.com> <51109FF5.6020804@oracle.com> <51125B90.6030404@oracle.com> <51128906.3000302@oracle.com> <5112EAA0.5050303@oracle.com> <51135D48.9040002@oracle.com> <51136C02.3080700@oracle.com> <5114D5E8.90000@oracle.com> <5114FC03.8010906@oracle.com> <5114FDF3.6040102@oracle.com> <51152BB2.6060300@oracle.com> Message-ID: <5115537B.6000309@oracle.com> The final fix is good. Thanks, Vladimir On 2/8/13 8:45 AM, Aleksey Shipilev wrote: > On 02/08/2013 05:30 PM, Aleksey Shipilev wrote: >> On 02/08/2013 05:22 PM, David Holmes wrote: >>> On 8/02/2013 8:39 PM, Aleksey Shipilev wrote: >>>> Ok then. This is the new webrev: >>>> http://cr.openjdk.java.net/~shade/8006997/webrev.01/ >>>> >>>> I haven't found another good place to stick the guarantee() to, so opted >>>> to stick it before the actual use. I would be happy to stick it >>>> somewhere else where the options are generally checked, but found no >>>> non-platform/non-OS specific location. >>> >>> arguments.cpp - Arguments::parse_each_vm_init_arg - see >>> -XX:MaxDirectMemorySize as an example. >> >> Ok, great, thanks! I will update the webrev and give it another jprt spin. > > Here's the update: > http://cr.openjdk.java.net/~shade/8006997/webrev.02/ > > Testing: > a) ad-hoc fastdebug build with negative value > b) JPRT/Hotspot full cycle > > -Aleksey. > From coleen.phillimore at oracle.com Fri Feb 8 11:59:13 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 08 Feb 2013 14:59:13 -0500 Subject: Code review request: 8006691: Remove jvm_version_info.is_kernel_jvm field In-Reply-To: <51152111.3030100@oracle.com> References: <51152111.3030100@oracle.com> Message-ID: <51155911.2060807@oracle.com> Looks good. Coleen On 2/8/2013 11:00 AM, Zhengyu Gu wrote: > This is a simple change to remove is_kernel_jvm field in > jvm_version_info structure. The CCC request has been approved, as > KERNEL VM has been deprecated since JDK7. > > JBS: https://jbs.oracle.com/bugs/browse/JDK-8006691 > Webrev: http://cr.openjdk.java.net/~zgu/8006691/webrev.00/ > > Thanks, > > -Zhengyu > > From alejandro.murillo at oracle.com Fri Feb 8 13:00:04 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 08 Feb 2013 21:00:04 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20130208210016.93C054795D@hg.openjdk.java.net> Changeset: 20b605466ccb Author: katleman Date: 2013-01-31 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/20b605466ccb Added tag jdk8-b75 for changeset 6778d0b16593 ! .hgtags Changeset: da53cb17186a Author: katleman Date: 2013-02-07 12:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/da53cb17186a Added tag jdk8-b76 for changeset 20b605466ccb ! .hgtags Changeset: 412d722168bc Author: amurillo Date: 2013-02-08 08:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/412d722168bc Merge - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java - make/solaris/makefiles/kernel.make - test/runtime/7158988/TestFieldMonitor.sh Changeset: cdb46031e718 Author: amurillo Date: 2013-02-08 08:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cdb46031e718 Added tag hs25-b18 for changeset 412d722168bc ! .hgtags Changeset: 1a0174612b49 Author: amurillo Date: 2013-02-08 08:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a0174612b49 8007801: new hotspot build - hs25-b19 Reviewed-by: jcoomes ! make/hotspot_version From mandy.chung at oracle.com Fri Feb 8 13:18:56 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 08 Feb 2013 13:18:56 -0800 Subject: Code review request: 8006691: Remove jvm_version_info.is_kernel_jvm field In-Reply-To: <51152111.3030100@oracle.com> References: <51152111.3030100@oracle.com> Message-ID: <51156BC0.5050200@oracle.com> Zhengyu, This looks good to me too. Please also update the jvm.h in the jdk repo (src/share/javavm/export/jvm.h) - for historical reason, this is not an exact copy in the hotspot repo and we tend to apply the same patch rather than replacing it with the hotspot copy. BTW here is the public accessible link to the bug report: http://bugs.sun.com/view_bug.do?bug_id=8006691 Mandy On 2/8/2013 8:00 AM, Zhengyu Gu wrote: > This is a simple change to remove is_kernel_jvm field in > jvm_version_info structure. The CCC request has been approved, as > KERNEL VM has been deprecated since JDK7. > > JBS: https://jbs.oracle.com/bugs/browse/JDK-8006691 > Webrev: http://cr.openjdk.java.net/~zgu/8006691/webrev.00/ > > Thanks, > > -Zhengyu > > From zhengyu.gu at oracle.com Fri Feb 8 13:44:44 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 08 Feb 2013 16:44:44 -0500 Subject: Code review request: 8006691: Remove jvm_version_info.is_kernel_jvm field In-Reply-To: <51156BC0.5050200@oracle.com> References: <51152111.3030100@oracle.com> <51156BC0.5050200@oracle.com> Message-ID: <511571CC.1060003@oracle.com> Mandy, Thanks for reviewing. What's the process to update jvm.h in the jdk repo? it should go to both jdk7 and jdk8, which repos should I make the changes? Thanks, -Zhengyu On 2/8/2013 4:18 PM, Mandy Chung wrote: > Zhengyu, > > This looks good to me too. Please also update the jvm.h in the jdk > repo (src/share/javavm/export/jvm.h) - for historical reason, this is > not an exact copy in the hotspot repo and we tend to apply the same > patch rather than replacing it with the hotspot copy. > > BTW here is the public accessible link to the bug report: > http://bugs.sun.com/view_bug.do?bug_id=8006691 > > Mandy > > On 2/8/2013 8:00 AM, Zhengyu Gu wrote: >> This is a simple change to remove is_kernel_jvm field in >> jvm_version_info structure. The CCC request has been approved, as >> KERNEL VM has been deprecated since JDK7. >> >> JBS: https://jbs.oracle.com/bugs/browse/JDK-8006691 >> Webrev: http://cr.openjdk.java.net/~zgu/8006691/webrev.00/ >> >> Thanks, >> >> -Zhengyu >> >> From mandy.chung at oracle.com Fri Feb 8 17:17:16 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 08 Feb 2013 17:17:16 -0800 Subject: Code review request: 8006691: Remove jvm_version_info.is_kernel_jvm field In-Reply-To: <511571CC.1060003@oracle.com> References: <51152111.3030100@oracle.com> <51156BC0.5050200@oracle.com> <511571CC.1060003@oracle.com> Message-ID: <5115A39C.7090802@oracle.com> On 2/8/2013 1:44 PM, Zhengyu Gu wrote: > Mandy, > > Thanks for reviewing. > > What's the process to update jvm.h in the jdk repo? it should go to > both jdk7 and jdk8, which repos should I make the changes? > Like other core-libs development (see the OpenJDK developer guide [1]). You can work on a clone of http://hg.openjdk.java.net/jdk8/tl/jdk and send it out to core-libs-dev at openjdk.java.net for review. I will sponsor the change and push it for you. There is no rush to update jvm.h in the jdk repo but just to make sure the bit can be reused (to avoid out-of-sync definition as jdk implementation is using jvm_version_info). I believe is_kernel_info is no longer used in the JDK (I have to dig up the bug number and link it to yours). Please open a new bug for this jdk repo change since they will be integrated in different build. Mandy [1] http://openjdk.java.net/guide/ > Thanks, > > -Zhengyu > > On 2/8/2013 4:18 PM, Mandy Chung wrote: >> Zhengyu, >> >> This looks good to me too. Please also update the jvm.h in the jdk >> repo (src/share/javavm/export/jvm.h) - for historical reason, this is >> not an exact copy in the hotspot repo and we tend to apply the same >> patch rather than replacing it with the hotspot copy. >> >> BTW here is the public accessible link to the bug report: >> http://bugs.sun.com/view_bug.do?bug_id=8006691 >> >> Mandy >> >> On 2/8/2013 8:00 AM, Zhengyu Gu wrote: >>> This is a simple change to remove is_kernel_jvm field in >>> jvm_version_info structure. The CCC request has been approved, as >>> KERNEL VM has been deprecated since JDK7. >>> >>> JBS: https://jbs.oracle.com/bugs/browse/JDK-8006691 >>> Webrev: http://cr.openjdk.java.net/~zgu/8006691/webrev.00/ >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> From christian.thalinger at oracle.com Fri Feb 8 17:20:28 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 8 Feb 2013 17:20:28 -0800 Subject: RFC: deprecating SPARC V8 support? In-Reply-To: References: Message-ID: <522D47BA-17DC-4450-9FB6-76D84583F422@oracle.com> On Feb 7, 2013, at 5:16 PM, Mani Sarkar wrote: > Hi, > > I ran the below query to members of the Adopt-a-JSR, Adopt OpenJDK and the > LJC mailing lists and no one came back with any feedback with regards to > being impacted by the decision to deprecate SPACE V8 support. > > I hope this helps along with the other feedback you have received from your > sources. Thank you very much! That is much appreciated. So far I haven't heard of anyone still using it. -- Chris > > Thanks. > > Regards, > mani > > -- > *Twitter:* @theNeomatrix369 > *Blog:* http://neomatrix369.wordpress.com > *JUG activity:* LJC Advocate > *Meet-a-Project:* https://github.com/MutabilityDetector > > *Don't chase success, rather aim for "Excellence", and success will come > chasing after you!* > * > * > > Hello Community! > > We are playing with the idea to deprecate SPARC V8 support in HotSpot and I > would like to get some input from the OpenJDK community (especially from > the usual suspects: SAP, RedHat, Debian, ...). > > Is anyone out there still using SPARC V8 hardware or is supporting it? > > -- Chris From krystal.mo at oracle.com Fri Feb 8 17:23:43 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Fri, 08 Feb 2013 17:23:43 -0800 Subject: Request for review (XS): JDK-8006430: TraceTypeProfile is a product flag while it should be a diagnostic flag Message-ID: <5115A51F.2070102@oracle.com> Hi all, Could I have a couple of reviews for this fix, please? Webrev: http://cr.openjdk.java.net/~kmo/8006430/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006430 This bug is actually not a regression from JDK-7198499, but a long time issue that C2 diagnostic flags were never treated as being "diagnostic" since the OpenJDK Mercurial repo history began (duke at 0). The problem is, C2 diagnostic flags have the kind "{C2 diagnostic}", but Flag::is_unlocked() only cared to test "{diagnostic}". So the fix is straighforward -- find out how many other "diagnostic" and "experimental" flag kinds there are, and check them. I didn't just check if the string ends with "diagnostic}" or "experimental}" because I think that's too permissive, but I don't have a strong opinion on that. If reviews form a consensus that checking just the postfix is good enough, I can make the change that way. Care has to be taken if new diagnostic/experimental flag kinds are added to other components in the future, e.g. C1. Tested with JPRT and these flags by hand: C2 diagnostic: TraceTypeProfile, LoopLimitCheck, RangeLimitCheck ARCH diagnostic: UseIncDec Thanks, Kris From vladimir.kozlov at oracle.com Fri Feb 8 17:36:28 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 08 Feb 2013 17:36:28 -0800 Subject: Request for review (XS): JDK-8006430: TraceTypeProfile is a product flag while it should be a diagnostic flag In-Reply-To: <5115A51F.2070102@oracle.com> References: <5115A51F.2070102@oracle.com> Message-ID: <5115A81C.6020706@oracle.com> Looks good. I think you can preemptively add "{C1 diagnostic}". Thanks, Vladimir On 2/8/13 5:23 PM, Krystal Mo wrote: > Hi all, > > Could I have a couple of reviews for this fix, please? > > Webrev: http://cr.openjdk.java.net/~kmo/8006430/webrev.00/ > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006430 > > This bug is actually not a regression from JDK-7198499, but a long time > issue that C2 diagnostic flags were never treated as being "diagnostic" > since the OpenJDK Mercurial repo history began (duke at 0). > > The problem is, C2 diagnostic flags have the kind "{C2 diagnostic}", but > Flag::is_unlocked() only cared to test "{diagnostic}". > So the fix is straightforward -- find out how many other "diagnostic" and > "experimental" flag kinds there are, and check them. > > I didn't just check if the string ends with "diagnostic}" or > "experimental}" because I think that's too permissive, but I don't have > a strong opinion on that. > If reviews form a consensus that checking just the postfix is good > enough, I can make the change that way. > > Care has to be taken if new diagnostic/experimental flag kinds are added > to other components in the future, e.g. C1. > > Tested with JPRT and these flags by hand: > C2 diagnostic: TraceTypeProfile, LoopLimitCheck, RangeLimitCheck > ARCH diagnostic: UseIncDec > > Thanks, > Kris From krystal.mo at oracle.com Fri Feb 8 17:52:09 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Fri, 08 Feb 2013 17:52:09 -0800 Subject: Request for review (XS): JDK-8006430: TraceTypeProfile is a product flag while it should be a diagnostic flag In-Reply-To: <5115A81C.6020706@oracle.com> References: <5115A51F.2070102@oracle.com> <5115A81C.6020706@oracle.com> Message-ID: <5115ABC9.8090805@oracle.com> Hi Vladimir, Thank you for the review. I didn't add any C1 related checks because C1 doesn't have diagnostic/experimental flags declared. If I were to add those kinds, I'd touch more files then I'd like. Perhaps a new RFE for adding C1 diagnostic/experimental flag kinds? P.S. Oops, I forgot to update the copyright year. Will be fixed before I push. Thanks, Kris On 02/08/2013 05:36 PM, Vladimir Kozlov wrote: > Looks good. I think you can preemptively add "{C1 diagnostic}". > > Thanks, > Vladimir > > On 2/8/13 5:23 PM, Krystal Mo wrote: >> Hi all, >> >> Could I have a couple of reviews for this fix, please? >> >> Webrev: http://cr.openjdk.java.net/~kmo/8006430/webrev.00/ >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006430 >> >> This bug is actually not a regression from JDK-7198499, but a long time >> issue that C2 diagnostic flags were never treated as being "diagnostic" >> since the OpenJDK Mercurial repo history began (duke at 0). >> >> The problem is, C2 diagnostic flags have the kind "{C2 diagnostic}", but >> Flag::is_unlocked() only cared to test "{diagnostic}". >> So the fix is straightforward -- find out how many other "diagnostic" >> and >> "experimental" flag kinds there are, and check them. >> >> I didn't just check if the string ends with "diagnostic}" or >> "experimental}" because I think that's too permissive, but I don't have >> a strong opinion on that. >> If reviews form a consensus that checking just the postfix is good >> enough, I can make the change that way. >> >> Care has to be taken if new diagnostic/experimental flag kinds are added >> to other components in the future, e.g. C1. >> >> Tested with JPRT and these flags by hand: >> C2 diagnostic: TraceTypeProfile, LoopLimitCheck, RangeLimitCheck >> ARCH diagnostic: UseIncDec >> >> Thanks, >> Kris From ysr1729 at gmail.com Fri Feb 8 18:01:04 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 8 Feb 2013 18:01:04 -0800 Subject: CFV: New hotspot Group Member: Stefan Karlsson In-Reply-To: <20756.2182.166418.194006@oracle.com> References: <20756.2182.166418.194006@oracle.com> Message-ID: vote: yes On Thu, Feb 7, 2013 at 12:03 PM, John Coomes wrote: > I hereby nominate Stefan Karlsson to Membership in the hotspot Group. > > In addition to his earlier experience developing the jrockit JVM, > Stefan has been working on the HotSpot JVM at Oracle for more than two > years. He has contributed several dozen HotSpot changes, and was a > key contributor to the project to remove the permanent generation. He > is a Reviewer for the hsx Project and a Committer for the jdk8, jdk7u > and jdk6 Projects. > > Votes are due by 7:00 PM Thursday, February 21, 2013 UTC [1]. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > John Coomes, hotspot Group Lead > > [1] > http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Stefan+Karlsson&iso=20130221T19 > [2] http://openjdk.java.net/census/#hotspot > [3] http://openjdk.java.net/groups/#member-vote > From ysr1729 at gmail.com Fri Feb 8 18:02:05 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 8 Feb 2013 18:02:05 -0800 Subject: CFV: New hotspot Group Member: Bengt Rutisson In-Reply-To: <20756.2119.61953.313096@oracle.com> References: <20756.2119.61953.313096@oracle.com> Message-ID: vote: yes On Thu, Feb 7, 2013 at 12:02 PM, John Coomes wrote: > I hereby nominate Bengt Rutisson to Membership in the hotspot Group. > > Bengt is an Oracle engineer and has been working on HotSpot for more > than two years; prior to that he worked on the jrockit JVM. He is a > Reviewer for the hsx Project and has contributed more than 50 HotSpot > changes, primarily relating to the G1 collector. > > Votes are due by 7:00 PM Thursday, February 21, 2013 UTC [1]. > > Only current Members of the hotspot Group [2] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > John Coomes, hotspot Group Lead > > [1] > http://www.timeanddate.com/worldclock/fixedtime.html?msg=CFV%3A+New+hotspot+Group+Member%3A+Bengt+Rutisson&iso=20130221T19 > [2] http://openjdk.java.net/census/#hotspot > [3] http://openjdk.java.net/groups/#member-vote > From david.holmes at oracle.com Fri Feb 8 18:13:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 09 Feb 2013 12:13:09 +1000 Subject: RFR: JDK-8007804: Need to be able to access Performance counter by name from JVM In-Reply-To: <51152A60.8000004@oracle.com> References: <51152A60.8000004@oracle.com> Message-ID: <5115B0B5.9030004@oracle.com> On 9/02/2013 2:40 AM, Nils Loodin wrote: > Please review the following very small and insignificant change: > Basically, I need to access a performance-counter by name from within > the JVM. The method name by_name seems a little odd to me. find_by_name would seem more consistent (particularly if you consider the strange PerfDataList::by_name method - which compares names) David > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007804 > http://cr.openjdk.java.net/~nloodin/8007804/webrev.00/ > > Regards, > Nils Loodin > > From david.holmes at oracle.com Fri Feb 8 18:24:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 09 Feb 2013 12:24:32 +1000 Subject: RFR (XXS) CR 8006997: ContendedPaddingWidth should be uintx In-Reply-To: <51152BB2.6060300@oracle.com> References: <510668D1.5070002@oracle.com> <51109FF5.6020804@oracle.com> <51125B90.6030404@oracle.com> <51128906.3000302@oracle.com> <5112EAA0.5050303@oracle.com> <51135D48.9040002@oracle.com> <51136C02.3080700@oracle.com> <5114D5E8.90000@oracle.com> <5114FC03.8010906@oracle.com> <5114FDF3.6040102@oracle.com> <51152BB2.6060300@oracle.com> Message-ID: <5115B360.8000005@oracle.com> On 9/02/2013 2:45 AM, Aleksey Shipilev wrote: > On 02/08/2013 05:30 PM, Aleksey Shipilev wrote: >> On 02/08/2013 05:22 PM, David Holmes wrote: >>> On 8/02/2013 8:39 PM, Aleksey Shipilev wrote: >>>> Ok then. This is the new webrev: >>>> http://cr.openjdk.java.net/~shade/8006997/webrev.01/ >>>> >>>> I haven't found another good place to stick the guarantee() to, so opted >>>> to stick it before the actual use. I would be happy to stick it >>>> somewhere else where the options are generally checked, but found no >>>> non-platform/non-OS specific location. >>> >>> arguments.cpp - Arguments::parse_each_vm_init_arg - see >>> -XX:MaxDirectMemorySize as an example. >> >> Ok, great, thanks! I will update the webrev and give it another jprt spin. > > Here's the update: > http://cr.openjdk.java.net/~shade/8006997/webrev.02/ Sorry but that's not quite going to work right. Now you are mixing assignment of a signed int and an unsigned jlong! I'm surprised there is no compiler warning about that. And if someone passes in a value greater than INT_MAX it will pass the range check then store a negative value into the variable due to the jlong -> int truncation. When I referred you to MaxMemorySize as an example I didn't mean to literally copy it :) But now I see that parse_memory_size seems to be the only range checking done. Will it suffice to change to: 2825 ArgsRange errcode = parse_memory_size(tail, &contended_padding_width, INT_MAX); and 2833 FLAG_SET_CMDLINE(intx, ContendedPaddingWidth, (intx) contended_padding_width); David ------ > Testing: > a) ad-hoc fastdebug build with negative value > b) JPRT/Hotspot full cycle > > -Aleksey. > From vladimir.kozlov at oracle.com Fri Feb 8 18:54:19 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 08 Feb 2013 18:54:19 -0800 Subject: Request for review (XS): JDK-8006430: TraceTypeProfile is a product flag while it should be a diagnostic flag In-Reply-To: <5115ABC9.8090805@oracle.com> References: <5115A51F.2070102@oracle.com> <5115A81C.6020706@oracle.com> <5115ABC9.8090805@oracle.com> Message-ID: <5115BA5B.4070100@oracle.com> I suggested only to add 2 additional lines to the code you are modifying: strcmp(kind, "{C1 diagnostic}") == 0 || strcmp(kind, "{C1 experimental}") == 0 || I am not asking you to implement C1_EXPERIMENTAL* and C1_DIAGNOSTIC*. But may be it is for an other RFE. So please file one and I will agree with your current fix. Thanks, Vladimir On 2/8/13 5:52 PM, Krystal Mo wrote: > Hi Vladimir, > > Thank you for the review. I didn't add any C1 related checks because C1 > doesn't have diagnostic/experimental flags declared. If I were to add > those kinds, I'd touch more files then I'd like. > Perhaps a new RFE for adding C1 diagnostic/experimental flag kinds? > > P.S. Oops, I forgot to update the copyright year. Will be fixed before I > push. > > Thanks, > Kris > > On 02/08/2013 05:36 PM, Vladimir Kozlov wrote: >> Looks good. I think you can preemptively add "{C1 diagnostic}". >> >> Thanks, >> Vladimir >> >> On 2/8/13 5:23 PM, Krystal Mo wrote: >>> Hi all, >>> >>> Could I have a couple of reviews for this fix, please? >>> >>> Webrev: http://cr.openjdk.java.net/~kmo/8006430/webrev.00/ >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006430 >>> >>> This bug is actually not a regression from JDK-7198499, but a long time >>> issue that C2 diagnostic flags were never treated as being "diagnostic" >>> since the OpenJDK Mercurial repo history began (duke at 0). >>> >>> The problem is, C2 diagnostic flags have the kind "{C2 diagnostic}", but >>> Flag::is_unlocked() only cared to test "{diagnostic}". >>> So the fix is straightforward -- find out how many other "diagnostic" >>> and >>> "experimental" flag kinds there are, and check them. >>> >>> I didn't just check if the string ends with "diagnostic}" or >>> "experimental}" because I think that's too permissive, but I don't have >>> a strong opinion on that. >>> If reviews form a consensus that checking just the postfix is good >>> enough, I can make the change that way. >>> >>> Care has to be taken if new diagnostic/experimental flag kinds are added >>> to other components in the future, e.g. C1. >>> >>> Tested with JPRT and these flags by hand: >>> C2 diagnostic: TraceTypeProfile, LoopLimitCheck, RangeLimitCheck >>> ARCH diagnostic: UseIncDec >>> >>> Thanks, >>> Kris > From staffan.larsen at oracle.com Sat Feb 9 11:06:26 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Sat, 9 Feb 2013 20:06:26 +0100 Subject: RFR (XS): 8007901 SA: Don't read flag values as constants Message-ID: Please review this small patch to avoid reading flag values in SA as constants. Reading them as constants means SA will only see the default value for these flags. Instead the infrastructure in SA to read command line flags should be used. In addition the value if EnableInvokeDynamic is never used, so I removed that from SA. webrev: http://cr.openjdk.java.net/~sla/8007901/webrev.00/ bug: http://bugs.sun.com/view_bug.do?bug_id=8007901 (not yet visible) Thanks, /Staffan From erik.joelsson at oracle.com Mon Feb 11 00:38:43 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 11 Feb 2013 09:38:43 +0100 Subject: RFR (S): 8007639: Workaround for ccache in vm.make is incorrect In-Reply-To: <5115442C.5030309@oracle.com> References: <5115442C.5030309@oracle.com> Message-ID: <5118AE13.9000505@oracle.com> Looks good to me. /Erik On 2013-02-08 19:30, Mikael Vidstedt wrote: > > Please review the following change: > > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8007639/webrev.00/webrev > Bug: http://bugs.sun.com/view_bug.do?bug_id=8007639 > > This change corrects the workaround that was introduced in vm.make for > enabling ccache for HotSpot builds. The change introduces a file > specific makefile variable (CFLAGS/) which is used to only set > the JRE_RELEASE_VERSION define when compiling vm_version.o. > > Verified manually by observing command lines with/without fix, also > passes JPRT. > > > Some additional background below, more information is available in the > bug report: > > To enable the use of ccache 7132779 [1] introduced some new makefile > logic in vm.make to only pass the JRE_RELEASE_VERSION define when > compiling the vm_version.cpp file. The underlying reason for that is > that the JRE_RELEASE_VERSION can in some cases contain a time stamp > and since ccache checks that the defines match before reusing the > cache version of the object file that would mean that if the time > stamp changed all files would have to be recompiled. With the fix only > vm_version.cpp needs to be recompiled. > > This almost works, but the logic introduced in the makefile is > actually incorrect. Today it looks like this: > > > # This is VERY important! The version define must only be supplied to > vm_version.o > # If not, ccache will not re-use the cache at all, since the version > string might contain > # a time and date. > vm_version.o: CXXFLAGS += ${JRE_VERSION} > > However, the above syntax does not only add the ${JRE_VERSION} to the > CXXFLAGS of vm_version.o as originally intended - it also /in some > cases/ adds it to the CXXFLAGS for any and all prerequisites of > vm_version.o. And vm_version.o depends on all other object files, > which means in theory this actually passes in that potentially time > stamped version string define to all object files anyway. For various > reasons in reality it only passes it to files that are > lexicographically after vm_version.o - see bug report for more > background on why - but there's still a handful of files that will be > recompiled unnecessarily. > > Cheers, > Mikael > > [1] http://bugs.sun.com/view_bug.do?bug_id=7132779 > From staffan.larsen at oracle.com Mon Feb 11 00:57:40 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 11 Feb 2013 09:57:40 +0100 Subject: Request for review (XS): JDK-8006430: TraceTypeProfile is a product flag while it should be a diagnostic flag In-Reply-To: <5115A51F.2070102@oracle.com> References: <5115A51F.2070102@oracle.com> Message-ID: <9F15BEC4-47F1-4529-B395-853D272FE54C@oracle.com> Forgive my ignorance, but why do diagnostic and experimental flags have different "kinds" depending on what part of the VM they belong to? Can't they all be just "{experimental}" or "{diagnostic}"? I don't see where the additional C1/C2/ARCH/Shark information is used. Thanks, /Staffan On 9 feb 2013, at 02:23, Krystal Mo wrote: > Hi all, > > Could I have a couple of reviews for this fix, please? > > Webrev: http://cr.openjdk.java.net/~kmo/8006430/webrev.00/ > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006430 > > This bug is actually not a regression from JDK-7198499, but a long time issue that C2 diagnostic flags were never treated as being "diagnostic" since the OpenJDK Mercurial repo history began (duke at 0). > > The problem is, C2 diagnostic flags have the kind "{C2 diagnostic}", but Flag::is_unlocked() only cared to test "{diagnostic}". > So the fix is straighforward -- find out how many other "diagnostic" and "experimental" flag kinds there are, and check them. > > I didn't just check if the string ends with "diagnostic}" or "experimental}" because I think that's too permissive, but I don't have a strong opinion on that. > If reviews form a consensus that checking just the postfix is good enough, I can make the change that way. > > Care has to be taken if new diagnostic/experimental flag kinds are added to other components in the future, e.g. C1. > > Tested with JPRT and these flags by hand: > C2 diagnostic: TraceTypeProfile, LoopLimitCheck, RangeLimitCheck > ARCH diagnostic: UseIncDec > > Thanks, > Kris From krystal.mo at oracle.com Mon Feb 11 02:15:28 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Mon, 11 Feb 2013 02:15:28 -0800 Subject: Request for review (XS): JDK-8006430: TraceTypeProfile is a product flag while it should be a diagnostic flag In-Reply-To: <9F15BEC4-47F1-4529-B395-853D272FE54C@oracle.com> References: <5115A51F.2070102@oracle.com> <9F15BEC4-47F1-4529-B395-853D272FE54C@oracle.com> Message-ID: <5118C4C0.5000101@oracle.com> Hi Staffan, Honestly, I'd like to know more on the history of separating these flag kinds, too. The only place where this piece of extra information is available to users is like -XX:+PrintFlagsFinal $ java -XX:+PrintFlagsFinal Foo | grep LoopLimitCheck bool LoopLimitCheck = true {C2 diagnostic} That in itself would still bring some value to users. - Kris On 02/11/2013 12:57 AM, Staffan Larsen wrote: > Forgive my ignorance, but why do diagnostic and experimental flags have different "kinds" depending on what part of the VM they belong to? Can't they all be just "{experimental}" or "{diagnostic}"? I don't see where the additional C1/C2/ARCH/Shark information is used. > > Thanks, > /Staffan > > On 9 feb 2013, at 02:23, Krystal Mo wrote: > >> Hi all, >> >> Could I have a couple of reviews for this fix, please? >> >> Webrev: http://cr.openjdk.java.net/~kmo/8006430/webrev.00/ >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006430 >> >> This bug is actually not a regression from JDK-7198499, but a long time issue that C2 diagnostic flags were never treated as being "diagnostic" since the OpenJDK Mercurial repo history began (duke at 0). >> >> The problem is, C2 diagnostic flags have the kind "{C2 diagnostic}", but Flag::is_unlocked() only cared to test "{diagnostic}". >> So the fix is straighforward -- find out how many other "diagnostic" and "experimental" flag kinds there are, and check them. >> >> I didn't just check if the string ends with "diagnostic}" or "experimental}" because I think that's too permissive, but I don't have a strong opinion on that. >> If reviews form a consensus that checking just the postfix is good enough, I can make the change that way. >> >> Care has to be taken if new diagnostic/experimental flag kinds are added to other components in the future, e.g. C1. >> >> Tested with JPRT and these flags by hand: >> C2 diagnostic: TraceTypeProfile, LoopLimitCheck, RangeLimitCheck >> ARCH diagnostic: UseIncDec >> >> Thanks, >> Kris From bengt.rutisson at oracle.com Mon Feb 11 08:44:16 2013 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Mon, 11 Feb 2013 16:44:16 +0000 Subject: hg: hsx/hsx24/hotspot: 8002144: G1: large number of evacuation failures may lead to large c heap memory usage Message-ID: <20130211164420.BA554479A6@hg.openjdk.java.net> Changeset: bf523388179f Author: brutisso Date: 2013-02-10 21:15 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bf523388179f 8002144: G1: large number of evacuation failures may lead to large c heap memory usage Summary: Use Stack<> instead of GrowableArray to keep track of preserved marks. Also reviewed by vitalyd at gmail.com. Reviewed-by: johnc, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp From mikael.vidstedt at oracle.com Mon Feb 11 10:45:33 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 11 Feb 2013 10:45:33 -0800 Subject: RFR (XS): 8007901 SA: Don't read flag values as constants In-Reply-To: References: Message-ID: <51193C4D.5090809@oracle.com> Nasty, so normally the code picks up the value from the VMIntConstant vmstructs array which is the hardcoded default value, but with this fix it's picked up from the command line options database which reflects the actual current value. That makes sense and looks good. Cheers, Mikael On 2013-02-09 11:06, Staffan Larsen wrote: > Please review this small patch to avoid reading flag values in SA as constants. Reading them as constants means SA will only see the default value for these flags. Instead the infrastructure in SA to read command line flags should be used. In addition the value if EnableInvokeDynamic is never used, so I removed that from SA. > > webrev: http://cr.openjdk.java.net/~sla/8007901/webrev.00/ > bug: http://bugs.sun.com/view_bug.do?bug_id=8007901 (not yet visible) > > Thanks, > /Staffan From staffan.larsen at oracle.com Mon Feb 11 10:53:19 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 11 Feb 2013 19:53:19 +0100 Subject: RFR (XS): 8007901 SA: Don't read flag values as constants In-Reply-To: <51193C4D.5090809@oracle.com> References: <51193C4D.5090809@oracle.com> Message-ID: Yes, you got it right. Thanks, /Staffan On 11 feb 2013, at 19:45, Mikael Vidstedt wrote: > > Nasty, so normally the code picks up the value from the VMIntConstant vmstructs array which is the hardcoded default value, but with this fix it's picked up from the command line options database which reflects the actual current value. That makes sense and looks good. > > Cheers, > Mikael > > On 2013-02-09 11:06, Staffan Larsen wrote: >> Please review this small patch to avoid reading flag values in SA as constants. Reading them as constants means SA will only see the default value for these flags. Instead the infrastructure in SA to read command line flags should be used. In addition the value if EnableInvokeDynamic is never used, so I removed that from SA. >> >> webrev: http://cr.openjdk.java.net/~sla/8007901/webrev.00/ >> bug: http://bugs.sun.com/view_bug.do?bug_id=8007901 (not yet visible) >> >> Thanks, >> /Staffan > From gnu.andrew at redhat.com Mon Feb 11 11:29:49 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 11 Feb 2013 14:29:49 -0500 (EST) Subject: Bad licensing header on testcase in HotSpot repositories In-Reply-To: <1682049083.908401.1360610865192.JavaMail.root@redhat.com> Message-ID: <1978457656.909025.1360610989660.JavaMail.root@redhat.com> The file: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/fe4a4ea5bed9/test/runtime/7158804/Test7158804.sh has a bad copyright header with just: # Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. and no mention of a license. The same file also appears in the jdk7u repositories: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/tip/test/runtime/7158804/Test7158804.sh and so will need correcting in both places. -- 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 jeffhain at rocketmail.com Mon Feb 11 13:53:19 2013 From: jeffhain at rocketmail.com (Jeff Hain) Date: Mon, 11 Feb 2013 21:53:19 +0000 (GMT) Subject: double a%b returns NaN for some (a,b) (|a| < inf, |b|>0) Message-ID: <1360619599.25551.YahooMailNeo@web132105.mail.ird.yahoo.com> Hello. While testing some mathematical treatments, I had "%" operator on doubles return NaN in some cases where the divisor is subnormal and the dividend either huge or tiny as well. More precisely, with D(x) = Double.longBitsToDouble(x), I had a%b being NaN for: - all (a,b) such as ? D(0x7FE0000000000000L) <= |a| <= D(0x7FEFFFFFFFFFFFFFL) ? and ? D(0x0000000000040000L) <= |b| <= D(0x000000000007FFFFL) - plus for some values of |b| outside this range, ? when |a| is D(0x7FEFFFFFFFFFFFFFL), like ? b = D(0x000000007FFFFFFFL) (but not for b = D(0x000000007FFEFFFFL)) ? b = 6.767486E-317 ? b = 7.528725E-318 I can reproduce this on a Core i7 980X (64 bits), with various versions of Java (64 bits), but not on a Dual Core T2300 (32 bits), with various versions of Java as well, so I wonder whether it's a JVM, a CPU bug (by construction or if it broke) or else. Is it a known issue, and if not can anyone reproduce this weird behavior? Thanks. -Jeff From jeffhain at rocketmail.com Mon Feb 11 14:04:45 2013 From: jeffhain at rocketmail.com (Jeff Hain) Date: Mon, 11 Feb 2013 22:04:45 +0000 (GMT) Subject: Tr : double a%b returns NaN for some (a,b) (|a| < inf, |b|>0) In-Reply-To: <1360619599.25551.YahooMailNeo@web132105.mail.ird.yahoo.com> References: <1360619599.25551.YahooMailNeo@web132105.mail.ird.yahoo.com> Message-ID: <1360620285.76858.YahooMailNeo@web132103.mail.ird.yahoo.com> In what I just sent please read "and the dividend huge."instead of "and the dividend either huge or tiny as well." (I also had trouble for tiny dividends, but the trouble was in my tests ;) -Jeff From vladimir.kozlov at oracle.com Mon Feb 11 15:17:24 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Feb 2013 15:17:24 -0800 Subject: Tr : double a%b returns NaN for some (a,b) (|a| < inf, |b|>0) In-Reply-To: <1360620285.76858.YahooMailNeo@web132103.mail.ird.yahoo.com> References: <1360619599.25551.YahooMailNeo@web132105.mail.ird.yahoo.com> <1360620285.76858.YahooMailNeo@web132103.mail.ird.yahoo.com> Message-ID: <51197C04.8070908@oracle.com> Hi, Jeff First, could you show what java versions you tried (java -version)? And what OS you are using? Second, could you try to run with -Xint? It will run in Interpreter mode only without JIT compilation. Third, run only Client (-client) or Server (-server) VM. It will use different JIT compilers. Note, that there is no Client 64bit VM. If you have latest jdk7update (7u10 or 7u12) or jdk8 you can specify next flags to use only Client's JIT compiler: -XX:+TieredCompilation -XX:TieredStopAtLevel=1. Regards, Vladimir On 2/11/13 2:04 PM, Jeff Hain wrote: > In what I just sent please read > > "and the dividend huge."instead of > "and the dividend either huge or tiny as well." > (I also had trouble for tiny dividends, > but the trouble was in my tests ;) > > -Jeff > From zhengyu.gu at oracle.com Mon Feb 11 16:14:43 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Tue, 12 Feb 2013 00:14:43 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130212001450.C84BF479BA@hg.openjdk.java.net> Changeset: b89e93583e0d Author: zgu Date: 2013-02-08 16:31 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b89e93583e0d 8006691: Remove jvm_version_info.is_kernel_jvm field Summary: Removed is_kernel_jvm from jvm_version_info as Kernel VM has been deprecated Reviewed-by: mchung, coleenp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 61dbc09285c3 Author: zgu Date: 2013-02-11 14:48 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/61dbc09285c3 Merge From david.holmes at oracle.com Mon Feb 11 16:20:51 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Feb 2013 10:20:51 +1000 Subject: RFR (XS): 8007901 SA: Don't read flag values as constants In-Reply-To: References: Message-ID: <51198AE3.5040706@oracle.com> On 10/02/2013 5:06 AM, Staffan Larsen wrote: > Please review this small patch to avoid reading flag values in SA as constants. Reading them as constants means SA will only see the default value for these flags. Instead the infrastructure in SA to read command line flags should be used. In addition the value if EnableInvokeDynamic is never used, so I removed that from SA. Isn't the real problem in the way db is initialized with the values for these flags? ie shouldn't db.lookupIntConstant("UseTLAB").intValue() be returning the actual value of UseTLAB as it occurs in the VM ? Also we need a regression test for this as obviously it ain't being tested! :( Thanks, David > webrev: http://cr.openjdk.java.net/~sla/8007901/webrev.00/ > bug: http://bugs.sun.com/view_bug.do?bug_id=8007901 (not yet visible) > > Thanks, > /Staffan > From staffan.larsen at oracle.com Tue Feb 12 02:19:24 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 12 Feb 2013 11:19:24 +0100 Subject: RFR (XS): 8007901 SA: Don't read flag values as constants In-Reply-To: <51198AE3.5040706@oracle.com> References: <51198AE3.5040706@oracle.com> Message-ID: <66CB6E74-D03C-43A7-B3B1-C162C2992398@oracle.com> The values are initialized at VM compile time in the VMStructs::localHotSpotVMIntConstants array. I don't think we want to modify SA so that values of int constants is made into a dynamic lookup. Or at least, that is a fairly significant change to SA. The problem here was to think that UseTLAB is a constant when it isn't. Yes, I thought about a regression test for this, but the valuable test would be to verify that no command line flag values are read as constants, and I don't see how I could write that. Thanks, /Staffan On 12 feb 2013, at 01:20, David Holmes wrote: > On 10/02/2013 5:06 AM, Staffan Larsen wrote: >> Please review this small patch to avoid reading flag values in SA as constants. Reading them as constants means SA will only see the default value for these flags. Instead the infrastructure in SA to read command line flags should be used. In addition the value if EnableInvokeDynamic is never used, so I removed that from SA. > > Isn't the real problem in the way db is initialized with the values for these flags? ie shouldn't db.lookupIntConstant("UseTLAB").intValue() be returning the actual value of UseTLAB as it occurs in the VM ? > > Also we need a regression test for this as obviously it ain't being tested! :( > > Thanks, > David > >> webrev: http://cr.openjdk.java.net/~sla/8007901/webrev.00/ >> bug: http://bugs.sun.com/view_bug.do?bug_id=8007901 (not yet visible) >> >> Thanks, >> /Staffan >> From staffan.larsen at oracle.com Tue Feb 12 02:22:52 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 12 Feb 2013 11:22:52 +0100 Subject: RFR (S): 8007779: os::die() on solaris should generate core file In-Reply-To: <51154244.8030209@oracle.com> References: <5115037C.8090705@oracle.com> <511515CD.2090406@oracle.com> <51152226.7070608@oracle.com> <51154244.8030209@oracle.com> Message-ID: Did we reach a conclusion on this change? Was it ok to call abort() so that we get core files and can debug these crashes? Thanks, /Staffan On 8 feb 2013, at 19:21, Dean Long wrote: > The 0x80 bit should be part of the value returned by wait(2), but it may be shell-specific which > bits are captured by $?. > > dl > > On 2/8/2013 8:04 AM, Mikael Vidstedt wrote: >> On 2013-02-08 07:12, Mikael Gerdin wrote: >>> On 2013-02-08 15:05, Staffan Larsen wrote: >>>> The return code from the process seems to be 134 (after an experiment). This would be the same as after a successful printing of hs_err when we do manage to create a core dump. >>> >>> When a posix process is terminated by an uncaught fatal signal the exit code is usually 128 + SIGNAL >>> Since SIGABRT == 6 you got 134 >> >> I believe the 128+n may be for bash specifically, not for general posix processes, but the same conclusion goes. >> >> /Another Mikael >> >>> >>> /Mikael >>> >>>> >>>> /Staffan >>>> >>>> On 8 feb 2013, at 14:54, David Holmes wrote: >>>> >>>>> My other email hasn't turned up yet but I was confusing this with the change that added the dump_core flag to os::abort. >>>>> >>>>> It's only by "accident" that we use ::abort on linux - _exit didn't work back in the old days of LinuxThreads :) >>>>> >>>>> This seems like a simple and potentially useful change, but I have a feeling it may have some unexpected consequences somewhere. :) >>>>> >>>>> Actually one possible consequence - what return code will the process issue if it now hits this? Could this impact testing and failure matching ? >>>>> >>>>> David >>>>> >>>>> On 8/02/2013 10:24 PM, Staffan Larsen wrote: >>>>>> This is a request for review of a small change to the crash reporting on solaris. >>>>>> >>>>>> When hotspot crashes during the writing of the hs_err file, we call os::die(). On linux and bsd this causes a core file to be written (by calling ::abort()). This is good since we then have some record of what went wrong. On solaris, we call _exit() and no core file is created. >>>>>> >>>>>> There are two cases during the hs_err writing where we call os::die(). First, if the writing hangs, the WatcherThread will call os::die(). Second, if we get too many errors during the writing we will call os::die(). In both these cases it would be very helpful to have a core file. Otherwise all you have to go on is something like this: >>>>>> >>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>> # >>>>>> # SIGSEGV (0xb) at pc=0xffffffff653848c0, pid=11823, tid=240 >>>>>> # >>>>>> # JRE version: Java(TM) SE Runtime Environment (7.0_12-b11) >>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b24 mixed mode solaris-sparc compressed oops) >>>>>> # Problematic frame: >>>>>> # C [libc.so.1+0x848c0]# [ timer expired, abort... ] >>>>>> >>>>>> Below is the change I would like to do. >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>> >>>>>> diff --git a/src/os/solaris/vm/os_solaris.cpp b/src/os/solaris/vm/os_solaris.cpp >>>>>> --- a/src/os/solaris/vm/os_solaris.cpp >>>>>> +++ b/src/os/solaris/vm/os_solaris.cpp >>>>>> @@ -1865,7 +1865,7 @@ >>>>>> >>>>>> // Die immediately, no exit hook, no abort hook, no cleanup. >>>>>> void os::die() { >>>>>> - _exit(-1); >>>>>> + ::abort(); // dump core (for debugging) >>>>>> } >>>>>> >>>>>> >>>> >> From zhengyu.gu at oracle.com Tue Feb 12 06:26:19 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 12 Feb 2013 09:26:19 -0500 Subject: Code review request: 8007950: Undo hs_file permission change Message-ID: <511A510B.2000104@oracle.com> The original change to hs_file permission was pushed prematurely, as it might have impact to hotspot build and test infrastructures. This change is to simply reverse the early one, and we will address the original CR once infrastructures are ready. CR: https://jbs.oracle.com/bugs/browse/JDK-8007950 Webrev: http://cr.openjdk.java.net/~zgu/8007950/webrev.00/ Thanks, -Zhengyu From dmitry.samersoff at oracle.com Tue Feb 12 06:28:37 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 12 Feb 2013 18:28:37 +0400 Subject: Code review request: 8007950: Undo hs_file permission change In-Reply-To: <511A510B.2000104@oracle.com> References: <511A510B.2000104@oracle.com> Message-ID: <511A5195.20401@oracle.com> Looks good to me. On 2013-02-12 18:26, Zhengyu Gu wrote: > The original change to hs_file permission was pushed prematurely, as it > might have impact to hotspot build and test infrastructures. This change > is to simply reverse the early one, and we will address the original CR > once infrastructures are ready. > > CR: https://jbs.oracle.com/bugs/browse/JDK-8007950 > Webrev: http://cr.openjdk.java.net/~zgu/8007950/webrev.00/ > > Thanks, > > -Zhengyu -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From daniel.daugherty at oracle.com Tue Feb 12 07:00:13 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 12 Feb 2013 08:00:13 -0700 Subject: Code review request: 8007950: Undo hs_file permission change In-Reply-To: <511A510B.2000104@oracle.com> References: <511A510B.2000104@oracle.com> Message-ID: <511A58FD.900@oracle.com> On 2/12/13 7:26 AM, Zhengyu Gu wrote: > The original change to hs_file permission was pushed prematurely, as > it might have impact to hotspot build and test infrastructures. This > change is to simply reverse the early one, and we will address the > original CR once infrastructures are ready. > > CR: https://jbs.oracle.com/bugs/browse/JDK-8007950 > Webrev: http://cr.openjdk.java.net/~zgu/8007950/webrev.00/ src/share/vm/utilities/vmError.cpp Anti delta looks clean Just a reminder, you can't reuse bug ID 8007791. You'll need yet another new bug ID. Dan > > Thanks, > > -Zhengyu From karen.kinnear at oracle.com Tue Feb 12 08:53:03 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 12 Feb 2013 11:53:03 -0500 Subject: Code review request: 8007950: Undo hs_file permission change In-Reply-To: <511A510B.2000104@oracle.com> References: <511A510B.2000104@oracle.com> Message-ID: <1550D240-6171-49EB-A9A8-59FFFD18DD23@oracle.com> Looks good. Thank you Zhengyu. thanks, Karen On Feb 12, 2013, at 9:26 AM, Zhengyu Gu wrote: > The original change to hs_file permission was pushed prematurely, as it might have impact to hotspot build and test infrastructures. This change is to simply reverse the early one, and we will address the original CR once infrastructures are ready. > > CR: https://jbs.oracle.com/bugs/browse/JDK-8007950 > Webrev: http://cr.openjdk.java.net/~zgu/8007950/webrev.00/ > > Thanks, > > -Zhengyu From sbergman at redhat.com Tue Feb 12 09:46:22 2013 From: sbergman at redhat.com (Stephan Bergmann) Date: Tue, 12 Feb 2013 18:46:22 +0100 Subject: get_stack_bounds using read(2) syscalls to read /proc/self/maps byte-by-byte Message-ID: <511A7FEE.20104@redhat.com> On some Linux box (Fedora 18, using java-1.7.0-openjdk-1.7.0.9-2.3.5.fc18.x86_64) I happened to look at an strace of a LibreOffice process (which can instantiate the JVM in-process), and noticed lots of calls to read(2) to read individual bytes of /proc/self/maps. And get_stack_bounds in os/linux/vm/os_linux.cpp indeed calls out to os::get_line_chars in share/vm/runtime/os.cpp that does read(fd, &buf[i], 1) This appears to be introduce with "7017193: Small memory leak in get_stack_bounds os::create_stack_guard_pages" to fix "Small memory leak in get_stack_bounds // os::create_stack_guard_pages." Is this a known performance issue? A (likely naive) Web search did not show anything that looked relevant, but I have vague memories of having seen it mentioned somewhere a while ago. Stephan From jeffhain at rocketmail.com Tue Feb 12 10:34:35 2013 From: jeffhain at rocketmail.com (Jeff Hain) Date: Tue, 12 Feb 2013 18:34:35 +0000 (GMT) Subject: Tr : double a%b returns NaN for some (a,b) (|a| < inf, |b|>0) References: <1360619599.25551.YahooMailNeo@web132105.mail.ird.yahoo.com> <1360620285.76858.YahooMailNeo@web132103.mail.ird.yahoo.com> <51197C04.8070908@oracle.com> Message-ID: <1360694075.66018.YahooMailNeo@web132105.mail.ird.yahoo.com> Vladimir wrote: >First, could you show what java versions you tried (java -version)? And what OS you are using? On Windows 7/Core i7 980X, it happens with the following 64 bits versions of Java: - 1.5.0_22-b03 - 1.6.0_21-ea-b05 - 1.6.0_29-ea-b08 (and also crashes at some point but this version seems to crash a lot, so might be unrelated) - 1.6.0_38-b05 ("Java HotSpot(TM) 64-Bit Server VM") but not with: - 1.7.0_11-b21 - 1.8.0-ea-b73 On Windows XP/T2300, it does not happen with: - 1.6.0_38 - 1.6.0_39 - 1.7.0_10 >Second, could you try to run with -Xint? It will run in Interpreter mode only without JIT compilation. Still happens. >Third, run only Client (-client) or Server (-server) VM. It will use different JIT compilers. >Note, that there is no Client 64bit VM. If you have latest jdk7update (7u10 or 7u12) or jdk8 you can specify next flags to use only Client's JIT compiler: -XX:+TieredCompilation -XX:TieredStopAtLevel=1. Only using 64 bits VMs. Here is some code that can reproduce the problem, and the output I get whether it happens or not: public class ModNaN { ??? /* Windows 7/Core i7 980X/1.6.0_38 (64): NaNs 8.98846567431158E307 % 1.295163E-318 = NaN 1.7976931348623157E308 % 2.59032E-318 = NaN 1.7976931348623157E308 % 1.060997895E-314 = NaN 1.7976931348623157E308 % 6.767486E-317 = NaN 1.7976931348623157E308 % 7.528725E-318 = NaN non-NaNs 8.98846567431158E307 % 1.29516E-318 = 2.53E-321 1.7976931348623157E308 % 2.590327E-318 = 0.0 1.7976931348623157E308 % 1.060965516E-314 = 9.35818525E-315 ???? */ ??? /* Windows 7/Core i7 980X/1.7.0_11 (64): NaNs 8.98846567431158E307 % 1.295163E-318 = 0.0 1.7976931348623157E308 % 2.59032E-318 = 2.57135E-318 1.7976931348623157E308 % 1.060997895E-314 = 5.31535078E-315 1.7976931348623157E308 % 6.767486E-317 = 1.142612E-317 1.7976931348623157E308 % 7.528725E-318 = 4.64634E-318 non-NaNs 8.98846567431158E307 % 1.29516E-318 = 2.53E-321 1.7976931348623157E308 % 2.590327E-318 = 0.0 1.7976931348623157E308 % 1.060965516E-314 = 9.35818525E-315 ???? */ ??? public static void main(String[] args) { ??????? System.out.println("NaNs"); ??????? for (double[] ab : new double[][]{ ??????????????? new double[]{Double.longBitsToDouble(0x7FE0000000000000L),Double.longBitsToDouble(0x0000000000040000L)}, ??????????????? new double[]{Double.longBitsToDouble(0x7FEFFFFFFFFFFFFFL),Double.longBitsToDouble(0x000000000007FFFFL)}, ??????????????? // ??????????????? new double[]{Double.longBitsToDouble(0x7FEFFFFFFFFFFFFFL),Double.longBitsToDouble(0x000000007FFFFFFFL)}, ??????????????? new double[]{Double.longBitsToDouble(0x7FEFFFFFFFFFFFFFL),6.767486E-317}, ??????????????? new double[]{Double.longBitsToDouble(0x7FEFFFFFFFFFFFFFL),7.528725E-318}, ??????? }) { ??????????? double a = ab[0]; ??????????? double b = ab[1]; ??????????? double mod = a % b; ??????????? System.out.println(a+" % "+b+" = "+mod); ??????? } ??????? System.out.println("non-NaNs"); ??????? for (double[] ab : new double[][]{ ??????????????? new double[]{Double.longBitsToDouble(0x7FE0000000000000L),Double.longBitsToDouble(0x000000000003FFFFL)}, ??????????????? new double[]{Double.longBitsToDouble(0x7FEFFFFFFFFFFFFFL),Double.longBitsToDouble(0x0000000000080000L)}, ??????????????? // ??????????????? new double[]{Double.longBitsToDouble(0x7FEFFFFFFFFFFFFFL),Double.longBitsToDouble(0x000000007FFEFFFFL)}, ??????? }) { ??????????? double a = ab[0]; ??????????? double b = ab[1]; ??????????? double mod = a % b; ??????????? System.out.println(a+" % "+b+" = "+mod); ??????? } ??? } } -Jeff From david.r.chase at oracle.com Tue Feb 12 11:30:27 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 12 Feb 2013 14:30:27 -0500 Subject: double a%b returns NaN for some (a,b) (|a| < inf, |b|>0) In-Reply-To: <1360694075.66018.YahooMailNeo@web132105.mail.ird.yahoo.com> References: <1360619599.25551.YahooMailNeo@web132105.mail.ird.yahoo.com> <1360620285.76858.YahooMailNeo@web132103.mail.ird.yahoo.com> <51197C04.8070908@oracle.com> <1360694075.66018.YahooMailNeo@web132105.mail.ird.yahoo.com> Message-ID: On 2013-02-12, at 1:34 PM, Jeff Hain wrote: > Vladimir wrote: >> First, could you show what java versions you tried (java -version)? And what OS you are using? > > > On Windows 7/Core i7 980X, it happens with the following 64 bits versions of Java: > - 1.5.0_22-b03 > - 1.6.0_21-ea-b05 > - 1.6.0_29-ea-b08 (and also crashes at some point but this version seems to crash a lot, so might be unrelated) > - 1.6.0_38-b05 ("Java HotSpot(TM) 64-Bit Server VM") > but not with: > - 1.7.0_11-b21 > - 1.8.0-ea-b73 > > > On Windows XP/T2300, it does not happen with: > - 1.6.0_38 > - 1.6.0_39 > - 1.7.0_10 I have some more non-results, MacOS 10.8.2, Core i5, does not happen with: java version "1.6.0_37" Java(TM) SE Runtime Environment (build 1.6.0_37-b06-434-11M3909) Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01-434, mixed mode) java version "1.7.0_13" Java(TM) SE Runtime Environment (build 1.7.0_13-b20) Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) openjdk version "1.8.0-internal-fastdebug" (near-current jdk8/tl) OpenJDK Runtime Environment (build 1.8.0-internal-fastdebug-dr2chase_2013_02_08_16_15-b00) OpenJDK 64-Bit Server VM (build 25.0-b17-fastdebug, mixed mode) Each above used corresponding javac to compiler ModNaN.java, and plain "java" to test. Also tried 7 and 8, class files from 1.6 javac, running java with flags: -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -XX:+TieredCompilation -XX:TieredStopAtLevel=2 Also tried on MacOS 10.8.2, Core i7, does not happen there with: java version "1.6.0_37" Java(TM) SE Runtime Environment (build 1.6.0_37-b06-434-11M3909) Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01-434, mixed mode) And thanks for the test code. David From vladimir.kozlov at oracle.com Tue Feb 12 13:50:52 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Feb 2013 13:50:52 -0800 Subject: CFV: New HSX Committer: Morris Meyer In-Reply-To: <5111D374.2090101@oracle.com> References: <5111D374.2090101@oracle.com> Message-ID: <511AB93C.1060003@oracle.com> I hereby nominate Morris Meyer (OpenJDK user name: morris) to HSX Committer. Morris is a member of the Hotspot Compiler group. He contributed 8 changesets to HSX project and he is qualified to be committer [1]: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=morris Votes are due by Feb 26, 2013. Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Vladimir Kozlov [1] http://openjdk.java.net/projects/#project-committer [2] http://openjdk.java.net/census#hsx [3] http://openjdk.java.net/projects#committer-vote From john.r.rose at oracle.com Tue Feb 12 14:01:29 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 12 Feb 2013 14:01:29 -0800 Subject: CFV: New HSX Committer: Morris Meyer In-Reply-To: <511AB93C.1060003@oracle.com> References: <5111D374.2090101@oracle.com> <511AB93C.1060003@oracle.com> Message-ID: <34ABB676-C0D4-4FF3-9280-248D2394ADB8@oracle.com> Vote: yes From vladimir.kozlov at oracle.com Tue Feb 12 14:05:44 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Feb 2013 14:05:44 -0800 Subject: CFV: New HSX Committer: Morris Meyer In-Reply-To: <511AB93C.1060003@oracle.com> References: <5111D374.2090101@oracle.com> <511AB93C.1060003@oracle.com> Message-ID: <511ABCB8.10807@oracle.com> Vote: yes On 2/12/13 1:50 PM, Vladimir Kozlov wrote: > I hereby nominate Morris Meyer (OpenJDK user name: morris) to > HSX Committer. > > Morris is a member of the Hotspot Compiler group. He contributed 8 > changesets to HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=morris > > Votes are due by Feb 26, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote From vladimir.x.ivanov at oracle.com Tue Feb 12 15:09:46 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 13 Feb 2013 02:09:46 +0300 Subject: CFV: New HSX Committer: Morris Meyer In-Reply-To: <511AB93C.1060003@oracle.com> References: <5111D374.2090101@oracle.com> <511AB93C.1060003@oracle.com> Message-ID: <511ACBBA.60405@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 2/13/13 12:50 AM, Vladimir Kozlov wrote: > I hereby nominate Morris Meyer (OpenJDK user name: morris) to > HSX Committer. > > Morris is a member of the Hotspot Compiler group. He contributed 8 > changesets to HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=morris > > Votes are due by Feb 26, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > > > From joe.darcy at oracle.com Tue Feb 12 14:20:22 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Tue, 12 Feb 2013 14:20:22 -0800 Subject: Tr : double a%b returns NaN for some (a,b) (|a| < inf, |b|>0) In-Reply-To: <1360694075.66018.YahooMailNeo@web132105.mail.ird.yahoo.com> References: <1360619599.25551.YahooMailNeo@web132105.mail.ird.yahoo.com> <1360620285.76858.YahooMailNeo@web132103.mail.ird.yahoo.com> <51197C04.8070908@oracle.com> <1360694075.66018.YahooMailNeo@web132105.mail.ird.yahoo.com> Message-ID: <511AC026.9080802@oracle.com> Hello, A quick note below, On 2/12/2013 10:34 AM, Jeff Hain wrote: > > Vladimir wrote: >> First, could you show what java versions you tried (java -version)? And what OS you are using? > > On Windows 7/Core i7 980X, it happens with the following 64 bits versions of Java: > - 1.5.0_22-b03 > - 1.6.0_21-ea-b05 > - 1.6.0_29-ea-b08 (and also crashes at some point but this version seems to crash a lot, so might be unrelated) > - 1.6.0_38-b05 ("Java HotSpot(TM) 64-Bit Server VM") > but not with: > - 1.7.0_11-b21 > - 1.8.0-ea-b73 > > > On Windows XP/T2300, it does not happen with: > - 1.6.0_38 > - 1.6.0_39 > - 1.7.0_10 > > > >> Second, could you try to run with -Xint? It will run in Interpreter mode only without JIT compilation. > Still happens. > > > >> Third, run only Client (-client) or Server (-server) VM. It will use different JIT compilers. >> Note, that there is no Client 64bit VM. If you have latest jdk7update (7u10 or 7u12) or jdk8 you can specify next flags to use only Client's JIT compiler: -XX:+TieredCompilation -XX:TieredStopAtLevel=1. > Only using 64 bits VMs. > > > > Here is some code that can reproduce the problem, > and the output I get whether it happens or not: > > > > public class ModNaN { > /* Windows 7/Core i7 980X/1.6.0_38 (64): > NaNs > 8.98846567431158E307 % 1.295163E-318 = NaN > 1.7976931348623157E308 % 2.59032E-318 = NaN > 1.7976931348623157E308 % 1.060997895E-314 = NaN > 1.7976931348623157E308 % 6.767486E-317 = NaN > 1.7976931348623157E308 % 7.528725E-318 = NaN > non-NaNs > 8.98846567431158E307 % 1.29516E-318 = 2.53E-321 > 1.7976931348623157E308 % 2.590327E-318 = 0.0 > 1.7976931348623157E308 % 1.060965516E-314 = 9.35818525E-315 > */ > /* Windows 7/Core i7 980X/1.7.0_11 (64): > NaNs > 8.98846567431158E307 % 1.295163E-318 = 0.0 > 1.7976931348623157E308 % 2.59032E-318 = 2.57135E-318 > 1.7976931348623157E308 % 1.060997895E-314 = 5.31535078E-315 > 1.7976931348623157E308 % 6.767486E-317 = 1.142612E-317 > 1.7976931348623157E308 % 7.528725E-318 = 4.64634E-318 > non-NaNs > 8.98846567431158E307 % 1.29516E-318 = 2.53E-321 > 1.7976931348623157E308 % 2.590327E-318 = 0.0 > 1.7976931348623157E308 % 1.060965516E-314 = 9.35818525E-315 > */ > public static void main(String[] args) { > System.out.println("NaNs"); > for (double[] ab : new double[][]{ > new double[]{Double.longBitsToDouble(0x7FE0000000000000L),Double.longBitsToDouble(0x0000000000040000L)}, > new double[]{Double.longBitsToDouble(0x7FEFFFFFFFFFFFFFL),Double.longBitsToDouble(0x000000000007FFFFL)}, > // > new double[]{Double.longBitsToDouble(0x7FEFFFFFFFFFFFFFL),Double.longBitsToDouble(0x000000007FFFFFFFL)}, > new double[]{Double.longBitsToDouble(0x7FEFFFFFFFFFFFFFL),6.767486E-317}, > new double[]{Double.longBitsToDouble(0x7FEFFFFFFFFFFFFFL),7.528725E-318}, > }) { > double a = ab[0]; > double b = ab[1]; > double mod = a % b; > System.out.println(a+" % "+b+" = "+mod); > } > > System.out.println("non-NaNs"); > for (double[] ab : new double[][]{ > new double[]{Double.longBitsToDouble(0x7FE0000000000000L),Double.longBitsToDouble(0x000000000003FFFFL)}, > new double[]{Double.longBitsToDouble(0x7FEFFFFFFFFFFFFFL),Double.longBitsToDouble(0x0000000000080000L)}, > // > new double[]{Double.longBitsToDouble(0x7FEFFFFFFFFFFFFFL),Double.longBitsToDouble(0x000000007FFEFFFFL)}, > }) { > double a = ab[0]; > double b = ab[1]; > double mod = a % b; > System.out.println(a+" % "+b+" = "+mod); > } > } > } For the non-NaN floating-point values, I recommend using hexadecimal floating-point syntax rather than calling Double.longBitsToDouble on a hex string value; see Double.toHexString for details. And to be clear, the value of the basic arithmetic operations are fully defined by the Java Language Specification in this case so there shouldn't be a difference across platforms, but you can add the "strictfp" modifier to remove one source of possible variance. -Joe From alejandro.murillo at oracle.com Tue Feb 12 14:18:45 2013 From: alejandro.murillo at oracle.com (alejandro murillo) Date: Tue, 12 Feb 2013 15:18:45 -0700 Subject: CFV: New HSX Committer: Morris Meyer In-Reply-To: <511AB93C.1060003@oracle.com> References: <5111D374.2090101@oracle.com> <511AB93C.1060003@oracle.com> Message-ID: <511ABFC5.7050007@oracle.com> vote:yes -- Alejandro From krystal.mo at oracle.com Tue Feb 12 14:26:48 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Tue, 12 Feb 2013 14:26:48 -0800 Subject: CFV: New HSX Committer: Morris Meyer In-Reply-To: <511AB93C.1060003@oracle.com> References: <5111D374.2090101@oracle.com> <511AB93C.1060003@oracle.com> Message-ID: <511AC1A8.8050607@oracle.com> Vote: yes - Kris On 02/12/2013 01:50 PM, Vladimir Kozlov wrote: > I hereby nominate Morris Meyer (OpenJDK user name: morris) to > HSX Committer. > > Morris is a member of the Hotspot Compiler group. He contributed 8 > changesets to HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=morris > > Votes are due by Feb 26, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > > > From jeffhain at rocketmail.com Tue Feb 12 14:52:33 2013 From: jeffhain at rocketmail.com (Jeff Hain) Date: Tue, 12 Feb 2013 22:52:33 +0000 (GMT) Subject: Tr : double a%b returns NaN for some (a,b) (|a| < inf, |b|>0) In-Reply-To: <511AC026.9080802@oracle.com> References: <1360619599.25551.YahooMailNeo@web132105.mail.ird.yahoo.com> <1360620285.76858.YahooMailNeo@web132103.mail.ird.yahoo.com> <51197C04.8070908@oracle.com> <1360694075.66018.YahooMailNeo@web132105.mail.ird.yahoo.com> <511AC026.9080802@oracle.com> Message-ID: <1360709553.65109.YahooMailNeo@web132101.mail.ird.yahoo.com> Joe Darcy wrote: >For the non-NaN floating-point values, I recommend using hexadecimal >floating-point syntax rather than calling Double.longBitsToDouble on a >hex string value; see Double.toHexString for details. It should be more readable for humans indeed, but I guess my transformation into a processor is now irreversible ;) >you can add the "strictfp" modifier to remove one source of possible variance. Still happens with strictfp. (about strictfp, off-topic but I removed it from all my code after someone pointed out it added some overhead (like 20ms+ on 10_000_000 calls micro-benchmarks, so about 2ns+), when having strictfp code call non-strictfp code or the opposite) -Jeff From John.Coomes at oracle.com Tue Feb 12 16:07:50 2013 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 12 Feb 2013 16:07:50 -0800 Subject: CFV: New HSX Committer: Morris Meyer In-Reply-To: <511AB93C.1060003@oracle.com> References: <5111D374.2090101@oracle.com> <511AB93C.1060003@oracle.com> Message-ID: <20762.55638.688645.55868@oracle.com> Vote: yes -John From coleen.phillimore at oracle.com Tue Feb 12 16:50:00 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 12 Feb 2013 16:50:00 -0800 Subject: CFV: New HSX Committer: Morris Meyer In-Reply-To: <511AB93C.1060003@oracle.com> References: <5111D374.2090101@oracle.com> <511AB93C.1060003@oracle.com> Message-ID: <511AE338.3030800@oracle.com> Vote: yes On 2/12/2013 1:50 PM, Vladimir Kozlov wrote: > I hereby nominate Morris Meyer (OpenJDK user name: morris) to > HSX Committer. > > Morris is a member of the Hotspot Compiler group. He contributed 8 > changesets to HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=morris > > Votes are due by Feb 26, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > > > From david.holmes at oracle.com Tue Feb 12 18:02:55 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Feb 2013 12:02:55 +1000 Subject: RFR (S): 8007639: Workaround for ccache in vm.make is incorrect In-Reply-To: <51199C9C.9030909@oracle.com> References: <5115442C.5030309@oracle.com> <51199C9C.9030909@oracle.com> Message-ID: <511AF44F.70401@oracle.com> Oops! Hit reply instead of reply-all. Adding back the lists. On 12/02/2013 11:36 AM, David Holmes wrote: > Hi Mikael, > > So after our side-bar discussions on other ways to tackle this, the only > query I have now is why the original change adjusted CXXFLAGS and this > change adjusts CFLAGS instead? > > Thanks, > David > > On 9/02/2013 4:30 AM, Mikael Vidstedt wrote: >> >> Please review the following change: >> >> Webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8007639/webrev.00/webrev >> Bug: http://bugs.sun.com/view_bug.do?bug_id=8007639 >> >> This change corrects the workaround that was introduced in vm.make for >> enabling ccache for HotSpot builds. The change introduces a file >> specific makefile variable (CFLAGS/) which is used to only set >> the JRE_RELEASE_VERSION define when compiling vm_version.o. >> >> Verified manually by observing command lines with/without fix, also >> passes JPRT. >> >> >> Some additional background below, more information is available in the >> bug report: >> >> To enable the use of ccache 7132779 [1] introduced some new makefile >> logic in vm.make to only pass the JRE_RELEASE_VERSION define when >> compiling the vm_version.cpp file. The underlying reason for that is >> that the JRE_RELEASE_VERSION can in some cases contain a time stamp and >> since ccache checks that the defines match before reusing the cache >> version of the object file that would mean that if the time stamp >> changed all files would have to be recompiled. With the fix only >> vm_version.cpp needs to be recompiled. >> >> This almost works, but the logic introduced in the makefile is actually >> incorrect. Today it looks like this: >> >> >> # This is VERY important! The version define must only be supplied to >> vm_version.o >> # If not, ccache will not re-use the cache at all, since the version >> string might contain >> # a time and date. >> vm_version.o: CXXFLAGS += ${JRE_VERSION} >> >> However, the above syntax does not only add the ${JRE_VERSION} to the >> CXXFLAGS of vm_version.o as originally intended - it also /in some >> cases/ adds it to the CXXFLAGS for any and all prerequisites of >> vm_version.o. And vm_version.o depends on all other object files, which >> means in theory this actually passes in that potentially time stamped >> version string define to all object files anyway. For various reasons in >> reality it only passes it to files that are lexicographically after >> vm_version.o - see bug report for more background on why - but there's >> still a handful of files that will be recompiled unnecessarily. >> >> Cheers, >> Mikael >> >> [1] http://bugs.sun.com/view_bug.do?bug_id=7132779 >> From mikael.vidstedt at oracle.com Tue Feb 12 18:27:22 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 12 Feb 2013 18:27:22 -0800 Subject: RFR (S): 8008081: Print outs do not have matching arguments Message-ID: <511AFA0A.2090504@oracle.com> All, Please review the following change: http://cr.openjdk.java.net/~mikael/webrevs/8008081/webrev.00/webrev Background: I found a few occurrences of calls to print type functions where the arguments do not match the format string. I hope that I have added the right/intended arguments in the respective places but could use some help to verify that that is indeed the case. One special case is in this webrev is jvmtiEnter.xls. Since it is used to generate the jvmtiEnterTrace.cpp file and therefore is a bit less obvious to review I have prepared a pair of before/after files for your convenience: Before: http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.orig After: http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.fixed I also prepared a diff -u of before vs after: http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.diff Passes JPRT. Cheers, Mikael From mikael.vidstedt at oracle.com Tue Feb 12 18:32:37 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 12 Feb 2013 18:32:37 -0800 Subject: RFR (S): 8007639: Workaround for ccache in vm.make is incorrect In-Reply-To: <511AF44F.70401@oracle.com> References: <5115442C.5030309@oracle.com> <51199C9C.9030909@oracle.com> <511AF44F.70401@oracle.com> Message-ID: <511AFB45.6010109@oracle.com> Good catch! There is no fundamental reason for switching to CFLAGS, and since the other defines are added to CXXFLAGS so should this. Updated webrev here: http://cr.openjdk.java.net/~mikael/webrevs/8007639/webrev.01/webrev/ Cheers, Mikael On 2013-02-12 18:02, David Holmes wrote: > Oops! Hit reply instead of reply-all. Adding back the lists. > > On 12/02/2013 11:36 AM, David Holmes wrote: >> Hi Mikael, >> >> So after our side-bar discussions on other ways to tackle this, the only >> query I have now is why the original change adjusted CXXFLAGS and this >> change adjusts CFLAGS instead? >> >> Thanks, >> David >> >> On 9/02/2013 4:30 AM, Mikael Vidstedt wrote: >>> >>> Please review the following change: >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mikael/webrevs/8007639/webrev.00/webrev >>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8007639 >>> >>> This change corrects the workaround that was introduced in vm.make for >>> enabling ccache for HotSpot builds. The change introduces a file >>> specific makefile variable (CFLAGS/) which is used to only set >>> the JRE_RELEASE_VERSION define when compiling vm_version.o. >>> >>> Verified manually by observing command lines with/without fix, also >>> passes JPRT. >>> >>> >>> Some additional background below, more information is available in the >>> bug report: >>> >>> To enable the use of ccache 7132779 [1] introduced some new makefile >>> logic in vm.make to only pass the JRE_RELEASE_VERSION define when >>> compiling the vm_version.cpp file. The underlying reason for that is >>> that the JRE_RELEASE_VERSION can in some cases contain a time stamp and >>> since ccache checks that the defines match before reusing the cache >>> version of the object file that would mean that if the time stamp >>> changed all files would have to be recompiled. With the fix only >>> vm_version.cpp needs to be recompiled. >>> >>> This almost works, but the logic introduced in the makefile is actually >>> incorrect. Today it looks like this: >>> >>> >>> # This is VERY important! The version define must only be supplied to >>> vm_version.o >>> # If not, ccache will not re-use the cache at all, since the version >>> string might contain >>> # a time and date. >>> vm_version.o: CXXFLAGS += ${JRE_VERSION} >>> >>> However, the above syntax does not only add the ${JRE_VERSION} to the >>> CXXFLAGS of vm_version.o as originally intended - it also /in some >>> cases/ adds it to the CXXFLAGS for any and all prerequisites of >>> vm_version.o. And vm_version.o depends on all other object files, which >>> means in theory this actually passes in that potentially time stamped >>> version string define to all object files anyway. For various >>> reasons in >>> reality it only passes it to files that are lexicographically after >>> vm_version.o - see bug report for more background on why - but there's >>> still a handful of files that will be recompiled unnecessarily. >>> >>> Cheers, >>> Mikael >>> >>> [1] http://bugs.sun.com/view_bug.do?bug_id=7132779 >>> From david.holmes at oracle.com Tue Feb 12 18:35:11 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Feb 2013 12:35:11 +1000 Subject: RFR (S): 8007639: Workaround for ccache in vm.make is incorrect In-Reply-To: <511AFB45.6010109@oracle.com> References: <5115442C.5030309@oracle.com> <51199C9C.9030909@oracle.com> <511AF44F.70401@oracle.com> <511AFB45.6010109@oracle.com> Message-ID: <511AFBDF.7090705@oracle.com> Looks okay to me. David On 13/02/2013 12:32 PM, Mikael Vidstedt wrote: > > Good catch! There is no fundamental reason for switching to CFLAGS, and > since the other defines are added to CXXFLAGS so should this. Updated > webrev here: > > http://cr.openjdk.java.net/~mikael/webrevs/8007639/webrev.01/webrev/ > > Cheers, > Mikael > > On 2013-02-12 18:02, David Holmes wrote: >> Oops! Hit reply instead of reply-all. Adding back the lists. >> >> On 12/02/2013 11:36 AM, David Holmes wrote: >>> Hi Mikael, >>> >>> So after our side-bar discussions on other ways to tackle this, the only >>> query I have now is why the original change adjusted CXXFLAGS and this >>> change adjusts CFLAGS instead? >>> >>> Thanks, >>> David >>> >>> On 9/02/2013 4:30 AM, Mikael Vidstedt wrote: >>>> >>>> Please review the following change: >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8007639/webrev.00/webrev >>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8007639 >>>> >>>> This change corrects the workaround that was introduced in vm.make for >>>> enabling ccache for HotSpot builds. The change introduces a file >>>> specific makefile variable (CFLAGS/) which is used to only set >>>> the JRE_RELEASE_VERSION define when compiling vm_version.o. >>>> >>>> Verified manually by observing command lines with/without fix, also >>>> passes JPRT. >>>> >>>> >>>> Some additional background below, more information is available in the >>>> bug report: >>>> >>>> To enable the use of ccache 7132779 [1] introduced some new makefile >>>> logic in vm.make to only pass the JRE_RELEASE_VERSION define when >>>> compiling the vm_version.cpp file. The underlying reason for that is >>>> that the JRE_RELEASE_VERSION can in some cases contain a time stamp and >>>> since ccache checks that the defines match before reusing the cache >>>> version of the object file that would mean that if the time stamp >>>> changed all files would have to be recompiled. With the fix only >>>> vm_version.cpp needs to be recompiled. >>>> >>>> This almost works, but the logic introduced in the makefile is actually >>>> incorrect. Today it looks like this: >>>> >>>> >>>> # This is VERY important! The version define must only be supplied to >>>> vm_version.o >>>> # If not, ccache will not re-use the cache at all, since the version >>>> string might contain >>>> # a time and date. >>>> vm_version.o: CXXFLAGS += ${JRE_VERSION} >>>> >>>> However, the above syntax does not only add the ${JRE_VERSION} to the >>>> CXXFLAGS of vm_version.o as originally intended - it also /in some >>>> cases/ adds it to the CXXFLAGS for any and all prerequisites of >>>> vm_version.o. And vm_version.o depends on all other object files, which >>>> means in theory this actually passes in that potentially time stamped >>>> version string define to all object files anyway. For various >>>> reasons in >>>> reality it only passes it to files that are lexicographically after >>>> vm_version.o - see bug report for more background on why - but there's >>>> still a handful of files that will be recompiled unnecessarily. >>>> >>>> Cheers, >>>> Mikael >>>> >>>> [1] http://bugs.sun.com/view_bug.do?bug_id=7132779 >>>> > From staffan.larsen at oracle.com Wed Feb 13 00:24:13 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 13 Feb 2013 09:24:13 +0100 Subject: CFV: New HSX Committer: Morris Meyer In-Reply-To: <511AB93C.1060003@oracle.com> References: <5111D374.2090101@oracle.com> <511AB93C.1060003@oracle.com> Message-ID: <16297AED-53F3-4344-944F-5875F9CB8DAD@oracle.com> Vote: yes. /Staffan On 12 feb 2013, at 22:50, Vladimir Kozlov wrote: > I hereby nominate Morris Meyer (OpenJDK user name: morris) to > HSX Committer. > > Morris is a member of the Hotspot Compiler group. He contributed 8 changesets to HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=morris > > Votes are due by Feb 26, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > > > From roland.westrelin at oracle.com Wed Feb 13 01:06:33 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 13 Feb 2013 10:06:33 +0100 Subject: CFV: New HSX Committer: Morris Meyer In-Reply-To: <511AB93C.1060003@oracle.com> References: <5111D374.2090101@oracle.com> <511AB93C.1060003@oracle.com> Message-ID: <87liasa8h2.fsf@oracle.com> Vote: yes Roland. From roland.westrelin at oracle.com Wed Feb 13 02:59:04 2013 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Wed, 13 Feb 2013 10:59:04 +0000 Subject: hg: hsx/hsx24/hotspot: 8007144: Incremental inlining mistakes some call sites for dead ones and doesn't inline them Message-ID: <20130213105913.CE5C947A18@hg.openjdk.java.net> Changeset: 6545f607320f Author: roland Date: 2013-02-04 11:30 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6545f607320f 8007144: Incremental inlining mistakes some call sites for dead ones and doesn't inline them Summary: wrong detection for dead call sites. Reviewed-by: kvn ! src/share/vm/opto/callGenerator.cpp From ach at quartetfs.com Wed Feb 13 05:42:13 2013 From: ach at quartetfs.com (Antoine Chambille) Date: Wed, 13 Feb 2013 14:42:13 +0100 Subject: NUMA-Aware Java Heaps for in-memory databases Message-ID: We are developing a Java in-memory analytical database (it's called "ActivePivot") that our customers deploy on ever larger datasets. Some ActivePivot instances are deployed on java heaps close to 1TB, on NUMA servers (typically 4 Xeon processors and 4 NUMA nodes). This is becoming a trend, and we are researching solutions to improve our performance on NUMA configurations. We understand that in the current state of things (and including JDK8) the support for NUMA in hotspot is the following: * The young generation heap layout can be NUMA-Aware (partitioned per NUMA node, objects allocated in the same node than the running thread) * The old generation heap layout is not optimized for NUMA (at best the old generation is interleaved among nodes which at least makes memory accesses somewhat uniform) * The parallel garbage collector is NUMA optimized, the GC threads focusing on objects in their node. Yet activating -XX:+UseNUMA option has almost no impact on the performance of our in-memory database. It is not surprising, the pattern for a database is to load the data in the memory and then make queries on it. The data goes and stays in the old generation, and it is read from there by queries. Most memory accesses are in the old gen and most of those are not local. I guess there is a reason hotspot does not yet optimize the old generation for NUMA. It must be very difficult to do it in the general case, when you have no idea what thread from what node will read data and interleaving is. But for an in-memory database this is frustrating because we know very well which threads will access which piece of data. At least in ActivePivot data structures are partitioned, partitions are each assigned a thread pool so the threads that allocated the data in a partition are also the threads that perform sub-queries on that partition. We are a few lines of code away from binding thread pools to NUMA nodes, and if the garbage collector would leave objects promoted to the old generation on their original NUMA node memory accesses would be close to optimal. We have not been able to do that. But that being said I read an inspiring 2005 article from Mustafa M. Tikir and Jeffrey K. Hollingsworth that did experiment on NUMA layouts for the old generation. ("NUMA-aware Java heaps for server applications" http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.6587&rep=rep1&type=pdf). That motivated me to ask questions in this mailing list: * Are there hidden or experimental hotspot options that allow NUMA-Aware partitioning of the old generation? * Do you know why there isn't much (visible, generally available) progress on NUMA optimizations for the old gen? Is the Java in-memory database use case considered a rare one? * Maybe we at Quartet FS should experiment and even contribute new heap layouts to the open-jdk project. Can you comment on the difficulty of that? Thanks for reading, and Best Regards, -- Antoine CHAMBILLE Director Research & Development Quartet FS From zhengyu.gu at oracle.com Wed Feb 13 09:46:32 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 13 Feb 2013 12:46:32 -0500 Subject: CFV: New HSX Committer: Morris Meyer In-Reply-To: <511AB93C.1060003@oracle.com> References: <5111D374.2090101@oracle.com> <511AB93C.1060003@oracle.com> Message-ID: <511BD178.8090009@oracle.com> Vote: yes -Zhengyu On 2/12/2013 4:50 PM, Vladimir Kozlov wrote: > I hereby nominate Morris Meyer (OpenJDK user name: morris) to > HSX Committer. > > Morris is a member of the Hotspot Compiler group. He contributed 8 > changesets to HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=morris > > Votes are due by Feb 26, 2013. > > Only current HSX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > > > From rkennke at redhat.com Wed Feb 13 11:40:20 2013 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 13 Feb 2013 20:40:20 +0100 Subject: [RFC] Fast-bytecodes for Zero Message-ID: <1360784420.2524.31.camel@mercury> The following change implements support for the following fast-bytecodes in the Zero interpreter: fast_agetfield fast_bgetfield fast_cgetfield fast_dgetfield fast_fgetfield fast_igetfield fast_lgetfield fast_sgetfield fast_aputfield fast_bputfield fast_cputfield fast_dputfield fast_fputfield fast_iputfield fast_lputfield fast_sputfield fast_aload_0 fast_iaccess_0 fast_aaccess_0 fast_faccess_0 fast_iload fast_iload2 fast_icaload fast_invokevfinal All together this leads to a speedup of the interpreter of about 25%. Some notes: - I extracted the JVMTI related blocks into a macro to avoid repetition. - The field get/put opcodes are only rewritten for non-volatile non-static field access, this makes the fast one really fast (no additional branches needed), and static/volatile field accesses seem rare enough anyway. http://cr.openjdk.java.net/~rkennke/zero-fast-opcodes/webrev.00/ Opinions? Can this be included in hotspot? And Can I have a bug-ID? Best regards, Roman From christian.thalinger at oracle.com Wed Feb 13 12:23:04 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 13 Feb 2013 12:23:04 -0800 Subject: CFV: New HSX Committer: Morris Meyer In-Reply-To: <511AB93C.1060003@oracle.com> References: <5111D374.2090101@oracle.com> <511AB93C.1060003@oracle.com> Message-ID: <0270CDED-460F-4385-9672-615E126F565F@oracle.com> Vote: yes On Feb 12, 2013, at 1:50 PM, Vladimir Kozlov wrote: > I hereby nominate Morris Meyer (OpenJDK user name: morris) to > HSX Committer. > > Morris is a member of the Hotspot Compiler group. He contributed 8 changesets to HSX project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=morris > > Votes are due by Feb 26, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > > > From christian.thalinger at oracle.com Wed Feb 13 12:26:26 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 13 Feb 2013 12:26:26 -0800 Subject: Request for review (XS): JDK-8006430: TraceTypeProfile is a product flag while it should be a diagnostic flag In-Reply-To: <9F15BEC4-47F1-4529-B395-853D272FE54C@oracle.com> References: <5115A51F.2070102@oracle.com> <9F15BEC4-47F1-4529-B395-853D272FE54C@oracle.com> Message-ID: On Feb 11, 2013, at 12:57 AM, Staffan Larsen wrote: > Forgive my ignorance, but why do diagnostic and experimental flags have different "kinds" depending on what part of the VM they belong to? Can't they all be just "{experimental}" or "{diagnostic}"? I don't see where the additional C1/C2/ARCH/Shark information is used. Are you asking why we have experimental and diagnostic flags? -- Chris > > Thanks, > /Staffan > > On 9 feb 2013, at 02:23, Krystal Mo wrote: > >> Hi all, >> >> Could I have a couple of reviews for this fix, please? >> >> Webrev: http://cr.openjdk.java.net/~kmo/8006430/webrev.00/ >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006430 >> >> This bug is actually not a regression from JDK-7198499, but a long time issue that C2 diagnostic flags were never treated as being "diagnostic" since the OpenJDK Mercurial repo history began (duke at 0). >> >> The problem is, C2 diagnostic flags have the kind "{C2 diagnostic}", but Flag::is_unlocked() only cared to test "{diagnostic}". >> So the fix is straighforward -- find out how many other "diagnostic" and "experimental" flag kinds there are, and check them. >> >> I didn't just check if the string ends with "diagnostic}" or "experimental}" because I think that's too permissive, but I don't have a strong opinion on that. >> If reviews form a consensus that checking just the postfix is good enough, I can make the change that way. >> >> Care has to be taken if new diagnostic/experimental flag kinds are added to other components in the future, e.g. C1. >> >> Tested with JPRT and these flags by hand: >> C2 diagnostic: TraceTypeProfile, LoopLimitCheck, RangeLimitCheck >> ARCH diagnostic: UseIncDec >> >> Thanks, >> Kris > From christian.thalinger at oracle.com Wed Feb 13 12:28:14 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 13 Feb 2013 12:28:14 -0800 Subject: Bad licensing header on testcase in HotSpot repositories In-Reply-To: <1978457656.909025.1360610989660.JavaMail.root@redhat.com> References: <1978457656.909025.1360610989660.JavaMail.root@redhat.com> Message-ID: <3C3DF1AB-6A85-4710-964F-B8071E0C2B88@oracle.com> On Feb 11, 2013, at 11:29 AM, Andrew Hughes wrote: > The file: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/fe4a4ea5bed9/test/runtime/7158804/Test7158804.sh > > has a bad copyright header with just: > > # Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved. > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > and no mention of a license. The same file also appears in the jdk7u repositories: > > http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/tip/test/runtime/7158804/Test7158804.sh > > and so will need correcting in both places. Thanks for noticing. Keith, can you add the appropriate headers? -- Chris > -- > 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 christian.thalinger at oracle.com Wed Feb 13 12:32:45 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 13 Feb 2013 12:32:45 -0800 Subject: Bad licensing header on testcase in HotSpot repositories In-Reply-To: <3C3DF1AB-6A85-4710-964F-B8071E0C2B88@oracle.com> References: <1978457656.909025.1360610989660.JavaMail.root@redhat.com> <3C3DF1AB-6A85-4710-964F-B8071E0C2B88@oracle.com> Message-ID: On Feb 13, 2013, at 12:28 PM, Christian Thalinger wrote: > > On Feb 11, 2013, at 11:29 AM, Andrew Hughes wrote: > >> The file: >> >> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/fe4a4ea5bed9/test/runtime/7158804/Test7158804.sh >> >> has a bad copyright header with just: >> >> # Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved. >> # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> >> and no mention of a license. The same file also appears in the jdk7u repositories: >> >> http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/tip/test/runtime/7158804/Test7158804.sh >> >> and so will need correcting in both places. > > Thanks for noticing. Keith, can you add the appropriate headers? Oops. Forgot that Keith left Oracle last year. I filed: 8008169: test/runtime/7158804/Test7158804.sh has bad copyright header with the runtime team. -- Chris > > -- Chris > >> -- >> 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 dmitry.samersoff at oracle.com Wed Feb 13 14:27:01 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Wed, 13 Feb 2013 22:27:01 +0000 Subject: hg: hsx/hotspot-main/hotspot: 13 new changesets Message-ID: <20130213222728.4D63847A5C@hg.openjdk.java.net> Changeset: 8d9fc28831cc Author: dcubed Date: 2013-02-06 14:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8d9fc28831cc 7182152: Instrumentation hot swap test incorrect monitor count Summary: Add/refine new tracing support using -XX:TraceRedefineClasses=16384. Reviewed-by: coleenp, acorn, sspitsyn ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.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/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/prims/jvmtiRedefineClassesTrace.hpp ! src/share/vm/utilities/accessFlags.cpp ! src/share/vm/utilities/accessFlags.hpp Changeset: 3a88007634b0 Author: ctornqvi Date: 2013-02-08 10:42 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3a88007634b0 8007434: Write tests for 8006298 Summary: Four tests written for 8006298 Reviewed-by: mgerdin, coleenp + test/runtime/CommandLine/BooleanFlagWithInvalidValue.java + test/runtime/CommandLine/FlagWithInvalidValue.java + test/runtime/CommandLine/NonBooleanFlagWithInvalidBooleanPrefix.java + test/runtime/CommandLine/UnrecognizedVMOption.java Changeset: 758935f7c23f Author: sla Date: 2013-02-08 12:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/758935f7c23f 8006423: SA: NullPointerException in sun.jvm.hotspot.debugger.bsd.BsdThread.getContext(BsdThread.java:67) Summary: Do not rely on mach thread port names to identify threads from SA Reviewed-by: dholmes, minqi, rbackman ! agent/src/os/bsd/MacosxDebuggerLocal.m ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_amd64/BsdAMD64JavaThreadPDAccess.java ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp Changeset: 7194f764221c Author: sla Date: 2013-02-08 14:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7194f764221c Merge Changeset: 461a3adac4d1 Author: sspitsyn Date: 2013-02-08 09:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/461a3adac4d1 Merge ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp Changeset: 8bf62bd86a4e Author: zgu Date: 2013-02-08 14:49 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8bf62bd86a4e 8007791: More Restricted hs_err file permission Summary: Enforce more restricted hs_file permission Reviewed-by: acorn, dcubed, dsamersoff ! src/share/vm/utilities/vmError.cpp Changeset: 1ba5b18088a8 Author: zgu Date: 2013-02-08 14:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1ba5b18088a8 Merge Changeset: 41d73c9b30a8 Author: zgu Date: 2013-02-08 16:31 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/41d73c9b30a8 8006691: Remove jvm_version_info.is_kernel_jvm field Summary: Removed is_kernel_jvm from jvm_version_info as Kernel VM has been deprecated Reviewed-by: mchung, coleenp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 3f11b37f047c Author: zgu Date: 2013-02-08 13:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3f11b37f047c Merge Changeset: f989aff6946f Author: zgu Date: 2013-02-08 16:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f989aff6946f Merge Changeset: 927a311d00f9 Author: coleenp Date: 2013-02-11 14:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/927a311d00f9 8007320: NPG: move method annotations Summary: allocate method annotations and attach to ConstMethod if present Reviewed-by: dcubed, jiangli, sspitsyn, iklam ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/annotations.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/vmStructs.cpp + test/runtime/8007320/ConstMethodTest.java Changeset: 5ee2b330eacd Author: zgu Date: 2013-02-12 12:19 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5ee2b330eacd 8007950: Undo hs_file permission change Summary: Reverse hs_err file permission back to 0666, as early push was premature Reviewed-by: dsamersoff, dcubed, acorn ! src/share/vm/utilities/vmError.cpp Changeset: deb43b8a436e Author: sspitsyn Date: 2013-02-13 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/deb43b8a436e Merge From krystal.mo at oracle.com Wed Feb 13 18:02:29 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Wed, 13 Feb 2013 18:02:29 -0800 Subject: Request for review (XS): JDK-8006430: TraceTypeProfile is a product flag while it should be a diagnostic flag In-Reply-To: References: <5115A51F.2070102@oracle.com> <9F15BEC4-47F1-4529-B395-853D272FE54C@oracle.com> Message-ID: <511C45B5.2000202@oracle.com> Hi Chris, I think Staffan is asking why we differentiate {C2 diagnostic} and friends from {diagnostic}. - Kris On 02/13/2013 12:26 PM, Christian Thalinger wrote: > On Feb 11, 2013, at 12:57 AM, Staffan Larsen wrote: > >> Forgive my ignorance, but why do diagnostic and experimental flags have different "kinds" depending on what part of the VM they belong to? Can't they all be just "{experimental}" or "{diagnostic}"? I don't see where the additional C1/C2/ARCH/Shark information is used. > Are you asking why we have experimental and diagnostic flags? > > -- Chris > >> Thanks, >> /Staffan >> >> On 9 feb 2013, at 02:23, Krystal Mo wrote: >> >>> Hi all, >>> >>> Could I have a couple of reviews for this fix, please? >>> >>> Webrev: http://cr.openjdk.java.net/~kmo/8006430/webrev.00/ >>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006430 >>> >>> This bug is actually not a regression from JDK-7198499, but a long time issue that C2 diagnostic flags were never treated as being "diagnostic" since the OpenJDK Mercurial repo history began (duke at 0). >>> >>> The problem is, C2 diagnostic flags have the kind "{C2 diagnostic}", but Flag::is_unlocked() only cared to test "{diagnostic}". >>> So the fix is straighforward -- find out how many other "diagnostic" and "experimental" flag kinds there are, and check them. >>> >>> I didn't just check if the string ends with "diagnostic}" or "experimental}" because I think that's too permissive, but I don't have a strong opinion on that. >>> If reviews form a consensus that checking just the postfix is good enough, I can make the change that way. >>> >>> Care has to be taken if new diagnostic/experimental flag kinds are added to other components in the future, e.g. C1. >>> >>> Tested with JPRT and these flags by hand: >>> C2 diagnostic: TraceTypeProfile, LoopLimitCheck, RangeLimitCheck >>> ARCH diagnostic: UseIncDec >>> >>> Thanks, >>> Kris From rickard.backman at oracle.com Thu Feb 14 03:16:20 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Thu, 14 Feb 2013 11:16:20 +0000 Subject: hg: hsx/hsx24/hotspot: 8008088: SA can hang the VM Message-ID: <20130214111626.D53D247A71@hg.openjdk.java.net> Changeset: f016e64be7b4 Author: rbackman Date: 2013-02-13 09:46 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f016e64be7b4 8008088: SA can hang the VM Reviewed-by: mgronlun, sla, dholmes ! agent/src/os/bsd/libproc_impl.c ! agent/src/os/bsd/libproc_impl.h ! agent/src/os/bsd/ps_proc.c ! agent/src/os/linux/libproc_impl.c ! agent/src/os/linux/libproc_impl.h ! agent/src/os/linux/ps_proc.c From staffan.larsen at oracle.com Thu Feb 14 04:04:30 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 14 Feb 2013 13:04:30 +0100 Subject: Request for review (XS): JDK-8006430: TraceTypeProfile is a product flag while it should be a diagnostic flag In-Reply-To: <511C45B5.2000202@oracle.com> References: <5115A51F.2070102@oracle.com> <9F15BEC4-47F1-4529-B395-853D272FE54C@oracle.com> <511C45B5.2000202@oracle.com> Message-ID: <3A2F2C9E-0982-47C2-826E-EF08158F9B0C@oracle.com> Yes, exactly. /Staffan On 14 feb 2013, at 03:02, Krystal Mo wrote: > Hi Chris, > > I think Staffan is asking why we differentiate {C2 diagnostic} and friends from {diagnostic}. > > - Kris > > On 02/13/2013 12:26 PM, Christian Thalinger wrote: >> On Feb 11, 2013, at 12:57 AM, Staffan Larsen wrote: >> >>> Forgive my ignorance, but why do diagnostic and experimental flags have different "kinds" depending on what part of the VM they belong to? Can't they all be just "{experimental}" or "{diagnostic}"? I don't see where the additional C1/C2/ARCH/Shark information is used. >> Are you asking why we have experimental and diagnostic flags? >> >> -- Chris >> >>> Thanks, >>> /Staffan >>> >>> On 9 feb 2013, at 02:23, Krystal Mo wrote: >>> >>>> Hi all, >>>> >>>> Could I have a couple of reviews for this fix, please? >>>> >>>> Webrev: http://cr.openjdk.java.net/~kmo/8006430/webrev.00/ >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006430 >>>> >>>> This bug is actually not a regression from JDK-7198499, but a long time issue that C2 diagnostic flags were never treated as being "diagnostic" since the OpenJDK Mercurial repo history began (duke at 0). >>>> >>>> The problem is, C2 diagnostic flags have the kind "{C2 diagnostic}", but Flag::is_unlocked() only cared to test "{diagnostic}". >>>> So the fix is straighforward -- find out how many other "diagnostic" and "experimental" flag kinds there are, and check them. >>>> >>>> I didn't just check if the string ends with "diagnostic}" or "experimental}" because I think that's too permissive, but I don't have a strong opinion on that. >>>> If reviews form a consensus that checking just the postfix is good enough, I can make the change that way. >>>> >>>> Care has to be taken if new diagnostic/experimental flag kinds are added to other components in the future, e.g. C1. >>>> >>>> Tested with JPRT and these flags by hand: >>>> C2 diagnostic: TraceTypeProfile, LoopLimitCheck, RangeLimitCheck >>>> ARCH diagnostic: UseIncDec >>>> >>>> Thanks, >>>> Kris > From bengt.rutisson at oracle.com Thu Feb 14 04:19:12 2013 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Thu, 14 Feb 2013 12:19:12 +0000 Subject: hg: hsx/hotspot-main/hotspot: 8 new changesets Message-ID: <20130214121929.AFA4D47A74@hg.openjdk.java.net> Changeset: bce1ac447f6b Author: johnc Date: 2013-02-06 14:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bce1ac447f6b 7052429: G1: Avoid unnecessary scanning of humongous regions during concurrent marking Summary: Skip unnecessary scanning of bitmap for unmarked humongous objects/regions. Reviewed-by: jwilhelm, johnc Contributed-by: Tao Mao ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/runtime/globals.hpp Changeset: f64ffbf81af5 Author: jwilhelm Date: 2013-02-07 15:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f64ffbf81af5 8006432: Ratio flags should be unsigned Summary: Flags changed to be of uintx type Reviewed-by: johnc, tamao ! src/cpu/zero/vm/shark_globals_zero.hpp ! src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 5d8325eb8240 Author: brutisso Date: 2013-02-07 22:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5d8325eb8240 Merge ! src/share/vm/runtime/thread.cpp Changeset: 9425ba04792d Author: brutisso Date: 2013-02-07 18:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9425ba04792d Merge - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java - make/solaris/makefiles/kernel.make ! src/share/vm/runtime/arguments.cpp - test/runtime/7158988/TestFieldMonitor.sh Changeset: ad747ee9d0b1 Author: brutisso Date: 2013-02-10 21:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ad747ee9d0b1 8002144: G1: large number of evacuation failures may lead to large c heap memory usage Summary: Use Stack<> instead of GrowableArray to keep track of preserved marks. Also reviewed by vitalyd at gmail.com. Reviewed-by: johnc, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 5e401ef52ec0 Author: johnc Date: 2013-02-11 15:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5e401ef52ec0 8007772: G1: assert(!hr->isHumongous() || mr.start() == hr->bottom()) failed: the start of HeapRegion and MemRegion should be consistent for humongous regions Summary: In do_marking_step(), we should always give up current region after scanning the object, if the region is humongous. Reviewed-by: brutisso, jwilhelm, tamao ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: a83cd101fd62 Author: jmasa Date: 2013-01-23 19:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a83cd101fd62 8005452: NPG: Create new flags for Metaspace resizing policy Reviewed-by: johnc, jwilhelm, coleenp, stefank ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: b8d5d7a6c94c Author: brutisso Date: 2013-02-14 11:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b8d5d7a6c94c Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/thread.cpp From poonam.bajaj at oracle.com Wed Feb 13 22:32:08 2013 From: poonam.bajaj at oracle.com (poonam.bajaj at oracle.com) Date: Thu, 14 Feb 2013 06:32:08 +0000 Subject: hg: hsx/hsx24/hotspot: 8006837: Missing call to cr() when printing entry_point in nmethod, in os::print_location Message-ID: <20130214063213.2F80947A69@hg.openjdk.java.net> Changeset: 79d04b85fd0d Author: poonam Date: 2013-02-13 06:06 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/79d04b85fd0d 8006837: Missing call to cr() when printing entry_point in nmethod, in os::print_location Reviewed-by: stefank, poonam, kvn Contributed-by: sergey.gabdurakhmanov at oracle.com ! src/share/vm/runtime/os.cpp From vladimir.x.ivanov at oracle.com Thu Feb 14 08:33:21 2013 From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com) Date: Thu, 14 Feb 2013 16:33:21 +0000 Subject: hg: hsx/hotspot-main/hotspot: 11 new changesets Message-ID: <20130214163344.DCC2B47A90@hg.openjdk.java.net> Changeset: 91a23b11d8dc Author: kvn Date: 2013-02-08 15:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/91a23b11d8dc 8007708: compiler/6855215 assert(VM_Version::supports_sse4_2()) Summary: Added missing UseSSE42 check. Also added missing avx2 assert for vpermq instruction. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp Changeset: 309460dcedf7 Author: morris Date: 2013-02-08 15:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/309460dcedf7 8006851: When TieredCompilation is set, max code cache should be bumped to 256mb Summary: Set ReservedCodeCacheSize to (default value)*5 when TieredCompilation is on. Reviewed-by: kvn, twisti ! src/share/vm/runtime/arguments.cpp Changeset: 2c673161698a Author: drchase Date: 2013-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2c673161698a 8007402: Code cleanup to remove Parfait false positive Summary: add array access range check Reviewed-by: kvn ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp Changeset: 64d2a0a39954 Author: kmo Date: 2013-02-10 22:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/64d2a0a39954 8006430: TraceTypeProfile is a product flag while it should be a diagnostic flag Summary: make sure all diagnostic and experimental flag kinds are checked in Flag::is_unlocked() Reviewed-by: kvn ! src/share/vm/runtime/globals.cpp Changeset: a9c29dfc7d73 Author: morris Date: 2013-02-11 10:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a9c29dfc7d73 8003251: ARM: move MacroAssembler into separate file Summary: moved MacroAssembler into separate file Reviewed-by: twisti, kvn, dlong ! src/share/vm/asm/macroAssembler.hpp ! src/share/vm/asm/macroAssembler.inline.hpp Changeset: 1e5e28bac299 Author: morris Date: 2013-02-11 14:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1e5e28bac299 8003252: PPC: move MacroAssembler into separate file Summary: moved MacroAssembler into separate file Reviewed-by: twisti, kvn, dlong ! src/share/vm/asm/macroAssembler.hpp ! src/share/vm/asm/macroAssembler.inline.hpp Changeset: 8b3da8d14c93 Author: roland Date: 2013-02-12 12:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8b3da8d14c93 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob Summary: Add support for expensive nodes. Reviewed-by: kvn ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/subnode.hpp Changeset: c703f9c4b025 Author: kmo Date: 2013-02-12 07:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c703f9c4b025 8002169: TEST_BUG: compiler/7009359/Test7009359.java sometimes times out Summary: make the test less prone to timeout by reducing the amount of iteration and allowing main to be compiled Reviewed-by: jrose ! test/compiler/7009359/Test7009359.java Changeset: aaad39923cdb Author: kmo Date: 2013-02-12 14:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/aaad39923cdb Merge Changeset: 12e01444ca2d Author: iignatyev Date: 2013-02-13 08:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/12e01444ca2d 8006683: Add WhiteBox API to testing of compiler Reviewed-by: kvn, vlivanov ! src/share/tools/whitebox/sun/hotspot/WhiteBox.java ! src/share/vm/prims/wbtestmethods/parserTests.hpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/prims/whitebox.hpp + test/compiler/whitebox/CompilerWhiteBoxTest.java + test/compiler/whitebox/DeoptimizeAllTest.java + test/compiler/whitebox/DeoptimizeMethodTest.java + test/compiler/whitebox/IsMethodCompilableTest.java + test/compiler/whitebox/MakeMethodNotCompilableTest.java + test/compiler/whitebox/SetDontInlineMethodTest.java Changeset: 1cdf241a4b26 Author: vlivanov Date: 2013-02-14 05:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1cdf241a4b26 Merge ! src/share/vm/runtime/arguments.cpp From erik.helin at oracle.com Thu Feb 14 09:01:06 2013 From: erik.helin at oracle.com (erik.helin at oracle.com) Date: Thu, 14 Feb 2013 17:01:06 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130214170110.8179D47A91@hg.openjdk.java.net> Changeset: d05fee30c170 Author: ehelin Date: 2013-02-07 19:07 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d05fee30c170 8006954: GC Cause equals No GC for CMS background collection in the trace GC event Reviewed-by: stefank, brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/gc_interface/gcCause.hpp Changeset: 38d1bd11fb2d Author: ehelin Date: 2013-02-14 16:04 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/38d1bd11fb2d Merge From vladimir.kozlov at oracle.com Thu Feb 14 09:45:54 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Feb 2013 09:45:54 -0800 Subject: Request for review (XS): JDK-8006430: TraceTypeProfile is a product flag while it should be a diagnostic flag In-Reply-To: <3A2F2C9E-0982-47C2-826E-EF08158F9B0C@oracle.com> References: <5115A51F.2070102@oracle.com> <9F15BEC4-47F1-4529-B395-853D272FE54C@oracle.com> <511C45B5.2000202@oracle.com> <3A2F2C9E-0982-47C2-826E-EF08158F9B0C@oracle.com> Message-ID: <511D22D2.5040006@oracle.com> It is done to separate flags per component (where a flag is defined) when we print them (-XX:+PrintFlagsInitial, -XX:+PrintFlagsFinal): bool TraceTypeProfile = false {C2 diagnostic} Yes, we can extend Flag struct to separate 'kind' and 'component' (or whatever). Could be good task for new members of Hotspot group. Vladimir On 2/14/13 4:04 AM, Staffan Larsen wrote: > Yes, exactly. > > /Staffan > > On 14 feb 2013, at 03:02, Krystal Mo wrote: > >> Hi Chris, >> >> I think Staffan is asking why we differentiate {C2 diagnostic} and friends from {diagnostic}. >> >> - Kris >> >> On 02/13/2013 12:26 PM, Christian Thalinger wrote: >>> On Feb 11, 2013, at 12:57 AM, Staffan Larsen wrote: >>> >>>> Forgive my ignorance, but why do diagnostic and experimental flags have different "kinds" depending on what part of the VM they belong to? Can't they all be just "{experimental}" or "{diagnostic}"? I don't see where the additional C1/C2/ARCH/Shark information is used. >>> Are you asking why we have experimental and diagnostic flags? >>> >>> -- Chris >>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 9 feb 2013, at 02:23, Krystal Mo wrote: >>>> >>>>> Hi all, >>>>> >>>>> Could I have a couple of reviews for this fix, please? >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~kmo/8006430/webrev.00/ >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006430 >>>>> >>>>> This bug is actually not a regression from JDK-7198499, but a long time issue that C2 diagnostic flags were never treated as being "diagnostic" since the OpenJDK Mercurial repo history began (duke at 0). >>>>> >>>>> The problem is, C2 diagnostic flags have the kind "{C2 diagnostic}", but Flag::is_unlocked() only cared to test "{diagnostic}". >>>>> So the fix is straighforward -- find out how many other "diagnostic" and "experimental" flag kinds there are, and check them. >>>>> >>>>> I didn't just check if the string ends with "diagnostic}" or "experimental}" because I think that's too permissive, but I don't have a strong opinion on that. >>>>> If reviews form a consensus that checking just the postfix is good enough, I can make the change that way. >>>>> >>>>> Care has to be taken if new diagnostic/experimental flag kinds are added to other components in the future, e.g. C1. >>>>> >>>>> Tested with JPRT and these flags by hand: >>>>> C2 diagnostic: TraceTypeProfile, LoopLimitCheck, RangeLimitCheck >>>>> ARCH diagnostic: UseIncDec >>>>> >>>>> Thanks, >>>>> Kris >> > From mikael.vidstedt at oracle.com Thu Feb 14 09:48:03 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 14 Feb 2013 09:48:03 -0800 Subject: RFR (S): 8007639: Workaround for ccache in vm.make is incorrect In-Reply-To: <511AFBDF.7090705@oracle.com> References: <5115442C.5030309@oracle.com> <51199C9C.9030909@oracle.com> <511AF44F.70401@oracle.com> <511AFB45.6010109@oracle.com> <511AFBDF.7090705@oracle.com> Message-ID: <511D2353.6030209@oracle.com> Erik/David - Thanks for the reviews! Cheers, Mikael On 2/12/2013 6:35 PM, David Holmes wrote: > Looks okay to me. > > David > > On 13/02/2013 12:32 PM, Mikael Vidstedt wrote: >> >> Good catch! There is no fundamental reason for switching to CFLAGS, and >> since the other defines are added to CXXFLAGS so should this. Updated >> webrev here: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8007639/webrev.01/webrev/ >> >> Cheers, >> Mikael >> >> On 2013-02-12 18:02, David Holmes wrote: >>> Oops! Hit reply instead of reply-all. Adding back the lists. >>> >>> On 12/02/2013 11:36 AM, David Holmes wrote: >>>> Hi Mikael, >>>> >>>> So after our side-bar discussions on other ways to tackle this, the >>>> only >>>> query I have now is why the original change adjusted CXXFLAGS and this >>>> change adjusts CFLAGS instead? >>>> >>>> Thanks, >>>> David >>>> >>>> On 9/02/2013 4:30 AM, Mikael Vidstedt wrote: >>>>> >>>>> Please review the following change: >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8007639/webrev.00/webrev >>>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8007639 >>>>> >>>>> This change corrects the workaround that was introduced in vm.make >>>>> for >>>>> enabling ccache for HotSpot builds. The change introduces a file >>>>> specific makefile variable (CFLAGS/) which is used to only >>>>> set >>>>> the JRE_RELEASE_VERSION define when compiling vm_version.o. >>>>> >>>>> Verified manually by observing command lines with/without fix, also >>>>> passes JPRT. >>>>> >>>>> >>>>> Some additional background below, more information is available in >>>>> the >>>>> bug report: >>>>> >>>>> To enable the use of ccache 7132779 [1] introduced some new makefile >>>>> logic in vm.make to only pass the JRE_RELEASE_VERSION define when >>>>> compiling the vm_version.cpp file. The underlying reason for that is >>>>> that the JRE_RELEASE_VERSION can in some cases contain a time >>>>> stamp and >>>>> since ccache checks that the defines match before reusing the cache >>>>> version of the object file that would mean that if the time stamp >>>>> changed all files would have to be recompiled. With the fix only >>>>> vm_version.cpp needs to be recompiled. >>>>> >>>>> This almost works, but the logic introduced in the makefile is >>>>> actually >>>>> incorrect. Today it looks like this: >>>>> >>>>> >>>>> # This is VERY important! The version define must only be supplied to >>>>> vm_version.o >>>>> # If not, ccache will not re-use the cache at all, since the version >>>>> string might contain >>>>> # a time and date. >>>>> vm_version.o: CXXFLAGS += ${JRE_VERSION} >>>>> >>>>> However, the above syntax does not only add the ${JRE_VERSION} to the >>>>> CXXFLAGS of vm_version.o as originally intended - it also /in some >>>>> cases/ adds it to the CXXFLAGS for any and all prerequisites of >>>>> vm_version.o. And vm_version.o depends on all other object files, >>>>> which >>>>> means in theory this actually passes in that potentially time stamped >>>>> version string define to all object files anyway. For various >>>>> reasons in >>>>> reality it only passes it to files that are lexicographically after >>>>> vm_version.o - see bug report for more background on why - but >>>>> there's >>>>> still a handful of files that will be recompiled unnecessarily. >>>>> >>>>> Cheers, >>>>> Mikael >>>>> >>>>> [1] http://bugs.sun.com/view_bug.do?bug_id=7132779 >>>>> >> From staffan.larsen at oracle.com Thu Feb 14 09:53:59 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 14 Feb 2013 18:53:59 +0100 Subject: Request for review (XS): JDK-8006430: TraceTypeProfile is a product flag while it should be a diagnostic flag In-Reply-To: <511D22D2.5040006@oracle.com> References: <5115A51F.2070102@oracle.com> <9F15BEC4-47F1-4529-B395-853D272FE54C@oracle.com> <511C45B5.2000202@oracle.com> <3A2F2C9E-0982-47C2-826E-EF08158F9B0C@oracle.com> <511D22D2.5040006@oracle.com> Message-ID: <510756F9-A47A-4FDF-86FF-41DE99E41AA6@oracle.com> Thanks for explaining. /Staffan On 14 feb 2013, at 18:45, Vladimir Kozlov wrote: > It is done to separate flags per component (where a flag is defined) when we print them (-XX:+PrintFlagsInitial, -XX:+PrintFlagsFinal): > > bool TraceTypeProfile = false {C2 diagnostic} > > Yes, we can extend Flag struct to separate 'kind' and 'component' (or whatever). Could be good task for new members of Hotspot group. > > Vladimir > > On 2/14/13 4:04 AM, Staffan Larsen wrote: >> Yes, exactly. >> >> /Staffan >> >> On 14 feb 2013, at 03:02, Krystal Mo wrote: >> >>> Hi Chris, >>> >>> I think Staffan is asking why we differentiate {C2 diagnostic} and friends from {diagnostic}. >>> >>> - Kris >>> >>> On 02/13/2013 12:26 PM, Christian Thalinger wrote: >>>> On Feb 11, 2013, at 12:57 AM, Staffan Larsen wrote: >>>> >>>>> Forgive my ignorance, but why do diagnostic and experimental flags have different "kinds" depending on what part of the VM they belong to? Can't they all be just "{experimental}" or "{diagnostic}"? I don't see where the additional C1/C2/ARCH/Shark information is used. >>>> Are you asking why we have experimental and diagnostic flags? >>>> >>>> -- Chris >>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> On 9 feb 2013, at 02:23, Krystal Mo wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Could I have a couple of reviews for this fix, please? >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~kmo/8006430/webrev.00/ >>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006430 >>>>>> >>>>>> This bug is actually not a regression from JDK-7198499, but a long time issue that C2 diagnostic flags were never treated as being "diagnostic" since the OpenJDK Mercurial repo history began (duke at 0). >>>>>> >>>>>> The problem is, C2 diagnostic flags have the kind "{C2 diagnostic}", but Flag::is_unlocked() only cared to test "{diagnostic}". >>>>>> So the fix is straighforward -- find out how many other "diagnostic" and "experimental" flag kinds there are, and check them. >>>>>> >>>>>> I didn't just check if the string ends with "diagnostic}" or "experimental}" because I think that's too permissive, but I don't have a strong opinion on that. >>>>>> If reviews form a consensus that checking just the postfix is good enough, I can make the change that way. >>>>>> >>>>>> Care has to be taken if new diagnostic/experimental flag kinds are added to other components in the future, e.g. C1. >>>>>> >>>>>> Tested with JPRT and these flags by hand: >>>>>> C2 diagnostic: TraceTypeProfile, LoopLimitCheck, RangeLimitCheck >>>>>> ARCH diagnostic: UseIncDec >>>>>> >>>>>> Thanks, >>>>>> Kris >>> >> From christian.thalinger at oracle.com Thu Feb 14 10:44:20 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 14 Feb 2013 10:44:20 -0800 Subject: RFR (S): 8008081: Print outs do not have matching arguments In-Reply-To: <511AFA0A.2090504@oracle.com> References: <511AFA0A.2090504@oracle.com> Message-ID: <7341DA48-8F25-493C-8D0D-6391ECDD4B97@oracle.com> I didn't verify all parameters you added but it looks good. It's definitely better than what we have now. -- Chris On Feb 12, 2013, at 6:27 PM, Mikael Vidstedt wrote: > > All, > > Please review the following change: > > http://cr.openjdk.java.net/~mikael/webrevs/8008081/webrev.00/webrev > > Background: > > I found a few occurrences of calls to print type functions where the arguments do not match the format string. I hope that I have added the right/intended arguments in the respective places but could use some help to verify that that is indeed the case. > > One special case is in this webrev is jvmtiEnter.xls. Since it is used to generate the jvmtiEnterTrace.cpp file and therefore is a bit less obvious to review I have prepared a pair of before/after files for your convenience: > > Before: http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.orig > After: http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.fixed > > I also prepared a diff -u of before vs after: > > http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.diff > > Passes JPRT. > > Cheers, > Mikael From christian.thalinger at oracle.com Thu Feb 14 10:51:02 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 14 Feb 2013 10:51:02 -0800 Subject: 8008243: Zero: implement fast-bytecodes [Was: Re: [RFC] Fast-bytecodes for Zero] In-Reply-To: <1360784420.2524.31.camel@mercury> References: <1360784420.2524.31.camel@mercury> Message-ID: I've filed: 8008243: Zero: implement fast-bytecodes -- Chris On Feb 13, 2013, at 11:40 AM, Roman Kennke wrote: > The following change implements support for the following fast-bytecodes > in the Zero interpreter: > > fast_agetfield > fast_bgetfield > fast_cgetfield > fast_dgetfield > fast_fgetfield > fast_igetfield > fast_lgetfield > fast_sgetfield > fast_aputfield > fast_bputfield > fast_cputfield > fast_dputfield > fast_fputfield > fast_iputfield > fast_lputfield > fast_sputfield > fast_aload_0 > fast_iaccess_0 > fast_aaccess_0 > fast_faccess_0 > fast_iload > fast_iload2 > fast_icaload > fast_invokevfinal > > All together this leads to a speedup of the interpreter of about 25%. > > Some notes: > - I extracted the JVMTI related blocks into a macro to avoid repetition. > - The field get/put opcodes are only rewritten for non-volatile > non-static field access, this makes the fast one really fast (no > additional branches needed), and static/volatile field accesses seem > rare enough anyway. > > http://cr.openjdk.java.net/~rkennke/zero-fast-opcodes/webrev.00/ > > > Opinions? Can this be included in hotspot? And Can I have a bug-ID? > > Best regards, > Roman > > From staffan.larsen at oracle.com Thu Feb 14 11:38:09 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 14 Feb 2013 19:38:09 +0000 Subject: hg: hsx/hsx24/hotspot: 8004840: Jstack seems to output unnecessary information in 7u9 Message-ID: <20130214193812.19D1247A99@hg.openjdk.java.net> Changeset: 6a71d443bd0a Author: sla Date: 2013-02-14 13:08 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6a71d443bd0a 8004840: Jstack seems to output unnecessary information in 7u9 Reviewed-by: dholmes, coleenp, sspitsyn, rbackman ! agent/src/share/classes/sun/jvm/hotspot/memory/CMSCollector.java ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java From poonam.bajaj at oracle.com Thu Feb 14 06:56:09 2013 From: poonam.bajaj at oracle.com (poonam.bajaj at oracle.com) Date: Thu, 14 Feb 2013 14:56:09 +0000 Subject: hg: hsx/hsx24/hotspot: 8006937: [obj|type]ArrayKlass::oop_print_on prints one line to tty instead of the provided output stream Message-ID: <20130214145612.CA11B47A84@hg.openjdk.java.net> Changeset: 78bef3bdb386 Author: poonam Date: 2013-02-14 04:40 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/78bef3bdb386 8006937: [obj|type]ArrayKlass::oop_print_on prints one line to tty instead of the provided output stream Reviewed-by: kvn, stefank, poonam Contributed-by: sergey.gabdurakhmanov at oracle.com ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.cpp From staffan.larsen at oracle.com Thu Feb 14 13:24:27 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 14 Feb 2013 21:24:27 +0000 Subject: hg: hsx/hsx24/hotspot: 8008208: Event tracing for code cache subsystems can give wrong timestamps Message-ID: <20130214212429.DD94947A9F@hg.openjdk.java.net> Changeset: 7ffe30a79778 Author: mgronlun Date: 2013-02-14 18:47 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/7ffe30a79778 8008208: Event tracing for code cache subsystems can give wrong timestamps Reviewed-by: kvn, sla ! src/share/vm/opto/compile.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp From coleen.phillimore at oracle.com Thu Feb 14 19:27:34 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 14 Feb 2013 19:27:34 -0800 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <510C18F6.6010305@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> <50A24E00.3070200@oracle.com> <50A25720.1040405@oracle.com> <50A59010.5040001@oracle.com> <510C18F6.6010305@oracle.com> Message-ID: <511DAB26.2010808@oracle.com> Looks good Mikael! I like these sorts of changes. Coleen On 2/1/2013 11:35 AM, Mikael Vidstedt wrote: > > All, > > I finally found some time to update the webrev: > > http://cr.openjdk.java.net/~mikael/8003310/webrev.03/webrev/ > > Not much has changes since the first webrev. I played around with > turning the #ifdef in constantPool.cpp into a const bool = false, but > one of the downsides I noticed with that is that the code will still > be compiled into product and especially for this type of function with > a relatively large number of constant strings in it it unnecessarily > adds to the footprint. This does not invalidate the const bool = false > idiom, but there may be cases where it is beneficial to use > alternatives to it. > > Cheers, > Mikael > > On 11/15/2012 5:00 PM, Mikael Vidstedt wrote: >> On 2012-11-13 06:20, Coleen Phillimore wrote: >>> On 11/13/2012 8:41 AM, Coleen Phillimore wrote: >>>> >>>> Hi Mikael, This is good! I have the same comments as David. >>>> >>>> For constantPool.cpp can you add #undef DBG after that code. >>>> >>>> Maybe there should be a new convention for DEBUG_ >>>> for unused code that people want to leave around for debugging. I >>>> don't recommend we add a lot of code like this, but having such an >>>> ifdef would differentiate code that was just left in >>>> unintentionally from code that we want to be left in (occasionally). >>> >>> Actually, I want to revise this. We had this discussion about this >>> recently rwt metaspace debugging and favored a const static variable >>> = false; under #ifdef DEBUG or ASSERT and the debugging code under >>> DEBUG/ASSERT so that it doesn't bit rot. This is for the code left >>> in intentionally. Which makes me wonder why print_cpool_bytes() is >>> there under DEBUG_CPOOL claiming to be "temporary" when there is >>> another printing function in that file already. >> >> The reason why I moved it under DBG was because it is only ever >> called wrapped with a DBG(). I can play around with making it a const >> static = false as you outlined. >> >> The other print functions in constantPool.cpp are implementations of >> the virtual functions inherited from Metadata, so they are not quite >> as temporary as print_cpool_bytes, if that makes sense. >> >> Cheers, >> Mikael >> >>> >>> Coleen >>> >>>> >>>> Thanks, >>>> Coleen >>>> >>>> On 11/13/2012 12:47 AM, David Holmes wrote: >>>>> Hi Mikael, >>>>> >>>>> A couple of general observations as really the "owners" of each >>>>> file needs to assess the changes: >>>>> >>>>> - sometimes functions exist for debugging/tracing and calls will >>>>> be added to the code by engineers as they debug. For example >>>>> MBFence in synchronizer.cpp allows you to add fences into >>>>> expressions. >>>>> >>>>> - why was the "static" removed from a number functions. They now >>>>> have global visibility rather than being restricted to their files? >>>>> >>>>> >>>>> In globaleDefinitions.cpp: >>>>> >>>>> + void GlobalDefinitions::test_globals() { >>>>> + intptr_t page_size = 4096; >>>>> >>>>> Page size may not be 4K - will the test still be valid? >>>>> >>>>> >>>>> The comments describing clamp_address_in_page don't need to be on >>>>> both the declaration and definition. >>>>> >>>>> Cheers, >>>>> David >>>>> ------ >>>>> >>>>> On 13/11/2012 1:59 PM, Mikael Vidstedt wrote: >>>>>> >>>>>> All, >>>>>> >>>>>> Please review the below change. The change adds the -Wunused flag >>>>>> when >>>>>> compiling with GCC and removes a number of unused functions/dead >>>>>> code. >>>>>> >>>>>> In the process I found one function (same_page) which was >>>>>> duplicated in >>>>>> four different places. I merged it to a single function, renamed >>>>>> it to >>>>>> clamp_address_in_page, added some comments and refactored it to be >>>>>> slightly easier to understand. I also added unit tests for it. >>>>>> Feedback >>>>>> appreciated (especially on the name). >>>>>> >>>>>> http://cr.openjdk.java.net/~mikael/8003310/webrev.00/ >>>>>> >>>>>> Passes JPRT and the built-in unit tests >>>>>> (-XX:+ExecuteInternalVMTests). >>>>>> >>>>>> Thanks, >>>>>> Mikael >>>>>> >>>> >>> >> > From azeem.jiva at oracle.com Thu Feb 14 20:04:48 2013 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Thu, 14 Feb 2013 20:04:48 -0800 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <511DAB26.2010808@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> <50A24E00.3070200@oracle.com> <50A25720.1040405@oracle.com> <50A59010.5040001@oracle.com> <510C18F6.6010305@oracle.com> <511DAB26.2010808@oracle.com> Message-ID: <511DB3E0.6030606@oracle.com> Did you measure how much the libjvm.so shrank with your changes? On 2/14/2013 7:27 PM, Coleen Phillmore wrote: > > Looks good Mikael! I like these sorts of changes. > Coleen > > On 2/1/2013 11:35 AM, Mikael Vidstedt wrote: >> >> All, >> >> I finally found some time to update the webrev: >> >> http://cr.openjdk.java.net/~mikael/8003310/webrev.03/webrev/ >> >> Not much has changes since the first webrev. I played around with >> turning the #ifdef in constantPool.cpp into a const bool = false, but >> one of the downsides I noticed with that is that the code will still >> be compiled into product and especially for this type of function >> with a relatively large number of constant strings in it it >> unnecessarily adds to the footprint. This does not invalidate the >> const bool = false idiom, but there may be cases where it is >> beneficial to use alternatives to it. >> >> Cheers, >> Mikael >> >> On 11/15/2012 5:00 PM, Mikael Vidstedt wrote: >>> On 2012-11-13 06:20, Coleen Phillimore wrote: >>>> On 11/13/2012 8:41 AM, Coleen Phillimore wrote: >>>>> >>>>> Hi Mikael, This is good! I have the same comments as David. >>>>> >>>>> For constantPool.cpp can you add #undef DBG after that code. >>>>> >>>>> Maybe there should be a new convention for DEBUG_>>>> caps> for unused code that people want to leave around for >>>>> debugging. I don't recommend we add a lot of code like this, but >>>>> having such an ifdef would differentiate code that was just left >>>>> in unintentionally from code that we want to be left in >>>>> (occasionally). >>>> >>>> Actually, I want to revise this. We had this discussion about this >>>> recently rwt metaspace debugging and favored a const static >>>> variable = false; under #ifdef DEBUG or ASSERT and the debugging >>>> code under DEBUG/ASSERT so that it doesn't bit rot. This is for >>>> the code left in intentionally. Which makes me wonder why >>>> print_cpool_bytes() is there under DEBUG_CPOOL claiming to be >>>> "temporary" when there is another printing function in that file >>>> already. >>> >>> The reason why I moved it under DBG was because it is only ever >>> called wrapped with a DBG(). I can play around with making it a >>> const static = false as you outlined. >>> >>> The other print functions in constantPool.cpp are implementations of >>> the virtual functions inherited from Metadata, so they are not quite >>> as temporary as print_cpool_bytes, if that makes sense. >>> >>> Cheers, >>> Mikael >>> >>>> >>>> Coleen >>>> >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 11/13/2012 12:47 AM, David Holmes wrote: >>>>>> Hi Mikael, >>>>>> >>>>>> A couple of general observations as really the "owners" of each >>>>>> file needs to assess the changes: >>>>>> >>>>>> - sometimes functions exist for debugging/tracing and calls will >>>>>> be added to the code by engineers as they debug. For example >>>>>> MBFence in synchronizer.cpp allows you to add fences into >>>>>> expressions. >>>>>> >>>>>> - why was the "static" removed from a number functions. They now >>>>>> have global visibility rather than being restricted to their files? >>>>>> >>>>>> >>>>>> In globaleDefinitions.cpp: >>>>>> >>>>>> + void GlobalDefinitions::test_globals() { >>>>>> + intptr_t page_size = 4096; >>>>>> >>>>>> Page size may not be 4K - will the test still be valid? >>>>>> >>>>>> >>>>>> The comments describing clamp_address_in_page don't need to be on >>>>>> both the declaration and definition. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> ------ >>>>>> >>>>>> On 13/11/2012 1:59 PM, Mikael Vidstedt wrote: >>>>>>> >>>>>>> All, >>>>>>> >>>>>>> Please review the below change. The change adds the -Wunused >>>>>>> flag when >>>>>>> compiling with GCC and removes a number of unused functions/dead >>>>>>> code. >>>>>>> >>>>>>> In the process I found one function (same_page) which was >>>>>>> duplicated in >>>>>>> four different places. I merged it to a single function, renamed >>>>>>> it to >>>>>>> clamp_address_in_page, added some comments and refactored it to be >>>>>>> slightly easier to understand. I also added unit tests for it. >>>>>>> Feedback >>>>>>> appreciated (especially on the name). >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mikael/8003310/webrev.00/ >>>>>>> >>>>>>> Passes JPRT and the built-in unit tests >>>>>>> (-XX:+ExecuteInternalVMTests). >>>>>>> >>>>>>> Thanks, >>>>>>> Mikael >>>>>>> >>>>> >>>> >>> >> > From david.holmes at oracle.com Thu Feb 14 23:25:35 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Feb 2013 17:25:35 +1000 Subject: 8008243: Zero: implement fast-bytecodes [Was: Re: [RFC] Fast-bytecodes for Zero] In-Reply-To: References: <1360784420.2524.31.camel@mercury> Message-ID: <511DE2EF.9090106@oracle.com> There's a lot of changes to shared code here - what is the impact on non-zero platforms? Thanks, David On 15/02/2013 4:51 AM, Christian Thalinger wrote: > I've filed: > > 8008243: Zero: implement fast-bytecodes > > -- Chris > > On Feb 13, 2013, at 11:40 AM, Roman Kennke wrote: > >> The following change implements support for the following fast-bytecodes >> in the Zero interpreter: >> >> fast_agetfield >> fast_bgetfield >> fast_cgetfield >> fast_dgetfield >> fast_fgetfield >> fast_igetfield >> fast_lgetfield >> fast_sgetfield >> fast_aputfield >> fast_bputfield >> fast_cputfield >> fast_dputfield >> fast_fputfield >> fast_iputfield >> fast_lputfield >> fast_sputfield >> fast_aload_0 >> fast_iaccess_0 >> fast_aaccess_0 >> fast_faccess_0 >> fast_iload >> fast_iload2 >> fast_icaload >> fast_invokevfinal >> >> All together this leads to a speedup of the interpreter of about 25%. >> >> Some notes: >> - I extracted the JVMTI related blocks into a macro to avoid repetition. >> - The field get/put opcodes are only rewritten for non-volatile >> non-static field access, this makes the fast one really fast (no >> additional branches needed), and static/volatile field accesses seem >> rare enough anyway. >> >> http://cr.openjdk.java.net/~rkennke/zero-fast-opcodes/webrev.00/ >> >> >> Opinions? Can this be included in hotspot? And Can I have a bug-ID? >> >> Best regards, >> Roman >> >> > From staffan.larsen at oracle.com Fri Feb 15 00:01:51 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 15 Feb 2013 09:01:51 +0100 Subject: RFR (S): 8008081: Print outs do not have matching arguments In-Reply-To: <511AFA0A.2090504@oracle.com> References: <511AFA0A.2090504@oracle.com> Message-ID: <285DDAAA-7E2C-4520-BBB6-C9BB29985719@oracle.com> src/share/vm/c1/c1_FrameMap.cpp:319 I wonder if the order of the last two arguments got flipped? Shouldn't the _num_monitors value go inside the [] ? Otherwise looks good! /Staffan On 13 feb 2013, at 03:27, Mikael Vidstedt wrote: > > All, > > Please review the following change: > > http://cr.openjdk.java.net/~mikael/webrevs/8008081/webrev.00/webrev > > Background: > > I found a few occurrences of calls to print type functions where the arguments do not match the format string. I hope that I have added the right/intended arguments in the respective places but could use some help to verify that that is indeed the case. > > One special case is in this webrev is jvmtiEnter.xls. Since it is used to generate the jvmtiEnterTrace.cpp file and therefore is a bit less obvious to review I have prepared a pair of before/after files for your convenience: > > Before: http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.orig > After: http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.fixed > > I also prepared a diff -u of before vs after: > > http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.diff > > Passes JPRT. > > Cheers, > Mikael From david.holmes at oracle.com Fri Feb 15 00:08:26 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Feb 2013 18:08:26 +1000 Subject: RFR (S): 8008081: Print outs do not have matching arguments In-Reply-To: <511AFA0A.2090504@oracle.com> References: <511AFA0A.2090504@oracle.com> Message-ID: <511DECFA.9090406@oracle.com> On 13/02/2013 12:27 PM, Mikael Vidstedt wrote: > Please review the following change: > > http://cr.openjdk.java.net/~mikael/webrevs/8008081/webrev.00/webrev > > Background: > > I found a few occurrences of calls to print type functions where the > arguments do not match the format string. I hope that I have added the > right/intended arguments in the respective places but could use some > help to verify that that is indeed the case. In c1_FrameMap: 316 if( _num_monitors > 0) { 317 tty->print_cr("monitor [0]:%d | [%2d]:%d", 318 in_bytes(sp_offset_for_monitor_base(0)), 319 in_bytes(sp_offset_for_monitor_base(_num_monitors)), 320 _num_monitors); 321 } I think the last two args need swapping and should it be _num_monitors-1 ie the "index" ? And does that make sp_offset_for_monitor_base(_num_monitors) wrong ?? Everything else seems reasonable - some obvious, some less so - but all 1000% better than before ;-) David ----- > One special case is in this webrev is jvmtiEnter.xls. Since it is used > to generate the jvmtiEnterTrace.cpp file and therefore is a bit less > obvious to review I have prepared a pair of before/after files for your > convenience: > > Before: > http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.orig > After: > http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.fixed > > > I also prepared a diff -u of before vs after: > > http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.diff > > Passes JPRT. > > Cheers, > Mikael From alejandro.murillo at oracle.com Fri Feb 15 00:27:07 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 15 Feb 2013 08:27:07 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130215082715.B692047ABE@hg.openjdk.java.net> Changeset: fcd41f89bfa3 Author: katleman Date: 2013-02-13 17:56 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/fcd41f89bfa3 Added tag jdk7u14-b13 for changeset 38b173289e57 ! .hgtags Changeset: 6a431dbf4a33 Author: amurillo Date: 2013-02-14 22:29 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6a431dbf4a33 Merge - test/runtime/7158988/TestFieldMonitor.sh Changeset: 0310fb7a08b6 Author: amurillo Date: 2013-02-14 22:29 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0310fb7a08b6 Added tag hs24-b33 for changeset 6a431dbf4a33 ! .hgtags From john.coomes at oracle.com Fri Feb 15 01:32:06 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 15 Feb 2013 09:32:06 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b77 for changeset 3933eebc659d Message-ID: <20130215093206.4888E47AC3@hg.openjdk.java.net> Changeset: 45dcccc6d221 Author: katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/45dcccc6d221 Added tag jdk8-b77 for changeset 3933eebc659d ! .hgtags From john.coomes at oracle.com Fri Feb 15 01:32:09 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 15 Feb 2013 09:32:09 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b77 for changeset 35684a40c584 Message-ID: <20130215093213.5340747AC4@hg.openjdk.java.net> Changeset: 27d6368ae8ba Author: katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/27d6368ae8ba Added tag jdk8-b77 for changeset 35684a40c584 ! .hgtags From john.coomes at oracle.com Fri Feb 15 01:32:17 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 15 Feb 2013 09:32:17 +0000 Subject: hg: hsx/hotspot-main/jaxp: 3 new changesets Message-ID: <20130215093233.6D02847AC5@hg.openjdk.java.net> Changeset: f0ad3747b40e Author: emc Date: 2013-02-05 14:56 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/f0ad3747b40e 8007389: Remove uses of _ as identifier in jaxp Reviewed-by: lancea, joehw ! src/javax/xml/validation/SchemaFactoryFinder.java ! src/javax/xml/xpath/XPathFactoryFinder.java Changeset: 573e789c187a Author: lana Date: 2013-02-11 16:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/573e789c187a Merge Changeset: 00958c5a7070 Author: katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/00958c5a7070 Added tag jdk8-b77 for changeset 573e789c187a ! .hgtags From john.coomes at oracle.com Fri Feb 15 01:32:37 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 15 Feb 2013 09:32:37 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b77 for changeset 64dfba1bad16 Message-ID: <20130215093243.1335347AC6@hg.openjdk.java.net> Changeset: 391de4c992d1 Author: katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/391de4c992d1 Added tag jdk8-b77 for changeset 64dfba1bad16 ! .hgtags From john.coomes at oracle.com Fri Feb 15 01:33:40 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 15 Feb 2013 09:33:40 +0000 Subject: hg: hsx/hotspot-main/jdk: 40 new changesets Message-ID: <20130215094226.5AF8647AC7@hg.openjdk.java.net> Changeset: e63e7ee18412 Author: bae Date: 2013-02-01 20:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e63e7ee18412 8004801: The image of BufferedImage.TYPE_INT_ARGB is blank. Reviewed-by: prr ! src/share/native/sun/awt/image/awt_parseImage.c ! src/solaris/native/sun/awt/awt_Mlib.c ! src/solaris/native/sun/awt/awt_Mlib.h ! src/windows/native/sun/windows/awt_Mlib.cpp ! src/windows/native/sun/windows/awt_Mlib.h + test/java/awt/image/LookupOp/IntImageReverseTest.java Changeset: 1df2944db538 Author: serb Date: 2013-02-04 19:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1df2944db538 8004821: Graphics2D.drawPolygon() fails with IllegalPathStateException Reviewed-by: prr, flar ! src/share/classes/sun/java2d/pipe/PixelToShapeConverter.java + test/sun/java2d/pipe/Test8004821.java Changeset: 8fc3e4015b09 Author: jgodinez Date: 2013-02-04 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8fc3e4015b09 8005052: [parfait] #416 X11SurfaceData.c UNINITIALISED OR MISSING RETURN VALUE 8005054: [parfait] #417 X11SurfaceData.c UNINITIALISED OR MISSING RETURN VALUE Reviewed-by: prr, vadim Contributed-by: jia-hong.chen at oracle.com ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c Changeset: fd61fcc1a5a9 Author: leonidr Date: 2013-01-31 18:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fd61fcc1a5a9 8007006: [macosx] Closing subwindow loses main window menus Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 452deb976c92 Author: ptbrunet Date: 2013-01-31 18:51 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/452deb976c92 7179482: Component.accessibleContext and JComponent.accessibleContext refactoring Reviewed-by: art, anthony, alexsch ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/javax/swing/JComponent.java Changeset: 0b56a169295f Author: pchelko Date: 2013-02-04 13:54 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0b56a169295f 8005405: [macosx] Drag and Drop: wrong animation when dropped outside any drop target. Summary: Changed the calculation of the drag image offset Reviewed-by: serb, kizune ! src/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java ! src/macosx/native/sun/awt/CDragSource.m Changeset: 171443b1eb3b Author: kshefov Date: 2013-02-04 16:01 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/171443b1eb3b 7077259: [TEST_BUG] [macosx] Test work correctly only when default L&F is Metal Reviewed-by: serb, alexsch ! test/javax/swing/JSlider/4252173/bug4252173.java ! test/javax/swing/JSpinner/6532833/bug6532833.java ! test/javax/swing/plaf/metal/MetalSliderUI/Test6657026.java Changeset: 0e929be3a9da Author: lana Date: 2013-02-05 11:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0e929be3a9da Merge Changeset: a343d280bd8c Author: jfranck Date: 2013-01-29 10:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a343d280bd8c 8004698: Implement Core Reflection for Type Annotations Reviewed-by: darcy ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/System.java + src/share/classes/java/lang/reflect/AnnotatedArrayType.java + src/share/classes/java/lang/reflect/AnnotatedParameterizedType.java + src/share/classes/java/lang/reflect/AnnotatedType.java + src/share/classes/java/lang/reflect/AnnotatedTypeVariable.java + src/share/classes/java/lang/reflect/AnnotatedWildcardType.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/ReflectAccess.java ! src/share/classes/java/lang/reflect/TypeVariable.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/LangReflectAccess.java ! src/share/classes/sun/reflect/ReflectionFactory.java + src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java + src/share/classes/sun/reflect/annotation/TypeAnnotation.java + src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! src/share/javavm/export/jvm.h ! src/share/native/java/lang/Class.c + test/java/lang/annotation/TypeAnnotationReflection.java + test/java/lang/annotation/TypeParamAnnotation.java Changeset: 5097fe015763 Author: jfranck Date: 2013-01-31 10:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5097fe015763 8005712: Simplify support for repeating annotations in j.l.r.AnnotatedElement 8004919: AnnotationSupport uses possibly half-constructed AnnotationType instances Summary: Implements the simplified semantics for repeating annotations and removes the incorrect obtaining of an AnnotationType Reviewed-by: darcy, abuckley ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/reflect/AnnotatedElement.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/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/annotation/AnnotationSupport.java ! test/java/lang/annotation/repeatingAnnotations/RepeatedUnitTest.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/Containee.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/Container.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainee.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainer.java Changeset: 3f766f58c48a Author: dbuck Date: 2013-01-31 10:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3f766f58c48a 7042126: (alt-rt) HashMap.clone implementation should be re-examined Summary: Test case for cr7042126. Issue only found in OracleJDK, but test case is valid for OpenJDK as well Reviewed-by: mduigou + test/java/util/HashMap/HashMapCloneLeak.java Changeset: 857d99bef21d Author: sherman Date: 2013-01-31 11:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/857d99bef21d 8005394: Base64.Decoder/Encoder.wrap(XStream) don't throw NPE for null args passed Summary: to check null for dec/enc.wrap methods Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java Changeset: 278397f752da Author: darcy Date: 2013-01-31 12:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/278397f752da 8005832: Remove java.lang.annotation.{ContainedBy, ContainerFor} annotation types Reviewed-by: mduigou - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java ! src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java Changeset: a5f38e811ab0 Author: darcy Date: 2013-01-31 12:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a5f38e811ab0 8007115: Refactor regression tests for java.lang.reflect.Parameter Reviewed-by: emc ! test/java/lang/reflect/Parameter/WithoutParameters.java Changeset: e5ce312a5b10 Author: sherman Date: 2013-01-31 13:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e5ce312a5b10 8007298: Base64.getMimeDecoder().decode() throws IAE for a single non-base64 character 8006526: Base64.Decoder.decode(String) spec contains a copy-paste mistake Summary: to ignore single non-base64 char in mime decoding Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java Changeset: cff8d7768d72 Author: mduigou Date: 2013-01-31 13:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cff8d7768d72 8006709: Add minimal support of MacOSX platform for NetBeans Projects Summary: Adds support for MacOSX platform and architecture detection. Other minor updates (-source/target 1.8) Reviewed-by: ohair + make/netbeans/common/architectures/arch-x86_64.properties + make/netbeans/common/architectures/name-Macosx.properties ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent ! make/netbeans/common/make.xml ! make/netbeans/common/shared.xml Changeset: 771551bc9e02 Author: lana Date: 2013-01-31 10:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/771551bc9e02 Merge Changeset: e822b4d50a5b Author: lana Date: 2013-01-31 14:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e822b4d50a5b Merge - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java Changeset: a09a37cff333 Author: mchung Date: 2013-01-31 14:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a09a37cff333 6355704: (fmt) %f formatting of BigDecimals is incorrect Reviewed-by: darcy Contributed-by: brian.burkhalter at oracle.com ! test/java/util/Formatter/Basic-X.java.template ! test/java/util/Formatter/BasicBigDecimal.java Changeset: d2495b9984fa Author: weijun Date: 2013-02-01 07:39 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d2495b9984fa 8006564: Test sun/security/util/Oid/S11N.sh fails with timeout on Linux 32-bit Reviewed-by: alanb + test/sun/security/util/Oid/S11N.java - test/sun/security/util/Oid/S11N.sh - test/sun/security/util/Oid/SerialTest.java Changeset: 17b643956999 Author: chegar Date: 2013-02-01 06:51 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/17b643956999 8006395: Race in async socket close on Linux Reviewed-by: alanb, dsamersoff ! src/solaris/native/java/net/linux_close.c + test/java/net/Socket/asyncClose/Race.java Changeset: ea8f3ca83501 Author: ksrini Date: 2013-02-01 07:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ea8f3ca83501 8006536: [launcher] removes trailing slashes on arguments Reviewed-by: ksrini, akhil Contributed-by: jviswana at linux.vnet.ibm.com ! src/windows/bin/cmdtoargs.c ! test/tools/launcher/Arrrghs.java Changeset: 5e47ee4d7196 Author: alanb Date: 2013-02-01 21:01 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5e47ee4d7196 5035569: Formatter should document that %a conversion unsupported for BigDecimal args Reviewed-by: darcy Contributed-by: brian.burkhalter at oracle.com ! src/share/classes/java/util/Formatter.java Changeset: cba578db5f39 Author: darcy Date: 2013-02-01 19:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cba578db5f39 6964528: Double.toHexString(double d) String manipulation with + in an append of StringBuilder Reviewed-by: shade ! src/share/classes/java/lang/Double.java Changeset: c1aaa8451547 Author: ksrini Date: 2013-02-01 22:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c1aaa8451547 8003549: (pack200) assertion errors when processing lambda class files with IMethods Summary: add more check for opcode, sketch provided by jrose Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java ! test/ProblemList.txt + test/tools/pack200/InstructionTests.java ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java Changeset: 6c88a12ea834 Author: ksrini Date: 2013-02-01 22:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6c88a12ea834 8007428: [launcher] add tools/launcher/FXLauncherTest.java to ProblemList.txt Reviewed-by: mchung ! test/ProblemList.txt Changeset: ee83319029a5 Author: chegar Date: 2013-02-02 17:15 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ee83319029a5 8007322: untangle ftp protocol from general networking URL tests Reviewed-by: alanb ! test/java/net/URL/Constructor.java ! test/java/net/URL/HandlerLoop.java ! test/java/net/URL/Test.java ! test/java/net/URL/URIToURLTest.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/java/net/URLConnection/RequestProperties.java ! test/java/net/URLConnection/RequestPropertyValues.java + test/sun/net/ftp/EncDec.doc + test/sun/net/ftp/MarkResetTest.java + test/sun/net/ftp/MarkResetTest.sh - test/sun/net/www/EncDec.doc - test/sun/net/www/MarkResetTest.java - test/sun/net/www/MarkResetTest.sh ! test/sun/net/www/http/HttpClient/ProxyTest.java Changeset: 25831e7009c4 Author: ksrini Date: 2013-02-02 12:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/25831e7009c4 8007135: tools/launcher/VersionCheck.java failing with new tool jabswitch Reviewed-by: ksrini, mduigou Contributed-by: ragini.prasad at oracle.com ! test/tools/launcher/VersionCheck.java Changeset: 308d1362b60a Author: dmeetry Date: 2013-02-03 18:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/308d1362b60a 6471906: java.lang.NegativeArraySizeException in tenToThe Reviewed-by: darcy Contributed-by: brian.burkhalter at oracle.com ! src/share/classes/java/math/BigDecimal.java Changeset: 962d6612cace Author: dsamersoff Date: 2013-02-03 21:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/962d6612cace 8002048: Protocol to discovery of manageable Java processes on a network Summary: Introduce a protocol to discover manageble Java instances across a network subnet, JDP Reviewed-by: sla, dfuchs ! src/share/classes/sun/management/Agent.java + src/share/classes/sun/management/jdp/JdpBroadcaster.java + src/share/classes/sun/management/jdp/JdpController.java + src/share/classes/sun/management/jdp/JdpException.java + src/share/classes/sun/management/jdp/JdpGenericPacket.java + src/share/classes/sun/management/jdp/JdpJmxPacket.java + src/share/classes/sun/management/jdp/JdpPacket.java + src/share/classes/sun/management/jdp/JdpPacketReader.java + src/share/classes/sun/management/jdp/JdpPacketWriter.java + src/share/classes/sun/management/jdp/package-info.java + test/sun/management/jdp/JdpClient.java + test/sun/management/jdp/JdpDoSomething.java + test/sun/management/jdp/JdpTest.sh + test/sun/management/jdp/JdpUnitTest.java Changeset: 5bf1c9e6be60 Author: vinnie Date: 2013-02-04 17:20 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5bf1c9e6be60 8006994: Cleanup PKCS12 tests to ensure streams get closed Reviewed-by: mullan ! test/java/security/KeyStore/PBETest.java ! test/sun/security/pkcs12/StorePasswordTest.java ! test/sun/security/pkcs12/StoreSecretKeyTest.java ! test/sun/security/pkcs12/StoreTrustedCertTest.java Changeset: e202f43a8b8a Author: sherman Date: 2013-02-04 11:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e202f43a8b8a 8006295: Base64.Decoder.wrap(java.io.InputStream) returns InputStream which throws unspecified IOException on attempt to decode invalid Base64 byte stream 8006315: Base64.Decoder decoding methods are not consistent in treating non-padded data 8006530: Base64.getMimeDecoder().decode() throws exception for non-base64 character after adding = Summary: updated the spec to describe the expected behave explicitly and the implementation to follow Reviewed-by: alanb, chegar, lancea ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java Changeset: e04467fa13af Author: darcy Date: 2013-02-04 17:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e04467fa13af 8007113: Upgrade AnnotatedElement.isAnnotionPresent to be a default method Reviewed-by: chegar, jfranck ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java ! src/share/classes/java/lang/reflect/Parameter.java ! src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java Changeset: fd37f0846653 Author: lana Date: 2013-02-04 22:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fd37f0846653 Merge Changeset: 9ffcd758e2be Author: jbachorik Date: 2013-02-05 12:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9ffcd758e2be 7170447: Intermittent DeadListenerTest.java failure Summary: Due to asynchronous nature of processing server notifications it may happen that an "unregister" notification ha$ Reviewed-by: sjiang ! test/javax/management/remote/mandatory/notif/DeadListenerTest.java Changeset: 3119f0ebb58d Author: jbachorik Date: 2013-02-05 12:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3119f0ebb58d 8005791: Remove java.beans.* imports from com.sun.jmx.mbeanserver.Introspector Reviewed-by: rbackman ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java Changeset: e526277b51be Author: vinnie Date: 2013-02-05 14:25 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e526277b51be 8007483: attributes are ignored when loading keys from a PKCS12 keystore Reviewed-by: mullan ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! test/sun/security/pkcs12/StorePasswordTest.java Changeset: f26b539bf1d5 Author: lana Date: 2013-02-05 11:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f26b539bf1d5 Merge - 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 Changeset: b2fc8e31cecc Author: lana Date: 2013-02-11 16:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b2fc8e31cecc Merge - 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 Changeset: c1304eb051f6 Author: katleman Date: 2013-02-14 11:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c1304eb051f6 Added tag jdk8-b77 for changeset b2fc8e31cecc ! .hgtags From john.coomes at oracle.com Fri Feb 15 01:44:21 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 15 Feb 2013 09:44:21 +0000 Subject: hg: hsx/hotspot-main/langtools: 21 new changesets Message-ID: <20130215094525.7B0BF47AC8@hg.openjdk.java.net> Changeset: cbcd9b484759 Author: vromero Date: 2013-01-27 19:38 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/cbcd9b484759 8006944: javac, combo tests should print out the number of threads used Reviewed-by: mcimadamore ! test/tools/javac/lib/JavacTestingAbstractThreadedTest.java Changeset: 950d8195a5a4 Author: jjg Date: 2013-01-30 09:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/950d8195a5a4 8007096: DocLint parsing problems with some comments Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java + test/tools/doclint/EndWithIdentifierTest.java + test/tools/doclint/EndWithIdentifierTest.out + test/tools/doclint/UnfinishedInlineTagTest.java + test/tools/doclint/UnfinishedInlineTagTest.out Changeset: c924291865e5 Author: jjg Date: 2013-01-30 09:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c924291865e5 8007034: debug printer for javac internals Reviewed-by: mcimadamore + test/tools/javac/lib/DPrinter.java Changeset: 8e4c22acebeb Author: darcy Date: 2013-01-31 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8e4c22acebeb 8007313: Remove use of {ContainerFor/ContainedBy} from langtools Reviewed-by: jjg ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java ! test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Driver.java Changeset: b7cb3d7ade25 Author: lana Date: 2013-01-31 10:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b7cb3d7ade25 Merge Changeset: 7b269e916e06 Author: lana Date: 2013-01-31 14:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7b269e916e06 Merge Changeset: bec996065c45 Author: darcy Date: 2013-01-31 18:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bec996065c45 8007351: Malformed copyright statements in typeAnnotations test directory Reviewed-by: jjg ! test/tools/javac/annotations/typeAnnotations/TargetTypes.java ! test/tools/javac/annotations/typeAnnotations/TypeProcOnly.java ! test/tools/javac/annotations/typeAnnotations/api/AnnotatedArrayOrder.java ! test/tools/javac/annotations/typeAnnotations/api/ArrayCreationTree.java ! test/tools/javac/annotations/typeAnnotations/api/ArrayPositionConsistency.java ! test/tools/javac/annotations/typeAnnotations/classfile/ClassfileTestHelper.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java ! test/tools/javac/annotations/typeAnnotations/classfile/NewTypeArguments.java ! test/tools/javac/annotations/typeAnnotations/classfile/NoTargetAnnotations.java ! test/tools/javac/annotations/typeAnnotations/classfile/TypeCasts.java ! test/tools/javac/annotations/typeAnnotations/classfile/Wildcards.java ! test/tools/javac/annotations/typeAnnotations/failures/target/DotClass.java ! test/tools/javac/annotations/typeAnnotations/newlocations/Varargs.java ! test/tools/javac/annotations/typeAnnotations/packageanno/PackageProcessor.java ! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/Anno.java ! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/MyClass.java ! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/package-info.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassExtends.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassTypeParam.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Driver.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ExceptionParameters.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Fields.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/FromSpecification.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodParameters.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReceivers.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReturns.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodThrows.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodTypeParam.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/NestedTypes.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/NewObjects.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ReferenceInfoUtil.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/RepeatingTypeAnnotations.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeCasts.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeTests.java Changeset: 3ab64e4293a1 Author: jjg Date: 2013-01-31 19:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3ab64e4293a1 8007329: minor issues in impl class hierarchry for DCTree.* classes Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/tree/DCTree.java Changeset: 3d97a9a7a82b Author: jjg Date: 2013-01-31 19:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3d97a9a7a82b 8004353: Generated html is wrong for overview.html; content has incorrect css footer class Reviewed-by: jjg Contributed-by: roger.riggs at oracle.com ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java Changeset: 8590c20af3ce Author: jjg Date: 2013-02-01 08:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8590c20af3ce 8007306: DPrinter: improve display of impl-class, internal tag/kind, and external tag/kind Reviewed-by: mcimadamore ! test/tools/javac/lib/DPrinter.java Changeset: 6df931ce1a81 Author: jjg Date: 2013-02-01 08:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6df931ce1a81 8007305: DPrinter: provide better usage message Reviewed-by: mcimadamore ! test/tools/javac/lib/DPrinter.java Changeset: 0b1c88705568 Author: jjg Date: 2013-02-01 12:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/0b1c88705568 8007344: javac may not make tree end positions and/or doc comments available to processors and listeners Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java + test/tools/javac/api/8007344/Test.java Changeset: 55cca2f38ee6 Author: darcy Date: 2013-02-01 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/55cca2f38ee6 8001614: Include annotation type to documented supported-ness Reviewed-by: alanb, jjg, tbell ! make/Makefile-classic ! make/build.properties + src/share/classes/jdk/Supported.java Changeset: 4cc73ec94686 Author: vromero Date: 2013-02-02 21:04 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4cc73ec94686 8005075: Pool.Method, and Pool.Variable redundant Symbol field should be removed Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java Changeset: a51a8dac0a2f Author: vromero Date: 2013-02-03 02:31 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a51a8dac0a2f 7199823: javac generates inner class that can't be verified Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/7199823/InnerClassCannotBeVerified.java Changeset: 1690928dc560 Author: jjg Date: 2013-02-04 15:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1690928dc560 8007490: NPE from DocumentationTool.run Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/api/JavadocTool.java ! test/tools/javadoc/api/basic/RunTest.java Changeset: 62d91c13dce2 Author: jjg Date: 2013-02-04 18:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/62d91c13dce2 8007492: DocumentationTool cannot locate standard doclet when invoked from JRE Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/api/JavadocTool.java Changeset: 10619513f51a Author: lana Date: 2013-02-04 22:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/10619513f51a Merge Changeset: 2480aec9a3f1 Author: jjh Date: 2013-02-05 18:55 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2480aec9a3f1 8007504: Remove @ignore from tests that no longer need it Reviewed-by: mcimadamore ! test/tools/javac/api/T6306137.java ! test/tools/javac/defaultMethods/TestNoBridgeOnDefaults.java ! test/tools/javac/lambda/LambdaCapture06.java ! test/tools/javac/lambda/LambdaExpr15.java Changeset: 89c664151689 Author: lana Date: 2013-02-11 16:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/89c664151689 Merge Changeset: bc24411bcc37 Author: katleman Date: 2013-02-14 11:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bc24411bcc37 Added tag jdk8-b77 for changeset 89c664151689 ! .hgtags From rkennke at redhat.com Fri Feb 15 02:22:01 2013 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 15 Feb 2013 11:22:01 +0100 Subject: 8008243: Zero: implement fast-bytecodes [Was: Re: [RFC] Fast-bytecodes for Zero] In-Reply-To: <511DE2EF.9090106@oracle.com> References: <1360784420.2524.31.camel@mercury> <511DE2EF.9090106@oracle.com> Message-ID: <1360923721.6566.20.camel@mercury> Hi David, Am Freitag, den 15.02.2013, 17:25 +1000 schrieb David Holmes: > There's a lot of changes to shared code here - what is the impact on > non-zero platforms? The changes to shared code are in bytecodeInterpreter.cpp, which is, to my knowledge, only used by Zero. *If* there are other interpreters that use it (maybe in closed trees?) they would most likely just pick up and benefit from the improvements. But of course, I cannot tell... Regards, Roman > Thanks, > David > > On 15/02/2013 4:51 AM, Christian Thalinger wrote: > > I've filed: > > > > 8008243: Zero: implement fast-bytecodes > > > > -- Chris > > > > On Feb 13, 2013, at 11:40 AM, Roman Kennke wrote: > > > >> The following change implements support for the following fast-bytecodes > >> in the Zero interpreter: > >> > >> fast_agetfield > >> fast_bgetfield > >> fast_cgetfield > >> fast_dgetfield > >> fast_fgetfield > >> fast_igetfield > >> fast_lgetfield > >> fast_sgetfield > >> fast_aputfield > >> fast_bputfield > >> fast_cputfield > >> fast_dputfield > >> fast_fputfield > >> fast_iputfield > >> fast_lputfield > >> fast_sputfield > >> fast_aload_0 > >> fast_iaccess_0 > >> fast_aaccess_0 > >> fast_faccess_0 > >> fast_iload > >> fast_iload2 > >> fast_icaload > >> fast_invokevfinal > >> > >> All together this leads to a speedup of the interpreter of about 25%. > >> > >> Some notes: > >> - I extracted the JVMTI related blocks into a macro to avoid repetition. > >> - The field get/put opcodes are only rewritten for non-volatile > >> non-static field access, this makes the fast one really fast (no > >> additional branches needed), and static/volatile field accesses seem > >> rare enough anyway. > >> > >> http://cr.openjdk.java.net/~rkennke/zero-fast-opcodes/webrev.00/ > >> > >> > >> Opinions? Can this be included in hotspot? And Can I have a bug-ID? > >> > >> Best regards, > >> Roman > >> > >> > > From alejandro.murillo at oracle.com Fri Feb 15 02:23:46 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 15 Feb 2013 10:23:46 +0000 Subject: hg: hsx/hsx24/hotspot: 8008284: new hotspot build - hs24-b34 Message-ID: <20130215102352.6187347AD5@hg.openjdk.java.net> Changeset: 2eb0b9e2a794 Author: amurillo Date: 2013-02-14 22:38 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2eb0b9e2a794 8008284: new hotspot build - hs24-b34 Reviewed-by: jcoomes ! make/hotspot_version From david.holmes at oracle.com Fri Feb 15 02:48:26 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Feb 2013 20:48:26 +1000 Subject: 8008243: Zero: implement fast-bytecodes [Was: Re: [RFC] Fast-bytecodes for Zero] In-Reply-To: <1360923721.6566.20.camel@mercury> References: <1360784420.2524.31.camel@mercury> <511DE2EF.9090106@oracle.com> <1360923721.6566.20.camel@mercury> Message-ID: <511E127A.7070008@oracle.com> On 15/02/2013 8:22 PM, Roman Kennke wrote: > Hi David, > > Am Freitag, den 15.02.2013, 17:25 +1000 schrieb David Holmes: >> There's a lot of changes to shared code here - what is the impact on >> non-zero platforms? > > The changes to shared code are in bytecodeInterpreter.cpp, which is, to > my knowledge, only used by Zero. *If* there are other interpreters that > use it (maybe in closed trees?) they would most likely just pick up and > benefit from the improvements. But of course, I cannot tell... Ah okay - I didn't realise that. I'll leave it to Christian and other compiler knowledgeable folks then. Thanks, David > Regards, > Roman > >> Thanks, >> David >> >> On 15/02/2013 4:51 AM, Christian Thalinger wrote: >>> I've filed: >>> >>> 8008243: Zero: implement fast-bytecodes >>> >>> -- Chris >>> >>> On Feb 13, 2013, at 11:40 AM, Roman Kennke wrote: >>> >>>> The following change implements support for the following fast-bytecodes >>>> in the Zero interpreter: >>>> >>>> fast_agetfield >>>> fast_bgetfield >>>> fast_cgetfield >>>> fast_dgetfield >>>> fast_fgetfield >>>> fast_igetfield >>>> fast_lgetfield >>>> fast_sgetfield >>>> fast_aputfield >>>> fast_bputfield >>>> fast_cputfield >>>> fast_dputfield >>>> fast_fputfield >>>> fast_iputfield >>>> fast_lputfield >>>> fast_sputfield >>>> fast_aload_0 >>>> fast_iaccess_0 >>>> fast_aaccess_0 >>>> fast_faccess_0 >>>> fast_iload >>>> fast_iload2 >>>> fast_icaload >>>> fast_invokevfinal >>>> >>>> All together this leads to a speedup of the interpreter of about 25%. >>>> >>>> Some notes: >>>> - I extracted the JVMTI related blocks into a macro to avoid repetition. >>>> - The field get/put opcodes are only rewritten for non-volatile >>>> non-static field access, this makes the fast one really fast (no >>>> additional branches needed), and static/volatile field accesses seem >>>> rare enough anyway. >>>> >>>> http://cr.openjdk.java.net/~rkennke/zero-fast-opcodes/webrev.00/ >>>> >>>> >>>> Opinions? Can this be included in hotspot? And Can I have a bug-ID? >>>> >>>> Best regards, >>>> Roman >>>> >>>> >>> > > From vitalyd at gmail.com Fri Feb 15 06:39:45 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 15 Feb 2013 09:39:45 -0500 Subject: 8008243: Zero: implement fast-bytecodes [Was: Re: [RFC] Fast-bytecodes for Zero] In-Reply-To: <1360923721.6566.20.camel@mercury> References: <1360784420.2524.31.camel@mercury> <511DE2EF.9090106@oracle.com> <1360923721.6566.20.camel@mercury> Message-ID: Hi Roman, One suggestion I have is to add functions to JvmtiExport like has_field_access_watchers() and change this accordingly: count_addr = (int *)JvmtiExport::get_field_access_count_addr(); \ 436 if ( *count_addr > 0 ) { The has_XXX function can simply have that code inside. Reason I think it's useful is because the field is an int but the get_* function declares address as return type requiring you to cast and thus know internal representation. Seems cleaner to encapsulate inside JvmtiExport? Thanks Sent from my phone On Feb 15, 2013 5:23 AM, "Roman Kennke" wrote: > Hi David, > > Am Freitag, den 15.02.2013, 17:25 +1000 schrieb David Holmes: > > There's a lot of changes to shared code here - what is the impact on > > non-zero platforms? > > The changes to shared code are in bytecodeInterpreter.cpp, which is, to > my knowledge, only used by Zero. *If* there are other interpreters that > use it (maybe in closed trees?) they would most likely just pick up and > benefit from the improvements. But of course, I cannot tell... > > Regards, > Roman > > > Thanks, > > David > > > > On 15/02/2013 4:51 AM, Christian Thalinger wrote: > > > I've filed: > > > > > > 8008243: Zero: implement fast-bytecodes > > > > > > -- Chris > > > > > > On Feb 13, 2013, at 11:40 AM, Roman Kennke wrote: > > > > > >> The following change implements support for the following > fast-bytecodes > > >> in the Zero interpreter: > > >> > > >> fast_agetfield > > >> fast_bgetfield > > >> fast_cgetfield > > >> fast_dgetfield > > >> fast_fgetfield > > >> fast_igetfield > > >> fast_lgetfield > > >> fast_sgetfield > > >> fast_aputfield > > >> fast_bputfield > > >> fast_cputfield > > >> fast_dputfield > > >> fast_fputfield > > >> fast_iputfield > > >> fast_lputfield > > >> fast_sputfield > > >> fast_aload_0 > > >> fast_iaccess_0 > > >> fast_aaccess_0 > > >> fast_faccess_0 > > >> fast_iload > > >> fast_iload2 > > >> fast_icaload > > >> fast_invokevfinal > > >> > > >> All together this leads to a speedup of the interpreter of about 25%. > > >> > > >> Some notes: > > >> - I extracted the JVMTI related blocks into a macro to avoid > repetition. > > >> - The field get/put opcodes are only rewritten for non-volatile > > >> non-static field access, this makes the fast one really fast (no > > >> additional branches needed), and static/volatile field accesses seem > > >> rare enough anyway. > > >> > > >> http://cr.openjdk.java.net/~rkennke/zero-fast-opcodes/webrev.00/ > > >> > > >> > > >> Opinions? Can this be included in hotspot? And Can I have a bug-ID? > > >> > > >> Best regards, > > >> Roman > > >> > > >> > > > > > > From joe.darcy at oracle.com Fri Feb 15 11:11:20 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 15 Feb 2013 11:11:20 -0800 Subject: Tr : double a%b returns NaN for some (a,b) (|a| < inf, |b|>0) In-Reply-To: <1360709553.65109.YahooMailNeo@web132101.mail.ird.yahoo.com> References: <1360619599.25551.YahooMailNeo@web132105.mail.ird.yahoo.com> <1360620285.76858.YahooMailNeo@web132103.mail.ird.yahoo.com> <51197C04.8070908@oracle.com> <1360694075.66018.YahooMailNeo@web132105.mail.ird.yahoo.com> <511AC026.9080802@oracle.com> <1360709553.65109.YahooMailNeo@web132101.mail.ird.yahoo.com> Message-ID: <511E8858.3090300@oracle.com> Hello, On 2/12/2013 2:52 PM, Jeff Hain wrote: > > Joe Darcy wrote: > >For the non-NaN floating-point values, I recommend using hexadecimal > >floating-point syntax rather than calling Double.longBitsToDouble on a > >hex string value; see Double.toHexString for details. > > > It should be more readable for humans indeed, but I guess my > transformation > into a processor is now irreversible ;) > > > > >you can add the "strictfp" modifier to remove one source of possible > variance. > > > Still happens with strictfp. > (about strictfp, off-topic but I removed it from all my code after > someone pointed out it added some overhead (like 20ms+ on > 10_000_000 calls micro-benchmarks, so about 2ns+), when > having strictfp code call non-strictfp code or the opposite) > On non-x86 systems, the presence or absence of strictfp should be a no-op. When an x86 implementation is only using SSE registers, such as when it is not calling into intrinsified java.lang.Math methods using the x87 instructions, there needed be additional overhead, but I haven't done measurements of what overhead may exist. -Joe From alejandro.murillo at oracle.com Fri Feb 15 15:31:57 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 15 Feb 2013 23:31:57 +0000 Subject: hg: hsx/hsx25/hotspot: 36 new changesets Message-ID: <20130215233319.04D2A47B19@hg.openjdk.java.net> Changeset: 1f84c84f8e1a Author: katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1f84c84f8e1a Added tag jdk8-b77 for changeset cdb46031e718 ! .hgtags Changeset: 1a0174612b49 Author: amurillo Date: 2013-02-08 08:16 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1a0174612b49 8007801: new hotspot build - hs25-b19 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8d9fc28831cc Author: dcubed Date: 2013-02-06 14:31 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8d9fc28831cc 7182152: Instrumentation hot swap test incorrect monitor count Summary: Add/refine new tracing support using -XX:TraceRedefineClasses=16384. Reviewed-by: coleenp, acorn, sspitsyn ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.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/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/prims/jvmtiRedefineClassesTrace.hpp ! src/share/vm/utilities/accessFlags.cpp ! src/share/vm/utilities/accessFlags.hpp Changeset: 3a88007634b0 Author: ctornqvi Date: 2013-02-08 10:42 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3a88007634b0 8007434: Write tests for 8006298 Summary: Four tests written for 8006298 Reviewed-by: mgerdin, coleenp + test/runtime/CommandLine/BooleanFlagWithInvalidValue.java + test/runtime/CommandLine/FlagWithInvalidValue.java + test/runtime/CommandLine/NonBooleanFlagWithInvalidBooleanPrefix.java + test/runtime/CommandLine/UnrecognizedVMOption.java Changeset: 758935f7c23f Author: sla Date: 2013-02-08 12:48 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/758935f7c23f 8006423: SA: NullPointerException in sun.jvm.hotspot.debugger.bsd.BsdThread.getContext(BsdThread.java:67) Summary: Do not rely on mach thread port names to identify threads from SA Reviewed-by: dholmes, minqi, rbackman ! agent/src/os/bsd/MacosxDebuggerLocal.m ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/bsd_amd64/BsdAMD64JavaThreadPDAccess.java ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp Changeset: 7194f764221c Author: sla Date: 2013-02-08 14:05 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7194f764221c Merge Changeset: 461a3adac4d1 Author: sspitsyn Date: 2013-02-08 09:14 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/461a3adac4d1 Merge ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp Changeset: 8bf62bd86a4e Author: zgu Date: 2013-02-08 14:49 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8bf62bd86a4e 8007791: More Restricted hs_err file permission Summary: Enforce more restricted hs_file permission Reviewed-by: acorn, dcubed, dsamersoff ! src/share/vm/utilities/vmError.cpp Changeset: 1ba5b18088a8 Author: zgu Date: 2013-02-08 14:32 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1ba5b18088a8 Merge Changeset: 41d73c9b30a8 Author: zgu Date: 2013-02-08 16:31 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/41d73c9b30a8 8006691: Remove jvm_version_info.is_kernel_jvm field Summary: Removed is_kernel_jvm from jvm_version_info as Kernel VM has been deprecated Reviewed-by: mchung, coleenp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 3f11b37f047c Author: zgu Date: 2013-02-08 13:55 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3f11b37f047c Merge Changeset: f989aff6946f Author: zgu Date: 2013-02-08 16:56 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f989aff6946f Merge Changeset: 927a311d00f9 Author: coleenp Date: 2013-02-11 14:06 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/927a311d00f9 8007320: NPG: move method annotations Summary: allocate method annotations and attach to ConstMethod if present Reviewed-by: dcubed, jiangli, sspitsyn, iklam ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/annotations.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/vmStructs.cpp + test/runtime/8007320/ConstMethodTest.java Changeset: 5ee2b330eacd Author: zgu Date: 2013-02-12 12:19 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5ee2b330eacd 8007950: Undo hs_file permission change Summary: Reverse hs_err file permission back to 0666, as early push was premature Reviewed-by: dsamersoff, dcubed, acorn ! src/share/vm/utilities/vmError.cpp Changeset: deb43b8a436e Author: sspitsyn Date: 2013-02-13 08:42 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/deb43b8a436e Merge Changeset: bce1ac447f6b Author: johnc Date: 2013-02-06 14:50 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bce1ac447f6b 7052429: G1: Avoid unnecessary scanning of humongous regions during concurrent marking Summary: Skip unnecessary scanning of bitmap for unmarked humongous objects/regions. Reviewed-by: jwilhelm, johnc Contributed-by: Tao Mao ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/runtime/globals.hpp Changeset: f64ffbf81af5 Author: jwilhelm Date: 2013-02-07 15:51 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f64ffbf81af5 8006432: Ratio flags should be unsigned Summary: Flags changed to be of uintx type Reviewed-by: johnc, tamao ! src/cpu/zero/vm/shark_globals_zero.hpp ! src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 5d8325eb8240 Author: brutisso Date: 2013-02-07 22:04 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5d8325eb8240 Merge ! src/share/vm/runtime/thread.cpp Changeset: 9425ba04792d Author: brutisso Date: 2013-02-07 18:40 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9425ba04792d Merge - agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java - make/solaris/makefiles/kernel.make ! src/share/vm/runtime/arguments.cpp - test/runtime/7158988/TestFieldMonitor.sh Changeset: ad747ee9d0b1 Author: brutisso Date: 2013-02-10 21:15 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ad747ee9d0b1 8002144: G1: large number of evacuation failures may lead to large c heap memory usage Summary: Use Stack<> instead of GrowableArray to keep track of preserved marks. Also reviewed by vitalyd at gmail.com. Reviewed-by: johnc, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 5e401ef52ec0 Author: johnc Date: 2013-02-11 15:24 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5e401ef52ec0 8007772: G1: assert(!hr->isHumongous() || mr.start() == hr->bottom()) failed: the start of HeapRegion and MemRegion should be consistent for humongous regions Summary: In do_marking_step(), we should always give up current region after scanning the object, if the region is humongous. Reviewed-by: brutisso, jwilhelm, tamao ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: a83cd101fd62 Author: jmasa Date: 2013-01-23 19:08 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a83cd101fd62 8005452: NPG: Create new flags for Metaspace resizing policy Reviewed-by: johnc, jwilhelm, coleenp, stefank ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: b8d5d7a6c94c Author: brutisso Date: 2013-02-14 11:01 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b8d5d7a6c94c Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/thread.cpp Changeset: 91a23b11d8dc Author: kvn Date: 2013-02-08 15:07 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/91a23b11d8dc 8007708: compiler/6855215 assert(VM_Version::supports_sse4_2()) Summary: Added missing UseSSE42 check. Also added missing avx2 assert for vpermq instruction. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp Changeset: 309460dcedf7 Author: morris Date: 2013-02-08 15:39 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/309460dcedf7 8006851: When TieredCompilation is set, max code cache should be bumped to 256mb Summary: Set ReservedCodeCacheSize to (default value)*5 when TieredCompilation is on. Reviewed-by: kvn, twisti ! src/share/vm/runtime/arguments.cpp Changeset: 2c673161698a Author: drchase Date: 2013-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2c673161698a 8007402: Code cleanup to remove Parfait false positive Summary: add array access range check Reviewed-by: kvn ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp Changeset: 64d2a0a39954 Author: kmo Date: 2013-02-10 22:35 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/64d2a0a39954 8006430: TraceTypeProfile is a product flag while it should be a diagnostic flag Summary: make sure all diagnostic and experimental flag kinds are checked in Flag::is_unlocked() Reviewed-by: kvn ! src/share/vm/runtime/globals.cpp Changeset: a9c29dfc7d73 Author: morris Date: 2013-02-11 10:38 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a9c29dfc7d73 8003251: ARM: move MacroAssembler into separate file Summary: moved MacroAssembler into separate file Reviewed-by: twisti, kvn, dlong ! src/share/vm/asm/macroAssembler.hpp ! src/share/vm/asm/macroAssembler.inline.hpp Changeset: 1e5e28bac299 Author: morris Date: 2013-02-11 14:47 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1e5e28bac299 8003252: PPC: move MacroAssembler into separate file Summary: moved MacroAssembler into separate file Reviewed-by: twisti, kvn, dlong ! src/share/vm/asm/macroAssembler.hpp ! src/share/vm/asm/macroAssembler.inline.hpp Changeset: 8b3da8d14c93 Author: roland Date: 2013-02-12 12:56 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8b3da8d14c93 7197327: 40% regression on 8 b41 comp 8 b40 on specjvm2008.mpegaudio on oob Summary: Add support for expensive nodes. Reviewed-by: kvn ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/subnode.hpp Changeset: c703f9c4b025 Author: kmo Date: 2013-02-12 07:39 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c703f9c4b025 8002169: TEST_BUG: compiler/7009359/Test7009359.java sometimes times out Summary: make the test less prone to timeout by reducing the amount of iteration and allowing main to be compiled Reviewed-by: jrose ! test/compiler/7009359/Test7009359.java Changeset: aaad39923cdb Author: kmo Date: 2013-02-12 14:33 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/aaad39923cdb Merge Changeset: 12e01444ca2d Author: iignatyev Date: 2013-02-13 08:29 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/12e01444ca2d 8006683: Add WhiteBox API to testing of compiler Reviewed-by: kvn, vlivanov ! src/share/tools/whitebox/sun/hotspot/WhiteBox.java ! src/share/vm/prims/wbtestmethods/parserTests.hpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/prims/whitebox.hpp + test/compiler/whitebox/CompilerWhiteBoxTest.java + test/compiler/whitebox/DeoptimizeAllTest.java + test/compiler/whitebox/DeoptimizeMethodTest.java + test/compiler/whitebox/IsMethodCompilableTest.java + test/compiler/whitebox/MakeMethodNotCompilableTest.java + test/compiler/whitebox/SetDontInlineMethodTest.java Changeset: 1cdf241a4b26 Author: vlivanov Date: 2013-02-14 05:36 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1cdf241a4b26 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 9f19f4a7d48a Author: amurillo Date: 2013-02-15 13:27 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9f19f4a7d48a Merge Changeset: d5e12e7d2f71 Author: amurillo Date: 2013-02-15 13:27 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d5e12e7d2f71 Added tag hs25-b19 for changeset 9f19f4a7d48a ! .hgtags From mikael.vidstedt at oracle.com Fri Feb 15 17:10:52 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 15 Feb 2013 17:10:52 -0800 Subject: RFR (S): 8008081: Print outs do not have matching arguments In-Reply-To: <511DECFA.9090406@oracle.com> References: <511AFA0A.2090504@oracle.com> <511DECFA.9090406@oracle.com> Message-ID: <511EDC9C.1000208@oracle.com> On 2/15/2013 12:08 AM, David Holmes wrote: > On 13/02/2013 12:27 PM, Mikael Vidstedt wrote: >> Please review the following change: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8008081/webrev.00/webrev >> >> Background: >> >> I found a few occurrences of calls to print type functions where the >> arguments do not match the format string. I hope that I have added the >> right/intended arguments in the respective places but could use some >> help to verify that that is indeed the case. > > In c1_FrameMap: > > 316 if( _num_monitors > 0) { > 317 tty->print_cr("monitor [0]:%d | [%2d]:%d", > 318 in_bytes(sp_offset_for_monitor_base(0)), > 319 in_bytes(sp_offset_for_monitor_base(_num_monitors)), > 320 _num_monitors); > 321 } > > I think the last two args need swapping and should it be > _num_monitors-1 ie the "index" ? And does that make > sp_offset_for_monitor_base(_num_monitors) wrong ?? Agreed, they should indeed be swapped. Thanks Staffan/David for pointing this out! Whether or not it should be _num_monitors-1 is indeed a good question. The code below uses num_spills-1 and prints things slightly differently if there is only one spill, so for symmetry reasons maybe this code should do the same thing? I'm counting on a C1 expert to provide guidance. Meanwhile I've updated the webrev to add _num_monitors in the right place: http://cr.openjdk.java.net/~mikael/webrevs/8008081/webrev.01/webrev/ > Everything else seems reasonable - some obvious, some less so - but > all 1000% better than before ;-) Wow, that sure is a lot of % :) Cheers, Mikael > > David > ----- > > >> One special case is in this webrev is jvmtiEnter.xls. Since it is used >> to generate the jvmtiEnterTrace.cpp file and therefore is a bit less >> obvious to review I have prepared a pair of before/after files for your >> convenience: >> >> Before: >> http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.orig >> >> After: >> http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.fixed >> >> >> >> I also prepared a diff -u of before vs after: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.diff >> >> >> Passes JPRT. >> >> Cheers, >> Mikael From alejandro.murillo at oracle.com Fri Feb 15 17:26:03 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 16 Feb 2013 01:26:03 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130216012613.3C64947B1A@hg.openjdk.java.net> Changeset: 1f84c84f8e1a Author: katleman Date: 2013-02-14 11:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1f84c84f8e1a Added tag jdk8-b77 for changeset cdb46031e718 ! .hgtags Changeset: 9f19f4a7d48a Author: amurillo Date: 2013-02-15 13:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9f19f4a7d48a Merge Changeset: d5e12e7d2f71 Author: amurillo Date: 2013-02-15 13:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d5e12e7d2f71 Added tag hs25-b19 for changeset 9f19f4a7d48a ! .hgtags Changeset: 57b81d6c3641 Author: amurillo Date: 2013-02-15 13:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/57b81d6c3641 8008286: new hotspot build - hs25-b20 Reviewed-by: jcoomes ! make/hotspot_version From joseph.provino at oracle.com Sun Feb 17 12:19:54 2013 From: joseph.provino at oracle.com (JOSEPH PROVINO) Date: Sun, 17 Feb 2013 15:19:54 -0500 Subject: Review request 8008310 - Some adjustments needed to minimal VM warnings and errors for unsupported command line options Message-ID: <51213B6A.8080303@oracle.com> Webrev is here: http://cr.openjdk.java.net/~jprovino/8008310/webrev.00 Only change is to arguments.cpp. thanks. joe From david.holmes at oracle.com Sun Feb 17 15:27:55 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Feb 2013 09:27:55 +1000 Subject: RFR (S): 8008081: Print outs do not have matching arguments In-Reply-To: <511EDC9C.1000208@oracle.com> References: <511AFA0A.2090504@oracle.com> <511DECFA.9090406@oracle.com> <511EDC9C.1000208@oracle.com> Message-ID: <5121677B.8010402@oracle.com> On 16/02/2013 11:10 AM, Mikael Vidstedt wrote: > > On 2/15/2013 12:08 AM, David Holmes wrote: >> On 13/02/2013 12:27 PM, Mikael Vidstedt wrote: >>> Please review the following change: >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/8008081/webrev.00/webrev >>> >>> Background: >>> >>> I found a few occurrences of calls to print type functions where the >>> arguments do not match the format string. I hope that I have added the >>> right/intended arguments in the respective places but could use some >>> help to verify that that is indeed the case. >> >> In c1_FrameMap: >> >> 316 if( _num_monitors > 0) { >> 317 tty->print_cr("monitor [0]:%d | [%2d]:%d", >> 318 in_bytes(sp_offset_for_monitor_base(0)), >> 319 in_bytes(sp_offset_for_monitor_base(_num_monitors)), >> 320 _num_monitors); >> 321 } >> >> I think the last two args need swapping and should it be >> _num_monitors-1 ie the "index" ? And does that make >> sp_offset_for_monitor_base(_num_monitors) wrong ?? > > Agreed, they should indeed be swapped. Thanks Staffan/David for pointing > this out! > > Whether or not it should be _num_monitors-1 is indeed a good question. > The code below uses num_spills-1 and prints things slightly differently > if there is only one spill, so for symmetry reasons maybe this code > should do the same thing? I'm counting on a C1 expert to provide guidance. Not a C1 expert but this: void check_monitor_index (int monitor_index) const { assert(monitor_index >= 0 && monitor_index < _num_monitors, "bad index"); } indicates that we shouldn't be using sp_offset_for_monitor_base(_num_monitors) Cheers, David ----- > Meanwhile I've updated the webrev to add _num_monitors in the right place: > > http://cr.openjdk.java.net/~mikael/webrevs/8008081/webrev.01/webrev/ > >> Everything else seems reasonable - some obvious, some less so - but >> all 1000% better than before ;-) > > Wow, that sure is a lot of % :) > > Cheers, > Mikael > >> >> David >> ----- >> >> >>> One special case is in this webrev is jvmtiEnter.xls. Since it is used >>> to generate the jvmtiEnterTrace.cpp file and therefore is a bit less >>> obvious to review I have prepared a pair of before/after files for your >>> convenience: >>> >>> Before: >>> http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.orig >>> >>> After: >>> http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.fixed >>> >>> >>> >>> I also prepared a diff -u of before vs after: >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.diff >>> >>> >>> Passes JPRT. >>> >>> Cheers, >>> Mikael > From david.holmes at oracle.com Sun Feb 17 15:49:59 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Feb 2013 09:49:59 +1000 Subject: Review request 8008310 - Some adjustments needed to minimal VM warnings and errors for unsupported command line options In-Reply-To: <51213B6A.8080303@oracle.com> References: <51213B6A.8080303@oracle.com> Message-ID: <51216CA7.40604@oracle.com> Hi Joe, On 18/02/2013 6:19 AM, JOSEPH PROVINO wrote: > Webrev is here: http://cr.openjdk.java.net/~jprovino/8008310/webrev.00 > > Only change is to arguments.cpp. I'm sorry I didn't pick up on this with earlier changes (eg -Dcom.sun.management usage) but it seems to me that the argument parsing code is not supposed to call vm_exit_during_initialization, but should instead print an error message and return JNI_ERR. This will ultimately lead to CreateJavaVM returning JNI_ERR. There is some existing use of vm_exit_during_initialization in arguments.cpp (CDS related and compilation policy related) but I would say those show bad examples of how to handle argument errors. There is an open RFE for the VM to never terminate during initialization but only return JNI_ERR. We're a long way from that, but I don't think we should be moving in the other direction. So I would say that these changes from warnings to failures have to be redone. In addition the other uses of vm_exit_during_initialization related to the minimal VM, here: 2475 if (match_option(option, "-Dcom.sun.management", &tail)) { 2476 #if INCLUDE_MANAGEMENT 2477 FLAG_SET_CMDLINE(bool, ManagementServer, true); 2478 #else 2479 vm_exit_during_initialization( 2480 "-Dcom.sun.management is not supported in this VM.", NULL); 2481 #endif here: 2826 #if !INCLUDE_MANAGEMENT 2827 } else if (match_option(option, "-XX:+ManagementServer", &tail)) { 2828 vm_exit_during_initialization( 2829 "ManagementServer is not supported in this VM.", NULL); 2830 #endif // INCLUDE_MANAGEMENT and here 3132 #if INCLUDE_NMT 3133 MemTracker::init_tracking_options(tail); 3134 #else 3135 vm_exit_during_initialization( 3136 "Native Memory Tracking is not supported in this VM", NULL); 3137 #endif should also be changed. David ----- > thanks. > > joe From david.holmes at oracle.com Sun Feb 17 20:23:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Feb 2013 14:23:42 +1000 Subject: RFR (XS): 8007901 SA: Don't read flag values as constants In-Reply-To: <66CB6E74-D03C-43A7-B3B1-C162C2992398@oracle.com> References: <51198AE3.5040706@oracle.com> <66CB6E74-D03C-43A7-B3B1-C162C2992398@oracle.com> Message-ID: <5121ACCE.6080707@oracle.com> Thanks for clarifying this Staffan, I see now how this was setup wrong in the first place. You are using the right mechanism now. I'm not sure UseTLAB warrants its own accessor in VM anymore as the two uses of it can simply ask for the flag value directly. Your call. Thanks, David On 12/02/2013 8:19 PM, Staffan Larsen wrote: > The values are initialized at VM compile time in the VMStructs::localHotSpotVMIntConstants array. I don't think we want to modify SA so that values of int constants is made into a dynamic lookup. Or at least, that is a fairly significant change to SA. The problem here was to think that UseTLAB is a constant when it isn't. > > Yes, I thought about a regression test for this, but the valuable test would be to verify that no command line flag values are read as constants, and I don't see how I could write that. > > Thanks, > /Staffan > > On 12 feb 2013, at 01:20, David Holmes wrote: > >> On 10/02/2013 5:06 AM, Staffan Larsen wrote: >>> Please review this small patch to avoid reading flag values in SA as constants. Reading them as constants means SA will only see the default value for these flags. Instead the infrastructure in SA to read command line flags should be used. In addition the value if EnableInvokeDynamic is never used, so I removed that from SA. >> >> Isn't the real problem in the way db is initialized with the values for these flags? ie shouldn't db.lookupIntConstant("UseTLAB").intValue() be returning the actual value of UseTLAB as it occurs in the VM ? >> >> Also we need a regression test for this as obviously it ain't being tested! :( >> >> Thanks, >> David >> >>> webrev: http://cr.openjdk.java.net/~sla/8007901/webrev.00/ >>> bug: http://bugs.sun.com/view_bug.do?bug_id=8007901 (not yet visible) >>> >>> Thanks, >>> /Staffan >>> > From staffan.larsen at oracle.com Mon Feb 18 01:41:42 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 18 Feb 2013 10:41:42 +0100 Subject: RFR (XS): 8007901 SA: Don't read flag values as constants In-Reply-To: <5121ACCE.6080707@oracle.com> References: <51198AE3.5040706@oracle.com> <66CB6E74-D03C-43A7-B3B1-C162C2992398@oracle.com> <5121ACCE.6080707@oracle.com> Message-ID: <0A6876F8-136B-46EC-8DFC-4AEAD95DEA30@oracle.com> I choose to follow the same pattern as for other flags, although I agree that the extra accessor isn't really needed. Thanks David! /Staffan On 18 feb 2013, at 05:23, David Holmes wrote: > Thanks for clarifying this Staffan, I see now how this was setup wrong in the first place. You are using the right mechanism now. > > I'm not sure UseTLAB warrants its own accessor in VM anymore as the two uses of it can simply ask for the flag value directly. Your call. > > Thanks, > David > > On 12/02/2013 8:19 PM, Staffan Larsen wrote: >> The values are initialized at VM compile time in the VMStructs::localHotSpotVMIntConstants array. I don't think we want to modify SA so that values of int constants is made into a dynamic lookup. Or at least, that is a fairly significant change to SA. The problem here was to think that UseTLAB is a constant when it isn't. >> >> Yes, I thought about a regression test for this, but the valuable test would be to verify that no command line flag values are read as constants, and I don't see how I could write that. >> >> Thanks, >> /Staffan >> >> On 12 feb 2013, at 01:20, David Holmes wrote: >> >>> On 10/02/2013 5:06 AM, Staffan Larsen wrote: >>>> Please review this small patch to avoid reading flag values in SA as constants. Reading them as constants means SA will only see the default value for these flags. Instead the infrastructure in SA to read command line flags should be used. In addition the value if EnableInvokeDynamic is never used, so I removed that from SA. >>> >>> Isn't the real problem in the way db is initialized with the values for these flags? ie shouldn't db.lookupIntConstant("UseTLAB").intValue() be returning the actual value of UseTLAB as it occurs in the VM ? >>> >>> Also we need a regression test for this as obviously it ain't being tested! :( >>> >>> Thanks, >>> David >>> >>>> webrev: http://cr.openjdk.java.net/~sla/8007901/webrev.00/ >>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8007901 (not yet visible) >>>> >>>> Thanks, >>>> /Staffan >>>> >> From joseph.provino at oracle.com Mon Feb 18 06:45:52 2013 From: joseph.provino at oracle.com (JOSEPH PROVINO) Date: Mon, 18 Feb 2013 09:45:52 -0500 Subject: Review request 8008310 - Some adjustments needed to minimal VM warnings and errors for unsupported command line options In-Reply-To: <51216CA7.40604@oracle.com> References: <51213B6A.8080303@oracle.com> <51216CA7.40604@oracle.com> Message-ID: <51223EA0.6030100@oracle.com> Okay, I'll make those changes. joe On 2/17/2013 6:49 PM, David Holmes wrote: > Hi Joe, > > On 18/02/2013 6:19 AM, JOSEPH PROVINO wrote: >> Webrev is here: http://cr.openjdk.java.net/~jprovino/8008310/webrev.00 >> >> Only change is to arguments.cpp. > > I'm sorry I didn't pick up on this with earlier changes (eg > -Dcom.sun.management usage) but it seems to me that the argument > parsing code is not supposed to call vm_exit_during_initialization, > but should instead print an error message and return JNI_ERR. This > will ultimately lead to CreateJavaVM returning JNI_ERR. > > There is some existing use of vm_exit_during_initialization in > arguments.cpp (CDS related and compilation policy related) but I would > say those show bad examples of how to handle argument errors. There is > an open RFE for the VM to never terminate during initialization but > only return JNI_ERR. We're a long way from that, but I don't think we > should be moving in the other direction. > > So I would say that these changes from warnings to failures have to be > redone. In addition the other uses of vm_exit_during_initialization > related to the minimal VM, here: > > 2475 if (match_option(option, "-Dcom.sun.management", &tail)) { > 2476 #if INCLUDE_MANAGEMENT > 2477 FLAG_SET_CMDLINE(bool, ManagementServer, true); > 2478 #else > 2479 vm_exit_during_initialization( > 2480 "-Dcom.sun.management is not supported in this VM.", > NULL); > 2481 #endif > > here: > > 2826 #if !INCLUDE_MANAGEMENT > 2827 } else if (match_option(option, "-XX:+ManagementServer", > &tail)) { > 2828 vm_exit_during_initialization( > 2829 "ManagementServer is not supported in this VM.", NULL); > 2830 #endif // INCLUDE_MANAGEMENT > > and here > > 3132 #if INCLUDE_NMT > 3133 MemTracker::init_tracking_options(tail); > 3134 #else > 3135 vm_exit_during_initialization( > 3136 "Native Memory Tracking is not supported in this VM", NULL); > 3137 #endif > > should also be changed. > > David > ----- > >> thanks. >> >> joe From eric.mccorkle at oracle.com Mon Feb 18 07:03:28 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 18 Feb 2013 10:03:28 -0500 Subject: Review request for JDK-8007153: update method parameters data in redefineClasses Message-ID: <512242C0.7090900@oracle.com> Hello, Please review this simple patch which updates hotspot to correctly manage method parameter data when redefineClasses is called. The webrev is here: http://cr.openjdk.java.net/~emc/8007153/ From coleen.phillimore at oracle.com Mon Feb 18 07:21:13 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 18 Feb 2013 10:21:13 -0500 Subject: Review request for JDK-8007153: update method parameters data in redefineClasses In-Reply-To: <512242C0.7090900@oracle.com> References: <512242C0.7090900@oracle.com> Message-ID: <512246E9.7000907@oracle.com> Eric, This looks good. I should have changed rewrite_cp_refs_in_methods_annotations and the other two to be called from rewrite_cp_refs_in_method() like you did. Are type_annotations also constant pool references? Should they be rewritten too? Is there a test for this? Thanks, Coleen On 02/18/2013 10:03 AM, Eric McCorkle wrote: > Hello, > > Please review this simple patch which updates hotspot to correctly > manage method parameter data when redefineClasses is called. > > The webrev is here: > http://cr.openjdk.java.net/~emc/8007153/ From eric.mccorkle at oracle.com Mon Feb 18 08:03:43 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 18 Feb 2013 11:03:43 -0500 Subject: Review request for JDK-8007153: update method parameters data in redefineClasses In-Reply-To: <512246E9.7000907@oracle.com> References: <512242C0.7090900@oracle.com> <512246E9.7000907@oracle.com> Message-ID: <512250DF.6070900@oracle.com> There are other bits in ConstMethod that seem to use CP indexes, and probably need to be rewritten. For this, I'm running my usual tests (testlist, ie everything). For this specific issue, that's a bit difficult, as it involves creating JAR files and running the vm with very specific arguments (which took me a while to figure out). I'm pretty sure this is beyond what JPRT can do. I don't really know anything about hotspot's test suites, so someone else will have to answer there. On 02/18/13 10:21, Coleen Phillimore wrote: > > Eric, > This looks good. > I should have changed rewrite_cp_refs_in_methods_annotations and the > other two to be called from rewrite_cp_refs_in_method() like you did. > Are type_annotations also constant pool references? Should they be > rewritten too? Is there a test for this? > > Thanks, > Coleen > > On 02/18/2013 10:03 AM, Eric McCorkle wrote: >> Hello, >> >> Please review this simple patch which updates hotspot to correctly >> manage method parameter data when redefineClasses is called. >> >> The webrev is here: >> http://cr.openjdk.java.net/~emc/8007153/ > From staffan.larsen at oracle.com Mon Feb 18 09:06:58 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Mon, 18 Feb 2013 17:06:58 +0000 Subject: hg: hsx/hsx24/hotspot: 8008102: SA on OS X does not stop the attached process Message-ID: <20130218170704.3862E47B6A@hg.openjdk.java.net> Changeset: e403a79fc41a Author: sla Date: 2013-02-15 08:54 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e403a79fc41a 8008102: SA on OS X does not stop the attached process Reviewed-by: dholmes, rbackman ! agent/src/os/bsd/MacosxDebuggerLocal.m From staffan.larsen at oracle.com Mon Feb 18 10:22:00 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 18 Feb 2013 19:22:00 +0100 Subject: Result: CFV: New HSX Committer: Serguei Spitsyn Message-ID: <9056D959-2025-4974-9180-12F0FA4F80CA@oracle.com> Voting for Serguei Spitsyn is now closed. Yes: 18 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Staffan From chris.plummer at oracle.com Mon Feb 18 10:52:33 2013 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 18 Feb 2013 10:52:33 -0800 Subject: Review request 8008310 - Some adjustments needed to, minimal VM warnings and errors for unsupported command line options In-Reply-To: References: Message-ID: <51227871.1010504@oracle.com> Hi Joe, I don't think the -Xshare change is quite correct. If you specify something invalid, like -Xshare:foo, you will get a warning about shared archives not being supported. This is a change from the current behavior, which will say "Unrecognized option" and then exit the VM. You probably need to check for each valid -Xshare option. Chris On 2/18/13 7:24 AM, JOSEPH PROVINO wrote: > Webrev is here:http://cr.openjdk.java.net/~jprovino/8008310/webrev.00 > > Only change is to arguments.cpp. > > thanks. > > joe From joseph.provino at oracle.com Mon Feb 18 10:53:48 2013 From: joseph.provino at oracle.com (JOSEPH PROVINO) Date: Mon, 18 Feb 2013 13:53:48 -0500 Subject: Review request 8008310 - Some adjustments needed to, minimal VM warnings and errors for unsupported command line options In-Reply-To: <51227871.1010504@oracle.com> References: <51227871.1010504@oracle.com> Message-ID: <512278BC.4080606@oracle.com> On 2/18/2013 1:52 PM, Chris Plummer wrote: > Hi Joe, > > I don't think the -Xshare change is quite correct. If you specify > something invalid, like -Xshare:foo, you will get a warning about > shared archives not being supported. This is a change from the current > behavior, which will say "Unrecognized option" and then exit the VM. > You probably need to check for each valid -Xshare option. okay, yeah, that didn't look quite right. joe > > Chris > > On 2/18/13 7:24 AM, JOSEPH PROVINO wrote: >> Webrev is here:http://cr.openjdk.java.net/~jprovino/8008310/webrev.00 >> >> Only change is to arguments.cpp. >> >> thanks. >> >> joe > From staffan.larsen at oracle.com Mon Feb 18 11:01:58 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Mon, 18 Feb 2013 19:01:58 +0000 Subject: hg: hsx/hsx24/hotspot: 8007779: os::die() on solaris should generate core file Message-ID: <20130218190200.E810F47B6E@hg.openjdk.java.net> Changeset: 5624724e4454 Author: sla Date: 2013-02-18 12:49 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5624724e4454 8007779: os::die() on solaris should generate core file Reviewed-by: dholmes, rbackman ! src/os/solaris/vm/os_solaris.cpp From christian.thalinger at oracle.com Mon Feb 18 12:30:08 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 18 Feb 2013 12:30:08 -0800 Subject: 8008243: Zero: implement fast-bytecodes [Was: Re: [RFC] Fast-bytecodes for Zero] In-Reply-To: References: <1360784420.2524.31.camel@mercury> <511DE2EF.9090106@oracle.com> <1360923721.6566.20.camel@mercury> Message-ID: <259E154F-3718-486B-A06F-CBA9C1A186B2@oracle.com> On Feb 15, 2013, at 6:39 AM, Vitaly Davidovich wrote: > Hi Roman, > > One suggestion I have is to add functions to JvmtiExport like has_field_access_watchers() and change this accordingly: > > count_addr = (int *)JvmtiExport::get_field_access_count_addr(); \ > 436 if ( *count_addr > 0 ) { > > The has_XXX function can simply have that code inside. > > Reason I think it's useful is because the field is an int but the get_* function declares address as return type requiring you to cast and thus know internal representation. Seems cleaner to encapsulate inside JvmtiExport? I agree on that but that would be beyond the scope of this change. Roman only moved the code into a macro so he can reuse it in multiple places. Actually I would prefer to move the code into a method because that would make the huge method a little smaller. -- Chris > > Thanks > > Sent from my phone > > On Feb 15, 2013 5:23 AM, "Roman Kennke" wrote: > Hi David, > > Am Freitag, den 15.02.2013, 17:25 +1000 schrieb David Holmes: > > There's a lot of changes to shared code here - what is the impact on > > non-zero platforms? > > The changes to shared code are in bytecodeInterpreter.cpp, which is, to > my knowledge, only used by Zero. *If* there are other interpreters that > use it (maybe in closed trees?) they would most likely just pick up and > benefit from the improvements. But of course, I cannot tell... > > Regards, > Roman > > > Thanks, > > David > > > > On 15/02/2013 4:51 AM, Christian Thalinger wrote: > > > I've filed: > > > > > > 8008243: Zero: implement fast-bytecodes > > > > > > -- Chris > > > > > > On Feb 13, 2013, at 11:40 AM, Roman Kennke wrote: > > > > > >> The following change implements support for the following fast-bytecodes > > >> in the Zero interpreter: > > >> > > >> fast_agetfield > > >> fast_bgetfield > > >> fast_cgetfield > > >> fast_dgetfield > > >> fast_fgetfield > > >> fast_igetfield > > >> fast_lgetfield > > >> fast_sgetfield > > >> fast_aputfield > > >> fast_bputfield > > >> fast_cputfield > > >> fast_dputfield > > >> fast_fputfield > > >> fast_iputfield > > >> fast_lputfield > > >> fast_sputfield > > >> fast_aload_0 > > >> fast_iaccess_0 > > >> fast_aaccess_0 > > >> fast_faccess_0 > > >> fast_iload > > >> fast_iload2 > > >> fast_icaload > > >> fast_invokevfinal > > >> > > >> All together this leads to a speedup of the interpreter of about 25%. > > >> > > >> Some notes: > > >> - I extracted the JVMTI related blocks into a macro to avoid repetition. > > >> - The field get/put opcodes are only rewritten for non-volatile > > >> non-static field access, this makes the fast one really fast (no > > >> additional branches needed), and static/volatile field accesses seem > > >> rare enough anyway. > > >> > > >> http://cr.openjdk.java.net/~rkennke/zero-fast-opcodes/webrev.00/ > > >> > > >> > > >> Opinions? Can this be included in hotspot? And Can I have a bug-ID? > > >> > > >> Best regards, > > >> Roman > > >> > > >> > > > > > From serguei.spitsyn at oracle.com Mon Feb 18 12:45:53 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 18 Feb 2013 12:45:53 -0800 Subject: Review request for JDK-8007153: update method parameters data in redefineClasses In-Reply-To: <512242C0.7090900@oracle.com> References: <512242C0.7090900@oracle.com> Message-ID: <51229301.4060506@oracle.com> Looks good. Do we have a jtreg test covering this? Thanks, Serguei On 2/18/13 7:03 AM, Eric McCorkle wrote: > Hello, > > Please review this simple patch which updates hotspot to correctly > manage method parameter data when redefineClasses is called. > > The webrev is here: > http://cr.openjdk.java.net/~emc/8007153/ From eric.mccorkle at oracle.com Mon Feb 18 13:52:20 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 18 Feb 2013 16:52:20 -0500 Subject: Review request for JDK-8007153: update method parameters data in redefineClasses In-Reply-To: <51229301.4060506@oracle.com> References: <512242C0.7090900@oracle.com> <51229301.4060506@oracle.com> Message-ID: <5122A294.7090300@oracle.com> The tests for this are in JDK. They will have to go in separately, and after propagation from hsx to tl. Note that there will be an effort to see what other metadata changes might be similarly affected. On 02/18/13 15:45, serguei.spitsyn at oracle.com wrote: > Looks good. > Do we have a jtreg test covering this? > > Thanks, > Serguei > > > On 2/18/13 7:03 AM, Eric McCorkle wrote: >> Hello, >> >> Please review this simple patch which updates hotspot to correctly >> manage method parameter data when redefineClasses is called. >> >> The webrev is here: >> http://cr.openjdk.java.net/~emc/8007153/ > From coleen.phillimore at oracle.com Mon Feb 18 14:02:29 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 18 Feb 2013 17:02:29 -0500 Subject: Review request for JDK-8007153: update method parameters data in redefineClasses In-Reply-To: <5122A294.7090300@oracle.com> References: <512242C0.7090900@oracle.com> <51229301.4060506@oracle.com> <5122A294.7090300@oracle.com> Message-ID: <5122A4F5.4030005@oracle.com> Eric, This looks good then. Thanks in advance for adding the tests. Coleen On 02/18/2013 04:52 PM, Eric McCorkle wrote: > The tests for this are in JDK. They will have to go in separately, and > after propagation from hsx to tl. > > Note that there will be an effort to see what other metadata changes > might be similarly affected. > > On 02/18/13 15:45, serguei.spitsyn at oracle.com wrote: >> Looks good. >> Do we have a jtreg test covering this? >> >> Thanks, >> Serguei >> >> >> On 2/18/13 7:03 AM, Eric McCorkle wrote: >>> Hello, >>> >>> Please review this simple patch which updates hotspot to correctly >>> manage method parameter data when redefineClasses is called. >>> >>> The webrev is here: >>> http://cr.openjdk.java.net/~emc/8007153/ From serguei.spitsyn at oracle.com Mon Feb 18 14:13:59 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 18 Feb 2013 14:13:59 -0800 Subject: Review request for JDK-8007153: update method parameters data in redefineClasses In-Reply-To: <5122A294.7090300@oracle.com> References: <512242C0.7090900@oracle.com> <51229301.4060506@oracle.com> <5122A294.7090300@oracle.com> Message-ID: <5122A7A7.2040502@oracle.com> We normally develop a new jtreg test so that the fix can be tested before the hsx integration. (It is if the issue does not have a test coverage yet.) Then the test is integrated into the tl/jdk after the hsx fix gets promoted. Just wanted to make sure we provide a unit test coverage with the fix. Thanks, Serguei On 2/18/13 1:52 PM, Eric McCorkle wrote: > The tests for this are in JDK. They will have to go in separately, and > after propagation from hsx to tl. > > Note that there will be an effort to see what other metadata changes > might be similarly affected. > > On 02/18/13 15:45, serguei.spitsyn at oracle.com wrote: >> Looks good. >> Do we have a jtreg test covering this? >> >> Thanks, >> Serguei >> >> >> On 2/18/13 7:03 AM, Eric McCorkle wrote: >>> Hello, >>> >>> Please review this simple patch which updates hotspot to correctly >>> manage method parameter data when redefineClasses is called. >>> >>> The webrev is here: >>> http://cr.openjdk.java.net/~emc/8007153/ From serguei.spitsyn at oracle.com Mon Feb 18 14:17:03 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 18 Feb 2013 14:17:03 -0800 Subject: Review request for JDK-8007153: update method parameters data in redefineClasses In-Reply-To: <5122A7A7.2040502@oracle.com> References: <512242C0.7090900@oracle.com> <51229301.4060506@oracle.com> <5122A294.7090300@oracle.com> <5122A7A7.2040502@oracle.com> Message-ID: <5122A85F.7060103@oracle.com> Forgot to say that it is nice that it is under control. :) Thanks, Serguei On 2/18/13 2:13 PM, serguei.spitsyn at oracle.com wrote: > We normally develop a new jtreg test so that the fix can be tested > before the hsx integration. > (It is if the issue does not have a test coverage yet.) > Then the test is integrated into the tl/jdk after the hsx fix gets > promoted. > Just wanted to make sure we provide a unit test coverage with the fix. > > Thanks, > Serguei > > On 2/18/13 1:52 PM, Eric McCorkle wrote: >> The tests for this are in JDK. They will have to go in separately, and >> after propagation from hsx to tl. >> >> Note that there will be an effort to see what other metadata changes >> might be similarly affected. >> >> On 02/18/13 15:45, serguei.spitsyn at oracle.com wrote: >>> Looks good. >>> Do we have a jtreg test covering this? >>> >>> Thanks, >>> Serguei >>> >>> >>> On 2/18/13 7:03 AM, Eric McCorkle wrote: >>>> Hello, >>>> >>>> Please review this simple patch which updates hotspot to correctly >>>> manage method parameter data when redefineClasses is called. >>>> >>>> The webrev is here: >>>> http://cr.openjdk.java.net/~emc/8007153/ > From mikael.vidstedt at oracle.com Mon Feb 18 15:14:11 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 18 Feb 2013 15:14:11 -0800 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <511DB3E0.6030606@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> <50A24E00.3070200@oracle.com> <50A25720.1040405@oracle.com> <50A59010.5040001@oracle.com> <510C18F6.6010305@oracle.com> <511DAB26.2010808@oracle.com> <511DB3E0.6030606@oracle.com> Message-ID: <5122B5C3.1010908@oracle.com> A really good control question, thanks a lot for asking! As a matter of fact these changes are basically just doing what the compiler already does for us, so it's more about cleaning up the source code than reducing the size of the binary. So in theory these changes should have no impact on the binary size at all, but it actually turns out they do. Very specifically, the fact that I moved the same_page() function from being duplicated in the three os_.cpp files to having it be in globalDefinitions.cpp makes the binary grow a few bytes (54 bytes to be specific). The reason is a bit subtle: The same_page() function is (was) static in the respective os_*.cpp files. They are only ever used when the Verbose flag is true, and furthermore the Verbose option is a develop only flag, which means it is hardcoded to false in product. The compiler knows that's the case and eliminates the same_page() function completely. Since I moved it to globalDefinitions.cpp there's no way easy for the compiler to know that it is not being used, so it will actually keep the function. Unless there are strong opinions I'm not going to do anything about this. However, this made me question my earlier experiments with using the const bool = false construct in constantPool.cpp, because after all that is the exact same pattern. And it turns out that I must have done something wrong when I was performing the experiments, because when I do the same thing again now it turns out the compiler actually *does* deadcode eliminate the debug-only functions. So I take everything back and conclude that const bool = false is indeed a great way to make sure the debug code does not rot over time, and that the product binary will *not* contain the dead functions. Sorry for any confusion this may have caused. With all that in mind, here's another version of the webrev: http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev04/webrev/ The only change since the earlier webrev is in constantPool.cpp, where I updated the code to use the const bool = false idiom. I would appreciate a review or two of that piece specifically. Thanks, Mikael On 2/14/2013 8:04 PM, Azeem Jiva wrote: > Did you measure how much the libjvm.so shrank with your changes? > > On 2/14/2013 7:27 PM, Coleen Phillmore wrote: >> >> Looks good Mikael! I like these sorts of changes. >> Coleen >> >> On 2/1/2013 11:35 AM, Mikael Vidstedt wrote: >>> >>> All, >>> >>> I finally found some time to update the webrev: >>> >>> http://cr.openjdk.java.net/~mikael/8003310/webrev.03/webrev/ >>> >>> Not much has changes since the first webrev. I played around with >>> turning the #ifdef in constantPool.cpp into a const bool = false, >>> but one of the downsides I noticed with that is that the code will >>> still be compiled into product and especially for this type of >>> function with a relatively large number of constant strings in it it >>> unnecessarily adds to the footprint. This does not invalidate the >>> const bool = false idiom, but there may be cases where it is >>> beneficial to use alternatives to it. >>> >>> Cheers, >>> Mikael >>> >>> On 11/15/2012 5:00 PM, Mikael Vidstedt wrote: >>>> On 2012-11-13 06:20, Coleen Phillimore wrote: >>>>> On 11/13/2012 8:41 AM, Coleen Phillimore wrote: >>>>>> >>>>>> Hi Mikael, This is good! I have the same comments as David. >>>>>> >>>>>> For constantPool.cpp can you add #undef DBG after that code. >>>>>> >>>>>> Maybe there should be a new convention for DEBUG_>>>>> caps> for unused code that people want to leave around for >>>>>> debugging. I don't recommend we add a lot of code like this, >>>>>> but having such an ifdef would differentiate code that was just >>>>>> left in unintentionally from code that we want to be left in >>>>>> (occasionally). >>>>> >>>>> Actually, I want to revise this. We had this discussion about >>>>> this recently rwt metaspace debugging and favored a const static >>>>> variable = false; under #ifdef DEBUG or ASSERT and the debugging >>>>> code under DEBUG/ASSERT so that it doesn't bit rot. This is for >>>>> the code left in intentionally. Which makes me wonder why >>>>> print_cpool_bytes() is there under DEBUG_CPOOL claiming to be >>>>> "temporary" when there is another printing function in that file >>>>> already. >>>> >>>> The reason why I moved it under DBG was because it is only ever >>>> called wrapped with a DBG(). I can play around with making it a >>>> const static = false as you outlined. >>>> >>>> The other print functions in constantPool.cpp are implementations >>>> of the virtual functions inherited from Metadata, so they are not >>>> quite as temporary as print_cpool_bytes, if that makes sense. >>>> >>>> Cheers, >>>> Mikael >>>> >>>>> >>>>> Coleen >>>>> >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> On 11/13/2012 12:47 AM, David Holmes wrote: >>>>>>> Hi Mikael, >>>>>>> >>>>>>> A couple of general observations as really the "owners" of each >>>>>>> file needs to assess the changes: >>>>>>> >>>>>>> - sometimes functions exist for debugging/tracing and calls will >>>>>>> be added to the code by engineers as they debug. For example >>>>>>> MBFence in synchronizer.cpp allows you to add fences into >>>>>>> expressions. >>>>>>> >>>>>>> - why was the "static" removed from a number functions. They now >>>>>>> have global visibility rather than being restricted to their files? >>>>>>> >>>>>>> >>>>>>> In globaleDefinitions.cpp: >>>>>>> >>>>>>> + void GlobalDefinitions::test_globals() { >>>>>>> + intptr_t page_size = 4096; >>>>>>> >>>>>>> Page size may not be 4K - will the test still be valid? >>>>>>> >>>>>>> >>>>>>> The comments describing clamp_address_in_page don't need to be >>>>>>> on both the declaration and definition. >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> ------ >>>>>>> >>>>>>> On 13/11/2012 1:59 PM, Mikael Vidstedt wrote: >>>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> Please review the below change. The change adds the -Wunused >>>>>>>> flag when >>>>>>>> compiling with GCC and removes a number of unused >>>>>>>> functions/dead code. >>>>>>>> >>>>>>>> In the process I found one function (same_page) which was >>>>>>>> duplicated in >>>>>>>> four different places. I merged it to a single function, >>>>>>>> renamed it to >>>>>>>> clamp_address_in_page, added some comments and refactored it to be >>>>>>>> slightly easier to understand. I also added unit tests for it. >>>>>>>> Feedback >>>>>>>> appreciated (especially on the name). >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~mikael/8003310/webrev.00/ >>>>>>>> >>>>>>>> Passes JPRT and the built-in unit tests >>>>>>>> (-XX:+ExecuteInternalVMTests). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Mikael >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From vladimir.kozlov at oracle.com Mon Feb 18 15:45:11 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Feb 2013 15:45:11 -0800 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <5122B5C3.1010908@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> <50A24E00.3070200@oracle.com> <50A25720.1040405@oracle.com> <50A59010.5040001@oracle.com> <510C18F6.6010305@oracle.com> <511DAB26.2010808@oracle.com> <511DB3E0.6030606@oracle.com> <5122B5C3.1010908@oracle.com> Message-ID: <5122BD07.4050708@oracle.com> Use PRODUCT_RETURN[0]: + address clamp_address_in_page(address addr, address page_address) PRODUCT_RETURN0; and #ifndef PRODUCT + static address clamp_address_in_page(address addr, address page_address, intptr_t page_size) { Vladimir On 2/18/13 3:14 PM, Mikael Vidstedt wrote: > > A really good control question, thanks a lot for asking! > > As a matter of fact these changes are basically just doing what the > compiler already does for us, so it's more about cleaning up the source > code than reducing the size of the binary. So in theory these changes > should have no impact on the binary size at all, but it actually turns > out they do. Very specifically, the fact that I moved the same_page() > function from being duplicated in the three os_.cpp files to having > it be in globalDefinitions.cpp makes the binary grow a few bytes (54 > bytes to be specific). The reason is a bit subtle: > > The same_page() function is (was) static in the respective os_*.cpp > files. They are only ever used when the Verbose flag is true, and > furthermore the Verbose option is a develop only flag, which means it is > hardcoded to false in product. The compiler knows that's the case and > eliminates the same_page() function completely. > > Since I moved it to globalDefinitions.cpp there's no way easy for the > compiler to know that it is not being used, so it will actually keep the > function. > > Unless there are strong opinions I'm not going to do anything about this. > > However, this made me question my earlier experiments with using the > const bool = false construct in constantPool.cpp, because after all that > is the exact same pattern. And it turns out that I must have done > something wrong when I was performing the experiments, because when I do > the same thing again now it turns out the compiler actually *does* > deadcode eliminate the debug-only functions. So I take everything back > and conclude that const bool = false is indeed a great way to make sure > the debug code does not rot over time, and that the product binary will > *not* contain the dead functions. Sorry for any confusion this may have > caused. > > With all that in mind, here's another version of the webrev: > > http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev04/webrev/ > > The only change since the earlier webrev is in constantPool.cpp, where I > updated the code to use the const bool = false idiom. > > I would appreciate a review or two of that piece specifically. > > Thanks, > Mikael > > On 2/14/2013 8:04 PM, Azeem Jiva wrote: >> Did you measure how much the libjvm.so shrank with your changes? >> >> On 2/14/2013 7:27 PM, Coleen Phillmore wrote: >>> >>> Looks good Mikael! I like these sorts of changes. >>> Coleen >>> >>> On 2/1/2013 11:35 AM, Mikael Vidstedt wrote: >>>> >>>> All, >>>> >>>> I finally found some time to update the webrev: >>>> >>>> http://cr.openjdk.java.net/~mikael/8003310/webrev.03/webrev/ >>>> >>>> Not much has changes since the first webrev. I played around with >>>> turning the #ifdef in constantPool.cpp into a const bool = false, >>>> but one of the downsides I noticed with that is that the code will >>>> still be compiled into product and especially for this type of >>>> function with a relatively large number of constant strings in it it >>>> unnecessarily adds to the footprint. This does not invalidate the >>>> const bool = false idiom, but there may be cases where it is >>>> beneficial to use alternatives to it. >>>> >>>> Cheers, >>>> Mikael >>>> >>>> On 11/15/2012 5:00 PM, Mikael Vidstedt wrote: >>>>> On 2012-11-13 06:20, Coleen Phillimore wrote: >>>>>> On 11/13/2012 8:41 AM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Hi Mikael, This is good! I have the same comments as David. >>>>>>> >>>>>>> For constantPool.cpp can you add #undef DBG after that code. >>>>>>> >>>>>>> Maybe there should be a new convention for DEBUG_>>>>>> caps> for unused code that people want to leave around for >>>>>>> debugging. I don't recommend we add a lot of code like this, >>>>>>> but having such an ifdef would differentiate code that was just >>>>>>> left in unintentionally from code that we want to be left in >>>>>>> (occasionally). >>>>>> >>>>>> Actually, I want to revise this. We had this discussion about >>>>>> this recently rwt metaspace debugging and favored a const static >>>>>> variable = false; under #ifdef DEBUG or ASSERT and the debugging >>>>>> code under DEBUG/ASSERT so that it doesn't bit rot. This is for >>>>>> the code left in intentionally. Which makes me wonder why >>>>>> print_cpool_bytes() is there under DEBUG_CPOOL claiming to be >>>>>> "temporary" when there is another printing function in that file >>>>>> already. >>>>> >>>>> The reason why I moved it under DBG was because it is only ever >>>>> called wrapped with a DBG(). I can play around with making it a >>>>> const static = false as you outlined. >>>>> >>>>> The other print functions in constantPool.cpp are implementations >>>>> of the virtual functions inherited from Metadata, so they are not >>>>> quite as temporary as print_cpool_bytes, if that makes sense. >>>>> >>>>> Cheers, >>>>> Mikael >>>>> >>>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 11/13/2012 12:47 AM, David Holmes wrote: >>>>>>>> Hi Mikael, >>>>>>>> >>>>>>>> A couple of general observations as really the "owners" of each >>>>>>>> file needs to assess the changes: >>>>>>>> >>>>>>>> - sometimes functions exist for debugging/tracing and calls will >>>>>>>> be added to the code by engineers as they debug. For example >>>>>>>> MBFence in synchronizer.cpp allows you to add fences into >>>>>>>> expressions. >>>>>>>> >>>>>>>> - why was the "static" removed from a number functions. They now >>>>>>>> have global visibility rather than being restricted to their files? >>>>>>>> >>>>>>>> >>>>>>>> In globaleDefinitions.cpp: >>>>>>>> >>>>>>>> + void GlobalDefinitions::test_globals() { >>>>>>>> + intptr_t page_size = 4096; >>>>>>>> >>>>>>>> Page size may not be 4K - will the test still be valid? >>>>>>>> >>>>>>>> >>>>>>>> The comments describing clamp_address_in_page don't need to be >>>>>>>> on both the declaration and definition. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> ------ >>>>>>>> >>>>>>>> On 13/11/2012 1:59 PM, Mikael Vidstedt wrote: >>>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> Please review the below change. The change adds the -Wunused >>>>>>>>> flag when >>>>>>>>> compiling with GCC and removes a number of unused >>>>>>>>> functions/dead code. >>>>>>>>> >>>>>>>>> In the process I found one function (same_page) which was >>>>>>>>> duplicated in >>>>>>>>> four different places. I merged it to a single function, >>>>>>>>> renamed it to >>>>>>>>> clamp_address_in_page, added some comments and refactored it to be >>>>>>>>> slightly easier to understand. I also added unit tests for it. >>>>>>>>> Feedback >>>>>>>>> appreciated (especially on the name). >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~mikael/8003310/webrev.00/ >>>>>>>>> >>>>>>>>> Passes JPRT and the built-in unit tests >>>>>>>>> (-XX:+ExecuteInternalVMTests). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Mikael >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From mikael.vidstedt at oracle.com Mon Feb 18 16:05:33 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 18 Feb 2013 16:05:33 -0800 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <5122BD07.4050708@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> <50A24E00.3070200@oracle.com> <50A25720.1040405@oracle.com> <50A59010.5040001@oracle.com> <510C18F6.6010305@oracle.com> <511DAB26.2010808@oracle.com> <511DB3E0.6030606@oracle.com> <5122B5C3.1010908@oracle.com> <5122BD07.4050708@oracle.com> Message-ID: <5122C1CD.8070201@oracle.com> If we really believe this is worth addressing (and I'm not sure it is) then I'd much rather have the function be defined in the globalDefinitions.hpp file, potentially as a static method in the GlobalDefinitions class which is currently only for unit testing. That way it would be included in the respective .cpp compile units and completely deadcode eliminated in the same way it is today without having to change its contract. Cheers, Mikael On 2/18/2013 3:45 PM, Vladimir Kozlov wrote: > Use PRODUCT_RETURN[0]: > > + address clamp_address_in_page(address addr, address page_address) > PRODUCT_RETURN0; > > and > > #ifndef PRODUCT > + static address clamp_address_in_page(address addr, address > page_address, intptr_t page_size) { > > Vladimir > > On 2/18/13 3:14 PM, Mikael Vidstedt wrote: >> >> A really good control question, thanks a lot for asking! >> >> As a matter of fact these changes are basically just doing what the >> compiler already does for us, so it's more about cleaning up the source >> code than reducing the size of the binary. So in theory these changes >> should have no impact on the binary size at all, but it actually turns >> out they do. Very specifically, the fact that I moved the same_page() >> function from being duplicated in the three os_.cpp files to having >> it be in globalDefinitions.cpp makes the binary grow a few bytes (54 >> bytes to be specific). The reason is a bit subtle: >> >> The same_page() function is (was) static in the respective os_*.cpp >> files. They are only ever used when the Verbose flag is true, and >> furthermore the Verbose option is a develop only flag, which means it is >> hardcoded to false in product. The compiler knows that's the case and >> eliminates the same_page() function completely. >> >> Since I moved it to globalDefinitions.cpp there's no way easy for the >> compiler to know that it is not being used, so it will actually keep the >> function. >> >> Unless there are strong opinions I'm not going to do anything about >> this. >> >> However, this made me question my earlier experiments with using the >> const bool = false construct in constantPool.cpp, because after all that >> is the exact same pattern. And it turns out that I must have done >> something wrong when I was performing the experiments, because when I do >> the same thing again now it turns out the compiler actually *does* >> deadcode eliminate the debug-only functions. So I take everything back >> and conclude that const bool = false is indeed a great way to make sure >> the debug code does not rot over time, and that the product binary will >> *not* contain the dead functions. Sorry for any confusion this may have >> caused. >> >> With all that in mind, here's another version of the webrev: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev04/webrev/ >> >> The only change since the earlier webrev is in constantPool.cpp, where I >> updated the code to use the const bool = false idiom. >> >> I would appreciate a review or two of that piece specifically. >> >> Thanks, >> Mikael >> >> On 2/14/2013 8:04 PM, Azeem Jiva wrote: >>> Did you measure how much the libjvm.so shrank with your changes? >>> >>> On 2/14/2013 7:27 PM, Coleen Phillmore wrote: >>>> >>>> Looks good Mikael! I like these sorts of changes. >>>> Coleen >>>> >>>> On 2/1/2013 11:35 AM, Mikael Vidstedt wrote: >>>>> >>>>> All, >>>>> >>>>> I finally found some time to update the webrev: >>>>> >>>>> http://cr.openjdk.java.net/~mikael/8003310/webrev.03/webrev/ >>>>> >>>>> Not much has changes since the first webrev. I played around with >>>>> turning the #ifdef in constantPool.cpp into a const bool = false, >>>>> but one of the downsides I noticed with that is that the code will >>>>> still be compiled into product and especially for this type of >>>>> function with a relatively large number of constant strings in it it >>>>> unnecessarily adds to the footprint. This does not invalidate the >>>>> const bool = false idiom, but there may be cases where it is >>>>> beneficial to use alternatives to it. >>>>> >>>>> Cheers, >>>>> Mikael >>>>> >>>>> On 11/15/2012 5:00 PM, Mikael Vidstedt wrote: >>>>>> On 2012-11-13 06:20, Coleen Phillimore wrote: >>>>>>> On 11/13/2012 8:41 AM, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> Hi Mikael, This is good! I have the same comments as David. >>>>>>>> >>>>>>>> For constantPool.cpp can you add #undef DBG after that code. >>>>>>>> >>>>>>>> Maybe there should be a new convention for DEBUG_>>>>>>> caps> for unused code that people want to leave around for >>>>>>>> debugging. I don't recommend we add a lot of code like this, >>>>>>>> but having such an ifdef would differentiate code that was just >>>>>>>> left in unintentionally from code that we want to be left in >>>>>>>> (occasionally). >>>>>>> >>>>>>> Actually, I want to revise this. We had this discussion about >>>>>>> this recently rwt metaspace debugging and favored a const static >>>>>>> variable = false; under #ifdef DEBUG or ASSERT and the debugging >>>>>>> code under DEBUG/ASSERT so that it doesn't bit rot. This is for >>>>>>> the code left in intentionally. Which makes me wonder why >>>>>>> print_cpool_bytes() is there under DEBUG_CPOOL claiming to be >>>>>>> "temporary" when there is another printing function in that file >>>>>>> already. >>>>>> >>>>>> The reason why I moved it under DBG was because it is only ever >>>>>> called wrapped with a DBG(). I can play around with making it a >>>>>> const static = false as you outlined. >>>>>> >>>>>> The other print functions in constantPool.cpp are implementations >>>>>> of the virtual functions inherited from Metadata, so they are not >>>>>> quite as temporary as print_cpool_bytes, if that makes sense. >>>>>> >>>>>> Cheers, >>>>>> Mikael >>>>>> >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 11/13/2012 12:47 AM, David Holmes wrote: >>>>>>>>> Hi Mikael, >>>>>>>>> >>>>>>>>> A couple of general observations as really the "owners" of each >>>>>>>>> file needs to assess the changes: >>>>>>>>> >>>>>>>>> - sometimes functions exist for debugging/tracing and calls will >>>>>>>>> be added to the code by engineers as they debug. For example >>>>>>>>> MBFence in synchronizer.cpp allows you to add fences into >>>>>>>>> expressions. >>>>>>>>> >>>>>>>>> - why was the "static" removed from a number functions. They now >>>>>>>>> have global visibility rather than being restricted to their >>>>>>>>> files? >>>>>>>>> >>>>>>>>> >>>>>>>>> In globaleDefinitions.cpp: >>>>>>>>> >>>>>>>>> + void GlobalDefinitions::test_globals() { >>>>>>>>> + intptr_t page_size = 4096; >>>>>>>>> >>>>>>>>> Page size may not be 4K - will the test still be valid? >>>>>>>>> >>>>>>>>> >>>>>>>>> The comments describing clamp_address_in_page don't need to be >>>>>>>>> on both the declaration and definition. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> David >>>>>>>>> ------ >>>>>>>>> >>>>>>>>> On 13/11/2012 1:59 PM, Mikael Vidstedt wrote: >>>>>>>>>> >>>>>>>>>> All, >>>>>>>>>> >>>>>>>>>> Please review the below change. The change adds the -Wunused >>>>>>>>>> flag when >>>>>>>>>> compiling with GCC and removes a number of unused >>>>>>>>>> functions/dead code. >>>>>>>>>> >>>>>>>>>> In the process I found one function (same_page) which was >>>>>>>>>> duplicated in >>>>>>>>>> four different places. I merged it to a single function, >>>>>>>>>> renamed it to >>>>>>>>>> clamp_address_in_page, added some comments and refactored it >>>>>>>>>> to be >>>>>>>>>> slightly easier to understand. I also added unit tests for it. >>>>>>>>>> Feedback >>>>>>>>>> appreciated (especially on the name). >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~mikael/8003310/webrev.00/ >>>>>>>>>> >>>>>>>>>> Passes JPRT and the built-in unit tests >>>>>>>>>> (-XX:+ExecuteInternalVMTests). >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Mikael >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> From david.holmes at oracle.com Mon Feb 18 17:54:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Feb 2013 11:54:21 +1000 Subject: JEP 161 SE Compact Profiles has pushed to jdk8/build forest Message-ID: <5122DB4D.4020302@oracle.com> The implementation support for the Reference Implementation of the SE Compact Profiles described by: http://openjdk.java.net/jeps/161 has now been pushed to the jdk8/build forest ready for integration with jdk8/jdk8 in time for b78. This reference implementation is for the Linux platform only. To build the compact profiles JREs specify the "profiles" target to make: make profiles or to build the full JDK/JRE and profile images use: make images profiles Profiles are not built by default ("make all"). The Profile JRE's are created in the images directory along side the j2re-image and j2sdk-image, and are named j2re-compactN-image, for N=1,2,3 One minor issue we just became aware of (bug 8008424), don't have the variable PROFILE set in your environment when building the "images" target. Workaround is to either unset the env variable before calling make, or pass PROFILE="" as a make argument when building. This will be fixed ASAP. David Holmes ------------- From vladimir.kozlov at oracle.com Mon Feb 18 18:28:07 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Feb 2013 18:28:07 -0800 Subject: CFV: New HSX Committer: David Chase In-Reply-To: <5111D374.2090101@oracle.com> References: <5111D374.2090101@oracle.com> Message-ID: <5122E337.5030203@oracle.com> I hereby nominate David Chase (OpenJDK user name: drchase) to HSX Committer. David is a member of the Hotspot Compiler group. He is working on Sumatra Project and new java types. He contributed 8 changesets to HSX project and he is qualified to be committer [1]: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=david.r.chase%40oracle.com http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=drchase The last changeset is not shown in the query yet: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a2bc322ca273 Votes are due by Mar 4, 2013. Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Vladimir Kozlov [1] http://openjdk.java.net/projects/#project-committer [2] http://openjdk.java.net/census#hsx [3] http://openjdk.java.net/projects#committer-vote From vladimir.kozlov at oracle.com Mon Feb 18 18:40:08 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Feb 2013 18:40:08 -0800 Subject: CFV: New HSX Committer: David Chase In-Reply-To: <5122E337.5030203@oracle.com> References: <5111D374.2090101@oracle.com> <5122E337.5030203@oracle.com> Message-ID: <5122E608.8050102@oracle.com> Vote: yes On 2/18/13 6:28 PM, Vladimir Kozlov wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX > Committer. > > David is a member of the Hotspot Compiler group. He is working on > Sumatra Project and new java types. He contributed 8 changesets to HSX > project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=david.r.chase%40oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=drchase > > The last changeset is not shown in the query yet: > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a2bc322ca273 > > Votes are due by Mar 4, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > > > From john.r.rose at oracle.com Mon Feb 18 19:10:08 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 18 Feb 2013 19:10:08 -0800 Subject: CFV: New HSX Committer: David Chase In-Reply-To: <5122E337.5030203@oracle.com> References: <5111D374.2090101@oracle.com> <5122E337.5030203@oracle.com> Message-ID: Vote: yes From coleen.phillimore at oracle.com Mon Feb 18 19:45:53 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 18 Feb 2013 22:45:53 -0500 Subject: CFV: New HSX Committer: David Chase In-Reply-To: <5122E337.5030203@oracle.com> References: <5111D374.2090101@oracle.com> <5122E337.5030203@oracle.com> Message-ID: <5122F571.5040705@oracle.com> Vote: yes On 2/18/2013 9:28 PM, Vladimir Kozlov wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX > Committer. > > David is a member of the Hotspot Compiler group. He is working on > Sumatra Project and new java types. He contributed 8 changesets to HSX > project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=david.r.chase%40oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=drchase > > The last changeset is not shown in the query yet: > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a2bc322ca273 > > Votes are due by Mar 4, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > > > From david.holmes at oracle.com Mon Feb 18 20:43:58 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Feb 2013 14:43:58 +1000 Subject: CFV: New HSX Committer: David Chase In-Reply-To: <5122E337.5030203@oracle.com> References: <5111D374.2090101@oracle.com> <5122E337.5030203@oracle.com> Message-ID: <5123030E.3020902@oracle.com> Vote: VETO Without impugning David's abilities or the scope of his future contributions, the contributions listed are for the most part quite trivial. The OpenJDK guidelines [1] state: "As a rough guide, for any given Project, a Contributor should make at least eight significant contributions before being nominated." I do not feel that the contributions referenced meet the criteria of being "significant", and that therefore this request for Committer status is premature. David ----- [1] http://openjdk.java.net/projects/ On 19/02/2013 12:28 PM, Vladimir Kozlov wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX > Committer. > > David is a member of the Hotspot Compiler group. He is working on > Sumatra Project and new java types. He contributed 8 changesets to HSX > project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=david.r.chase%40oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=drchase > > The last changeset is not shown in the query yet: > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a2bc322ca273 > > Votes are due by Mar 4, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > > > From jesper.wilhelmsson at oracle.com Mon Feb 18 22:25:43 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 19 Feb 2013 07:25:43 +0100 Subject: RFR (S): 8008314 - Unimplemented() Atomic::load breaks the applications Message-ID: <51231AE7.9070206@oracle.com> Hi, Please review the following change: Webrev: http://cr.openjdk.java.net/~jwilhelm/8008314/ Bug: https://jbs.oracle.com/bugs/browse/JDK-8008314 The use of atomic::add(jlong,jlong*) breaks everything on ARM since it uses atomic::load(jlong) which isn't implemented. The add was used to update a counter in rotating log file handling, but it turns out that the counter that was updated doesn't need to be a jlong. The counter is used to indicate that it is time to do a log file rotation and by adding a saftey catch for overflow, we can use an uintx for the counter. In practice this means that the upper "limit" for the log file size becomes UINX_MAX-1 (used to be UINT_MAX) since I change from < to <= in the comparison to the limit, but since this is not a hard limit the difference will only be noticeable when someone has written UINT_MAX characters to the log file and the next write will end up in the next log file part instead of in the same (which one could argue is a more correct behavior). Sine I changed all places where the counter was used I also fixed a typo in its name. Thanks, /Jesper From david.holmes at oracle.com Mon Feb 18 23:08:43 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Feb 2013 17:08:43 +1000 Subject: RFR (S): 8008314 - Unimplemented() Atomic::load breaks the applications In-Reply-To: <51231AE7.9070206@oracle.com> References: <51231AE7.9070206@oracle.com> Message-ID: <512324FB.7090106@oracle.com> Hi Jesper, The jlong version of Atomic::add not only relies on a jlong version of Atomic::load but also a jlong version of Atomic::cmpxchg - facilities that are only conditionally available on 32-bit platforms. Further, the jlong version of add implements the wrong semantics by returning the previous value rather than the updated value as it should (as per atomic.hpp). Given that the jlong Atomic::add will not be used once this is pushed (assuming Bengt pushes 8008382 first), could I ask that you also delete it from atomic.cpp/hpp as part of this change. That way no one will be tempted to use it again. I'd also suggest adding a comment in atomic.hpp: // Atomic operations on jlong types are not available on all 32-bit // platforms. If atomic ops on jlongs are defined here they must only // be used from code that verifies they are available at runtime and // can provide an alternative action if not - see supports_cx8() for // a means to test availability There remain Atomic::store(jlong) and Atomic::load(jlong) operations that violate this rule but the code involved is not presently used on platforms that don't support them. This obviously needs fixing. Thanks, David On 19/02/2013 4:25 PM, Jesper Wilhelmsson wrote: > Hi, > > Please review the following change: > > Webrev: http://cr.openjdk.java.net/~jwilhelm/8008314/ > > Bug: https://jbs.oracle.com/bugs/browse/JDK-8008314 > > > The use of atomic::add(jlong,jlong*) breaks everything on ARM since it > uses atomic::load(jlong) which isn't implemented. > > The add was used to update a counter in rotating log file handling, but > it turns out that the counter that was updated doesn't need to be a jlong. > > The counter is used to indicate that it is time to do a log file > rotation and by adding a saftey catch for overflow, we can use an uintx > for the counter. > > In practice this means that the upper "limit" for the log file size > becomes UINX_MAX-1 (used to be UINT_MAX) since I change from < to <= in > the comparison to the limit, but since this is not a hard limit the > difference will only be noticeable when someone has written UINT_MAX > characters to the log file and the next write will end up in the next > log file part instead of in the same (which one could argue is a more > correct behavior). > > Sine I changed all places where the counter was used I also fixed a typo > in its name. > > Thanks, > /Jesper From bengt.rutisson at oracle.com Tue Feb 19 00:08:27 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 19 Feb 2013 09:08:27 +0100 Subject: RFR (S): 8008314 - Unimplemented() Atomic::load breaks the applications In-Reply-To: <51231AE7.9070206@oracle.com> References: <51231AE7.9070206@oracle.com> Message-ID: <512332FB.7020600@oracle.com> Hi Jesper, Thanks for fixing this! I don't feel very comfortable with this code, so don't consider this a full review. Just a couple of comments: It seems to make sense to use uintx for _bytes_written since the flag to control the file size, GCLogFileSize, is uintx. But since the atomics you use are handling jint I think it looks a bit suspicious. jint is always 32 bits and uintx can be 32 or 64 bit. So, what happens here if _bytes_written is 64 bit? 457 Atomic::add((jint)count, (jint*)&_bytes_written); If _bytes_written is 0x00000000FFFFFFFF and count is 1, I would guess that we get 0x0 instead of 0x0000000100000000. Also, in rotatingFileStream::rotate_log() you changed to: if (_bytes_written <= GCLogFileSize) return; instead of : if (_bytes_writen < (jlong)GCLogFileSize) return; isn't this a problem since you set _bytes_written to UINT_MAX if we wrap around? If someone sets GCLogFileSize on the command line to be UINT_MAX we will never rotate the file, right? Also, we only call rotate_log() when we start a safepoint. If we wrap around once in write() but then call it again before a safepoint happens we can probably set _bytes_written to a value that looks small enough to not have to rotate the log. It seems to me that we would need a separate flag to say that we written enough to rotate the log. Bengt On 2/19/13 7:25 AM, Jesper Wilhelmsson wrote: > Hi, > > Please review the following change: > > Webrev: http://cr.openjdk.java.net/~jwilhelm/8008314/ > > Bug: https://jbs.oracle.com/bugs/browse/JDK-8008314 > > > The use of atomic::add(jlong,jlong*) breaks everything on ARM since it > uses atomic::load(jlong) which isn't implemented. > > The add was used to update a counter in rotating log file handling, > but it turns out that the counter that was updated doesn't need to be > a jlong. > > The counter is used to indicate that it is time to do a log file > rotation and by adding a saftey catch for overflow, we can use an > uintx for the counter. > > In practice this means that the upper "limit" for the log file size > becomes UINX_MAX-1 (used to be UINT_MAX) since I change from < to <= > in the comparison to the limit, but since this is not a hard limit the > difference will only be noticeable when someone has written UINT_MAX > characters to the log file and the next write will end up in the next > log file part instead of in the same (which one could argue is a more > correct behavior). > > Sine I changed all places where the counter was used I also fixed a > typo in its name. > > Thanks, > /Jesper From roland.westrelin at oracle.com Tue Feb 19 01:15:24 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 19 Feb 2013 10:15:24 +0100 Subject: CFV: New HSX Committer: David Chase In-Reply-To: <5122E337.5030203@oracle.com> References: <5111D374.2090101@oracle.com> <5122E337.5030203@oracle.com> Message-ID: <87obfgfyvn.fsf@oracle.com> Vote: yes Roland. From vladimir.x.ivanov at oracle.com Tue Feb 19 01:23:32 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 19 Feb 2013 13:23:32 +0400 Subject: CFV: New HSX Committer: David Chase In-Reply-To: <5122E337.5030203@oracle.com> References: <5111D374.2090101@oracle.com> <5122E337.5030203@oracle.com> Message-ID: <51234494.4020705@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 2/19/13 6:28 AM, Vladimir Kozlov wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX > Committer. > > David is a member of the Hotspot Compiler group. He is working on > Sumatra Project and new java types. He contributed 8 changesets to HSX > project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=david.r.chase%40oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=drchase > > The last changeset is not shown in the query yet: > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a2bc322ca273 > > Votes are due by Mar 4, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > > > From jesper.wilhelmsson at oracle.com Tue Feb 19 02:18:10 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 19 Feb 2013 11:18:10 +0100 Subject: RFR (S): 8008314 - Unimplemented() Atomic::load breaks the applications In-Reply-To: <512332FB.7020600@oracle.com> References: <51231AE7.9070206@oracle.com> <512332FB.7020600@oracle.com> Message-ID: <51235162.9030702@oracle.com> Bengt, Thanks for catching this! I should listen to Ted's mother, nothing good happens after 2am[1]. I wasn't aware that jint was 32-bit on all platforms. Using 32-bit atomic add like this won't work, back to the drawing board. The one quick solution I can think of right now that won't be awful would be to limit GcLogFileSize to 32 bit. I'm not sure how quick a fix it will be though since it may require a CCC approval... /Jesper [1] http://en.wikipedia.org/wiki/Nothing_Good_Happens_After_2_A.M. On 19/2/13 9:08 AM, Bengt Rutisson wrote: > > Hi Jesper, > > Thanks for fixing this! I don't feel very comfortable with this code, so don't > consider this a full review. Just a couple of comments: > > It seems to make sense to use uintx for _bytes_written since the flag to control > the file size, GCLogFileSize, is uintx. But since the atomics you use are > handling jint I think it looks a bit suspicious. jint is always 32 bits and > uintx can be 32 or 64 bit. So, what happens here if _bytes_written is 64 bit? > > 457 Atomic::add((jint)count, (jint*)&_bytes_written); > > If _bytes_written is 0x00000000FFFFFFFF and count is 1, I would guess that we > get 0x0 instead of 0x0000000100000000. > > Also, in rotatingFileStream::rotate_log() you changed to: > > if (_bytes_written <= GCLogFileSize) return; > > instead of : > > if (_bytes_writen < (jlong)GCLogFileSize) return; > > isn't this a problem since you set _bytes_written to UINT_MAX if we wrap around? > If someone sets GCLogFileSize on the command line to be UINT_MAX we will never > rotate the file, right? > > Also, we only call rotate_log() when we start a safepoint. If we wrap around > once in write() but then call it again before a safepoint happens we can > probably set _bytes_written to a value that looks small enough to not have to > rotate the log. It seems to me that we would need a separate flag to say that we > written enough to rotate the log. > > Bengt > > > > On 2/19/13 7:25 AM, Jesper Wilhelmsson wrote: >> Hi, >> >> Please review the following change: >> >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8008314/ >> >> Bug: https://jbs.oracle.com/bugs/browse/JDK-8008314 >> >> >> The use of atomic::add(jlong,jlong*) breaks everything on ARM since it uses >> atomic::load(jlong) which isn't implemented. >> >> The add was used to update a counter in rotating log file handling, but it >> turns out that the counter that was updated doesn't need to be a jlong. >> >> The counter is used to indicate that it is time to do a log file rotation and >> by adding a saftey catch for overflow, we can use an uintx for the counter. >> >> In practice this means that the upper "limit" for the log file size becomes >> UINX_MAX-1 (used to be UINT_MAX) since I change from < to <= in the comparison >> to the limit, but since this is not a hard limit the difference will only be >> noticeable when someone has written UINT_MAX characters to the log file and >> the next write will end up in the next log file part instead of in the same >> (which one could argue is a more correct behavior). >> >> Sine I changed all places where the counter was used I also fixed a typo in >> its name. >> >> Thanks, >> /Jesper > From nils.loodin at oracle.com Tue Feb 19 03:09:18 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Tue, 19 Feb 2013 12:09:18 +0100 Subject: RFR: JDK-8007804: Need to be able to access Performance counter by name from JVM In-Reply-To: <5115B0B5.9030004@oracle.com> References: <51152A60.8000004@oracle.com> <5115B0B5.9030004@oracle.com> Message-ID: <51235D5E.6010103@oracle.com> On 02/09/2013 03:13 AM, David Holmes wrote: > On 9/02/2013 2:40 AM, Nils Loodin wrote: >> Please review the following very small and insignificant change: >> Basically, I need to access a performance-counter by name from within >> the JVM. > > The method name by_name seems a little odd to me. find_by_name would > seem more consistent (particularly if you consider the strange > PerfDataList::by_name method - which compares names) I think you're right. I'll rename it to find_by_name instead and send out another webrev. Nisse > > David > >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007804 >> http://cr.openjdk.java.net/~nloodin/8007804/webrev.00/ >> >> Regards, >> Nils Loodin >> >> From david.holmes at oracle.com Tue Feb 19 03:39:13 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Feb 2013 21:39:13 +1000 Subject: RFR (S): 8008314 - Unimplemented() Atomic::load breaks the applications In-Reply-To: <51235162.9030702@oracle.com> References: <51231AE7.9070206@oracle.com> <512332FB.7020600@oracle.com> <51235162.9030702@oracle.com> Message-ID: <51236461.7060101@oracle.com> I'm also indebted to Bengt for spotting that - hadn't realized the 'x' types were intptr_t typedefs. But backing up a step, this code is not obviously thread-safes, or if it is it must be by a lock at a higher level - so why do we need an atomic update of the _bytes_written value? David On 19/02/2013 8:18 PM, Jesper Wilhelmsson wrote: > Bengt, > > Thanks for catching this! I should listen to Ted's mother, nothing good > happens after 2am[1]. > > I wasn't aware that jint was 32-bit on all platforms. Using 32-bit > atomic add like this won't work, back to the drawing board. > > The one quick solution I can think of right now that won't be awful > would be to limit GcLogFileSize to 32 bit. I'm not sure how quick a fix > it will be though since it may require a CCC approval... > > /Jesper > > > [1] http://en.wikipedia.org/wiki/Nothing_Good_Happens_After_2_A.M. > > > On 19/2/13 9:08 AM, Bengt Rutisson wrote: >> >> Hi Jesper, >> >> Thanks for fixing this! I don't feel very comfortable with this code, >> so don't >> consider this a full review. Just a couple of comments: >> >> It seems to make sense to use uintx for _bytes_written since the flag >> to control >> the file size, GCLogFileSize, is uintx. But since the atomics you use are >> handling jint I think it looks a bit suspicious. jint is always 32 >> bits and >> uintx can be 32 or 64 bit. So, what happens here if _bytes_written is >> 64 bit? >> >> 457 Atomic::add((jint)count, (jint*)&_bytes_written); >> >> If _bytes_written is 0x00000000FFFFFFFF and count is 1, I would guess >> that we >> get 0x0 instead of 0x0000000100000000. >> >> Also, in rotatingFileStream::rotate_log() you changed to: >> >> if (_bytes_written <= GCLogFileSize) return; >> >> instead of : >> >> if (_bytes_writen < (jlong)GCLogFileSize) return; >> >> isn't this a problem since you set _bytes_written to UINT_MAX if we >> wrap around? >> If someone sets GCLogFileSize on the command line to be UINT_MAX we >> will never >> rotate the file, right? >> >> Also, we only call rotate_log() when we start a safepoint. If we wrap >> around >> once in write() but then call it again before a safepoint happens we can >> probably set _bytes_written to a value that looks small enough to not >> have to >> rotate the log. It seems to me that we would need a separate flag to >> say that we >> written enough to rotate the log. >> >> Bengt >> >> >> >> On 2/19/13 7:25 AM, Jesper Wilhelmsson wrote: >>> Hi, >>> >>> Please review the following change: >>> >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8008314/ >>> >>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8008314 >>> >>> >>> The use of atomic::add(jlong,jlong*) breaks everything on ARM since >>> it uses >>> atomic::load(jlong) which isn't implemented. >>> >>> The add was used to update a counter in rotating log file handling, >>> but it >>> turns out that the counter that was updated doesn't need to be a jlong. >>> >>> The counter is used to indicate that it is time to do a log file >>> rotation and >>> by adding a saftey catch for overflow, we can use an uintx for the >>> counter. >>> >>> In practice this means that the upper "limit" for the log file size >>> becomes >>> UINX_MAX-1 (used to be UINT_MAX) since I change from < to <= in the >>> comparison >>> to the limit, but since this is not a hard limit the difference will >>> only be >>> noticeable when someone has written UINT_MAX characters to the log >>> file and >>> the next write will end up in the next log file part instead of in >>> the same >>> (which one could argue is a more correct behavior). >>> >>> Sine I changed all places where the counter was used I also fixed a >>> typo in >>> its name. >>> >>> Thanks, >>> /Jesper >> From bengt.rutisson at oracle.com Tue Feb 19 04:52:25 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 19 Feb 2013 13:52:25 +0100 Subject: RFR (S): 8008314 - Unimplemented() Atomic::load breaks the applications In-Reply-To: <51236461.7060101@oracle.com> References: <51231AE7.9070206@oracle.com> <512332FB.7020600@oracle.com> <51235162.9030702@oracle.com> <51236461.7060101@oracle.com> Message-ID: <51237589.4030105@oracle.com> On 2/19/13 12:39 PM, David Holmes wrote: > I'm also indebted to Bengt for spotting that - hadn't realized the 'x' > types were intptr_t typedefs. > > But backing up a step, this code is not obviously thread-safes, or if > it is it must be by a lock at a higher level - so why do we need an > atomic update of the _bytes_written value? Yes, this is something we discussed at lunch today. It looks like calling update_position() without some kind of locking is unsafe. This is not introduced only by the rotatingFileStream. All the outputStream implmentations does this. Looks scary to me. I don't really understand how this works in a safe way. Maybe it doesn't. We are not doing any locking higher up in the call chain as far as I can see. Bengt > > David > > On 19/02/2013 8:18 PM, Jesper Wilhelmsson wrote: >> Bengt, >> >> Thanks for catching this! I should listen to Ted's mother, nothing good >> happens after 2am[1]. >> >> I wasn't aware that jint was 32-bit on all platforms. Using 32-bit >> atomic add like this won't work, back to the drawing board. >> >> The one quick solution I can think of right now that won't be awful >> would be to limit GcLogFileSize to 32 bit. I'm not sure how quick a fix >> it will be though since it may require a CCC approval... >> >> /Jesper >> >> >> [1] http://en.wikipedia.org/wiki/Nothing_Good_Happens_After_2_A.M. >> >> >> On 19/2/13 9:08 AM, Bengt Rutisson wrote: >>> >>> Hi Jesper, >>> >>> Thanks for fixing this! I don't feel very comfortable with this code, >>> so don't >>> consider this a full review. Just a couple of comments: >>> >>> It seems to make sense to use uintx for _bytes_written since the flag >>> to control >>> the file size, GCLogFileSize, is uintx. But since the atomics you >>> use are >>> handling jint I think it looks a bit suspicious. jint is always 32 >>> bits and >>> uintx can be 32 or 64 bit. So, what happens here if _bytes_written is >>> 64 bit? >>> >>> 457 Atomic::add((jint)count, (jint*)&_bytes_written); >>> >>> If _bytes_written is 0x00000000FFFFFFFF and count is 1, I would guess >>> that we >>> get 0x0 instead of 0x0000000100000000. >>> >>> Also, in rotatingFileStream::rotate_log() you changed to: >>> >>> if (_bytes_written <= GCLogFileSize) return; >>> >>> instead of : >>> >>> if (_bytes_writen < (jlong)GCLogFileSize) return; >>> >>> isn't this a problem since you set _bytes_written to UINT_MAX if we >>> wrap around? >>> If someone sets GCLogFileSize on the command line to be UINT_MAX we >>> will never >>> rotate the file, right? >>> >>> Also, we only call rotate_log() when we start a safepoint. If we wrap >>> around >>> once in write() but then call it again before a safepoint happens we >>> can >>> probably set _bytes_written to a value that looks small enough to not >>> have to >>> rotate the log. It seems to me that we would need a separate flag to >>> say that we >>> written enough to rotate the log. >>> >>> Bengt >>> >>> >>> >>> On 2/19/13 7:25 AM, Jesper Wilhelmsson wrote: >>>> Hi, >>>> >>>> Please review the following change: >>>> >>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8008314/ >>>> >>>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8008314 >>>> >>>> >>>> The use of atomic::add(jlong,jlong*) breaks everything on ARM since >>>> it uses >>>> atomic::load(jlong) which isn't implemented. >>>> >>>> The add was used to update a counter in rotating log file handling, >>>> but it >>>> turns out that the counter that was updated doesn't need to be a >>>> jlong. >>>> >>>> The counter is used to indicate that it is time to do a log file >>>> rotation and >>>> by adding a saftey catch for overflow, we can use an uintx for the >>>> counter. >>>> >>>> In practice this means that the upper "limit" for the log file size >>>> becomes >>>> UINX_MAX-1 (used to be UINT_MAX) since I change from < to <= in the >>>> comparison >>>> to the limit, but since this is not a hard limit the difference will >>>> only be >>>> noticeable when someone has written UINT_MAX characters to the log >>>> file and >>>> the next write will end up in the next log file part instead of in >>>> the same >>>> (which one could argue is a more correct behavior). >>>> >>>> Sine I changed all places where the counter was used I also fixed a >>>> typo in >>>> its name. >>>> >>>> Thanks, >>>> /Jesper >>> From nils.loodin at oracle.com Tue Feb 19 04:52:52 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Tue, 19 Feb 2013 13:52:52 +0100 Subject: RFR: JDK-8007804: Need to be able to access Performance counter by name from JVM In-Reply-To: <51235D5E.6010103@oracle.com> References: <51152A60.8000004@oracle.com> <5115B0B5.9030004@oracle.com> <51235D5E.6010103@oracle.com> Message-ID: <512375A4.6070301@oracle.com> Here's the updated webrev: http://cr.openjdk.java.net/~nloodin/8007804/webrev.01/ Regards, Nils Loodin On 02/19/2013 12:09 PM, Nils Loodin wrote: > On 02/09/2013 03:13 AM, David Holmes wrote: >> On 9/02/2013 2:40 AM, Nils Loodin wrote: >>> Please review the following very small and insignificant change: >>> Basically, I need to access a performance-counter by name from within >>> the JVM. >> >> The method name by_name seems a little odd to me. find_by_name would >> seem more consistent (particularly if you consider the strange >> PerfDataList::by_name method - which compares names) > > > I think you're right. I'll rename it to find_by_name instead and send > out another webrev. > > Nisse > >> >> David >> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007804 >>> http://cr.openjdk.java.net/~nloodin/8007804/webrev.00/ >>> >>> Regards, >>> Nils Loodin >>> >>> > From daniel.daugherty at oracle.com Tue Feb 19 05:46:02 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Feb 2013 06:46:02 -0700 Subject: CFV: New HSX Committer: David Chase In-Reply-To: <5122E337.5030203@oracle.com> References: <5111D374.2090101@oracle.com> <5122E337.5030203@oracle.com> Message-ID: <5123821A.7080308@oracle.com> Vote: yes Dan On 2/18/13 7:28 PM, Vladimir Kozlov wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX > Committer. > > David is a member of the Hotspot Compiler group. He is working on > Sumatra Project and new java types. He contributed 8 changesets to HSX > project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=david.r.chase%40oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=drchase > > The last changeset is not shown in the query yet: > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a2bc322ca273 > > Votes are due by Mar 4, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > > > From bengt.rutisson at oracle.com Tue Feb 19 06:32:20 2013 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Tue, 19 Feb 2013 14:32:20 +0000 Subject: hg: hsx/hsx24/hotspot: 8008382: Remove redundant use of Atomic::add(jlong, jlong *) in create_new_gc_id() Message-ID: <20130219143223.3E2C247B9C@hg.openjdk.java.net> Changeset: f82f0250456f Author: brutisso Date: 2013-02-18 14:13 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f82f0250456f 8008382: Remove redundant use of Atomic::add(jlong, jlong *) in create_new_gc_id() Summary: Moving register_gc_start() in to the CMS VM operation makes sure that create_new_gc_id() is not called by multiple threads in parallel. This removes the need for atomics in create_new_gc_d(). Also, Atomic::add(jlong, jlong *) is unimplemented for ARM. Reviewed-by: stefank, dholmes, ehelin ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/shared/gcTrace.cpp From jesper.wilhelmsson at oracle.com Tue Feb 19 08:58:06 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 19 Feb 2013 17:58:06 +0100 Subject: RFR (S): 8008314 - Unimplemented() Atomic::load breaks the applications In-Reply-To: <51237589.4030105@oracle.com> References: <51231AE7.9070206@oracle.com> <512332FB.7020600@oracle.com> <51235162.9030702@oracle.com> <51236461.7060101@oracle.com> <51237589.4030105@oracle.com> Message-ID: <5123AF1E.2020603@oracle.com> Hi, The counter that is protected by the atomic add is only used to decide when to switch to the next file in the rotating log file scheme. Even with the atomic add it is not an exact limit since we only check the limt at a sefepoint and we will always write a whole log message at a time. I ran several tests with most GC logging turned on with and without the atomic add and I see no significant difference in the sizes of the log files. I have a new patch where I remove the atomic add: HS24: http://cr.openjdk.java.net/~jwilhelm/8008314/webrev.2.hs24/ HS25: http://cr.openjdk.java.net/~jwilhelm/8008314/webrev.2.hs25/ Let me know if you feel confident in pushing this. /Jesper On 19/2/13 1:52 PM, Bengt Rutisson wrote: > On 2/19/13 12:39 PM, David Holmes wrote: >> I'm also indebted to Bengt for spotting that - hadn't realized the 'x' types >> were intptr_t typedefs. >> >> But backing up a step, this code is not obviously thread-safes, or if it is it >> must be by a lock at a higher level - so why do we need an atomic update of >> the _bytes_written value? > > Yes, this is something we discussed at lunch today. It looks like calling > update_position() without some kind of locking is unsafe. This is not introduced > only by the rotatingFileStream. All the outputStream implmentations does this. > Looks scary to me. I don't really understand how this works in a safe way. Maybe > it doesn't. > > We are not doing any locking higher up in the call chain as far as I can see. > > Bengt > >> >> David >> >> On 19/02/2013 8:18 PM, Jesper Wilhelmsson wrote: >>> Bengt, >>> >>> Thanks for catching this! I should listen to Ted's mother, nothing good >>> happens after 2am[1]. >>> >>> I wasn't aware that jint was 32-bit on all platforms. Using 32-bit >>> atomic add like this won't work, back to the drawing board. >>> >>> The one quick solution I can think of right now that won't be awful >>> would be to limit GcLogFileSize to 32 bit. I'm not sure how quick a fix >>> it will be though since it may require a CCC approval... >>> >>> /Jesper >>> >>> >>> [1] http://en.wikipedia.org/wiki/Nothing_Good_Happens_After_2_A.M. >>> >>> >>> On 19/2/13 9:08 AM, Bengt Rutisson wrote: >>>> >>>> Hi Jesper, >>>> >>>> Thanks for fixing this! I don't feel very comfortable with this code, >>>> so don't >>>> consider this a full review. Just a couple of comments: >>>> >>>> It seems to make sense to use uintx for _bytes_written since the flag >>>> to control >>>> the file size, GCLogFileSize, is uintx. But since the atomics you use are >>>> handling jint I think it looks a bit suspicious. jint is always 32 >>>> bits and >>>> uintx can be 32 or 64 bit. So, what happens here if _bytes_written is >>>> 64 bit? >>>> >>>> 457 Atomic::add((jint)count, (jint*)&_bytes_written); >>>> >>>> If _bytes_written is 0x00000000FFFFFFFF and count is 1, I would guess >>>> that we >>>> get 0x0 instead of 0x0000000100000000. >>>> >>>> Also, in rotatingFileStream::rotate_log() you changed to: >>>> >>>> if (_bytes_written <= GCLogFileSize) return; >>>> >>>> instead of : >>>> >>>> if (_bytes_writen < (jlong)GCLogFileSize) return; >>>> >>>> isn't this a problem since you set _bytes_written to UINT_MAX if we >>>> wrap around? >>>> If someone sets GCLogFileSize on the command line to be UINT_MAX we >>>> will never >>>> rotate the file, right? >>>> >>>> Also, we only call rotate_log() when we start a safepoint. If we wrap >>>> around >>>> once in write() but then call it again before a safepoint happens we can >>>> probably set _bytes_written to a value that looks small enough to not >>>> have to >>>> rotate the log. It seems to me that we would need a separate flag to >>>> say that we >>>> written enough to rotate the log. >>>> >>>> Bengt >>>> >>>> >>>> >>>> On 2/19/13 7:25 AM, Jesper Wilhelmsson wrote: >>>>> Hi, >>>>> >>>>> Please review the following change: >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8008314/ >>>>> >>>>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8008314 >>>>> >>>>> >>>>> The use of atomic::add(jlong,jlong*) breaks everything on ARM since >>>>> it uses >>>>> atomic::load(jlong) which isn't implemented. >>>>> >>>>> The add was used to update a counter in rotating log file handling, >>>>> but it >>>>> turns out that the counter that was updated doesn't need to be a jlong. >>>>> >>>>> The counter is used to indicate that it is time to do a log file >>>>> rotation and >>>>> by adding a saftey catch for overflow, we can use an uintx for the >>>>> counter. >>>>> >>>>> In practice this means that the upper "limit" for the log file size >>>>> becomes >>>>> UINX_MAX-1 (used to be UINT_MAX) since I change from < to <= in the >>>>> comparison >>>>> to the limit, but since this is not a hard limit the difference will >>>>> only be >>>>> noticeable when someone has written UINT_MAX characters to the log >>>>> file and >>>>> the next write will end up in the next log file part instead of in >>>>> the same >>>>> (which one could argue is a more correct behavior). >>>>> >>>>> Sine I changed all places where the counter was used I also fixed a >>>>> typo in >>>>> its name. >>>>> >>>>> Thanks, >>>>> /Jesper >>>> > From mikael.gerdin at oracle.com Tue Feb 19 10:15:22 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 19 Feb 2013 19:15:22 +0100 Subject: Review request: JDK-8006753 fix failed for JDK-8002415 White box testing API for HotSpot In-Reply-To: <5112A73F.5010105@oracle.com> References: <510FBECB.6050903@oracle.com> <5112853E.4010404@oracle.com> <51129E06.2020104@oracle.com> <5112A73F.5010105@oracle.com> Message-ID: <5123C13A.6050809@oracle.com> Vladimir, all I've merged the recent whitebox test additions into my change and added the missing copyright headers. Here's the latest and greatest webrev: http://cr.openjdk.java.net/~mgerdin/8006753/webrev.2/ I've also ran these tests with jprt -retest to see that the new variant works on different platforms. When doing the change to PrintNMTStatistics.java I discovered that the test was in fact only compiled with javac and not run, and in fact needed further updates to work properly. I filed a bug for that test and updated it to compile the java sources using the new scheme. /Mikael On 02/06/2013 07:55 PM, Vladimir Kozlov wrote: > On 2/6/13 10:16 AM, Mikael Gerdin wrote: >> Vladimir, >> >> On 2013-02-06 17:30, Vladimir Kozlov wrote: >>> Mikael, >>> >>> I like that all WB functionality is moved to test directory. >>> >>> You missed Copyright header in all new files. >> >> Thanks for the reminder, I'm not used to creating new files :) > > I still don't see it in DiagnosticCommand.java. Also old files > WBApi.java and ParserTest.java do not have it. > > Mikael, we need Copyright header in all files we push into open sources. > > Thanks, > Vladimir > >> >>> >>> Could you rename ClassFileDumper to ClassFileInstaller? It will be more >>> clear what it does. >> >> Done. Updated webrev at: >> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.1/ >> >> /Mikael >> >>> >>> Thanks, >>> Vladimir >>> >>> On 2/4/13 5:59 AM, Mikael Gerdin wrote: >>>> Hi, >>>> >>>> Background: >>>> Even from the beginning of the WhiteBox testing API implementation the >>>> tests have not worked on builds promoted by release engineering due to >>>> the fact that the wb.jar file containing the Java classes was not >>>> imported by the JDK-level makefiles. >>>> On one level this was ok since we didn't want to ship the classes to >>>> end >>>> users and we worked around the complexity of somehow post-processing >>>> the >>>> RE bundles to remove them. >>>> >>>> The problem is that we aren't able to run the WhiteBox tests in >>>> promotion testing, or to verify fixes against earlier builds. >>>> >>>> Solution: >>>> The solution suggested here is to put the WhiteBox helper classes in >>>> the >>>> testlibrary directory under test/ and >>>> * tell jtreg to first compile the classes >>>> * run a special Java program to copy the classes to the test work >>>> directory >>>> * run the white box test with -Xbootclasspath/a:. to pick up the copied >>>> classes. >>>> >>>> The solution is kind-of hackish but I've been unable to come up with a >>>> better solution without performing complex surgery on jtreg. >>>> >>>> The changes to the make/ directory should basically revert the makefile >>>> changes that were added to support this API. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.0/ >>>> Bug: >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006753 >>>> >>>> Note about renamed/moved files: >>>> I will try to make sure that the moved/renamed files will be tracked >>>> properly by mercurial, but I think that using patch files and MQ breaks >>>> this so I'll do this after the review is done. >>>> >>>> Thanks >>>> /Mikael From serguei.spitsyn at oracle.com Tue Feb 19 10:30:37 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Feb 2013 10:30:37 -0800 Subject: RFR: JDK-8007804: Need to be able to access Performance counter by name from JVM In-Reply-To: <512375A4.6070301@oracle.com> References: <51152A60.8000004@oracle.com> <5115B0B5.9030004@oracle.com> <51235D5E.6010103@oracle.com> <512375A4.6070301@oracle.com> Message-ID: <5123C4CD.8010607@oracle.com> Looks good. Thanks, Serguei On 2/19/13 4:52 AM, Nils Loodin wrote: > Here's the updated webrev: > > http://cr.openjdk.java.net/~nloodin/8007804/webrev.01/ > > Regards, > Nils Loodin > > On 02/19/2013 12:09 PM, Nils Loodin wrote: >> On 02/09/2013 03:13 AM, David Holmes wrote: >>> On 9/02/2013 2:40 AM, Nils Loodin wrote: >>>> Please review the following very small and insignificant change: >>>> Basically, I need to access a performance-counter by name from within >>>> the JVM. >>> >>> The method name by_name seems a little odd to me. find_by_name would >>> seem more consistent (particularly if you consider the strange >>> PerfDataList::by_name method - which compares names) >> >> >> I think you're right. I'll rename it to find_by_name instead and send >> out another webrev. >> >> Nisse >> >>> >>> David >>> >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007804 >>>> http://cr.openjdk.java.net/~nloodin/8007804/webrev.00/ >>>> >>>> Regards, >>>> Nils Loodin >>>> >>>> >> > From staffan.larsen at oracle.com Tue Feb 19 11:01:43 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 19 Feb 2013 20:01:43 +0100 Subject: RFR: JDK-8007804: Need to be able to access Performance counter by name from JVM In-Reply-To: <512375A4.6070301@oracle.com> References: <51152A60.8000004@oracle.com> <5115B0B5.9030004@oracle.com> <51235D5E.6010103@oracle.com> <512375A4.6070301@oracle.com> Message-ID: Looks good. /Staffan On 19 feb 2013, at 13:52, Nils Loodin wrote: > Here's the updated webrev: > > http://cr.openjdk.java.net/~nloodin/8007804/webrev.01/ > > Regards, > Nils Loodin > > On 02/19/2013 12:09 PM, Nils Loodin wrote: >> On 02/09/2013 03:13 AM, David Holmes wrote: >>> On 9/02/2013 2:40 AM, Nils Loodin wrote: >>>> Please review the following very small and insignificant change: >>>> Basically, I need to access a performance-counter by name from within >>>> the JVM. >>> >>> The method name by_name seems a little odd to me. find_by_name would >>> seem more consistent (particularly if you consider the strange >>> PerfDataList::by_name method - which compares names) >> >> >> I think you're right. I'll rename it to find_by_name instead and send >> out another webrev. >> >> Nisse >> >>> >>> David >>> >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007804 >>>> http://cr.openjdk.java.net/~nloodin/8007804/webrev.00/ >>>> >>>> Regards, >>>> Nils Loodin >>>> >>>> >> > From mitchnull at gmail.com Tue Feb 19 07:55:15 2013 From: mitchnull at gmail.com (=?ISO-8859-1?Q?P=E9ter_Radics?=) Date: Tue, 19 Feb 2013 16:55:15 +0100 Subject: Bug 100297 - [patch] fix name clash of assert macro in debug.hpp with libc's assert macro Message-ID: Hello, hotspot/src/share/vm/utilities/debug.hpp defines an assert macro with two parameters. This macro definition clashes with libc's assert macro from (and to the best of my knowledge it's undefined behavior to redefine assert like this). The name clash causes build failures if any of the files using debug.hpp directly or indirectly include (or ), too. This doesn't seem to happen with libstdc++ (yet?), but this error is triggered if trying to build with libc++ (http://libcxx.llvm.org). I propose changing the name of the assert macro defined in debug.hpp to assert_vm (based on the fact that this macro is used solely in the vm subsystem). I've created a set of patches and attached it to issue 100297: https://bugs.openjdk.java.net/show_bug.cgi?id=100297 I believe libc++ will be used by more and more systems in the near future (as far as I know FreeBSD is planning to include it as the default c++ lib in a coming release), so it would be worthwhile fixing this issue. cheers, mitch From vladimir.kozlov at oracle.com Tue Feb 19 11:18:01 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Feb 2013 11:18:01 -0800 Subject: Review request: JDK-8006753 fix failed for JDK-8002415 White box testing API for HotSpot In-Reply-To: <5123C13A.6050809@oracle.com> References: <510FBECB.6050903@oracle.com> <5112853E.4010404@oracle.com> <51129E06.2020104@oracle.com> <5112A73F.5010105@oracle.com> <5123C13A.6050809@oracle.com> Message-ID: <5123CFE9.3050202@oracle.com> Mikael, Did you use 'hg rename' to move WhiteBox.java and DiagnosticCommand.java? Or you just copied it? I don't see in hsx-rt.patch that they were removed from src/share/tools/whitebox. I noticed that changeset's Summary still reference ClassFileDumper: Summary: Modify WhiteBoxAPI to use interface classes from test/testlibrary instead, add ClassFileDumper to resolve the boot class path issue Thanks, Vladimir On 2/19/13 10:15 AM, Mikael Gerdin wrote: > Vladimir, all > > I've merged the recent whitebox test additions into my change and added > the missing copyright headers. > Here's the latest and greatest webrev: > http://cr.openjdk.java.net/~mgerdin/8006753/webrev.2/ > > I've also ran these tests with jprt -retest to see that the new variant > works on different platforms. > > When doing the change to PrintNMTStatistics.java I discovered that the > test was in fact only compiled with javac and not run, and in fact > needed further updates to work properly. I filed a bug for that test and > updated it to compile the java sources using the new scheme. > > /Mikael > > On 02/06/2013 07:55 PM, Vladimir Kozlov wrote: >> On 2/6/13 10:16 AM, Mikael Gerdin wrote: >>> Vladimir, >>> >>> On 2013-02-06 17:30, Vladimir Kozlov wrote: >>>> Mikael, >>>> >>>> I like that all WB functionality is moved to test directory. >>>> >>>> You missed Copyright header in all new files. >>> >>> Thanks for the reminder, I'm not used to creating new files :) >> >> I still don't see it in DiagnosticCommand.java. Also old files >> WBApi.java and ParserTest.java do not have it. >> >> Mikael, we need Copyright header in all files we push into open sources. >> >> Thanks, >> Vladimir >> >>> >>>> >>>> Could you rename ClassFileDumper to ClassFileInstaller? It will be more >>>> clear what it does. >>> >>> Done. Updated webrev at: >>> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.1/ >>> >>> /Mikael >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 2/4/13 5:59 AM, Mikael Gerdin wrote: >>>>> Hi, >>>>> >>>>> Background: >>>>> Even from the beginning of the WhiteBox testing API implementation the >>>>> tests have not worked on builds promoted by release engineering due to >>>>> the fact that the wb.jar file containing the Java classes was not >>>>> imported by the JDK-level makefiles. >>>>> On one level this was ok since we didn't want to ship the classes to >>>>> end >>>>> users and we worked around the complexity of somehow post-processing >>>>> the >>>>> RE bundles to remove them. >>>>> >>>>> The problem is that we aren't able to run the WhiteBox tests in >>>>> promotion testing, or to verify fixes against earlier builds. >>>>> >>>>> Solution: >>>>> The solution suggested here is to put the WhiteBox helper classes in >>>>> the >>>>> testlibrary directory under test/ and >>>>> * tell jtreg to first compile the classes >>>>> * run a special Java program to copy the classes to the test work >>>>> directory >>>>> * run the white box test with -Xbootclasspath/a:. to pick up the >>>>> copied >>>>> classes. >>>>> >>>>> The solution is kind-of hackish but I've been unable to come up with a >>>>> better solution without performing complex surgery on jtreg. >>>>> >>>>> The changes to the make/ directory should basically revert the >>>>> makefile >>>>> changes that were added to support this API. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.0/ >>>>> Bug: >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006753 >>>>> >>>>> Note about renamed/moved files: >>>>> I will try to make sure that the moved/renamed files will be tracked >>>>> properly by mercurial, but I think that using patch files and MQ >>>>> breaks >>>>> this so I'll do this after the review is done. >>>>> >>>>> Thanks >>>>> /Mikael > From mikael.gerdin at oracle.com Tue Feb 19 11:21:42 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 19 Feb 2013 20:21:42 +0100 Subject: Review request: JDK-8006753 fix failed for JDK-8002415 White box testing API for HotSpot In-Reply-To: <5123CFE9.3050202@oracle.com> References: <510FBECB.6050903@oracle.com> <5112853E.4010404@oracle.com> <51129E06.2020104@oracle.com> <5112A73F.5010105@oracle.com> <5123C13A.6050809@oracle.com> <5123CFE9.3050202@oracle.com> Message-ID: <5123D0C6.1050201@oracle.com> Vladimir, On 2013-02-19 20:18, Vladimir Kozlov wrote: > Mikael, > > Did you use 'hg rename' to move WhiteBox.java and > DiagnosticCommand.java? Or you just copied it? I don't see in > hsx-rt.patch that they were removed from src/share/tools/whitebox. Yes, if you look at the webrev html it says " test/testlibrary/whitebox/sun/hotspot/WhiteBox.java (was src/share/tools/whitebox/sun/hotspot/WhiteBox.java" but you are correct in that the hsx-rt.patch file does not contain that information, but the changeset in my local repository does have that information. I believe this is because webrev does not create a "real" hg patch with all the releavant hg metadata. > > I noticed that changeset's Summary still reference ClassFileDumper: Oops, will fix that. > > Summary: Modify WhiteBoxAPI to use interface classes from > test/testlibrary instead, add ClassFileDumper to resolve the boot class > path issue Given that fix, are you ok with me pushing this? /Mikael > > Thanks, > Vladimir > > On 2/19/13 10:15 AM, Mikael Gerdin wrote: >> Vladimir, all >> >> I've merged the recent whitebox test additions into my change and added >> the missing copyright headers. >> Here's the latest and greatest webrev: >> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.2/ >> >> I've also ran these tests with jprt -retest to see that the new variant >> works on different platforms. >> >> When doing the change to PrintNMTStatistics.java I discovered that the >> test was in fact only compiled with javac and not run, and in fact >> needed further updates to work properly. I filed a bug for that test and >> updated it to compile the java sources using the new scheme. >> >> /Mikael >> >> On 02/06/2013 07:55 PM, Vladimir Kozlov wrote: >>> On 2/6/13 10:16 AM, Mikael Gerdin wrote: >>>> Vladimir, >>>> >>>> On 2013-02-06 17:30, Vladimir Kozlov wrote: >>>>> Mikael, >>>>> >>>>> I like that all WB functionality is moved to test directory. >>>>> >>>>> You missed Copyright header in all new files. >>>> >>>> Thanks for the reminder, I'm not used to creating new files :) >>> >>> I still don't see it in DiagnosticCommand.java. Also old files >>> WBApi.java and ParserTest.java do not have it. >>> >>> Mikael, we need Copyright header in all files we push into open sources. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>>> >>>>> Could you rename ClassFileDumper to ClassFileInstaller? It will be >>>>> more >>>>> clear what it does. >>>> >>>> Done. Updated webrev at: >>>> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.1/ >>>> >>>> /Mikael >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 2/4/13 5:59 AM, Mikael Gerdin wrote: >>>>>> Hi, >>>>>> >>>>>> Background: >>>>>> Even from the beginning of the WhiteBox testing API implementation >>>>>> the >>>>>> tests have not worked on builds promoted by release engineering >>>>>> due to >>>>>> the fact that the wb.jar file containing the Java classes was not >>>>>> imported by the JDK-level makefiles. >>>>>> On one level this was ok since we didn't want to ship the classes to >>>>>> end >>>>>> users and we worked around the complexity of somehow post-processing >>>>>> the >>>>>> RE bundles to remove them. >>>>>> >>>>>> The problem is that we aren't able to run the WhiteBox tests in >>>>>> promotion testing, or to verify fixes against earlier builds. >>>>>> >>>>>> Solution: >>>>>> The solution suggested here is to put the WhiteBox helper classes in >>>>>> the >>>>>> testlibrary directory under test/ and >>>>>> * tell jtreg to first compile the classes >>>>>> * run a special Java program to copy the classes to the test work >>>>>> directory >>>>>> * run the white box test with -Xbootclasspath/a:. to pick up the >>>>>> copied >>>>>> classes. >>>>>> >>>>>> The solution is kind-of hackish but I've been unable to come up >>>>>> with a >>>>>> better solution without performing complex surgery on jtreg. >>>>>> >>>>>> The changes to the make/ directory should basically revert the >>>>>> makefile >>>>>> changes that were added to support this API. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.0/ >>>>>> Bug: >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006753 >>>>>> >>>>>> Note about renamed/moved files: >>>>>> I will try to make sure that the moved/renamed files will be tracked >>>>>> properly by mercurial, but I think that using patch files and MQ >>>>>> breaks >>>>>> this so I'll do this after the review is done. >>>>>> >>>>>> Thanks >>>>>> /Mikael >> From zhengyu.gu at oracle.com Tue Feb 19 11:25:00 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 19 Feb 2013 14:25:00 -0500 Subject: CFV: New HSX Committer: David Chase In-Reply-To: <5122E337.5030203@oracle.com> References: <5111D374.2090101@oracle.com> <5122E337.5030203@oracle.com> Message-ID: <5123D18C.8050801@oracle.com> Vote: yes -Zhengyu On 2/18/2013 9:28 PM, Vladimir Kozlov wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX > Committer. > > David is a member of the Hotspot Compiler group. He is working on > Sumatra Project and new java types. He contributed 8 changesets to HSX > project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=david.r.chase%40oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=drchase > > The last changeset is not shown in the query yet: > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a2bc322ca273 > > Votes are due by Mar 4, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > > > From vladimir.kozlov at oracle.com Tue Feb 19 11:35:31 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Feb 2013 11:35:31 -0800 Subject: Review request: JDK-8006753 fix failed for JDK-8002415 White box testing API for HotSpot In-Reply-To: <5123D0C6.1050201@oracle.com> References: <510FBECB.6050903@oracle.com> <5112853E.4010404@oracle.com> <51129E06.2020104@oracle.com> <5112A73F.5010105@oracle.com> <5123C13A.6050809@oracle.com> <5123CFE9.3050202@oracle.com> <5123D0C6.1050201@oracle.com> Message-ID: <5123D403.2070002@oracle.com> Changes are good for push. I only worried about the first issue but I reproduced your case with next instruction: $ hg rename src/share/tools/whitebox test/testlibrary/whitebox moving src/share/tools/whitebox/sun/hotspot/WhiteBox.java to test/testlibrary/whitebox/sun/hotspot/WhiteBox.java moving src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java to test/testlibrary/whitebox/sun/hotspot/parser/DiagnosticCommand.java Did your 'hg st' shows the next?: $ hg st A test/testlibrary/whitebox/sun/hotspot/WhiteBox.java A test/testlibrary/whitebox/sun/hotspot/parser/DiagnosticCommand.java R src/share/tools/whitebox/sun/hotspot/WhiteBox.java R src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java Thanks, Vladimir On 2/19/13 11:21 AM, Mikael Gerdin wrote: > Vladimir, > > On 2013-02-19 20:18, Vladimir Kozlov wrote: >> Mikael, >> >> Did you use 'hg rename' to move WhiteBox.java and >> DiagnosticCommand.java? Or you just copied it? I don't see in >> hsx-rt.patch that they were removed from src/share/tools/whitebox. > > Yes, if you look at the webrev html it says > " test/testlibrary/whitebox/sun/hotspot/WhiteBox.java (was > src/share/tools/whitebox/sun/hotspot/WhiteBox.java" > but you are correct in that the hsx-rt.patch file does not contain that > information, but the changeset in my local repository does have that > information. I believe this is because webrev does not create a "real" > hg patch with all the releavant hg metadata. > >> >> I noticed that changeset's Summary still reference ClassFileDumper: > > Oops, will fix that. > >> >> Summary: Modify WhiteBoxAPI to use interface classes from >> test/testlibrary instead, add ClassFileDumper to resolve the boot class >> path issue > > Given that fix, are you ok with me pushing this? > > /Mikael > >> >> Thanks, >> Vladimir >> >> On 2/19/13 10:15 AM, Mikael Gerdin wrote: >>> Vladimir, all >>> >>> I've merged the recent whitebox test additions into my change and added >>> the missing copyright headers. >>> Here's the latest and greatest webrev: >>> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.2/ >>> >>> I've also ran these tests with jprt -retest to see that the new variant >>> works on different platforms. >>> >>> When doing the change to PrintNMTStatistics.java I discovered that the >>> test was in fact only compiled with javac and not run, and in fact >>> needed further updates to work properly. I filed a bug for that test and >>> updated it to compile the java sources using the new scheme. >>> >>> /Mikael >>> >>> On 02/06/2013 07:55 PM, Vladimir Kozlov wrote: >>>> On 2/6/13 10:16 AM, Mikael Gerdin wrote: >>>>> Vladimir, >>>>> >>>>> On 2013-02-06 17:30, Vladimir Kozlov wrote: >>>>>> Mikael, >>>>>> >>>>>> I like that all WB functionality is moved to test directory. >>>>>> >>>>>> You missed Copyright header in all new files. >>>>> >>>>> Thanks for the reminder, I'm not used to creating new files :) >>>> >>>> I still don't see it in DiagnosticCommand.java. Also old files >>>> WBApi.java and ParserTest.java do not have it. >>>> >>>> Mikael, we need Copyright header in all files we push into open >>>> sources. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>>> >>>>>> Could you rename ClassFileDumper to ClassFileInstaller? It will be >>>>>> more >>>>>> clear what it does. >>>>> >>>>> Done. Updated webrev at: >>>>> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.1/ >>>>> >>>>> /Mikael >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 2/4/13 5:59 AM, Mikael Gerdin wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Background: >>>>>>> Even from the beginning of the WhiteBox testing API implementation >>>>>>> the >>>>>>> tests have not worked on builds promoted by release engineering >>>>>>> due to >>>>>>> the fact that the wb.jar file containing the Java classes was not >>>>>>> imported by the JDK-level makefiles. >>>>>>> On one level this was ok since we didn't want to ship the classes to >>>>>>> end >>>>>>> users and we worked around the complexity of somehow post-processing >>>>>>> the >>>>>>> RE bundles to remove them. >>>>>>> >>>>>>> The problem is that we aren't able to run the WhiteBox tests in >>>>>>> promotion testing, or to verify fixes against earlier builds. >>>>>>> >>>>>>> Solution: >>>>>>> The solution suggested here is to put the WhiteBox helper classes in >>>>>>> the >>>>>>> testlibrary directory under test/ and >>>>>>> * tell jtreg to first compile the classes >>>>>>> * run a special Java program to copy the classes to the test work >>>>>>> directory >>>>>>> * run the white box test with -Xbootclasspath/a:. to pick up the >>>>>>> copied >>>>>>> classes. >>>>>>> >>>>>>> The solution is kind-of hackish but I've been unable to come up >>>>>>> with a >>>>>>> better solution without performing complex surgery on jtreg. >>>>>>> >>>>>>> The changes to the make/ directory should basically revert the >>>>>>> makefile >>>>>>> changes that were added to support this API. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.0/ >>>>>>> Bug: >>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006753 >>>>>>> >>>>>>> Note about renamed/moved files: >>>>>>> I will try to make sure that the moved/renamed files will be tracked >>>>>>> properly by mercurial, but I think that using patch files and MQ >>>>>>> breaks >>>>>>> this so I'll do this after the review is done. >>>>>>> >>>>>>> Thanks >>>>>>> /Mikael >>> From mikael.gerdin at oracle.com Tue Feb 19 11:52:12 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 19 Feb 2013 20:52:12 +0100 Subject: Review request: JDK-8006753 fix failed for JDK-8002415 White box testing API for HotSpot In-Reply-To: <5123D403.2070002@oracle.com> References: <510FBECB.6050903@oracle.com> <5112853E.4010404@oracle.com> <51129E06.2020104@oracle.com> <5112A73F.5010105@oracle.com> <5123C13A.6050809@oracle.com> <5123CFE9.3050202@oracle.com> <5123D0C6.1050201@oracle.com> <5123D403.2070002@oracle.com> Message-ID: <5123D7EC.9030702@oracle.com> Vladimir, On 2013-02-19 20:35, Vladimir Kozlov wrote: > Changes are good for push. > > I only worried about the first issue but I reproduced your case with > next instruction: > > $ hg rename src/share/tools/whitebox test/testlibrary/whitebox > moving src/share/tools/whitebox/sun/hotspot/WhiteBox.java to > test/testlibrary/whitebox/sun/hotspot/WhiteBox.java > moving > src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java to > test/testlibrary/whitebox/sun/hotspot/parser/DiagnosticCommand.java > > Did your 'hg st' shows the next?: > > $ hg st > A test/testlibrary/whitebox/sun/hotspot/WhiteBox.java > A test/testlibrary/whitebox/sun/hotspot/parser/DiagnosticCommand.java > R src/share/tools/whitebox/sun/hotspot/WhiteBox.java > R src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java Yes, hg doesn't seem to be very good at describing moved files. But if you run "hg diff --git" then it should tell you about the moved file. /Mikael > > Thanks, > Vladimir > > On 2/19/13 11:21 AM, Mikael Gerdin wrote: >> Vladimir, >> >> On 2013-02-19 20:18, Vladimir Kozlov wrote: >>> Mikael, >>> >>> Did you use 'hg rename' to move WhiteBox.java and >>> DiagnosticCommand.java? Or you just copied it? I don't see in >>> hsx-rt.patch that they were removed from src/share/tools/whitebox. >> >> Yes, if you look at the webrev html it says >> " test/testlibrary/whitebox/sun/hotspot/WhiteBox.java (was >> src/share/tools/whitebox/sun/hotspot/WhiteBox.java" >> but you are correct in that the hsx-rt.patch file does not contain that >> information, but the changeset in my local repository does have that >> information. I believe this is because webrev does not create a "real" >> hg patch with all the releavant hg metadata. >> >>> >>> I noticed that changeset's Summary still reference ClassFileDumper: >> >> Oops, will fix that. >> >>> >>> Summary: Modify WhiteBoxAPI to use interface classes from >>> test/testlibrary instead, add ClassFileDumper to resolve the boot class >>> path issue >> >> Given that fix, are you ok with me pushing this? >> >> /Mikael >> >>> >>> Thanks, >>> Vladimir >>> >>> On 2/19/13 10:15 AM, Mikael Gerdin wrote: >>>> Vladimir, all >>>> >>>> I've merged the recent whitebox test additions into my change and added >>>> the missing copyright headers. >>>> Here's the latest and greatest webrev: >>>> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.2/ >>>> >>>> I've also ran these tests with jprt -retest to see that the new variant >>>> works on different platforms. >>>> >>>> When doing the change to PrintNMTStatistics.java I discovered that the >>>> test was in fact only compiled with javac and not run, and in fact >>>> needed further updates to work properly. I filed a bug for that test >>>> and >>>> updated it to compile the java sources using the new scheme. >>>> >>>> /Mikael >>>> >>>> On 02/06/2013 07:55 PM, Vladimir Kozlov wrote: >>>>> On 2/6/13 10:16 AM, Mikael Gerdin wrote: >>>>>> Vladimir, >>>>>> >>>>>> On 2013-02-06 17:30, Vladimir Kozlov wrote: >>>>>>> Mikael, >>>>>>> >>>>>>> I like that all WB functionality is moved to test directory. >>>>>>> >>>>>>> You missed Copyright header in all new files. >>>>>> >>>>>> Thanks for the reminder, I'm not used to creating new files :) >>>>> >>>>> I still don't see it in DiagnosticCommand.java. Also old files >>>>> WBApi.java and ParserTest.java do not have it. >>>>> >>>>> Mikael, we need Copyright header in all files we push into open >>>>> sources. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>>> >>>>>>> Could you rename ClassFileDumper to ClassFileInstaller? It will be >>>>>>> more >>>>>>> clear what it does. >>>>>> >>>>>> Done. Updated webrev at: >>>>>> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.1/ >>>>>> >>>>>> /Mikael >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 2/4/13 5:59 AM, Mikael Gerdin wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Background: >>>>>>>> Even from the beginning of the WhiteBox testing API implementation >>>>>>>> the >>>>>>>> tests have not worked on builds promoted by release engineering >>>>>>>> due to >>>>>>>> the fact that the wb.jar file containing the Java classes was not >>>>>>>> imported by the JDK-level makefiles. >>>>>>>> On one level this was ok since we didn't want to ship the >>>>>>>> classes to >>>>>>>> end >>>>>>>> users and we worked around the complexity of somehow >>>>>>>> post-processing >>>>>>>> the >>>>>>>> RE bundles to remove them. >>>>>>>> >>>>>>>> The problem is that we aren't able to run the WhiteBox tests in >>>>>>>> promotion testing, or to verify fixes against earlier builds. >>>>>>>> >>>>>>>> Solution: >>>>>>>> The solution suggested here is to put the WhiteBox helper >>>>>>>> classes in >>>>>>>> the >>>>>>>> testlibrary directory under test/ and >>>>>>>> * tell jtreg to first compile the classes >>>>>>>> * run a special Java program to copy the classes to the test work >>>>>>>> directory >>>>>>>> * run the white box test with -Xbootclasspath/a:. to pick up the >>>>>>>> copied >>>>>>>> classes. >>>>>>>> >>>>>>>> The solution is kind-of hackish but I've been unable to come up >>>>>>>> with a >>>>>>>> better solution without performing complex surgery on jtreg. >>>>>>>> >>>>>>>> The changes to the make/ directory should basically revert the >>>>>>>> makefile >>>>>>>> changes that were added to support this API. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.0/ >>>>>>>> Bug: >>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006753 >>>>>>>> >>>>>>>> Note about renamed/moved files: >>>>>>>> I will try to make sure that the moved/renamed files will be >>>>>>>> tracked >>>>>>>> properly by mercurial, but I think that using patch files and MQ >>>>>>>> breaks >>>>>>>> this so I'll do this after the review is done. >>>>>>>> >>>>>>>> Thanks >>>>>>>> /Mikael >>>> From christian.thalinger at oracle.com Tue Feb 19 12:01:20 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 19 Feb 2013 12:01:20 -0800 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <5122B5C3.1010908@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> <50A24E00.3070200@oracle.com> <50A25720.1040405@oracle.com> <50A59010.5040001@oracle.com> <510C18F6.6010305@oracle.com> <511DAB26.2010808@oracle.com> <511DB3E0.6030606@oracle.com> <5122B5C3.1010908@oracle.com> Message-ID: <0153EC9C-4474-4B54-B215-6BE7BF2A7E1B@oracle.com> On Feb 18, 2013, at 3:14 PM, Mikael Vidstedt wrote: > > A really good control question, thanks a lot for asking! > > As a matter of fact these changes are basically just doing what the compiler already does for us, so it's more about cleaning up the source code than reducing the size of the binary. So in theory these changes should have no impact on the binary size at all, but it actually turns out they do. Very specifically, the fact that I moved the same_page() function from being duplicated in the three os_.cpp files to having it be in globalDefinitions.cpp makes the binary grow a few bytes (54 bytes to be specific). The reason is a bit subtle: > > The same_page() function is (was) static in the respective os_*.cpp files. They are only ever used when the Verbose flag is true, and furthermore the Verbose option is a develop only flag, which means it is hardcoded to false in product. The compiler knows that's the case and eliminates the same_page() function completely. > > Since I moved it to globalDefinitions.cpp there's no way easy for the compiler to know that it is not being used, so it will actually keep the function. > > Unless there are strong opinions I'm not going to do anything about this. > > However, this made me question my earlier experiments with using the const bool = false construct in constantPool.cpp, because after all that is the exact same pattern. And it turns out that I must have done something wrong when I was performing the experiments, because when I do the same thing again now it turns out the compiler actually *does* deadcode eliminate the debug-only functions. So I take everything back and conclude that const bool = false is indeed a great way to make sure the debug code does not rot over time, and that the product binary will *not* contain the dead functions. Sorry for any confusion this may have caused. > > With all that in mind, here's another version of the webrev: > > http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev04/webrev/ src/share/vm/interpreter/interpreterRuntime.cpp: I suppose that #if 0 is to keep that code for...? Could we add a comment why we keep it? src/share/vm/oops/constantPool.cpp: So we use: + const bool debug_cpool = false; but we still have the DBG macro. Can't we have a static debug method that takes all printf arguments and prints them? The debug_cpool should make that method empty and the compiler can remove it. I really start to hate all these macros... -- Chris > > The only change since the earlier webrev is in constantPool.cpp, where I updated the code to use the const bool = false idiom. > > I would appreciate a review or two of that piece specifically. > > Thanks, > Mikael > > On 2/14/2013 8:04 PM, Azeem Jiva wrote: >> Did you measure how much the libjvm.so shrank with your changes? >> >> On 2/14/2013 7:27 PM, Coleen Phillmore wrote: >>> >>> Looks good Mikael! I like these sorts of changes. >>> Coleen >>> >>> On 2/1/2013 11:35 AM, Mikael Vidstedt wrote: >>>> >>>> All, >>>> >>>> I finally found some time to update the webrev: >>>> >>>> http://cr.openjdk.java.net/~mikael/8003310/webrev.03/webrev/ >>>> >>>> Not much has changes since the first webrev. I played around with turning the #ifdef in constantPool.cpp into a const bool = false, but one of the downsides I noticed with that is that the code will still be compiled into product and especially for this type of function with a relatively large number of constant strings in it it unnecessarily adds to the footprint. This does not invalidate the const bool = false idiom, but there may be cases where it is beneficial to use alternatives to it. >>>> >>>> Cheers, >>>> Mikael >>>> >>>> On 11/15/2012 5:00 PM, Mikael Vidstedt wrote: >>>>> On 2012-11-13 06:20, Coleen Phillimore wrote: >>>>>> On 11/13/2012 8:41 AM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Hi Mikael, This is good! I have the same comments as David. >>>>>>> >>>>>>> For constantPool.cpp can you add #undef DBG after that code. >>>>>>> >>>>>>> Maybe there should be a new convention for DEBUG_ for unused code that people want to leave around for debugging. I don't recommend we add a lot of code like this, but having such an ifdef would differentiate code that was just left in unintentionally from code that we want to be left in (occasionally). >>>>>> >>>>>> Actually, I want to revise this. We had this discussion about this recently rwt metaspace debugging and favored a const static variable = false; under #ifdef DEBUG or ASSERT and the debugging code under DEBUG/ASSERT so that it doesn't bit rot. This is for the code left in intentionally. Which makes me wonder why print_cpool_bytes() is there under DEBUG_CPOOL claiming to be "temporary" when there is another printing function in that file already. >>>>> >>>>> The reason why I moved it under DBG was because it is only ever called wrapped with a DBG(). I can play around with making it a const static = false as you outlined. >>>>> >>>>> The other print functions in constantPool.cpp are implementations of the virtual functions inherited from Metadata, so they are not quite as temporary as print_cpool_bytes, if that makes sense. >>>>> >>>>> Cheers, >>>>> Mikael >>>>> >>>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 11/13/2012 12:47 AM, David Holmes wrote: >>>>>>>> Hi Mikael, >>>>>>>> >>>>>>>> A couple of general observations as really the "owners" of each file needs to assess the changes: >>>>>>>> >>>>>>>> - sometimes functions exist for debugging/tracing and calls will be added to the code by engineers as they debug. For example MBFence in synchronizer.cpp allows you to add fences into expressions. >>>>>>>> >>>>>>>> - why was the "static" removed from a number functions. They now have global visibility rather than being restricted to their files? >>>>>>>> >>>>>>>> >>>>>>>> In globaleDefinitions.cpp: >>>>>>>> >>>>>>>> + void GlobalDefinitions::test_globals() { >>>>>>>> + intptr_t page_size = 4096; >>>>>>>> >>>>>>>> Page size may not be 4K - will the test still be valid? >>>>>>>> >>>>>>>> >>>>>>>> The comments describing clamp_address_in_page don't need to be on both the declaration and definition. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> ------ >>>>>>>> >>>>>>>> On 13/11/2012 1:59 PM, Mikael Vidstedt wrote: >>>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> Please review the below change. The change adds the -Wunused flag when >>>>>>>>> compiling with GCC and removes a number of unused functions/dead code. >>>>>>>>> >>>>>>>>> In the process I found one function (same_page) which was duplicated in >>>>>>>>> four different places. I merged it to a single function, renamed it to >>>>>>>>> clamp_address_in_page, added some comments and refactored it to be >>>>>>>>> slightly easier to understand. I also added unit tests for it. Feedback >>>>>>>>> appreciated (especially on the name). >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~mikael/8003310/webrev.00/ >>>>>>>>> >>>>>>>>> Passes JPRT and the built-in unit tests (-XX:+ExecuteInternalVMTests). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Mikael >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From vladimir.kozlov at oracle.com Tue Feb 19 12:04:25 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Feb 2013 12:04:25 -0800 Subject: Review request: JDK-8006753 fix failed for JDK-8002415 White box testing API for HotSpot In-Reply-To: <5123D7EC.9030702@oracle.com> References: <510FBECB.6050903@oracle.com> <5112853E.4010404@oracle.com> <51129E06.2020104@oracle.com> <5112A73F.5010105@oracle.com> <5123C13A.6050809@oracle.com> <5123CFE9.3050202@oracle.com> <5123D0C6.1050201@oracle.com> <5123D403.2070002@oracle.com> <5123D7EC.9030702@oracle.com> Message-ID: <5123DAC9.3020608@oracle.com> Thank you for confirming it. It is good for push. Thanks, Vladimir On 2/19/13 11:52 AM, Mikael Gerdin wrote: > Vladimir, > > On 2013-02-19 20:35, Vladimir Kozlov wrote: >> Changes are good for push. >> >> I only worried about the first issue but I reproduced your case with >> next instruction: >> >> $ hg rename src/share/tools/whitebox test/testlibrary/whitebox >> moving src/share/tools/whitebox/sun/hotspot/WhiteBox.java to >> test/testlibrary/whitebox/sun/hotspot/WhiteBox.java >> moving >> src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java to >> test/testlibrary/whitebox/sun/hotspot/parser/DiagnosticCommand.java >> >> Did your 'hg st' shows the next?: >> >> $ hg st >> A test/testlibrary/whitebox/sun/hotspot/WhiteBox.java >> A test/testlibrary/whitebox/sun/hotspot/parser/DiagnosticCommand.java >> R src/share/tools/whitebox/sun/hotspot/WhiteBox.java >> R src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java > > Yes, hg doesn't seem to be very good at describing moved files. > But if you run "hg diff --git" then it should tell you about the moved > file. > > /Mikael > >> >> Thanks, >> Vladimir >> >> On 2/19/13 11:21 AM, Mikael Gerdin wrote: >>> Vladimir, >>> >>> On 2013-02-19 20:18, Vladimir Kozlov wrote: >>>> Mikael, >>>> >>>> Did you use 'hg rename' to move WhiteBox.java and >>>> DiagnosticCommand.java? Or you just copied it? I don't see in >>>> hsx-rt.patch that they were removed from src/share/tools/whitebox. >>> >>> Yes, if you look at the webrev html it says >>> " test/testlibrary/whitebox/sun/hotspot/WhiteBox.java (was >>> src/share/tools/whitebox/sun/hotspot/WhiteBox.java" >>> but you are correct in that the hsx-rt.patch file does not contain that >>> information, but the changeset in my local repository does have that >>> information. I believe this is because webrev does not create a "real" >>> hg patch with all the releavant hg metadata. >>> >>>> >>>> I noticed that changeset's Summary still reference ClassFileDumper: >>> >>> Oops, will fix that. >>> >>>> >>>> Summary: Modify WhiteBoxAPI to use interface classes from >>>> test/testlibrary instead, add ClassFileDumper to resolve the boot class >>>> path issue >>> >>> Given that fix, are you ok with me pushing this? >>> >>> /Mikael >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 2/19/13 10:15 AM, Mikael Gerdin wrote: >>>>> Vladimir, all >>>>> >>>>> I've merged the recent whitebox test additions into my change and >>>>> added >>>>> the missing copyright headers. >>>>> Here's the latest and greatest webrev: >>>>> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.2/ >>>>> >>>>> I've also ran these tests with jprt -retest to see that the new >>>>> variant >>>>> works on different platforms. >>>>> >>>>> When doing the change to PrintNMTStatistics.java I discovered that the >>>>> test was in fact only compiled with javac and not run, and in fact >>>>> needed further updates to work properly. I filed a bug for that test >>>>> and >>>>> updated it to compile the java sources using the new scheme. >>>>> >>>>> /Mikael >>>>> >>>>> On 02/06/2013 07:55 PM, Vladimir Kozlov wrote: >>>>>> On 2/6/13 10:16 AM, Mikael Gerdin wrote: >>>>>>> Vladimir, >>>>>>> >>>>>>> On 2013-02-06 17:30, Vladimir Kozlov wrote: >>>>>>>> Mikael, >>>>>>>> >>>>>>>> I like that all WB functionality is moved to test directory. >>>>>>>> >>>>>>>> You missed Copyright header in all new files. >>>>>>> >>>>>>> Thanks for the reminder, I'm not used to creating new files :) >>>>>> >>>>>> I still don't see it in DiagnosticCommand.java. Also old files >>>>>> WBApi.java and ParserTest.java do not have it. >>>>>> >>>>>> Mikael, we need Copyright header in all files we push into open >>>>>> sources. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>>> >>>>>>>> Could you rename ClassFileDumper to ClassFileInstaller? It will be >>>>>>>> more >>>>>>>> clear what it does. >>>>>>> >>>>>>> Done. Updated webrev at: >>>>>>> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.1/ >>>>>>> >>>>>>> /Mikael >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 2/4/13 5:59 AM, Mikael Gerdin wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Background: >>>>>>>>> Even from the beginning of the WhiteBox testing API implementation >>>>>>>>> the >>>>>>>>> tests have not worked on builds promoted by release engineering >>>>>>>>> due to >>>>>>>>> the fact that the wb.jar file containing the Java classes was not >>>>>>>>> imported by the JDK-level makefiles. >>>>>>>>> On one level this was ok since we didn't want to ship the >>>>>>>>> classes to >>>>>>>>> end >>>>>>>>> users and we worked around the complexity of somehow >>>>>>>>> post-processing >>>>>>>>> the >>>>>>>>> RE bundles to remove them. >>>>>>>>> >>>>>>>>> The problem is that we aren't able to run the WhiteBox tests in >>>>>>>>> promotion testing, or to verify fixes against earlier builds. >>>>>>>>> >>>>>>>>> Solution: >>>>>>>>> The solution suggested here is to put the WhiteBox helper >>>>>>>>> classes in >>>>>>>>> the >>>>>>>>> testlibrary directory under test/ and >>>>>>>>> * tell jtreg to first compile the classes >>>>>>>>> * run a special Java program to copy the classes to the test work >>>>>>>>> directory >>>>>>>>> * run the white box test with -Xbootclasspath/a:. to pick up the >>>>>>>>> copied >>>>>>>>> classes. >>>>>>>>> >>>>>>>>> The solution is kind-of hackish but I've been unable to come up >>>>>>>>> with a >>>>>>>>> better solution without performing complex surgery on jtreg. >>>>>>>>> >>>>>>>>> The changes to the make/ directory should basically revert the >>>>>>>>> makefile >>>>>>>>> changes that were added to support this API. >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~mgerdin/8006753/webrev.0/ >>>>>>>>> Bug: >>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006753 >>>>>>>>> >>>>>>>>> Note about renamed/moved files: >>>>>>>>> I will try to make sure that the moved/renamed files will be >>>>>>>>> tracked >>>>>>>>> properly by mercurial, but I think that using patch files and MQ >>>>>>>>> breaks >>>>>>>>> this so I'll do this after the review is done. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> /Mikael >>>>> From john.r.rose at oracle.com Tue Feb 19 13:05:51 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 19 Feb 2013 13:05:51 -0800 Subject: Bug 100297 - [patch] fix name clash of assert macro in debug.hpp with libc's assert macro In-Reply-To: References: Message-ID: <8DA26308-F698-4399-9302-D01C48D0E2D4@oracle.com> On Feb 19, 2013, at 7:55 AM, P?ter Radics wrote: > it would be worthwhile fixing this issue. I added the following text to bug 8007770, which gives reasons not to take this action: > I count about 15,000 occurrences of assert in our sources. > The proposed rename would therefore be a disruptive change. > Patches and change sets would no longer apply across that change, leading to maintenance costs, especially back-porting bug fixes. > Thus, a mere claim of "would be prudent to conform exactly to the standard" is not enough grounds to accept this change. > > Since 'assert' macros are common programming practice, we can expect (or request, if necessary) that the C++ standard libraries provide an op-out mechanism, such as '#undef assert' or '-DNDEBUG'. > > For a reference on NDEBUG, see: http://www.cplusplus.com/reference/cassert/assert/ ? John From christian.thalinger at oracle.com Tue Feb 19 13:56:35 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 19 Feb 2013 13:56:35 -0800 Subject: 8007770: fix name clash of assert macro in debug.hpp with libc's assert macro [Was: Re: Bug 100297 - [patch] fix name clash of assert macro in debug.hpp with libc's assert macro] In-Reply-To: References: Message-ID: <152FA772-A91D-42C5-BF24-4B6B9860517A@oracle.com> [David already filed an RFE for this: 8007770: fix name clash of assert macro in debug.hpp with libc's assert macro] On Feb 19, 2013, at 7:55 AM, P?ter Radics wrote: > Hello, > > hotspot/src/share/vm/utilities/debug.hpp defines an assert macro with two > parameters. This macro definition clashes with libc's assert macro from > (and to the best of my knowledge it's undefined behavior to > redefine > assert like this). > > The name clash causes build failures if any of the files using debug.hpp > directly or indirectly include (or ), too. > > This doesn't seem to happen with libstdc++ (yet?), but this error is > triggered if > trying to build with libc++ (http://libcxx.llvm.org). > > I propose changing the name of the assert macro defined in debug.hpp to > assert_vm (based on the fact that this macro is used solely in the vm > subsystem). > > I've created a set of patches and attached it to issue 100297: > https://bugs.openjdk.java.net/show_bug.cgi?id=100297 > > > I believe libc++ will be used by more and more systems in the near future > (as far as I > know FreeBSD is planning to include it as the default c++ lib in a coming > release), so > it would be worthwhile fixing this issue. That's an interesting point and it's something that will bite us eventually. I would suggest to rename it to ASSERT since it's actually a macro. -- Chris > > cheers, > mitch From jon.masamitsu at oracle.com Tue Feb 19 14:17:05 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 19 Feb 2013 14:17:05 -0800 Subject: NUMA-Aware Java Heaps for in-memory databases In-Reply-To: References: Message-ID: <5123F9E1.8020900@oracle.com> On 02/13/13 05:42, Antoine Chambille wrote: > We are developing a Java in-memory analytical database (it's called > "ActivePivot") that our customers deploy on ever larger datasets. Some > ActivePivot instances are deployed on java heaps close to 1TB, on NUMA > servers (typically 4 Xeon processors and 4 NUMA nodes). This is becoming a > trend, and we are researching solutions to improve our performance on NUMA > configurations. > > > We understand that in the current state of things (and including JDK8) the > support for NUMA in hotspot is the following: > * The young generation heap layout can be NUMA-Aware (partitioned per NUMA > node, objects allocated in the same node than the running thread) > * The old generation heap layout is not optimized for NUMA (at best the old > generation is interleaved among nodes which at least makes memory accesses > somewhat uniform) > * The parallel garbage collector is NUMA optimized, the GC threads focusing > on objects in their node. This last part is not true. GC threads do not focus on objects on their node. > Yet activating -XX:+UseNUMA option has almost no impact on the performance > of our in-memory database. It is not surprising, the pattern for a database > is to load the data in the memory and then make queries on it. The data > goes and stays in the old generation, and it is read from there by queries. > Most memory accesses are in the old gen and most of those are not local. > > I guess there is a reason hotspot does not yet optimize the old generation > for NUMA. It must be very difficult to do it in the general case, when you > have no idea what thread from what node will read data and interleaving is. > But for an in-memory database this is frustrating because we know very well > which threads will access which piece of data. At least in ActivePivot data > structures are partitioned, partitions are each assigned a thread pool so > the threads that allocated the data in a partition are also the threads > that perform sub-queries on that partition. We are a few lines of code away > from binding thread pools to NUMA nodes, and if the garbage collector would > leave objects promoted to the old generation on their original NUMA node > memory accesses would be close to optimal. > > We have not been able to do that. But that being said I read an inspiring > 2005 article from Mustafa M. Tikir and Jeffrey K. Hollingsworth that did > experiment on NUMA layouts for the old generation. ("NUMA-aware Java heaps > for server applications" > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.6587&rep=rep1&type=pdf). > That motivated me to ask questions in this mailing list: > > > * Are there hidden or experimental hotspot options that allow NUMA-Aware > partitioning of the old generation? > * Do you know why there isn't much (visible, generally available) progress > on NUMA optimizations for the old gen? Is the Java in-memory database use > case considered a rare one? Development does not make decisions about what feature/enhancements we implement. We have a product management team that talks to customers and proposes projects to development. I'll forward your mail to them if you like. > * Maybe we at Quartet FS should experiment and even contribute new heap > layouts to the open-jdk project. Can you comment on the difficulty of that? So for your case you would want the data allocated to a region of the young generation on node XX to be promoted to a region of the old generation on XX. I think doing this would require 1) Partition the old gen into regions OXX that would have the OXX's memory on a particular node (easy) 2) A strategy for moving the right objects into OXX's. The young gen GC's do the copying of the objects from the young gen to the old gen. You know that you want the objects in NXX (region in young gen on node XX), but our young gen GC's would not just copy live objects from NXX to OXX. The young gen GC's start from the roots (references to objects) held by each thread (e.g., reference to an object on the thread's stack) and copies all objects reachable from the roots (i.e., referenced from the roots so can used by the application thread so is live) to the old gen. I can think of ways to do this but don't know how effective they would be. Would need some experimentation so I would say hard. 3) Changing the old GC to understand that the old gen is divided into regions OXX and to keep the objects in an OXX in the same OXX. I think we know how to do this but there would have to be lots of code changes so not easy. 4) Maybe a strategy for dynamically sizing the OXX in case some OXX have more live data that others. Plus a strategy for overflowing an OXX. Simplest thing would be to do a full GC but that might happen too often. Jon > Thanks for reading, and Best Regards, > > -- > Antoine CHAMBILLE > Director Research & Development > Quartet FS From david.holmes at oracle.com Tue Feb 19 16:51:51 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Feb 2013 10:51:51 +1000 Subject: RFR (S): 8008314 - Unimplemented() Atomic::load breaks the applications In-Reply-To: <5123AF1E.2020603@oracle.com> References: <51231AE7.9070206@oracle.com> <512332FB.7020600@oracle.com> <51235162.9030702@oracle.com> <51236461.7060101@oracle.com> <51237589.4030105@oracle.com> <5123AF1E.2020603@oracle.com> Message-ID: <51241E27.7040408@oracle.com> On 20/02/2013 2:58 AM, Jesper Wilhelmsson wrote: > Hi, > > The counter that is protected by the atomic add is only used to decide > when to switch to the next file in the rotating log file scheme. Even > with the atomic add it is not an exact limit since we only check the > limt at a sefepoint and we will always write a whole log message at a time. > > I ran several tests with most GC logging turned on with and without the > atomic add and I see no significant difference in the sizes of the log > files. > > I have a new patch where I remove the atomic add: > > HS24: http://cr.openjdk.java.net/~jwilhelm/8008314/webrev.2.hs24/ > HS25: http://cr.openjdk.java.net/~jwilhelm/8008314/webrev.2.hs25/ > > Let me know if you feel confident in pushing this. I have no problem with this. Thanks, David > /Jesper > > > On 19/2/13 1:52 PM, Bengt Rutisson wrote: >> On 2/19/13 12:39 PM, David Holmes wrote: >>> I'm also indebted to Bengt for spotting that - hadn't realized the >>> 'x' types >>> were intptr_t typedefs. >>> >>> But backing up a step, this code is not obviously thread-safes, or if >>> it is it >>> must be by a lock at a higher level - so why do we need an atomic >>> update of >>> the _bytes_written value? >> >> Yes, this is something we discussed at lunch today. It looks like calling >> update_position() without some kind of locking is unsafe. This is not >> introduced >> only by the rotatingFileStream. All the outputStream implmentations >> does this. >> Looks scary to me. I don't really understand how this works in a safe >> way. Maybe >> it doesn't. >> >> We are not doing any locking higher up in the call chain as far as I >> can see. >> >> Bengt >> >>> >>> David >>> >>> On 19/02/2013 8:18 PM, Jesper Wilhelmsson wrote: >>>> Bengt, >>>> >>>> Thanks for catching this! I should listen to Ted's mother, nothing good >>>> happens after 2am[1]. >>>> >>>> I wasn't aware that jint was 32-bit on all platforms. Using 32-bit >>>> atomic add like this won't work, back to the drawing board. >>>> >>>> The one quick solution I can think of right now that won't be awful >>>> would be to limit GcLogFileSize to 32 bit. I'm not sure how quick a fix >>>> it will be though since it may require a CCC approval... >>>> >>>> /Jesper >>>> >>>> >>>> [1] http://en.wikipedia.org/wiki/Nothing_Good_Happens_After_2_A.M. >>>> >>>> >>>> On 19/2/13 9:08 AM, Bengt Rutisson wrote: >>>>> >>>>> Hi Jesper, >>>>> >>>>> Thanks for fixing this! I don't feel very comfortable with this code, >>>>> so don't >>>>> consider this a full review. Just a couple of comments: >>>>> >>>>> It seems to make sense to use uintx for _bytes_written since the flag >>>>> to control >>>>> the file size, GCLogFileSize, is uintx. But since the atomics you >>>>> use are >>>>> handling jint I think it looks a bit suspicious. jint is always 32 >>>>> bits and >>>>> uintx can be 32 or 64 bit. So, what happens here if _bytes_written is >>>>> 64 bit? >>>>> >>>>> 457 Atomic::add((jint)count, (jint*)&_bytes_written); >>>>> >>>>> If _bytes_written is 0x00000000FFFFFFFF and count is 1, I would guess >>>>> that we >>>>> get 0x0 instead of 0x0000000100000000. >>>>> >>>>> Also, in rotatingFileStream::rotate_log() you changed to: >>>>> >>>>> if (_bytes_written <= GCLogFileSize) return; >>>>> >>>>> instead of : >>>>> >>>>> if (_bytes_writen < (jlong)GCLogFileSize) return; >>>>> >>>>> isn't this a problem since you set _bytes_written to UINT_MAX if we >>>>> wrap around? >>>>> If someone sets GCLogFileSize on the command line to be UINT_MAX we >>>>> will never >>>>> rotate the file, right? >>>>> >>>>> Also, we only call rotate_log() when we start a safepoint. If we wrap >>>>> around >>>>> once in write() but then call it again before a safepoint happens >>>>> we can >>>>> probably set _bytes_written to a value that looks small enough to not >>>>> have to >>>>> rotate the log. It seems to me that we would need a separate flag to >>>>> say that we >>>>> written enough to rotate the log. >>>>> >>>>> Bengt >>>>> >>>>> >>>>> >>>>> On 2/19/13 7:25 AM, Jesper Wilhelmsson wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the following change: >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8008314/ >>>>>> >>>>>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8008314 >>>>>> >>>>>> >>>>>> The use of atomic::add(jlong,jlong*) breaks everything on ARM since >>>>>> it uses >>>>>> atomic::load(jlong) which isn't implemented. >>>>>> >>>>>> The add was used to update a counter in rotating log file handling, >>>>>> but it >>>>>> turns out that the counter that was updated doesn't need to be a >>>>>> jlong. >>>>>> >>>>>> The counter is used to indicate that it is time to do a log file >>>>>> rotation and >>>>>> by adding a saftey catch for overflow, we can use an uintx for the >>>>>> counter. >>>>>> >>>>>> In practice this means that the upper "limit" for the log file size >>>>>> becomes >>>>>> UINX_MAX-1 (used to be UINT_MAX) since I change from < to <= in the >>>>>> comparison >>>>>> to the limit, but since this is not a hard limit the difference will >>>>>> only be >>>>>> noticeable when someone has written UINT_MAX characters to the log >>>>>> file and >>>>>> the next write will end up in the next log file part instead of in >>>>>> the same >>>>>> (which one could argue is a more correct behavior). >>>>>> >>>>>> Sine I changed all places where the counter was used I also fixed a >>>>>> typo in >>>>>> its name. >>>>>> >>>>>> Thanks, >>>>>> /Jesper >>>>> >> From david.holmes at oracle.com Tue Feb 19 16:53:33 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Feb 2013 10:53:33 +1000 Subject: RFR: JDK-8007804: Need to be able to access Performance counter by name from JVM In-Reply-To: <512375A4.6070301@oracle.com> References: <51152A60.8000004@oracle.com> <5115B0B5.9030004@oracle.com> <51235D5E.6010103@oracle.com> <512375A4.6070301@oracle.com> Message-ID: <51241E8D.50308@oracle.com> Thanks Nils. Looks good to me too. David On 19/02/2013 10:52 PM, Nils Loodin wrote: > Here's the updated webrev: > > http://cr.openjdk.java.net/~nloodin/8007804/webrev.01/ > > Regards, > Nils Loodin > > On 02/19/2013 12:09 PM, Nils Loodin wrote: >> On 02/09/2013 03:13 AM, David Holmes wrote: >>> On 9/02/2013 2:40 AM, Nils Loodin wrote: >>>> Please review the following very small and insignificant change: >>>> Basically, I need to access a performance-counter by name from within >>>> the JVM. >>> >>> The method name by_name seems a little odd to me. find_by_name would >>> seem more consistent (particularly if you consider the strange >>> PerfDataList::by_name method - which compares names) >> >> >> I think you're right. I'll rename it to find_by_name instead and send >> out another webrev. >> >> Nisse >> >>> >>> David >>> >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007804 >>>> http://cr.openjdk.java.net/~nloodin/8007804/webrev.00/ >>>> >>>> Regards, >>>> Nils Loodin >>>> >>>> >> > From david.holmes at oracle.com Tue Feb 19 18:44:55 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Feb 2013 12:44:55 +1000 Subject: 8007770: fix name clash of assert macro in debug.hpp with libc's assert macro [Was: Re: Bug 100297 - [patch] fix name clash of assert macro in debug.hpp with libc's assert macro] In-Reply-To: <152FA772-A91D-42C5-BF24-4B6B9860517A@oracle.com> References: <152FA772-A91D-42C5-BF24-4B6B9860517A@oracle.com> Message-ID: <512438A7.9050107@oracle.com> On 20/02/2013 7:56 AM, Christian Thalinger wrote: > [David already filed an RFE for this: > > 8007770: fix name clash of assert macro in debug.hpp with libc's assert macro] Yes. For the record it is only undefined behaviour if you suppress the assert macro and re-define it as a function - which we do not do. John Rose also added the following to the bug report: "I count about 15,000 occurrences of assert in our sources. The proposed rename would therefore be a disruptive change. Patches and change sets would no longer apply across that change, leading to maintenance costs, especially back-porting bug fixes. Thus, a mere claim of "would be prudent to conform exactly to the standard" is not enough grounds to accept this change. Since 'assert' macros are common programming practice, we can expect (or request, if necessary) that the C++ standard libraries provide an op-out mechanism, such as '#undef assert' or '-DNDEBUG'. For a reference on NDEBUG, see: http://www.cplusplus.com/reference/cassert/assert/ (To be clear, NDEBUG does not remove the macro. Another option would be required, if #undef is not allowed.) " --- If this is potentially a problem then I think we need to avoid it by other means - most likely by bracketing standard includes with "#undef assert" so that they are not affected by hotspot's definition, and our source is not affected by the definition from assert.h David ----- > On Feb 19, 2013, at 7:55 AM, P?ter Radics wrote: > >> Hello, >> >> hotspot/src/share/vm/utilities/debug.hpp defines an assert macro with two >> parameters. This macro definition clashes with libc's assert macro from >> (and to the best of my knowledge it's undefined behavior to >> redefine >> assert like this). >> >> The name clash causes build failures if any of the files using debug.hpp >> directly or indirectly include (or ), too. >> >> This doesn't seem to happen with libstdc++ (yet?), but this error is >> triggered if >> trying to build with libc++ (http://libcxx.llvm.org). >> >> I propose changing the name of the assert macro defined in debug.hpp to >> assert_vm (based on the fact that this macro is used solely in the vm >> subsystem). >> >> I've created a set of patches and attached it to issue 100297: >> https://bugs.openjdk.java.net/show_bug.cgi?id=100297 >> >> >> I believe libc++ will be used by more and more systems in the near future >> (as far as I >> know FreeBSD is planning to include it as the default c++ lib in a coming >> release), so >> it would be worthwhile fixing this issue. > > That's an interesting point and it's something that will bite us eventually. I would suggest to rename it to ASSERT since it's actually a macro. > > -- Chris > >> >> cheers, >> mitch > From dean.long at oracle.com Tue Feb 19 19:54:33 2013 From: dean.long at oracle.com (Dean Long) Date: Tue, 19 Feb 2013 19:54:33 -0800 Subject: RFR (S): 8008314 - Unimplemented() Atomic::load breaks the applications In-Reply-To: <5123AF1E.2020603@oracle.com> References: <51231AE7.9070206@oracle.com> <512332FB.7020600@oracle.com> <51235162.9030702@oracle.com> <51236461.7060101@oracle.com> <51237589.4030105@oracle.com> <5123AF1E.2020603@oracle.com> Message-ID: <512448F9.6050609@oracle.com> How about using "if (count() < (jlong)GCLogFileSize)" and "set_position(0);set_count(0);" in rotate_log(), then removing_bytes_written? However be aware that count() grows even when _file == NULL, because write() calls update_position() unconditionally. dl On 2/19/2013 8:58 AM, Jesper Wilhelmsson wrote: > Hi, > > The counter that is protected by the atomic add is only used to decide > when to switch to the next file in the rotating log file scheme. Even > with the atomic add it is not an exact limit since we only check the > limt at a sefepoint and we will always write a whole log message at a > time. > > I ran several tests with most GC logging turned on with and without > the atomic add and I see no significant difference in the sizes of the > log files. > > I have a new patch where I remove the atomic add: > > HS24: http://cr.openjdk.java.net/~jwilhelm/8008314/webrev.2.hs24/ > HS25: http://cr.openjdk.java.net/~jwilhelm/8008314/webrev.2.hs25/ > > Let me know if you feel confident in pushing this. > /Jesper > > > On 19/2/13 1:52 PM, Bengt Rutisson wrote: >> On 2/19/13 12:39 PM, David Holmes wrote: >>> I'm also indebted to Bengt for spotting that - hadn't realized the >>> 'x' types >>> were intptr_t typedefs. >>> >>> But backing up a step, this code is not obviously thread-safes, or >>> if it is it >>> must be by a lock at a higher level - so why do we need an atomic >>> update of >>> the _bytes_written value? >> >> Yes, this is something we discussed at lunch today. It looks like >> calling >> update_position() without some kind of locking is unsafe. This is not >> introduced >> only by the rotatingFileStream. All the outputStream implmentations >> does this. >> Looks scary to me. I don't really understand how this works in a safe >> way. Maybe >> it doesn't. >> >> We are not doing any locking higher up in the call chain as far as I >> can see. >> >> Bengt >> >>> >>> David >>> >>> On 19/02/2013 8:18 PM, Jesper Wilhelmsson wrote: >>>> Bengt, >>>> >>>> Thanks for catching this! I should listen to Ted's mother, nothing >>>> good >>>> happens after 2am[1]. >>>> >>>> I wasn't aware that jint was 32-bit on all platforms. Using 32-bit >>>> atomic add like this won't work, back to the drawing board. >>>> >>>> The one quick solution I can think of right now that won't be awful >>>> would be to limit GcLogFileSize to 32 bit. I'm not sure how quick a >>>> fix >>>> it will be though since it may require a CCC approval... >>>> >>>> /Jesper >>>> >>>> >>>> [1] http://en.wikipedia.org/wiki/Nothing_Good_Happens_After_2_A.M. >>>> >>>> >>>> On 19/2/13 9:08 AM, Bengt Rutisson wrote: >>>>> >>>>> Hi Jesper, >>>>> >>>>> Thanks for fixing this! I don't feel very comfortable with this code, >>>>> so don't >>>>> consider this a full review. Just a couple of comments: >>>>> >>>>> It seems to make sense to use uintx for _bytes_written since the flag >>>>> to control >>>>> the file size, GCLogFileSize, is uintx. But since the atomics you >>>>> use are >>>>> handling jint I think it looks a bit suspicious. jint is always 32 >>>>> bits and >>>>> uintx can be 32 or 64 bit. So, what happens here if _bytes_written is >>>>> 64 bit? >>>>> >>>>> 457 Atomic::add((jint)count, (jint*)&_bytes_written); >>>>> >>>>> If _bytes_written is 0x00000000FFFFFFFF and count is 1, I would guess >>>>> that we >>>>> get 0x0 instead of 0x0000000100000000. >>>>> >>>>> Also, in rotatingFileStream::rotate_log() you changed to: >>>>> >>>>> if (_bytes_written <= GCLogFileSize) return; >>>>> >>>>> instead of : >>>>> >>>>> if (_bytes_writen < (jlong)GCLogFileSize) return; >>>>> >>>>> isn't this a problem since you set _bytes_written to UINT_MAX if we >>>>> wrap around? >>>>> If someone sets GCLogFileSize on the command line to be UINT_MAX we >>>>> will never >>>>> rotate the file, right? >>>>> >>>>> Also, we only call rotate_log() when we start a safepoint. If we wrap >>>>> around >>>>> once in write() but then call it again before a safepoint happens >>>>> we can >>>>> probably set _bytes_written to a value that looks small enough to not >>>>> have to >>>>> rotate the log. It seems to me that we would need a separate flag to >>>>> say that we >>>>> written enough to rotate the log. >>>>> >>>>> Bengt >>>>> >>>>> >>>>> >>>>> On 2/19/13 7:25 AM, Jesper Wilhelmsson wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the following change: >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8008314/ >>>>>> >>>>>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8008314 >>>>>> >>>>>> >>>>>> The use of atomic::add(jlong,jlong*) breaks everything on ARM since >>>>>> it uses >>>>>> atomic::load(jlong) which isn't implemented. >>>>>> >>>>>> The add was used to update a counter in rotating log file handling, >>>>>> but it >>>>>> turns out that the counter that was updated doesn't need to be a >>>>>> jlong. >>>>>> >>>>>> The counter is used to indicate that it is time to do a log file >>>>>> rotation and >>>>>> by adding a saftey catch for overflow, we can use an uintx for the >>>>>> counter. >>>>>> >>>>>> In practice this means that the upper "limit" for the log file size >>>>>> becomes >>>>>> UINX_MAX-1 (used to be UINT_MAX) since I change from < to <= in the >>>>>> comparison >>>>>> to the limit, but since this is not a hard limit the difference will >>>>>> only be >>>>>> noticeable when someone has written UINT_MAX characters to the log >>>>>> file and >>>>>> the next write will end up in the next log file part instead of in >>>>>> the same >>>>>> (which one could argue is a more correct behavior). >>>>>> >>>>>> Sine I changed all places where the counter was used I also fixed a >>>>>> typo in >>>>>> its name. >>>>>> >>>>>> Thanks, >>>>>> /Jesper >>>>> >> From dean.long at oracle.com Tue Feb 19 22:33:29 2013 From: dean.long at oracle.com (Dean Long) Date: Tue, 19 Feb 2013 22:33:29 -0800 Subject: 8007770: fix name clash of assert macro in debug.hpp with libc's assert macro [Was: Re: Bug 100297 - [patch] fix name clash of assert macro in debug.hpp with libc's assert macro] In-Reply-To: <512438A7.9050107@oracle.com> References: <152FA772-A91D-42C5-BF24-4B6B9860517A@oracle.com> <512438A7.9050107@oracle.com> Message-ID: <51246E39.2070402@oracle.com> On 2/19/2013 6:44 PM, David Holmes wrote: > On 20/02/2013 7:56 AM, Christian Thalinger wrote: >> [David already filed an RFE for this: >> >> 8007770: fix name clash of assert macro in debug.hpp with libc's >> assert macro] > > Yes. For the record it is only undefined behaviour if you suppress the > assert macro and re-define it as a function - which we do not do. > > John Rose also added the following to the bug report: > > "I count about 15,000 occurrences of assert in our sources. > The proposed rename would therefore be a disruptive change. > Patches and change sets would no longer apply across that change, > leading to maintenance costs, especially back-porting bug fixes. > Thus, a mere claim of "would be prudent to conform exactly to the > standard" is not enough grounds to accept this change. > > Since 'assert' macros are common programming practice, we can expect > (or request, if necessary) that the C++ standard libraries provide an > op-out mechanism, such as '#undef assert' or '-DNDEBUG'. > > For a reference on NDEBUG, see: > http://www.cplusplus.com/reference/cassert/assert/ > > (To be clear, NDEBUG does not remove the macro. Another option would > be required, if #undef is not allowed.) " > > --- > > If this is potentially a problem then I think we need to avoid it by > other means - most likely by bracketing standard includes with "#undef > assert" so that they are not affected by hotspot's definition, and our > source is not affected by the definition from assert.h > Can't we just do something like the following in debug.hpp? #include #undef assert #define assert(p, msg) \ ... Any #include that happens after this should be a no-op because it was already included once. dl > David > ----- From david.holmes at oracle.com Tue Feb 19 23:50:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Feb 2013 17:50:07 +1000 Subject: 8007770: fix name clash of assert macro in debug.hpp with libc's assert macro [Was: Re: Bug 100297 - [patch] fix name clash of assert macro in debug.hpp with libc's assert macro] In-Reply-To: <51246E39.2070402@oracle.com> References: <152FA772-A91D-42C5-BF24-4B6B9860517A@oracle.com> <512438A7.9050107@oracle.com> <51246E39.2070402@oracle.com> Message-ID: <5124802F.3060202@oracle.com> On 20/02/2013 4:33 PM, Dean Long wrote: > On 2/19/2013 6:44 PM, David Holmes wrote: >> If this is potentially a problem then I think we need to avoid it by >> other means - most likely by bracketing standard includes with "#undef >> assert" so that they are not affected by hotspot's definition, and our >> source is not affected by the definition from assert.h >> > > Can't we just do something like the following in debug.hpp? > > #include > #undef assert > #define assert(p, msg) \ > ... > > Any #include that happens after this should be a no-op > because it was already included once. Not true for assert.h. Every individual include of assert.h can be modified by setting NDEBUG, so assert.h does not use the "#ifndef _ASSERT_H" trick to only process the file once. Plus if a standard header includes assert.h and uses assert, we probably don't want it to use the VM's assert. That said if we use the C libraries assert it probably won't work nicely with the VM. So we would probably need #undef assert #define NDEBUG #include #undef NDEBUG #undef assert David > dl > >> David >> ----- > From mitchnull at gmail.com Tue Feb 19 23:58:22 2013 From: mitchnull at gmail.com (=?ISO-8859-1?Q?P=E9ter_Radics?=) Date: Wed, 20 Feb 2013 08:58:22 +0100 Subject: 8007770: fix name clash of assert macro in debug.hpp with libc's assert macro [Was: Re: Bug 100297 - [patch] fix name clash of assert macro in debug.hpp with libc's assert macro] In-Reply-To: <51246E39.2070402@oracle.com> References: <152FA772-A91D-42C5-BF24-4B6B9860517A@oracle.com> <512438A7.9050107@oracle.com> <51246E39.2070402@oracle.com> Message-ID: On Wed, Feb 20, 2013 at 7:33 AM, Dean Long wrote: > On 2/19/2013 6:44 PM, David Holmes wrote: > >> On 20/02/2013 7:56 AM, Christian Thalinger wrote: >> >>> [David already filed an RFE for this: >>> >>> 8007770: fix name clash of assert macro in debug.hpp with libc's assert >>> macro] >>> >> >> Yes. For the record it is only undefined behaviour if you suppress the >> assert macro and re-define it as a function - which we do not do. >> >> John Rose also added the following to the bug report: >> >> "I count about 15,000 occurrences of assert in our sources. >> The proposed rename would therefore be a disruptive change. >> Patches and change sets would no longer apply across that change, leading >> to maintenance costs, especially back-porting bug fixes. >> Thus, a mere claim of "would be prudent to conform exactly to the >> standard" is not enough grounds to accept this change. >> >> Since 'assert' macros are common programming practice, we can expect (or >> request, if necessary) that the C++ standard libraries provide an op-out >> mechanism, such as '#undef assert' or '-DNDEBUG'. >> >> For a reference on NDEBUG, see: >> http://www.cplusplus.com/reference/cassert/assert/ >> >> (To be clear, NDEBUG does not remove the macro. Another option would be >> required, if #undef is not allowed.) " >> >> --- >> >> If this is potentially a problem then I think we need to avoid it by >> other means - most likely by bracketing standard includes with "#undef >> assert" so that they are not affected by hotspot's definition, and our >> source is not affected by the definition from assert.h >> >> > Can't we just do something like the following in debug.hpp? > > #include > #undef assert > #define assert(p, msg) \ > ... > > Any #include that happens after this should be a no-op because > it was already included once. > > dl > > David >> ----- >> > Unfortunately that doesn't work, as may be included multiple times by design, even with different NDEBUG settings. Regarding the 15k occurrences of assert: yes, it's unfortunate, and it is a disruptive change, but other workarounds (such as the one attempted with shark/llvmHeaders.hpp) are ugly and brittle, so in my opinion this one-time disruption should be accepted. Incoming patches could be pre-processed with a script like the one I attached to the bug report in the transition-period, but I think most repos will pick up the change within a reasonable time. The other options is to try convincing the libc++ devs to not use a perfectly valid way of using the standard assert facilities... cheers, mitch From rkennke at redhat.com Wed Feb 20 00:45:04 2013 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 20 Feb 2013 09:45:04 +0100 Subject: 8008243: Zero: implement fast-bytecodes [Was: Re: [RFC] Fast-bytecodes for Zero] In-Reply-To: <259E154F-3718-486B-A06F-CBA9C1A186B2@oracle.com> References: <1360784420.2524.31.camel@mercury> <511DE2EF.9090106@oracle.com> <1360923721.6566.20.camel@mercury> <259E154F-3718-486B-A06F-CBA9C1A186B2@oracle.com> Message-ID: <1361349904.19150.6.camel@mercury> Am Montag, den 18.02.2013, 12:30 -0800 schrieb Christian Thalinger: > On Feb 15, 2013, at 6:39 AM, Vitaly Davidovich wrote: > > > Hi Roman, > > > > One suggestion I have is to add functions to JvmtiExport like has_field_access_watchers() and change this accordingly: > > > > count_addr = (int *)JvmtiExport::get_field_access_count_addr(); \ > > 436 if ( *count_addr > 0 ) { > > > > The has_XXX function can simply have that code inside. > > > > Reason I think it's useful is because the field is an int but the get_* function declares address as return type requiring you to cast and thus know internal representation. Seems cleaner to encapsulate inside JvmtiExport? > > I agree on that but that would be beyond the scope of this change. Roman only moved the code into a macro so he can reuse it in multiple places. Actually I would prefer to move the code into a method because that would make the huge method a little smaller. I agree with both of you. :-) I also tried to move this code into separate methods. However, this seems to be very difficult, because the CALL_VM macro depends on a lot of variables local to the interpreter loop: cp, locals, cache, thread, topOfStack, pc, istate and handle_exception, handle_Pop_frame (goto-labels). Yes, it is possible to somehow pass everything into such a method, but this seems awkward. I am not sure what is the lesser evil here. Roman > > -- Chris > > > > > Thanks > > > > Sent from my phone > > > > On Feb 15, 2013 5:23 AM, "Roman Kennke" wrote: > > Hi David, > > > > Am Freitag, den 15.02.2013, 17:25 +1000 schrieb David Holmes: > > > There's a lot of changes to shared code here - what is the impact on > > > non-zero platforms? > > > > The changes to shared code are in bytecodeInterpreter.cpp, which is, to > > my knowledge, only used by Zero. *If* there are other interpreters that > > use it (maybe in closed trees?) they would most likely just pick up and > > benefit from the improvements. But of course, I cannot tell... > > > > Regards, > > Roman > > > > > Thanks, > > > David > > > > > > On 15/02/2013 4:51 AM, Christian Thalinger wrote: > > > > I've filed: > > > > > > > > 8008243: Zero: implement fast-bytecodes > > > > > > > > -- Chris > > > > > > > > On Feb 13, 2013, at 11:40 AM, Roman Kennke wrote: > > > > > > > >> The following change implements support for the following fast-bytecodes > > > >> in the Zero interpreter: > > > >> > > > >> fast_agetfield > > > >> fast_bgetfield > > > >> fast_cgetfield > > > >> fast_dgetfield > > > >> fast_fgetfield > > > >> fast_igetfield > > > >> fast_lgetfield > > > >> fast_sgetfield > > > >> fast_aputfield > > > >> fast_bputfield > > > >> fast_cputfield > > > >> fast_dputfield > > > >> fast_fputfield > > > >> fast_iputfield > > > >> fast_lputfield > > > >> fast_sputfield > > > >> fast_aload_0 > > > >> fast_iaccess_0 > > > >> fast_aaccess_0 > > > >> fast_faccess_0 > > > >> fast_iload > > > >> fast_iload2 > > > >> fast_icaload > > > >> fast_invokevfinal > > > >> > > > >> All together this leads to a speedup of the interpreter of about 25%. > > > >> > > > >> Some notes: > > > >> - I extracted the JVMTI related blocks into a macro to avoid repetition. > > > >> - The field get/put opcodes are only rewritten for non-volatile > > > >> non-static field access, this makes the fast one really fast (no > > > >> additional branches needed), and static/volatile field accesses seem > > > >> rare enough anyway. > > > >> > > > >> http://cr.openjdk.java.net/~rkennke/zero-fast-opcodes/webrev.00/ > > > >> > > > >> > > > >> Opinions? Can this be included in hotspot? And Can I have a bug-ID? > > > >> > > > >> Best regards, > > > >> Roman > > > >> > > > >> > > > > > > > > > From ach at quartetfs.com Wed Feb 20 01:12:01 2013 From: ach at quartetfs.com (Antoine Chambille) Date: Wed, 20 Feb 2013 10:12:01 +0100 Subject: NUMA-Aware Java Heaps for in-memory databases In-Reply-To: <5123F9E1.8020900@oracle.com> References: <5123F9E1.8020900@oracle.com> Message-ID: Thank you very much Jon for taking the time to understand the use case and describe the steps toward a NUMA-Partitioned old generation. I better realize the amount of work/skill that is involved and I fear it is out of reach of hotspot codebase beginners. I would appreciate to get in touch with product management if you will to give them my contact, to understand how they look at the "Java for in-memory database" use case. -Antoine On 19 February 2013 23:17, Jon Masamitsu wrote: > > > On 02/13/13 05:42, Antoine Chambille wrote: > >> We are developing a Java in-memory analytical database (it's called >> "ActivePivot") that our customers deploy on ever larger datasets. Some >> ActivePivot instances are deployed on java heaps close to 1TB, on NUMA >> servers (typically 4 Xeon processors and 4 NUMA nodes). This is becoming a >> trend, and we are researching solutions to improve our performance on NUMA >> configurations. >> >> >> We understand that in the current state of things (and including JDK8) the >> support for NUMA in hotspot is the following: >> * The young generation heap layout can be NUMA-Aware (partitioned per NUMA >> node, objects allocated in the same node than the running thread) >> * The old generation heap layout is not optimized for NUMA (at best the >> old >> generation is interleaved among nodes which at least makes memory accesses >> somewhat uniform) >> * The parallel garbage collector is NUMA optimized, the GC threads >> focusing >> on objects in their node. >> > > This last part is not true. GC threads do not focus on objects on > > their node. > > Yet activating -XX:+UseNUMA option has almost no impact on the performance >> of our in-memory database. It is not surprising, the pattern for a >> database >> is to load the data in the memory and then make queries on it. The data >> goes and stays in the old generation, and it is read from there by >> queries. >> Most memory accesses are in the old gen and most of those are not local. >> >> I guess there is a reason hotspot does not yet optimize the old generation >> for NUMA. It must be very difficult to do it in the general case, when you >> have no idea what thread from what node will read data and interleaving >> is. >> But for an in-memory database this is frustrating because we know very >> well >> which threads will access which piece of data. At least in ActivePivot >> data >> structures are partitioned, partitions are each assigned a thread pool so >> the threads that allocated the data in a partition are also the threads >> that perform sub-queries on that partition. We are a few lines of code >> away >> from binding thread pools to NUMA nodes, and if the garbage collector >> would >> leave objects promoted to the old generation on their original NUMA node >> memory accesses would be close to optimal. >> >> We have not been able to do that. But that being said I read an inspiring >> 2005 article from Mustafa M. Tikir and Jeffrey K. Hollingsworth that did >> experiment on NUMA layouts for the old generation. ("NUMA-aware Java heaps >> for server applications" >> http://citeseerx.ist.psu.edu/**viewdoc/download?doi=10.1.1.** >> 92.6587&rep=rep1&type=pdf >> ). >> That motivated me to ask questions in this mailing list: >> >> >> * Are there hidden or experimental hotspot options that allow NUMA-Aware >> partitioning of the old generation? >> * Do you know why there isn't much (visible, generally available) progress >> on NUMA optimizations for the old gen? Is the Java in-memory database use >> case considered a rare one? >> > > Development does not make decisions about what feature/enhancements > we implement. We have a product management team that talks to > customers and proposes projects to development. I'll forward your mail to > them if you like. > > > * Maybe we at Quartet FS should experiment and even contribute new heap >> layouts to the open-jdk project. Can you comment on the difficulty of >> that? >> > > So for your case you would want the data allocated to > a region of the young generation on node XX > to be promoted to a region of the old generation > on XX. > > I think doing this would require > > 1) Partition the old gen into regions OXX that > would have the OXX's memory on a particular > node (easy) > > 2) A strategy for moving the right > objects into OXX's. The young gen > GC's do the copying of the objects from the > young gen to the old gen. You know that > you want the objects in NXX (region in young > gen on node XX), but our young gen GC's > would not just copy live objects from NXX > to OXX. The young gen GC's start from the > roots (references to objects) held by each > thread (e.g., reference to an object on the > thread's stack) and copies all objects reachable > from the roots (i.e., referenced from the roots > so can used by the application thread so > is live) to the old gen. I can think of ways to > do this but don't know how effective they > would be. Would need some experimentation > so I would say hard. > > 3) Changing the old GC to understand that the > old gen is divided into regions OXX and to > keep the objects in an OXX in the same OXX. > I think we know how to do this but there > would have to be lots of code changes so > not easy. > > 4) Maybe a strategy for dynamically sizing the > OXX in case some OXX have more live data > that others. Plus a strategy for overflowing > an OXX. Simplest thing would be to do a > full GC but that might happen too often. > > Jon > > > > Thanks for reading, and Best Regards, >> >> -- >> Antoine CHAMBILLE >> Director Research & Development >> Quartet FS >> > -- Antoine CHAMBILLE Director Research & Development Quartet FS From nils.eliasson at oracle.com Wed Feb 20 03:54:07 2013 From: nils.eliasson at oracle.com (nils.eliasson at oracle.com) Date: Wed, 20 Feb 2013 11:54:07 +0000 Subject: hg: hsx/hsx24/hotspot: 8005772: Stubs report compile id -1 in phase events Message-ID: <20130220115412.C6DBF47BF2@hg.openjdk.java.net> Changeset: c8304f3d0a6c Author: neliasso Date: 2013-02-13 10:25 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c8304f3d0a6c 8005772: Stubs report compile id -1 in phase events Summary: Use 0 to indicate id is NA, -1 for error or uninitalized Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/compile.cpp From volker.simonis at gmail.com Wed Feb 20 05:28:06 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 20 Feb 2013 14:28:06 +0100 Subject: NUMA-Aware Java Heaps for in-memory databases In-Reply-To: References: Message-ID: The limitations you describe are the reason why databases implemented in Java usually use external memory (to a greater or lesser extent) to work around (mostly performance) problems of Java heap memory. There was a very interesting talk at JavaOne about how these problems are solved in Cassandra: "Dealing with JVM Limitations in Apache Cassandra" (https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=3586) Regards, Volker On Wed, Feb 13, 2013 at 2:42 PM, Antoine Chambille wrote: > We are developing a Java in-memory analytical database (it's called > "ActivePivot") that our customers deploy on ever larger datasets. Some > ActivePivot instances are deployed on java heaps close to 1TB, on NUMA > servers (typically 4 Xeon processors and 4 NUMA nodes). This is becoming a > trend, and we are researching solutions to improve our performance on NUMA > configurations. > > > We understand that in the current state of things (and including JDK8) the > support for NUMA in hotspot is the following: > * The young generation heap layout can be NUMA-Aware (partitioned per NUMA > node, objects allocated in the same node than the running thread) > * The old generation heap layout is not optimized for NUMA (at best the old > generation is interleaved among nodes which at least makes memory accesses > somewhat uniform) > * The parallel garbage collector is NUMA optimized, the GC threads focusing > on objects in their node. > > > Yet activating -XX:+UseNUMA option has almost no impact on the performance > of our in-memory database. It is not surprising, the pattern for a database > is to load the data in the memory and then make queries on it. The data > goes and stays in the old generation, and it is read from there by queries. > Most memory accesses are in the old gen and most of those are not local. > > I guess there is a reason hotspot does not yet optimize the old generation > for NUMA. It must be very difficult to do it in the general case, when you > have no idea what thread from what node will read data and interleaving is. > But for an in-memory database this is frustrating because we know very well > which threads will access which piece of data. At least in ActivePivot data > structures are partitioned, partitions are each assigned a thread pool so > the threads that allocated the data in a partition are also the threads > that perform sub-queries on that partition. We are a few lines of code away > from binding thread pools to NUMA nodes, and if the garbage collector would > leave objects promoted to the old generation on their original NUMA node > memory accesses would be close to optimal. > > We have not been able to do that. But that being said I read an inspiring > 2005 article from Mustafa M. Tikir and Jeffrey K. Hollingsworth that did > experiment on NUMA layouts for the old generation. ("NUMA-aware Java heaps > for server applications" > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.6587&rep=rep1&type=pdf). > That motivated me to ask questions in this mailing list: > > > * Are there hidden or experimental hotspot options that allow NUMA-Aware > partitioning of the old generation? > * Do you know why there isn't much (visible, generally available) progress > on NUMA optimizations for the old gen? Is the Java in-memory database use > case considered a rare one? > * Maybe we at Quartet FS should experiment and even contribute new heap > layouts to the open-jdk project. Can you comment on the difficulty of that? > > > Thanks for reading, and Best Regards, > > -- > Antoine CHAMBILLE > Director Research & Development > Quartet FS From nils.loodin at oracle.com Wed Feb 20 06:21:24 2013 From: nils.loodin at oracle.com (nils.loodin at oracle.com) Date: Wed, 20 Feb 2013 14:21:24 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130220142128.DD9F447C00@hg.openjdk.java.net> Changeset: bc34e24e0637 Author: nloodin Date: 2013-02-20 11:24 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/bc34e24e0637 8007804: Need to be able to access Performance counter by name from JVM Reviewed-by: dholmes, sla, sspitsyn ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/perfData.hpp Changeset: eb911d21c6b1 Author: nloodin Date: 2013-02-20 03:58 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/eb911d21c6b1 Merge From forax at univ-mlv.fr Wed Feb 20 06:54:08 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 20 Feb 2013 15:54:08 +0100 Subject: NUMA-Aware Java Heaps for in-memory databases In-Reply-To: References: Message-ID: <5124E390.9010000@univ-mlv.fr> On 02/20/2013 02:28 PM, Volker Simonis wrote: > The limitations you describe are the reason why databases implemented > in Java usually use external memory (to a greater or lesser extent) to > work around (mostly performance) problems of Java heap memory. There > was a very interesting talk at JavaOne about how these problems are > solved in Cassandra: "Dealing with JVM Limitations in Apache > Cassandra" (https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=3586) > > Regards, > Volker but as far as I know, Cassandra only stores primitive values no object. cheers, R?mi > > > On Wed, Feb 13, 2013 at 2:42 PM, Antoine Chambille wrote: >> We are developing a Java in-memory analytical database (it's called >> "ActivePivot") that our customers deploy on ever larger datasets. Some >> ActivePivot instances are deployed on java heaps close to 1TB, on NUMA >> servers (typically 4 Xeon processors and 4 NUMA nodes). This is becoming a >> trend, and we are researching solutions to improve our performance on NUMA >> configurations. >> >> >> We understand that in the current state of things (and including JDK8) the >> support for NUMA in hotspot is the following: >> * The young generation heap layout can be NUMA-Aware (partitioned per NUMA >> node, objects allocated in the same node than the running thread) >> * The old generation heap layout is not optimized for NUMA (at best the old >> generation is interleaved among nodes which at least makes memory accesses >> somewhat uniform) >> * The parallel garbage collector is NUMA optimized, the GC threads focusing >> on objects in their node. >> >> >> Yet activating -XX:+UseNUMA option has almost no impact on the performance >> of our in-memory database. It is not surprising, the pattern for a database >> is to load the data in the memory and then make queries on it. The data >> goes and stays in the old generation, and it is read from there by queries. >> Most memory accesses are in the old gen and most of those are not local. >> >> I guess there is a reason hotspot does not yet optimize the old generation >> for NUMA. It must be very difficult to do it in the general case, when you >> have no idea what thread from what node will read data and interleaving is. >> But for an in-memory database this is frustrating because we know very well >> which threads will access which piece of data. At least in ActivePivot data >> structures are partitioned, partitions are each assigned a thread pool so >> the threads that allocated the data in a partition are also the threads >> that perform sub-queries on that partition. We are a few lines of code away >> from binding thread pools to NUMA nodes, and if the garbage collector would >> leave objects promoted to the old generation on their original NUMA node >> memory accesses would be close to optimal. >> >> We have not been able to do that. But that being said I read an inspiring >> 2005 article from Mustafa M. Tikir and Jeffrey K. Hollingsworth that did >> experiment on NUMA layouts for the old generation. ("NUMA-aware Java heaps >> for server applications" >> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.6587&rep=rep1&type=pdf). >> That motivated me to ask questions in this mailing list: >> >> >> * Are there hidden or experimental hotspot options that allow NUMA-Aware >> partitioning of the old generation? >> * Do you know why there isn't much (visible, generally available) progress >> on NUMA optimizations for the old gen? Is the Java in-memory database use >> case considered a rare one? >> * Maybe we at Quartet FS should experiment and even contribute new heap >> layouts to the open-jdk project. Can you comment on the difficulty of that? >> >> >> Thanks for reading, and Best Regards, >> >> -- >> Antoine CHAMBILLE >> Director Research & Development >> Quartet FS From daniel.daugherty at oracle.com Wed Feb 20 07:00:31 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Feb 2013 08:00:31 -0700 Subject: Review Request: 8008451: Make mac builds on 10.8 work on 10.7 In-Reply-To: <5124E33C.3070903@oracle.com> References: <511D0FCD.4020803@oracle.com> <93A5D67B-22E9-4EB7-980E-3C8B3646DE6B@oracle.com> <511DF527.4080208@oracle.com> <511E0491.7070508@oracle.com> <5124E33C.3070903@oracle.com> Message-ID: <5124E50F.2060804@oracle.com> Widening the NotSpot net from just Runtime to all of HotSpot... Dan On 2/20/13 7:52 AM, Erik Joelsson wrote: > I was wrong, just setting the macros below did not generate 10.7 > compatible bits when built on 10.8. Since I already pushed the old > solution (except for hotspot), I created a new bug. Here is a new set > of patches, combining -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 and > -mmacosx-version-min=10.7.0 and also setting the latter on the link > command line. This combination both generates compatible binaries and > treats newer API calls as errors, all verified. > > Sine the two parameters take their argument in different formats, the > handling of defaults is a bit more complicated. The variable being > sent around and that you can override on the command line is now > MACOSX_VERSION_MIN=10.7.0, matching the parameter to the compiler/linker. > > It would be good if someone from hotspot could review the hotspot > changes. > > http://cr.openjdk.java.net/~erikj/8008451/webrev.hotspot.01/ > http://cr.openjdk.java.net/~erikj/8008451/webrev.root.01/ > http://cr.openjdk.java.net/~erikj/8008451/webrev.jdk.01/ > > /Erik > > On 2013-02-15 10:49, Erik Joelsson wrote: >> >> >> On 2013-02-15 09:43, Erik Joelsson wrote: >>> >>> On 2013-02-14 18:04, David DeHaven wrote: >>>>> Here are a series of patches that adds the following to all native >>>>> compile lines on macosx: >>>>> >>>>> -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 >>>>> -DMAC_OS_X_VERSION_MIN_REQUIRED=1070 >>>> I know I'm not a reviewer, but I have an opinion anyways :) >>>> >>>> Using "-mmacosx-version-min=10.7" seems more appropriate for the >>>> latter, this is passed to the linker as well which I believe sets >>>> version information in the Mach-O headers (in the form of a load >>>> command) to prevent it from being loaded on older systems. The >>>> MIN_REQUIRED macro is set to a value that matches what's passed to >>>> the -mmacosx-version-min argument, so it doesn't need to be provided. >>>> >>>> >>> The effect of the -mmacosx-version-min=10.7 when sent to the linker >>> is to make any calls to newer APIs "softlinked". This means the >>> library will still load fine on the older OS, but the application is >>> responsible for only actually making the newer calls if they are >>> available. This is a good feature if you knowingly want to support >>> multiple versions of the OS and still use features in the newer OS >>> when available. I do not believe we have the need for that and if we >>> ever do, then these parameters will need to change. >>> >> It's true -mmacosx-version-min= also sets the macro >> MAC_OS_X_VERSION_MIN_REQUIRED=, but I see no gain in changing just >> one of them to something else just because it works. The format of >> the parameter is also different (10.7 vs 1070) which would require us >> to add logic for converting between the two. >> >> /Erik From jesper.wilhelmsson at oracle.com Wed Feb 20 07:09:27 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 20 Feb 2013 16:09:27 +0100 Subject: RFR (S): 8008314 - Unimplemented() Atomic::load breaks the applications In-Reply-To: <512448F9.6050609@oracle.com> References: <51231AE7.9070206@oracle.com> <512332FB.7020600@oracle.com> <51235162.9030702@oracle.com> <51236461.7060101@oracle.com> <51237589.4030105@oracle.com> <5123AF1E.2020603@oracle.com> <512448F9.6050609@oracle.com> Message-ID: <5124E727.5030908@oracle.com> Hi Dean, Using count() is a good suggestion. It would require a larger change though since the rotatingFileStream doesn't use the _position and _precount variables right now and they aren't properly updated as you noted. There are places in the code that uses count() to find information about the logfiles. I suspect there could be a really unlikely bug hiding here: If a long running program happens to wrap the _precount variable at the end of a line, calls to count() would return zero and believe that there is no logging in progress. Regarding thread saftey there is no difference in using count() to using the current _bytes_written (none of them are thread safe), and since this bug is about removing the use of atomic add, I'd prefer to keep the change small. There are other things in rotatingFileStream that would benefit from an overview. For instance there are two constructors that are identical apart from a minor detail. I'd like to clean this up and remove the duplicated code - especially as only one of the constructors are ever used. Are you OK with my current change if I'll create a separate CR to look in to the potential problem with count() and to do this cleanup? /Jesper On 20/2/13 4:54 AM, Dean Long wrote: > How about using "if (count() < (jlong)GCLogFileSize)" and > "set_position(0);set_count(0);" in > rotate_log(), then removing_bytes_written? However be aware that count() grows > even when > _file == NULL, because write() calls update_position() unconditionally. > > dl > > On 2/19/2013 8:58 AM, Jesper Wilhelmsson wrote: >> Hi, >> >> The counter that is protected by the atomic add is only used to decide when to >> switch to the next file in the rotating log file scheme. Even with the atomic >> add it is not an exact limit since we only check the limt at a sefepoint and >> we will always write a whole log message at a time. >> >> I ran several tests with most GC logging turned on with and without the atomic >> add and I see no significant difference in the sizes of the log files. >> >> I have a new patch where I remove the atomic add: >> >> HS24: http://cr.openjdk.java.net/~jwilhelm/8008314/webrev.2.hs24/ >> HS25: http://cr.openjdk.java.net/~jwilhelm/8008314/webrev.2.hs25/ >> >> Let me know if you feel confident in pushing this. >> /Jesper >> >> >> On 19/2/13 1:52 PM, Bengt Rutisson wrote: >>> On 2/19/13 12:39 PM, David Holmes wrote: >>>> I'm also indebted to Bengt for spotting that - hadn't realized the 'x' types >>>> were intptr_t typedefs. >>>> >>>> But backing up a step, this code is not obviously thread-safes, or if it is it >>>> must be by a lock at a higher level - so why do we need an atomic update of >>>> the _bytes_written value? >>> >>> Yes, this is something we discussed at lunch today. It looks like calling >>> update_position() without some kind of locking is unsafe. This is not introduced >>> only by the rotatingFileStream. All the outputStream implmentations does this. >>> Looks scary to me. I don't really understand how this works in a safe way. Maybe >>> it doesn't. >>> >>> We are not doing any locking higher up in the call chain as far as I can see. >>> >>> Bengt >>> >>>> >>>> David >>>> >>>> On 19/02/2013 8:18 PM, Jesper Wilhelmsson wrote: >>>>> Bengt, >>>>> >>>>> Thanks for catching this! I should listen to Ted's mother, nothing good >>>>> happens after 2am[1]. >>>>> >>>>> I wasn't aware that jint was 32-bit on all platforms. Using 32-bit >>>>> atomic add like this won't work, back to the drawing board. >>>>> >>>>> The one quick solution I can think of right now that won't be awful >>>>> would be to limit GcLogFileSize to 32 bit. I'm not sure how quick a fix >>>>> it will be though since it may require a CCC approval... >>>>> >>>>> /Jesper >>>>> >>>>> >>>>> [1] http://en.wikipedia.org/wiki/Nothing_Good_Happens_After_2_A.M. >>>>> >>>>> >>>>> On 19/2/13 9:08 AM, Bengt Rutisson wrote: >>>>>> >>>>>> Hi Jesper, >>>>>> >>>>>> Thanks for fixing this! I don't feel very comfortable with this code, >>>>>> so don't >>>>>> consider this a full review. Just a couple of comments: >>>>>> >>>>>> It seems to make sense to use uintx for _bytes_written since the flag >>>>>> to control >>>>>> the file size, GCLogFileSize, is uintx. But since the atomics you use are >>>>>> handling jint I think it looks a bit suspicious. jint is always 32 >>>>>> bits and >>>>>> uintx can be 32 or 64 bit. So, what happens here if _bytes_written is >>>>>> 64 bit? >>>>>> >>>>>> 457 Atomic::add((jint)count, (jint*)&_bytes_written); >>>>>> >>>>>> If _bytes_written is 0x00000000FFFFFFFF and count is 1, I would guess >>>>>> that we >>>>>> get 0x0 instead of 0x0000000100000000. >>>>>> >>>>>> Also, in rotatingFileStream::rotate_log() you changed to: >>>>>> >>>>>> if (_bytes_written <= GCLogFileSize) return; >>>>>> >>>>>> instead of : >>>>>> >>>>>> if (_bytes_writen < (jlong)GCLogFileSize) return; >>>>>> >>>>>> isn't this a problem since you set _bytes_written to UINT_MAX if we >>>>>> wrap around? >>>>>> If someone sets GCLogFileSize on the command line to be UINT_MAX we >>>>>> will never >>>>>> rotate the file, right? >>>>>> >>>>>> Also, we only call rotate_log() when we start a safepoint. If we wrap >>>>>> around >>>>>> once in write() but then call it again before a safepoint happens we can >>>>>> probably set _bytes_written to a value that looks small enough to not >>>>>> have to >>>>>> rotate the log. It seems to me that we would need a separate flag to >>>>>> say that we >>>>>> written enough to rotate the log. >>>>>> >>>>>> Bengt >>>>>> >>>>>> >>>>>> >>>>>> On 2/19/13 7:25 AM, Jesper Wilhelmsson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review the following change: >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8008314/ >>>>>>> >>>>>>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8008314 >>>>>>> >>>>>>> >>>>>>> The use of atomic::add(jlong,jlong*) breaks everything on ARM since >>>>>>> it uses >>>>>>> atomic::load(jlong) which isn't implemented. >>>>>>> >>>>>>> The add was used to update a counter in rotating log file handling, >>>>>>> but it >>>>>>> turns out that the counter that was updated doesn't need to be a jlong. >>>>>>> >>>>>>> The counter is used to indicate that it is time to do a log file >>>>>>> rotation and >>>>>>> by adding a saftey catch for overflow, we can use an uintx for the >>>>>>> counter. >>>>>>> >>>>>>> In practice this means that the upper "limit" for the log file size >>>>>>> becomes >>>>>>> UINX_MAX-1 (used to be UINT_MAX) since I change from < to <= in the >>>>>>> comparison >>>>>>> to the limit, but since this is not a hard limit the difference will >>>>>>> only be >>>>>>> noticeable when someone has written UINT_MAX characters to the log >>>>>>> file and >>>>>>> the next write will end up in the next log file part instead of in >>>>>>> the same >>>>>>> (which one could argue is a more correct behavior). >>>>>>> >>>>>>> Sine I changed all places where the counter was used I also fixed a >>>>>>> typo in >>>>>>> its name. >>>>>>> >>>>>>> Thanks, >>>>>>> /Jesper >>>>>> >>> > From zhengyu.gu at oracle.com Wed Feb 20 07:28:49 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 20 Feb 2013 10:28:49 -0500 Subject: Code review request: 8008071: Crashed in promote_malloc_records() with Kitchensink after 19 days Message-ID: <5124EBB1.9010105@oracle.com> This is a simple fix to add NULL pointer check. This bug is hard to reproduce, since it only happens what an arena pointer has highest address in NMT database. Bug: http://bugs.sun.com/view_bug.do?bug_id=8008071 Webrev: http://cr.openjdk.java.net/~zgu/8008071/webrev.00/ Test: I have Kitchensink running over a day now, still in progress. Thanks, -Zhengyu From dean.long at oracle.com Wed Feb 20 08:06:18 2013 From: dean.long at oracle.com (Dean Long) Date: Wed, 20 Feb 2013 08:06:18 -0800 Subject: RFR (S): 8008314 - Unimplemented() Atomic::load breaks the applications In-Reply-To: <5124E727.5030908@oracle.com> References: <51231AE7.9070206@oracle.com> <512332FB.7020600@oracle.com> <51235162.9030702@oracle.com> <51236461.7060101@oracle.com> <51237589.4030105@oracle.com> <5123AF1E.2020603@oracle.com> <512448F9.6050609@oracle.com> <5124E727.5030908@oracle.com> Message-ID: <5124F47A.5070004@oracle.com> On 2/20/2013 7:09 AM, Jesper Wilhelmsson wrote: > Hi Dean, > > Using count() is a good suggestion. It would require a larger change > though since the rotatingFileStream doesn't use the _position and > _precount variables right now and they aren't properly updated as you > noted. There are places in the code that uses count() to find > information about the logfiles. I suspect there could be a really > unlikely bug hiding here: If a long running program happens to wrap > the _precount variable at the end of a line, calls to count() would > return zero and believe that there is no logging in progress. > > Regarding thread saftey there is no difference in using count() to > using the current _bytes_written (none of them are thread safe), and > since this bug is about removing the use of atomic add, I'd prefer to > keep the change small. > > There are other things in rotatingFileStream that would benefit from > an overview. For instance there are two constructors that are > identical apart from a minor detail. I'd like to clean this up and > remove the duplicated code - especially as only one of the > constructors are ever used. > > Are you OK with my current change if I'll create a separate CR to look > in to the potential problem with count() and to do this cleanup? > /Jesper > Yes, sounds good. dl > > On 20/2/13 4:54 AM, Dean Long wrote: >> How about using "if (count() < (jlong)GCLogFileSize)" and >> "set_position(0);set_count(0);" in >> rotate_log(), then removing_bytes_written? However be aware that >> count() grows >> even when >> _file == NULL, because write() calls update_position() unconditionally. >> >> dl >> >> On 2/19/2013 8:58 AM, Jesper Wilhelmsson wrote: >>> Hi, >>> >>> The counter that is protected by the atomic add is only used to >>> decide when to >>> switch to the next file in the rotating log file scheme. Even with >>> the atomic >>> add it is not an exact limit since we only check the limt at a >>> sefepoint and >>> we will always write a whole log message at a time. >>> >>> I ran several tests with most GC logging turned on with and without >>> the atomic >>> add and I see no significant difference in the sizes of the log files. >>> >>> I have a new patch where I remove the atomic add: >>> >>> HS24: http://cr.openjdk.java.net/~jwilhelm/8008314/webrev.2.hs24/ >>> HS25: http://cr.openjdk.java.net/~jwilhelm/8008314/webrev.2.hs25/ >>> >>> Let me know if you feel confident in pushing this. >>> /Jesper >>> >>> >>> On 19/2/13 1:52 PM, Bengt Rutisson wrote: >>>> On 2/19/13 12:39 PM, David Holmes wrote: >>>>> I'm also indebted to Bengt for spotting that - hadn't realized the >>>>> 'x' types >>>>> were intptr_t typedefs. >>>>> >>>>> But backing up a step, this code is not obviously thread-safes, or >>>>> if it is it >>>>> must be by a lock at a higher level - so why do we need an atomic >>>>> update of >>>>> the _bytes_written value? >>>> >>>> Yes, this is something we discussed at lunch today. It looks like >>>> calling >>>> update_position() without some kind of locking is unsafe. This is >>>> not introduced >>>> only by the rotatingFileStream. All the outputStream implmentations >>>> does this. >>>> Looks scary to me. I don't really understand how this works in a >>>> safe way. Maybe >>>> it doesn't. >>>> >>>> We are not doing any locking higher up in the call chain as far as >>>> I can see. >>>> >>>> Bengt >>>> >>>>> >>>>> David >>>>> >>>>> On 19/02/2013 8:18 PM, Jesper Wilhelmsson wrote: >>>>>> Bengt, >>>>>> >>>>>> Thanks for catching this! I should listen to Ted's mother, >>>>>> nothing good >>>>>> happens after 2am[1]. >>>>>> >>>>>> I wasn't aware that jint was 32-bit on all platforms. Using 32-bit >>>>>> atomic add like this won't work, back to the drawing board. >>>>>> >>>>>> The one quick solution I can think of right now that won't be awful >>>>>> would be to limit GcLogFileSize to 32 bit. I'm not sure how quick >>>>>> a fix >>>>>> it will be though since it may require a CCC approval... >>>>>> >>>>>> /Jesper >>>>>> >>>>>> >>>>>> [1] http://en.wikipedia.org/wiki/Nothing_Good_Happens_After_2_A.M. >>>>>> >>>>>> >>>>>> On 19/2/13 9:08 AM, Bengt Rutisson wrote: >>>>>>> >>>>>>> Hi Jesper, >>>>>>> >>>>>>> Thanks for fixing this! I don't feel very comfortable with this >>>>>>> code, >>>>>>> so don't >>>>>>> consider this a full review. Just a couple of comments: >>>>>>> >>>>>>> It seems to make sense to use uintx for _bytes_written since the >>>>>>> flag >>>>>>> to control >>>>>>> the file size, GCLogFileSize, is uintx. But since the atomics >>>>>>> you use are >>>>>>> handling jint I think it looks a bit suspicious. jint is always 32 >>>>>>> bits and >>>>>>> uintx can be 32 or 64 bit. So, what happens here if >>>>>>> _bytes_written is >>>>>>> 64 bit? >>>>>>> >>>>>>> 457 Atomic::add((jint)count, (jint*)&_bytes_written); >>>>>>> >>>>>>> If _bytes_written is 0x00000000FFFFFFFF and count is 1, I would >>>>>>> guess >>>>>>> that we >>>>>>> get 0x0 instead of 0x0000000100000000. >>>>>>> >>>>>>> Also, in rotatingFileStream::rotate_log() you changed to: >>>>>>> >>>>>>> if (_bytes_written <= GCLogFileSize) return; >>>>>>> >>>>>>> instead of : >>>>>>> >>>>>>> if (_bytes_writen < (jlong)GCLogFileSize) return; >>>>>>> >>>>>>> isn't this a problem since you set _bytes_written to UINT_MAX if we >>>>>>> wrap around? >>>>>>> If someone sets GCLogFileSize on the command line to be UINT_MAX we >>>>>>> will never >>>>>>> rotate the file, right? >>>>>>> >>>>>>> Also, we only call rotate_log() when we start a safepoint. If we >>>>>>> wrap >>>>>>> around >>>>>>> once in write() but then call it again before a safepoint >>>>>>> happens we can >>>>>>> probably set _bytes_written to a value that looks small enough >>>>>>> to not >>>>>>> have to >>>>>>> rotate the log. It seems to me that we would need a separate >>>>>>> flag to >>>>>>> say that we >>>>>>> written enough to rotate the log. >>>>>>> >>>>>>> Bengt >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2/19/13 7:25 AM, Jesper Wilhelmsson wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review the following change: >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8008314/ >>>>>>>> >>>>>>>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8008314 >>>>>>>> >>>>>>>> >>>>>>>> The use of atomic::add(jlong,jlong*) breaks everything on ARM >>>>>>>> since >>>>>>>> it uses >>>>>>>> atomic::load(jlong) which isn't implemented. >>>>>>>> >>>>>>>> The add was used to update a counter in rotating log file >>>>>>>> handling, >>>>>>>> but it >>>>>>>> turns out that the counter that was updated doesn't need to be >>>>>>>> a jlong. >>>>>>>> >>>>>>>> The counter is used to indicate that it is time to do a log file >>>>>>>> rotation and >>>>>>>> by adding a saftey catch for overflow, we can use an uintx for the >>>>>>>> counter. >>>>>>>> >>>>>>>> In practice this means that the upper "limit" for the log file >>>>>>>> size >>>>>>>> becomes >>>>>>>> UINX_MAX-1 (used to be UINT_MAX) since I change from < to <= in >>>>>>>> the >>>>>>>> comparison >>>>>>>> to the limit, but since this is not a hard limit the difference >>>>>>>> will >>>>>>>> only be >>>>>>>> noticeable when someone has written UINT_MAX characters to the log >>>>>>>> file and >>>>>>>> the next write will end up in the next log file part instead of in >>>>>>>> the same >>>>>>>> (which one could argue is a more correct behavior). >>>>>>>> >>>>>>>> Sine I changed all places where the counter was used I also >>>>>>>> fixed a >>>>>>>> typo in >>>>>>>> its name. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> /Jesper >>>>>>> >>>> >> From nils.loodin at oracle.com Wed Feb 20 08:33:45 2013 From: nils.loodin at oracle.com (nils.loodin at oracle.com) Date: Wed, 20 Feb 2013 16:33:45 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130220163355.2096847C07@hg.openjdk.java.net> Changeset: 4eca232ca0c6 Author: nloodin Date: 2013-02-20 11:24 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4eca232ca0c6 8007804: Need to be able to access Performance counter by name from JVM Reviewed-by: dholmes, sla, sspitsyn ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/perfData.hpp Changeset: 32ff8194b6d4 Author: nloodin Date: 2013-02-20 06:25 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/32ff8194b6d4 Merge From serguei.spitsyn at oracle.com Wed Feb 20 09:32:45 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 20 Feb 2013 09:32:45 -0800 Subject: Code review request: 8008071: Crashed in promote_malloc_records() with Kitchensink after 19 days In-Reply-To: <5124EBB1.9010105@oracle.com> References: <5124EBB1.9010105@oracle.com> Message-ID: <512508BD.9020808@oracle.com> Looks good. Thanks, Serguei On 2/20/13 7:28 AM, Zhengyu Gu wrote: > This is a simple fix to add NULL pointer check. This bug is hard to > reproduce, since it only happens what an arena pointer has highest > address in NMT database. > > > Bug: http://bugs.sun.com/view_bug.do?bug_id=8008071 > Webrev: http://cr.openjdk.java.net/~zgu/8008071/webrev.00/ > > Test: > > I have Kitchensink running over a day now, still in progress. > > > Thanks, > > -Zhengyu From mikael.vidstedt at oracle.com Wed Feb 20 09:33:18 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 20 Feb 2013 09:33:18 -0800 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <0153EC9C-4474-4B54-B215-6BE7BF2A7E1B@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> <50A24E00.3070200@oracle.com> <50A25720.1040405@oracle.com> <50A59010.5040001@oracle.com> <510C18F6.6010305@oracle.com> <511DAB26.2010808@oracle.com> <511DB3E0.6030606@oracle.com> <5122B5C3.1010908@oracle.com> <0153EC9C-4474-4B54-B215-6BE7BF2A7E1B@oracle.com> Message-ID: <512508DE.70904@oracle.com> On 2/19/2013 12:01 PM, Christian Thalinger wrote: > On Feb 18, 2013, at 3:14 PM, Mikael Vidstedt wrote: > >> A really good control question, thanks a lot for asking! >> >> As a matter of fact these changes are basically just doing what the compiler already does for us, so it's more about cleaning up the source code than reducing the size of the binary. So in theory these changes should have no impact on the binary size at all, but it actually turns out they do. Very specifically, the fact that I moved the same_page() function from being duplicated in the three os_.cpp files to having it be in globalDefinitions.cpp makes the binary grow a few bytes (54 bytes to be specific). The reason is a bit subtle: >> >> The same_page() function is (was) static in the respective os_*.cpp files. They are only ever used when the Verbose flag is true, and furthermore the Verbose option is a develop only flag, which means it is hardcoded to false in product. The compiler knows that's the case and eliminates the same_page() function completely. >> >> Since I moved it to globalDefinitions.cpp there's no way easy for the compiler to know that it is not being used, so it will actually keep the function. >> >> Unless there are strong opinions I'm not going to do anything about this. >> >> However, this made me question my earlier experiments with using the const bool = false construct in constantPool.cpp, because after all that is the exact same pattern. And it turns out that I must have done something wrong when I was performing the experiments, because when I do the same thing again now it turns out the compiler actually *does* deadcode eliminate the debug-only functions. So I take everything back and conclude that const bool = false is indeed a great way to make sure the debug code does not rot over time, and that the product binary will *not* contain the dead functions. Sorry for any confusion this may have caused. >> >> With all that in mind, here's another version of the webrev: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev04/webrev/ > src/share/vm/interpreter/interpreterRuntime.cpp: > > I suppose that #if 0 is to keep that code for...? Could we add a comment why we keep it? This was by "popular request" (from David Holmes) :) I personally don't know if and how this is being used. Note that ObjectSynchronizer::trace_locking is PRODUCT_RETURN and the non-product implementation in synchronizer.cpp is empty (modulo the comment saying "Don't know what to do here"), so one can question the value of keeping the any of the trace_locking functions, but they may be someone's favorite debugging tool. Until proven differently I will leave it in there for now. If somebody can help me provide a useful comment about how the code is actually being used then I will certainly add it, otherwise I'll keep this as it is. > src/share/vm/oops/constantPool.cpp: > > So we use: > > + const bool debug_cpool = false; > > but we still have the DBG macro. Can't we have a static debug method that takes all printf arguments and prints them? The debug_cpool should make that method empty and the compiler can remove it. I really start to hate all these macros... I share your macro hate and I actually played around with removing the macros just as you say. There is one small problem with doing it that way, and that's the fact that a few of the printf:s print symbols names, and as part of that they need to create utf8 strings using sym->as_utf8(). The compiler can unfortunately not know that that function is for all intents and purposes a no-op, so it will keep the call even in product meaning increased binary size and it will also add to the runtime since it actually performs the call and creates the utf8 string. So I'm going to keep the macros for now. I also moved the clamp_address_in_page to the globalDefinitions.hpp header file, meaning it will be inlined and dead code eliminated. New webrev here: http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev.05/webrev/ Final comments? Cheers, Mikael From coleen.phillimore at oracle.com Wed Feb 20 10:04:05 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 20 Feb 2013 13:04:05 -0500 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <512508DE.70904@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> <50A24E00.3070200@oracle.com> <50A25720.1040405@oracle.com> <50A59010.5040001@oracle.com> <510C18F6.6010305@oracle.com> <511DAB26.2010808@oracle.com> <511DB3E0.6030606@oracle.com> <5122B5C3.1010908@oracle.com> <0153EC9C-4474-4B54-B215-6BE7BF2A7E1B@oracle.com> <512508DE.70904@oracle.com> Message-ID: <51251015.5000501@oracle.com> On 2/20/2013 12:33 PM, Mikael Vidstedt wrote: > > On 2/19/2013 12:01 PM, Christian Thalinger wrote: >> On Feb 18, 2013, at 3:14 PM, Mikael Vidstedt >> wrote: >> >>> A really good control question, thanks a lot for asking! >>> >>> As a matter of fact these changes are basically just doing what the >>> compiler already does for us, so it's more about cleaning up the >>> source code than reducing the size of the binary. So in theory these >>> changes should have no impact on the binary size at all, but it >>> actually turns out they do. Very specifically, the fact that I moved >>> the same_page() function from being duplicated in the three >>> os_.cpp files to having it be in globalDefinitions.cpp makes the >>> binary grow a few bytes (54 bytes to be specific). The reason is a >>> bit subtle: >>> >>> The same_page() function is (was) static in the respective os_*.cpp >>> files. They are only ever used when the Verbose flag is true, and >>> furthermore the Verbose option is a develop only flag, which means >>> it is hardcoded to false in product. The compiler knows that's the >>> case and eliminates the same_page() function completely. >>> >>> Since I moved it to globalDefinitions.cpp there's no way easy for >>> the compiler to know that it is not being used, so it will actually >>> keep the function. >>> >>> Unless there are strong opinions I'm not going to do anything about >>> this. >>> >>> However, this made me question my earlier experiments with using the >>> const bool = false construct in constantPool.cpp, because after all >>> that is the exact same pattern. And it turns out that I must have >>> done something wrong when I was performing the experiments, because >>> when I do the same thing again now it turns out the compiler >>> actually *does* deadcode eliminate the debug-only functions. So I >>> take everything back and conclude that const bool = false is indeed >>> a great way to make sure the debug code does not rot over time, and >>> that the product binary will *not* contain the dead functions. Sorry >>> for any confusion this may have caused. >>> >>> With all that in mind, here's another version of the webrev: >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev04/webrev/ >> src/share/vm/interpreter/interpreterRuntime.cpp: >> >> I suppose that #if 0 is to keep that code for...? Could we add a >> comment why we keep it? > > This was by "popular request" (from David Holmes) :) > > I personally don't know if and how this is being used. Note that > ObjectSynchronizer::trace_locking is PRODUCT_RETURN and the > non-product implementation in synchronizer.cpp is empty (modulo the > comment saying "Don't know what to do here"), so one can question the > value of keeping the any of the trace_locking functions, but they may > be someone's favorite debugging tool. Until proven differently I will > leave it in there for now. If somebody can help me provide a useful > comment about how the code is actually being used then I will > certainly add it, otherwise I'll keep this as it is. If I remember correctly, this trace_locking code was associated with a flag that we removed a long time ago. I don't think if we want to implement TraceLocking we'd use this function. My vote is that it and the ObjectMonitor:: version should be removed. Coleen > >> src/share/vm/oops/constantPool.cpp: >> >> So we use: >> >> + const bool debug_cpool = false; >> >> but we still have the DBG macro. Can't we have a static debug method >> that takes all printf arguments and prints them? The debug_cpool >> should make that method empty and the compiler can remove it. I >> really start to hate all these macros... > > I share your macro hate and I actually played around with removing the > macros just as you say. There is one small problem with doing it that > way, and that's the fact that a few of the printf:s print symbols > names, and as part of that they need to create utf8 strings using > sym->as_utf8(). The compiler can unfortunately not know that that > function is for all intents and purposes a no-op, so it will keep the > call even in product meaning increased binary size and it will also > add to the runtime since it actually performs the call and creates the > utf8 string. So I'm going to keep the macros for now. > > > I also moved the clamp_address_in_page to the globalDefinitions.hpp > header file, meaning it will be inlined and dead code eliminated. > > New webrev here: > > http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev.05/webrev/ > > Final comments? > > Cheers, > Mikael > From coleen.phillimore at oracle.com Wed Feb 20 10:58:55 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 20 Feb 2013 13:58:55 -0500 Subject: 8008243: Zero: implement fast-bytecodes [Was: Re: [RFC] Fast-bytecodes for Zero] In-Reply-To: <1361349904.19150.6.camel@mercury> References: <1360784420.2524.31.camel@mercury> <511DE2EF.9090106@oracle.com> <1360923721.6566.20.camel@mercury> <259E154F-3718-486B-A06F-CBA9C1A186B2@oracle.com> <1361349904.19150.6.camel@mercury> Message-ID: <51251CEF.4060406@oracle.com> I'm glad bytecode rewriting gives a good performance improvement with the c++ interpreter. This is great. I have a couple of questions about the code. In templateInterpreter_.cpp we only patch the bytecode with _fast_{x}putfield if the constant pool cache is resolved. This isn't always the case. You can call putfield on a class that isn't completely initialized yet and don't want other threads to execute this code (we have a test for this somewhere). Also, there's some conditional code with posting breakpoints. If this bytecode is a breakpoint bytecode, we patch into the method's stream. You might not have to do this. It can try again to patch the bytecode if there's a breakpoint there. Anyway, the code here has the patching unconditional, and I think it needs to be conditioned on these two things. The second is that if I'm reading this right, the patching code assumes that the order of the fast bytecodes doesn't change. This could silently break if we do change the order. Maybe an assert is in order here. I didn't see how this tests the flag value of RewriteBytecodes and RewriteFrequentPairs. If Zero supports Class data sharing, you need to turn off this bytecode rewriting (unfortunately). This looks like good work. Someday someone has to break out the cases here into functions because I can't imagine how the C++ compiler can optimize this massive function. Thanks, Coleen On 2/20/2013 3:45 AM, Roman Kennke wrote: > Am Montag, den 18.02.2013, 12:30 -0800 schrieb Christian Thalinger: >> On Feb 15, 2013, at 6:39 AM, Vitaly Davidovich wrote: >> >>> Hi Roman, >>> >>> One suggestion I have is to add functions to JvmtiExport like has_field_access_watchers() and change this accordingly: >>> >>> count_addr = (int *)JvmtiExport::get_field_access_count_addr(); \ >>> 436 if ( *count_addr > 0 ) { >>> >>> The has_XXX function can simply have that code inside. >>> >>> Reason I think it's useful is because the field is an int but the get_* function declares address as return type requiring you to cast and thus know internal representation. Seems cleaner to encapsulate inside JvmtiExport? >> I agree on that but that would be beyond the scope of this change. Roman only moved the code into a macro so he can reuse it in multiple places. Actually I would prefer to move the code into a method because that would make the huge method a little smaller. > I agree with both of you. :-) > > I also tried to move this code into separate methods. However, this > seems to be very difficult, because the CALL_VM macro depends on a lot > of variables local to the interpreter loop: cp, locals, cache, thread, > topOfStack, pc, istate and handle_exception, handle_Pop_frame > (goto-labels). Yes, it is possible to somehow pass everything into such > a method, but this seems awkward. I am not sure what is the lesser evil > here. > > Roman > >> -- Chris >> >>> Thanks >>> >>> Sent from my phone >>> >>> On Feb 15, 2013 5:23 AM, "Roman Kennke" wrote: >>> Hi David, >>> >>> Am Freitag, den 15.02.2013, 17:25 +1000 schrieb David Holmes: >>>> There's a lot of changes to shared code here - what is the impact on >>>> non-zero platforms? >>> The changes to shared code are in bytecodeInterpreter.cpp, which is, to >>> my knowledge, only used by Zero. *If* there are other interpreters that >>> use it (maybe in closed trees?) they would most likely just pick up and >>> benefit from the improvements. But of course, I cannot tell... >>> >>> Regards, >>> Roman >>> >>>> Thanks, >>>> David >>>> >>>> On 15/02/2013 4:51 AM, Christian Thalinger wrote: >>>>> I've filed: >>>>> >>>>> 8008243: Zero: implement fast-bytecodes >>>>> >>>>> -- Chris >>>>> >>>>> On Feb 13, 2013, at 11:40 AM, Roman Kennke wrote: >>>>> >>>>>> The following change implements support for the following fast-bytecodes >>>>>> in the Zero interpreter: >>>>>> >>>>>> fast_agetfield >>>>>> fast_bgetfield >>>>>> fast_cgetfield >>>>>> fast_dgetfield >>>>>> fast_fgetfield >>>>>> fast_igetfield >>>>>> fast_lgetfield >>>>>> fast_sgetfield >>>>>> fast_aputfield >>>>>> fast_bputfield >>>>>> fast_cputfield >>>>>> fast_dputfield >>>>>> fast_fputfield >>>>>> fast_iputfield >>>>>> fast_lputfield >>>>>> fast_sputfield >>>>>> fast_aload_0 >>>>>> fast_iaccess_0 >>>>>> fast_aaccess_0 >>>>>> fast_faccess_0 >>>>>> fast_iload >>>>>> fast_iload2 >>>>>> fast_icaload >>>>>> fast_invokevfinal >>>>>> >>>>>> All together this leads to a speedup of the interpreter of about 25%. >>>>>> >>>>>> Some notes: >>>>>> - I extracted the JVMTI related blocks into a macro to avoid repetition. >>>>>> - The field get/put opcodes are only rewritten for non-volatile >>>>>> non-static field access, this makes the fast one really fast (no >>>>>> additional branches needed), and static/volatile field accesses seem >>>>>> rare enough anyway. >>>>>> >>>>>> http://cr.openjdk.java.net/~rkennke/zero-fast-opcodes/webrev.00/ >>>>>> >>>>>> >>>>>> Opinions? Can this be included in hotspot? And Can I have a bug-ID? >>>>>> >>>>>> Best regards, >>>>>> Roman >>>>>> >>>>>> >>> > From vladimir.kozlov at oracle.com Wed Feb 20 11:39:49 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 20 Feb 2013 11:39:49 -0800 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <512508DE.70904@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> <50A24E00.3070200@oracle.com> <50A25720.1040405@oracle.com> <50A59010.5040001@oracle.com> <510C18F6.6010305@oracle.com> <511DAB26.2010808@oracle.com> <511DB3E0.6030606@oracle.com> <5122B5C3.1010908@oracle.com> <0153EC9C-4474-4B54-B215-6BE7BF2A7E1B@oracle.com> <512508DE.70904@oracle.com> Message-ID: <51252685.70904@oracle.com> Good. Thanks, Vladimir On 2/20/13 9:33 AM, Mikael Vidstedt wrote: > > On 2/19/2013 12:01 PM, Christian Thalinger wrote: >> On Feb 18, 2013, at 3:14 PM, Mikael Vidstedt >> wrote: >> >>> A really good control question, thanks a lot for asking! >>> >>> As a matter of fact these changes are basically just doing what the >>> compiler already does for us, so it's more about cleaning up the >>> source code than reducing the size of the binary. So in theory these >>> changes should have no impact on the binary size at all, but it >>> actually turns out they do. Very specifically, the fact that I moved >>> the same_page() function from being duplicated in the three >>> os_.cpp files to having it be in globalDefinitions.cpp makes the >>> binary grow a few bytes (54 bytes to be specific). The reason is a >>> bit subtle: >>> >>> The same_page() function is (was) static in the respective os_*.cpp >>> files. They are only ever used when the Verbose flag is true, and >>> furthermore the Verbose option is a develop only flag, which means it >>> is hardcoded to false in product. The compiler knows that's the case >>> and eliminates the same_page() function completely. >>> >>> Since I moved it to globalDefinitions.cpp there's no way easy for the >>> compiler to know that it is not being used, so it will actually keep >>> the function. >>> >>> Unless there are strong opinions I'm not going to do anything about >>> this. >>> >>> However, this made me question my earlier experiments with using the >>> const bool = false construct in constantPool.cpp, because after all >>> that is the exact same pattern. And it turns out that I must have >>> done something wrong when I was performing the experiments, because >>> when I do the same thing again now it turns out the compiler actually >>> *does* deadcode eliminate the debug-only functions. So I take >>> everything back and conclude that const bool = false is indeed a >>> great way to make sure the debug code does not rot over time, and >>> that the product binary will *not* contain the dead functions. Sorry >>> for any confusion this may have caused. >>> >>> With all that in mind, here's another version of the webrev: >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev04/webrev/ >> src/share/vm/interpreter/interpreterRuntime.cpp: >> >> I suppose that #if 0 is to keep that code for...? Could we add a >> comment why we keep it? > > This was by "popular request" (from David Holmes) :) > > I personally don't know if and how this is being used. Note that > ObjectSynchronizer::trace_locking is PRODUCT_RETURN and the non-product > implementation in synchronizer.cpp is empty (modulo the comment saying > "Don't know what to do here"), so one can question the value of keeping > the any of the trace_locking functions, but they may be someone's > favorite debugging tool. Until proven differently I will leave it in > there for now. If somebody can help me provide a useful comment about > how the code is actually being used then I will certainly add it, > otherwise I'll keep this as it is. > >> src/share/vm/oops/constantPool.cpp: >> >> So we use: >> >> + const bool debug_cpool = false; >> >> but we still have the DBG macro. Can't we have a static debug method >> that takes all printf arguments and prints them? The debug_cpool >> should make that method empty and the compiler can remove it. I >> really start to hate all these macros... > > I share your macro hate and I actually played around with removing the > macros just as you say. There is one small problem with doing it that > way, and that's the fact that a few of the printf:s print symbols names, > and as part of that they need to create utf8 strings using > sym->as_utf8(). The compiler can unfortunately not know that that > function is for all intents and purposes a no-op, so it will keep the > call even in product meaning increased binary size and it will also add > to the runtime since it actually performs the call and creates the utf8 > string. So I'm going to keep the macros for now. > > > I also moved the clamp_address_in_page to the globalDefinitions.hpp > header file, meaning it will be inlined and dead code eliminated. > > New webrev here: > > http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev.05/webrev/ > > Final comments? > > Cheers, > Mikael > From zhengyu.gu at oracle.com Wed Feb 20 11:39:57 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 20 Feb 2013 14:39:57 -0500 Subject: Does UseLargePages option work on Windows? Message-ID: <5125268D.3080105@oracle.com> Hi, I am trying to experiment UseLargePages option (-XX:+UseLargePages) with NMT, but I have trouble to get large page to work on Windows (mine is Windows 7). I followed instruction to grant myself the permission to lock pages in memory (http://msdn.microsoft.com/en-us/library/ms190730.aspx), but I am still getting following warning message: Java HotSpot(TM) Server VM warning: JVM cannot use large page memory because it does not have enough privilege to lock pages in memory. Test jobs from JPRT also show large pages are not enabled. Java HotSpot(TM) Client VM warning: Large page is not supported by the operating system. Java HotSpot(TM) Server VM warning: Large page is not supported by the operating system. Could you please comment what I did wrong? Thanks, -Zhengyu From david.holmes at oracle.com Wed Feb 20 12:15:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Feb 2013 06:15:09 +1000 Subject: Code review request: 8008071: Crashed in promote_malloc_records() with Kitchensink after 19 days In-Reply-To: <5124EBB1.9010105@oracle.com> References: <5124EBB1.9010105@oracle.com> Message-ID: <51252ECD.70705@oracle.com> Looks good. David On 21/02/2013 1:28 AM, Zhengyu Gu wrote: > This is a simple fix to add NULL pointer check. This bug is hard to > reproduce, since it only happens what an arena pointer has highest > address in NMT database. > > > Bug: http://bugs.sun.com/view_bug.do?bug_id=8008071 > Webrev: http://cr.openjdk.java.net/~zgu/8008071/webrev.00/ > > Test: > > I have Kitchensink running over a day now, still in progress. > > > Thanks, > > -Zhengyu From poonam.bajaj at oracle.com Tue Feb 19 20:31:49 2013 From: poonam.bajaj at oracle.com (poonam.bajaj at oracle.com) Date: Wed, 20 Feb 2013 04:31:49 +0000 Subject: hg: hsx/hsx24/hotspot: 8006938: Change os::print_location to be more descriptive when a location is pointing into an object Message-ID: <20130220043154.2715147BC3@hg.openjdk.java.net> Changeset: 5e48fb5e9625 Author: poonam Date: 2013-02-19 16:03 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/5e48fb5e9625 8006938: Change os::print_location to be more descriptive when a location is pointing into an object Reviewed-by: stefank, twisti, poonam Contributed-by: sergey.gabdurakhmanov at oracle.com ! src/share/vm/runtime/os.cpp From John.Coomes at oracle.com Wed Feb 20 12:53:29 2013 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 20 Feb 2013 12:53:29 -0800 Subject: Result: New hsx Committer: Volker Simonis Message-ID: <20773.14281.112806.998234@oracle.com> Voting for Volker Simonis [1] is now closed. Yes: 15 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. John Coomes [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-February/008299.html From vladimir.kozlov at oracle.com Wed Feb 20 12:56:38 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 20 Feb 2013 12:56:38 -0800 Subject: Result: New HSX Committer: Bharadwaj Yadavalli In-Reply-To: <406C03C1-E65E-459E-B68C-BB7862977E7A@oracle.com> References: <406C03C1-E65E-459E-B68C-BB7862977E7A@oracle.com> Message-ID: <51253886.4060705@oracle.com> Voting for Bharadwaj Yadavalli [1] is now closed. Yes: 14 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus [2], this is sufficient to approve the nomination. Vladimir Kozlov [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-February/008276.html [2] http://openjdk.java.net/bylaws#lazy-consensus From John.Coomes at oracle.com Wed Feb 20 12:58:31 2013 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 20 Feb 2013 12:58:31 -0800 Subject: Result: New hotspot Group Member: Volker Simonis Message-ID: <20773.14583.448240.936567@oracle.com> The vote for Volker Simonis [1] is now closed. Yes: 9 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. John Coomes [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-February/008304.html From joseph.provino at oracle.com Wed Feb 20 13:47:55 2013 From: joseph.provino at oracle.com (JOSEPH PROVINO) Date: Wed, 20 Feb 2013 16:47:55 -0500 Subject: Please review: 8006498 and 8008474 Message-ID: <5125448B.8090107@oracle.com> 8006498: ASSERT and other symbols used incorrectly with #if are supposed to be defined or not 8008474: -Wundef should be added to the build to catch #if references to undefined macros. Webrev is here: http://cr.openjdk.java.net/~jprovino/8006498/webrev.00/ Thanks. joe From John.Coomes at oracle.com Wed Feb 20 14:25:34 2013 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 20 Feb 2013 14:25:34 -0800 Subject: CFV: New HSX Committer: David Chase In-Reply-To: <5122E337.5030203@oracle.com> References: <5111D374.2090101@oracle.com> <5122E337.5030203@oracle.com> Message-ID: <20773.19806.324266.877282@oracle.com> Vote: yes -John From dean.long at oracle.com Wed Feb 20 14:29:04 2013 From: dean.long at oracle.com (Dean Long) Date: Wed, 20 Feb 2013 14:29:04 -0800 Subject: 8007770: fix name clash of assert macro in debug.hpp with libc's assert macro [Was: Re: Bug 100297 - [patch] fix name clash of assert macro in debug.hpp with libc's assert macro] In-Reply-To: References: <152FA772-A91D-42C5-BF24-4B6B9860517A@oracle.com> <512438A7.9050107@oracle.com> <51246E39.2070402@oracle.com> Message-ID: <51254E30.4040403@oracle.com> On 2/19/2013 11:58 PM, P?ter Radics wrote: > > On Wed, Feb 20, 2013 at 7:33 AM, Dean Long > wrote: > > On 2/19/2013 6:44 PM, David Holmes wrote: > > On 20/02/2013 7:56 AM, Christian Thalinger wrote: > > [David already filed an RFE for this: > > 8007770: fix name clash of assert macro in debug.hpp with > libc's assert macro] > > > Yes. For the record it is only undefined behaviour if you > suppress the assert macro and re-define it as a function - > which we do not do. > > John Rose also added the following to the bug report: > > "I count about 15,000 occurrences of assert in our sources. > The proposed rename would therefore be a disruptive change. > Patches and change sets would no longer apply across that > change, leading to maintenance costs, especially back-porting > bug fixes. > Thus, a mere claim of "would be prudent to conform exactly to > the standard" is not enough grounds to accept this change. > > Since 'assert' macros are common programming practice, we can > expect (or request, if necessary) that the C++ standard > libraries provide an op-out mechanism, such as '#undef assert' > or '-DNDEBUG'. > > For a reference on NDEBUG, see: > http://www.cplusplus.com/reference/cassert/assert/ > > (To be clear, NDEBUG does not remove the macro. Another option > would be required, if #undef is not allowed.) " > > --- > > If this is potentially a problem then I think we need to avoid > it by other means - most likely by bracketing standard > includes with "#undef assert" so that they are not affected by > hotspot's definition, and our source is not affected by the > definition from assert.h > > > Can't we just do something like the following in debug.hpp? > > #include > #undef assert > #define assert(p, msg) \ > ... > > Any #include that happens after this should be a no-op > because it was already included once. > > dl > > David > ----- > > > Unfortunately that doesn't work, as may be included > multiple times by design, even with different NDEBUG settings. > > Regarding the 15k occurrences of assert: yes, it's unfortunate, and it > is a disruptive change, but other workarounds (such as the one > attempted with shark/llvmHeaders.hpp) are ugly and brittle, so in my > opinion this one-time disruption should be accepted. > > Incoming patches could be pre-processed with a script like the one I > attached to the bug report in the transition-period, but I think most > repos will pick up the change within a reasonable time. > > The other options is to try convincing the libc++ devs to not use a > perfectly valid way of using the standard assert facilities... > > cheers, > mitch > A less disruptive change would be to add something like: #undef assert #define assert(e,msg) assert_vm(e,msg) after the #includes in all hotspot source files. Hopefully this would have little impact on back-ports and patches. dl From vladimir.kozlov at oracle.com Wed Feb 20 15:05:27 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 20 Feb 2013 23:05:27 +0000 Subject: hg: hsx/hsx24/hotspot: 8004867: VM crashing with assert "share/vm/opto/node.hpp:357 - assert(i < _max) failed: oob" Message-ID: <20130220230531.5FD3647C1E@hg.openjdk.java.net> Changeset: 9bf91e181464 Author: kvn Date: 2013-02-18 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/9bf91e181464 8004867: VM crashing with assert "share/vm/opto/node.hpp:357 - assert(i < _max) failed: oob" Summary: Added few checks and early bailout from Superword optimization to avoid such cases in a future. Reviewed-by: roland, twisti ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp + test/compiler/8004867/TestIntAtomicCAS.java + test/compiler/8004867/TestIntAtomicOrdered.java + test/compiler/8004867/TestIntAtomicVolatile.java + test/compiler/8004867/TestIntUnsafeCAS.java + test/compiler/8004867/TestIntUnsafeOrdered.java + test/compiler/8004867/TestIntUnsafeVolatile.java From david.holmes at oracle.com Wed Feb 20 16:20:47 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Feb 2013 10:20:47 +1000 Subject: Please review: 8006498 and 8008474 In-Reply-To: <5125448B.8090107@oracle.com> References: <5125448B.8090107@oracle.com> Message-ID: <5125685F.5070907@oracle.com> On 21/02/2013 7:47 AM, JOSEPH PROVINO wrote: > 8006498: ASSERT and other symbols used incorrectly with #if are > supposed to be defined or not > > 8008474: -Wundef should be added to the build to catch #if references > to undefined macros. > > > Webrev is here: http://cr.openjdk.java.net/~jprovino/8006498/webrev.00/ On bsd and linux you simply added -Wundef directly to the CFLAGS: +CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(ACCEPTABLE_WARNINGS) -Wundef but on Solaris you added it to ADDITIONAL_WARNINGS: +ADDITIONAL_WARNINGS = -Wpointer-arith -Wconversion -Wsign-compare -Wundef I guess it is a little confusing as to whether ACCEPTABLE_WARNINGS and ADDITIONAL_WARNINGS are meant to be the same thing. Otherwise all the #if -> #ifdef etc seem okay. David > Thanks. > > joe From dmitry.samersoff at oracle.com Wed Feb 20 16:40:17 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Thu, 21 Feb 2013 00:40:17 +0000 Subject: hg: hsx/hotspot-main/hotspot: 14 new changesets Message-ID: <20130221004049.C252647C20@hg.openjdk.java.net> Changeset: 7adae9244bc8 Author: mgronlun Date: 2013-02-13 11:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7adae9244bc8 8007312: null check signal semaphore in os::signal_notify windows Reviewed-by: dholmes, sla ! src/os/windows/vm/os_windows.cpp Changeset: 2394a89e89f4 Author: rbackman Date: 2013-02-13 09:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2394a89e89f4 8008088: SA can hang the VM Reviewed-by: mgronlun, sla, dholmes ! agent/src/os/bsd/libproc_impl.c ! agent/src/os/bsd/libproc_impl.h ! agent/src/os/bsd/ps_proc.c ! agent/src/os/linux/libproc_impl.c ! agent/src/os/linux/libproc_impl.h ! agent/src/os/linux/ps_proc.c Changeset: 49618582fc5b Author: sla Date: 2013-02-14 13:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/49618582fc5b 8004840: Jstack seems to output unnecessary information in 7u9 Reviewed-by: dholmes, coleenp, sspitsyn, rbackman ! agent/src/share/classes/sun/jvm/hotspot/memory/CMSCollector.java ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java Changeset: 3a531d40ad93 Author: acorn Date: 2013-02-14 14:33 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3a531d40ad93 8007736: VerifyError for static method in interface Reviewed-by: dholmes, acorn Contributed-by: bharadwaj.yadavalli at oracle.com ! src/share/vm/classfile/verifier.cpp + test/runtime/8007736/TestStaticIF.java Changeset: e7e9e08147fc Author: mikael Date: 2013-02-14 12:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e7e9e08147fc 8007639: Workaround for ccache in vm.make is incorrect Summary: Fixed makefile logic to correctly special case JRE_RELEASE_VERSION and vm_version.o Reviewed-by: dholmes, erikj ! make/bsd/makefiles/vm.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make Changeset: 5d5c577296fd Author: sla Date: 2013-02-15 08:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5d5c577296fd 8008102: SA on OS X does not stop the attached process Reviewed-by: dholmes, rbackman ! agent/src/os/bsd/MacosxDebuggerLocal.m Changeset: f35f1fbab3e1 Author: sla Date: 2013-02-15 10:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f35f1fbab3e1 Merge Changeset: dc1de5e78a85 Author: dsamersoff Date: 2013-02-15 10:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dc1de5e78a85 Merge Changeset: f82bcc429e8c Author: sla Date: 2013-02-18 10:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f82bcc429e8c 8007901: SA: Don't read flag values as constants Reviewed-by: dholmes, mikael ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/runtime/vmStructs.cpp Changeset: b5e3ec9c69fa Author: sla Date: 2013-02-18 12:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b5e3ec9c69fa 8007779: os::die() on solaris should generate core file Reviewed-by: dholmes, rbackman ! src/os/solaris/vm/os_solaris.cpp Changeset: 5cd2fac2ae70 Author: hseigel Date: 2013-02-19 08:51 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5cd2fac2ae70 6749267: Signal handler should save/restore errno Summary: Save errno before processing signal, then restore it. Reviewed-by: acorn, sspitsyn ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp Changeset: 56c364daccc3 Author: emc Date: 2013-02-19 11:36 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/56c364daccc3 8007153: Ensure that MethodParameters API works properly with RedefineClasses Summary: Adds code to HotSpot to properly update MethodParameter attributes' constant pool indexes when redefineClasses is called Reviewed-by: coleenp, sspitsyn ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 1048edb5434a Author: coleenp Date: 2013-02-19 13:33 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1048edb5434a Merge Changeset: 20fff74158eb Author: sspitsyn Date: 2013-02-20 08:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/20fff74158eb Merge From krystal.mo at oracle.com Wed Feb 20 19:36:29 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Wed, 20 Feb 2013 19:36:29 -0800 Subject: CFV: New HSX Committer: David Chase In-Reply-To: <5122E337.5030203@oracle.com> References: <5111D374.2090101@oracle.com> <5122E337.5030203@oracle.com> Message-ID: <5125963D.1000207@oracle.com> Vote: yes - Kris On 2013/2/18 18:28, Vladimir Kozlov wrote: > I hereby nominate David Chase (OpenJDK user name: drchase) to HSX > Committer. > > David is a member of the Hotspot Compiler group. He is working on > Sumatra Project and new java types. He contributed 8 changesets to HSX > project and he is qualified to be committer [1]: > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=david.r.chase%40oracle.com > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/log?rev=drchase > > The last changeset is not shown in the query yet: > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a2bc322ca273 > > Votes are due by Mar 4, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > > > > > From bengt.rutisson at oracle.com Thu Feb 21 01:05:12 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 21 Feb 2013 10:05:12 +0100 Subject: Please review: 8006498 and 8008474 In-Reply-To: <5125448B.8090107@oracle.com> References: <5125448B.8090107@oracle.com> Message-ID: <5125E348.8050708@oracle.com> Hi Joe, I haven't looked at the make file changes, so don't consider this a full review. I have one request regarding the change in vm/gc_implementation/g1/concurrentMark.cpp: The code guarded by VERIFY_OBJS_PROCESSED actually does not work. This looks like some debugging code that was left behind. If someone defines VERIFY_OBJS_PROCESSED the code does not compile since _scan_obj_cl and ThreadLocalObjQueue do not exist. Do you think you can remove this code instead of fixing it? Thanks, Bengt Here is the patch if you want to do it: diff --git a/src/share/vm/gc_implementation/g1/concurrentMark.cpp b/src/share/vm/gc_implementation/g1/concurrentMark.cpp --- a/src/share/vm/gc_implementation/g1/concurrentMark.cpp +++ b/src/share/vm/gc_implementation/g1/concurrentMark.cpp @@ -1310,11 +1310,6 @@ _markStack.expand(); } -#if VERIFY_OBJS_PROCESSED - _scan_obj_cl.objs_processed = 0; - ThreadLocalObjQueue::objs_enqueued = 0; -#endif - // Statistics double now = os::elapsedTime(); _remark_mark_times.add((mark_work_end - start) * 1000.0); @@ -2555,17 +2550,6 @@ guarantee(satb_mq_set.completed_buffers_num() == 0, "invariant"); print_stats(); - -#if VERIFY_OBJS_PROCESSED - if (_scan_obj_cl.objs_processed != ThreadLocalObjQueue::objs_enqueued) { - gclog_or_tty->print_cr("Processed = %d, enqueued = %d.", - _scan_obj_cl.objs_processed, - ThreadLocalObjQueue::objs_enqueued); - guarantee(_scan_obj_cl.objs_processed == - ThreadLocalObjQueue::objs_enqueued, - "Different number of objs processed and enqueued."); - } -#endif } On 2/20/13 10:47 PM, JOSEPH PROVINO wrote: > 8006498: ASSERT and other symbols used incorrectly with #if are > supposed to be defined or not > > 8008474: -Wundef should be added to the build to catch #if references > to undefined macros. > > > Webrev is here: http://cr.openjdk.java.net/~jprovino/8006498/webrev.00/ > > Thanks. > > joe From ach at quartetfs.com Thu Feb 21 02:58:38 2013 From: ach at quartetfs.com (Antoine Chambille) Date: Thu, 21 Feb 2013 11:58:38 +0100 Subject: NUMA-Aware Java Heaps for in-memory databases In-Reply-To: <5124E390.9010000@univ-mlv.fr> References: <5124E390.9010000@univ-mlv.fr> Message-ID: Thanks for the feedback. The "Dealing with JVM Limitations in Apache Cassandra" presentation was indeed captivating and I felt at home. That being said their engine is disk based, they are "caching" the disk in-memory but design for disk: they serialize everything. An in-memory database like ActivePivot maintains the entire data in-memory, with compression, indexes and data layouts that are best suited for memory access. That also offers the opportunity to hold object based data and aggregates, with custom aggregation functions. I can't stress enough how important it is to our customers that inject their business logic in the core database engine (and love to do it in Java by the way). Last week I had lunch with Gil Tene, CTO and co-founder of Azul Systems, the writers of the Zing JVM (he knows a thing or two about GC and memory layouts ;). I was telling him my concerns about NUMA, that NUMA machines would become more and more common, and we should adapt our structures and algorithms for NUMA like we did adapt to multicore (we did didn't we?). But he does not share my position. To him the performance issues associated with NUMA are transient, going to be fixed or minimized by chip makers. He also reckons that NUMA optimization for the general case is VERY hard (impossible?) and that it should not be the burden of application writers. If people share his view, and if there is already this tradition of using off-heap data structures in Java databases, I understand why nobody is looking hard at making the old generation NUMA Aware. For ActivePivot I think we will prototype the usage of off-heap direct buffers to hold primitive data. Object data we'll leave in the heap as serialization is prohibitive. That may be good enough knowing that in typical projects primitive data is dominating. Then we'll buy one of the early Intel Xeon Haswell servers to see if progress is being made. -- Antoine CHAMBILLE Director Research & Development Quartet FS On 20 February 2013 15:54, Remi Forax wrote: > On 02/20/2013 02:28 PM, Volker Simonis wrote: > >> The limitations you describe are the reason why databases implemented >> in Java usually use external memory (to a greater or lesser extent) to >> work around (mostly performance) problems of Java heap memory. There >> was a very interesting talk at JavaOne about how these problems are >> solved in Cassandra: "Dealing with JVM Limitations in Apache >> Cassandra" (https://oracleus.**activeevents.com/connect/** >> sessionDetail.ww?SESSION_ID=**3586 >> ) >> >> Regards, >> Volker >> > > but as far as I know, Cassandra only stores primitive values no object. > > cheers, > R?mi > > > >> >> On Wed, Feb 13, 2013 at 2:42 PM, Antoine Chambille >> wrote: >> >>> We are developing a Java in-memory analytical database (it's called >>> "ActivePivot") that our customers deploy on ever larger datasets. Some >>> ActivePivot instances are deployed on java heaps close to 1TB, on NUMA >>> servers (typically 4 Xeon processors and 4 NUMA nodes). This is becoming >>> a >>> trend, and we are researching solutions to improve our performance on >>> NUMA >>> configurations. >>> >>> >>> We understand that in the current state of things (and including JDK8) >>> the >>> support for NUMA in hotspot is the following: >>> * The young generation heap layout can be NUMA-Aware (partitioned per >>> NUMA >>> node, objects allocated in the same node than the running thread) >>> * The old generation heap layout is not optimized for NUMA (at best the >>> old >>> generation is interleaved among nodes which at least makes memory >>> accesses >>> somewhat uniform) >>> * The parallel garbage collector is NUMA optimized, the GC threads >>> focusing >>> on objects in their node. >>> >>> >>> Yet activating -XX:+UseNUMA option has almost no impact on the >>> performance >>> of our in-memory database. It is not surprising, the pattern for a >>> database >>> is to load the data in the memory and then make queries on it. The data >>> goes and stays in the old generation, and it is read from there by >>> queries. >>> Most memory accesses are in the old gen and most of those are not local. >>> >>> I guess there is a reason hotspot does not yet optimize the old >>> generation >>> for NUMA. It must be very difficult to do it in the general case, when >>> you >>> have no idea what thread from what node will read data and interleaving >>> is. >>> But for an in-memory database this is frustrating because we know very >>> well >>> which threads will access which piece of data. At least in ActivePivot >>> data >>> structures are partitioned, partitions are each assigned a thread pool so >>> the threads that allocated the data in a partition are also the threads >>> that perform sub-queries on that partition. We are a few lines of code >>> away >>> from binding thread pools to NUMA nodes, and if the garbage collector >>> would >>> leave objects promoted to the old generation on their original NUMA node >>> memory accesses would be close to optimal. >>> >>> We have not been able to do that. But that being said I read an inspiring >>> 2005 article from Mustafa M. Tikir and Jeffrey K. Hollingsworth that did >>> experiment on NUMA layouts for the old generation. ("NUMA-aware Java >>> heaps >>> for server applications" >>> http://citeseerx.ist.psu.edu/**viewdoc/download?doi=10.1.1.** >>> 92.6587&rep=rep1&type=pdf >>> ). >>> That motivated me to ask questions in this mailing list: >>> >>> >>> * Are there hidden or experimental hotspot options that allow NUMA-Aware >>> partitioning of the old generation? >>> * Do you know why there isn't much (visible, generally available) >>> progress >>> on NUMA optimizations for the old gen? Is the Java in-memory database use >>> case considered a rare one? >>> * Maybe we at Quartet FS should experiment and even contribute new heap >>> layouts to the open-jdk project. Can you comment on the difficulty of >>> that? >>> >>> >>> Thanks for reading, and Best Regards, >>> >>> -- >>> Antoine CHAMBILLE >>> Director Research & Development >>> Quartet FS >>> >> > From david.holmes at oracle.com Thu Feb 21 03:17:41 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Feb 2013 21:17:41 +1000 Subject: [RFC] Fix Zero and Shark builds In-Reply-To: <5125F89B.40909@oracle.com> References: <1360776090.2524.22.camel@mercury> <511CA038.7050708@oracle.com> <1361395969.19150.80.camel@mercury> <5125F89B.40909@oracle.com> Message-ID: <51260255.5000508@oracle.com> So far I've looked at the hotspot changes - but really this should also go to hotspot-dev - cc'd I only see one change that isn't confined to zero/shark specific code and that is in make/linux/makefiles/vm.make: ifeq ($(JVM_VARIANT_ZEROSHARK), true) STATIC_CXX = false else ! ifeq ($(OPENJDK_TARGET_CPU), ppc64) STATIC_CXX = false else STATIC_CXX = true endif endif this may conflict with the incoming AIX/ppc64 port. My other comment on these changes is that you've now made the zero hotspot build dependent on being part of a complete build - ie there must be a spec.gmk/hotspot-spec.gmk for these variables to be defined. You won't be able to build hotspot stand-alone. Is that what you intended? David ----- On 21/02/2013 8:36 PM, Erik Joelsson wrote: > > > On 2013-02-20 22:32, Roman Kennke wrote: >> >> Thanks for the review! I made the following changes: >> >> - I moved all platform-foo to platform.m4, in >> PLATFORM_SETUP_LEGACY_VARS. Little problem: in this section I don't know >> about JVM_VARIANTS_ZERO yet, therefore I set those vars unconditionally. >> (But I propagate them to Make conditionally, see below). *However* those >> variables might actually be useful for non-Zero builds, if you look at >> the places where they're used, in non-Zero builds we find hardcoded >> values/strings for the various platforms, where the Zero way seems more >> elegant here. >> - I replaced ZERO_ENDIANNESS with the equivalent >> OPENJDK_TARGET_CPU_ENDIAN. >> - I replaced ARCH_DATA_MODEL with OPENJDK_TARGET_CPU_BITS. >> - I replaced ZERO_LIBARCH with OPENJDK_TARGET_CPU_LEGACY_LIB. >> - ZERO_ARCHFLAG is still needed for build on s390, to enable the correct >> ABI (by setting -m31). >> - ZERO_ARCHDEF is needed to get in the correct -DAMD64 or whatever >> setting (which are otherwise hardcoded in the various platform_XXX.in >> files in non-zero builds -- you/we might want to re-think this). >> >> Those changes also require some changes in the hotspot tree. See webrevs >> below. >> >> Re: Mike's suggestion: I set the variables in spec.gmk conditionally >> now. However, the resulting spec.gmk does have the conditions and >> var-setting code still in it, i.e. the zero-related code does not >> disappear. >> >>> Where is INCLUDE_SA supposed to be set? I know it was handled in >>> Defs-[os].gmk files in the old build, but in the new I would assume >>> configure should be setting it. >> it is set in jdk/common/Defs-$PLATFORM.gmk. As per David's suggestion, I >> will not touch this for now. It is only required for images-builds... so >> not super-critical - for the time being. >> >> Webrevs: >> http://cr.openjdk.java.net/~rkennke/zero-build-infra/webrev.03/ >> http://cr.openjdk.java.net/~rkennke/zero_build_infra_hotspot/webrev.01/ >> >> How's this now? >> > That looks much cleaner, thank you. If the hotspot team is ok with > renaming the variables in the hotspot makefiles, I'm fine with that too, > but it's not my decision. If they aren't, you can still set the hotspot > specific variables based on the ones from configure in > hotspot-spec.gmk.in. From the build group this is ok. You will still > need an official jdk8 reviewer to look at it, and the hotspot changes > need someone from hotspot. > > /Erik > From rkennke at redhat.com Thu Feb 21 03:26:30 2013 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 21 Feb 2013 12:26:30 +0100 Subject: [RFC] Fix Zero and Shark builds In-Reply-To: <51260255.5000508@oracle.com> References: <1360776090.2524.22.camel@mercury> <511CA038.7050708@oracle.com> <1361395969.19150.80.camel@mercury> <5125F89B.40909@oracle.com> <51260255.5000508@oracle.com> Message-ID: <1361445990.2945.7.camel@mercury> Am Donnerstag, den 21.02.2013, 21:17 +1000 schrieb David Holmes: > So far I've looked at the hotspot changes - but really this should also > go to hotspot-dev - cc'd > > I only see one change that isn't confined to zero/shark specific code > and that is in make/linux/makefiles/vm.make: > > ifeq ($(JVM_VARIANT_ZEROSHARK), true) > STATIC_CXX = false > else > ! ifeq ($(OPENJDK_TARGET_CPU), ppc64) > STATIC_CXX = false > else > STATIC_CXX = true > endif > endif > > this may conflict with the incoming AIX/ppc64 port. So far, the only supported ppc64 in Hotspot is Zero. At least to my knowledge. I am not sure why we need to explicitely link libstdc++ dynamically there though. I don't really see how this could affect anything outside Zero. And yes, it probably does affect the upcoming PPC64 port, but this needs to be sorted out anyway. > My other comment on these changes is that you've now made the zero > hotspot build dependent on being part of a complete build - ie there > must be a spec.gmk/hotspot-spec.gmk for these variables to be defined. > You won't be able to build hotspot stand-alone. Is that what you intended? Probably not. Not sure how a standalone hotspot build works with the new build-system. (I would be very happy to do this to reduce turnaround even more.) What would I need to do? Move all Zero/Shark variables to hotspot-spec.gmk.in ? Thanks, Roman From david.holmes at oracle.com Thu Feb 21 04:15:37 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Feb 2013 22:15:37 +1000 Subject: [RFC] Fix Zero and Shark builds In-Reply-To: <1361445990.2945.7.camel@mercury> References: <1360776090.2524.22.camel@mercury> <511CA038.7050708@oracle.com> <1361395969.19150.80.camel@mercury> <5125F89B.40909@oracle.com> <51260255.5000508@oracle.com> <1361445990.2945.7.camel@mercury> Message-ID: <51260FE9.4090302@oracle.com> On 21/02/2013 9:26 PM, Roman Kennke wrote: > Am Donnerstag, den 21.02.2013, 21:17 +1000 schrieb David Holmes: >> So far I've looked at the hotspot changes - but really this should also >> go to hotspot-dev - cc'd >> >> I only see one change that isn't confined to zero/shark specific code >> and that is in make/linux/makefiles/vm.make: >> >> ifeq ($(JVM_VARIANT_ZEROSHARK), true) >> STATIC_CXX = false >> else >> ! ifeq ($(OPENJDK_TARGET_CPU), ppc64) >> STATIC_CXX = false >> else >> STATIC_CXX = true >> endif >> endif >> >> this may conflict with the incoming AIX/ppc64 port. > > So far, the only supported ppc64 in Hotspot is Zero. At least to my > knowledge. I am not sure why we need to explicitely link libstdc++ > dynamically there though. I don't really see how this could affect > anything outside Zero. And yes, it probably does affect the upcoming > PPC64 port, but this needs to be sorted out anyway. Ok. Just wanted to flag it. >> My other comment on these changes is that you've now made the zero >> hotspot build dependent on being part of a complete build - ie there >> must be a spec.gmk/hotspot-spec.gmk for these variables to be defined. >> You won't be able to build hotspot stand-alone. Is that what you intended? > > Probably not. Not sure how a standalone hotspot build works with the new > build-system. (I would be very happy to do this to reduce turnaround > even more.) What would I need to do? Move all Zero/Shark variables to > hotspot-spec.gmk.in ? Hotspot has always been "self-configuring" on the build side. You can set a few variables to influence things but for the most part it detects things at build time. With the new build system hotspot was made "configure-aware". It was changed to include the spec.gmk file if it existed and the setting of variables potentially set by configure (and so in the spec.gmk file) was only done if not already set. Hence the two build approaches can co-exist. I don't know how a zero build was previously initiated but I could imagine it was something like: make ZEROARCH=zero then the zero-target together with the ZEROARCH value would trigger the right build logic to set all the necessary Zero flags. To maintain this you just need to be prepared for values to have been pre-set via spec.gmk. David ----- > Thanks, > Roman > > From zhengyu.gu at oracle.com Thu Feb 21 05:19:25 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 21 Feb 2013 08:19:25 -0500 Subject: Please review: 8006498 and 8008474 In-Reply-To: <5125685F.5070907@oracle.com> References: <5125448B.8090107@oracle.com> <5125685F.5070907@oracle.com> Message-ID: <51261EDD.2020309@oracle.com> Agree with David, -Wundef should go to CFLAGS_WARN/DEFAULT on Solaris if there is not particular reason not to. Other than that, look good to me. -Zhengyu On 2/20/2013 7:20 PM, David Holmes wrote: > On 21/02/2013 7:47 AM, JOSEPH PROVINO wrote: >> 8006498: ASSERT and other symbols used incorrectly with #if are >> supposed to be defined or not >> >> 8008474: -Wundef should be added to the build to catch #if references >> to undefined macros. >> >> >> Webrev is here: http://cr.openjdk.java.net/~jprovino/8006498/webrev.00/ > > On bsd and linux you simply added -Wundef directly to the CFLAGS: > > +CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(ACCEPTABLE_WARNINGS) > -Wundef > > but on Solaris you added it to ADDITIONAL_WARNINGS: > > +ADDITIONAL_WARNINGS = -Wpointer-arith -Wconversion -Wsign-compare > -Wundef > > I guess it is a little confusing as to whether ACCEPTABLE_WARNINGS and > ADDITIONAL_WARNINGS are meant to be the same thing. > > Otherwise all the #if -> #ifdef etc seem okay. > > David > >> Thanks. >> >> joe From sbergman at redhat.com Thu Feb 21 06:02:35 2013 From: sbergman at redhat.com (Stephan Bergmann) Date: Thu, 21 Feb 2013 15:02:35 +0100 Subject: get_stack_bounds using read(2) syscalls to read /proc/self/maps byte-by-byte In-Reply-To: <511A7FEE.20104@redhat.com> References: <511A7FEE.20104@redhat.com> Message-ID: <512628FB.803@redhat.com> On 02/12/2013 06:46 PM, Stephan Bergmann wrote: > On some Linux box (Fedora 18, using > java-1.7.0-openjdk-1.7.0.9-2.3.5.fc18.x86_64) I happened to look at an > strace of a LibreOffice process (which can instantiate the JVM > in-process), and noticed lots of calls to read(2) to read individual > bytes of /proc/self/maps. > > And get_stack_bounds in os/linux/vm/os_linux.cpp indeed calls out to > os::get_line_chars in share/vm/runtime/os.cpp that does > > read(fd, &buf[i], 1) > > This appears to be introduce with > > "7017193: Small memory leak in get_stack_bounds > os::create_stack_guard_pages" to fix > "Small > memory leak in get_stack_bounds // os::create_stack_guard_pages." > > Is this a known performance issue? A (likely naive) Web search did not > show anything that looked relevant, but I have vague memories of having > seen it mentioned somewhere a while ago. This lead to bug reports like "very bad performance with E-Porto Add-In f?r OpenOffice Writer installed" against LibreOffice now, so I took another look. The design of the LibreOffice extension infrastructure can lead, under certain conditions, to frequent (main thread) JNI Attach/DetachCurrentThread calls. This is a known problem with LibreOffice and modern JVMs on Linux, but one for which there is unfortunately no quick and easy fix in LibreOffice. So I prepared a local OpenJDK 1.7.0 version where I reverted "7017193: Small memory leak in get_stack_bounds os::create_stack_guard_pages" and instead applied the changes discussed in "Small memory leak in get_stack_bounds // os::create_stack_guard_pages" to get_satck_bounds in openjdk/hotspot/src/os/linux/vm/os_linux.cpp, i.e., changing from using per-byte read(2) calls to using larger getline(2) calls when reading /proc/self/maps. This caused the problems described in "very bad performance with E-Porto Add-In f?r OpenOffice Writer installed" to become much less dramatic. So I wonder, what was the reason to address "Small memory leak in get_stack_bounds // os::create_stack_guard_pages" with "7017193: Small memory leak in get_stack_bounds os::create_stack_guard_pages" and accept a performance degradation in certain cases? I see no obvious problems with the suggested fix in "Small memory leak in get_stack_bounds // os::create_stack_guard_pages?" Stephan From bengt.rutisson at oracle.com Thu Feb 21 06:21:18 2013 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Thu, 21 Feb 2013 14:21:18 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20130221142130.85D2147C3A@hg.openjdk.java.net> Changeset: bbc7936779f9 Author: brutisso Date: 2013-02-14 09:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bbc7936779f9 8006398: Add regression tests for deprectated GCs Reviewed-by: ehelin, jwilhelm, jmasa ! test/TEST.ROOT + test/gc/startup_warnings/TestCMS.java + test/gc/startup_warnings/TestCMSIncrementalMode.java + test/gc/startup_warnings/TestCMSNoIncrementalMode.java + test/gc/startup_warnings/TestDefNewCMS.java + test/gc/startup_warnings/TestG1.java + test/gc/startup_warnings/TestIncGC.java + test/gc/startup_warnings/TestParNewCMS.java + test/gc/startup_warnings/TestParNewSerialOld.java + test/gc/startup_warnings/TestParallelGC.java + test/gc/startup_warnings/TestParallelScavengeSerialOld.java + test/gc/startup_warnings/TestSerialGC.java Changeset: fd7b3770c77e Author: tamao Date: 2013-02-14 14:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fd7b3770c77e 8007764: Wrong initialized value of max_gc_pause_sec for an instance of class AdaptiveSizePolicy Summary: This is a fix of an initialization mistake for class AdaptiveSizePolicy. Reviewed-by: jmasa Contributed-by: Tao Mao ! src/share/vm/memory/collectorPolicy.cpp Changeset: ccc57295818b Author: johnc Date: 2013-02-19 16:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ccc57295818b 8006628: NEED_TEST for JDK-8002870 Summary: Regression test for 8000311. Verifies that PLABStats works with zero parallel GC threads. Reviewed-by: jmasa, johnc Contributed-by: Filipp Zhinkin + test/gc/8000311/Test8000311.java Changeset: b9c5e46bf915 Author: johnc Date: 2013-02-20 12:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b9c5e46bf915 8008188: Add regression test for 8005875 Summary: Add regression test for crash seen in 8005875. Test is run with G1 and PGCT=0 and issues "jcmd Thread.print" against itself. Without the fix for 8005875 the test will crash. Reviewed-by: brutisso + test/gc/TestG1ZeroPGCTJcmdThreadPrint.java Changeset: 5741d3fc502d Author: brutisso Date: 2013-02-21 13:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5741d3fc502d Merge From joseph.provino at oracle.com Thu Feb 21 06:32:39 2013 From: joseph.provino at oracle.com (Joseph Provino) Date: Thu, 21 Feb 2013 09:32:39 -0500 Subject: Please review: 8006498 and 8008474 In-Reply-To: <5125685F.5070907@oracle.com> References: <5125448B.8090107@oracle.com> <5125685F.5070907@oracle.com> Message-ID: <51263007.3080201@oracle.com> On 02/20/2013 07:20 PM, David Holmes wrote: > On 21/02/2013 7:47 AM, JOSEPH PROVINO wrote: >> 8006498: ASSERT and other symbols used incorrectly with #if are >> supposed to be defined or not >> >> 8008474: -Wundef should be added to the build to catch #if references >> to undefined macros. >> >> >> Webrev is here: http://cr.openjdk.java.net/~jprovino/8006498/webrev.00/ > > On bsd and linux you simply added -Wundef directly to the CFLAGS: > > +CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(ACCEPTABLE_WARNINGS) > -Wundef > > but on Solaris you added it to ADDITIONAL_WARNINGS: > > +ADDITIONAL_WARNINGS = -Wpointer-arith -Wconversion -Wsign-compare > -Wundef > > I guess it is a little confusing as to whether ACCEPTABLE_WARNINGS and > ADDITIONAL_WARNINGS are meant to be the same thing. Yes, I wasn't sure which way would be better. If you have a preference, I'll change it. joe > > Otherwise all the #if -> #ifdef etc seem okay. > > David > >> Thanks. >> >> joe From joseph.provino at oracle.com Thu Feb 21 06:42:13 2013 From: joseph.provino at oracle.com (Joseph Provino) Date: Thu, 21 Feb 2013 09:42:13 -0500 Subject: Please review: 8006498 and 8008474 In-Reply-To: <5125E348.8050708@oracle.com> References: <5125448B.8090107@oracle.com> <5125E348.8050708@oracle.com> Message-ID: <51263245.8070305@oracle.com> On 02/21/2013 04:05 AM, Bengt Rutisson wrote: > > Hi Joe, > > I haven't looked at the make file changes, so don't consider this a > full review. > > I have one request regarding the change in > vm/gc_implementation/g1/concurrentMark.cpp: > > The code guarded by VERIFY_OBJS_PROCESSED actually does not work. This > looks like some debugging code that was left behind. If someone > defines VERIFY_OBJS_PROCESSED the code does not compile since > _scan_obj_cl and ThreadLocalObjQueue do not exist. Do you think you > can remove this code instead of fixing it? Yes, that makes sense. I'll remove it. joe > > Thanks, > Bengt > > Here is the patch if you want to do it: > > diff --git a/src/share/vm/gc_implementation/g1/concurrentMark.cpp > b/src/share/vm/gc_implementation/g1/concurrentMark.cpp > --- a/src/share/vm/gc_implementation/g1/concurrentMark.cpp > +++ b/src/share/vm/gc_implementation/g1/concurrentMark.cpp > @@ -1310,11 +1310,6 @@ > _markStack.expand(); > } > > -#if VERIFY_OBJS_PROCESSED > - _scan_obj_cl.objs_processed = 0; > - ThreadLocalObjQueue::objs_enqueued = 0; > -#endif > - > // Statistics > double now = os::elapsedTime(); > _remark_mark_times.add((mark_work_end - start) * 1000.0); > @@ -2555,17 +2550,6 @@ > guarantee(satb_mq_set.completed_buffers_num() == 0, "invariant"); > > print_stats(); > - > -#if VERIFY_OBJS_PROCESSED > - if (_scan_obj_cl.objs_processed != > ThreadLocalObjQueue::objs_enqueued) { > - gclog_or_tty->print_cr("Processed = %d, enqueued = %d.", > - _scan_obj_cl.objs_processed, > - ThreadLocalObjQueue::objs_enqueued); > - guarantee(_scan_obj_cl.objs_processed == > - ThreadLocalObjQueue::objs_enqueued, > - "Different number of objs processed and enqueued."); > - } > -#endif > } > > > > > On 2/20/13 10:47 PM, JOSEPH PROVINO wrote: >> 8006498: ASSERT and other symbols used incorrectly with #if are >> supposed to be defined or not >> >> 8008474: -Wundef should be added to the build to catch #if >> references to undefined macros. >> >> >> Webrev is here: http://cr.openjdk.java.net/~jprovino/8006498/webrev.00/ >> >> Thanks. >> >> joe > From joseph.provino at oracle.com Thu Feb 21 06:48:53 2013 From: joseph.provino at oracle.com (JOSEPH PROVINO) Date: Thu, 21 Feb 2013 09:48:53 -0500 Subject: Please review: 8006498 and 8008474 In-Reply-To: <51261EDD.2020309@oracle.com> References: <5125448B.8090107@oracle.com> <5125685F.5070907@oracle.com> <51261EDD.2020309@oracle.com> Message-ID: <512633D5.6040202@oracle.com> Actually, from looking at this again, I thought David was suggesting that -Wundef should be added to ACCEPTABLE_WARNINGS for linux and bsd. joe On 2/21/2013 8:19 AM, Zhengyu Gu wrote: > Agree with David, -Wundef should go to CFLAGS_WARN/DEFAULT on Solaris > if there is not particular reason not to. > > Other than that, look good to me. > > -Zhengyu > > On 2/20/2013 7:20 PM, David Holmes wrote: >> On 21/02/2013 7:47 AM, JOSEPH PROVINO wrote: >>> 8006498: ASSERT and other symbols used incorrectly with #if are >>> supposed to be defined or not >>> >>> 8008474: -Wundef should be added to the build to catch #if references >>> to undefined macros. >>> >>> >>> Webrev is here: http://cr.openjdk.java.net/~jprovino/8006498/webrev.00/ >> >> On bsd and linux you simply added -Wundef directly to the CFLAGS: >> >> +CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(ACCEPTABLE_WARNINGS) >> -Wundef >> >> but on Solaris you added it to ADDITIONAL_WARNINGS: >> >> +ADDITIONAL_WARNINGS = -Wpointer-arith -Wconversion -Wsign-compare >> -Wundef >> >> I guess it is a little confusing as to whether ACCEPTABLE_WARNINGS >> and ADDITIONAL_WARNINGS are meant to be the same thing. >> >> Otherwise all the #if -> #ifdef etc seem okay. >> >> David >> >>> Thanks. >>> >>> joe > From dmitry.samersoff at oracle.com Thu Feb 21 07:05:13 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 21 Feb 2013 19:05:13 +0400 Subject: get_stack_bounds using read(2) syscalls to read /proc/self/maps byte-by-byte In-Reply-To: <512628FB.803@redhat.com> References: <511A7FEE.20104@redhat.com> <512628FB.803@redhat.com> Message-ID: <512637A9.2080607@oracle.com> Stephan, There was some reasons for me to go off getline: 1. Behaviour of getline is not properly documented so it's not clean for me whether we should clean the buffer on all platforms for all version of libc in case of getline error. see http://sourceware.org/bugzilla/show_bug.cgi?id=5666 2. The fix reduces number of heap memory allocations/deallocations within VM. Huge java app with long paths to DSO could have huge map file, getline version read it entirely, but we are interesting in first 128 bytes of each line only. 3. Kernel doesn't report size of /proc files and doesn't notify process on /proc/* files changes (see e.g. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/454722) So buffered reading of /proc/* files could lead to subtle errors or crashes if file is changed during read e.g. after suspend/resume. It might be possible to reduce number of read syscalls by implementing some internal bufferisation but I definitely would prefer not to return getline. Is there a performance problems with other applications? -Dmitry On 2013-02-21 18:02, Stephan Bergmann wrote: > On 02/12/2013 06:46 PM, Stephan Bergmann wrote: >> On some Linux box (Fedora 18, using >> java-1.7.0-openjdk-1.7.0.9-2.3.5.fc18.x86_64) I happened to look at an >> strace of a LibreOffice process (which can instantiate the JVM >> in-process), and noticed lots of calls to read(2) to read individual >> bytes of /proc/self/maps. >> >> And get_stack_bounds in os/linux/vm/os_linux.cpp indeed calls out to >> os::get_line_chars in share/vm/runtime/os.cpp that does >> >> read(fd, &buf[i], 1) >> >> This appears to be introduce with >> >> "7017193: Small memory leak in get_stack_bounds >> os::create_stack_guard_pages" to fix >> "Small >> memory leak in get_stack_bounds // os::create_stack_guard_pages." >> >> Is this a known performance issue? A (likely naive) Web search did not >> show anything that looked relevant, but I have vague memories of having >> seen it mentioned somewhere a while ago. > > This lead to bug reports like > "very bad > performance with E-Porto Add-In f?r OpenOffice Writer installed" against > LibreOffice now, so I took another look. > > The design of the LibreOffice extension infrastructure can lead, under > certain conditions, to frequent (main thread) JNI > Attach/DetachCurrentThread calls. This is a known problem with > LibreOffice and modern JVMs on Linux, but one for which there is > unfortunately no quick and easy fix in LibreOffice. > > So I prepared a local OpenJDK 1.7.0 version where I reverted > > "7017193: Small memory leak in get_stack_bounds > os::create_stack_guard_pages" and instead applied the changes discussed > in "Small > memory leak in get_stack_bounds // os::create_stack_guard_pages" to > get_satck_bounds in openjdk/hotspot/src/os/linux/vm/os_linux.cpp, i.e., > changing from using per-byte read(2) calls to using larger getline(2) > calls when reading /proc/self/maps. This caused the problems described > in "very bad > performance with E-Porto Add-In f?r OpenOffice Writer installed" to > become much less dramatic. > > So I wonder, what was the reason to address > "Small > memory leak in get_stack_bounds // os::create_stack_guard_pages" with > > "7017193: Small memory leak in get_stack_bounds > os::create_stack_guard_pages" and accept a performance degradation in > certain cases? I see no obvious problems with the suggested fix in > "Small > memory leak in get_stack_bounds // os::create_stack_guard_pages?" > > Stephan -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From bengt.rutisson at oracle.com Thu Feb 21 07:15:20 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 21 Feb 2013 16:15:20 +0100 Subject: Please review: 8006498 and 8008474 In-Reply-To: <51263245.8070305@oracle.com> References: <5125448B.8090107@oracle.com> <5125E348.8050708@oracle.com> <51263245.8070305@oracle.com> Message-ID: <51263A08.9010209@oracle.com> On 2/21/13 3:42 PM, Joseph Provino wrote: > On 02/21/2013 04:05 AM, Bengt Rutisson wrote: >> >> Hi Joe, >> >> I haven't looked at the make file changes, so don't consider this a >> full review. >> >> I have one request regarding the change in >> vm/gc_implementation/g1/concurrentMark.cpp: >> >> The code guarded by VERIFY_OBJS_PROCESSED actually does not work. >> This looks like some debugging code that was left behind. If someone >> defines VERIFY_OBJS_PROCESSED the code does not compile since >> _scan_obj_cl and ThreadLocalObjQueue do not exist. Do you think you >> can remove this code instead of fixing it? > > Yes, that makes sense. I'll remove it. Great! Thanks, Joe! Bengt > > joe > >> >> Thanks, >> Bengt >> >> Here is the patch if you want to do it: >> >> diff --git a/src/share/vm/gc_implementation/g1/concurrentMark.cpp >> b/src/share/vm/gc_implementation/g1/concurrentMark.cpp >> --- a/src/share/vm/gc_implementation/g1/concurrentMark.cpp >> +++ b/src/share/vm/gc_implementation/g1/concurrentMark.cpp >> @@ -1310,11 +1310,6 @@ >> _markStack.expand(); >> } >> >> -#if VERIFY_OBJS_PROCESSED >> - _scan_obj_cl.objs_processed = 0; >> - ThreadLocalObjQueue::objs_enqueued = 0; >> -#endif >> - >> // Statistics >> double now = os::elapsedTime(); >> _remark_mark_times.add((mark_work_end - start) * 1000.0); >> @@ -2555,17 +2550,6 @@ >> guarantee(satb_mq_set.completed_buffers_num() == 0, "invariant"); >> >> print_stats(); >> - >> -#if VERIFY_OBJS_PROCESSED >> - if (_scan_obj_cl.objs_processed != >> ThreadLocalObjQueue::objs_enqueued) { >> - gclog_or_tty->print_cr("Processed = %d, enqueued = %d.", >> - _scan_obj_cl.objs_processed, >> - ThreadLocalObjQueue::objs_enqueued); >> - guarantee(_scan_obj_cl.objs_processed == >> - ThreadLocalObjQueue::objs_enqueued, >> - "Different number of objs processed and enqueued."); >> - } >> -#endif >> } >> >> >> >> >> On 2/20/13 10:47 PM, JOSEPH PROVINO wrote: >>> 8006498: ASSERT and other symbols used incorrectly with #if are >>> supposed to be defined or not >>> >>> 8008474: -Wundef should be added to the build to catch #if >>> references to undefined macros. >>> >>> >>> Webrev is here: http://cr.openjdk.java.net/~jprovino/8006498/webrev.00/ >>> >>> Thanks. >>> >>> joe >> > From staffan.larsen at oracle.com Thu Feb 21 07:38:32 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 21 Feb 2013 16:38:32 +0100 Subject: RFR(M): 7165259 Remove BugSpot Message-ID: <9496CFBE-4F80-490A-9A07-C2B58447F532@oracle.com> Please review the following change to remove the BugSpot UI for the Serviceability Agent. My understanding is that BugSpot was intended as a more general native debugger not only focused on the JVM, but that it was never fully implemented. I don't think there is a need for a general-purpose debugger in SA and would like to clean up the code. One effect of this change is that PStack and PMap will no longer be able to operate on executables other than the JVM. This change was first proposed last year in this thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2012-April/005811.html This change also removes some old JVMDI code in SA (JVMDI is no longer supported in HotSpot). bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7165259 webrev: http://cr.openjdk.java.net/~sla/7165259/webrev.00/ Thanks, /Staffan From jesper.wilhelmsson at oracle.com Thu Feb 21 07:45:04 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 21 Feb 2013 16:45:04 +0100 Subject: RFR (S): 8008314 - Unimplemented() Atomic::load breaks the applications In-Reply-To: <5124F47A.5070004@oracle.com> References: <51231AE7.9070206@oracle.com> <512332FB.7020600@oracle.com> <51235162.9030702@oracle.com> <51236461.7060101@oracle.com> <51237589.4030105@oracle.com> <5123AF1E.2020603@oracle.com> <512448F9.6050609@oracle.com> <5124E727.5030908@oracle.com> <5124F47A.5070004@oracle.com> Message-ID: <51264100.60807@oracle.com> This is now pushed to hsx/hotspot-gc. I will push to hsx24 once it has survived a couple of rounds of nightly testing. I created JDK-8008650 to track the problems with rotatingFileStream. /Jesper On 20/2/13 5:06 PM, Dean Long wrote: > On 2/20/2013 7:09 AM, Jesper Wilhelmsson wrote: >> Hi Dean, >> >> Using count() is a good suggestion. It would require a larger change though >> since the rotatingFileStream doesn't use the _position and _precount variables >> right now and they aren't properly updated as you noted. There are places in >> the code that uses count() to find information about the logfiles. I suspect >> there could be a really unlikely bug hiding here: If a long running program >> happens to wrap the _precount variable at the end of a line, calls to count() >> would return zero and believe that there is no logging in progress. >> >> Regarding thread saftey there is no difference in using count() to using the >> current _bytes_written (none of them are thread safe), and since this bug is >> about removing the use of atomic add, I'd prefer to keep the change small. >> >> There are other things in rotatingFileStream that would benefit from an >> overview. For instance there are two constructors that are identical apart >> from a minor detail. I'd like to clean this up and remove the duplicated code >> - especially as only one of the constructors are ever used. >> >> Are you OK with my current change if I'll create a separate CR to look in to >> the potential problem with count() and to do this cleanup? >> /Jesper >> > Yes, sounds good. > > dl > >> >> On 20/2/13 4:54 AM, Dean Long wrote: >>> How about using "if (count() < (jlong)GCLogFileSize)" and >>> "set_position(0);set_count(0);" in >>> rotate_log(), then removing_bytes_written? However be aware that count() grows >>> even when >>> _file == NULL, because write() calls update_position() unconditionally. >>> >>> dl >>> >>> On 2/19/2013 8:58 AM, Jesper Wilhelmsson wrote: >>>> Hi, >>>> >>>> The counter that is protected by the atomic add is only used to decide when to >>>> switch to the next file in the rotating log file scheme. Even with the atomic >>>> add it is not an exact limit since we only check the limt at a sefepoint and >>>> we will always write a whole log message at a time. >>>> >>>> I ran several tests with most GC logging turned on with and without the atomic >>>> add and I see no significant difference in the sizes of the log files. >>>> >>>> I have a new patch where I remove the atomic add: >>>> >>>> HS24: http://cr.openjdk.java.net/~jwilhelm/8008314/webrev.2.hs24/ >>>> HS25: http://cr.openjdk.java.net/~jwilhelm/8008314/webrev.2.hs25/ >>>> >>>> Let me know if you feel confident in pushing this. >>>> /Jesper >>>> >>>> >>>> On 19/2/13 1:52 PM, Bengt Rutisson wrote: >>>>> On 2/19/13 12:39 PM, David Holmes wrote: >>>>>> I'm also indebted to Bengt for spotting that - hadn't realized the 'x' types >>>>>> were intptr_t typedefs. >>>>>> >>>>>> But backing up a step, this code is not obviously thread-safes, or if it >>>>>> is it >>>>>> must be by a lock at a higher level - so why do we need an atomic update of >>>>>> the _bytes_written value? >>>>> >>>>> Yes, this is something we discussed at lunch today. It looks like calling >>>>> update_position() without some kind of locking is unsafe. This is not >>>>> introduced >>>>> only by the rotatingFileStream. All the outputStream implmentations does this. >>>>> Looks scary to me. I don't really understand how this works in a safe way. >>>>> Maybe >>>>> it doesn't. >>>>> >>>>> We are not doing any locking higher up in the call chain as far as I can see. >>>>> >>>>> Bengt >>>>> >>>>>> >>>>>> David >>>>>> >>>>>> On 19/02/2013 8:18 PM, Jesper Wilhelmsson wrote: >>>>>>> Bengt, >>>>>>> >>>>>>> Thanks for catching this! I should listen to Ted's mother, nothing good >>>>>>> happens after 2am[1]. >>>>>>> >>>>>>> I wasn't aware that jint was 32-bit on all platforms. Using 32-bit >>>>>>> atomic add like this won't work, back to the drawing board. >>>>>>> >>>>>>> The one quick solution I can think of right now that won't be awful >>>>>>> would be to limit GcLogFileSize to 32 bit. I'm not sure how quick a fix >>>>>>> it will be though since it may require a CCC approval... >>>>>>> >>>>>>> /Jesper >>>>>>> >>>>>>> >>>>>>> [1] http://en.wikipedia.org/wiki/Nothing_Good_Happens_After_2_A.M. >>>>>>> >>>>>>> >>>>>>> On 19/2/13 9:08 AM, Bengt Rutisson wrote: >>>>>>>> >>>>>>>> Hi Jesper, >>>>>>>> >>>>>>>> Thanks for fixing this! I don't feel very comfortable with this code, >>>>>>>> so don't >>>>>>>> consider this a full review. Just a couple of comments: >>>>>>>> >>>>>>>> It seems to make sense to use uintx for _bytes_written since the flag >>>>>>>> to control >>>>>>>> the file size, GCLogFileSize, is uintx. But since the atomics you use are >>>>>>>> handling jint I think it looks a bit suspicious. jint is always 32 >>>>>>>> bits and >>>>>>>> uintx can be 32 or 64 bit. So, what happens here if _bytes_written is >>>>>>>> 64 bit? >>>>>>>> >>>>>>>> 457 Atomic::add((jint)count, (jint*)&_bytes_written); >>>>>>>> >>>>>>>> If _bytes_written is 0x00000000FFFFFFFF and count is 1, I would guess >>>>>>>> that we >>>>>>>> get 0x0 instead of 0x0000000100000000. >>>>>>>> >>>>>>>> Also, in rotatingFileStream::rotate_log() you changed to: >>>>>>>> >>>>>>>> if (_bytes_written <= GCLogFileSize) return; >>>>>>>> >>>>>>>> instead of : >>>>>>>> >>>>>>>> if (_bytes_writen < (jlong)GCLogFileSize) return; >>>>>>>> >>>>>>>> isn't this a problem since you set _bytes_written to UINT_MAX if we >>>>>>>> wrap around? >>>>>>>> If someone sets GCLogFileSize on the command line to be UINT_MAX we >>>>>>>> will never >>>>>>>> rotate the file, right? >>>>>>>> >>>>>>>> Also, we only call rotate_log() when we start a safepoint. If we wrap >>>>>>>> around >>>>>>>> once in write() but then call it again before a safepoint happens we can >>>>>>>> probably set _bytes_written to a value that looks small enough to not >>>>>>>> have to >>>>>>>> rotate the log. It seems to me that we would need a separate flag to >>>>>>>> say that we >>>>>>>> written enough to rotate the log. >>>>>>>> >>>>>>>> Bengt >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2/19/13 7:25 AM, Jesper Wilhelmsson wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review the following change: >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8008314/ >>>>>>>>> >>>>>>>>> Bug: https://jbs.oracle.com/bugs/browse/JDK-8008314 >>>>>>>>> >>>>>>>>> >>>>>>>>> The use of atomic::add(jlong,jlong*) breaks everything on ARM since >>>>>>>>> it uses >>>>>>>>> atomic::load(jlong) which isn't implemented. >>>>>>>>> >>>>>>>>> The add was used to update a counter in rotating log file handling, >>>>>>>>> but it >>>>>>>>> turns out that the counter that was updated doesn't need to be a jlong. >>>>>>>>> >>>>>>>>> The counter is used to indicate that it is time to do a log file >>>>>>>>> rotation and >>>>>>>>> by adding a saftey catch for overflow, we can use an uintx for the >>>>>>>>> counter. >>>>>>>>> >>>>>>>>> In practice this means that the upper "limit" for the log file size >>>>>>>>> becomes >>>>>>>>> UINX_MAX-1 (used to be UINT_MAX) since I change from < to <= in the >>>>>>>>> comparison >>>>>>>>> to the limit, but since this is not a hard limit the difference will >>>>>>>>> only be >>>>>>>>> noticeable when someone has written UINT_MAX characters to the log >>>>>>>>> file and >>>>>>>>> the next write will end up in the next log file part instead of in >>>>>>>>> the same >>>>>>>>> (which one could argue is a more correct behavior). >>>>>>>>> >>>>>>>>> Sine I changed all places where the counter was used I also fixed a >>>>>>>>> typo in >>>>>>>>> its name. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> /Jesper >>>>>>>> >>>>> >>> > From sitnikov.vladimir at gmail.com Thu Feb 21 08:35:54 2013 From: sitnikov.vladimir at gmail.com (Vladimir Sitnikov) Date: Thu, 21 Feb 2013 20:35:54 +0400 Subject: RFR (S): 8008314 - Unimplemented() Atomic::load breaks the applications In-Reply-To: <51264100.60807@oracle.com> References: <51231AE7.9070206@oracle.com> <512332FB.7020600@oracle.com> <51235162.9030702@oracle.com> <51236461.7060101@oracle.com> <51237589.4030105@oracle.com> <5123AF1E.2020603@oracle.com> <512448F9.6050609@oracle.com> <5124E727.5030908@oracle.com> <5124F47A.5070004@oracle.com> <51264100.60807@oracle.com> Message-ID: Is there a chance to get "rotate gc log on startup" option? I do respect the importance of rotation policy based on file size. However, log rotation on startup is crucial to have gc log at all in case of failure. I often face a problem when a customer reboots the application, and does not backup gc log beforehand. Regards, Vladimir Sitnikov From zhengyu.gu at oracle.com Thu Feb 21 09:01:20 2013 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Thu, 21 Feb 2013 17:01:20 +0000 Subject: hg: hsx/hsx24/hotspot: 8008071: Crashed in promote_malloc_records() with Kitchensink after 19 days Message-ID: <20130221170125.B76E347C40@hg.openjdk.java.net> Changeset: a398781bfe8b Author: zgu Date: 2013-02-21 07:50 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a398781bfe8b 8008071: Crashed in promote_malloc_records() with Kitchensink after 19 days Summary: Added NULL pointer check for arena size record Reviewed-by: sspitsyn, dholmes ! src/share/vm/services/memSnapshot.cpp From jesper.wilhelmsson at oracle.com Thu Feb 21 11:33:10 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 21 Feb 2013 20:33:10 +0100 Subject: RFR (S): 8008314 - Unimplemented() Atomic::load breaks the applications In-Reply-To: References: <51231AE7.9070206@oracle.com> <512332FB.7020600@oracle.com> <51235162.9030702@oracle.com> <51236461.7060101@oracle.com> <51237589.4030105@oracle.com> <5123AF1E.2020603@oracle.com> <512448F9.6050609@oracle.com> <5124E727.5030908@oracle.com> <5124F47A.5070004@oracle.com> <51264100.60807@oracle.com> Message-ID: <51267676.6090009@oracle.com> Hi Vladimir, Do I understand your question correct if I say that you want to save the log file from an old VM when a new VM is started instead of overwriting the old log file as is done today? This was discussed when log file rotation was introduced. Possible solutions could be to attach the PID to the log file name, or maybe use the timestamp when the VM is started as a way to get a unique file name. There is an RFE for this (JDK-6950794). I don't think anyone is actively working on this right now. There are also different external tools that can be used for log rotation that may have the functionality you are looking for. RFE JDK-7090324 is requesting better support for these tools, so I don't know if there are any problems with the current logging that makes it hard to use these tools. Cheers, /Jesper On 21/2/13 5:35 PM, Vladimir Sitnikov wrote: > Is there a chance to get "rotate gc log on startup" option? > > I do respect the importance of rotation policy based on file size. However, log > rotation on startup is crucial to have gc log at all in case of failure. > > I often face a problem when a customer reboots the application, and does not > backup gc log beforehand. > > Regards, > Vladimir Sitnikov > From vladimir.x.ivanov at oracle.com Thu Feb 21 11:33:32 2013 From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com) Date: Thu, 21 Feb 2013 19:33:32 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20130221193345.433DB47C4F@hg.openjdk.java.net> Changeset: c59b7900a2bd Author: roland Date: 2013-02-18 09:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c59b7900a2bd 8007959: Use expensive node logic for more math nodes Summary: use expensive node logic for other more math nodes. Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/subnode.hpp Changeset: 514efad5e81a Author: drchase Date: 2013-02-18 14:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/514efad5e81a 8008180: Several tests in compiler/5091921 need more time to run Summary: Added an explicit timeouts. Reviewed-by: kvn, twisti ! test/compiler/5091921/Test6850611.java ! test/compiler/5091921/Test6890943.java ! test/compiler/5091921/Test6905845.java ! test/compiler/5091921/Test6992759.java Changeset: a2bc322ca273 Author: drchase Date: 2013-02-18 15:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a2bc322ca273 7102300: performance warnings cause results diff failure in Test6890943 Summary: Strip lines matching the performance warning from the output before diff. Reviewed-by: kvn ! test/compiler/5091921/Test6890943.sh Changeset: ad736b4683b4 Author: kvn Date: 2013-02-18 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ad736b4683b4 8004867: VM crashing with assert "share/vm/opto/node.hpp:357 - assert(i < _max) failed: oob" Summary: Added few checks and early bailout from Superword optimization to avoid such cases in a future. Reviewed-by: roland, twisti ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp + test/compiler/8004867/TestIntAtomicCAS.java + test/compiler/8004867/TestIntAtomicOrdered.java + test/compiler/8004867/TestIntAtomicVolatile.java + test/compiler/8004867/TestIntUnsafeCAS.java + test/compiler/8004867/TestIntUnsafeOrdered.java + test/compiler/8004867/TestIntUnsafeVolatile.java Changeset: 2e4b16122164 Author: vlivanov Date: 2013-02-21 06:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2e4b16122164 Merge From christian.thalinger at oracle.com Thu Feb 21 11:48:24 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 21 Feb 2013 11:48:24 -0800 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <512508DE.70904@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> <50A24E00.3070200@oracle.com> <50A25720.1040405@oracle.com> <50A59010.5040001@oracle.com> <510C18F6.6010305@oracle.com> <511DAB26.2010808@oracle.com> <511DB3E0.6030606@oracle.com> <5122B5C3.1010908@oracle.com> <0153EC9C-4474-4B54-B215-6BE7BF2A7E1B@oracle.com> <512508DE.70904@oracle.com> Message-ID: <72E99204-0657-475A-AF91-E6454497186E@oracle.com> On Feb 20, 2013, at 9:33 AM, Mikael Vidstedt wrote: > > On 2/19/2013 12:01 PM, Christian Thalinger wrote: >> On Feb 18, 2013, at 3:14 PM, Mikael Vidstedt wrote: >> >>> A really good control question, thanks a lot for asking! >>> >>> As a matter of fact these changes are basically just doing what the compiler already does for us, so it's more about cleaning up the source code than reducing the size of the binary. So in theory these changes should have no impact on the binary size at all, but it actually turns out they do. Very specifically, the fact that I moved the same_page() function from being duplicated in the three os_.cpp files to having it be in globalDefinitions.cpp makes the binary grow a few bytes (54 bytes to be specific). The reason is a bit subtle: >>> >>> The same_page() function is (was) static in the respective os_*.cpp files. They are only ever used when the Verbose flag is true, and furthermore the Verbose option is a develop only flag, which means it is hardcoded to false in product. The compiler knows that's the case and eliminates the same_page() function completely. >>> >>> Since I moved it to globalDefinitions.cpp there's no way easy for the compiler to know that it is not being used, so it will actually keep the function. >>> >>> Unless there are strong opinions I'm not going to do anything about this. >>> >>> However, this made me question my earlier experiments with using the const bool = false construct in constantPool.cpp, because after all that is the exact same pattern. And it turns out that I must have done something wrong when I was performing the experiments, because when I do the same thing again now it turns out the compiler actually *does* deadcode eliminate the debug-only functions. So I take everything back and conclude that const bool = false is indeed a great way to make sure the debug code does not rot over time, and that the product binary will *not* contain the dead functions. Sorry for any confusion this may have caused. >>> >>> With all that in mind, here's another version of the webrev: >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev04/webrev/ >> src/share/vm/interpreter/interpreterRuntime.cpp: >> >> I suppose that #if 0 is to keep that code for...? Could we add a comment why we keep it? > > This was by "popular request" (from David Holmes) :) > > I personally don't know if and how this is being used. Note that ObjectSynchronizer::trace_locking is PRODUCT_RETURN and the non-product implementation in synchronizer.cpp is empty (modulo the comment saying "Don't know what to do here"), so one can question the value of keeping the any of the trace_locking functions, but they may be someone's favorite debugging tool. Until proven differently I will leave it in there for now. If somebody can help me provide a useful comment about how the code is actually being used then I will certainly add it, otherwise I'll keep this as it is. It's a mystery... > >> src/share/vm/oops/constantPool.cpp: >> >> So we use: >> >> + const bool debug_cpool = false; >> >> but we still have the DBG macro. Can't we have a static debug method that takes all printf arguments and prints them? The debug_cpool should make that method empty and the compiler can remove it. I really start to hate all these macros... > > I share your macro hate and I actually played around with removing the macros just as you say. There is one small problem with doing it that way, and that's the fact that a few of the printf:s print symbols names, and as part of that they need to create utf8 strings using sym->as_utf8(). The compiler can unfortunately not know that that function is for all intents and purposes a no-op, so it will keep the call even in product meaning increased binary size and it will also add to the runtime since it actually performs the call and creates the utf8 string. So I'm going to keep the macros for now. Right. Thanks for looking into it anyway. > > > I also moved the clamp_address_in_page to the globalDefinitions.hpp header file, meaning it will be inlined and dead code eliminated. > > New webrev here: > > http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev.05/webrev/ > > Final comments? Looks good. -- Chris > > Cheers, > Mikael > From John.Coomes at oracle.com Thu Feb 21 11:47:39 2013 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 21 Feb 2013 11:47:39 -0800 Subject: Result: New hotspot Group Member: Bengt Rutisson Message-ID: <20774.31195.904921.879954@oracle.com> The vote for Bengt Rutisson [1] is now closed. Yes: 10 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. John Coomes [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-February/008346.html From John.Coomes at oracle.com Thu Feb 21 11:49:16 2013 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 21 Feb 2013 11:49:16 -0800 Subject: Result: New hotspot Group Member: Stefan Karlsson Message-ID: <20774.31292.347190.757657@oracle.com> The vote for Stefan Karlsson [1] is now closed. Yes: 10 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. John Coomes [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-February/008347.html From christian.thalinger at oracle.com Thu Feb 21 11:50:57 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 21 Feb 2013 11:50:57 -0800 Subject: [RFC] Fix Zero and Shark builds In-Reply-To: <51260FE9.4090302@oracle.com> References: <1360776090.2524.22.camel@mercury> <511CA038.7050708@oracle.com> <1361395969.19150.80.camel@mercury> <5125F89B.40909@oracle.com> <51260255.5000508@oracle.com> <1361445990.2945.7.camel@mercury> <51260FE9.4090302@oracle.com> Message-ID: <5285BBAE-766C-4B52-8D6A-1547299AB9E2@oracle.com> On Feb 21, 2013, at 4:15 AM, David Holmes wrote: > On 21/02/2013 9:26 PM, Roman Kennke wrote: >> Am Donnerstag, den 21.02.2013, 21:17 +1000 schrieb David Holmes: >>> So far I've looked at the hotspot changes - but really this should also >>> go to hotspot-dev - cc'd >>> >>> I only see one change that isn't confined to zero/shark specific code >>> and that is in make/linux/makefiles/vm.make: >>> >>> ifeq ($(JVM_VARIANT_ZEROSHARK), true) >>> STATIC_CXX = false >>> else >>> ! ifeq ($(OPENJDK_TARGET_CPU), ppc64) >>> STATIC_CXX = false >>> else >>> STATIC_CXX = true >>> endif >>> endif >>> >>> this may conflict with the incoming AIX/ppc64 port. >> >> So far, the only supported ppc64 in Hotspot is Zero. At least to my >> knowledge. I am not sure why we need to explicitely link libstdc++ >> dynamically there though. I don't really see how this could affect >> anything outside Zero. And yes, it probably does affect the upcoming >> PPC64 port, but this needs to be sorted out anyway. > > Ok. Just wanted to flag it. > >>> My other comment on these changes is that you've now made the zero >>> hotspot build dependent on being part of a complete build - ie there >>> must be a spec.gmk/hotspot-spec.gmk for these variables to be defined. >>> You won't be able to build hotspot stand-alone. Is that what you intended? >> >> Probably not. Not sure how a standalone hotspot build works with the new >> build-system. (I would be very happy to do this to reduce turnaround >> even more.) What would I need to do? Move all Zero/Shark variables to >> hotspot-spec.gmk.in ? > > Hotspot has always been "self-configuring" on the build side. You can set a few variables to influence things but for the most part it detects things at build time. With the new build system hotspot was made "configure-aware". It was changed to include the spec.gmk file if it existed and the setting of variables potentially set by configure (and so in the spec.gmk file) was only done if not already set. Hence the two build approaches can co-exist. > > I don't know how a zero build was previously initiated but I could imagine it was something like: > > make ZEROARCH=zero Close: JVM_VARIANT_ZERO=true ZERO_BUILD=true; and a couple more. -- Chris > > then the zero-target together with the ZEROARCH value would trigger the right build logic to set all the necessary Zero flags. To maintain this you just need to be prepared for values to have been pre-set via spec.gmk. > > David > ----- > > >> Thanks, >> Roman >> >> From mikael.vidstedt at oracle.com Thu Feb 21 12:00:36 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 21 Feb 2013 12:00:36 -0800 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <51251015.5000501@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> <50A24E00.3070200@oracle.com> <50A25720.1040405@oracle.com> <50A59010.5040001@oracle.com> <510C18F6.6010305@oracle.com> <511DAB26.2010808@oracle.com> <511DB3E0.6030606@oracle.com> <5122B5C3.1010908@oracle.com> <0153EC9C-4474-4B54-B215-6BE7BF2A7E1B@oracle.com> <512508DE.70904@oracle.com> <51251015.5000501@oracle.com> Message-ID: <51267CE4.6090104@oracle.com> On 2013-02-20 10:04, Coleen Phillimore wrote: > On 2/20/2013 12:33 PM, Mikael Vidstedt wrote: >> >> On 2/19/2013 12:01 PM, Christian Thalinger wrote: >>> On Feb 18, 2013, at 3:14 PM, Mikael Vidstedt >>> wrote: >>> >>>> A really good control question, thanks a lot for asking! >>>> >>>> As a matter of fact these changes are basically just doing what the >>>> compiler already does for us, so it's more about cleaning up the >>>> source code than reducing the size of the binary. So in theory >>>> these changes should have no impact on the binary size at all, but >>>> it actually turns out they do. Very specifically, the fact that I >>>> moved the same_page() function from being duplicated in the three >>>> os_.cpp files to having it be in globalDefinitions.cpp makes >>>> the binary grow a few bytes (54 bytes to be specific). The reason >>>> is a bit subtle: >>>> >>>> The same_page() function is (was) static in the respective os_*.cpp >>>> files. They are only ever used when the Verbose flag is true, and >>>> furthermore the Verbose option is a develop only flag, which means >>>> it is hardcoded to false in product. The compiler knows that's the >>>> case and eliminates the same_page() function completely. >>>> >>>> Since I moved it to globalDefinitions.cpp there's no way easy for >>>> the compiler to know that it is not being used, so it will actually >>>> keep the function. >>>> >>>> Unless there are strong opinions I'm not going to do anything about >>>> this. >>>> >>>> However, this made me question my earlier experiments with using >>>> the const bool = false construct in constantPool.cpp, because after >>>> all that is the exact same pattern. And it turns out that I must >>>> have done something wrong when I was performing the experiments, >>>> because when I do the same thing again now it turns out the >>>> compiler actually *does* deadcode eliminate the debug-only >>>> functions. So I take everything back and conclude that const bool = >>>> false is indeed a great way to make sure the debug code does not >>>> rot over time, and that the product binary will *not* contain the >>>> dead functions. Sorry for any confusion this may have caused. >>>> >>>> With all that in mind, here's another version of the webrev: >>>> >>>> http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev04/webrev/ >>> src/share/vm/interpreter/interpreterRuntime.cpp: >>> >>> I suppose that #if 0 is to keep that code for...? Could we add a >>> comment why we keep it? >> >> This was by "popular request" (from David Holmes) :) >> >> I personally don't know if and how this is being used. Note that >> ObjectSynchronizer::trace_locking is PRODUCT_RETURN and the >> non-product implementation in synchronizer.cpp is empty (modulo the >> comment saying "Don't know what to do here"), so one can question the >> value of keeping the any of the trace_locking functions, but they may >> be someone's favorite debugging tool. Until proven differently I will >> leave it in there for now. If somebody can help me provide a useful >> comment about how the code is actually being used then I will >> certainly add it, otherwise I'll keep this as it is. > > If I remember correctly, this trace_locking code was associated with a > flag that we removed a long time ago. I don't think if we want to > implement TraceLocking we'd use this function. My vote is that it and > the ObjectMonitor:: version should be removed. Thanks Coleen, that makes sense. I've prepared a final version of the webrev with the trace_locking methods removed too: http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev.06/webrev/ Any final comments? Cheers, Mikael > > Coleen >> >>> src/share/vm/oops/constantPool.cpp: >>> >>> So we use: >>> >>> + const bool debug_cpool = false; >>> >>> but we still have the DBG macro. Can't we have a static debug >>> method that takes all printf arguments and prints them? The >>> debug_cpool should make that method empty and the compiler can >>> remove it. I really start to hate all these macros... >> >> I share your macro hate and I actually played around with removing >> the macros just as you say. There is one small problem with doing it >> that way, and that's the fact that a few of the printf:s print >> symbols names, and as part of that they need to create utf8 strings >> using sym->as_utf8(). The compiler can unfortunately not know that >> that function is for all intents and purposes a no-op, so it will >> keep the call even in product meaning increased binary size and it >> will also add to the runtime since it actually performs the call and >> creates the utf8 string. So I'm going to keep the macros for now. >> >> >> I also moved the clamp_address_in_page to the globalDefinitions.hpp >> header file, meaning it will be inlined and dead code eliminated. >> >> New webrev here: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev.05/webrev/ >> >> Final comments? >> >> Cheers, >> Mikael >> > From vladimir.danushevsky at oracle.com Thu Feb 21 13:33:41 2013 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Thu, 21 Feb 2013 21:33:41 +0000 Subject: hg: hsx/hotspot-main/hotspot: 11 new changesets Message-ID: <20130221213405.D03C147C55@hg.openjdk.java.net> Changeset: 579f6adb7f51 Author: jprovino Date: 2013-02-05 13:32 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/579f6adb7f51 8003539: Minimal VM don't react to -Dcom.sun.management and -XX:+ManagementServer Summary: A warning message should be displayed if these options are used with the Minimal VM. Reviewed-by: dholmes, dsamersoff ! src/share/vm/runtime/arguments.cpp Changeset: 9e2da96f9976 Author: bpittore Date: 2013-02-08 16:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9e2da96f9976 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 6c2da81297c5 Author: kvn Date: 2013-02-12 09:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6c2da81297c5 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 84a926fe53d0 Author: bpittore Date: 2013-01-24 13:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/84a926fe53d0 8005722: Assert in c1_LIR.hpp incorrect wrt to number of register operands Summary: In LIR_OpVisitState::visit() the receiver operand is processed twice Reviewed-by: roland, vladidan ! src/share/vm/c1/c1_LIR.cpp Changeset: cf9a2071eeac Author: jprovino Date: 2013-02-14 11:07 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cf9a2071eeac 8006878: Some non-existent GC source files are in the minimalVM exclude list. Summary: cmsPermGen.cpp, psPermGen.cpp have been removed. yieldWorkingGroup.cpp typo is fixed. immutableSpace.cpp was in the list twice. Reviewed-by: dholmes, jmasa ! make/excludeSrc.make ! src/share/vm/utilities/yieldingWorkgroup.cpp Changeset: 1605eef8e11e Author: jprovino Date: 2013-02-14 11:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1605eef8e11e 8003581: UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS Summary: Fix warning messages when selected garbage collectors are excluded from the minimal jvm. Reviewed-by: dholmes, cjplummer ! src/share/vm/runtime/arguments.cpp Changeset: 9c7d0948523f Author: jprovino Date: 2013-02-15 14:42 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9c7d0948523f Merge Changeset: 1ba18258caa4 Author: bpittore Date: 2013-02-15 21:53 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1ba18258caa4 Merge ! src/share/vm/runtime/arguments.cpp Changeset: abf488c22e09 Author: bpittore Date: 2013-02-20 23:29 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/abf488c22e09 Merge Changeset: 2af22eb04623 Author: vladidan Date: 2013-02-21 09:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2af22eb04623 Merge Changeset: ed96c6015470 Author: vladidan Date: 2013-02-21 11:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ed96c6015470 Merge From tao.mao at oracle.com Thu Feb 21 15:48:21 2013 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 21 Feb 2013 15:48:21 -0800 Subject: Review Request: 8008451: Make mac builds on 10.8 work on 10.7 In-Reply-To: <20773.10674.494494.347984@oracle.com> References: <511D0FCD.4020803@oracle.com> <93A5D67B-22E9-4EB7-980E-3C8B3646DE6B@oracle.com> <511DF527.4080208@oracle.com> <511E0491.7070508@oracle.com> <5124E33C.3070903@oracle.com> <20773.10674.494494.347984@oracle.com> Message-ID: <5126B245.7040008@oracle.com> Please reply to this thread to make sure all interested parties can see it. Tao On 2/20/2013 11:53 AM, John Coomes wrote: > Erik Joelsson (erik.joelsson at oracle.com) wrote: >> I was wrong, just setting the macros below did not generate 10.7 >> compatible bits when built on 10.8. Since I already pushed the old >> solution (except for hotspot), I created a new bug. Here is a new set of >> patches, combining -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 and >> -mmacosx-version-min=10.7.0 and also setting the latter on the link >> command line. This combination both generates compatible binaries and >> treats newer API calls as errors, all verified. >> >> Sine the two parameters take their argument in different formats, the >> handling of defaults is a bit more complicated. The variable being sent >> around and that you can override on the command line is now >> MACOSX_VERSION_MIN=10.7.0, matching the parameter to the compiler/linker. >> >> It would be good if someone from hotspot could review the hotspot changes. >> >> http://cr.openjdk.java.net/~erikj/8008451/webrev.hotspot.01/ > The hotspot changes look good to me. > > -John > >> http://cr.openjdk.java.net/~erikj/8008451/webrev.root.01/ >> http://cr.openjdk.java.net/~erikj/8008451/webrev.jdk.01/ >> >> /Erik >> >> On 2013-02-15 10:49, Erik Joelsson wrote: >>> >>> On 2013-02-15 09:43, Erik Joelsson wrote: >>>> On 2013-02-14 18:04, David DeHaven wrote: >>>>>> Here are a series of patches that adds the following to all native >>>>>> compile lines on macosx: >>>>>> >>>>>> -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 >>>>>> -DMAC_OS_X_VERSION_MIN_REQUIRED=1070 >>>>> I know I'm not a reviewer, but I have an opinion anyways :) >>>>> >>>>> Using "-mmacosx-version-min=10.7" seems more appropriate for the >>>>> latter, this is passed to the linker as well which I believe sets >>>>> version information in the Mach-O headers (in the form of a load >>>>> command) to prevent it from being loaded on older systems. The >>>>> MIN_REQUIRED macro is set to a value that matches what's passed to >>>>> the -mmacosx-version-min argument, so it doesn't need to be provided. >>>>> >>>>> >>>> The effect of the -mmacosx-version-min=10.7 when sent to the linker >>>> is to make any calls to newer APIs "softlinked". This means the >>>> library will still load fine on the older OS, but the application is >>>> responsible for only actually making the newer calls if they are >>>> available. This is a good feature if you knowingly want to support >>>> multiple versions of the OS and still use features in the newer OS >>>> when available. I do not believe we have the need for that and if we >>>> ever do, then these parameters will need to change. >>>> >>> It's true -mmacosx-version-min= also sets the macro >>> MAC_OS_X_VERSION_MIN_REQUIRED=, but I see no gain in changing just one >>> of them to something else just because it works. The format of the >>> parameter is also different (10.7 vs 1070) which would require us to >>> add logic for converting between the two. >>> >>> /Erik From christian.thalinger at oracle.com Thu Feb 21 18:40:15 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 21 Feb 2013 18:40:15 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK Message-ID: http://cr.openjdk.java.net/~twisti/8006965 8006965: test_gamma should run with import JDK Reviewed-by: Right now test_gamma runs with the boot JDK which is JDK n-1 (where JDK n is the version we are actually compiling for). This setup is unsupported and thus should not be done during HotSpot builds. The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when running test_gamma. make/bsd/makefiles/buildtree.make make/defs.make make/linux/makefiles/buildtree.make make/solaris/makefiles/buildtree.make From coleen.phillimore at oracle.com Thu Feb 21 18:46:26 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 21 Feb 2013 21:46:26 -0500 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <51267CE4.6090104@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> <50A24E00.3070200@oracle.com> <50A25720.1040405@oracle.com> <50A59010.5040001@oracle.com> <510C18F6.6010305@oracle.com> <511DAB26.2010808@oracle.com> <511DB3E0.6030606@oracle.com> <5122B5C3.1010908@oracle.com> <0153EC9C-4474-4B54-B215-6BE7BF2A7E1B@oracle.com> <512508DE.70904@oracle.com> <51251015.5000501@oracle.com> <51267CE4.6090104@oracle.com> Message-ID: <5126DC02.1050502@oracle.com> No final comments. It looks good to me. Coleen On 2/21/2013 3:00 PM, Mikael Vidstedt wrote: > > On 2013-02-20 10:04, Coleen Phillimore wrote: >> On 2/20/2013 12:33 PM, Mikael Vidstedt wrote: >>> >>> On 2/19/2013 12:01 PM, Christian Thalinger wrote: >>>> On Feb 18, 2013, at 3:14 PM, Mikael Vidstedt >>>> wrote: >>>> >>>>> A really good control question, thanks a lot for asking! >>>>> >>>>> As a matter of fact these changes are basically just doing what >>>>> the compiler already does for us, so it's more about cleaning up >>>>> the source code than reducing the size of the binary. So in theory >>>>> these changes should have no impact on the binary size at all, but >>>>> it actually turns out they do. Very specifically, the fact that I >>>>> moved the same_page() function from being duplicated in the three >>>>> os_.cpp files to having it be in globalDefinitions.cpp makes >>>>> the binary grow a few bytes (54 bytes to be specific). The reason >>>>> is a bit subtle: >>>>> >>>>> The same_page() function is (was) static in the respective >>>>> os_*.cpp files. They are only ever used when the Verbose flag is >>>>> true, and furthermore the Verbose option is a develop only flag, >>>>> which means it is hardcoded to false in product. The compiler >>>>> knows that's the case and eliminates the same_page() function >>>>> completely. >>>>> >>>>> Since I moved it to globalDefinitions.cpp there's no way easy for >>>>> the compiler to know that it is not being used, so it will >>>>> actually keep the function. >>>>> >>>>> Unless there are strong opinions I'm not going to do anything >>>>> about this. >>>>> >>>>> However, this made me question my earlier experiments with using >>>>> the const bool = false construct in constantPool.cpp, because >>>>> after all that is the exact same pattern. And it turns out that I >>>>> must have done something wrong when I was performing the >>>>> experiments, because when I do the same thing again now it turns >>>>> out the compiler actually *does* deadcode eliminate the debug-only >>>>> functions. So I take everything back and conclude that const bool >>>>> = false is indeed a great way to make sure the debug code does not >>>>> rot over time, and that the product binary will *not* contain the >>>>> dead functions. Sorry for any confusion this may have caused. >>>>> >>>>> With all that in mind, here's another version of the webrev: >>>>> >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev04/webrev/ >>>> src/share/vm/interpreter/interpreterRuntime.cpp: >>>> >>>> I suppose that #if 0 is to keep that code for...? Could we add a >>>> comment why we keep it? >>> >>> This was by "popular request" (from David Holmes) :) >>> >>> I personally don't know if and how this is being used. Note that >>> ObjectSynchronizer::trace_locking is PRODUCT_RETURN and the >>> non-product implementation in synchronizer.cpp is empty (modulo the >>> comment saying "Don't know what to do here"), so one can question >>> the value of keeping the any of the trace_locking functions, but >>> they may be someone's favorite debugging tool. Until proven >>> differently I will leave it in there for now. If somebody can help >>> me provide a useful comment about how the code is actually being >>> used then I will certainly add it, otherwise I'll keep this as it is. >> >> If I remember correctly, this trace_locking code was associated with >> a flag that we removed a long time ago. I don't think if we want to >> implement TraceLocking we'd use this function. My vote is that it >> and the ObjectMonitor:: version should be removed. > > Thanks Coleen, that makes sense. I've prepared a final version of the > webrev with the trace_locking methods removed too: > > http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev.06/webrev/ > > Any final comments? > > Cheers, > Mikael > >> >> Coleen >>> >>>> src/share/vm/oops/constantPool.cpp: >>>> >>>> So we use: >>>> >>>> + const bool debug_cpool = false; >>>> >>>> but we still have the DBG macro. Can't we have a static debug >>>> method that takes all printf arguments and prints them? The >>>> debug_cpool should make that method empty and the compiler can >>>> remove it. I really start to hate all these macros... >>> >>> I share your macro hate and I actually played around with removing >>> the macros just as you say. There is one small problem with doing it >>> that way, and that's the fact that a few of the printf:s print >>> symbols names, and as part of that they need to create utf8 strings >>> using sym->as_utf8(). The compiler can unfortunately not know that >>> that function is for all intents and purposes a no-op, so it will >>> keep the call even in product meaning increased binary size and it >>> will also add to the runtime since it actually performs the call and >>> creates the utf8 string. So I'm going to keep the macros for now. >>> >>> >>> I also moved the clamp_address_in_page to the globalDefinitions.hpp >>> header file, meaning it will be inlined and dead code eliminated. >>> >>> New webrev here: >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev.05/webrev/ >>> >>> Final comments? >>> >>> Cheers, >>> Mikael >>> >> > From david.holmes at oracle.com Thu Feb 21 18:59:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Feb 2013 12:59:21 +1000 Subject: Please review: 8006498 and 8008474 In-Reply-To: <512633D5.6040202@oracle.com> References: <5125448B.8090107@oracle.com> <5125685F.5070907@oracle.com> <51261EDD.2020309@oracle.com> <512633D5.6040202@oracle.com> Message-ID: <5126DF09.2040207@oracle.com> On 22/02/2013 12:48 AM, JOSEPH PROVINO wrote: > Actually, from looking at this again, I thought David was suggesting > that -Wundef > should be added to ACCEPTABLE_WARNINGS for linux and bsd. I was being ambivalent - I just wanted to see consistency. We should see where Mikael is adding -Wunused David > joe > > On 2/21/2013 8:19 AM, Zhengyu Gu wrote: >> Agree with David, -Wundef should go to CFLAGS_WARN/DEFAULT on Solaris >> if there is not particular reason not to. >> >> Other than that, look good to me. >> >> -Zhengyu >> >> On 2/20/2013 7:20 PM, David Holmes wrote: >>> On 21/02/2013 7:47 AM, JOSEPH PROVINO wrote: >>>> 8006498: ASSERT and other symbols used incorrectly with #if are >>>> supposed to be defined or not >>>> >>>> 8008474: -Wundef should be added to the build to catch #if references >>>> to undefined macros. >>>> >>>> >>>> Webrev is here: http://cr.openjdk.java.net/~jprovino/8006498/webrev.00/ >>> >>> On bsd and linux you simply added -Wundef directly to the CFLAGS: >>> >>> +CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(ACCEPTABLE_WARNINGS) >>> -Wundef >>> >>> but on Solaris you added it to ADDITIONAL_WARNINGS: >>> >>> +ADDITIONAL_WARNINGS = -Wpointer-arith -Wconversion -Wsign-compare >>> -Wundef >>> >>> I guess it is a little confusing as to whether ACCEPTABLE_WARNINGS >>> and ADDITIONAL_WARNINGS are meant to be the same thing. >>> >>> Otherwise all the #if -> #ifdef etc seem okay. >>> >>> David >>> >>>> Thanks. >>>> >>>> joe >> > From david.holmes at oracle.com Thu Feb 21 19:13:37 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Feb 2013 13:13:37 +1000 Subject: Please review: 8006498 and 8008474 In-Reply-To: <5126DF09.2040207@oracle.com> References: <5125448B.8090107@oracle.com> <5125685F.5070907@oracle.com> <51261EDD.2020309@oracle.com> <512633D5.6040202@oracle.com> <5126DF09.2040207@oracle.com> Message-ID: <5126E261.6080601@oracle.com> On 22/02/2013 12:59 PM, David Holmes wrote: > On 22/02/2013 12:48 AM, JOSEPH PROVINO wrote: >> Actually, from looking at this again, I thought David was suggesting >> that -Wundef >> should be added to ACCEPTABLE_WARNINGS for linux and bsd. > > I was being ambivalent - I just wanted to see consistency. We should see > where Mikael is adding -Wunused Ha! Now this really muddies the waters (this is linux only): ! ADDITIONAL_WARNINGS = -Wunused-function ! ! CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(ACCEPTABLE_WARNINGS) $(ADDITIONAL_WARNINGS) David > > David > >> joe >> >> On 2/21/2013 8:19 AM, Zhengyu Gu wrote: >>> Agree with David, -Wundef should go to CFLAGS_WARN/DEFAULT on Solaris >>> if there is not particular reason not to. >>> >>> Other than that, look good to me. >>> >>> -Zhengyu >>> >>> On 2/20/2013 7:20 PM, David Holmes wrote: >>>> On 21/02/2013 7:47 AM, JOSEPH PROVINO wrote: >>>>> 8006498: ASSERT and other symbols used incorrectly with #if are >>>>> supposed to be defined or not >>>>> >>>>> 8008474: -Wundef should be added to the build to catch #if references >>>>> to undefined macros. >>>>> >>>>> >>>>> Webrev is here: >>>>> http://cr.openjdk.java.net/~jprovino/8006498/webrev.00/ >>>> >>>> On bsd and linux you simply added -Wundef directly to the CFLAGS: >>>> >>>> +CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(ACCEPTABLE_WARNINGS) >>>> -Wundef >>>> >>>> but on Solaris you added it to ADDITIONAL_WARNINGS: >>>> >>>> +ADDITIONAL_WARNINGS = -Wpointer-arith -Wconversion -Wsign-compare >>>> -Wundef >>>> >>>> I guess it is a little confusing as to whether ACCEPTABLE_WARNINGS >>>> and ADDITIONAL_WARNINGS are meant to be the same thing. >>>> >>>> Otherwise all the #if -> #ifdef etc seem okay. >>>> >>>> David >>>> >>>>> Thanks. >>>>> >>>>> joe >>> >> From david.holmes at oracle.com Thu Feb 21 19:16:14 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Feb 2013 13:16:14 +1000 Subject: RFR: 8003310: Enable -Wunused when compiling with GCC In-Reply-To: <51267CE4.6090104@oracle.com> References: <50A1C598.4050904@oracle.com> <50A1DEE5.8090606@oracle.com> <50A24E00.3070200@oracle.com> <50A25720.1040405@oracle.com> <50A59010.5040001@oracle.com> <510C18F6.6010305@oracle.com> <511DAB26.2010808@oracle.com> <511DB3E0.6030606@oracle.com> <5122B5C3.1010908@oracle.com> <0153EC9C-4474-4B54-B215-6BE7BF2A7E1B@oracle.com> <512508DE.70904@oracle.com> <51251015.5000501@oracle.com> <51267CE4.6090104@oracle.com> Message-ID: <5126E2FE.9060200@oracle.com> One final comment - please liaise with Joe Provino who is adding -Wundef so we can get a consistent approach as to where these -Wxxx flags get added. :) (Don't know what I was looking at with the trace_locking stuff - it ends up as an empty method.) David On 22/02/2013 6:00 AM, Mikael Vidstedt wrote: > > On 2013-02-20 10:04, Coleen Phillimore wrote: >> On 2/20/2013 12:33 PM, Mikael Vidstedt wrote: >>> >>> On 2/19/2013 12:01 PM, Christian Thalinger wrote: >>>> On Feb 18, 2013, at 3:14 PM, Mikael Vidstedt >>>> wrote: >>>> >>>>> A really good control question, thanks a lot for asking! >>>>> >>>>> As a matter of fact these changes are basically just doing what the >>>>> compiler already does for us, so it's more about cleaning up the >>>>> source code than reducing the size of the binary. So in theory >>>>> these changes should have no impact on the binary size at all, but >>>>> it actually turns out they do. Very specifically, the fact that I >>>>> moved the same_page() function from being duplicated in the three >>>>> os_.cpp files to having it be in globalDefinitions.cpp makes >>>>> the binary grow a few bytes (54 bytes to be specific). The reason >>>>> is a bit subtle: >>>>> >>>>> The same_page() function is (was) static in the respective os_*.cpp >>>>> files. They are only ever used when the Verbose flag is true, and >>>>> furthermore the Verbose option is a develop only flag, which means >>>>> it is hardcoded to false in product. The compiler knows that's the >>>>> case and eliminates the same_page() function completely. >>>>> >>>>> Since I moved it to globalDefinitions.cpp there's no way easy for >>>>> the compiler to know that it is not being used, so it will actually >>>>> keep the function. >>>>> >>>>> Unless there are strong opinions I'm not going to do anything about >>>>> this. >>>>> >>>>> However, this made me question my earlier experiments with using >>>>> the const bool = false construct in constantPool.cpp, because after >>>>> all that is the exact same pattern. And it turns out that I must >>>>> have done something wrong when I was performing the experiments, >>>>> because when I do the same thing again now it turns out the >>>>> compiler actually *does* deadcode eliminate the debug-only >>>>> functions. So I take everything back and conclude that const bool = >>>>> false is indeed a great way to make sure the debug code does not >>>>> rot over time, and that the product binary will *not* contain the >>>>> dead functions. Sorry for any confusion this may have caused. >>>>> >>>>> With all that in mind, here's another version of the webrev: >>>>> >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev04/webrev/ >>>> src/share/vm/interpreter/interpreterRuntime.cpp: >>>> >>>> I suppose that #if 0 is to keep that code for...? Could we add a >>>> comment why we keep it? >>> >>> This was by "popular request" (from David Holmes) :) >>> >>> I personally don't know if and how this is being used. Note that >>> ObjectSynchronizer::trace_locking is PRODUCT_RETURN and the >>> non-product implementation in synchronizer.cpp is empty (modulo the >>> comment saying "Don't know what to do here"), so one can question the >>> value of keeping the any of the trace_locking functions, but they may >>> be someone's favorite debugging tool. Until proven differently I will >>> leave it in there for now. If somebody can help me provide a useful >>> comment about how the code is actually being used then I will >>> certainly add it, otherwise I'll keep this as it is. >> >> If I remember correctly, this trace_locking code was associated with a >> flag that we removed a long time ago. I don't think if we want to >> implement TraceLocking we'd use this function. My vote is that it and >> the ObjectMonitor:: version should be removed. > > Thanks Coleen, that makes sense. I've prepared a final version of the > webrev with the trace_locking methods removed too: > > http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev.06/webrev/ > > Any final comments? > > Cheers, > Mikael > >> >> Coleen >>> >>>> src/share/vm/oops/constantPool.cpp: >>>> >>>> So we use: >>>> >>>> + const bool debug_cpool = false; >>>> >>>> but we still have the DBG macro. Can't we have a static debug >>>> method that takes all printf arguments and prints them? The >>>> debug_cpool should make that method empty and the compiler can >>>> remove it. I really start to hate all these macros... >>> >>> I share your macro hate and I actually played around with removing >>> the macros just as you say. There is one small problem with doing it >>> that way, and that's the fact that a few of the printf:s print >>> symbols names, and as part of that they need to create utf8 strings >>> using sym->as_utf8(). The compiler can unfortunately not know that >>> that function is for all intents and purposes a no-op, so it will >>> keep the call even in product meaning increased binary size and it >>> will also add to the runtime since it actually performs the call and >>> creates the utf8 string. So I'm going to keep the macros for now. >>> >>> >>> I also moved the clamp_address_in_page to the globalDefinitions.hpp >>> header file, meaning it will be inlined and dead code eliminated. >>> >>> New webrev here: >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/8003310/webrev.05/webrev/ >>> >>> Final comments? >>> >>> Cheers, >>> Mikael >>> >> > From david.holmes at oracle.com Thu Feb 21 19:21:57 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Feb 2013 13:21:57 +1000 Subject: [RFC] Fix Zero and Shark builds In-Reply-To: <5285BBAE-766C-4B52-8D6A-1547299AB9E2@oracle.com> References: <1360776090.2524.22.camel@mercury> <511CA038.7050708@oracle.com> <1361395969.19150.80.camel@mercury> <5125F89B.40909@oracle.com> <51260255.5000508@oracle.com> <1361445990.2945.7.camel@mercury> <51260FE9.4090302@oracle.com> <5285BBAE-766C-4B52-8D6A-1547299AB9E2@oracle.com> Message-ID: <5126E455.2020409@oracle.com> On 22/02/2013 5:50 AM, Christian Thalinger wrote: > > On Feb 21, 2013, at 4:15 AM, David Holmes wrote: > >> On 21/02/2013 9:26 PM, Roman Kennke wrote: >>> Am Donnerstag, den 21.02.2013, 21:17 +1000 schrieb David Holmes: >>>> So far I've looked at the hotspot changes - but really this should also >>>> go to hotspot-dev - cc'd >>>> >>>> I only see one change that isn't confined to zero/shark specific code >>>> and that is in make/linux/makefiles/vm.make: >>>> >>>> ifeq ($(JVM_VARIANT_ZEROSHARK), true) >>>> STATIC_CXX = false >>>> else >>>> ! ifeq ($(OPENJDK_TARGET_CPU), ppc64) >>>> STATIC_CXX = false >>>> else >>>> STATIC_CXX = true >>>> endif >>>> endif >>>> >>>> this may conflict with the incoming AIX/ppc64 port. >>> >>> So far, the only supported ppc64 in Hotspot is Zero. At least to my >>> knowledge. I am not sure why we need to explicitely link libstdc++ >>> dynamically there though. I don't really see how this could affect >>> anything outside Zero. And yes, it probably does affect the upcoming >>> PPC64 port, but this needs to be sorted out anyway. >> >> Ok. Just wanted to flag it. >> >>>> My other comment on these changes is that you've now made the zero >>>> hotspot build dependent on being part of a complete build - ie there >>>> must be a spec.gmk/hotspot-spec.gmk for these variables to be defined. >>>> You won't be able to build hotspot stand-alone. Is that what you intended? >>> >>> Probably not. Not sure how a standalone hotspot build works with the new >>> build-system. (I would be very happy to do this to reduce turnaround >>> even more.) What would I need to do? Move all Zero/Shark variables to >>> hotspot-spec.gmk.in ? >> >> Hotspot has always been "self-configuring" on the build side. You can set a few variables to influence things but for the most part it detects things at build time. With the new build system hotspot was made "configure-aware". It was changed to include the spec.gmk file if it existed and the setting of variables potentially set by configure (and so in the spec.gmk file) was only done if not already set. Hence the two build approaches can co-exist. >> >> I don't know how a zero build was previously initiated but I could imagine it was something like: >> >> make ZEROARCH=zero > > Close: JVM_VARIANT_ZERO=true ZERO_BUILD=true; and a couple more. Ah! Then it was already using some variables that would otherwise come from configure. But now you would have to pass values for: OPENJDK_TARGET_CPU_LEGACY_LIB OPENJDK_TARGET_CPU_BITS OPENJDK_TARGET_CPU OPENJDK_TARGET_CPU_ENDIAN which is probably not what you would want to have to do. David ----- > -- Chris > >> >> then the zero-target together with the ZEROARCH value would trigger the right build logic to set all the necessary Zero flags. To maintain this you just need to be prepared for values to have been pre-set via spec.gmk. >> >> David >> ----- >> >> >>> Thanks, >>> Roman >>> >>> > From david.holmes at oracle.com Thu Feb 21 20:10:23 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Feb 2013 14:10:23 +1000 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: References: Message-ID: <5126EFAF.5000101@oracle.com> Hi Christian, cc'ing build-dev On 22/02/2013 12:40 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8006965 > > 8006965: test_gamma should run with import JDK > Reviewed-by: > > Right now test_gamma runs with the boot JDK which is JDK n-1 (where > JDK n is the version we are actually compiling for). This setup is > unsupported and thus should not be done during HotSpot builds. > > The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when > running test_gamma. First, the simplest change seems to me to just to do: ! MAKE_ARGS += JAVA_HOME=$(JDK_IMPORT_PATH) and not need to change anything in buildtree.make. But this forces everyone outside of Oracle (and some inside) to have to set ALT_JDK_IMPORT_PATH explicitly otherwise they get: JDK_IMPORT_PATH=$(SLASH_JAVA)/re/j2se/$(JDK_VERSION)/promoted/latest/binaries/$(PLATFORM) And the boot JDK is only JDK n-1 for our official builds - people can use whatever boot JDK works for them including latest JDK. I see the problem you want to fix, and I know why you've hit it, but this doesn't seem like a general solution. I don't know what to suggest. > make/bsd/makefiles/buildtree.make > make/defs.make Why did you add: MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) ? David ----- > make/linux/makefiles/buildtree.make > make/solaris/makefiles/buildtree.make > From coleen.phillimore at oracle.com Thu Feb 21 21:12:01 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 22 Feb 2013 00:12:01 -0500 Subject: RFR(M): 7165259 Remove BugSpot In-Reply-To: <9496CFBE-4F80-490A-9A07-C2B58447F532@oracle.com> References: <9496CFBE-4F80-490A-9A07-C2B58447F532@oracle.com> Message-ID: <5126FE21.6010608@oracle.com> This looks great to me. Thanks! Coleen On 2/21/2013 10:38 AM, Staffan Larsen wrote: > Please review the following change to remove the BugSpot UI for the Serviceability Agent. My understanding is that BugSpot was intended as a more general native debugger not only focused on the JVM, but that it was never fully implemented. I don't think there is a need for a general-purpose debugger in SA and would like to clean up the code. One effect of this change is that PStack and PMap will no longer be able to operate on executables other than the JVM. > > This change was first proposed last year in this thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2012-April/005811.html > > This change also removes some old JVMDI code in SA (JVMDI is no longer supported in HotSpot). > > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7165259 > > webrev: http://cr.openjdk.java.net/~sla/7165259/webrev.00/ > > > Thanks, > /Staffan From staffan.larsen at oracle.com Fri Feb 22 00:58:47 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 22 Feb 2013 09:58:47 +0100 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: References: Message-ID: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. Thanks, /Staffan On 22 feb 2013, at 03:40, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8006965 > > 8006965: test_gamma should run with import JDK > Reviewed-by: > > Right now test_gamma runs with the boot JDK which is JDK n-1 (where > JDK n is the version we are actually compiling for). This setup is > unsupported and thus should not be done during HotSpot builds. > > The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when > running test_gamma. > > make/bsd/makefiles/buildtree.make > make/defs.make > make/linux/makefiles/buildtree.make > make/solaris/makefiles/buildtree.make > From markus.gronlund at oracle.com Fri Feb 22 01:03:08 2013 From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=) Date: Fri, 22 Feb 2013 01:03:08 -0800 (PST) Subject: RFR(M): 7165259 Remove BugSpot In-Reply-To: <9496CFBE-4F80-490A-9A07-C2B58447F532@oracle.com> References: <9496CFBE-4F80-490A-9A07-C2B58447F532@oracle.com> Message-ID: Hi Staffan, Looks good (not a Reviewer). Thanks for taking on this cleanup. Markus -----Original Message----- From: Staffan Larsen Sent: den 21 februari 2013 16:39 To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Developers Subject: RFR(M): 7165259 Remove BugSpot Please review the following change to remove the BugSpot UI for the Serviceability Agent. My understanding is that BugSpot was intended as a more general native debugger not only focused on the JVM, but that it was never fully implemented. I don't think there is a need for a general-purpose debugger in SA and would like to clean up the code. One effect of this change is that PStack and PMap will no longer be able to operate on executables other than the JVM. This change was first proposed last year in this thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2012-April/005811.html This change also removes some old JVMDI code in SA (JVMDI is no longer supported in HotSpot). bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7165259 webrev: http://cr.openjdk.java.net/~sla/7165259/webrev.00/ Thanks, /Staffan From staffan.larsen at oracle.com Fri Feb 22 01:07:08 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 22 Feb 2013 10:07:08 +0100 Subject: RFR(M): 7165259 Remove BugSpot In-Reply-To: References: <9496CFBE-4F80-490A-9A07-C2B58447F532@oracle.com> Message-ID: <0F14BCF9-CF02-4F48-A8A3-3C0B26B6507F@oracle.com> Coleen, Markus: Thanks! On 22 feb 2013, at 10:03, Markus Gr?nlund wrote: > Hi Staffan, > > Looks good (not a Reviewer). > > Thanks for taking on this cleanup. > > Markus > > -----Original Message----- > From: Staffan Larsen > Sent: den 21 februari 2013 16:39 > To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Developers > Subject: RFR(M): 7165259 Remove BugSpot > > Please review the following change to remove the BugSpot UI for the Serviceability Agent. My understanding is that BugSpot was intended as a more general native debugger not only focused on the JVM, but that it was never fully implemented. I don't think there is a need for a general-purpose debugger in SA and would like to clean up the code. One effect of this change is that PStack and PMap will no longer be able to operate on executables other than the JVM. > > This change was first proposed last year in this thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2012-April/005811.html > > This change also removes some old JVMDI code in SA (JVMDI is no longer supported in HotSpot). > > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7165259 > > webrev: http://cr.openjdk.java.net/~sla/7165259/webrev.00/ > > > Thanks, > /Staffan From volker.simonis at gmail.com Fri Feb 22 01:14:09 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 22 Feb 2013 10:14:09 +0100 Subject: [RFC] Fix Zero and Shark builds In-Reply-To: <51260255.5000508@oracle.com> References: <1360776090.2524.22.camel@mercury> <511CA038.7050708@oracle.com> <1361395969.19150.80.camel@mercury> <5125F89B.40909@oracle.com> <51260255.5000508@oracle.com> Message-ID: Good catch! This will indeed affect the upcoming AIX/ppc64 port but I think it can be easily fixed. As far as I understand, the intention of the change is to statically link libstsc++ for the Zero build on ppc64, so why don't change it this way: 242 ifeq ($(JVM_VARIANT_ZEROSHARK), true) 243 STATIC_CXX = false 244 else ifeq ($(JVM_VARIANT_ZERO), true) 245 ifeq ($(OPENJDK_TARGET_CPU), ppc64) 246 STATIC_CXX = false 247 else 248 STATIC_CXX = true 249 endif endif 250 endif Thank you and best regards, Volker On Thu, Feb 21, 2013 at 12:17 PM, David Holmes wrote: > So far I've looked at the hotspot changes - but really this should also go > to hotspot-dev - cc'd > > I only see one change that isn't confined to zero/shark specific code and > that is in make/linux/makefiles/vm.make: > > ifeq ($(JVM_VARIANT_ZEROSHARK), true) > STATIC_CXX = false > else > ! ifeq ($(OPENJDK_TARGET_CPU), ppc64) > STATIC_CXX = false > else > STATIC_CXX = true > endif > endif > > this may conflict with the incoming AIX/ppc64 port. > > My other comment on these changes is that you've now made the zero hotspot > build dependent on being part of a complete build - ie there must be a > spec.gmk/hotspot-spec.gmk for these variables to be defined. You won't be > able to build hotspot stand-alone. Is that what you intended? > > David > ----- > > > > On 21/02/2013 8:36 PM, Erik Joelsson wrote: >> >> >> >> On 2013-02-20 22:32, Roman Kennke wrote: >>> >>> >>> Thanks for the review! I made the following changes: >>> >>> - I moved all platform-foo to platform.m4, in >>> PLATFORM_SETUP_LEGACY_VARS. Little problem: in this section I don't know >>> about JVM_VARIANTS_ZERO yet, therefore I set those vars unconditionally. >>> (But I propagate them to Make conditionally, see below). *However* those >>> variables might actually be useful for non-Zero builds, if you look at >>> the places where they're used, in non-Zero builds we find hardcoded >>> values/strings for the various platforms, where the Zero way seems more >>> elegant here. >>> - I replaced ZERO_ENDIANNESS with the equivalent >>> OPENJDK_TARGET_CPU_ENDIAN. >>> - I replaced ARCH_DATA_MODEL with OPENJDK_TARGET_CPU_BITS. >>> - I replaced ZERO_LIBARCH with OPENJDK_TARGET_CPU_LEGACY_LIB. >>> - ZERO_ARCHFLAG is still needed for build on s390, to enable the correct >>> ABI (by setting -m31). >>> - ZERO_ARCHDEF is needed to get in the correct -DAMD64 or whatever >>> setting (which are otherwise hardcoded in the various platform_XXX.in >>> files in non-zero builds -- you/we might want to re-think this). >>> >>> Those changes also require some changes in the hotspot tree. See webrevs >>> below. >>> >>> Re: Mike's suggestion: I set the variables in spec.gmk conditionally >>> now. However, the resulting spec.gmk does have the conditions and >>> var-setting code still in it, i.e. the zero-related code does not >>> disappear. >>> >>>> Where is INCLUDE_SA supposed to be set? I know it was handled in >>>> Defs-[os].gmk files in the old build, but in the new I would assume >>>> configure should be setting it. >>> >>> it is set in jdk/common/Defs-$PLATFORM.gmk. As per David's suggestion, I >>> will not touch this for now. It is only required for images-builds... so >>> not super-critical - for the time being. >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~rkennke/zero-build-infra/webrev.03/ >>> http://cr.openjdk.java.net/~rkennke/zero_build_infra_hotspot/webrev.01/ >>> >>> How's this now? >>> >> That looks much cleaner, thank you. If the hotspot team is ok with >> renaming the variables in the hotspot makefiles, I'm fine with that too, >> but it's not my decision. If they aren't, you can still set the hotspot >> specific variables based on the ones from configure in >> hotspot-spec.gmk.in. From the build group this is ok. You will still >> need an official jdk8 reviewer to look at it, and the hotspot changes >> need someone from hotspot. >> >> /Erik >> > From krystal.mo at oracle.com Fri Feb 22 01:27:43 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Fri, 22 Feb 2013 01:27:43 -0800 Subject: RFR(M): 7165259 Remove BugSpot In-Reply-To: <9496CFBE-4F80-490A-9A07-C2B58447F532@oracle.com> References: <9496CFBE-4F80-490A-9A07-C2B58447F532@oracle.com> Message-ID: <51273A0F.5080204@oracle.com> Hi Staffan, Looks good to me (not a Reviewer). I had a slight hope in that someday we'll be able to morph Serviceability Agent into what it was meant to be -- a full-fledged mixed-mode debugger for HotSpot. But with the current resources available, I guess we'll just have to accept that it's not going to happen... So I'm alright with this change. Thanks, Kris On 2013/2/21 7:38, Staffan Larsen wrote: > Please review the following change to remove the BugSpot UI for the Serviceability Agent. My understanding is that BugSpot was intended as a more general native debugger not only focused on the JVM, but that it was never fully implemented. I don't think there is a need for a general-purpose debugger in SA and would like to clean up the code. One effect of this change is that PStack and PMap will no longer be able to operate on executables other than the JVM. > > This change was first proposed last year in this thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2012-April/005811.html > > This change also removes some old JVMDI code in SA (JVMDI is no longer supported in HotSpot). > > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7165259 > > webrev: http://cr.openjdk.java.net/~sla/7165259/webrev.00/ > > > Thanks, > /Staffan From staffan.larsen at oracle.com Fri Feb 22 01:41:31 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 22 Feb 2013 10:41:31 +0100 Subject: RFR(M): 7165259 Remove BugSpot In-Reply-To: <51273A0F.5080204@oracle.com> References: <9496CFBE-4F80-490A-9A07-C2B58447F532@oracle.com> <51273A0F.5080204@oracle.com> Message-ID: <12027490-7DF5-4CA1-913C-50A4AD418486@oracle.com> Thanks Kris! Yeah, it would be a nice project to build a full-fledged debugger, but very hard to justify the resources spent :-) I think instead we should view SA as a great tool to dig out JVM-specific data from a process/core - the things a normal debugger knows nothing about. /Staffan On 22 feb 2013, at 10:27, Krystal Mo wrote: > Hi Staffan, > > Looks good to me (not a Reviewer). > > I had a slight hope in that someday we'll be able to morph Serviceability Agent into what it was meant to be -- a full-fledged mixed-mode debugger for HotSpot. > But with the current resources available, I guess we'll just have to accept that it's not going to happen... So I'm alright with this change. > > Thanks, > Kris > > On 2013/2/21 7:38, Staffan Larsen wrote: >> Please review the following change to remove the BugSpot UI for the Serviceability Agent. My understanding is that BugSpot was intended as a more general native debugger not only focused on the JVM, but that it was never fully implemented. I don't think there is a need for a general-purpose debugger in SA and would like to clean up the code. One effect of this change is that PStack and PMap will no longer be able to operate on executables other than the JVM. >> >> This change was first proposed last year in this thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2012-April/005811.html >> >> This change also removes some old JVMDI code in SA (JVMDI is no longer supported in HotSpot). >> >> >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7165259 >> >> webrev: http://cr.openjdk.java.net/~sla/7165259/webrev.00/ >> >> >> Thanks, >> /Staffan > From coleen.phillimore at oracle.com Fri Feb 22 05:49:44 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 22 Feb 2013 08:49:44 -0500 Subject: RFR(M): 7165259 Remove BugSpot In-Reply-To: <12027490-7DF5-4CA1-913C-50A4AD418486@oracle.com> References: <9496CFBE-4F80-490A-9A07-C2B58447F532@oracle.com> <51273A0F.5080204@oracle.com> <12027490-7DF5-4CA1-913C-50A4AD418486@oracle.com> Message-ID: <51277778.50904@oracle.com> On 2/22/2013 4:41 AM, Staffan Larsen wrote: > Thanks Kris! > > Yeah, it would be a nice project to build a full-fledged debugger, but very hard to justify the resources spent :-) I think instead we should view SA as a great tool to dig out JVM-specific data from a process/core - the things a normal debugger knows nothing about. I agree with Staffan. We have full-fledged debuggers on our platforms, but having the SA help find vm-specific bugs is a great benefit. Without belaboring the point, it would be great if the SA didn't duplicate all the code in the VM to do so. Thanks, Coleen > > /Staffan > > > > On 22 feb 2013, at 10:27, Krystal Mo wrote: > >> Hi Staffan, >> >> Looks good to me (not a Reviewer). >> >> I had a slight hope in that someday we'll be able to morph Serviceability Agent into what it was meant to be -- a full-fledged mixed-mode debugger for HotSpot. >> But with the current resources available, I guess we'll just have to accept that it's not going to happen... So I'm alright with this change. >> >> Thanks, >> Kris >> >> On 2013/2/21 7:38, Staffan Larsen wrote: >>> Please review the following change to remove the BugSpot UI for the Serviceability Agent. My understanding is that BugSpot was intended as a more general native debugger not only focused on the JVM, but that it was never fully implemented. I don't think there is a need for a general-purpose debugger in SA and would like to clean up the code. One effect of this change is that PStack and PMap will no longer be able to operate on executables other than the JVM. >>> >>> This change was first proposed last year in this thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2012-April/005811.html >>> >>> This change also removes some old JVMDI code in SA (JVMDI is no longer supported in HotSpot). >>> >>> >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7165259 >>> >>> webrev: http://cr.openjdk.java.net/~sla/7165259/webrev.00/ >>> >>> >>> Thanks, >>> /Staffan From joseph.provino at oracle.com Fri Feb 22 06:35:23 2013 From: joseph.provino at oracle.com (Joseph Provino) Date: Fri, 22 Feb 2013 09:35:23 -0500 Subject: Please review: 8006498 and 8008474 In-Reply-To: <5126E261.6080601@oracle.com> References: <5125448B.8090107@oracle.com> <5125685F.5070907@oracle.com> <51261EDD.2020309@oracle.com> <512633D5.6040202@oracle.com> <5126DF09.2040207@oracle.com> <5126E261.6080601@oracle.com> Message-ID: <5127822B.9090208@oracle.com> On 02/21/2013 10:13 PM, David Holmes wrote: > On 22/02/2013 12:59 PM, David Holmes wrote: >> On 22/02/2013 12:48 AM, JOSEPH PROVINO wrote: >>> Actually, from looking at this again, I thought David was suggesting >>> that -Wundef >>> should be added to ACCEPTABLE_WARNINGS for linux and bsd. >> >> I was being ambivalent - I just wanted to see consistency. We should see >> where Mikael is adding -Wunused > > Ha! Now this really muddies the waters (this is linux only): > > ! ADDITIONAL_WARNINGS = -Wunused-function > ! > ! CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(ACCEPTABLE_WARNINGS) > $(ADDITIONAL_WARNINGS) That's the problem -- it's already inconsistent. joe > > > David > >> >> David >> >>> joe >>> >>> On 2/21/2013 8:19 AM, Zhengyu Gu wrote: >>>> Agree with David, -Wundef should go to CFLAGS_WARN/DEFAULT on Solaris >>>> if there is not particular reason not to. >>>> >>>> Other than that, look good to me. >>>> >>>> -Zhengyu >>>> >>>> On 2/20/2013 7:20 PM, David Holmes wrote: >>>>> On 21/02/2013 7:47 AM, JOSEPH PROVINO wrote: >>>>>> 8006498: ASSERT and other symbols used incorrectly with #if are >>>>>> supposed to be defined or not >>>>>> >>>>>> 8008474: -Wundef should be added to the build to catch #if >>>>>> references >>>>>> to undefined macros. >>>>>> >>>>>> >>>>>> Webrev is here: >>>>>> http://cr.openjdk.java.net/~jprovino/8006498/webrev.00/ >>>>> >>>>> On bsd and linux you simply added -Wundef directly to the CFLAGS: >>>>> >>>>> +CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(ACCEPTABLE_WARNINGS) >>>>> -Wundef >>>>> >>>>> but on Solaris you added it to ADDITIONAL_WARNINGS: >>>>> >>>>> +ADDITIONAL_WARNINGS = -Wpointer-arith -Wconversion -Wsign-compare >>>>> -Wundef >>>>> >>>>> I guess it is a little confusing as to whether ACCEPTABLE_WARNINGS >>>>> and ADDITIONAL_WARNINGS are meant to be the same thing. >>>>> >>>>> Otherwise all the #if -> #ifdef etc seem okay. >>>>> >>>>> David >>>>> >>>>>> Thanks. >>>>>> >>>>>> joe >>>> >>> From kevin.walls at oracle.com Fri Feb 22 06:44:51 2013 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 22 Feb 2013 14:44:51 +0000 Subject: RFR(M): 7165259 Remove BugSpot In-Reply-To: <9496CFBE-4F80-490A-9A07-C2B58447F532@oracle.com> References: <9496CFBE-4F80-490A-9A07-C2B58447F532@oracle.com> Message-ID: <51278463.7020000@oracle.com> Hi Staffan - This looks good, and I don't believe it breaks anything I use, or hear of being used (anecdotally: sightings of BugSpot in use to my knowledge are very very limited, and not recent!) Thanks Kevin On 21/02/13 15:38, Staffan Larsen wrote: > Please review the following change to remove the BugSpot UI for the Serviceability Agent. My understanding is that BugSpot was intended as a more general native debugger not only focused on the JVM, but that it was never fully implemented. I don't think there is a need for a general-purpose debugger in SA and would like to clean up the code. One effect of this change is that PStack and PMap will no longer be able to operate on executables other than the JVM. > > This change was first proposed last year in this thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2012-April/005811.html > > This change also removes some old JVMDI code in SA (JVMDI is no longer supported in HotSpot). > > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7165259 > > webrev: http://cr.openjdk.java.net/~sla/7165259/webrev.00/ > > > Thanks, > /Staffan From christian.thalinger at oracle.com Fri Feb 22 08:47:54 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 22 Feb 2013 08:47:54 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <5126EFAF.5000101@oracle.com> References: <5126EFAF.5000101@oracle.com> Message-ID: On Feb 21, 2013, at 8:10 PM, David Holmes wrote: > Hi Christian, > > cc'ing build-dev > > On 22/02/2013 12:40 PM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/8006965 >> >> 8006965: test_gamma should run with import JDK >> Reviewed-by: >> >> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >> JDK n is the version we are actually compiling for). This setup is >> unsupported and thus should not be done during HotSpot builds. >> >> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >> running test_gamma. > > First, the simplest change seems to me to just to do: > > ! MAKE_ARGS += JAVA_HOME=$(JDK_IMPORT_PATH) > > and not need to change anything in buildtree.make. Maybe. But the conditional setting of JAVA_HOME in env.sh is a problem. > > But this forces everyone outside of Oracle (and some inside) to have to set ALT_JDK_IMPORT_PATH explicitly otherwise they get: > > JDK_IMPORT_PATH=$(SLASH_JAVA)/re/j2se/$(JDK_VERSION)/promoted/latest/binaries/$(PLATFORM) That should be set by the OpenJDK build. And people who are only building hotspot are probably setting this anyway (and are special). > > And the boot JDK is only JDK n-1 for our official builds - people can use whatever boot JDK works for them including latest JDK. Right. They can use whatever boot JDK they want but not import. > > I see the problem you want to fix, and I know why you've hit it, but this doesn't seem like a general solution. I don't know what to suggest. > >> make/bsd/makefiles/buildtree.make >> make/defs.make > > Why did you add: > > MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) > > ? Because JAVA_HOME was overwritten by ABS_BOOTDIR which looks completely wrong to me (and caused a problem with a version of the patch that still had the conditional setting of JAVA_HOME). -- Chris > > David > ----- > >> make/linux/makefiles/buildtree.make >> make/solaris/makefiles/buildtree.make >> From christian.thalinger at oracle.com Fri Feb 22 08:48:59 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 22 Feb 2013 08:48:59 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> Message-ID: <4F056DFB-A8E8-4298-A3A2-8220A8462ED1@oracle.com> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: > I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. That file is in the JDK I suppose? -- Chris > > Thanks, > /Staffan > > On 22 feb 2013, at 03:40, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/8006965 >> >> 8006965: test_gamma should run with import JDK >> Reviewed-by: >> >> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >> JDK n is the version we are actually compiling for). This setup is >> unsupported and thus should not be done during HotSpot builds. >> >> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >> running test_gamma. >> >> make/bsd/makefiles/buildtree.make >> make/defs.make >> make/linux/makefiles/buildtree.make >> make/solaris/makefiles/buildtree.make > From mikael.vidstedt at oracle.com Fri Feb 22 09:29:53 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 22 Feb 2013 09:29:53 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <4F056DFB-A8E8-4298-A3A2-8220A8462ED1@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <4F056DFB-A8E8-4298-A3A2-8220A8462ED1@oracle.com> Message-ID: <5127AB11.1060702@oracle.com> On 2013-02-22 08:48, Christian Thalinger wrote: > On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: > >> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. > That file is in the JDK I suppose? -- Chris The jdkpath.sh file is generated as part of building hotspot, see buildtree.make in the various OS specific make directories. Cheers, Mikael > >> Thanks, >> /Staffan >> >> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/8006965 >>> >>> 8006965: test_gamma should run with import JDK >>> Reviewed-by: >>> >>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>> JDK n is the version we are actually compiling for). This setup is >>> unsupported and thus should not be done during HotSpot builds. >>> >>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>> running test_gamma. >>> >>> make/bsd/makefiles/buildtree.make >>> make/defs.make >>> make/linux/makefiles/buildtree.make >>> make/solaris/makefiles/buildtree.make From christian.thalinger at oracle.com Fri Feb 22 11:04:31 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 22 Feb 2013 11:04:31 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <5127AB11.1060702@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <4F056DFB-A8E8-4298-A3A2-8220A8462ED1@oracle.com> <5127AB11.1060702@oracle.com> Message-ID: <59FF5558-5BD4-4427-AABC-3EFDFF8FA4BA@oracle.com> On Feb 22, 2013, at 9:29 AM, Mikael Vidstedt wrote: > On 2013-02-22 08:48, Christian Thalinger wrote: >> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >> >>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >> That file is in the JDK I suppose? -- Chris > > The jdkpath.sh file is generated as part of building hotspot, see buildtree.make in the various OS specific make directories. Oh. The other script. What is actually env.csh used for? Or .dbxrc? Anyone using these files? -- Chris > > Cheers, > Mikael > >> >>> Thanks, >>> /Staffan >>> >>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>> >>>> http://cr.openjdk.java.net/~twisti/8006965 >>>> >>>> 8006965: test_gamma should run with import JDK >>>> Reviewed-by: >>>> >>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>> JDK n is the version we are actually compiling for). This setup is >>>> unsupported and thus should not be done during HotSpot builds. >>>> >>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>> running test_gamma. >>>> >>>> make/bsd/makefiles/buildtree.make >>>> make/defs.make >>>> make/linux/makefiles/buildtree.make >>>> make/solaris/makefiles/buildtree.make > From john.coomes at oracle.com Fri Feb 22 11:32:51 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 22 Feb 2013 19:32:51 +0000 Subject: hg: hsx/hotspot-main: 15 new changesets Message-ID: <20130222193251.E6AA147CCF@hg.openjdk.java.net> Changeset: 8dd61906da5f Author: chegar Date: 2013-02-06 11:36 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/8dd61906da5f 8007625: race with nested repos in /common/bin/hgforest.sh Reviewed-by: dholmes, ohair, ohrstrom ! common/bin/hgforest.sh ! get_source.sh Changeset: 168dd033604a Author: mduigou Date: 2013-02-06 11:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/168dd033604a 8004726: Link bug ids to jbs rather than monaco. Reviewed-by: ohair, chegar, katleman ! make/scripts/webrev.ksh Changeset: 7817368287cd Author: mduigou Date: 2013-02-06 11:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/7817368287cd 8006595: Use jdk/test/Makefile targets in preference to local definitions Reviewed-by: alanb ! common/makefiles/Main.gmk ! test/Makefile Changeset: fdb1e09519ed Author: sherman Date: 2013-02-12 09:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/fdb1e09519ed 8007392: JSR 310: DateTime API Updates Summary: Integration of JSR310 Date/Time API for M7 Reviewed-by: darcy, alanb, naoto Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, masayoshi.okutsu at oracle.com, patrick.zhang at oracle.com ! common/makefiles/javadoc/CORE_PKGS.gmk Changeset: 76808fb4194a Author: lana Date: 2013-02-13 11:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/76808fb4194a Merge ! common/makefiles/Main.gmk Changeset: bbb7548d45c7 Author: lana Date: 2013-02-14 22:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/bbb7548d45c7 Merge Changeset: ffb4d2e95140 Author: erikj Date: 2013-02-15 10:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ffb4d2e95140 8005879: Add -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 to builds on Mac Reviewed-by: ohair ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: b0642df54d63 Author: erikj Date: 2013-02-18 10:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/b0642df54d63 Merge Changeset: b80abec66e70 Author: bpatel Date: 2013-01-21 00:29 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/b80abec66e70 8006124: javadoc/doclet should be updated to support profiles Reviewed-by: jjg, dholmes ! common/makefiles/javadoc/Javadoc.gmk Changeset: 7ed0c9db6943 Author: dholmes Date: 2013-01-21 01:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/7ed0c9db6943 8004265: Add build support for Compact Profiles Reviewed-by: erikj, ohair ! NewMakefile.gmk ! common/autoconf/generated-configure.sh ! common/makefiles/Main.gmk Changeset: 2f8fd30f02e6 Author: dholmes Date: 2013-01-22 19:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/2f8fd30f02e6 Merge ! common/autoconf/generated-configure.sh Changeset: bebeaa04ab8e Author: dholmes Date: 2013-02-04 18:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/bebeaa04ab8e Merge ! common/autoconf/generated-configure.sh ! common/makefiles/javadoc/Javadoc.gmk Changeset: 28071e4ca1de Author: dholmes Date: 2013-02-17 16:44 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/28071e4ca1de Merge ! common/autoconf/generated-configure.sh ! common/makefiles/Main.gmk Changeset: fd1a5574cf68 Author: dholmes Date: 2013-02-18 15:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/fd1a5574cf68 Merge ! common/autoconf/generated-configure.sh Changeset: 91d35211e744 Author: katleman Date: 2013-02-21 11:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/91d35211e744 Added tag jdk8-b78 for changeset fd1a5574cf68 ! .hgtags From john.coomes at oracle.com Fri Feb 22 11:32:59 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 22 Feb 2013 19:32:59 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b78 for changeset 27d6368ae8ba Message-ID: <20130222193302.013F547CD0@hg.openjdk.java.net> Changeset: e41fb1aa0329 Author: katleman Date: 2013-02-21 11:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/e41fb1aa0329 Added tag jdk8-b78 for changeset 27d6368ae8ba ! .hgtags From john.coomes at oracle.com Fri Feb 22 11:33:08 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 22 Feb 2013 19:33:08 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b78 for changeset 00958c5a7070 Message-ID: <20130222193317.ED1EC47CD1@hg.openjdk.java.net> Changeset: 58fa065dd5d6 Author: katleman Date: 2013-02-21 11:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/58fa065dd5d6 Added tag jdk8-b78 for changeset 00958c5a7070 ! .hgtags From john.coomes at oracle.com Fri Feb 22 11:33:25 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 22 Feb 2013 19:33:25 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b78 for changeset 391de4c992d1 Message-ID: <20130222193330.C477047CD2@hg.openjdk.java.net> Changeset: 70d8658d2a30 Author: katleman Date: 2013-02-21 11:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/70d8658d2a30 Added tag jdk8-b78 for changeset 391de4c992d1 ! .hgtags From vladimir.kozlov at oracle.com Fri Feb 22 11:39:57 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Feb 2013 11:39:57 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <59FF5558-5BD4-4427-AABC-3EFDFF8FA4BA@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <4F056DFB-A8E8-4298-A3A2-8220A8462ED1@oracle.com> <5127AB11.1060702@oracle.com> <59FF5558-5BD4-4427-AABC-3EFDFF8FA4BA@oracle.com> Message-ID: <5127C98D.3040808@oracle.com> On 2/22/13 11:04 AM, Christian Thalinger wrote: > > On Feb 22, 2013, at 9:29 AM, Mikael Vidstedt wrote: > >> On 2013-02-22 08:48, Christian Thalinger wrote: >>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>> >>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>> That file is in the JDK I suppose? -- Chris >> >> The jdkpath.sh file is generated as part of building hotspot, see buildtree.make in the various OS specific make directories. > > Oh. The other script. What is actually env.csh used for? Or .dbxrc? Anyone using these files? They are used for incremental build and debugging using gamma: "cd solaris_amd64_compiler2/jvmg; gnumake; dbx gamma" I work this way. Vladimir > > -- Chris > >> >> Cheers, >> Mikael >> >>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>> >>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>> >>>>> 8006965: test_gamma should run with import JDK >>>>> Reviewed-by: >>>>> >>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>> JDK n is the version we are actually compiling for). This setup is >>>>> unsupported and thus should not be done during HotSpot builds. >>>>> >>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>> running test_gamma. >>>>> >>>>> make/bsd/makefiles/buildtree.make >>>>> make/defs.make >>>>> make/linux/makefiles/buildtree.make >>>>> make/solaris/makefiles/buildtree.make >> > From john.coomes at oracle.com Fri Feb 22 11:35:59 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 22 Feb 2013 19:35:59 +0000 Subject: hg: hsx/hotspot-main/jdk: 70 new changesets Message-ID: <20130222195002.EA97847CD3@hg.openjdk.java.net> Changeset: 37719b174e87 Author: jgodinez Date: 2013-02-06 14:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/37719b174e87 8005194: [parfait] #353 sun/awt/image/jpeg/imageioJPEG.c Memory leak of pointer 'scale' allocated with calloc() Reviewed-by: prr, vadim Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c Changeset: ad49012d10a1 Author: jgodinez Date: 2013-02-08 11:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ad49012d10a1 8005129: [parfait] #1122 - #1130 native/sun/awt/medialib/mlib_Image*.c Memory leak of pointer 'k' allocated with mlib_malloc Reviewed-by: prr, vadim Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/awt/medialib/mlib_ImageConv.h ! src/share/native/sun/awt/medialib/mlib_ImageConvMxN_ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_16ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_16nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_32nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_8ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_8nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_u16ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_u16nw.c ! src/share/native/sun/awt/medialib/mlib_ImageCreate.c ! src/share/native/sun/awt/medialib/mlib_c_ImageConv.h Changeset: 1ea9feb6d8c5 Author: jgodinez Date: 2013-02-08 11:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1ea9feb6d8c5 8005261: [parfait] #415 sun/java2d/opengl/GLXSurfaceData.c Memory leak of pointer 'glxsdo' allocated with malloc Reviewed-by: prr, vadim Contributed-by: jia-hong.chen at oracle.com ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c Changeset: 5f0217537435 Author: prr Date: 2013-02-12 09:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5f0217537435 8007748: MacOSX build error : cast of type 'SEL' to 'uintptr_t' (aka 'unsigned long') is deprecated; use sel_getName instead Reviewed-by: anthony ! src/macosx/native/jobjc/src/core/native/SEL.m Changeset: 1b47e2dfa89a Author: lana Date: 2013-02-13 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1b47e2dfa89a Merge - 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 Changeset: 6df3acd02449 Author: prr Date: 2013-02-13 15:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6df3acd02449 8008017: The fix for 8005129 does not build on Windows Reviewed-by: prr, jgodinez Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/awt/medialib/mlib_ImageConv_16ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_16nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_8ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_8nw.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_u16ext.c ! src/share/native/sun/awt/medialib/mlib_ImageConv_u16nw.c Changeset: ac89a5d71466 Author: alexsch Date: 2013-02-06 18:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ac89a5d71466 8000326: Focus unable to traverse in the menubar Reviewed-by: alexsch, malenkov ! src/share/classes/javax/swing/JMenuBar.java Changeset: 6e17465f4a1a Author: mcherkas Date: 2013-02-08 22:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6e17465f4a1a 8005932: Java 7 on mac os x only provides text clipboard formats Reviewed-by: alexp, denis ! src/macosx/lib/flavormap.properties + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/AbsoluteComponentCenterCalculator.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/DataFlavorSearcher.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/InterprocessMessages.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MyTransferable.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/NextFramePositionCalculator.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/SourcePanel.java + test/java/awt/DataFlavor/MissedHtmlAndRtfBug/TargetPanel.java Changeset: 5406c4e381e2 Author: kshefov Date: 2013-02-13 18:01 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5406c4e381e2 7161759: TEST_BUG: java/awt/Frame/WindowDragTest/WindowDragTest.java fails to compile, should be modified Summary: Added @build Util jtreg tag Reviewed-by: serb, alexsch Contributed-by: Vera Akulova ! test/java/awt/Frame/WindowDragTest/WindowDragTest.java Changeset: dd6cf41a6953 Author: kshefov Date: 2013-02-13 19:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dd6cf41a6953 7132383: [macosx] bug6596966.java should be adapted for Mac Reviewed-by: serb, alexsch Contributed-by: Vera Akulova ! test/javax/swing/JLabel/6596966/bug6596966.java ! test/javax/swing/regtesthelpers/Util.java Changeset: caec64340f42 Author: vkarnauk Date: 2013-02-13 19:23 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/caec64340f42 4199622: RFE: JComboBox shouldn't sending ActionEvents for keyboard navigation Reviewed-by: alexp, alexsch ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java + test/javax/swing/JComboBox/4199622/bug4199622.java Changeset: 4d9691e95e05 Author: pchelko Date: 2013-02-13 15:27 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4d9691e95e05 7079260: InputContext leaks memory Summary: Replaced strong refs with weak refs Reviewed-by: art, serb ! src/share/classes/sun/awt/im/CompositionAreaHandler.java ! src/solaris/classes/sun/awt/X11InputMethod.java + test/java/awt/im/memoryleak/InputContextMemoryLeakTest.java ! test/java/awt/regtesthelpers/Util.java Changeset: c552cde0e3f9 Author: pchelko Date: 2013-02-13 15:32 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c552cde0e3f9 8005629: javac warnings compiling java.awt.EventDispatchThread and sun.awt.X11.XIconWindow Summary: Removed macosx specific workaround from shared code and made macosx use public API Reviewed-by: art, serb ! src/macosx/classes/sun/lwawt/macosx/CPrinterJob.java - src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java ! src/macosx/native/sun/awt/CPrinterJob.m ! src/share/classes/java/awt/EventDispatchThread.java ! src/solaris/classes/sun/awt/X11/XIconWindow.java Changeset: c95dc15ac183 Author: lana Date: 2013-02-13 12:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c95dc15ac183 Merge - 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 Changeset: c9efb349b391 Author: lana Date: 2013-02-13 17:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c9efb349b391 Merge - src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java Changeset: 0e7d5dd84fdf Author: dsamersoff Date: 2013-02-06 16:53 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0e7d5dd84fdf 8007277: JDK-8002048 testcase fails to compile Summary: sun.* classes is not included to ct.sym file and symbol file have to be ignored Reviewed-by: alanb ! test/sun/management/jdp/JdpTest.sh Changeset: 1574fa3df1c0 Author: lancea Date: 2013-02-06 14:15 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1574fa3df1c0 8006505: additional changes for JSR 310 support Reviewed-by: naoto, ulfzibis ! src/share/classes/java/sql/JDBCType.java ! src/share/classes/java/sql/SQLInput.java ! src/share/classes/java/sql/SQLOutput.java ! src/share/classes/java/sql/Types.java Changeset: 2f1505c49e79 Author: martin Date: 2013-02-06 17:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2f1505c49e79 8006995: java launcher fails to open executable JAR > 2GB Summary: Use O_LARGEFILE consistently when opening jar files Reviewed-by: alanb, sherman ! src/share/bin/parse_manifest.c Changeset: 2de8c6c2d652 Author: ykantser Date: 2013-02-07 11:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2de8c6c2d652 8007142: Add utility classes for writing better multiprocess tests in jtreg Reviewed-by: alanb, rbackman + test/lib/testlibrary/OutputAnalyzerTest.java + test/lib/testlibrary/jdk/testlibrary/JcmdBase.java + test/lib/testlibrary/jdk/testlibrary/JdkFinder.java + test/lib/testlibrary/jdk/testlibrary/OutputAnalyzer.java + test/lib/testlibrary/jdk/testlibrary/OutputBuffer.java + test/lib/testlibrary/jdk/testlibrary/ProcessTools.java + test/lib/testlibrary/jdk/testlibrary/StreamPumper.java Changeset: 79d7595abe95 Author: naoto Date: 2013-02-08 09:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/79d7595abe95 8007038: ArrayIndexOutOfBoundsException on calling localizedDateTime().print() with JapaneseChrono Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java + test/java/util/Calendar/Bug8007038.java Changeset: 522fb3867a3a Author: darcy Date: 2013-02-08 16:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/522fb3867a3a 8005623: Retrofit FunctionalInterface annotations to core platform interfaces Reviewed-by: mduigou, chegar, alanb ! src/share/classes/java/io/Closeable.java ! src/share/classes/java/io/FileFilter.java ! src/share/classes/java/io/FilenameFilter.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 ! src/share/classes/java/lang/Runnable.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/nio/file/DirectoryStream.java ! src/share/classes/java/nio/file/PathMatcher.java ! src/share/classes/java/util/Comparator.java ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/Block.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java ! src/share/classes/java/util/function/DoubleBlock.java ! src/share/classes/java/util/function/DoubleFunction.java ! src/share/classes/java/util/function/DoubleSupplier.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBinaryOperator.java ! src/share/classes/java/util/function/IntBlock.java ! src/share/classes/java/util/function/IntFunction.java ! src/share/classes/java/util/function/IntSupplier.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java ! src/share/classes/java/util/function/LongBlock.java ! src/share/classes/java/util/function/LongFunction.java ! src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/LongUnaryOperator.java ! src/share/classes/java/util/function/Predicate.java ! src/share/classes/java/util/function/Supplier.java ! src/share/classes/java/util/function/UnaryOperator.java ! src/share/classes/java/util/logging/Filter.java ! src/share/classes/java/util/prefs/PreferenceChangeListener.java Changeset: 36d25dc2b8f0 Author: dl Date: 2013-02-09 08:35 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/36d25dc2b8f0 8005697: Add StampedLock Reviewed-by: chegar, alanb, dice, martin ! make/java/java/FILES_java.gmk ! src/share/classes/java/util/concurrent/locks/LockSupport.java + src/share/classes/java/util/concurrent/locks/StampedLock.java + test/java/util/concurrent/locks/StampedLock/Basic.java Changeset: d14cd2272b2d Author: weijun Date: 2013-02-09 16:43 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d14cd2272b2d 8001104: Unbound SASL service: the GSSAPI/krb5 mech Reviewed-by: valeriep ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/javax/security/auth/kerberos/JavaxSecurityAuthKerberosAccessImpl.java ! src/share/classes/javax/security/auth/kerberos/KeyTab.java ! src/share/classes/sun/security/jgss/LoginConfigImpl.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/share/classes/sun/security/jgss/krb5/ServiceCreds.java ! src/share/classes/sun/security/jgss/krb5/SubjectComber.java ! src/share/classes/sun/security/krb5/JavaxSecurityAuthKerberosAccess.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/provider/ConfigSpiFile.java ! test/sun/security/krb5/ServiceCredsCombination.java ! test/sun/security/krb5/auto/AcceptPermissions.java + test/sun/security/krb5/auto/GSSUnbound.java ! test/sun/security/krb5/auto/OneKDC.java + test/sun/security/krb5/auto/SaslUnbound.java + test/sun/security/krb5/auto/UnboundService.java Changeset: 57cb988c811e Author: weijun Date: 2013-02-09 16:43 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/57cb988c811e 8007761: NTLM coding errors Reviewed-by: chegar ! src/share/classes/com/sun/security/ntlm/Client.java ! src/share/classes/com/sun/security/ntlm/NTLM.java Changeset: 58c95d0b6b1a Author: ksrini Date: 2013-02-10 08:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/58c95d0b6b1a 8007519: [unpack200] produces bad class files when producing BootstrapMethods attribute Reviewed-by: alanb ! test/ProblemList.txt Changeset: 520a3433883d Author: ksrini Date: 2013-02-10 08:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/520a3433883d 8007902: [unpack200] incorrect BootstrapMethods attribute Reviewed-by: jjh ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! test/tools/pack200/Pack200Test.java ! test/tools/pack200/pack200-verifier/data/golden.jar Changeset: 1df991184045 Author: dsamersoff Date: 2013-02-11 18:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1df991184045 8007536: Incorrect copyright header in JDP files Summary: Copyright header in JDP files missed the "classpath exception" rule. Reviewed-by: mikael ! src/share/classes/sun/management/jdp/JdpBroadcaster.java ! src/share/classes/sun/management/jdp/JdpController.java ! src/share/classes/sun/management/jdp/JdpException.java ! src/share/classes/sun/management/jdp/JdpGenericPacket.java ! src/share/classes/sun/management/jdp/JdpJmxPacket.java ! src/share/classes/sun/management/jdp/JdpPacket.java ! src/share/classes/sun/management/jdp/JdpPacketReader.java ! src/share/classes/sun/management/jdp/JdpPacketWriter.java ! src/share/classes/sun/management/jdp/package-info.java Changeset: abd530253f01 Author: dcubed Date: 2013-02-11 10:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/abd530253f01 8007420: add test for 6805864 to com/sun/jdi, add test for 7182152 to java/lang/instrument Reviewed-by: coleenp, sspitsyn + test/com/sun/jdi/RedefineAbstractClass.sh + test/java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesAgent.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesApp.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesImpl.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesImpl_1.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesIntf1.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesIntf2.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesRemote.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesTarget.java + test/java/lang/instrument/RedefineSubclassWithTwoInterfacesTarget_1.java Changeset: f21a4b761424 Author: alanb Date: 2013-02-11 20:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f21a4b761424 8007405: Update java.lang.reflect API to replace SYNTHESIZED with MANDATED Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Modifier.java ! src/share/classes/java/lang/reflect/Parameter.java Changeset: 465cce29a9ed Author: mduigou Date: 2013-02-06 11:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/465cce29a9ed 8006594: Add jdk_core target to jdk/test/Makefile Reviewed-by: alanb ! make/jprt.properties ! test/Makefile ! test/ProblemList.txt Changeset: f7fb173ac833 Author: dsamersoff Date: 2013-02-12 16:02 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f7fb173ac833 8007786: JDK-8002048 testcase doesn't work on Solaris Summary: test built in into Solaris shell doesn't have -e operator Reviewed-by: sla, sspitsyn ! test/sun/management/jdp/JdpTest.sh Changeset: 7dcb74c3ffba Author: sherman Date: 2013-02-12 09:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7dcb74c3ffba 8007392: JSR 310: DateTime API Updates 8007520: Update date/time classes in j.util and j.sql packages 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb Summary: Integration of JSR310 Date/Time API for M7 Reviewed-by: darcy, alanb, naoto Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, masayoshi.okutsu at oracle.com, patrick.zhang at oracle.com ! make/docs/CORE_PKGS.gmk ! make/java/java/FILES_java.gmk ! make/sun/Makefile ! make/sun/javazic/Makefile + make/sun/javazic/tzdata/gmt + make/sun/javazic/tzdata/jdk11_backward ! make/sun/tzdb/Makefile ! make/tools/Makefile ! make/tools/src/build/tools/javazic/Zoneinfo.java ! make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java ! makefiles/GendataTZDB.gmk ! makefiles/GendataTimeZone.gmk ! makefiles/GenerateData.gmk ! makefiles/Tools.gmk ! src/share/classes/java/sql/Date.java ! src/share/classes/java/sql/Time.java ! src/share/classes/java/sql/Timestamp.java ! src/share/classes/java/time/Clock.java ! src/share/classes/java/time/DayOfWeek.java ! 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/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/PeriodParser.java ! src/share/classes/java/time/Ser.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/ZoneRegion.java ! src/share/classes/java/time/ZonedDateTime.java - src/share/classes/java/time/calendar/ChronoDateImpl.java - src/share/classes/java/time/calendar/HijrahChrono.java - src/share/classes/java/time/calendar/HijrahDate.java - src/share/classes/java/time/calendar/HijrahDeviationReader.java - src/share/classes/java/time/calendar/HijrahEra.java - src/share/classes/java/time/calendar/JapaneseChrono.java - src/share/classes/java/time/calendar/JapaneseDate.java - src/share/classes/java/time/calendar/JapaneseEra.java - src/share/classes/java/time/calendar/MinguoChrono.java - src/share/classes/java/time/calendar/MinguoDate.java - src/share/classes/java/time/calendar/MinguoEra.java - src/share/classes/java/time/calendar/Ser.java - src/share/classes/java/time/calendar/ThaiBuddhistChrono.java - src/share/classes/java/time/calendar/ThaiBuddhistDate.java - src/share/classes/java/time/calendar/ThaiBuddhistEra.java - src/share/classes/java/time/calendar/package-info.java + src/share/classes/java/time/chrono/ChronoDateImpl.java + src/share/classes/java/time/chrono/ChronoLocalDate.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/chrono/Chronology.java + src/share/classes/java/time/chrono/Era.java + src/share/classes/java/time/chrono/HijrahChronology.java + src/share/classes/java/time/chrono/HijrahDate.java + src/share/classes/java/time/chrono/HijrahDeviationReader.java + src/share/classes/java/time/chrono/HijrahEra.java + src/share/classes/java/time/chrono/IsoChronology.java + src/share/classes/java/time/chrono/IsoEra.java + src/share/classes/java/time/chrono/JapaneseChronology.java + src/share/classes/java/time/chrono/JapaneseDate.java + src/share/classes/java/time/chrono/JapaneseEra.java + src/share/classes/java/time/chrono/MinguoChronology.java + src/share/classes/java/time/chrono/MinguoDate.java + src/share/classes/java/time/chrono/MinguoEra.java + src/share/classes/java/time/chrono/Ser.java + src/share/classes/java/time/chrono/ThaiBuddhistChronology.java + src/share/classes/java/time/chrono/ThaiBuddhistDate.java + src/share/classes/java/time/chrono/ThaiBuddhistEra.java + src/share/classes/java/time/chrono/package-info.java ! src/share/classes/java/time/format/DateTimeBuilder.java ! src/share/classes/java/time/format/DateTimeFormatStyleProvider.java ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java - src/share/classes/java/time/format/DateTimeFormatters.java ! src/share/classes/java/time/format/DateTimeParseContext.java ! src/share/classes/java/time/format/DateTimePrintContext.java - src/share/classes/java/time/format/DateTimePrintException.java ! src/share/classes/java/time/format/DateTimeTextProvider.java ! src/share/classes/java/time/format/FormatStyle.java + src/share/classes/java/time/format/ZoneName.java ! src/share/classes/java/time/format/package-info.java ! src/share/classes/java/time/overview.html ! src/share/classes/java/time/package-info.java - src/share/classes/java/time/temporal/Chrono.java ! src/share/classes/java/time/temporal/ChronoField.java - src/share/classes/java/time/temporal/ChronoLocalDate.java - src/share/classes/java/time/temporal/ChronoLocalDateTime.java - src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/temporal/ChronoUnit.java - src/share/classes/java/time/temporal/ChronoZonedDateTime.java - src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java - src/share/classes/java/time/temporal/Era.java - src/share/classes/java/time/temporal/ISOChrono.java - src/share/classes/java/time/temporal/ISOEra.java - src/share/classes/java/time/temporal/ISOFields.java + src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/JulianFields.java - src/share/classes/java/time/temporal/MonthDay.java - src/share/classes/java/time/temporal/OffsetDate.java - src/share/classes/java/time/temporal/OffsetDateTime.java - src/share/classes/java/time/temporal/OffsetTime.java ! src/share/classes/java/time/temporal/Queries.java - src/share/classes/java/time/temporal/Ser.java - src/share/classes/java/time/temporal/SimplePeriod.java ! src/share/classes/java/time/temporal/Temporal.java ! src/share/classes/java/time/temporal/TemporalAccessor.java - src/share/classes/java/time/temporal/TemporalAdder.java ! src/share/classes/java/time/temporal/TemporalAdjuster.java + src/share/classes/java/time/temporal/TemporalAmount.java ! src/share/classes/java/time/temporal/TemporalField.java ! src/share/classes/java/time/temporal/TemporalQuery.java - src/share/classes/java/time/temporal/TemporalSubtractor.java ! src/share/classes/java/time/temporal/TemporalUnit.java ! src/share/classes/java/time/temporal/WeekFields.java - src/share/classes/java/time/temporal/Year.java - src/share/classes/java/time/temporal/YearMonth.java ! src/share/classes/java/time/temporal/package-info.java ! src/share/classes/java/time/zone/TzdbZoneRulesProvider.java ! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java ! src/share/classes/java/time/zone/ZoneRules.java ! src/share/classes/java/time/zone/ZoneRulesProvider.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Date.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/sun/text/resources/FormatData.java ! src/share/classes/sun/text/resources/ar/FormatData_ar.java ! src/share/classes/sun/text/resources/el/FormatData_el.java ! src/share/classes/sun/text/resources/hr/FormatData_hr.java ! src/share/classes/sun/text/resources/ja/FormatData_ja.java ! src/share/classes/sun/text/resources/ko/FormatData_ko.java ! src/share/classes/sun/text/resources/sr/FormatData_sr.java ! src/share/classes/sun/text/resources/sv/FormatData_sv.java ! src/share/classes/sun/text/resources/zh/FormatData_zh.java ! src/share/classes/sun/text/resources/zh/FormatData_zh_TW.java ! src/share/classes/sun/util/calendar/CalendarSystem.java ! src/share/classes/sun/util/calendar/LocalGregorianCalendar.java - src/share/classes/sun/util/calendar/TzIDOldMapping.java ! src/share/classes/sun/util/calendar/ZoneInfo.java ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleResources.java + test/java/sql/JavatimeTest.java + test/java/time/META-INF/services/java.time.chrono.Chronology - test/java/time/META-INF/services/java.time.temporal.Chrono ! test/java/time/tck/java/time/AbstractTCKTest.java + test/java/time/tck/java/time/MockSimplePeriod.java ! test/java/time/tck/java/time/TCKClock.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/TCKDayOfWeek.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/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/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/TestChronology.java + test/java/time/tck/java/time/TestIsoChronology.java - test/java/time/tck/java/time/calendar/CopticChrono.java - test/java/time/tck/java/time/calendar/CopticDate.java - test/java/time/tck/java/time/calendar/CopticEra.java - test/java/time/tck/java/time/calendar/TestChronoLocalDate.java - test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java - test/java/time/tck/java/time/calendar/TestHijrahChrono.java - test/java/time/tck/java/time/calendar/TestJapaneseChrono.java - test/java/time/tck/java/time/calendar/TestMinguoChrono.java - test/java/time/tck/java/time/calendar/TestServiceLoader.java - test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java + test/java/time/tck/java/time/chrono/CopticChronology.java + test/java/time/tck/java/time/chrono/CopticDate.java + test/java/time/tck/java/time/chrono/CopticEra.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/TestChronoLocalDate.java + test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java + test/java/time/tck/java/time/chrono/TestHijrahChronology.java + test/java/time/tck/java/time/chrono/TestJapaneseChronology.java + test/java/time/tck/java/time/chrono/TestMinguoChronology.java + test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java + test/java/time/tck/java/time/format/TCKChronoPrinterParser.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatter.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java - test/java/time/tck/java/time/format/TCKDateTimePrintException.java ! test/java/time/tck/java/time/format/TCKDateTimeTextPrinting.java ! test/java/time/tck/java/time/format/TCKLocalizedFieldParser.java ! test/java/time/tck/java/time/format/TCKLocalizedFieldPrinter.java + test/java/time/tck/java/time/format/TCKLocalizedPrinterParser.java + test/java/time/tck/java/time/format/TCKOffsetPrinterParser.java + test/java/time/tck/java/time/format/TCKPadPrinterParser.java + test/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java - test/java/time/tck/java/time/temporal/TCKISOFields.java + test/java/time/tck/java/time/temporal/TCKIsoFields.java ! test/java/time/tck/java/time/temporal/TCKJulianFields.java - test/java/time/tck/java/time/temporal/TCKMonthDay.java - test/java/time/tck/java/time/temporal/TCKOffsetDate.java - test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java - test/java/time/tck/java/time/temporal/TCKOffsetTime.java - test/java/time/tck/java/time/temporal/TCKSimplePeriod.java ! test/java/time/tck/java/time/temporal/TCKWeekFields.java - test/java/time/tck/java/time/temporal/TCKYear.java - test/java/time/tck/java/time/temporal/TCKYearMonth.java - test/java/time/tck/java/time/temporal/TestChrono.java ! test/java/time/tck/java/time/temporal/TestChronoLocalDate.java ! test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java ! test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java - test/java/time/tck/java/time/temporal/TestISOChrono.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/TCKZoneRulesProvider.java ! test/java/time/test/java/time/MockSimplePeriod.java ! test/java/time/test/java/time/TestDuration.java ! test/java/time/test/java/time/TestLocalDateTime.java ! test/java/time/test/java/time/TestLocalTime.java + test/java/time/test/java/time/TestMonthDay.java + test/java/time/test/java/time/TestOffsetDateTime.java + test/java/time/test/java/time/TestOffsetDateTime_instants.java + test/java/time/test/java/time/TestOffsetTime.java ! test/java/time/test/java/time/TestPeriod.java - test/java/time/test/java/time/TestPeriodParser.java + test/java/time/test/java/time/TestYear.java + test/java/time/test/java/time/TestYearMonth.java ! test/java/time/test/java/time/TestZoneId.java + test/java/time/test/java/time/chrono/TestExampleCode.java + test/java/time/test/java/time/chrono/TestIsoChronoImpl.java + test/java/time/test/java/time/chrono/TestServiceLoader.java ! test/java/time/test/java/time/format/TestCharLiteralParser.java ! test/java/time/test/java/time/format/TestCharLiteralPrinter.java + test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java - test/java/time/test/java/time/format/TestDateTimeFormatters.java - test/java/time/test/java/time/format/TestDateTimePrintException.java ! test/java/time/test/java/time/format/TestDateTimeTextProvider.java ! test/java/time/test/java/time/format/TestFractionPrinterParser.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/TestNumberPrinter.java - test/java/time/test/java/time/format/TestPadParserDecorator.java ! test/java/time/test/java/time/format/TestPadPrinterDecorator.java ! test/java/time/test/java/time/format/TestReducedParser.java ! test/java/time/test/java/time/format/TestReducedPrinter.java ! test/java/time/test/java/time/format/TestSettingsParser.java ! test/java/time/test/java/time/format/TestStringLiteralParser.java ! test/java/time/test/java/time/format/TestStringLiteralPrinter.java ! test/java/time/test/java/time/format/TestTextParser.java ! test/java/time/test/java/time/format/TestTextPrinter.java - test/java/time/test/java/time/format/TestZoneIdParser.java ! test/java/time/test/java/time/format/TestZoneOffsetParser.java ! test/java/time/test/java/time/format/TestZoneOffsetPrinter.java ! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java + test/java/time/test/java/time/format/ZoneName.java ! test/java/time/test/java/time/temporal/MockFieldNoValue.java ! test/java/time/test/java/time/temporal/MockFieldValue.java ! test/java/time/test/java/time/temporal/TestChronoUnit.java ! test/java/time/test/java/time/temporal/TestDateTimeBuilderCombinations.java - test/java/time/test/java/time/temporal/TestISOChronoImpl.java ! test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java + test/java/time/test/java/time/temporal/TestJulianFields.java - test/java/time/test/java/time/temporal/TestMonthDay.java - test/java/time/test/java/time/temporal/TestOffsetDate.java - test/java/time/test/java/time/temporal/TestOffsetDateTime.java - test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java - test/java/time/test/java/time/temporal/TestOffsetTime.java ! test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java - test/java/time/test/java/time/temporal/TestYear.java - test/java/time/test/java/time/temporal/TestYearMonth.java ! test/java/time/test/java/time/zone/TestFixedZoneRules.java ! test/java/time/test/java/util/TestFormatter.java + test/java/util/Calendar/JavatimeTest.java ! test/java/util/TimeZone/OldIDMappingTest.java + test/java/util/TimeZone/TzIDOldMapping.java + test/sun/util/calendar/zi/BackEnd.java + test/sun/util/calendar/zi/Checksum.java + test/sun/util/calendar/zi/DayOfWeek.java + test/sun/util/calendar/zi/Gen.java + test/sun/util/calendar/zi/GenDoc.java + test/sun/util/calendar/zi/Main.java + test/sun/util/calendar/zi/Mappings.java + test/sun/util/calendar/zi/Month.java + test/sun/util/calendar/zi/Rule.java + test/sun/util/calendar/zi/RuleDay.java + test/sun/util/calendar/zi/RuleRec.java + test/sun/util/calendar/zi/Simple.java + test/sun/util/calendar/zi/TestZoneInfo310.java + test/sun/util/calendar/zi/Time.java + test/sun/util/calendar/zi/Timezone.java + test/sun/util/calendar/zi/TzIDOldMapping.java + test/sun/util/calendar/zi/Zone.java + test/sun/util/calendar/zi/ZoneInfoFile.java + test/sun/util/calendar/zi/ZoneInfoOld.java + test/sun/util/calendar/zi/ZoneRec.java + test/sun/util/calendar/zi/Zoneinfo.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/factory + test/sun/util/calendar/zi/tzdata/gmt + test/sun/util/calendar/zi/tzdata/iso3166.tab + test/sun/util/calendar/zi/tzdata/jdk11_backward + test/sun/util/calendar/zi/tzdata/leapseconds + test/sun/util/calendar/zi/tzdata/northamerica + test/sun/util/calendar/zi/tzdata/pacificnew + test/sun/util/calendar/zi/tzdata/solar87 + test/sun/util/calendar/zi/tzdata/solar88 + test/sun/util/calendar/zi/tzdata/solar89 + test/sun/util/calendar/zi/tzdata/southamerica + test/sun/util/calendar/zi/tzdata/systemv + test/sun/util/calendar/zi/tzdata/zone.tab + test/sun/util/calendar/zi/tzdata_jdk/gmt + test/sun/util/calendar/zi/tzdata_jdk/jdk11_backward + test/sun/util/calendar/zi/tzdata_jdk/jdk11_full_backward Changeset: 2cd67a8c7abc Author: jfranck Date: 2013-02-13 10:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2cd67a8c7abc 8007278: Rename j.l.r.AnnotatedElement.getAnnotations(Class) to getAnnotationsByType(Class) Reviewed-by: darcy, abuckley ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/AnnotatedElement.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/generics/reflectiveObjects/TypeVariableImpl.java ! test/java/lang/annotation/TypeParamAnnotation.java ! test/java/lang/annotation/repeatingAnnotations/RepeatedUnitTest.java Changeset: cd111064d4e9 Author: zgu Date: 2013-02-12 14:47 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cd111064d4e9 8006691: Remove jvm_version_info->is_kernel_jvm field Summary: Remove is_kernel_jvm field in jvm_version_info structure, as kernel VM has been deprecated Reviewed-by: mchung ! src/share/javavm/export/jvm.h Changeset: bf64f83aa0cd Author: vinnie Date: 2013-02-13 16:01 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bf64f83aa0cd 8007934: algorithm parameters for PBE Scheme 2 not decoded correctly in PKCS12 keystore Reviewed-by: mullan ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! test/java/security/KeyStore/PBETest.java Changeset: ceb7c712c693 Author: vinnie Date: 2013-02-13 16:03 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ceb7c712c693 Merge Changeset: 8181be9a3538 Author: dsamersoff Date: 2013-02-13 21:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8181be9a3538 8008095: TEST_BUG: JDK-8002048 one more testcase failure on Solaris Summary: fixed couple of more Solaris shell incompatibilities Reviewed-by: chegar ! test/sun/management/jdp/JdpTest.sh Changeset: 11438befdd4c Author: vinnie Date: 2013-02-13 19:40 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/11438befdd4c 8007755: Support the logical grouping of keystores Reviewed-by: mullan ! src/share/classes/java/security/KeyStore.java + src/share/classes/sun/security/provider/DomainKeyStore.java ! src/share/classes/sun/security/provider/PolicyParser.java ! src/share/classes/sun/security/provider/Sun.java ! src/share/classes/sun/security/provider/SunEntries.java ! src/share/classes/sun/security/util/Resources.java + test/sun/security/provider/KeyStore/DKSTest.java + test/sun/security/provider/KeyStore/DKSTest.sh + test/sun/security/provider/KeyStore/domains.cfg ! test/sun/security/tools/keytool/AltProviderPath.sh ! test/sun/security/tools/keytool/DummyProvider.java Changeset: efc66fe16f91 Author: sherman Date: 2013-02-13 11:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/efc66fe16f91 8008161: Regression: j.u.TimeZone.getAvailableIDs(rawOffset) returns non-sorted list Summary: to return a sorted list Reviewed-by: lancea, naoto ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! test/sun/util/calendar/zi/TestZoneInfo310.java Changeset: ff80a6b2ae9b Author: lana Date: 2013-02-13 11:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ff80a6b2ae9b Merge Changeset: a5aad284904e Author: lana Date: 2013-02-13 11:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a5aad284904e Merge Changeset: 83c09292f5ad Author: ksrini Date: 2013-02-13 12:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/83c09292f5ad 8005750: [parfait] Memory leak at jdk/src/share/bin/parse_manifest.c Reviewed-by: jjh ! src/share/bin/parse_manifest.c Changeset: b13247d5408d Author: dcubed Date: 2013-02-13 13:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b13247d5408d 8007935: java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh should use $COMPILEJAVA for javac Reviewed-by: sspitsyn, alanb ! test/java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh Changeset: 4f520ce7ba3f Author: acorn Date: 2013-02-13 16:09 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4f520ce7ba3f 8007888: jdk fix default method: VerifyError: Illegal use of nonvirtual Summary: Recognize VM generated method in old verifier. With 8004967 Reviewed-by: coleenp, acorn Contributed-by: bharadwaj.yadavalli at oracle.com ! src/share/javavm/export/jvm.h ! src/share/native/common/check_code.c Changeset: e6f34051c60c Author: acorn Date: 2013-02-13 16:15 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e6f34051c60c Merge Changeset: dc3019a336c0 Author: lana Date: 2013-02-13 17:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dc3019a336c0 Merge - src/share/classes/java/time/PeriodParser.java - src/share/classes/java/time/calendar/ChronoDateImpl.java - src/share/classes/java/time/calendar/HijrahChrono.java - src/share/classes/java/time/calendar/HijrahDate.java - src/share/classes/java/time/calendar/HijrahDeviationReader.java - src/share/classes/java/time/calendar/HijrahEra.java - src/share/classes/java/time/calendar/JapaneseChrono.java - src/share/classes/java/time/calendar/JapaneseDate.java - src/share/classes/java/time/calendar/JapaneseEra.java - src/share/classes/java/time/calendar/MinguoChrono.java - src/share/classes/java/time/calendar/MinguoDate.java - src/share/classes/java/time/calendar/MinguoEra.java - src/share/classes/java/time/calendar/Ser.java - src/share/classes/java/time/calendar/ThaiBuddhistChrono.java - src/share/classes/java/time/calendar/ThaiBuddhistDate.java - src/share/classes/java/time/calendar/ThaiBuddhistEra.java - src/share/classes/java/time/calendar/package-info.java - src/share/classes/java/time/format/DateTimeFormatters.java - src/share/classes/java/time/format/DateTimePrintException.java - src/share/classes/java/time/temporal/Chrono.java - src/share/classes/java/time/temporal/ChronoLocalDate.java - src/share/classes/java/time/temporal/ChronoLocalDateTime.java - src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java - src/share/classes/java/time/temporal/ChronoZonedDateTime.java - src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java - src/share/classes/java/time/temporal/Era.java - src/share/classes/java/time/temporal/ISOChrono.java - src/share/classes/java/time/temporal/ISOEra.java - src/share/classes/java/time/temporal/ISOFields.java - src/share/classes/java/time/temporal/MonthDay.java - src/share/classes/java/time/temporal/OffsetDate.java - src/share/classes/java/time/temporal/OffsetDateTime.java - src/share/classes/java/time/temporal/OffsetTime.java - src/share/classes/java/time/temporal/Ser.java - src/share/classes/java/time/temporal/SimplePeriod.java - src/share/classes/java/time/temporal/TemporalAdder.java - src/share/classes/java/time/temporal/TemporalSubtractor.java - src/share/classes/java/time/temporal/Year.java - src/share/classes/java/time/temporal/YearMonth.java - src/share/classes/sun/util/calendar/TzIDOldMapping.java - test/java/time/META-INF/services/java.time.temporal.Chrono - test/java/time/tck/java/time/calendar/CopticChrono.java - test/java/time/tck/java/time/calendar/CopticDate.java - test/java/time/tck/java/time/calendar/CopticEra.java - test/java/time/tck/java/time/calendar/TestChronoLocalDate.java - test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java - test/java/time/tck/java/time/calendar/TestHijrahChrono.java - test/java/time/tck/java/time/calendar/TestJapaneseChrono.java - test/java/time/tck/java/time/calendar/TestMinguoChrono.java - test/java/time/tck/java/time/calendar/TestServiceLoader.java - test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java - test/java/time/tck/java/time/format/TCKDateTimePrintException.java - test/java/time/tck/java/time/temporal/TCKISOFields.java - test/java/time/tck/java/time/temporal/TCKMonthDay.java - test/java/time/tck/java/time/temporal/TCKOffsetDate.java - test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java - test/java/time/tck/java/time/temporal/TCKOffsetTime.java - test/java/time/tck/java/time/temporal/TCKSimplePeriod.java - test/java/time/tck/java/time/temporal/TCKYear.java - test/java/time/tck/java/time/temporal/TCKYearMonth.java - test/java/time/tck/java/time/temporal/TestChrono.java - test/java/time/tck/java/time/temporal/TestISOChrono.java - test/java/time/test/java/time/TestPeriodParser.java - test/java/time/test/java/time/format/TestDateTimeFormatters.java - test/java/time/test/java/time/format/TestDateTimePrintException.java - test/java/time/test/java/time/format/TestPadParserDecorator.java - test/java/time/test/java/time/format/TestZoneIdParser.java - test/java/time/test/java/time/temporal/TestISOChronoImpl.java - test/java/time/test/java/time/temporal/TestMonthDay.java - test/java/time/test/java/time/temporal/TestOffsetDate.java - test/java/time/test/java/time/temporal/TestOffsetDateTime.java - test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java - test/java/time/test/java/time/temporal/TestOffsetTime.java - test/java/time/test/java/time/temporal/TestYear.java - test/java/time/test/java/time/temporal/TestYearMonth.java Changeset: 5ea0024ba765 Author: lana Date: 2013-02-14 22:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5ea0024ba765 Merge Changeset: 90707943f83c Author: erikj Date: 2013-02-15 10:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/90707943f83c 8005879: Add -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 to builds on Mac Reviewed-by: ohair ! make/common/Defs-macosx.gmk Changeset: 9a693ebd5595 Author: erikj Date: 2013-02-18 10:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9a693ebd5595 Merge - src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java - src/share/classes/java/time/PeriodParser.java - src/share/classes/java/time/calendar/ChronoDateImpl.java - src/share/classes/java/time/calendar/HijrahChrono.java - src/share/classes/java/time/calendar/HijrahDate.java - src/share/classes/java/time/calendar/HijrahDeviationReader.java - src/share/classes/java/time/calendar/HijrahEra.java - src/share/classes/java/time/calendar/JapaneseChrono.java - src/share/classes/java/time/calendar/JapaneseDate.java - src/share/classes/java/time/calendar/JapaneseEra.java - src/share/classes/java/time/calendar/MinguoChrono.java - src/share/classes/java/time/calendar/MinguoDate.java - src/share/classes/java/time/calendar/MinguoEra.java - src/share/classes/java/time/calendar/Ser.java - src/share/classes/java/time/calendar/ThaiBuddhistChrono.java - src/share/classes/java/time/calendar/ThaiBuddhistDate.java - src/share/classes/java/time/calendar/ThaiBuddhistEra.java - src/share/classes/java/time/calendar/package-info.java - src/share/classes/java/time/format/DateTimeFormatters.java - src/share/classes/java/time/format/DateTimePrintException.java - src/share/classes/java/time/temporal/Chrono.java - src/share/classes/java/time/temporal/ChronoLocalDate.java - src/share/classes/java/time/temporal/ChronoLocalDateTime.java - src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java - src/share/classes/java/time/temporal/ChronoZonedDateTime.java - src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java - src/share/classes/java/time/temporal/Era.java - src/share/classes/java/time/temporal/ISOChrono.java - src/share/classes/java/time/temporal/ISOEra.java - src/share/classes/java/time/temporal/ISOFields.java - src/share/classes/java/time/temporal/MonthDay.java - src/share/classes/java/time/temporal/OffsetDate.java - src/share/classes/java/time/temporal/OffsetDateTime.java - src/share/classes/java/time/temporal/OffsetTime.java - src/share/classes/java/time/temporal/Ser.java - src/share/classes/java/time/temporal/SimplePeriod.java - src/share/classes/java/time/temporal/TemporalAdder.java - src/share/classes/java/time/temporal/TemporalSubtractor.java - src/share/classes/java/time/temporal/Year.java - src/share/classes/java/time/temporal/YearMonth.java - src/share/classes/sun/util/calendar/TzIDOldMapping.java - test/java/time/META-INF/services/java.time.temporal.Chrono - test/java/time/tck/java/time/calendar/CopticChrono.java - test/java/time/tck/java/time/calendar/CopticDate.java - test/java/time/tck/java/time/calendar/CopticEra.java - test/java/time/tck/java/time/calendar/TestChronoLocalDate.java - test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java - test/java/time/tck/java/time/calendar/TestHijrahChrono.java - test/java/time/tck/java/time/calendar/TestJapaneseChrono.java - test/java/time/tck/java/time/calendar/TestMinguoChrono.java - test/java/time/tck/java/time/calendar/TestServiceLoader.java - test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java - test/java/time/tck/java/time/format/TCKDateTimePrintException.java - test/java/time/tck/java/time/temporal/TCKISOFields.java - test/java/time/tck/java/time/temporal/TCKMonthDay.java - test/java/time/tck/java/time/temporal/TCKOffsetDate.java - test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java - test/java/time/tck/java/time/temporal/TCKOffsetTime.java - test/java/time/tck/java/time/temporal/TCKSimplePeriod.java - test/java/time/tck/java/time/temporal/TCKYear.java - test/java/time/tck/java/time/temporal/TCKYearMonth.java - test/java/time/tck/java/time/temporal/TestChrono.java - test/java/time/tck/java/time/temporal/TestISOChrono.java - test/java/time/test/java/time/TestPeriodParser.java - test/java/time/test/java/time/format/TestDateTimeFormatters.java - test/java/time/test/java/time/format/TestDateTimePrintException.java - test/java/time/test/java/time/format/TestPadParserDecorator.java - test/java/time/test/java/time/format/TestZoneIdParser.java - test/java/time/test/java/time/temporal/TestISOChronoImpl.java - test/java/time/test/java/time/temporal/TestMonthDay.java - test/java/time/test/java/time/temporal/TestOffsetDate.java - test/java/time/test/java/time/temporal/TestOffsetDateTime.java - test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java - test/java/time/test/java/time/temporal/TestOffsetTime.java - test/java/time/test/java/time/temporal/TestYear.java - test/java/time/test/java/time/temporal/TestYearMonth.java Changeset: fb7e3edf22b2 Author: erikj Date: 2013-02-18 11:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fb7e3edf22b2 8008294: build-infra: Build-infra closed fails on solaris 11.1 Reviewed-by: ohrstrom, dholmes, tbell ! makefiles/CompileDemos.gmk ! makefiles/CompileNativeLibraries.gmk Changeset: a23b0df73324 Author: erikj Date: 2013-02-18 11:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a23b0df73324 8008295: build-infra: Cleanup in Import.gmk Reviewed-by: ohrstrom, tbell ! makefiles/Import.gmk Changeset: 32549d339437 Author: bpatel Date: 2013-01-21 00:31 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/32549d339437 8006124: javadoc/doclet should be updated to support profiles Reviewed-by: jjg, dholmes ! make/docs/Makefile Changeset: 80afadbf967d Author: alanb Date: 2013-01-21 01:46 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/80afadbf967d 8004182: Add support for profiles in javac Reviewed-by: dholmes ! make/common/Release.gmk Changeset: 353b88963430 Author: dholmes Date: 2013-01-21 21:54 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/353b88963430 8006651: build-infra: Import.gmk needs to add support for the minimal VM Reviewed-by: erikj, ohair ! makefiles/Import.gmk Changeset: 7096f51288ab Author: dholmes Date: 2013-01-21 23:17 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7096f51288ab 8004265: Add build support for Compact Profiles Reviewed-by: erikj, ohair ! make/tools/src/build/tools/jarreorder/JarReorder.java ! makefiles/BuildJdk.gmk ! makefiles/CreateJars.gmk ! makefiles/Images.gmk + makefiles/ProfileNames.gmk + makefiles/Profiles.gmk Changeset: ccd0aceb1190 Author: alanb Date: 2013-01-21 23:20 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ccd0aceb1190 8003255: (profiles) Update JAR file specification to support profiles Reviewed-by: dholmes, mchung, ksrini ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/java/util/jar/Attributes.java + src/share/classes/java/util/jar/UnsupportedProfileException.java ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! src/share/classes/sun/misc/URLClassPath.java ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/jar/resources/jar.properties + 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 Changeset: c024147205f6 Author: alanb Date: 2013-01-21 23:21 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c024147205f6 8003256: (profiles) Add support for profile identification Reviewed-by: dholmes, mchung, ksrini ! make/java/version/Makefile ! makefiles/GensrcMisc.gmk ! src/share/classes/sun/misc/Version.java.template + test/tools/launcher/profiles/VersionCheck.java Changeset: 4b3434f5f509 Author: alanb Date: 2013-01-21 23:23 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4b3434f5f509 8004931: add/removePropertyChangeListener should not exist in subset Profiles of Java SE Reviewed-by: dholmes, mchung, ksrini + make/tools/src/build/tools/RemoveMethods.java ! makefiles/Tools.gmk ! src/share/classes/java/util/jar/Pack200.java ! src/share/classes/java/util/logging/LogManager.java + test/java/util/logging/Reflect.java + test/tools/pack200/NoBeans.java + test/tools/pack200/Reflect.java Changeset: d9cfe581c8fe Author: alanb Date: 2013-01-21 23:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d9cfe581c8fe 8004502: Compact Profiles contents Reviewed-by: dholmes, mchung + makefiles/profile-includes.txt + makefiles/profile-rtjar-includes.txt + test/java/lang/SecurityManager/NoAWT.java + test/java/security/cert/CertStore/NoLDAP.java + test/javax/management/remote/mandatory/connection/NoIIOP.java + test/javax/naming/InitialContext/NoApplet.java + test/sun/net/www/protocol/http/NoNTLM.java + test/sun/security/ssl/sanity/ciphersuites/NoKerberos.java Changeset: d1b29d290ebd Author: dholmes Date: 2013-01-22 19:31 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d1b29d290ebd Merge Changeset: 0918d6d9c18b Author: dholmes Date: 2013-01-22 20:04 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0918d6d9c18b 8006667: Merge issue: Profile attribute need to be examined before custom attributes Summary: swap profile checking and FXHelper checking Reviewed-by: alanb ! src/share/classes/sun/launcher/LauncherHelper.java Changeset: 77668918a388 Author: dholmes Date: 2013-02-04 18:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/77668918a388 Merge ! make/docs/Makefile ! makefiles/CreateJars.gmk ! makefiles/GensrcMisc.gmk ! makefiles/Tools.gmk ! src/share/classes/sun/misc/URLClassPath.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/CallbackInterface.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/Callback_Stub.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup_Stub.java Changeset: f308a689c049 Author: dholmes Date: 2013-02-17 16:44 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f308a689c049 Merge ! makefiles/Tools.gmk - src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java - src/share/classes/java/time/PeriodParser.java - src/share/classes/java/time/calendar/ChronoDateImpl.java - src/share/classes/java/time/calendar/HijrahChrono.java - src/share/classes/java/time/calendar/HijrahDate.java - src/share/classes/java/time/calendar/HijrahDeviationReader.java - src/share/classes/java/time/calendar/HijrahEra.java - src/share/classes/java/time/calendar/JapaneseChrono.java - src/share/classes/java/time/calendar/JapaneseDate.java - src/share/classes/java/time/calendar/JapaneseEra.java - src/share/classes/java/time/calendar/MinguoChrono.java - src/share/classes/java/time/calendar/MinguoDate.java - src/share/classes/java/time/calendar/MinguoEra.java - src/share/classes/java/time/calendar/Ser.java - src/share/classes/java/time/calendar/ThaiBuddhistChrono.java - src/share/classes/java/time/calendar/ThaiBuddhistDate.java - src/share/classes/java/time/calendar/ThaiBuddhistEra.java - src/share/classes/java/time/calendar/package-info.java - src/share/classes/java/time/format/DateTimeFormatters.java - src/share/classes/java/time/format/DateTimePrintException.java - src/share/classes/java/time/temporal/Chrono.java - src/share/classes/java/time/temporal/ChronoLocalDate.java - src/share/classes/java/time/temporal/ChronoLocalDateTime.java - src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java - src/share/classes/java/time/temporal/ChronoZonedDateTime.java - src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java - src/share/classes/java/time/temporal/Era.java - src/share/classes/java/time/temporal/ISOChrono.java - src/share/classes/java/time/temporal/ISOEra.java - src/share/classes/java/time/temporal/ISOFields.java - src/share/classes/java/time/temporal/MonthDay.java - src/share/classes/java/time/temporal/OffsetDate.java - src/share/classes/java/time/temporal/OffsetDateTime.java - src/share/classes/java/time/temporal/OffsetTime.java - src/share/classes/java/time/temporal/Ser.java - src/share/classes/java/time/temporal/SimplePeriod.java - src/share/classes/java/time/temporal/TemporalAdder.java - src/share/classes/java/time/temporal/TemporalSubtractor.java - src/share/classes/java/time/temporal/Year.java - src/share/classes/java/time/temporal/YearMonth.java - src/share/classes/sun/util/calendar/TzIDOldMapping.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/java/time/META-INF/services/java.time.temporal.Chrono - test/java/time/tck/java/time/calendar/CopticChrono.java - test/java/time/tck/java/time/calendar/CopticDate.java - test/java/time/tck/java/time/calendar/CopticEra.java - test/java/time/tck/java/time/calendar/TestChronoLocalDate.java - test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java - test/java/time/tck/java/time/calendar/TestHijrahChrono.java - test/java/time/tck/java/time/calendar/TestJapaneseChrono.java - test/java/time/tck/java/time/calendar/TestMinguoChrono.java - test/java/time/tck/java/time/calendar/TestServiceLoader.java - test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java - test/java/time/tck/java/time/format/TCKDateTimePrintException.java - test/java/time/tck/java/time/temporal/TCKISOFields.java - test/java/time/tck/java/time/temporal/TCKMonthDay.java - test/java/time/tck/java/time/temporal/TCKOffsetDate.java - test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java - test/java/time/tck/java/time/temporal/TCKOffsetTime.java - test/java/time/tck/java/time/temporal/TCKSimplePeriod.java - test/java/time/tck/java/time/temporal/TCKYear.java - test/java/time/tck/java/time/temporal/TCKYearMonth.java - test/java/time/tck/java/time/temporal/TestChrono.java - test/java/time/tck/java/time/temporal/TestISOChrono.java - test/java/time/test/java/time/TestPeriodParser.java - test/java/time/test/java/time/format/TestDateTimeFormatters.java - test/java/time/test/java/time/format/TestDateTimePrintException.java - test/java/time/test/java/time/format/TestPadParserDecorator.java - test/java/time/test/java/time/format/TestZoneIdParser.java - test/java/time/test/java/time/temporal/TestISOChronoImpl.java - test/java/time/test/java/time/temporal/TestMonthDay.java - test/java/time/test/java/time/temporal/TestOffsetDate.java - test/java/time/test/java/time/temporal/TestOffsetDateTime.java - test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java - test/java/time/test/java/time/temporal/TestOffsetTime.java - test/java/time/test/java/time/temporal/TestYear.java - test/java/time/test/java/time/temporal/TestYearMonth.java - 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 Changeset: 16c684b2ab82 Author: alanb Date: 2013-02-18 08:57 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/16c684b2ab82 8007436: (profiles) Add JSR-310 to Compact Profiles contents Reviewed-by: dholmes, erikj ! makefiles/profile-includes.txt ! makefiles/profile-rtjar-includes.txt Changeset: c24bc91caa67 Author: dholmes Date: 2013-02-18 15:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c24bc91caa67 Merge ! makefiles/Import.gmk Changeset: b46c75e221c7 Author: dholmes Date: 2013-02-19 06:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b46c75e221c7 8008424: Isolate PROFILE make variable from incidental setting in the environment Reviewed-by: erikj, alanb ! makefiles/BuildJdk.gmk Changeset: 6f4615fd32da Author: alanb Date: 2013-02-19 11:08 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6f4615fd32da 8007097: (profiles) Build needs test to ensure that profile definitions are updated Reviewed-by: dholmes, erikj - make/tools/src/build/tools/RemoveMethods.java + make/tools/src/build/tools/classfile/RemoveMethods.java + make/tools/src/build/tools/deps/CheckDeps.java + make/tools/src/build/tools/deps/refs.allowed ! makefiles/Images.gmk ! makefiles/Tools.gmk ! makefiles/profile-rtjar-includes.txt Changeset: 033f2707ef32 Author: alanb Date: 2013-02-19 11:32 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/033f2707ef32 Merge Changeset: 00b7535d743f Author: dholmes Date: 2013-02-19 17:32 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/00b7535d743f 8008481: Dependency analyzer needs exclusion for profile builds with JFR disabled Reviewed-by: alanb ! make/tools/src/build/tools/deps/refs.allowed Changeset: bb97c93e4fd7 Author: katleman Date: 2013-02-21 11:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bb97c93e4fd7 Added tag jdk8-b78 for changeset 00b7535d743f ! .hgtags From john.coomes at oracle.com Fri Feb 22 11:52:51 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 22 Feb 2013 19:52:51 +0000 Subject: hg: hsx/hotspot-main/langtools: 24 new changesets Message-ID: <20130222195359.593EE47CD4@hg.openjdk.java.net> Changeset: de932285124c Author: jjg Date: 2013-02-05 21:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/de932285124c 8007485: test creates .class files in the test/ directory Reviewed-by: mcimadamore ! test/tools/javac/api/8007344/Test.java Changeset: 1df20330f6bd Author: mcimadamore Date: 2013-02-06 14:03 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1df20330f6bd 8007463: Cleanup inference related classes Summary: Make Infer.InferenceContext an inner class; adjust bound replacement logic in Type.UndetVar 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/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/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/util/List.java ! test/tools/javac/generics/inference/7154127/T7154127.out ! test/tools/javac/lib/DPrinter.java Changeset: 8cdd96f2fdb9 Author: mcimadamore Date: 2013-02-06 14:04 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8cdd96f2fdb9 8007479: Refactor DeferredAttrContext so that it points to parent context Summary: Move DeferredAttrNode out of DeferredAttrContext; add support for nested deferred contexts Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java Changeset: 153d20d0cac5 Author: jjg Date: 2013-02-06 07:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/153d20d0cac5 8007566: DocLint too aggressive with not allowed here:

Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/doclint/Checker.java + test/tools/doclint/ParaTagTest.java Changeset: b386b8c45387 Author: jjh Date: 2013-02-06 23:10 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b386b8c45387 8007698: jtreg test T6306137.java won't compile with ASCII encoding Reviewed-by: ksrini ! test/tools/javac/api/T6306137.java Changeset: 5125b9854d07 Author: darcy Date: 2013-02-07 20:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/5125b9854d07 7195131: Update 2 compiler combo tests for repeating annotations to include package and default use cases Reviewed-by: darcy Contributed-by: sonali.goel at oracle.com ! test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java + test/tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java + test/tools/javac/annotations/repeatingAnnotations/combo/TestCaseGenerator.java Changeset: 762d0af062f5 Author: vromero Date: 2013-02-08 09:12 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/762d0af062f5 7166455: javac doesn't set ACC_STRICT bit on for strictfp class Reviewed-by: mcimadamore ! 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/jvm/Gen.java + test/tools/javac/7166455/CheckACC_STRICTFlagOnclinitTest.java Changeset: b1deb90d2e37 Author: vromero Date: 2013-02-08 09:15 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b1deb90d2e37 8005931: javac doesn't set ACC_STRICT for classes with package access Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/8005931/CheckACC_STRICTFlagOnPkgAccessClassTest.java Changeset: 017e8bdd440f Author: vromero Date: 2013-02-08 09:21 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/017e8bdd440f 7167125: Two variables after the same operation in a inner class return different results Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/7167125/DiffResultAfterSameOperationInnerClasses.java Changeset: 60caf53b98e2 Author: jjg Date: 2013-02-08 17:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/60caf53b98e2 8007610: javadoc doclint does not work with -private Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! test/com/sun/javadoc/T6735320/T6735320.java ! test/tools/javadoc/doclint/DocLintTest.java Changeset: 01af1b5c631d Author: darcy Date: 2013-02-11 13:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/01af1b5c631d 8007574: Provide isFunctionalInterface in javax.lang.model Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/javax/lang/model/element/TypeElement.java ! src/share/classes/javax/lang/model/util/Elements.java + test/tools/javac/processing/model/util/elements/TestIsFunctionalInterface.java Changeset: 973646bf043a Author: jfranck Date: 2013-02-12 11:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/973646bf043a 8004822: RFE to write language model API tests for repeating annotations based on the spec updates Reviewed-by: jjg, abuckley Contributed-by: Matherey Nunez + test/tools/javac/processing/model/element/repeatingAnnotations/ElementRepAnnoTester.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedA1Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedA2Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB1Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB2Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixSingularAndUnofficialContainerBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixSingularAndUnofficialContainerInheritedA1Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixSingularAndUnofficialContainerInheritedA2Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixSingularAndUnofficialContainerInheritedB1Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/MixSingularAndUnofficialContainerInheritedB2Test.java + test/tools/javac/processing/model/element/repeatingAnnotations/OfficialContainerBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/OfficialContainerInheritedTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableInheritedTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOfficialContainerBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOfficialContainerInheritedTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideATest.java + test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideBTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/SingularBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/SingularInheritedATest.java + test/tools/javac/processing/model/element/repeatingAnnotations/SingularInheritedBTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/UnofficialContainerBasicTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/UnofficialContainerInheritedTest.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/Bar.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/BarContainer.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/BarContainerContainer.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/BarInherited.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/BarInheritedContainer.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/BarInheritedContainerContainer.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/ExpectedBase.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/ExpectedContainer.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/Foo.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/FooInherited.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/UnofficialContainer.java + test/tools/javac/processing/model/element/repeatingAnnotations/supportingAnnotations/UnofficialInheritedContainer.java Changeset: 073696f59241 Author: vromero Date: 2013-02-12 13:36 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/073696f59241 8006334: javap, JavapTask constructor breaks with null pointer exception if parameter options is null Reviewed-by: jjg ! src/share/classes/com/sun/tools/javap/JavapTask.java + test/tools/javap/8006334/JavapTaskCtorFailWithNPE.java Changeset: 2154ed9ff6c8 Author: mcimadamore Date: 2013-02-12 19:25 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2154ed9ff6c8 8007464: Add graph inference support Summary: Add support for more aggressive type-inference scheme Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java + src/share/classes/com/sun/tools/javac/util/GraphUtils.java ! test/tools/javac/6758789/T6758789b.out ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/diags/examples/CantApplyDiamond1.java ! test/tools/javac/diags/examples/InferredDoNotConformToEq.java ! test/tools/javac/diags/examples/InferredDoNotConformToUpper.java ! test/tools/javac/diags/examples/WhereFreshTvar.java ! test/tools/javac/generics/7015430/T7015430.out ! test/tools/javac/generics/7151802/T7151802.out ! test/tools/javac/generics/diamond/neg/Neg06.out ! test/tools/javac/generics/inference/6278587/T6278587Neg.java ! test/tools/javac/generics/inference/6638712/T6638712d.out ! test/tools/javac/generics/inference/6638712/T6638712e.out ! test/tools/javac/generics/inference/7154127/T7154127.java ! test/tools/javac/generics/inference/7154127/T7154127.out ! test/tools/javac/generics/inference/7177306/T7177306a.out ! test/tools/javac/generics/inference/7177306/T7177306e.java ! test/tools/javac/generics/inference/7177306/T7177306e.out ! test/tools/javac/generics/odersky/BadTest4.java ! test/tools/javac/lambda/TargetType14.out ! test/tools/javac/lambda/TargetType20.java - test/tools/javac/lambda/TargetType20.out ! test/tools/javac/lambda/TargetType28.out ! test/tools/javac/lambda/TargetType50.java - test/tools/javac/lambda/TargetType50.out ! test/tools/javac/lambda/TargetType51.java ! test/tools/javac/lambda/TargetType52.java ! test/tools/javac/lambda/TargetType52.out + test/tools/javac/lambda/TargetType53.java + test/tools/javac/lambda/TargetType54.java + test/tools/javac/lambda/TargetType55.java + test/tools/javac/lambda/TargetType56.java + test/tools/javac/lambda/TargetType57.java + test/tools/javac/lambda/TargetType57.out + test/tools/javac/lambda/TargetType58.java + test/tools/javac/lambda/TargetType59.java + test/tools/javac/lambda/TargetType61.java + test/tools/javac/lambda/TargetType62.java Changeset: bc456436c613 Author: jjg Date: 2013-02-12 17:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/bc456436c613 8008077: update reference impl for type-annotations Reviewed-by: jjg Contributed-by: wmdietl at cs.washington.edu ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/TypeAnnotation.java ! src/share/classes/com/sun/tools/javac/code/TargetType.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/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javap/AnnotationWriter.java + test/tools/javac/annotations/typeAnnotations/failures/LazyConstantValue.java + test/tools/javac/annotations/typeAnnotations/failures/TypeVariable.java ! test/tools/javac/annotations/typeAnnotations/failures/VoidGenericMethod.java + test/tools/javac/annotations/typeAnnotations/newlocations/Lambda.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/Lambda.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodParameters.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeCasts.java Changeset: aeadaf905d78 Author: jfranck Date: 2013-02-13 10:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/aeadaf905d78 8007279: Rename javax.l.model.element.Element.getAnnotations(Class) to getAnnotationsByType(Class) Reviewed-by: darcy, abuckley ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/javax/lang/model/element/Element.java ! test/tools/javac/processing/model/element/repeatingAnnotations/ElementRepAnnoTester.java Changeset: d04960f05593 Author: mcimadamore Date: 2013-02-13 17:04 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d04960f05593 8006345: Report Synthesized Parameters in java.lang.reflect.Parameter API 8006896: ClassReader doesn't see MethodParameters attr for method of anon inner class 8007098: Output Synthesized Parameters to MethodParameters Attributes Summary: Correctly report synthesized and mandated parameters Reviewed-by: mcimadamore, jjg Contributed-by: eric.mccorkle at oracle.com ! src/share/classes/com/sun/tools/classfile/AccessFlags.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java Changeset: 3f9875aa5d67 Author: lana Date: 2013-02-13 11:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3f9875aa5d67 Merge Changeset: a3aa32fe4536 Author: lana Date: 2013-02-14 22:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a3aa32fe4536 Merge Changeset: 5f0731e4e5e6 Author: bpatel Date: 2013-01-21 00:45 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/5f0731e4e5e6 8006124: javadoc/doclet should be updated to support profiles Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/AbstractProfileIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.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/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/ProfilePackageSummaryWriter.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/ProfileSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfilePackageSummaryBuilder.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfileSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java + test/com/sun/javadoc/testProfiles/TestProfiles.java + test/com/sun/javadoc/testProfiles/pkg1/Class1Pkg1.java + test/com/sun/javadoc/testProfiles/pkg1/Class2Pkg1.java + test/com/sun/javadoc/testProfiles/pkg1/Class3Pkg1.java + test/com/sun/javadoc/testProfiles/pkg1/Interface1Pkg1.java + test/com/sun/javadoc/testProfiles/pkg2/Anno1Pkg2.java + test/com/sun/javadoc/testProfiles/pkg2/Anno2Pkg2.java + test/com/sun/javadoc/testProfiles/pkg2/Class1Pkg2.java + test/com/sun/javadoc/testProfiles/pkg3/Class1Pkg3.java + test/com/sun/javadoc/testProfiles/pkg3/Class2Pkg3.java + test/com/sun/javadoc/testProfiles/pkg3/Interface1Pkg3.java + test/com/sun/javadoc/testProfiles/pkg4/Anno1Pkg4.java + test/com/sun/javadoc/testProfiles/pkg4/Class1Pkg4.java + test/com/sun/javadoc/testProfiles/pkg5/Class1Pkg5.java + test/com/sun/javadoc/testProfiles/pkg5/Interface1Pkg5.java + test/com/sun/javadoc/testProfiles/profile-rtjar-includes.txt Changeset: 475eb15dfdad Author: jjg Date: 2013-01-21 01:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/475eb15dfdad 8004182: Add support for profiles in javac Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Symtab.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/jvm/ClassReader.java + src/share/classes/com/sun/tools/javac/jvm/Profile.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/resources/javac.properties ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java + src/share/classes/com/sun/tools/javac/sym/Profiles.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java + test/tools/javac/diags/examples/NotInProfile.java + test/tools/javac/profiles/ProfileOptionTest.java Changeset: f91144b7da75 Author: dholmes Date: 2013-02-04 18:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f91144b7da75 Merge ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Symtab.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/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java - test/tools/javac/annotations/repeatingAnnotations/MissingContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/MissingContainerFor.java - test/tools/javac/annotations/repeatingAnnotations/UseWrongContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/UseWrongContainerFor.java - test/tools/javac/annotations/repeatingAnnotations/WrongContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/WrongContainerFor.java - test/tools/javac/diags/examples/ContainedByDocumentedMismatch.java - test/tools/javac/diags/examples/ContainedByInheritedMismatch.java - test/tools/javac/diags/examples/ContainedByNoValue.java - test/tools/javac/diags/examples/ContainedByNonDefault.java - test/tools/javac/diags/examples/ContainedByRetentionMismatch.java - test/tools/javac/diags/examples/ContainedByTargetMismatch.java - test/tools/javac/diags/examples/ContainedByWrongValueType.java - test/tools/javac/diags/examples/InferredDoNotConformToLower.java - test/tools/javac/diags/examples/NoUniqueMaximalInstance.java - test/tools/javac/diags/examples/WrongContainedBy.java - test/tools/javac/diags/examples/WrongContainerFor.java - test/tools/javac/lambda/MethodReference26.out - test/tools/javac/lambda/TargetType06.out - test/tools/javac/lambda/TargetType11.out - test/tools/javac/lambda/TargetType45.out - test/tools/javac/lambda/VoidCompatibility.out - test/tools/javac/typeAnnotations/newlocations/BasicTest.java - test/tools/javac/typeAnnotations/newlocations/BasicTest.out Changeset: af8417e590f4 Author: dholmes Date: 2013-02-17 16:44 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/af8417e590f4 Merge ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/javac/code/Flags.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/jvm/ClassReader.java - test/tools/javac/lambda/TargetType20.out - test/tools/javac/lambda/TargetType50.out Changeset: 56dfafbb9e1a Author: katleman Date: 2013-02-21 11:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/56dfafbb9e1a Added tag jdk8-b78 for changeset af8417e590f4 ! .hgtags From alejandro.murillo at oracle.com Fri Feb 22 12:01:31 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 22 Feb 2013 20:01:31 +0000 Subject: hg: hsx/hsx25/hotspot: 39 new changesets Message-ID: <20130222200250.80E8647CE0@hg.openjdk.java.net> Changeset: db3359133cdd Author: katleman Date: 2013-02-21 11:12 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/db3359133cdd Added tag jdk8-b78 for changeset d5e12e7d2f71 ! .hgtags Changeset: 57b81d6c3641 Author: amurillo Date: 2013-02-15 13:36 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/57b81d6c3641 8008286: new hotspot build - hs25-b20 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 7adae9244bc8 Author: mgronlun Date: 2013-02-13 11:23 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7adae9244bc8 8007312: null check signal semaphore in os::signal_notify windows Reviewed-by: dholmes, sla ! src/os/windows/vm/os_windows.cpp Changeset: 2394a89e89f4 Author: rbackman Date: 2013-02-13 09:46 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2394a89e89f4 8008088: SA can hang the VM Reviewed-by: mgronlun, sla, dholmes ! agent/src/os/bsd/libproc_impl.c ! agent/src/os/bsd/libproc_impl.h ! agent/src/os/bsd/ps_proc.c ! agent/src/os/linux/libproc_impl.c ! agent/src/os/linux/libproc_impl.h ! agent/src/os/linux/ps_proc.c Changeset: 49618582fc5b Author: sla Date: 2013-02-14 13:08 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/49618582fc5b 8004840: Jstack seems to output unnecessary information in 7u9 Reviewed-by: dholmes, coleenp, sspitsyn, rbackman ! agent/src/share/classes/sun/jvm/hotspot/memory/CMSCollector.java ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java Changeset: 3a531d40ad93 Author: acorn Date: 2013-02-14 14:33 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3a531d40ad93 8007736: VerifyError for static method in interface Reviewed-by: dholmes, acorn Contributed-by: bharadwaj.yadavalli at oracle.com ! src/share/vm/classfile/verifier.cpp + test/runtime/8007736/TestStaticIF.java Changeset: e7e9e08147fc Author: mikael Date: 2013-02-14 12:36 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e7e9e08147fc 8007639: Workaround for ccache in vm.make is incorrect Summary: Fixed makefile logic to correctly special case JRE_RELEASE_VERSION and vm_version.o Reviewed-by: dholmes, erikj ! make/bsd/makefiles/vm.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make Changeset: 5d5c577296fd Author: sla Date: 2013-02-15 08:54 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5d5c577296fd 8008102: SA on OS X does not stop the attached process Reviewed-by: dholmes, rbackman ! agent/src/os/bsd/MacosxDebuggerLocal.m Changeset: f35f1fbab3e1 Author: sla Date: 2013-02-15 10:08 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f35f1fbab3e1 Merge Changeset: dc1de5e78a85 Author: dsamersoff Date: 2013-02-15 10:29 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dc1de5e78a85 Merge Changeset: f82bcc429e8c Author: sla Date: 2013-02-18 10:43 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f82bcc429e8c 8007901: SA: Don't read flag values as constants Reviewed-by: dholmes, mikael ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/share/vm/runtime/vmStructs.cpp Changeset: b5e3ec9c69fa Author: sla Date: 2013-02-18 12:49 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b5e3ec9c69fa 8007779: os::die() on solaris should generate core file Reviewed-by: dholmes, rbackman ! src/os/solaris/vm/os_solaris.cpp Changeset: 5cd2fac2ae70 Author: hseigel Date: 2013-02-19 08:51 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5cd2fac2ae70 6749267: Signal handler should save/restore errno Summary: Save errno before processing signal, then restore it. Reviewed-by: acorn, sspitsyn ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp Changeset: 56c364daccc3 Author: emc Date: 2013-02-19 11:36 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/56c364daccc3 8007153: Ensure that MethodParameters API works properly with RedefineClasses Summary: Adds code to HotSpot to properly update MethodParameter attributes' constant pool indexes when redefineClasses is called Reviewed-by: coleenp, sspitsyn ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 1048edb5434a Author: coleenp Date: 2013-02-19 13:33 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1048edb5434a Merge Changeset: 20fff74158eb Author: sspitsyn Date: 2013-02-20 08:51 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/20fff74158eb Merge Changeset: bbc7936779f9 Author: brutisso Date: 2013-02-14 09:11 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bbc7936779f9 8006398: Add regression tests for deprectated GCs Reviewed-by: ehelin, jwilhelm, jmasa ! test/TEST.ROOT + test/gc/startup_warnings/TestCMS.java + test/gc/startup_warnings/TestCMSIncrementalMode.java + test/gc/startup_warnings/TestCMSNoIncrementalMode.java + test/gc/startup_warnings/TestDefNewCMS.java + test/gc/startup_warnings/TestG1.java + test/gc/startup_warnings/TestIncGC.java + test/gc/startup_warnings/TestParNewCMS.java + test/gc/startup_warnings/TestParNewSerialOld.java + test/gc/startup_warnings/TestParallelGC.java + test/gc/startup_warnings/TestParallelScavengeSerialOld.java + test/gc/startup_warnings/TestSerialGC.java Changeset: fd7b3770c77e Author: tamao Date: 2013-02-14 14:43 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fd7b3770c77e 8007764: Wrong initialized value of max_gc_pause_sec for an instance of class AdaptiveSizePolicy Summary: This is a fix of an initialization mistake for class AdaptiveSizePolicy. Reviewed-by: jmasa Contributed-by: Tao Mao ! src/share/vm/memory/collectorPolicy.cpp Changeset: ccc57295818b Author: johnc Date: 2013-02-19 16:22 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ccc57295818b 8006628: NEED_TEST for JDK-8002870 Summary: Regression test for 8000311. Verifies that PLABStats works with zero parallel GC threads. Reviewed-by: jmasa, johnc Contributed-by: Filipp Zhinkin + test/gc/8000311/Test8000311.java Changeset: b9c5e46bf915 Author: johnc Date: 2013-02-20 12:52 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b9c5e46bf915 8008188: Add regression test for 8005875 Summary: Add regression test for crash seen in 8005875. Test is run with G1 and PGCT=0 and issues "jcmd Thread.print" against itself. Without the fix for 8005875 the test will crash. Reviewed-by: brutisso + test/gc/TestG1ZeroPGCTJcmdThreadPrint.java Changeset: 5741d3fc502d Author: brutisso Date: 2013-02-21 13:13 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5741d3fc502d Merge Changeset: c59b7900a2bd Author: roland Date: 2013-02-18 09:06 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c59b7900a2bd 8007959: Use expensive node logic for more math nodes Summary: use expensive node logic for other more math nodes. Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/subnode.hpp Changeset: 514efad5e81a Author: drchase Date: 2013-02-18 14:29 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/514efad5e81a 8008180: Several tests in compiler/5091921 need more time to run Summary: Added an explicit timeouts. Reviewed-by: kvn, twisti ! test/compiler/5091921/Test6850611.java ! test/compiler/5091921/Test6890943.java ! test/compiler/5091921/Test6905845.java ! test/compiler/5091921/Test6992759.java Changeset: a2bc322ca273 Author: drchase Date: 2013-02-18 15:08 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a2bc322ca273 7102300: performance warnings cause results diff failure in Test6890943 Summary: Strip lines matching the performance warning from the output before diff. Reviewed-by: kvn ! test/compiler/5091921/Test6890943.sh Changeset: ad736b4683b4 Author: kvn Date: 2013-02-18 16:47 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ad736b4683b4 8004867: VM crashing with assert "share/vm/opto/node.hpp:357 - assert(i < _max) failed: oob" Summary: Added few checks and early bailout from Superword optimization to avoid such cases in a future. Reviewed-by: roland, twisti ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp + test/compiler/8004867/TestIntAtomicCAS.java + test/compiler/8004867/TestIntAtomicOrdered.java + test/compiler/8004867/TestIntAtomicVolatile.java + test/compiler/8004867/TestIntUnsafeCAS.java + test/compiler/8004867/TestIntUnsafeOrdered.java + test/compiler/8004867/TestIntUnsafeVolatile.java Changeset: 2e4b16122164 Author: vlivanov Date: 2013-02-21 06:29 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2e4b16122164 Merge Changeset: 579f6adb7f51 Author: jprovino Date: 2013-02-05 13:32 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/579f6adb7f51 8003539: Minimal VM don't react to -Dcom.sun.management and -XX:+ManagementServer Summary: A warning message should be displayed if these options are used with the Minimal VM. Reviewed-by: dholmes, dsamersoff ! src/share/vm/runtime/arguments.cpp Changeset: 9e2da96f9976 Author: bpittore Date: 2013-02-08 16:08 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9e2da96f9976 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 6c2da81297c5 Author: kvn Date: 2013-02-12 09:54 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6c2da81297c5 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 84a926fe53d0 Author: bpittore Date: 2013-01-24 13:27 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/84a926fe53d0 8005722: Assert in c1_LIR.hpp incorrect wrt to number of register operands Summary: In LIR_OpVisitState::visit() the receiver operand is processed twice Reviewed-by: roland, vladidan ! src/share/vm/c1/c1_LIR.cpp Changeset: cf9a2071eeac Author: jprovino Date: 2013-02-14 11:07 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cf9a2071eeac 8006878: Some non-existent GC source files are in the minimalVM exclude list. Summary: cmsPermGen.cpp, psPermGen.cpp have been removed. yieldWorkingGroup.cpp typo is fixed. immutableSpace.cpp was in the list twice. Reviewed-by: dholmes, jmasa ! make/excludeSrc.make ! src/share/vm/utilities/yieldingWorkgroup.cpp Changeset: 1605eef8e11e Author: jprovino Date: 2013-02-14 11:08 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1605eef8e11e 8003581: UseG1GC is not properly accounted for by INCLUDE_ALTERNATE_GCS Summary: Fix warning messages when selected garbage collectors are excluded from the minimal jvm. Reviewed-by: dholmes, cjplummer ! src/share/vm/runtime/arguments.cpp Changeset: 9c7d0948523f Author: jprovino Date: 2013-02-15 14:42 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9c7d0948523f Merge Changeset: 1ba18258caa4 Author: bpittore Date: 2013-02-15 21:53 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1ba18258caa4 Merge ! src/share/vm/runtime/arguments.cpp Changeset: abf488c22e09 Author: bpittore Date: 2013-02-20 23:29 -0500 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/abf488c22e09 Merge Changeset: 2af22eb04623 Author: vladidan Date: 2013-02-21 09:08 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2af22eb04623 Merge Changeset: ed96c6015470 Author: vladidan Date: 2013-02-21 11:39 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ed96c6015470 Merge Changeset: 555ec35a2507 Author: amurillo Date: 2013-02-22 10:02 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/555ec35a2507 Merge Changeset: 6691814929b6 Author: amurillo Date: 2013-02-22 10:02 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6691814929b6 Added tag hs25-b20 for changeset 555ec35a2507 ! .hgtags From christian.thalinger at oracle.com Fri Feb 22 12:10:25 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 22 Feb 2013 12:10:25 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <5127C98D.3040808@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <4F056DFB-A8E8-4298-A3A2-8220A8462ED1@oracle.com> <5127AB11.1060702@oracle.com> <59FF5558-5BD4-4427-AABC-3EFDFF8FA4BA@oracle.com> <5127C98D.3040808@oracle.com> Message-ID: On Feb 22, 2013, at 11:39 AM, Vladimir Kozlov wrote: > On 2/22/13 11:04 AM, Christian Thalinger wrote: >> >> On Feb 22, 2013, at 9:29 AM, Mikael Vidstedt wrote: >> >>> On 2013-02-22 08:48, Christian Thalinger wrote: >>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>> >>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>> That file is in the JDK I suppose? -- Chris >>> >>> The jdkpath.sh file is generated as part of building hotspot, see buildtree.make in the various OS specific make directories. >> >> Oh. The other script. What is actually env.csh used for? Or .dbxrc? Anyone using these files? > > They are used for incremental build and debugging using gamma: > > "cd solaris_amd64_compiler2/jvmg; gnumake; dbx gamma" > > I work this way. But DBX picks up your ~/.dbxrc by default anyway and the file only contains: $ cat .dbxrc echo '# Loading solaris_amd64_graal/product/.dbxrc' if [ -f "${HOTSPOT_DBXWARE}" ] then source "${HOTSPOT_DBXWARE}" elif [ -f "$HOME/.dbxrc" ] then source "$HOME/.dbxrc" fi The question is what is/was HOTSPOT_DBXWARE? -- Chris > > Vladimir > >> >> -- Chris >> >>> >>> Cheers, >>> Mikael >>> >>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>> >>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>> >>>>>> 8006965: test_gamma should run with import JDK >>>>>> Reviewed-by: >>>>>> >>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>> >>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>> running test_gamma. >>>>>> >>>>>> make/bsd/makefiles/buildtree.make >>>>>> make/defs.make >>>>>> make/linux/makefiles/buildtree.make >>>>>> make/solaris/makefiles/buildtree.make >>> >> From vladimir.kozlov at oracle.com Fri Feb 22 12:23:01 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Feb 2013 12:23:01 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <4F056DFB-A8E8-4298-A3A2-8220A8462ED1@oracle.com> <5127AB11.1060702@oracle.com> <59FF5558-5BD4-4427-AABC-3EFDFF8FA4BA@oracle.com> <5127C98D.3040808@oracle.com> Message-ID: <5127D3A5.7010006@oracle.com> > The question is what is/was HOTSPOT_DBXWARE? I never used or heard about HOTSPOT_DBXWARE. I think we should ask original author :) : s 00189/00000/00000 d D 1.1 00/03/22 15:32:37 jcoomes 1 0 c Build tree generation with dependency checking plus clean up of c generated scripts. test_gamma skips the test for product builds (which c must be installed in a JDK to run); generated .dbxrc will source the c file pointed to by env var $HOTSPOT_DBXWARE if it exists. Thanks, Vladimir On 2/22/13 12:10 PM, Christian Thalinger wrote: > > On Feb 22, 2013, at 11:39 AM, Vladimir Kozlov wrote: > >> On 2/22/13 11:04 AM, Christian Thalinger wrote: >>> >>> On Feb 22, 2013, at 9:29 AM, Mikael Vidstedt wrote: >>> >>>> On 2013-02-22 08:48, Christian Thalinger wrote: >>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>> >>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>> That file is in the JDK I suppose? -- Chris >>>> >>>> The jdkpath.sh file is generated as part of building hotspot, see buildtree.make in the various OS specific make directories. >>> >>> Oh. The other script. What is actually env.csh used for? Or .dbxrc? Anyone using these files? >> >> They are used for incremental build and debugging using gamma: >> >> "cd solaris_amd64_compiler2/jvmg; gnumake; dbx gamma" >> >> I work this way. > > But DBX picks up your ~/.dbxrc by default anyway and the file only contains: > > $ cat .dbxrc > echo '# Loading solaris_amd64_graal/product/.dbxrc' > if [ -f "${HOTSPOT_DBXWARE}" ] > then > source "${HOTSPOT_DBXWARE}" > elif [ -f "$HOME/.dbxrc" ] > then > source "$HOME/.dbxrc" > fi > > The question is what is/was HOTSPOT_DBXWARE? > > -- Chris > >> >> Vladimir >> >>> >>> -- Chris >>> >>>> >>>> Cheers, >>>> Mikael >>>> >>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>> >>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>> >>>>>>> 8006965: test_gamma should run with import JDK >>>>>>> Reviewed-by: >>>>>>> >>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>> >>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>> running test_gamma. >>>>>>> >>>>>>> make/bsd/makefiles/buildtree.make >>>>>>> make/defs.make >>>>>>> make/linux/makefiles/buildtree.make >>>>>>> make/solaris/makefiles/buildtree.make >>>> >>> > From alejandro.murillo at oracle.com Fri Feb 22 13:47:53 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 22 Feb 2013 21:47:53 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130222214802.C2A0B47D24@hg.openjdk.java.net> Changeset: db3359133cdd Author: katleman Date: 2013-02-21 11:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/db3359133cdd Added tag jdk8-b78 for changeset d5e12e7d2f71 ! .hgtags Changeset: 555ec35a2507 Author: amurillo Date: 2013-02-22 10:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/555ec35a2507 Merge Changeset: 6691814929b6 Author: amurillo Date: 2013-02-22 10:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6691814929b6 Added tag hs25-b20 for changeset 555ec35a2507 ! .hgtags Changeset: be1fbee20765 Author: amurillo Date: 2013-02-22 10:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/be1fbee20765 8008692: new hotspot build - hs25-b21 Reviewed-by: jcoomes ! make/hotspot_version From christian.thalinger at oracle.com Fri Feb 22 14:16:41 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 22 Feb 2013 14:16:41 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <5127D3A5.7010006@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <4F056DFB-A8E8-4298-A3A2-8220A8462ED1@oracle.com> <5127AB11.1060702@oracle.com> <59FF5558-5BD4-4427-AABC-3EFDFF8FA4BA@oracle.com> <5127C98D.3040808@oracle.com> <5127D3A5.7010006@oracle.com> Message-ID: <92EBD5E5-1D21-4C0F-B826-C4C3799995D0@oracle.com> On Feb 22, 2013, at 12:23 PM, Vladimir Kozlov wrote: > > The question is what is/was HOTSPOT_DBXWARE? > > I never used or heard about HOTSPOT_DBXWARE. I think we should ask original author :) : Not sure if John's replying but he said that it was there before and he kept it. I couldn't find any reference to HOTSPOT_DBXWARE on our internal websites so I think we could get rid of it. Regarding env.csh, test_gamma always uses sh (and in fact sources env.sh unconditionally) so it's not required by the build. -- Chris > > s 00189/00000/00000 > d D 1.1 00/03/22 15:32:37 jcoomes 1 0 > c Build tree generation with dependency checking plus clean up of > c generated scripts. test_gamma skips the test for product builds (which > c must be installed in a JDK to run); generated .dbxrc will source the > c file pointed to by env var $HOTSPOT_DBXWARE if it exists. > > Thanks, > Vladimir > > On 2/22/13 12:10 PM, Christian Thalinger wrote: >> >> On Feb 22, 2013, at 11:39 AM, Vladimir Kozlov wrote: >> >>> On 2/22/13 11:04 AM, Christian Thalinger wrote: >>>> >>>> On Feb 22, 2013, at 9:29 AM, Mikael Vidstedt wrote: >>>> >>>>> On 2013-02-22 08:48, Christian Thalinger wrote: >>>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>>> >>>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>>> That file is in the JDK I suppose? -- Chris >>>>> >>>>> The jdkpath.sh file is generated as part of building hotspot, see buildtree.make in the various OS specific make directories. >>>> >>>> Oh. The other script. What is actually env.csh used for? Or .dbxrc? Anyone using these files? >>> >>> They are used for incremental build and debugging using gamma: >>> >>> "cd solaris_amd64_compiler2/jvmg; gnumake; dbx gamma" >>> >>> I work this way. >> >> But DBX picks up your ~/.dbxrc by default anyway and the file only contains: >> >> $ cat .dbxrc >> echo '# Loading solaris_amd64_graal/product/.dbxrc' >> if [ -f "${HOTSPOT_DBXWARE}" ] >> then >> source "${HOTSPOT_DBXWARE}" >> elif [ -f "$HOME/.dbxrc" ] >> then >> source "$HOME/.dbxrc" >> fi >> >> The question is what is/was HOTSPOT_DBXWARE? >> >> -- Chris >> >>> >>> Vladimir >>> >>>> >>>> -- Chris >>>> >>>>> >>>>> Cheers, >>>>> Mikael >>>>> >>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>>> >>>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>>> >>>>>>>> 8006965: test_gamma should run with import JDK >>>>>>>> Reviewed-by: >>>>>>>> >>>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>>> >>>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>>> running test_gamma. >>>>>>>> >>>>>>>> make/bsd/makefiles/buildtree.make >>>>>>>> make/defs.make >>>>>>>> make/linux/makefiles/buildtree.make >>>>>>>> make/solaris/makefiles/buildtree.make >>>>> >>>> >> From joseph.provino at oracle.com Fri Feb 22 14:35:12 2013 From: joseph.provino at oracle.com (JOSEPH PROVINO) Date: Fri, 22 Feb 2013 17:35:12 -0500 Subject: Review request 8008310 - Some adjustments needed to, minimal VM warnings and errors for unsupported command line options Message-ID: <5127F2A0.7010506@oracle.com> Webrev is here: http://cr.openjdk.java.net/~jprovino/8008310/webrev.01 Thanks. joe From christian.thalinger at oracle.com Fri Feb 22 15:21:49 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 22 Feb 2013 15:21:49 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> Message-ID: <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: > I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. -- Chris > > Thanks, > /Staffan > > On 22 feb 2013, at 03:40, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/8006965 >> >> 8006965: test_gamma should run with import JDK >> Reviewed-by: >> >> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >> JDK n is the version we are actually compiling for). This setup is >> unsupported and thus should not be done during HotSpot builds. >> >> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >> running test_gamma. >> >> make/bsd/makefiles/buildtree.make >> make/defs.make >> make/linux/makefiles/buildtree.make >> make/solaris/makefiles/buildtree.make >> > From coleen.phillimore at oracle.com Fri Feb 22 16:39:11 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 22 Feb 2013 19:39:11 -0500 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> Message-ID: <51280FAF.3000009@oracle.com> On 2/22/2013 6:21 PM, Christian Thalinger wrote: > On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: > >> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. > How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? > > Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. I use the hotspot script on linux to debug with -gdb, ie: hotspot -gdb It works really well! So the gamma launcher is really good for debugging without having to do odd things like ^C or PauseVMAtStartup to set breakpoints after libjvm.so is loaded. How else can you debug this? For testing, I copy the jvm into a jdk binary. Coleen > > -- Chris > >> Thanks, >> /Staffan >> >> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/8006965 >>> >>> 8006965: test_gamma should run with import JDK >>> Reviewed-by: >>> >>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>> JDK n is the version we are actually compiling for). This setup is >>> unsupported and thus should not be done during HotSpot builds. >>> >>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>> running test_gamma. >>> >>> make/bsd/makefiles/buildtree.make >>> make/defs.make >>> make/linux/makefiles/buildtree.make >>> make/solaris/makefiles/buildtree.make >>> From coleen.phillimore at oracle.com Fri Feb 22 16:43:40 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 22 Feb 2013 19:43:40 -0500 Subject: Review request 8008310 - Some adjustments needed to, minimal VM warnings and errors for unsupported command line options In-Reply-To: <5127F2A0.7010506@oracle.com> References: <5127F2A0.7010506@oracle.com> Message-ID: <512810BC.6020306@oracle.com> On 2/22/2013 5:35 PM, JOSEPH PROVINO wrote: > Webrev is here: http://cr.openjdk.java.net/~jprovino/8008310/webrev.01 > > Thanks. > > joe Joe, This is nice that you can exclude another file. It would be better if filemap.hpp had less CDS_RETURNs. Some of these inlined functions are only called from metaspaceShared.cpp so wouldn't have footprint in .text even if included. I think there are only a couple that are called from outside metaspaceShared - which you already have excluded. If someone says -Xshare:dump aka. -XX:+DumpSharedSpaces, I think this should return JNI_ERR. A warning is good for the rest. Thanks, Coleen From bill.pittore at oracle.com Fri Feb 22 17:40:59 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Fri, 22 Feb 2013 20:40:59 -0500 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <51280FAF.3000009@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <51280FAF.3000009@oracle.com> Message-ID: <51281E2B.5010900@oracle.com> On 2/22/2013 7:39 PM, Coleen Phillimore wrote: > On 2/22/2013 6:21 PM, Christian Thalinger wrote: >> On Feb 22, 2013, at 12:58 AM, Staffan Larsen >> wrote: >> >>> I'm not sure what the correct solution is, but when you do find out, >>> the jdkpath.sh target should also be updated. >> How many are actually using the hotspot script? Would people be very >> sentimental if we would remove the gamma launcher altogether? >> >> Taking to people here it seems that most are copying their libjvm >> into a JDK and use java anyway. > > I use the hotspot script on linux to debug with -gdb, ie: > > hotspot -gdb > > It works really well! So the gamma launcher is really good for > debugging without having to do odd things like ^C or PauseVMAtStartup > to set breakpoints after libjvm.so is loaded. How else can you debug > this? With recent versions of gdb I have no problem debugging using gdb on the java executable gdb --args ./bin/java -cp . HelloWorld GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04 ... (gdb) break ClassVerifier::verify_method Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (ClassVerifier::verify_method) pending. (gdb) run ... Breakpoint 1, ClassVerifier::verify_method (this=0xf732ab60, m=0xf732ab08, __the_thread__=0xf7108000) at /export/users/bpittore/hotspot-emb/hotspot/src/share/vm/classfile/verifier.cpp:575 575 HandleMark hm(THREAD); (gdb) bill > > For testing, I copy the jvm into a jdk binary. > > Coleen >> >> -- Chris >> >>> Thanks, >>> /Staffan >>> >>> On 22 feb 2013, at 03:40, Christian Thalinger >>> wrote: >>> >>>> http://cr.openjdk.java.net/~twisti/8006965 >>>> >>>> 8006965: test_gamma should run with import JDK >>>> Reviewed-by: >>>> >>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>> JDK n is the version we are actually compiling for). This setup is >>>> unsupported and thus should not be done during HotSpot builds. >>>> >>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>> running test_gamma. >>>> >>>> make/bsd/makefiles/buildtree.make >>>> make/defs.make >>>> make/linux/makefiles/buildtree.make >>>> make/solaris/makefiles/buildtree.make >>>> > From christian.thalinger at oracle.com Fri Feb 22 19:44:34 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 22 Feb 2013 19:44:34 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <51280FAF.3000009@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <51280FAF.3000009@oracle.com> Message-ID: <5BBE7A09-6692-4A59-A2F1-B831A4CDFC48@oracle.com> On Feb 22, 2013, at 4:39 PM, Coleen Phillimore wrote: > On 2/22/2013 6:21 PM, Christian Thalinger wrote: >> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >> >>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >> >> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. > > I use the hotspot script on linux to debug with -gdb, ie: > > hotspot -gdb > > It works really well! So the gamma launcher is really good for debugging without having to do odd things like ^C or PauseVMAtStartup to set breakpoints after libjvm.so is loaded. How else can you debug this? Probably the easiest way in both GDB and DBX is to run the VM once without arguments and set the breakpoints then. At that point all libraries are loaded. -- Chris > > For testing, I copy the jvm into a jdk binary. > > Coleen >> >> -- Chris >> >>> Thanks, >>> /Staffan >>> >>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>> >>>> http://cr.openjdk.java.net/~twisti/8006965 >>>> >>>> 8006965: test_gamma should run with import JDK >>>> Reviewed-by: >>>> >>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>> JDK n is the version we are actually compiling for). This setup is >>>> unsupported and thus should not be done during HotSpot builds. >>>> >>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>> running test_gamma. >>>> >>>> make/bsd/makefiles/buildtree.make >>>> make/defs.make >>>> make/linux/makefiles/buildtree.make >>>> make/solaris/makefiles/buildtree.make >>>> > From christian.thalinger at oracle.com Fri Feb 22 19:55:58 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 22 Feb 2013 19:55:58 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> Message-ID: I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: http://cr.openjdk.java.net/~twisti/8006965/ This would be the first of three fixes: Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} -- Chris On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: > > On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: > >> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. > > How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? > > Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. > > -- Chris > >> >> Thanks, >> /Staffan >> >> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/8006965 >>> >>> 8006965: test_gamma should run with import JDK >>> Reviewed-by: >>> >>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>> JDK n is the version we are actually compiling for). This setup is >>> unsupported and thus should not be done during HotSpot builds. >>> >>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>> running test_gamma. >>> >>> make/bsd/makefiles/buildtree.make >>> make/defs.make >>> make/linux/makefiles/buildtree.make >>> make/solaris/makefiles/buildtree.make >>> >> > From poonam.bajaj at oracle.com Sat Feb 23 19:55:29 2013 From: poonam.bajaj at oracle.com (poonam.bajaj at oracle.com) Date: Sun, 24 Feb 2013 03:55:29 +0000 Subject: hg: hsx/hsx25/hotspot: 2 new changesets Message-ID: <20130224035536.7367D47DBC@hg.openjdk.java.net> Changeset: f1fb03a251e9 Author: poonam Date: 2013-02-21 23:58 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f1fb03a251e9 8008546: Wrong G1ConfidencePercent results in GUARANTEE(VARIANCE() > -1.0) FAILED Reviewed-by: brutisso, johnc Contributed-by: vladimir.kempik at oracle.com ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: fd32b88a87e9 Author: poonam Date: 2013-02-23 17:40 -0800 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fd32b88a87e9 Merge From coleen.phillimore at oracle.com Sun Feb 24 14:18:55 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Sun, 24 Feb 2013 17:18:55 -0500 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <51281E2B.5010900@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <51280FAF.3000009@oracle.com> <51281E2B.5010900@oracle.com> Message-ID: <512A91CF.8080109@oracle.com> On 2/22/2013 8:40 PM, BILL PITTORE wrote: > On 2/22/2013 7:39 PM, Coleen Phillimore wrote: >> On 2/22/2013 6:21 PM, Christian Thalinger wrote: >>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen >>> wrote: >>> >>>> I'm not sure what the correct solution is, but when you do find >>>> out, the jdkpath.sh target should also be updated. >>> How many are actually using the hotspot script? Would people be >>> very sentimental if we would remove the gamma launcher altogether? >>> >>> Taking to people here it seems that most are copying their libjvm >>> into a JDK and use java anyway. >> >> I use the hotspot script on linux to debug with -gdb, ie: >> >> hotspot -gdb >> >> It works really well! So the gamma launcher is really good for >> debugging without having to do odd things like ^C or PauseVMAtStartup >> to set breakpoints after libjvm.so is loaded. How else can you debug >> this? > With recent versions of gdb I have no problem debugging using gdb on > the java executable > gdb --args ./bin/java -cp . HelloWorld > GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04 > ... > (gdb) break ClassVerifier::verify_method > Make breakpoint pending on future shared library load? (y or [n]) y > > Breakpoint 1 (ClassVerifier::verify_method) pending. > (gdb) run > ... > > Breakpoint 1, ClassVerifier::verify_method (this=0xf732ab60, > m=0xf732ab08, > __the_thread__=0xf7108000) > at > /export/users/bpittore/hotspot-emb/hotspot/src/share/vm/classfile/verifier.cpp:575 > 575 HandleMark hm(THREAD); > (gdb) > This works on the linux 32 and 64 bit machine we're using. But it only works on 32 bit if DEBUG_BINARIES=true is set while building (this creates binaries with dwarf2 rather than stabs, apparently dwarf takes more disk space so the build by default creates binaries with stabs). I don't think this works on solaris and I don't know about windows. Someone who debugs on windows should tell us how they debug without gamma. Coleen > bill >> >> For testing, I copy the jvm into a jdk binary. >> >> Coleen >>> >>> -- Chris >>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 22 feb 2013, at 03:40, Christian Thalinger >>>> wrote: >>>> >>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>> >>>>> 8006965: test_gamma should run with import JDK >>>>> Reviewed-by: >>>>> >>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>> JDK n is the version we are actually compiling for). This setup is >>>>> unsupported and thus should not be done during HotSpot builds. >>>>> >>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>> running test_gamma. >>>>> >>>>> make/bsd/makefiles/buildtree.make >>>>> make/defs.make >>>>> make/linux/makefiles/buildtree.make >>>>> make/solaris/makefiles/buildtree.make >>>>> >> > From david.holmes at oracle.com Sun Feb 24 14:54:55 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Feb 2013 08:54:55 +1000 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> Message-ID: <512A9A3F.4070402@oracle.com> On 23/02/2013 1:55 PM, Christian Thalinger wrote: > I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: > > http://cr.openjdk.java.net/~twisti/8006965/ > > This would be the first of three fixes: > > Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets This logic is not suitable: 541 # Testing the built JVM 542 ifeq ($(JAVA_HOME),) 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma 544 else 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma 546 endif I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. And this addition still makes no sense to me: MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) Why do you need to add BOOTDIR to the MAKE_ARGS? David > Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 > > Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} > > -- Chris > > On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: > >> >> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >> >>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >> >> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >> >> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >> >> -- Chris >> >>> >>> Thanks, >>> /Staffan >>> >>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>> >>>> http://cr.openjdk.java.net/~twisti/8006965 >>>> >>>> 8006965: test_gamma should run with import JDK >>>> Reviewed-by: >>>> >>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>> JDK n is the version we are actually compiling for). This setup is >>>> unsupported and thus should not be done during HotSpot builds. >>>> >>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>> running test_gamma. >>>> >>>> make/bsd/makefiles/buildtree.make >>>> make/defs.make >>>> make/linux/makefiles/buildtree.make >>>> make/solaris/makefiles/buildtree.make >>>> >>> >> > From david.holmes at oracle.com Sun Feb 24 14:59:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Feb 2013 08:59:42 +1000 Subject: Please review: 8006498 and 8008474 In-Reply-To: <5127822B.9090208@oracle.com> References: <5125448B.8090107@oracle.com> <5125685F.5070907@oracle.com> <51261EDD.2020309@oracle.com> <512633D5.6040202@oracle.com> <5126DF09.2040207@oracle.com> <5126E261.6080601@oracle.com> <5127822B.9090208@oracle.com> Message-ID: <512A9B5E.7040401@oracle.com> On 23/02/2013 12:35 AM, Joseph Provino wrote: > On 02/21/2013 10:13 PM, David Holmes wrote: >> On 22/02/2013 12:59 PM, David Holmes wrote: >>> On 22/02/2013 12:48 AM, JOSEPH PROVINO wrote: >>>> Actually, from looking at this again, I thought David was suggesting >>>> that -Wundef >>>> should be added to ACCEPTABLE_WARNINGS for linux and bsd. >>> >>> I was being ambivalent - I just wanted to see consistency. We should see >>> where Mikael is adding -Wunused >> >> Ha! Now this really muddies the waters (this is linux only): >> >> ! ADDITIONAL_WARNINGS = -Wunused-function >> ! >> ! CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(ACCEPTABLE_WARNINGS) >> $(ADDITIONAL_WARNINGS) > > That's the problem -- it's already inconsistent. The names do not make sense to me but perhaps I am misunderstanding how this works. Are we listing all the warnings that will be errors, or are we listing those warnings that we don't want to be errors? I'm not understanding what acceptable nor additional are supposed to mean here. David > joe > >> >> >> David >> >>> >>> David >>> >>>> joe >>>> >>>> On 2/21/2013 8:19 AM, Zhengyu Gu wrote: >>>>> Agree with David, -Wundef should go to CFLAGS_WARN/DEFAULT on Solaris >>>>> if there is not particular reason not to. >>>>> >>>>> Other than that, look good to me. >>>>> >>>>> -Zhengyu >>>>> >>>>> On 2/20/2013 7:20 PM, David Holmes wrote: >>>>>> On 21/02/2013 7:47 AM, JOSEPH PROVINO wrote: >>>>>>> 8006498: ASSERT and other symbols used incorrectly with #if are >>>>>>> supposed to be defined or not >>>>>>> >>>>>>> 8008474: -Wundef should be added to the build to catch #if >>>>>>> references >>>>>>> to undefined macros. >>>>>>> >>>>>>> >>>>>>> Webrev is here: >>>>>>> http://cr.openjdk.java.net/~jprovino/8006498/webrev.00/ >>>>>> >>>>>> On bsd and linux you simply added -Wundef directly to the CFLAGS: >>>>>> >>>>>> +CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(ACCEPTABLE_WARNINGS) >>>>>> -Wundef >>>>>> >>>>>> but on Solaris you added it to ADDITIONAL_WARNINGS: >>>>>> >>>>>> +ADDITIONAL_WARNINGS = -Wpointer-arith -Wconversion -Wsign-compare >>>>>> -Wundef >>>>>> >>>>>> I guess it is a little confusing as to whether ACCEPTABLE_WARNINGS >>>>>> and ADDITIONAL_WARNINGS are meant to be the same thing. >>>>>> >>>>>> Otherwise all the #if -> #ifdef etc seem okay. >>>>>> >>>>>> David >>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> joe >>>>> >>>> > From david.holmes at oracle.com Sun Feb 24 16:01:47 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Feb 2013 10:01:47 +1000 Subject: Review request 8008310 - Some adjustments needed to, minimal VM warnings and errors for unsupported command line options In-Reply-To: <5127F2A0.7010506@oracle.com> References: <5127F2A0.7010506@oracle.com> Message-ID: <512AA9EB.1040403@oracle.com> On 23/02/2013 8:35 AM, JOSEPH PROVINO wrote: > Webrev is here: http://cr.openjdk.java.net/~jprovino/8008310/webrev.01 An explanation of what has been updated would be useful to the reader, and potential reviewers. I agree with Colleen that -Xshare:dump should be a fatal error as dumping the shared archive is the only thing the VM is supposed to do in that case. I'm also concerned about the filemap.hpp changes. This seems too extensive. If everything is conditional on CDS then shouldn't the whole file be excluded or at least ifdef'd to almost nothing? What is the client code for this? I would expect the client code to already be conditionalized on INCLUDE_CDS else it isn't going to work. David > Thanks. > > joe From david.holmes at oracle.com Mon Feb 25 00:28:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Feb 2013 18:28:01 +1000 Subject: RFR: 8008783 Modifications needed to JPRT Message-ID: <512B2091.1070904@oracle.com> Simple update to jprt.properties to change target names. http://cr.openjdk.java.net/~dholmes/8008783/webrev/ Pushing through hotspot-emb once the renamed promoted builds are available. Thanks, David From bengt.rutisson at oracle.com Mon Feb 25 01:07:19 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 25 Feb 2013 10:07:19 +0100 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <512A91CF.8080109@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <51280FAF.3000009@oracle.com> <51281E2B.5010900@oracle.com> <512A91CF.8080109@oracle.com> Message-ID: <512B29C7.4030706@oracle.com> Hi all, I know I'm a bit late in the game here, but I get a bit worried about removing the gamma launcher. I admit that I don't know much about the launchers or how they are built. But if removing the gamma launcher means that I will have to start copying libjvms around I don't think this is acceptable. Please correct me if I am miss understanding something here. I am always using the hotspot script to execute my newly built hotspots. It is very convenient, and I don't want to have a situation where I have to copy the libjvm every time I want to run my builds. And I certainly don't want to build the whole JDK every time I build. Also, have you looked in to how the Visual Studio projects are affected by this? Again I don't know the details, but debugging support on Windows is excellent and I don't want that to get more difficult if we remove the gamma launcher. Not sure if it is used by the Visual Studio projects though. Bengt On 2/24/13 11:18 PM, Coleen Phillimore wrote: > On 2/22/2013 8:40 PM, BILL PITTORE wrote: >> On 2/22/2013 7:39 PM, Coleen Phillimore wrote: >>> On 2/22/2013 6:21 PM, Christian Thalinger wrote: >>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen >>>> wrote: >>>> >>>>> I'm not sure what the correct solution is, but when you do find >>>>> out, the jdkpath.sh target should also be updated. >>>> How many are actually using the hotspot script? Would people be >>>> very sentimental if we would remove the gamma launcher altogether? >>>> >>>> Taking to people here it seems that most are copying their libjvm >>>> into a JDK and use java anyway. >>> >>> I use the hotspot script on linux to debug with -gdb, ie: >>> >>> hotspot -gdb >>> >>> It works really well! So the gamma launcher is really good for >>> debugging without having to do odd things like ^C or >>> PauseVMAtStartup to set breakpoints after libjvm.so is loaded. How >>> else can you debug this? >> With recent versions of gdb I have no problem debugging using gdb on >> the java executable >> gdb --args ./bin/java -cp . HelloWorld >> GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04 >> ... >> (gdb) break ClassVerifier::verify_method >> Make breakpoint pending on future shared library load? (y or [n]) y >> >> Breakpoint 1 (ClassVerifier::verify_method) pending. >> (gdb) run >> ... >> >> Breakpoint 1, ClassVerifier::verify_method (this=0xf732ab60, >> m=0xf732ab08, >> __the_thread__=0xf7108000) >> at >> /export/users/bpittore/hotspot-emb/hotspot/src/share/vm/classfile/verifier.cpp:575 >> 575 HandleMark hm(THREAD); >> (gdb) >> > > This works on the linux 32 and 64 bit machine we're using. But it > only works on 32 bit if DEBUG_BINARIES=true is set while building > (this creates binaries with dwarf2 rather than stabs, apparently dwarf > takes more disk space so the build by default creates binaries with > stabs). > > I don't think this works on solaris and I don't know about windows. > Someone who debugs on windows should tell us how they debug without > gamma. > > Coleen > >> bill >>> >>> For testing, I copy the jvm into a jdk binary. >>> >>> Coleen >>>> >>>> -- Chris >>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> On 22 feb 2013, at 03:40, Christian Thalinger >>>>> wrote: >>>>> >>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>> >>>>>> 8006965: test_gamma should run with import JDK >>>>>> Reviewed-by: >>>>>> >>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>> >>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>> running test_gamma. >>>>>> >>>>>> make/bsd/makefiles/buildtree.make >>>>>> make/defs.make >>>>>> make/linux/makefiles/buildtree.make >>>>>> make/solaris/makefiles/buildtree.make >>>>>> >>> >> > From staffan.larsen at oracle.com Mon Feb 25 01:41:05 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 25 Feb 2013 10:41:05 +0100 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <512B29C7.4030706@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <51280FAF.3000009@oracle.com> <51281E2B.5010900@oracle.com> <512A91CF.8080109@oracle.com> <512B29C7.4030706@oracle.com> Message-ID: <5349F69E-0A26-471E-AEA2-68EF94F9D10E@oracle.com> I agree with Bengt here. I never copy libjvms around and do not want to. So far I've always used the hotspot script (I added it), but I'm more and more going the way of compiling the whole jdk as it takes only a little bit more time and is much closer to the final product. /Staffan On 25 feb 2013, at 10:07, Bengt Rutisson wrote: > > Hi all, > > I know I'm a bit late in the game here, but I get a bit worried about removing the gamma launcher. I admit that I don't know much about the launchers or how they are built. But if removing the gamma launcher means that I will have to start copying libjvms around I don't think this is acceptable. > > Please correct me if I am miss understanding something here. I am always using the hotspot script to execute my newly built hotspots. It is very convenient, and I don't want to have a situation where I have to copy the libjvm every time I want to run my builds. And I certainly don't want to build the whole JDK every time I build. > > Also, have you looked in to how the Visual Studio projects are affected by this? Again I don't know the details, but debugging support on Windows is excellent and I don't want that to get more difficult if we remove the gamma launcher. Not sure if it is used by the Visual Studio projects though. > > Bengt > > On 2/24/13 11:18 PM, Coleen Phillimore wrote: >> On 2/22/2013 8:40 PM, BILL PITTORE wrote: >>> On 2/22/2013 7:39 PM, Coleen Phillimore wrote: >>>> On 2/22/2013 6:21 PM, Christian Thalinger wrote: >>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>> >>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>>> >>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>> >>>> I use the hotspot script on linux to debug with -gdb, ie: >>>> >>>> hotspot -gdb >>>> >>>> It works really well! So the gamma launcher is really good for debugging without having to do odd things like ^C or PauseVMAtStartup to set breakpoints after libjvm.so is loaded. How else can you debug this? >>> With recent versions of gdb I have no problem debugging using gdb on the java executable >>> gdb --args ./bin/java -cp . HelloWorld >>> GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04 >>> ... >>> (gdb) break ClassVerifier::verify_method >>> Make breakpoint pending on future shared library load? (y or [n]) y >>> >>> Breakpoint 1 (ClassVerifier::verify_method) pending. >>> (gdb) run >>> ... >>> >>> Breakpoint 1, ClassVerifier::verify_method (this=0xf732ab60, m=0xf732ab08, >>> __the_thread__=0xf7108000) >>> at /export/users/bpittore/hotspot-emb/hotspot/src/share/vm/classfile/verifier.cpp:575 >>> 575 HandleMark hm(THREAD); >>> (gdb) >>> >> >> This works on the linux 32 and 64 bit machine we're using. But it only works on 32 bit if DEBUG_BINARIES=true is set while building (this creates binaries with dwarf2 rather than stabs, apparently dwarf takes more disk space so the build by default creates binaries with stabs). >> >> I don't think this works on solaris and I don't know about windows. Someone who debugs on windows should tell us how they debug without gamma. >> >> Coleen >> >>> bill >>>> >>>> For testing, I copy the jvm into a jdk binary. >>>> >>>> Coleen >>>>> >>>>> -- Chris >>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>> >>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>> >>>>>>> 8006965: test_gamma should run with import JDK >>>>>>> Reviewed-by: >>>>>>> >>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>> >>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>> running test_gamma. >>>>>>> >>>>>>> make/bsd/makefiles/buildtree.make >>>>>>> make/defs.make >>>>>>> make/linux/makefiles/buildtree.make >>>>>>> make/solaris/makefiles/buildtree.make >>>>>>> >>>> >>> >> > From jesper.wilhelmsson at oracle.com Mon Feb 25 04:53:11 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 25 Feb 2013 13:53:11 +0100 Subject: RFR: JDK-8008790 - Promotion failed tracing event for all GCs Message-ID: <512B5EB7.4050107@oracle.com> Hi, I'm looking for a couple of reviews for the promotion failed tracing event, now implemented for ParNew and Serial GC. I have replaced the existing counters and booleans with a PromotionFailedInfo object and uses that throughout, so now promotion failed reporting (through the tracing framework) looks the same and reports the same data for all young collectors. I have added two new fields to the promotion failed event: firstSize as reported by ParNew logging, and smallestSize which is the smallest object size that failed to promote. Webrew: http://cr.openjdk.java.net/~jwilhelm/8008790 Testing: Passes JPRT and the existing promotion failed tests with all collectors. Thanks, /Jesper From erik.gahlin at oracle.com Mon Feb 25 05:10:28 2013 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Mon, 25 Feb 2013 14:10:28 +0100 Subject: RFR: JDK-8008790 - Promotion failed tracing event for all GCs In-Reply-To: <512B5EB7.4050107@oracle.com> References: <512B5EB7.4050107@oracle.com> Message-ID: <512B62C4.4090908@oracle.com> Only reviewed the event metadata (trace.xml), but it look good! I'm not a Reviewer. Erik Jesper Wilhelmsson skrev 2/25/13 1:53 PM: > Hi, > > I'm looking for a couple of reviews for the promotion failed tracing > event, now implemented for ParNew and Serial GC. > > I have replaced the existing counters and booleans with a > PromotionFailedInfo object and uses that throughout, so now promotion > failed reporting (through the tracing framework) looks the same and > reports the same data for all young collectors. > > I have added two new fields to the promotion failed event: firstSize > as reported by ParNew logging, and smallestSize which is the smallest > object size that failed to promote. > > Webrew: http://cr.openjdk.java.net/~jwilhelm/8008790 > > Testing: Passes JPRT and the existing promotion failed tests with all > collectors. > > Thanks, > /Jesper From staffan.larsen at oracle.com Mon Feb 25 06:57:05 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Mon, 25 Feb 2013 14:57:05 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130225145712.0B7DF47E28@hg.openjdk.java.net> Changeset: 606aa0fc3944 Author: mgronlun Date: 2013-02-25 10:21 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/606aa0fc3944 8007147: Trace event ExecuteVMOperation may get dangling pointer Reviewed-by: dholmes, sla ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/trace/trace.xml Changeset: 6bd965cc1563 Author: mgronlun Date: 2013-02-13 11:23 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6bd965cc1563 8007312: null check signal semaphore in os::signal_notify windows Reviewed-by: dholmes, sla ! src/os/windows/vm/os_windows.cpp From joseph.provino at oracle.com Mon Feb 25 07:58:02 2013 From: joseph.provino at oracle.com (JOSEPH PROVINO) Date: Mon, 25 Feb 2013 10:58:02 -0500 Subject: Review request 8008310 - Some adjustments needed to, minimal VM warnings and errors for unsupported command line options In-Reply-To: <5127F2A0.7010506@oracle.com> References: <5127F2A0.7010506@oracle.com> Message-ID: <512B8A0A.9050301@oracle.com> Latest webrev is here: http://cr.openjdk.java.net/~jprovino/8008310/webrev.02 - excluded filemap.cpp if CDS is 0. - confined changes for CDS to filemap.hpp. thanks. joe From john.r.rose at oracle.com Mon Feb 25 08:23:38 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 25 Feb 2013 08:23:38 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <92EBD5E5-1D21-4C0F-B826-C4C3799995D0@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <4F056DFB-A8E8-4298-A3A2-8220A8462ED1@oracle.com> <5127AB11.1060702@oracle.com> <59FF5558-5BD4-4427-AABC-3EFDFF8FA4BA@oracle.com> <5127C98D.3040808@oracle.com> <5127D3A5.7010006@oracle.com> <92EBD5E5-1D21-4C0F-B826-C4C3799995D0@oracle.com> Message-ID: On Feb 22, 2013, at 2:16 PM, Christian Thalinger wrote: > Not sure if John's replying but he said that it was there before and he kept it. I couldn't find any reference to HOTSPOT_DBXWARE on our internal websites so I think we could get rid of it. The "dbx ware" was a script (vintage 1999 or so) with a few dbx commands for debugging hotspot. The HOTSPOT_DBXWARE env-var hook almost certainly has not been used in years. The script may be in the same old shared internal directories as the predecessor to hsdis.so. ? John From coleen.phillimore at oracle.com Mon Feb 25 09:06:58 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 25 Feb 2013 12:06:58 -0500 Subject: Review request 8008310 - Some adjustments needed to, minimal VM warnings and errors for unsupported command line options In-Reply-To: <512B8A0A.9050301@oracle.com> References: <5127F2A0.7010506@oracle.com> <512B8A0A.9050301@oracle.com> Message-ID: <512B9A32.1070207@oracle.com> This looks good. Thank you for making the changes. Coleen On 02/25/2013 10:58 AM, JOSEPH PROVINO wrote: > Latest webrev is here: > http://cr.openjdk.java.net/~jprovino/8008310/webrev.02 > > - excluded filemap.cpp if CDS is 0. > > - confined changes for CDS to filemap.hpp. > > thanks. > > joe > > From christian.thalinger at oracle.com Mon Feb 25 09:11:15 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 25 Feb 2013 09:11:15 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <5349F69E-0A26-471E-AEA2-68EF94F9D10E@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <51280FAF.3000009@oracle.com> <51281E2B.5010900@oracle.com> <512A91CF.8080109@oracle.com> <512B29C7.4030706@oracle.com> <5349F69E-0A26-471E-AEA2-68EF94F9D10E@oracle.com> Message-ID: <977C66BB-C7EA-46AF-BA87-BC34005C959D@oracle.com> On Feb 25, 2013, at 1:41 AM, Staffan Larsen wrote: > I agree with Bengt here. I never copy libjvms around and do not want to. So far I've always used the hotspot script (I added it), but I'm more and more going the way of compiling the whole jdk as it takes only a little bit more time and is much closer to the final product. So in fact you are copying the libjvm around. It's just that the JDK build does it for you. Btw. there are make targets that do this copying. -- Chris > > /Staffan > > On 25 feb 2013, at 10:07, Bengt Rutisson wrote: > >> >> Hi all, >> >> I know I'm a bit late in the game here, but I get a bit worried about removing the gamma launcher. I admit that I don't know much about the launchers or how they are built. But if removing the gamma launcher means that I will have to start copying libjvms around I don't think this is acceptable. >> >> Please correct me if I am miss understanding something here. I am always using the hotspot script to execute my newly built hotspots. It is very convenient, and I don't want to have a situation where I have to copy the libjvm every time I want to run my builds. And I certainly don't want to build the whole JDK every time I build. >> >> Also, have you looked in to how the Visual Studio projects are affected by this? Again I don't know the details, but debugging support on Windows is excellent and I don't want that to get more difficult if we remove the gamma launcher. Not sure if it is used by the Visual Studio projects though. >> >> Bengt >> >> On 2/24/13 11:18 PM, Coleen Phillimore wrote: >>> On 2/22/2013 8:40 PM, BILL PITTORE wrote: >>>> On 2/22/2013 7:39 PM, Coleen Phillimore wrote: >>>>> On 2/22/2013 6:21 PM, Christian Thalinger wrote: >>>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>>> >>>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>>>> >>>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>>> >>>>> I use the hotspot script on linux to debug with -gdb, ie: >>>>> >>>>> hotspot -gdb >>>>> >>>>> It works really well! So the gamma launcher is really good for debugging without having to do odd things like ^C or PauseVMAtStartup to set breakpoints after libjvm.so is loaded. How else can you debug this? >>>> With recent versions of gdb I have no problem debugging using gdb on the java executable >>>> gdb --args ./bin/java -cp . HelloWorld >>>> GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04 >>>> ... >>>> (gdb) break ClassVerifier::verify_method >>>> Make breakpoint pending on future shared library load? (y or [n]) y >>>> >>>> Breakpoint 1 (ClassVerifier::verify_method) pending. >>>> (gdb) run >>>> ... >>>> >>>> Breakpoint 1, ClassVerifier::verify_method (this=0xf732ab60, m=0xf732ab08, >>>> __the_thread__=0xf7108000) >>>> at /export/users/bpittore/hotspot-emb/hotspot/src/share/vm/classfile/verifier.cpp:575 >>>> 575 HandleMark hm(THREAD); >>>> (gdb) >>> >>> This works on the linux 32 and 64 bit machine we're using. But it only works on 32 bit if DEBUG_BINARIES=true is set while building (this creates binaries with dwarf2 rather than stabs, apparently dwarf takes more disk space so the build by default creates binaries with stabs). >>> >>> I don't think this works on solaris and I don't know about windows. Someone who debugs on windows should tell us how they debug without gamma. >>> >>> Coleen >>> >>>> bill >>>>> >>>>> For testing, I copy the jvm into a jdk binary. >>>>> >>>>> Coleen >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>>> >>>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>>> >>>>>>>> 8006965: test_gamma should run with import JDK >>>>>>>> Reviewed-by: >>>>>>>> >>>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>>> >>>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>>> running test_gamma. >>>>>>>> >>>>>>>> make/bsd/makefiles/buildtree.make >>>>>>>> make/defs.make >>>>>>>> make/linux/makefiles/buildtree.make >>>>>>>> make/solaris/makefiles/buildtree.make > From mikael.vidstedt at oracle.com Mon Feb 25 10:33:25 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 25 Feb 2013 10:33:25 -0800 Subject: Please review: 8006498 and 8008474 In-Reply-To: <512A9B5E.7040401@oracle.com> References: <5125448B.8090107@oracle.com> <5125685F.5070907@oracle.com> <51261EDD.2020309@oracle.com> <512633D5.6040202@oracle.com> <5126DF09.2040207@oracle.com> <5126E261.6080601@oracle.com> <5127822B.9090208@oracle.com> <512A9B5E.7040401@oracle.com> Message-ID: <512BAE75.5080800@oracle.com> On 2/24/2013 2:59 PM, David Holmes wrote: > On 23/02/2013 12:35 AM, Joseph Provino wrote: >> On 02/21/2013 10:13 PM, David Holmes wrote: >>> On 22/02/2013 12:59 PM, David Holmes wrote: >>>> On 22/02/2013 12:48 AM, JOSEPH PROVINO wrote: >>>>> Actually, from looking at this again, I thought David was suggesting >>>>> that -Wundef >>>>> should be added to ACCEPTABLE_WARNINGS for linux and bsd. >>>> >>>> I was being ambivalent - I just wanted to see consistency. We >>>> should see >>>> where Mikael is adding -Wunused >>> >>> Ha! Now this really muddies the waters (this is linux only): >>> >>> ! ADDITIONAL_WARNINGS = -Wunused-function >>> ! >>> ! CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(ACCEPTABLE_WARNINGS) >>> $(ADDITIONAL_WARNINGS) >> >> That's the problem -- it's already inconsistent. > > The names do not make sense to me but perhaps I am misunderstanding > how this works. Are we listing all the warnings that will be errors, > or are we listing those warnings that we don't want to be errors? I'm > not understanding what acceptable nor additional are supposed to mean > here. I can't say that I see any real patterns in how these variables are used either. My guess is that at some point somebody figured out a few warnings that were "acceptable" - as in warnings that we could turn on without getting tons of false positives and incorrectly generated code, but that's just a guess. Unless somebody has insights around why these are named and split up the way they are I suggest that we simplify and unify all of it. My suggestion is to have all the warning flags go into a variable called WARNING_FLAGS, leaving only two variables: WARNINGS_ARE_ERRORS and WARNING_FLAGS. Something like this (for Linux, similar for Solaris): WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wunused-functions -Wundef # Since GCC 4.3, -Wconversion has changed its meanings to warn these implicit # conversions which might affect the values. To avoid that, we do not use it. ifeq "$(shell expr \( $(CC_VER_MAJOR) \> 4 \) \| \( \( $(CC_VER_MAJOR) = 4 \) \& \( $(CC_VER_MINOR) \>= 3 \) \))" "0" WARNING_FLAGS += -Wconversion endif CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(WARNING_FLAGS) Reasonable? Cheers, Mikael > > David > >> joe >> >>> >>> >>> David >>> >>>> >>>> David >>>> >>>>> joe >>>>> >>>>> On 2/21/2013 8:19 AM, Zhengyu Gu wrote: >>>>>> Agree with David, -Wundef should go to CFLAGS_WARN/DEFAULT on >>>>>> Solaris >>>>>> if there is not particular reason not to. >>>>>> >>>>>> Other than that, look good to me. >>>>>> >>>>>> -Zhengyu >>>>>> >>>>>> On 2/20/2013 7:20 PM, David Holmes wrote: >>>>>>> On 21/02/2013 7:47 AM, JOSEPH PROVINO wrote: >>>>>>>> 8006498: ASSERT and other symbols used incorrectly with #if are >>>>>>>> supposed to be defined or not >>>>>>>> >>>>>>>> 8008474: -Wundef should be added to the build to catch #if >>>>>>>> references >>>>>>>> to undefined macros. >>>>>>>> >>>>>>>> >>>>>>>> Webrev is here: >>>>>>>> http://cr.openjdk.java.net/~jprovino/8006498/webrev.00/ >>>>>>> >>>>>>> On bsd and linux you simply added -Wundef directly to the CFLAGS: >>>>>>> >>>>>>> +CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) >>>>>>> $(ACCEPTABLE_WARNINGS) >>>>>>> -Wundef >>>>>>> >>>>>>> but on Solaris you added it to ADDITIONAL_WARNINGS: >>>>>>> >>>>>>> +ADDITIONAL_WARNINGS = -Wpointer-arith -Wconversion -Wsign-compare >>>>>>> -Wundef >>>>>>> >>>>>>> I guess it is a little confusing as to whether ACCEPTABLE_WARNINGS >>>>>>> and ADDITIONAL_WARNINGS are meant to be the same thing. >>>>>>> >>>>>>> Otherwise all the #if -> #ifdef etc seem okay. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> joe >>>>>> >>>>> >> From joseph.provino at oracle.com Mon Feb 25 10:39:48 2013 From: joseph.provino at oracle.com (JOSEPH PROVINO) Date: Mon, 25 Feb 2013 13:39:48 -0500 Subject: Please review: 8006498 and 8008474 In-Reply-To: <512BAE75.5080800@oracle.com> References: <5125448B.8090107@oracle.com> <5125685F.5070907@oracle.com> <51261EDD.2020309@oracle.com> <512633D5.6040202@oracle.com> <5126DF09.2040207@oracle.com> <5126E261.6080601@oracle.com> <5127822B.9090208@oracle.com> <512A9B5E.7040401@oracle.com> <512BAE75.5080800@oracle.com> Message-ID: <512BAFF4.60603@oracle.com> On 2/25/2013 1:33 PM, Mikael Vidstedt wrote: > > On 2/24/2013 2:59 PM, David Holmes wrote: >> On 23/02/2013 12:35 AM, Joseph Provino wrote: >>> On 02/21/2013 10:13 PM, David Holmes wrote: >>>> On 22/02/2013 12:59 PM, David Holmes wrote: >>>>> On 22/02/2013 12:48 AM, JOSEPH PROVINO wrote: >>>>>> Actually, from looking at this again, I thought David was suggesting >>>>>> that -Wundef >>>>>> should be added to ACCEPTABLE_WARNINGS for linux and bsd. >>>>> >>>>> I was being ambivalent - I just wanted to see consistency. We >>>>> should see >>>>> where Mikael is adding -Wunused >>>> >>>> Ha! Now this really muddies the waters (this is linux only): >>>> >>>> ! ADDITIONAL_WARNINGS = -Wunused-function >>>> ! >>>> ! CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(ACCEPTABLE_WARNINGS) >>>> $(ADDITIONAL_WARNINGS) >>> >>> That's the problem -- it's already inconsistent. >> >> The names do not make sense to me but perhaps I am misunderstanding >> how this works. Are we listing all the warnings that will be errors, >> or are we listing those warnings that we don't want to be errors? I'm >> not understanding what acceptable nor additional are supposed to mean >> here. > > I can't say that I see any real patterns in how these variables are > used either. My guess is that at some point somebody figured out a few > warnings that were "acceptable" - as in warnings that we could turn on > without getting tons of false positives and incorrectly generated > code, but that's just a guess. Unless somebody has insights around why > these are named and split up the way they are I suggest that we > simplify and unify all of it. > > My suggestion is to have all the warning flags go into a variable > called WARNING_FLAGS, leaving only two variables: WARNINGS_ARE_ERRORS > and WARNING_FLAGS. Something like this (for Linux, similar for Solaris): > > WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wunused-functions -Wundef > > # Since GCC 4.3, -Wconversion has changed its meanings to warn these > implicit > # conversions which might affect the values. To avoid that, we do not > use it. > ifeq "$(shell expr \( $(CC_VER_MAJOR) \> 4 \) \| \( \( $(CC_VER_MAJOR) > = 4 \) \& \( $(CC_VER_MINOR) \>= 3 \) \))" "0" > WARNING_FLAGS += -Wconversion > endif > > CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(WARNING_FLAGS) > > Reasonable? Sounds good to me. joe > > Cheers, > Mikael > > >> >> David >> >>> joe >>> >>>> >>>> >>>> David >>>> >>>>> >>>>> David >>>>> >>>>>> joe >>>>>> >>>>>> On 2/21/2013 8:19 AM, Zhengyu Gu wrote: >>>>>>> Agree with David, -Wundef should go to CFLAGS_WARN/DEFAULT on >>>>>>> Solaris >>>>>>> if there is not particular reason not to. >>>>>>> >>>>>>> Other than that, look good to me. >>>>>>> >>>>>>> -Zhengyu >>>>>>> >>>>>>> On 2/20/2013 7:20 PM, David Holmes wrote: >>>>>>>> On 21/02/2013 7:47 AM, JOSEPH PROVINO wrote: >>>>>>>>> 8006498: ASSERT and other symbols used incorrectly with #if are >>>>>>>>> supposed to be defined or not >>>>>>>>> >>>>>>>>> 8008474: -Wundef should be added to the build to catch #if >>>>>>>>> references >>>>>>>>> to undefined macros. >>>>>>>>> >>>>>>>>> >>>>>>>>> Webrev is here: >>>>>>>>> http://cr.openjdk.java.net/~jprovino/8006498/webrev.00/ >>>>>>>> >>>>>>>> On bsd and linux you simply added -Wundef directly to the CFLAGS: >>>>>>>> >>>>>>>> +CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) >>>>>>>> $(ACCEPTABLE_WARNINGS) >>>>>>>> -Wundef >>>>>>>> >>>>>>>> but on Solaris you added it to ADDITIONAL_WARNINGS: >>>>>>>> >>>>>>>> +ADDITIONAL_WARNINGS = -Wpointer-arith -Wconversion -Wsign-compare >>>>>>>> -Wundef >>>>>>>> >>>>>>>> I guess it is a little confusing as to whether ACCEPTABLE_WARNINGS >>>>>>>> and ADDITIONAL_WARNINGS are meant to be the same thing. >>>>>>>> >>>>>>>> Otherwise all the #if -> #ifdef etc seem okay. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> joe >>>>>>> >>>>>> >>> > From christian.thalinger at oracle.com Mon Feb 25 10:42:13 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 25 Feb 2013 10:42:13 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <512A9A3F.4070402@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> Message-ID: <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> On Feb 24, 2013, at 2:54 PM, David Holmes wrote: > On 23/02/2013 1:55 PM, Christian Thalinger wrote: >> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: >> >> http://cr.openjdk.java.net/~twisti/8006965/ >> >> This would be the first of three fixes: >> >> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets > > This logic is not suitable: > > 541 # Testing the built JVM > 542 ifeq ($(JAVA_HOME),) > 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma > 544 else > 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma > 546 endif > > I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! That's not entirely correct. test_gamma uses your JAVA_HOME setting: cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma JAVA_HOME must point to a 64-bit OpenJDK. And here comes this little snippet into play: -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. > > I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. > > I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. -- Chris > > And this addition still makes no sense to me: > > MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) > > Why do you need to add BOOTDIR to the MAKE_ARGS? > > David > > >> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 >> >> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} >> >> -- Chris >> >> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: >> >>> >>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>> >>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>> >>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>> >>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>> >>> -- Chris >>> >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>> >>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>> >>>>> 8006965: test_gamma should run with import JDK >>>>> Reviewed-by: >>>>> >>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>> JDK n is the version we are actually compiling for). This setup is >>>>> unsupported and thus should not be done during HotSpot builds. >>>>> >>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>> running test_gamma. >>>>> >>>>> make/bsd/makefiles/buildtree.make >>>>> make/defs.make >>>>> make/linux/makefiles/buildtree.make >>>>> make/solaris/makefiles/buildtree.make >>>>> >>>> >>> >> From christian.thalinger at oracle.com Mon Feb 25 10:53:08 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 25 Feb 2013 10:53:08 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <512B29C7.4030706@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <51280FAF.3000009@oracle.com> <51281E2B.5010900@oracle.com> <512A91CF.8080109@oracle.com> <512B29C7.4030706@oracle.com> Message-ID: <5A7AB3CC-FA3F-449A-88C8-E63474466442@oracle.com> On Feb 25, 2013, at 1:07 AM, Bengt Rutisson wrote: > > Hi all, > > I know I'm a bit late in the game here Not too late; we're just getting started :-) > , but I get a bit worried about removing the gamma launcher. I admit that I don't know much about the launchers or how they are built. But if removing the gamma launcher means that I will have to start copying libjvms around I don't think this is acceptable. > > Please correct me if I am miss understanding something here. I am always using the hotspot script to execute my newly built hotspots. It is very convenient, and I don't want to have a situation where I have to copy the libjvm every time I want to run my builds. And I certainly don't want to build the whole JDK every time I build. The hotspot script doesn't go away; I know that a lot of people use it. Mikael and I found a way to run the newly built libjvm without copying somewhere and without using gamma. You shouldn't notice any difference. > > Also, have you looked in to how the Visual Studio projects are affected by this? Again I don't know the details, but debugging support on Windows is excellent and I don't want that to get more difficult if we remove the gamma launcher. Not sure if it is used by the Visual Studio projects though. Honestly, I never did a manual build on Windows. If, as you say, debugging support is excellent on Windows than it certainly should be able to handle a shared libjvm library (that's what most people are concerned about: statically linked gamma vs. java launcher dlopen'ing libjvm). -- Chris > > Bengt > > On 2/24/13 11:18 PM, Coleen Phillimore wrote: >> On 2/22/2013 8:40 PM, BILL PITTORE wrote: >>> On 2/22/2013 7:39 PM, Coleen Phillimore wrote: >>>> On 2/22/2013 6:21 PM, Christian Thalinger wrote: >>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>> >>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>>> >>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>> >>>> I use the hotspot script on linux to debug with -gdb, ie: >>>> >>>> hotspot -gdb >>>> >>>> It works really well! So the gamma launcher is really good for debugging without having to do odd things like ^C or PauseVMAtStartup to set breakpoints after libjvm.so is loaded. How else can you debug this? >>> With recent versions of gdb I have no problem debugging using gdb on the java executable >>> gdb --args ./bin/java -cp . HelloWorld >>> GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04 >>> ... >>> (gdb) break ClassVerifier::verify_method >>> Make breakpoint pending on future shared library load? (y or [n]) y >>> >>> Breakpoint 1 (ClassVerifier::verify_method) pending. >>> (gdb) run >>> ... >>> >>> Breakpoint 1, ClassVerifier::verify_method (this=0xf732ab60, m=0xf732ab08, >>> __the_thread__=0xf7108000) >>> at /export/users/bpittore/hotspot-emb/hotspot/src/share/vm/classfile/verifier.cpp:575 >>> 575 HandleMark hm(THREAD); >>> (gdb) >>> >> >> This works on the linux 32 and 64 bit machine we're using. But it only works on 32 bit if DEBUG_BINARIES=true is set while building (this creates binaries with dwarf2 rather than stabs, apparently dwarf takes more disk space so the build by default creates binaries with stabs). >> >> I don't think this works on solaris and I don't know about windows. Someone who debugs on windows should tell us how they debug without gamma. >> >> Coleen >> >>> bill >>>> >>>> For testing, I copy the jvm into a jdk binary. >>>> >>>> Coleen >>>>> >>>>> -- Chris >>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>> >>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>> >>>>>>> 8006965: test_gamma should run with import JDK >>>>>>> Reviewed-by: >>>>>>> >>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>> >>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>> running test_gamma. >>>>>>> >>>>>>> make/bsd/makefiles/buildtree.make >>>>>>> make/defs.make >>>>>>> make/linux/makefiles/buildtree.make >>>>>>> make/solaris/makefiles/buildtree.make >>>>>>> >>>> >>> >> > From staffan.larsen at oracle.com Mon Feb 25 11:34:50 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 25 Feb 2013 20:34:50 +0100 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <977C66BB-C7EA-46AF-BA87-BC34005C959D@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <51280FAF.3000009@oracle.com> <51281E2B.5010900@oracle.com> <512A91CF.8080109@oracle.com> <512B29C7.4030706@oracle.com> <5349F69E-0A26-471E-AEA2-68EF94F9D10E@oracle.com> <977C66BB-C7EA-46AF-BA87-BC34005C959D@oracle.com> Message-ID: On 25 feb 2013, at 18:11, Christian Thalinger wrote: > > On Feb 25, 2013, at 1:41 AM, Staffan Larsen wrote: > >> I agree with Bengt here. I never copy libjvms around and do not want to. So far I've always used the hotspot script (I added it), but I'm more and more going the way of compiling the whole jdk as it takes only a little bit more time and is much closer to the final product. > > So in fact you are copying the libjvm around. It's just that the JDK build does it for you. Fair enough - but the less I have to care about it, the better. /Staffan From christian.thalinger at oracle.com Mon Feb 25 11:41:22 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 25 Feb 2013 11:41:22 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <51280FAF.3000009@oracle.com> <51281E2B.5010900@oracle.com> <512A91CF.8080109@oracle.com> <512B29C7.4030706@oracle.com> <5349F69E-0A26-471E-AEA2-68EF94F9D10E@oracle.com> <977C66BB-C7EA-46AF-BA87-BC34005C959D@oracle.com> Message-ID: <3BDFA6C8-767E-4191-85B9-356EFEEEA515@oracle.com> On Feb 25, 2013, at 11:34 AM, Staffan Larsen wrote: > > On 25 feb 2013, at 18:11, Christian Thalinger wrote: > >> >> On Feb 25, 2013, at 1:41 AM, Staffan Larsen wrote: >> >>> I agree with Bengt here. I never copy libjvms around and do not want to. So far I've always used the hotspot script (I added it), but I'm more and more going the way of compiling the whole jdk as it takes only a little bit more time and is much closer to the final product. >> >> So in fact you are copying the libjvm around. It's just that the JDK build does it for you. > > Fair enough - but the less I have to care about it, the better. Right. You are good either way. -- Chris > > /Staffan > From mikael.vidstedt at oracle.com Mon Feb 25 12:38:58 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 25 Feb 2013 12:38:58 -0800 Subject: RFR (S): 8008081: Print outs do not have matching arguments In-Reply-To: <5121677B.8010402@oracle.com> References: <511AFA0A.2090504@oracle.com> <511DECFA.9090406@oracle.com> <511EDC9C.1000208@oracle.com> <5121677B.8010402@oracle.com> Message-ID: <512BCBE2.4060802@oracle.com> On 2013-02-17 15:27, David Holmes wrote: > On 16/02/2013 11:10 AM, Mikael Vidstedt wrote: >> >> On 2/15/2013 12:08 AM, David Holmes wrote: >>> On 13/02/2013 12:27 PM, Mikael Vidstedt wrote: >>>> Please review the following change: >>>> >>>> http://cr.openjdk.java.net/~mikael/webrevs/8008081/webrev.00/webrev >>>> >>>> Background: >>>> >>>> I found a few occurrences of calls to print type functions where the >>>> arguments do not match the format string. I hope that I have added the >>>> right/intended arguments in the respective places but could use some >>>> help to verify that that is indeed the case. >>> >>> In c1_FrameMap: >>> >>> 316 if( _num_monitors > 0) { >>> 317 tty->print_cr("monitor [0]:%d | [%2d]:%d", >>> 318 in_bytes(sp_offset_for_monitor_base(0)), >>> 319 in_bytes(sp_offset_for_monitor_base(_num_monitors)), >>> 320 _num_monitors); >>> 321 } >>> >>> I think the last two args need swapping and should it be >>> _num_monitors-1 ie the "index" ? And does that make >>> sp_offset_for_monitor_base(_num_monitors) wrong ?? >> >> Agreed, they should indeed be swapped. Thanks Staffan/David for pointing >> this out! >> >> Whether or not it should be _num_monitors-1 is indeed a good question. >> The code below uses num_spills-1 and prints things slightly differently >> if there is only one spill, so for symmetry reasons maybe this code >> should do the same thing? I'm counting on a C1 expert to provide >> guidance. > > Not a C1 expert but this: > > void check_monitor_index (int monitor_index) const { > assert(monitor_index >= 0 && monitor_index < _num_monitors, "bad > index"); } > > indicates that we shouldn't be using > sp_offset_for_monitor_base(_num_monitors) I asked on hotspot-compiler-dev (now also cross posted) and the conclusion is that the print_frame_layout function can be removed all together. That makes the webrev look like this: http://cr.openjdk.java.net/~mikael/webrevs/8008081/webrev.02/webrev/ Only c1_FrameMap.cpp and c1_FrameMap.hpp have been changed (from webrev.01). Good? Cheers, Mikael > > Cheers, > David > ----- > > >> Meanwhile I've updated the webrev to add _num_monitors in the right >> place: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8008081/webrev.01/webrev/ >> >>> Everything else seems reasonable - some obvious, some less so - but >>> all 1000% better than before ;-) >> >> Wow, that sure is a lot of % :) >> >> Cheers, >> Mikael >> >>> >>> David >>> ----- >>> >>> >>>> One special case is in this webrev is jvmtiEnter.xls. Since it is used >>>> to generate the jvmtiEnterTrace.cpp file and therefore is a bit less >>>> obvious to review I have prepared a pair of before/after files for >>>> your >>>> convenience: >>>> >>>> Before: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.orig >>>> >>>> >>>> After: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.fixed >>>> >>>> >>>> >>>> >>>> I also prepared a diff -u of before vs after: >>>> >>>> http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.diff >>>> >>>> >>>> >>>> Passes JPRT. >>>> >>>> Cheers, >>>> Mikael >> From nils.loodin at oracle.com Mon Feb 25 17:07:27 2013 From: nils.loodin at oracle.com (nils.loodin at oracle.com) Date: Tue, 26 Feb 2013 01:07:27 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130226010736.8748B47EC2@hg.openjdk.java.net> Changeset: a71f8a0deaf1 Author: nloodin Date: 2013-02-25 15:01 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a71f8a0deaf1 8007085: EnableTracing prints garbage for Compilation: [Java Method Reviewed-by: coleenp, sla Contributed-by: markus.gronlund at oracle.com ! src/share/vm/trace/traceStream.hpp Changeset: 1273de7c42d4 Author: nloodin Date: 2013-02-25 14:44 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1273de7c42d4 Merge From david.holmes at oracle.com Mon Feb 25 17:43:37 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Feb 2013 11:43:37 +1000 Subject: Review request 8008310 - Some adjustments needed to, minimal VM warnings and errors for unsupported command line options In-Reply-To: <512B8A0A.9050301@oracle.com> References: <5127F2A0.7010506@oracle.com> <512B8A0A.9050301@oracle.com> Message-ID: <512C1349.1020706@oracle.com> On 26/02/2013 1:58 AM, JOSEPH PROVINO wrote: > Latest webrev is here: > http://cr.openjdk.java.net/~jprovino/8008310/webrev.02 > > - excluded filemap.cpp if CDS is 0. > > - confined changes for CDS to filemap.hpp. These changes are good - thanks. For arguments.cpp: 1076 FLAG_SET_DEFAULT(RequireSharedSpaces, false); If we execute this line then the flag is already false. Also, as discussed in email -Xshare:dump should probably be an error not a warning, but note that if left as a warning then this code: 2518 // -Xshare:dump 2519 } else if (match_option(option, "-Xshare:dump", &tail)) { 2520 FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true); 2521 set_mode_flags(_int); // Prevent compilation, which creates objects would also force us into intepreter mode, so you would still need to check INCLUDE_CDS here. David ----- > thanks. > > joe > > From John.Coomes at oracle.com Mon Feb 25 18:05:47 2013 From: John.Coomes at oracle.com (John Coomes) Date: Mon, 25 Feb 2013 18:05:47 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <512A91CF.8080109@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <51280FAF.3000009@oracle.com> <51281E2B.5010900@oracle.com> <512A91CF.8080109@oracle.com> Message-ID: <20780.6267.110385.2062@oracle.com> Coleen Phillimore (coleen.phillimore at oracle.com) wrote: > On 2/22/2013 8:40 PM, BILL PITTORE wrote: > > On 2/22/2013 7:39 PM, Coleen Phillimore wrote: > >> On 2/22/2013 6:21 PM, Christian Thalinger wrote: > >>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen > >>> wrote: > >>> > >>>> I'm not sure what the correct solution is, but when you do find > >>>> out, the jdkpath.sh target should also be updated. > >>> How many are actually using the hotspot script? Would people be > >>> very sentimental if we would remove the gamma launcher altogether? > >>> > >>> Taking to people here it seems that most are copying their libjvm > >>> into a JDK and use java anyway. > >> > >> I use the hotspot script on linux to debug with -gdb, ie: > >> > >> hotspot -gdb > >> > >> It works really well! So the gamma launcher is really good for > >> debugging without having to do odd things like ^C or PauseVMAtStartup > >> to set breakpoints after libjvm.so is loaded. How else can you debug > >> this? > > With recent versions of gdb I have no problem debugging using gdb on > > the java executable > > gdb --args ./bin/java -cp . HelloWorld > > GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04 > > ... > > (gdb) break ClassVerifier::verify_method > > Make breakpoint pending on future shared library load? (y or [n]) y > > > > Breakpoint 1 (ClassVerifier::verify_method) pending. > > (gdb) run > > ... > > This works on the linux 32 and 64 bit machine we're using. But it only > works on 32 bit if DEBUG_BINARIES=true is set while building (this > creates binaries with dwarf2 rather than stabs, apparently dwarf takes > more disk space so the build by default creates binaries with stabs). > > I don't think this works on solaris and I don't know about windows. On solaris (dbx) you can do this: $ dbx java dbx> when dlopen libjvm.so { stop in JNI_CreateJavaVM; } dbx> run -version > Someone who debugs on windows should tell us how they debug without gamma. I haven't used it for a number of years, but it certainly used to work when you built from within visual studio. make/windows/create.bat (which creates the VS project) takes a parameter that defines the JDK to use to run the newly-built JVM. -John > >> For testing, I copy the jvm into a jdk binary. > >> > >> Coleen > >>> > >>> -- Chris > >>> > >>>> Thanks, > >>>> /Staffan > >>>> > >>>> On 22 feb 2013, at 03:40, Christian Thalinger > >>>> wrote: > >>>> > >>>>> http://cr.openjdk.java.net/~twisti/8006965 > >>>>> > >>>>> 8006965: test_gamma should run with import JDK > >>>>> Reviewed-by: > >>>>> > >>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where > >>>>> JDK n is the version we are actually compiling for). This setup is > >>>>> unsupported and thus should not be done during HotSpot builds. > >>>>> > >>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when > >>>>> running test_gamma. > >>>>> > >>>>> make/bsd/makefiles/buildtree.make > >>>>> make/defs.make > >>>>> make/linux/makefiles/buildtree.make > >>>>> make/solaris/makefiles/buildtree.make > >>>>> > >> > > > From david.holmes at oracle.com Mon Feb 25 21:24:25 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Feb 2013 15:24:25 +1000 Subject: RFR (S): 8008081: Print outs do not have matching arguments In-Reply-To: <512BCBE2.4060802@oracle.com> References: <511AFA0A.2090504@oracle.com> <511DECFA.9090406@oracle.com> <511EDC9C.1000208@oracle.com> <5121677B.8010402@oracle.com> <512BCBE2.4060802@oracle.com> Message-ID: <512C4709.4020809@oracle.com> Good to go - thanks Mikael. Perhaps make a mention in bug report about the dead code removal for print_frame_layout. (Did -Wunused find that ?? :) ) David On 26/02/2013 6:38 AM, Mikael Vidstedt wrote: > > On 2013-02-17 15:27, David Holmes wrote: >> On 16/02/2013 11:10 AM, Mikael Vidstedt wrote: >>> >>> On 2/15/2013 12:08 AM, David Holmes wrote: >>>> On 13/02/2013 12:27 PM, Mikael Vidstedt wrote: >>>>> Please review the following change: >>>>> >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8008081/webrev.00/webrev >>>>> >>>>> Background: >>>>> >>>>> I found a few occurrences of calls to print type functions where the >>>>> arguments do not match the format string. I hope that I have added the >>>>> right/intended arguments in the respective places but could use some >>>>> help to verify that that is indeed the case. >>>> >>>> In c1_FrameMap: >>>> >>>> 316 if( _num_monitors > 0) { >>>> 317 tty->print_cr("monitor [0]:%d | [%2d]:%d", >>>> 318 in_bytes(sp_offset_for_monitor_base(0)), >>>> 319 in_bytes(sp_offset_for_monitor_base(_num_monitors)), >>>> 320 _num_monitors); >>>> 321 } >>>> >>>> I think the last two args need swapping and should it be >>>> _num_monitors-1 ie the "index" ? And does that make >>>> sp_offset_for_monitor_base(_num_monitors) wrong ?? >>> >>> Agreed, they should indeed be swapped. Thanks Staffan/David for pointing >>> this out! >>> >>> Whether or not it should be _num_monitors-1 is indeed a good question. >>> The code below uses num_spills-1 and prints things slightly differently >>> if there is only one spill, so for symmetry reasons maybe this code >>> should do the same thing? I'm counting on a C1 expert to provide >>> guidance. >> >> Not a C1 expert but this: >> >> void check_monitor_index (int monitor_index) const { >> assert(monitor_index >= 0 && monitor_index < _num_monitors, "bad >> index"); } >> >> indicates that we shouldn't be using >> sp_offset_for_monitor_base(_num_monitors) > > I asked on hotspot-compiler-dev (now also cross posted) and the > conclusion is that the print_frame_layout function can be removed all > together. That makes the webrev look like this: > > http://cr.openjdk.java.net/~mikael/webrevs/8008081/webrev.02/webrev/ > > Only c1_FrameMap.cpp and c1_FrameMap.hpp have been changed (from > webrev.01). > > Good? > > Cheers, > Mikael > >> >> Cheers, >> David >> ----- >> >> >>> Meanwhile I've updated the webrev to add _num_monitors in the right >>> place: >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/8008081/webrev.01/webrev/ >>> >>>> Everything else seems reasonable - some obvious, some less so - but >>>> all 1000% better than before ;-) >>> >>> Wow, that sure is a lot of % :) >>> >>> Cheers, >>> Mikael >>> >>>> >>>> David >>>> ----- >>>> >>>> >>>>> One special case is in this webrev is jvmtiEnter.xls. Since it is used >>>>> to generate the jvmtiEnterTrace.cpp file and therefore is a bit less >>>>> obvious to review I have prepared a pair of before/after files for >>>>> your >>>>> convenience: >>>>> >>>>> Before: >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.orig >>>>> >>>>> >>>>> After: >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.fixed >>>>> >>>>> >>>>> >>>>> >>>>> I also prepared a diff -u of before vs after: >>>>> >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.diff >>>>> >>>>> >>>>> >>>>> Passes JPRT. >>>>> >>>>> Cheers, >>>>> Mikael >>> > From david.holmes at oracle.com Mon Feb 25 23:24:27 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Feb 2013 17:24:27 +1000 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> Message-ID: <512C632B.3070206@oracle.com> On 26/02/2013 4:42 AM, Christian Thalinger wrote: > On Feb 24, 2013, at 2:54 PM, David Holmes wrote: >> On 23/02/2013 1:55 PM, Christian Thalinger wrote: >>> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: >>> >>> http://cr.openjdk.java.net/~twisti/8006965/ >>> >>> This would be the first of three fixes: >>> >>> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets >> >> This logic is not suitable: >> >> 541 # Testing the built JVM >> 542 ifeq ($(JAVA_HOME),) >> 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >> 544 else >> 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >> 546 endif >> >> I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! > > That's not entirely correct. test_gamma uses your JAVA_HOME setting: This is so confusing. Our makefiles are an abomination! So this all started because the makefile has: JAVA_HOME=$(ABS_BOOTDIR) which was flagged as wrong because gamma would run in the boot JDK. But now it seems the make variable JAVA_HOME is irrelevant anyway because the test_gamma script will use the JAVA_HOME environment variable. So how did the boot JDK come back into this??? > cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 > cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma > Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre > > cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo > cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma > JAVA_HOME must point to a 64-bit OpenJDK. > > And here comes this little snippet into play: > > -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) > +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) > > Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is this BOOTDIR value being used? There is no use of it in http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it pre-existing ?? Thanks, David > I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. > >> >> I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? > > It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. > >> >> I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. > > It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. > > -- Chris > >> >> And this addition still makes no sense to me: >> >> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >> >> Why do you need to add BOOTDIR to the MAKE_ARGS? >> >> David >> >> >>> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 >>> >>> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} >>> >>> -- Chris >>> >>> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: >>> >>>> >>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>> >>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>> >>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>> >>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>> >>>> -- Chris >>>> >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>> >>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>> >>>>>> 8006965: test_gamma should run with import JDK >>>>>> Reviewed-by: >>>>>> >>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>> >>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>> running test_gamma. >>>>>> >>>>>> make/bsd/makefiles/buildtree.make >>>>>> make/defs.make >>>>>> make/linux/makefiles/buildtree.make >>>>>> make/solaris/makefiles/buildtree.make >>>>>> >>>>> >>>> >>> > From bengt.rutisson at oracle.com Mon Feb 25 23:34:37 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 26 Feb 2013 08:34:37 +0100 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <5A7AB3CC-FA3F-449A-88C8-E63474466442@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <51280FAF.3000009@oracle.com> <51281E2B.5010900@oracle.com> <512A91CF.8080109@oracle.com> <512B29C7.4030706@oracle.com> <5A7AB3CC-FA3F-449A-88C8-E63474466442@oracle.com> Message-ID: <512C658D.9020404@oracle.com> On 2/25/13 7:53 PM, Christian Thalinger wrote: > On Feb 25, 2013, at 1:07 AM, Bengt Rutisson wrote: > >> Hi all, >> >> I know I'm a bit late in the game here > Not too late; we're just getting started :-) Great! :) >> , but I get a bit worried about removing the gamma launcher. I admit that I don't know much about the launchers or how they are built. But if removing the gamma launcher means that I will have to start copying libjvms around I don't think this is acceptable. >> >> Please correct me if I am miss understanding something here. I am always using the hotspot script to execute my newly built hotspots. It is very convenient, and I don't want to have a situation where I have to copy the libjvm every time I want to run my builds. And I certainly don't want to build the whole JDK every time I build. > The hotspot script doesn't go away; I know that a lot of people use it. Mikael and I found a way to run the newly built libjvm without copying somewhere and without using gamma. You shouldn't notice any difference. That's good enough for me. Thanks! >> Also, have you looked in to how the Visual Studio projects are affected by this? Again I don't know the details, but debugging support on Windows is excellent and I don't want that to get more difficult if we remove the gamma launcher. Not sure if it is used by the Visual Studio projects though. > Honestly, I never did a manual build on Windows. If, as you say, debugging support is excellent on Windows than it certainly should be able to handle a shared libjvm library (that's what most people are concerned about: statically linked gamma vs. java launcher dlopen'ing libjvm). You are probably correct. If you want to I can try it out. Do you have a patch that removes gamma? In that case I can create a VS project and try some debugging. If that works and the hotspot script will keep working I'm fine with removing gamma. Thanks, Bengt > > -- Chris > >> Bengt >> >> On 2/24/13 11:18 PM, Coleen Phillimore wrote: >>> On 2/22/2013 8:40 PM, BILL PITTORE wrote: >>>> On 2/22/2013 7:39 PM, Coleen Phillimore wrote: >>>>> On 2/22/2013 6:21 PM, Christian Thalinger wrote: >>>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>>> >>>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>>>> >>>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>>> I use the hotspot script on linux to debug with -gdb, ie: >>>>> >>>>> hotspot -gdb >>>>> >>>>> It works really well! So the gamma launcher is really good for debugging without having to do odd things like ^C or PauseVMAtStartup to set breakpoints after libjvm.so is loaded. How else can you debug this? >>>> With recent versions of gdb I have no problem debugging using gdb on the java executable >>>> gdb --args ./bin/java -cp . HelloWorld >>>> GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04 >>>> ... >>>> (gdb) break ClassVerifier::verify_method >>>> Make breakpoint pending on future shared library load? (y or [n]) y >>>> >>>> Breakpoint 1 (ClassVerifier::verify_method) pending. >>>> (gdb) run >>>> ... >>>> >>>> Breakpoint 1, ClassVerifier::verify_method (this=0xf732ab60, m=0xf732ab08, >>>> __the_thread__=0xf7108000) >>>> at /export/users/bpittore/hotspot-emb/hotspot/src/share/vm/classfile/verifier.cpp:575 >>>> 575 HandleMark hm(THREAD); >>>> (gdb) >>>> >>> This works on the linux 32 and 64 bit machine we're using. But it only works on 32 bit if DEBUG_BINARIES=true is set while building (this creates binaries with dwarf2 rather than stabs, apparently dwarf takes more disk space so the build by default creates binaries with stabs). >>> >>> I don't think this works on solaris and I don't know about windows. Someone who debugs on windows should tell us how they debug without gamma. >>> >>> Coleen >>> >>>> bill >>>>> For testing, I copy the jvm into a jdk binary. >>>>> >>>>> Coleen >>>>>> -- Chris >>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>>> >>>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>>> >>>>>>>> 8006965: test_gamma should run with import JDK >>>>>>>> Reviewed-by: >>>>>>>> >>>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>>> >>>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>>> running test_gamma. >>>>>>>> >>>>>>>> make/bsd/makefiles/buildtree.make >>>>>>>> make/defs.make >>>>>>>> make/linux/makefiles/buildtree.make >>>>>>>> make/solaris/makefiles/buildtree.make >>>>>>>> From staffan.larsen at oracle.com Tue Feb 26 00:39:46 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 26 Feb 2013 09:39:46 +0100 Subject: =?iso-8859-1?Q?CFV=3A_New_HSX_Committer=3A_Markus_Gr=F6nlund?= Message-ID: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> I hereby nominate Markus Gr?nlund to HSX Committer. Markus has worked in the Serviceability team at Oracle for a few years now. He has been one of the key developers behind the Event-Based JVM Tracing work and has also contributed a number of bugfixes for Hotspot. http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=mgronlun http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=markus.gronlund Votes are due by 2013-03-12. Only current HSX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. For Lazy Consensus voting instructions, see [2]. Staffan Larsen [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From vladimir.x.ivanov at oracle.com Tue Feb 26 01:05:17 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 26 Feb 2013 13:05:17 +0400 Subject: CFV: New HSX Committer: Markus =?ISO-8859-1?Q?Gr=F6nlund?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: <512C7ACD.8090003@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 2/26/13 12:39 PM, Staffan Larsen wrote: > I hereby nominate Markus Gr?nlund to HSX Committer. > > Markus has worked in the Serviceability team at Oracle for a few years now. He has been one of the key developers behind the Event-Based JVM Tracing work and has also contributed a number of bugfixes for Hotspot. > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=mgronlun > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=markus.gronlund > > Votes are due by 2013-03-12. > > Only current HSX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Staffan Larsen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From rickard.backman at oracle.com Tue Feb 26 01:07:23 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Tue, 26 Feb 2013 10:07:23 +0100 Subject: =?iso-8859-1?Q?Re=3A_CFV=3A_New_HSX_Committer=3A_Markus_Gr=F6nlu?= =?iso-8859-1?Q?nd?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: <3054F2D4-9290-4C0C-A654-9A6ADD079259@oracle.com> Vote: yes /R On Feb 26, 2013, at 9:39 AM, Staffan Larsen wrote: > I hereby nominate Markus Gr?nlund to HSX Committer. > > Markus has worked in the Serviceability team at Oracle for a few years now. He has been one of the key developers behind the Event-Based JVM Tracing work and has also contributed a number of bugfixes for Hotspot. > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=mgronlun > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=markus.gronlund > > Votes are due by 2013-03-12. > > Only current HSX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Staffan Larsen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From volker.simonis at gmail.com Tue Feb 26 01:07:28 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 26 Feb 2013 10:07:28 +0100 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_HSX_Committer=3A_Markus_Gr=C3=B6nlund?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: Vote: yes Best regards, Volker Simonis On Tue, Feb 26, 2013 at 9:39 AM, Staffan Larsen wrote: > I hereby nominate Markus Gr?nlund to HSX Committer. > > Markus has worked in the Serviceability team at Oracle for a few years now. He has been one of the key developers behind the Event-Based JVM Tracing work and has also contributed a number of bugfixes for Hotspot. > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=mgronlun > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=markus.gronlund > > Votes are due by 2013-03-12. > > Only current HSX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Staffan Larsen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From nils.loodin at oracle.com Tue Feb 26 01:05:21 2013 From: nils.loodin at oracle.com (Nils Loodin) Date: Tue, 26 Feb 2013 10:05:21 +0100 Subject: CFV: New HSX Committer: Markus =?ISO-8859-1?Q?Gr=F6nlund?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: <512C7AD1.1090408@oracle.com> Vote: yes /Nils Loodin On 02/26/2013 09:39 AM, Staffan Larsen wrote: > I hereby nominate Markus Gr?nlund to HSX Committer. > > Markus has worked in the Serviceability team at Oracle for a few years now. He has been one of the key developers behind the Event-Based JVM Tracing work and has also contributed a number of bugfixes for Hotspot. > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=mgronlun > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=markus.gronlund > > Votes are due by 2013-03-12. > > Only current HSX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Staffan Larsen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From erik.helin at oracle.com Tue Feb 26 01:39:26 2013 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 26 Feb 2013 10:39:26 +0100 Subject: CFV: New HSX Committer: Markus =?ISO-8859-1?Q?Gr=F6nlund?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: <512C82CE.6080301@oracle.com> Vote: yes Best regards, Erik Helin On 02/26/2013 09:39 AM, Staffan Larsen wrote: > I hereby nominate Markus Gr?nlund to HSX Committer. > > Markus has worked in the Serviceability team at Oracle for a few years now. He has been one of the key developers behind the Event-Based JVM Tracing work and has also contributed a number of bugfixes for Hotspot. > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=mgronlun > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=markus.gronlund > > Votes are due by 2013-03-12. > > Only current HSX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Staffan Larsen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From stefan.karlsson at oracle.com Tue Feb 26 01:58:14 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 26 Feb 2013 10:58:14 +0100 Subject: CFV: New HSX Committer: Markus =?ISO-8859-1?Q?Gr=F6nlund?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: <512C8736.4030702@oracle.com> vote: yes StefanK On 02/26/2013 09:39 AM, Staffan Larsen wrote: > I hereby nominate Markus Gr?nlund to HSX Committer. > > Markus has worked in the Serviceability team at Oracle for a few years now. He has been one of the key developers behind the Event-Based JVM Tracing work and has also contributed a number of bugfixes for Hotspot. > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=mgronlun > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=markus.gronlund > > Votes are due by 2013-03-12. > > Only current HSX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Staffan Larsen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From christian.tornqvist at oracle.com Tue Feb 26 01:55:11 2013 From: christian.tornqvist at oracle.com (=?iso-8859-1?B?Q2hyaXN0aWFuIFT2cm5xdmlzdA==?=) Date: Tue, 26 Feb 2013 01:55:11 -0800 (PST) Subject: =?iso-8859-1?B?UkU6IENGVjogTmV3IEhTWCBDb21t?= =?iso-8859-1?B?aXR0ZXI6IE1hcmt1cyBHcvZubHVuZA==?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: <9797356c-c463-44a9-928e-33879b06c6cf@default> Vote: yes -----Original Message----- From: Staffan Larsen Sent: den 26 februari 2013 09:40 To: hotspot-dev at openjdk.java.net Developers Subject: CFV: New HSX Committer: Markus Gr?nlund I hereby nominate Markus Gr?nlund to HSX Committer. Markus has worked in the Serviceability team at Oracle for a few years now. He has been one of the key developers behind the Event-Based JVM Tracing work and has also contributed a number of bugfixes for Hotspot. http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=mgronlun http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=markus.gronlund Votes are due by 2013-03-12. Only current HSX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. For Lazy Consensus voting instructions, see [2]. Staffan Larsen [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From serguei.spitsyn at oracle.com Tue Feb 26 02:10:15 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Feb 2013 02:10:15 -0800 Subject: CFV: New HSX Committer: Markus =?ISO-8859-1?Q?Gr=F6nlund?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: <512C8A07.7090505@oracle.com> Vote: yes Thanks, Serguei On 2/26/13 12:39 AM, Staffan Larsen wrote: > I hereby nominate Markus Gr?nlund to HSX Committer. > > Markus has worked in the Serviceability team at Oracle for a few years now. He has been one of the key developers behind the Event-Based JVM Tracing work and has also contributed a number of bugfixes for Hotspot. > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=mgronlun > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=markus.gronlund > > Votes are due by 2013-03-12. > > Only current HSX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Staffan Larsen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From bengt.rutisson at oracle.com Tue Feb 26 02:49:13 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 26 Feb 2013 11:49:13 +0100 Subject: CFV: New HSX Committer: Markus =?ISO-8859-1?Q?Gr=F6nlund?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: <512C9329.8060908@oracle.com> Vote: yes Bengt On 2/26/13 9:39 AM, Staffan Larsen wrote: > I hereby nominate Markus Gr?nlund to HSX Committer. > > Markus has worked in the Serviceability team at Oracle for a few years now. He has been one of the key developers behind the Event-Based JVM Tracing work and has also contributed a number of bugfixes for Hotspot. > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=mgronlun > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=markus.gronlund > > Votes are due by 2013-03-12. > > Only current HSX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Staffan Larsen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From jesper.wilhelmsson at oracle.com Tue Feb 26 03:41:27 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 26 Feb 2013 12:41:27 +0100 Subject: CFV: New HSX Committer: Markus =?ISO-8859-1?Q?Gr=F6nlund?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: <512C9F67.3080802@oracle.com> Vote: yes /Jesper On 26/2/13 9:39 AM, Staffan Larsen wrote: > I hereby nominate Markus Gr?nlund to HSX Committer. > > Markus has worked in the Serviceability team at Oracle for a few years now. He has been one of the key developers behind the Event-Based JVM Tracing work and has also contributed a number of bugfixes for Hotspot. > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=mgronlun > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=markus.gronlund > > Votes are due by 2013-03-12. > > Only current HSX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Staffan Larsen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From daniel.daugherty at oracle.com Tue Feb 26 04:39:59 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 26 Feb 2013 05:39:59 -0700 Subject: CFV: New HSX Committer: Markus =?ISO-8859-1?Q?Gr=F6nlund?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: <512CAD1F.9080001@oracle.com> Vote: yes Dan On 2/26/13 1:39 AM, Staffan Larsen wrote: > I hereby nominate Markus Gr?nlund to HSX Committer. > > Markus has worked in the Serviceability team at Oracle for a few years now. He has been one of the key developers behind the Event-Based JVM Tracing work and has also contributed a number of bugfixes for Hotspot. > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=mgronlun > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=markus.gronlund > > Votes are due by 2013-03-12. > > Only current HSX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Staffan Larsen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From coleen.phillimore at oracle.com Tue Feb 26 05:07:37 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 26 Feb 2013 08:07:37 -0500 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <512C658D.9020404@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <51280FAF.3000009@oracle.com> <51281E2B.5010900@oracle.com> <512A91CF.8080109@oracle.com> <512B29C7.4030706@oracle.com> <5A7AB3CC-FA3F-449A-88C8-E63474466442@oracle.com> <512C658D.9020404@oracle.com> Message-ID: <512CB399.9080604@oracle.com> This thread is getting really long. Associated with this change, can someone update a wiki page somewhere with all this information. IE. How to run a test at the end of building so we don't install a broken libjvm.so into a jdk and how to set breakpoints in the platforms that we debug? I think these are the two main requirements here. Thanks! Coleen On 2/26/2013 2:34 AM, Bengt Rutisson wrote: > On 2/25/13 7:53 PM, Christian Thalinger wrote: >> On Feb 25, 2013, at 1:07 AM, Bengt Rutisson >> wrote: >> >>> Hi all, >>> >>> I know I'm a bit late in the game here >> Not too late; we're just getting started :-) > > Great! :) > > >>> , but I get a bit worried about removing the gamma launcher. I admit >>> that I don't know much about the launchers or how they are built. >>> But if removing the gamma launcher means that I will have to start >>> copying libjvms around I don't think this is acceptable. >>> >>> Please correct me if I am miss understanding something here. I am >>> always using the hotspot script to execute my newly built hotspots. >>> It is very convenient, and I don't want to have a situation where I >>> have to copy the libjvm every time I want to run my builds. And I >>> certainly don't want to build the whole JDK every time I build. >> The hotspot script doesn't go away; I know that a lot of people use >> it. Mikael and I found a way to run the newly built libjvm without >> copying somewhere and without using gamma. You shouldn't notice any >> difference. > > That's good enough for me. Thanks! > > >>> Also, have you looked in to how the Visual Studio projects are >>> affected by this? Again I don't know the details, but debugging >>> support on Windows is excellent and I don't want that to get more >>> difficult if we remove the gamma launcher. Not sure if it is used by >>> the Visual Studio projects though. >> Honestly, I never did a manual build on Windows. If, as you say, >> debugging support is excellent on Windows than it certainly should be >> able to handle a shared libjvm library (that's what most people are >> concerned about: statically linked gamma vs. java launcher dlopen'ing >> libjvm). > > You are probably correct. If you want to I can try it out. Do you have > a patch that removes gamma? In that case I can create a VS project and > try some debugging. If that works and the hotspot script will keep > working I'm fine with removing gamma. > > Thanks, > Bengt > >> >> -- Chris >> >>> Bengt >>> >>> On 2/24/13 11:18 PM, Coleen Phillimore wrote: >>>> On 2/22/2013 8:40 PM, BILL PITTORE wrote: >>>>> On 2/22/2013 7:39 PM, Coleen Phillimore wrote: >>>>>> On 2/22/2013 6:21 PM, Christian Thalinger wrote: >>>>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen >>>>>>> wrote: >>>>>>> >>>>>>>> I'm not sure what the correct solution is, but when you do find >>>>>>>> out, the jdkpath.sh target should also be updated. >>>>>>> How many are actually using the hotspot script? Would people be >>>>>>> very sentimental if we would remove the gamma launcher altogether? >>>>>>> >>>>>>> Taking to people here it seems that most are copying their >>>>>>> libjvm into a JDK and use java anyway. >>>>>> I use the hotspot script on linux to debug with -gdb, ie: >>>>>> >>>>>> hotspot -gdb >>>>>> >>>>>> It works really well! So the gamma launcher is really good for >>>>>> debugging without having to do odd things like ^C or >>>>>> PauseVMAtStartup to set breakpoints after libjvm.so is loaded. >>>>>> How else can you debug this? >>>>> With recent versions of gdb I have no problem debugging using gdb >>>>> on the java executable >>>>> gdb --args ./bin/java -cp . HelloWorld >>>>> GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04 >>>>> ... >>>>> (gdb) break ClassVerifier::verify_method >>>>> Make breakpoint pending on future shared library load? (y or [n]) y >>>>> >>>>> Breakpoint 1 (ClassVerifier::verify_method) pending. >>>>> (gdb) run >>>>> ... >>>>> >>>>> Breakpoint 1, ClassVerifier::verify_method (this=0xf732ab60, >>>>> m=0xf732ab08, >>>>> __the_thread__=0xf7108000) >>>>> at >>>>> /export/users/bpittore/hotspot-emb/hotspot/src/share/vm/classfile/verifier.cpp:575 >>>>> 575 HandleMark hm(THREAD); >>>>> (gdb) >>>>> >>>> This works on the linux 32 and 64 bit machine we're using. But it >>>> only works on 32 bit if DEBUG_BINARIES=true is set while building >>>> (this creates binaries with dwarf2 rather than stabs, apparently >>>> dwarf takes more disk space so the build by default creates >>>> binaries with stabs). >>>> >>>> I don't think this works on solaris and I don't know about >>>> windows. Someone who debugs on windows should tell us how they >>>> debug without gamma. >>>> >>>> Coleen >>>> >>>>> bill >>>>>> For testing, I copy the jvm into a jdk binary. >>>>>> >>>>>> Coleen >>>>>>> -- Chris >>>>>>> >>>>>>>> Thanks, >>>>>>>> /Staffan >>>>>>>> >>>>>>>> On 22 feb 2013, at 03:40, Christian Thalinger >>>>>>>> wrote: >>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>>>> >>>>>>>>> 8006965: test_gamma should run with import JDK >>>>>>>>> Reviewed-by: >>>>>>>>> >>>>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 >>>>>>>>> (where >>>>>>>>> JDK n is the version we are actually compiling for). This >>>>>>>>> setup is >>>>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>>>> >>>>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME >>>>>>>>> when >>>>>>>>> running test_gamma. >>>>>>>>> >>>>>>>>> make/bsd/makefiles/buildtree.make >>>>>>>>> make/defs.make >>>>>>>>> make/linux/makefiles/buildtree.make >>>>>>>>> make/solaris/makefiles/buildtree.make >>>>>>>>> > From coleen.phillimore at oracle.com Tue Feb 26 05:09:57 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 26 Feb 2013 08:09:57 -0500 Subject: CFV: New HSX Committer: Markus =?ISO-8859-1?Q?Gr=F6nlund?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: <512CB425.2060208@oracle.com> Vote: yes On 2/26/2013 3:39 AM, Staffan Larsen wrote: > I hereby nominate Markus Gr?nlund to HSX Committer. > > Markus has worked in the Serviceability team at Oracle for a few years now. He has been one of the key developers behind the Event-Based JVM Tracing work and has also contributed a number of bugfixes for Hotspot. > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=mgronlun > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=markus.gronlund > > Votes are due by 2013-03-12. > > Only current HSX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Staffan Larsen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From krystal.mo at oracle.com Tue Feb 26 06:05:29 2013 From: krystal.mo at oracle.com (Krystal Mo) Date: Tue, 26 Feb 2013 06:05:29 -0800 Subject: CFV: New HSX Committer: Markus =?ISO-8859-1?Q?Gr=F6nlund?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: <512CC129.9090106@oracle.com> Vote: yes - Kris On 2013/2/26 0:39, Staffan Larsen wrote: > I hereby nominate Markus Gr?nlund to HSX Committer. > > Markus has worked in the Serviceability team at Oracle for a few years now. He has been one of the key developers behind the Event-Based JVM Tracing work and has also contributed a number of bugfixes for Hotspot. > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=mgronlun > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=markus.gronlund > > Votes are due by 2013-03-12. > > Only current HSX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Staffan Larsen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From frederic.parain at oracle.com Tue Feb 26 06:23:57 2013 From: frederic.parain at oracle.com (frederic parain) Date: Tue, 26 Feb 2013 15:23:57 +0100 Subject: CFV: New HSX Committer: Markus =?ISO-8859-1?Q?Gr=F6nlund?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: <512CC57D.3070705@oracle.com> Vote: yes Fred On 26/02/2013 09:39, Staffan Larsen wrote: > I hereby nominate Markus Gr?nlund to HSX Committer. > > Markus has worked in the Serviceability team at Oracle for a few years now. He has been one of the key developers behind the Event-Based JVM Tracing work and has also contributed a number of bugfixes for Hotspot. > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=mgronlun > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=markus.gronlund > > Votes are due by 2013-03-12. > > Only current HSX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Staffan Larsen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From zhengyu.gu at oracle.com Tue Feb 26 06:27:21 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 26 Feb 2013 09:27:21 -0500 Subject: CFV: New HSX Committer: Markus =?ISO-8859-1?Q?Gr=F6nlund?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: <512CC649.1090302@oracle.com> Vote: yes -Zhengyu On 2/26/2013 3:39 AM, Staffan Larsen wrote: > I hereby nominate Markus Gr?nlund to HSX Committer. > > Markus has worked in the Serviceability team at Oracle for a few years now. He has been one of the key developers behind the Event-Based JVM Tracing work and has also contributed a number of bugfixes for Hotspot. > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=mgronlun > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=markus.gronlund > > Votes are due by 2013-03-12. > > Only current HSX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Staffan Larsen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From vladimir.kozlov at oracle.com Tue Feb 26 08:44:55 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Feb 2013 08:44:55 -0800 Subject: CFV: New HSX Committer: Markus =?ISO-8859-1?Q?Gr=F6nlund?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: <512CE687.80706@oracle.com> Vote: yes On 2/26/13 12:39 AM, Staffan Larsen wrote: > I hereby nominate Markus Gr?nlund to HSX Committer. > > Markus has worked in the Serviceability team at Oracle for a few years now. He has been one of the key developers behind the Event-Based JVM Tracing work and has also contributed a number of bugfixes for Hotspot. > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=mgronlun > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=markus.gronlund > > Votes are due by 2013-03-12. > > Only current HSX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Staffan Larsen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From joseph.provino at oracle.com Tue Feb 26 08:59:28 2013 From: joseph.provino at oracle.com (JOSEPH PROVINO) Date: Tue, 26 Feb 2013 11:59:28 -0500 Subject: Review request 8008310 - Some adjustments needed to, minimal VM warnings and errors for unsupported command line options In-Reply-To: <512C1349.1020706@oracle.com> References: <5127F2A0.7010506@oracle.com> <512B8A0A.9050301@oracle.com> <512C1349.1020706@oracle.com> Message-ID: <512CE9F0.6010901@oracle.com> On 2/25/2013 8:43 PM, David Holmes wrote: > On 26/02/2013 1:58 AM, JOSEPH PROVINO wrote: >> Latest webrev is here: >> http://cr.openjdk.java.net/~jprovino/8008310/webrev.02 >> >> - excluded filemap.cpp if CDS is 0. >> >> - confined changes for CDS to filemap.hpp. > > These changes are good - thanks. > > For arguments.cpp: > > 1076 FLAG_SET_DEFAULT(RequireSharedSpaces, false); > > If we execute this line then the flag is already false. > > Also, as discussed in email -Xshare:dump should probably be an error > not a warning, but note that if left as a warning then this code: > > 2518 // -Xshare:dump > 2519 } else if (match_option(option, "-Xshare:dump", &tail)) { > 2520 FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true); > 2521 set_mode_flags(_int); // Prevent compilation, which > creates objects > > would also force us into intepreter mode, so you would still need to > check INCLUDE_CDS here. If DumpSharedSpaces is changed to return JNI_ERR do I still need a conditional here? joe > > David > ----- > >> thanks. >> >> joe >> >> From aph at redhat.com Tue Feb 26 09:58:45 2013 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Feb 2013 17:58:45 +0000 Subject: Very poor performance of JNI AttachCurrentThread on Linux Message-ID: <512CF7D5.2030300@redhat.com> get_stack_bounds() was rewritten because of a small memory leak. Instead of simply free()ing the memory to prevent the leak, it was rewritten to use a byte-by-byte loop around read() : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-February/001864.html Unfortunately, the performance impact of this change is tragic. As you can imagine, tens of thousands of system calls are made whenever get_stack_bounds() is called. Before rewrite: typically 100 microseconds After rewrite: typically 1500 microseconds It's impossible for me to tell from the discussion on the mailing list why such a change was made. There is a rather elliptical comment > I'm strictly against reading /proc entry using stdio functions, > as (a) /proc file could be changed while we are reading it (b) it's not > fancy as we are buffering kmem. but this doesn't make any sense. If the contents of "/proc/self/maps" really did change while it was being read, reading a byte at a time wouldn't help at all. I don't know what the second sentence means. It would be possible to read "/proc/self/maps" in chunks and scan that, but my measurements show that it would not be significantly faster than the original version of get_stack_bounds(). This severe regression is impacting a current large Java deployment. See https://bugzilla.redhat.com/show_bug.cgi?id=902004 Is there any reason why I should not simply submit a webrev that reverts to the original code, with suitable use of free() ? I have attached the code that I am testing. Andrew. static bool get_stack_bounds(uintptr_t *bottom, uintptr_t *top) { FILE *f = fopen("/proc/self/maps", "r"); if (f == NULL) return false; char *str = NULL; while (!feof(f)) { size_t dummy; ssize_t len = getline(&str, &dummy, f); if (len == -1) { free(str); fclose(f); return false; } if (len > 0 && str[len-1] == '\n') { str[len-1] = 0; len--; } static const char *stack_str = "[stack]"; if (len > (ssize_t)strlen(stack_str) && (strcmp(str + len - strlen(stack_str), stack_str) == 0)) { if (sscanf(str, "%" SCNxPTR "-%" SCNxPTR, bottom, top) == 2) { uintptr_t sp = (uintptr_t)__builtin_frame_address(0); if (sp >= *bottom && sp <= *top) { free(str); fclose(f); return true; } } } } free(str); fclose(f); return false; } From mikael.vidstedt at oracle.com Tue Feb 26 11:15:06 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 26 Feb 2013 11:15:06 -0800 Subject: RFR (S): 8008081: Print outs do not have matching arguments In-Reply-To: <512C4709.4020809@oracle.com> References: <511AFA0A.2090504@oracle.com> <511DECFA.9090406@oracle.com> <511EDC9C.1000208@oracle.com> <5121677B.8010402@oracle.com> <512BCBE2.4060802@oracle.com> <512C4709.4020809@oracle.com> Message-ID: <512D09BA.50709@oracle.com> On 2/25/2013 9:24 PM, David Holmes wrote: > Good to go - thanks Mikael. > > Perhaps make a mention in bug report about the dead code removal for > print_frame_layout. (Did -Wunused find that ?? :) ) Thanks Staffan, David! I added a comment to the bug report regarding the dead function and I'll keep a background process going to see if there are things we can do to find more of them! Cheers, Mikael > > David > > On 26/02/2013 6:38 AM, Mikael Vidstedt wrote: >> >> On 2013-02-17 15:27, David Holmes wrote: >>> On 16/02/2013 11:10 AM, Mikael Vidstedt wrote: >>>> >>>> On 2/15/2013 12:08 AM, David Holmes wrote: >>>>> On 13/02/2013 12:27 PM, Mikael Vidstedt wrote: >>>>>> Please review the following change: >>>>>> >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8008081/webrev.00/webrev >>>>>> >>>>>> Background: >>>>>> >>>>>> I found a few occurrences of calls to print type functions where the >>>>>> arguments do not match the format string. I hope that I have >>>>>> added the >>>>>> right/intended arguments in the respective places but could use some >>>>>> help to verify that that is indeed the case. >>>>> >>>>> In c1_FrameMap: >>>>> >>>>> 316 if( _num_monitors > 0) { >>>>> 317 tty->print_cr("monitor [0]:%d | [%2d]:%d", >>>>> 318 in_bytes(sp_offset_for_monitor_base(0)), >>>>> 319 in_bytes(sp_offset_for_monitor_base(_num_monitors)), >>>>> 320 _num_monitors); >>>>> 321 } >>>>> >>>>> I think the last two args need swapping and should it be >>>>> _num_monitors-1 ie the "index" ? And does that make >>>>> sp_offset_for_monitor_base(_num_monitors) wrong ?? >>>> >>>> Agreed, they should indeed be swapped. Thanks Staffan/David for >>>> pointing >>>> this out! >>>> >>>> Whether or not it should be _num_monitors-1 is indeed a good question. >>>> The code below uses num_spills-1 and prints things slightly >>>> differently >>>> if there is only one spill, so for symmetry reasons maybe this code >>>> should do the same thing? I'm counting on a C1 expert to provide >>>> guidance. >>> >>> Not a C1 expert but this: >>> >>> void check_monitor_index (int monitor_index) const { >>> assert(monitor_index >= 0 && monitor_index < _num_monitors, "bad >>> index"); } >>> >>> indicates that we shouldn't be using >>> sp_offset_for_monitor_base(_num_monitors) >> >> I asked on hotspot-compiler-dev (now also cross posted) and the >> conclusion is that the print_frame_layout function can be removed all >> together. That makes the webrev look like this: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8008081/webrev.02/webrev/ >> >> Only c1_FrameMap.cpp and c1_FrameMap.hpp have been changed (from >> webrev.01). >> >> Good? >> >> Cheers, >> Mikael >> >>> >>> Cheers, >>> David >>> ----- >>> >>> >>>> Meanwhile I've updated the webrev to add _num_monitors in the right >>>> place: >>>> >>>> http://cr.openjdk.java.net/~mikael/webrevs/8008081/webrev.01/webrev/ >>>> >>>>> Everything else seems reasonable - some obvious, some less so - but >>>>> all 1000% better than before ;-) >>>> >>>> Wow, that sure is a lot of % :) >>>> >>>> Cheers, >>>> Mikael >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> One special case is in this webrev is jvmtiEnter.xls. Since it is >>>>>> used >>>>>> to generate the jvmtiEnterTrace.cpp file and therefore is a bit less >>>>>> obvious to review I have prepared a pair of before/after files for >>>>>> your >>>>>> convenience: >>>>>> >>>>>> Before: >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.orig >>>>>> >>>>>> >>>>>> >>>>>> After: >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.fixed >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I also prepared a diff -u of before vs after: >>>>>> >>>>>> http://cr.openjdk.java.net/~mikael/webrevs/8008081/jvmtiEnterTrace.cpp.diff >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Passes JPRT. >>>>>> >>>>>> Cheers, >>>>>> Mikael >>>> >> From vladimir.kozlov at oracle.com Tue Feb 26 12:02:16 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Feb 2013 12:02:16 -0800 Subject: Result: New HSX Committer: Bharadwaj Yadavalli In-Reply-To: <51253886.4060705@oracle.com> References: <51253886.4060705@oracle.com> Message-ID: <512D14C8.7020701@oracle.com> Voting for Bharadwaj Yadavalli [1] is now closed. Yes: 14 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus [2], this is sufficient to approve the nomination. Vladimir Kozlov [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-February/008276.html [2] http://openjdk.java.net/bylaws#lazy-consensus From dmitry.samersoff at oracle.com Tue Feb 26 12:38:44 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 27 Feb 2013 00:38:44 +0400 Subject: Very poor performance of JNI AttachCurrentThread on Linux In-Reply-To: <512CF7D5.2030300@redhat.com> References: <512CF7D5.2030300@redhat.com> Message-ID: <512D1D54.7050004@oracle.com> Andrew, I'm repeating the answer I sent to Stephan Bergmann few days below, is it the same issue with Libre Office? -------- Original Message -------- Subject: Re: get_stack_bounds using read(2) syscalls to read /proc/self/maps byte-by-byte Date: Thu, 21 Feb 2013 19:05:13 +0400 From: Dmitry Samersoff To: Stephan Bergmann CC: hotspot-dev at openjdk.java.net Stephan, There was some reasons for me to go off getline: 1. Behaviour of getline is not properly documented so it's not clean for me whether we should clean the buffer on all platforms for all version of libc in case of getline error. see http://sourceware.org/bugzilla/show_bug.cgi?id=5666 2. The fix reduces number of heap memory allocations/deallocations within VM. Huge java app with long paths to DSO could have huge map file, getline version read it entirely, but we are interesting in first 128 bytes of each line only. 3. Kernel doesn't report size of /proc files and doesn't notify process on /proc/* files changes (see e.g. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/454722) So buffered reading of /proc/* files could lead to subtle errors or crashes if file is changed during read e.g. after suspend/resume. It might be possible to reduce number of read syscalls by implementing some internal bufferisation but I definitely would prefer not to return getline. Is there a performance problems with other applications? -Dmitry On 2013-02-26 21:58, Andrew Haley wrote: > get_stack_bounds() was rewritten because of a small memory leak. > Instead of simply free()ing the memory to prevent the leak, it was > rewritten to use a byte-by-byte loop around read() : > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-February/001864.html > > Unfortunately, the performance impact of this change is tragic. As > you can imagine, tens of thousands of system calls are made whenever > get_stack_bounds() is called. > > Before rewrite: typically 100 microseconds > After rewrite: typically 1500 microseconds > > It's impossible for me to tell from the discussion on the mailing list > why such a change was made. There is a rather elliptical comment > >> I'm strictly against reading /proc entry using stdio functions, >> as (a) /proc file could be changed while we are reading it (b) it's not >> fancy as we are buffering kmem. > > but this doesn't make any sense. If the contents of "/proc/self/maps" > really did change while it was being read, reading a byte at a time > wouldn't help at all. I don't know what the second sentence means. > > It would be possible to read "/proc/self/maps" in chunks and scan that, > but my measurements show that it would not be significantly faster > than the original version of get_stack_bounds(). > > This severe regression is impacting a current large Java deployment. > See https://bugzilla.redhat.com/show_bug.cgi?id=902004 > > Is there any reason why I should not simply submit a webrev that reverts > to the original code, with suitable use of free() ? I have attached the > code that I am testing. > > Andrew. > > > > > static bool > get_stack_bounds(uintptr_t *bottom, uintptr_t *top) > { > FILE *f = fopen("/proc/self/maps", "r"); > if (f == NULL) > return false; > char *str = NULL; > while (!feof(f)) { > size_t dummy; > ssize_t len = getline(&str, &dummy, f); > if (len == -1) { > free(str); > fclose(f); > return false; > } > > if (len > 0 && str[len-1] == '\n') { > str[len-1] = 0; > len--; > } > > static const char *stack_str = "[stack]"; > if (len > (ssize_t)strlen(stack_str) > && (strcmp(str + len - strlen(stack_str), stack_str) == 0)) { > if (sscanf(str, "%" SCNxPTR "-%" SCNxPTR, bottom, top) == 2) { > uintptr_t sp = (uintptr_t)__builtin_frame_address(0); > if (sp >= *bottom && sp <= *top) { > free(str); > fclose(f); > return true; > } > } > } > } > free(str); > fclose(f); > return false; > } > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From dmitry.samersoff at oracle.com Tue Feb 26 13:38:59 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 27 Feb 2013 01:38:59 +0400 Subject: Very poor performance of JNI AttachCurrentThread on Linux In-Reply-To: <512CF7D5.2030300@redhat.com> References: <512CF7D5.2030300@redhat.com> Message-ID: <512D2B73.4060103@oracle.com> Andrew, Filed a bug JDK-8009062 -Dmitry On 2013-02-26 21:58, Andrew Haley wrote: > get_stack_bounds() was rewritten because of a small memory leak. > Instead of simply free()ing the memory to prevent the leak, it was > rewritten to use a byte-by-byte loop around read() : > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-February/001864.html > > Unfortunately, the performance impact of this change is tragic. As > you can imagine, tens of thousands of system calls are made whenever > get_stack_bounds() is called. > > Before rewrite: typically 100 microseconds > After rewrite: typically 1500 microseconds > > It's impossible for me to tell from the discussion on the mailing list > why such a change was made. There is a rather elliptical comment > >> I'm strictly against reading /proc entry using stdio functions, >> as (a) /proc file could be changed while we are reading it (b) it's not >> fancy as we are buffering kmem. > > but this doesn't make any sense. If the contents of "/proc/self/maps" > really did change while it was being read, reading a byte at a time > wouldn't help at all. I don't know what the second sentence means. > > It would be possible to read "/proc/self/maps" in chunks and scan that, > but my measurements show that it would not be significantly faster > than the original version of get_stack_bounds(). > > This severe regression is impacting a current large Java deployment. > See https://bugzilla.redhat.com/show_bug.cgi?id=902004 > > Is there any reason why I should not simply submit a webrev that reverts > to the original code, with suitable use of free() ? I have attached the > code that I am testing. > > Andrew. > > > > > static bool > get_stack_bounds(uintptr_t *bottom, uintptr_t *top) > { > FILE *f = fopen("/proc/self/maps", "r"); > if (f == NULL) > return false; > char *str = NULL; > while (!feof(f)) { > size_t dummy; > ssize_t len = getline(&str, &dummy, f); > if (len == -1) { > free(str); > fclose(f); > return false; > } > > if (len > 0 && str[len-1] == '\n') { > str[len-1] = 0; > len--; > } > > static const char *stack_str = "[stack]"; > if (len > (ssize_t)strlen(stack_str) > && (strcmp(str + len - strlen(stack_str), stack_str) == 0)) { > if (sscanf(str, "%" SCNxPTR "-%" SCNxPTR, bottom, top) == 2) { > uintptr_t sp = (uintptr_t)__builtin_frame_address(0); > if (sp >= *bottom && sp <= *top) { > free(str); > fclose(f); > return true; > } > } > } > } > free(str); > fclose(f); > return false; > } > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer From alejandro.murillo at oracle.com Tue Feb 26 14:30:11 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 26 Feb 2013 15:30:11 -0700 Subject: CFV: New HSX Committer: Markus =?ISO-8859-1?Q?Gr=F6nlund?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: <512D3773.3060004@oracle.com> vote: yes -- Alejandro From dean.long at oracle.com Tue Feb 26 15:28:42 2013 From: dean.long at oracle.com (Dean Long) Date: Tue, 26 Feb 2013 15:28:42 -0800 Subject: Very poor performance of JNI AttachCurrentThread on Linux In-Reply-To: <512CF7D5.2030300@redhat.com> References: <512CF7D5.2030300@redhat.com> Message-ID: <512D452A.2030801@oracle.com> This function should only get called in debug builds or for the initial thread, so I'm guessing the app has a custom launcher because, if I'm not mistaken, the default launcher creates a separate main thread to attach to the JVM while the initial thread waits. But even so, I don't think we need this function. We already captured the bounds of the initial thread in os::Linux::capture_initial_stack(), and the current range can be read using getrlimit(). However if we do decide to keep get_stack_bounds(), I don't see why it can't use stdio like find_vma(). dl On 2/26/2013 9:58 AM, Andrew Haley wrote: > get_stack_bounds() was rewritten because of a small memory leak. > Instead of simply free()ing the memory to prevent the leak, it was > rewritten to use a byte-by-byte loop around read() : > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-February/001864.html > > Unfortunately, the performance impact of this change is tragic. As > you can imagine, tens of thousands of system calls are made whenever > get_stack_bounds() is called. > > Before rewrite: typically 100 microseconds > After rewrite: typically 1500 microseconds > > It's impossible for me to tell from the discussion on the mailing list > why such a change was made. There is a rather elliptical comment > >> I'm strictly against reading /proc entry using stdio functions, >> as (a) /proc file could be changed while we are reading it (b) it's not >> fancy as we are buffering kmem. > but this doesn't make any sense. If the contents of "/proc/self/maps" > really did change while it was being read, reading a byte at a time > wouldn't help at all. I don't know what the second sentence means. > > It would be possible to read "/proc/self/maps" in chunks and scan that, > but my measurements show that it would not be significantly faster > than the original version of get_stack_bounds(). > > This severe regression is impacting a current large Java deployment. > See https://bugzilla.redhat.com/show_bug.cgi?id=902004 > > Is there any reason why I should not simply submit a webrev that reverts > to the original code, with suitable use of free() ? I have attached the > code that I am testing. > > Andrew. > > > > > static bool > get_stack_bounds(uintptr_t *bottom, uintptr_t *top) > { > FILE *f = fopen("/proc/self/maps", "r"); > if (f == NULL) > return false; > char *str = NULL; > while (!feof(f)) { > size_t dummy; > ssize_t len = getline(&str, &dummy, f); > if (len == -1) { > free(str); > fclose(f); > return false; > } > > if (len > 0 && str[len-1] == '\n') { > str[len-1] = 0; > len--; > } > > static const char *stack_str = "[stack]"; > if (len > (ssize_t)strlen(stack_str) > && (strcmp(str + len - strlen(stack_str), stack_str) == 0)) { > if (sscanf(str, "%" SCNxPTR "-%" SCNxPTR, bottom, top) == 2) { > uintptr_t sp = (uintptr_t)__builtin_frame_address(0); > if (sp >= *bottom && sp <= *top) { > free(str); > fclose(f); > return true; > } > } > } > } > free(str); > fclose(f); > return false; > } > > From david.holmes at oracle.com Tue Feb 26 17:31:35 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Feb 2013 11:31:35 +1000 Subject: CFV: New HSX Committer: Markus =?ISO-8859-1?Q?Gr=F6nlund?= In-Reply-To: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> References: <1CDA95EC-CB25-4F3A-A27B-734EEC7C3491@oracle.com> Message-ID: <512D61F7.6080505@oracle.com> Vote: yes David On 26/02/2013 6:39 PM, Staffan Larsen wrote: > I hereby nominate Markus Gr?nlund to HSX Committer. > > Markus has worked in the Serviceability team at Oracle for a few years now. He has been one of the key developers behind the Event-Based JVM Tracing work and has also contributed a number of bugfixes for Hotspot. > > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=mgronlun > http://hg.openjdk.java.net/hsx/hsx24/hotspot/log?rev=markus.gronlund > > Votes are due by 2013-03-12. > > Only current HSX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Staffan Larsen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From david.holmes at oracle.com Tue Feb 26 17:45:45 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Feb 2013 11:45:45 +1000 Subject: Review request 8008310 - Some adjustments needed to, minimal VM warnings and errors for unsupported command line options In-Reply-To: <512CE9F0.6010901@oracle.com> References: <5127F2A0.7010506@oracle.com> <512B8A0A.9050301@oracle.com> <512C1349.1020706@oracle.com> <512CE9F0.6010901@oracle.com> Message-ID: <512D6549.2080406@oracle.com> On 27/02/2013 2:59 AM, JOSEPH PROVINO wrote: > > On 2/25/2013 8:43 PM, David Holmes wrote: >> On 26/02/2013 1:58 AM, JOSEPH PROVINO wrote: >>> Latest webrev is here: >>> http://cr.openjdk.java.net/~jprovino/8008310/webrev.02 >>> >>> - excluded filemap.cpp if CDS is 0. >>> >>> - confined changes for CDS to filemap.hpp. >> >> These changes are good - thanks. >> >> For arguments.cpp: >> >> 1076 FLAG_SET_DEFAULT(RequireSharedSpaces, false); >> >> If we execute this line then the flag is already false. >> >> Also, as discussed in email -Xshare:dump should probably be an error >> not a warning, but note that if left as a warning then this code: >> >> 2518 // -Xshare:dump >> 2519 } else if (match_option(option, "-Xshare:dump", &tail)) { >> 2520 FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true); >> 2521 set_mode_flags(_int); // Prevent compilation, which >> creates objects >> >> would also force us into intepreter mode, so you would still need to >> check INCLUDE_CDS here. > > If DumpSharedSpaces is changed to return JNI_ERR do I still need a > conditional here? ?? You would need the conditional to decide to return JNI_ERR. David > joe > >> >> David >> ----- >> >>> thanks. >>> >>> joe >>> >>> > From christian.thalinger at oracle.com Tue Feb 26 18:09:10 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 26 Feb 2013 18:09:10 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: <512C632B.3070206@oracle.com> References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> <512C632B.3070206@oracle.com> Message-ID: On Feb 25, 2013, at 11:24 PM, David Holmes wrote: > On 26/02/2013 4:42 AM, Christian Thalinger wrote: >> On Feb 24, 2013, at 2:54 PM, David Holmes wrote: >>> On 23/02/2013 1:55 PM, Christian Thalinger wrote: >>>> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: >>>> >>>> http://cr.openjdk.java.net/~twisti/8006965/ >>>> >>>> This would be the first of three fixes: >>>> >>>> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets >>> >>> This logic is not suitable: >>> >>> 541 # Testing the built JVM >>> 542 ifeq ($(JAVA_HOME),) >>> 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>> 544 else >>> 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>> 546 endif >>> >>> I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! >> >> That's not entirely correct. test_gamma uses your JAVA_HOME setting: > > This is so confusing. Our makefiles are an abomination! I couldn't agree more. > > So this all started because the makefile has: > > JAVA_HOME=$(ABS_BOOTDIR) > > which was flagged as wrong because gamma would run in the boot JDK. But now it seems the make variable JAVA_HOME is irrelevant anyway because the test_gamma script will use the JAVA_HOME environment variable. > > So how did the boot JDK come back into this??? > >> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 >> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre >> >> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo >> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >> JAVA_HOME must point to a 64-bit OpenJDK. >> >> And here comes this little snippet into play: >> >> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) >> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >> >> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. > > I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is this BOOTDIR value being used? There is no use of it in http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it pre-existing ?? I talked to John Coomes about that yesterday and we can remove that line. ABS_BOOTDIR is only used by Windows. -- Chris > > Thanks, > David > >> I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. >> >>> >>> I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? >> >> It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. >> >>> >>> I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. >> >> It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. >> >> -- Chris >> >>> >>> And this addition still makes no sense to me: >>> >>> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>> >>> Why do you need to add BOOTDIR to the MAKE_ARGS? >>> >>> David >>> >>> >>>> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 >>>> >>>> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} >>>> >>>> -- Chris >>>> >>>> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: >>>> >>>>> >>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>> >>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>> >>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>>> >>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>>> >>>>> -- Chris >>>>> >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>> >>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>> >>>>>>> 8006965: test_gamma should run with import JDK >>>>>>> Reviewed-by: >>>>>>> >>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>> >>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>> running test_gamma. >>>>>>> >>>>>>> make/bsd/makefiles/buildtree.make >>>>>>> make/defs.make >>>>>>> make/linux/makefiles/buildtree.make >>>>>>> make/solaris/makefiles/buildtree.make >>>>>>> >>>>>> >>>>> >>>> >> From christian.tornqvist at oracle.com Tue Feb 26 23:45:22 2013 From: christian.tornqvist at oracle.com (=?utf-8?B?Q2hyaXN0aWFuIFTDtnJucXZpc3Q=?=) Date: Tue, 26 Feb 2013 23:45:22 -0800 (PST) Subject: Does UseLargePages option work on Windows? In-Reply-To: <5125268D.3080105@oracle.com> References: <5125268D.3080105@oracle.com> Message-ID: Hi Zhengyu, I got it to work (on my Windows 8 machine), granted myself the "Lock pages in memory" right and rebooted the machine. Then I had to start my java process from an administrative command prompt to get it to work, otherwise it would give me the privilege error. I managed to reproduce your NMT assert using this. If you don't get it to work, please ping me and I'll give you access to my machine. Thanks, Christian -----Original Message----- From: Zhengyu Gu Sent: den 20 februari 2013 20:40 To: hotspot-dev at openjdk.java.net Subject: Does UseLargePages option work on Windows? Hi, I am trying to experiment UseLargePages option (-XX:+UseLargePages) with NMT, but I have trouble to get large page to work on Windows (mine is Windows 7). I followed instruction to grant myself the permission to lock pages in memory (http://msdn.microsoft.com/en-us/library/ms190730.aspx), but I am still getting following warning message: Java HotSpot(TM) Server VM warning: JVM cannot use large page memory because it does not have enough privilege to lock pages in memory. Test jobs from JPRT also show large pages are not enabled. Java HotSpot(TM) Client VM warning: Large page is not supported by the operating system. Java HotSpot(TM) Server VM warning: Large page is not supported by the operating system. Could you please comment what I did wrong? Thanks, -Zhengyu From sbergman at redhat.com Wed Feb 27 02:01:37 2013 From: sbergman at redhat.com (Stephan Bergmann) Date: Wed, 27 Feb 2013 11:01:37 +0100 Subject: Very poor performance of JNI AttachCurrentThread on Linux In-Reply-To: <512D452A.2030801@oracle.com> References: <512CF7D5.2030300@redhat.com> <512D452A.2030801@oracle.com> Message-ID: <512DD981.1090201@redhat.com> On 02/27/2013 12:28 AM, Dean Long wrote: > This function should only get called in debug builds or for the initial > thread, so I'm guessing > the app has a custom launcher because, if I'm not mistaken, the default > launcher creates > a separate main thread to attach to the JVM while the initial thread waits. The app in question is LibreOffice, which has an extension mechanism (UNO) that allows for extensions in various programming languages, among them Java. For that, it instantiates a JVM in-process and makes JNI calls. Due to the fundamental design of LibreOffice and its extension mechanism, it is not practically possible in the general case to either prevent such JNI calls from being made on the main thread, nor to establish large scopes in which a thread will make JNI calls, to restrict Attach/DetachCurrentThread calls to the boundaries of such larger scopes. Therefore, LibreOffice can unfortunately end up making rather frequent calls to Attach/DetachCurrentThread from the main thread. Stephan From aph at redhat.com Wed Feb 27 02:19:24 2013 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Feb 2013 10:19:24 +0000 Subject: Very poor performance of JNI AttachCurrentThread on Linux In-Reply-To: <512D1D54.7050004@oracle.com> References: <512CF7D5.2030300@redhat.com> <512D1D54.7050004@oracle.com> Message-ID: <512DDDAC.7080803@redhat.com> On 02/26/2013 08:38 PM, Dmitry Samersoff wrote: > Andrew, > > I'm repeating the answer I sent to Stephan Bergmann few days below, > is it the same issue with Libre Office? > > There was some reasons for me to go off getline: > > 1. Behaviour of getline is not properly documented so it's not clean for > me whether we should clean the buffer on all platforms for all version > of libc in case of getline error. > > see http://sourceware.org/bugzilla/show_bug.cgi?id=5666 It's clear now, as can be seen from that bug. > 2. The fix reduces number of heap memory allocations/deallocations > within VM. > > Huge java app with long paths to DSO could have huge map file, getline > version read it entirely, but we are interesting in first > 128 bytes of each line only. I don't understand this. Only reading the first 128 bytes makes sense if you're trying to improve performance, but the performance is very poor. > 3. Kernel doesn't report size of /proc files and doesn't notify process > on /proc/* files changes > (see e.g. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/454722) Yes. How is this relevant? Do you think that getline() might actually rely on the reported size of a file or on notification? > So buffered reading of /proc/* files could lead to subtle errors or > crashes if file is changed during read e.g. after suspend/resume. > > It might be possible to reduce number of read syscalls by implementing > some internal bufferisation but I definitely would prefer not to return > getline. OK. I don't really mind how this gets fixed; I will go along with any buffering strategy that brings the performance back to where it was before. > Is there a performance problems with other applications? Other than what? Every usage of JNI AttachCurrentThread is severely impacted. Andrew. From david.holmes at oracle.com Wed Feb 27 05:06:56 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Feb 2013 23:06:56 +1000 Subject: Very poor performance of JNI AttachCurrentThread on Linux In-Reply-To: <512DDDAC.7080803@redhat.com> References: <512CF7D5.2030300@redhat.com> <512D1D54.7050004@oracle.com> <512DDDAC.7080803@redhat.com> Message-ID: <512E04F0.10106@oracle.com> On 27/02/2013 8:19 PM, Andrew Haley wrote: > On 02/26/2013 08:38 PM, Dmitry Samersoff wrote: >> Is there a performance problems with other applications? > > Other than what? Every usage of JNI AttachCurrentThread is severely > impacted. In a debug build this affects all threads. Otherwise it only affects the main thread - or should. Are you seeing something different? The "other application" is LibreOffice where the main thread keeps attaching and detaching. David From aph at redhat.com Wed Feb 27 05:41:16 2013 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Feb 2013 13:41:16 +0000 Subject: Very poor performance of JNI AttachCurrentThread on Linux In-Reply-To: <512E04F0.10106@oracle.com> References: <512CF7D5.2030300@redhat.com> <512D1D54.7050004@oracle.com> <512DDDAC.7080803@redhat.com> <512E04F0.10106@oracle.com> Message-ID: <512E0CFC.9020507@redhat.com> On 02/27/2013 01:06 PM, David Holmes wrote: > On 27/02/2013 8:19 PM, Andrew Haley wrote: >> On 02/26/2013 08:38 PM, Dmitry Samersoff wrote: >>> Is there a performance problems with other applications? >> >> Other than what? Every usage of JNI AttachCurrentThread is severely >> impacted. > > In a debug build this affects all threads. Otherwise it only affects the > main thread - or should. Are you seeing something different? The "other > application" is LibreOffice where the main thread keeps attaching and > detaching. Right, that's the one. But I don't understand what the question is for -- we have found that JNI AttachCurrentThread is very slow when the main thread is involved. I don't see what the application in question has to do with anything: this happens to every application that calls AttachCurrentThread from the main thread. Andrew. From joseph.provino at oracle.com Wed Feb 27 09:41:04 2013 From: joseph.provino at oracle.com (JOSEPH PROVINO) Date: Wed, 27 Feb 2013 12:41:04 -0500 Subject: Review request 8008310 - Some adjustments needed to, minimal VM warnings and errors for unsupported command line options In-Reply-To: <512D6549.2080406@oracle.com> References: <5127F2A0.7010506@oracle.com> <512B8A0A.9050301@oracle.com> <512C1349.1020706@oracle.com> <512CE9F0.6010901@oracle.com> <512D6549.2080406@oracle.com> Message-ID: <512E4530.6010204@oracle.com> On 2/26/2013 8:45 PM, David Holmes wrote: > On 27/02/2013 2:59 AM, JOSEPH PROVINO wrote: >> >> On 2/25/2013 8:43 PM, David Holmes wrote: >>> On 26/02/2013 1:58 AM, JOSEPH PROVINO wrote: >>>> Latest webrev is here: >>>> http://cr.openjdk.java.net/~jprovino/8008310/webrev.02 >>>> >>>> - excluded filemap.cpp if CDS is 0. >>>> >>>> - confined changes for CDS to filemap.hpp. >>> >>> These changes are good - thanks. >>> >>> For arguments.cpp: >>> >>> 1076 FLAG_SET_DEFAULT(RequireSharedSpaces, false); >>> >>> If we execute this line then the flag is already false. >>> >>> Also, as discussed in email -Xshare:dump should probably be an error >>> not a warning, but note that if left as a warning then this code: >>> >>> 2518 // -Xshare:dump >>> 2519 } else if (match_option(option, "-Xshare:dump", &tail)) { >>> 2520 FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true); >>> 2521 set_mode_flags(_int); // Prevent compilation, which >>> creates objects >>> >>> would also force us into intepreter mode, so you would still need to >>> check INCLUDE_CDS here. >> >> If DumpSharedSpaces is changed to return JNI_ERR do I still need a >> conditional here? > > ?? You would need the conditional to decide to return JNI_ERR. I meant do I need #if INCLUDE_CDS around set_mode_flags(_int); joe > > David > >> joe >> >>> >>> David >>> ----- >>> >>>> thanks. >>>> >>>> joe >>>> >>>> >> From vladimir.kozlov at oracle.com Wed Feb 27 10:38:09 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Feb 2013 10:38:09 -0800 Subject: Result: New HSX Committer: Morris Meyer In-Reply-To: <512D14C8.7020701@oracle.com> References: <512D14C8.7020701@oracle.com> Message-ID: <512E5291.1060804@oracle.com> Voting for Morris Meyer [1] is now closed. Yes: 11 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus [2], this is sufficient to approve the nomination. Vladimir Kozlov [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-February/008430.html [2] http://openjdk.java.net/bylaws#lazy-consensus From serguei.spitsyn at oracle.com Wed Feb 27 17:03:55 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 28 Feb 2013 01:03:55 +0000 Subject: hg: hsx/hotspot-main/hotspot: 10 new changesets Message-ID: <20130228010417.C7A6847493@hg.openjdk.java.net> Changeset: 1b0dc9f87e75 Author: mgerdin Date: 2013-02-19 18:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1b0dc9f87e75 8006753: fix failed for JDK-8002415 White box testing API for HotSpot Summary: Modify WhiteBoxAPI to use interface classes from test/testlibrary instead, add ClassFileInstaller to resolve the boot class path issue Reviewed-by: ctornqvi, dsamersoff, coleenp, kvn ! make/Makefile ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/vm.make - make/bsd/makefiles/wb.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/vm.make - make/linux/makefiles/wb.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/vm.make - make/solaris/makefiles/wb.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java ! src/share/vm/runtime/arguments.cpp ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java ! test/compiler/whitebox/SetDontInlineMethodTest.java ! test/runtime/NMT/AllocTestType.java ! test/runtime/NMT/PrintNMTStatistics.java ! test/runtime/NMT/SummarySanityCheck.java ! test/sanity/WBApi.java ! test/serviceability/ParserTest.java + test/testlibrary/ClassFileInstaller.java + test/testlibrary/whitebox/sun/hotspot/WhiteBox.java + test/testlibrary/whitebox/sun/hotspot/parser/DiagnosticCommand.java Changeset: 4c1d8002ffb1 Author: hseigel Date: 2013-02-20 07:16 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4c1d8002ffb1 8004495: [parfait] False positive Buffer overflow in hotspot/src/os/linux/vm/os_linux.cpp Summary: Delete the questionable source code because it is for no-longer supported versions of Linux. Reviewed-by: mikael, coleenp ! src/os/linux/vm/os_linux.cpp Changeset: b861c8af2510 Author: hseigel Date: 2013-02-20 07:42 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b861c8af2510 Merge - make/bsd/makefiles/wb.make - make/linux/makefiles/wb.make - make/solaris/makefiles/wb.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java Changeset: b6d5b3e50379 Author: dcubed Date: 2013-02-20 19:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b6d5b3e50379 6799919: Recursive calls to report_vm_out_of_memory are handled incorrectly Summary: report_vm_out_of_memory() should allow VMError.report_and_die() to handle multiple out of native memory errors. Reviewed-by: dcubed, dholmes, coleenp, acorn Contributed-by: ron.durbin at oracle.com ! src/share/vm/utilities/debug.cpp Changeset: fc64254f5579 Author: zgu Date: 2013-02-21 07:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fc64254f5579 8008071: Crashed in promote_malloc_records() with Kitchensink after 19 days Summary: Added NULL pointer check for arena size record Reviewed-by: sspitsyn, dholmes ! src/share/vm/services/memSnapshot.cpp Changeset: 5ed317b25e23 Author: sla Date: 2013-02-22 10:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5ed317b25e23 7165259: Remove BugSpot Reviewed-by: coleenp, mgronlun ! agent/make/Makefile - agent/make/bugspot.bat ! agent/make/marks_notes.html ! agent/src/os/win32/windbg/sawindbg.cpp - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.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/Tool.java ! agent/src/share/classes/sun/jvm/hotspot/ui/SAPanel.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js - agent/src/share/native/jvmdi/sa.cpp - agent/src/share/native/jvmdi/sa.dsp - agent/src/share/native/jvmdi/sa.dsw - agent/src/share/native/jvmdi/sa.hpp ! make/sa.files Changeset: f16e75e0cf11 Author: coleenp Date: 2013-02-22 08:36 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f16e75e0cf11 8000797: NPG: is_pseudo_string_at() doesn't work Summary: Zero Symbol* for constant pool strings to indicate pseudo_strings (objects that aren't strings). Clean up JVM_CONSTANT_Object and unused flags. Reviewed-by: sspitsyn, jrose ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: 94478a033036 Author: sspitsyn Date: 2013-02-22 10:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/94478a033036 Merge - agent/make/bugspot.bat - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java - agent/src/share/native/jvmdi/sa.cpp - agent/src/share/native/jvmdi/sa.dsp - agent/src/share/native/jvmdi/sa.dsw - agent/src/share/native/jvmdi/sa.hpp - make/bsd/makefiles/wb.make - make/linux/makefiles/wb.make - make/solaris/makefiles/wb.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java ! src/share/vm/runtime/arguments.cpp Changeset: ec2eddfed950 Author: rbackman Date: 2013-02-26 14:09 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ec2eddfed950 8008340: [sampling] assert(upper->pc_offset() >= pc_offset) failed: sanity Reviewed-by: kvn, sla ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp Changeset: 77f9b6d0126e Author: sspitsyn Date: 2013-02-27 12:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/77f9b6d0126e Merge - agent/make/bugspot.bat - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java - agent/src/share/native/jvmdi/sa.cpp - agent/src/share/native/jvmdi/sa.dsp - agent/src/share/native/jvmdi/sa.dsw - agent/src/share/native/jvmdi/sa.hpp - make/bsd/makefiles/wb.make - make/linux/makefiles/wb.make - make/solaris/makefiles/wb.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java From david.holmes at oracle.com Wed Feb 27 20:18:38 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Feb 2013 14:18:38 +1000 Subject: Very poor performance of JNI AttachCurrentThread on Linux In-Reply-To: <512E0CFC.9020507@redhat.com> References: <512CF7D5.2030300@redhat.com> <512D1D54.7050004@oracle.com> <512DDDAC.7080803@redhat.com> <512E04F0.10106@oracle.com> <512E0CFC.9020507@redhat.com> Message-ID: <512EDA9E.7060708@oracle.com> On 27/02/2013 11:41 PM, Andrew Haley wrote: > On 02/27/2013 01:06 PM, David Holmes wrote: >> On 27/02/2013 8:19 PM, Andrew Haley wrote: >>> On 02/26/2013 08:38 PM, Dmitry Samersoff wrote: >>>> Is there a performance problems with other applications? >>> >>> Other than what? Every usage of JNI AttachCurrentThread is severely >>> impacted. >> >> In a debug build this affects all threads. Otherwise it only affects the >> main thread - or should. Are you seeing something different? The "other >> application" is LibreOffice where the main thread keeps attaching and >> detaching. > > Right, that's the one. But I don't understand what the question is for -- > we have found that JNI AttachCurrentThread is very slow when the main > thread is involved. I don't see what the application in question has > to do with anything: this happens to every application that calls > AttachCurrentThread from the main thread. Sure but the vast majority of applications only do that once, so it isn't an issue for them. Anyway this is on Dmitry's to-do list. David ----- > Andrew. > From david.holmes at oracle.com Wed Feb 27 20:36:47 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Feb 2013 14:36:47 +1000 Subject: Review request 8008310 - Some adjustments needed to, minimal VM warnings and errors for unsupported command line options In-Reply-To: <512E4530.6010204@oracle.com> References: <5127F2A0.7010506@oracle.com> <512B8A0A.9050301@oracle.com> <512C1349.1020706@oracle.com> <512CE9F0.6010901@oracle.com> <512D6549.2080406@oracle.com> <512E4530.6010204@oracle.com> Message-ID: <512EDEDF.2080900@oracle.com> On 28/02/2013 3:41 AM, JOSEPH PROVINO wrote: > > On 2/26/2013 8:45 PM, David Holmes wrote: >> On 27/02/2013 2:59 AM, JOSEPH PROVINO wrote: >>> >>> On 2/25/2013 8:43 PM, David Holmes wrote: >>>> On 26/02/2013 1:58 AM, JOSEPH PROVINO wrote: >>>>> Latest webrev is here: >>>>> http://cr.openjdk.java.net/~jprovino/8008310/webrev.02 >>>>> >>>>> - excluded filemap.cpp if CDS is 0. >>>>> >>>>> - confined changes for CDS to filemap.hpp. >>>> >>>> These changes are good - thanks. >>>> >>>> For arguments.cpp: >>>> >>>> 1076 FLAG_SET_DEFAULT(RequireSharedSpaces, false); >>>> >>>> If we execute this line then the flag is already false. >>>> >>>> Also, as discussed in email -Xshare:dump should probably be an error >>>> not a warning, but note that if left as a warning then this code: >>>> >>>> 2518 // -Xshare:dump >>>> 2519 } else if (match_option(option, "-Xshare:dump", &tail)) { >>>> 2520 FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true); >>>> 2521 set_mode_flags(_int); // Prevent compilation, which >>>> creates objects >>>> >>>> would also force us into intepreter mode, so you would still need to >>>> check INCLUDE_CDS here. >>> >>> If DumpSharedSpaces is changed to return JNI_ERR do I still need a >>> conditional here? >> >> ?? You would need the conditional to decide to return JNI_ERR. > > I meant do I need #if INCLUDE_CDS around set_mode_flags(_int); So I was assuming this was the only place you needed to check this, but you have to check for -XX:+DumpSharedSpaces as well. So if you left the -Xshare:dump code alone and later checked for DumpSharedSpaces and returned with JNI_ERR then it would not matter that the switch to interpreter mode had already been made. David > joe > >> >> David >> >>> joe >>> >>>> >>>> David >>>> ----- >>>> >>>>> thanks. >>>>> >>>>> joe >>>>> >>>>> >>> > From rickard.backman at oracle.com Wed Feb 27 21:10:20 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Thu, 28 Feb 2013 05:10:20 +0000 Subject: hg: hsx/hsx24/hotspot: 8008340: [sampling] assert(upper->pc_offset() >= pc_offset) failed: sanity Message-ID: <20130228051024.BBE68474A4@hg.openjdk.java.net> Changeset: f38f66e78fb2 Author: rbackman Date: 2013-02-18 10:22 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f38f66e78fb2 8008340: [sampling] assert(upper->pc_offset() >= pc_offset) failed: sanity Reviewed-by: kvn, sla ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp From aph at redhat.com Thu Feb 28 01:22:53 2013 From: aph at redhat.com (Andrew Haley) Date: Thu, 28 Feb 2013 09:22:53 +0000 Subject: Very poor performance of JNI AttachCurrentThread on Linux In-Reply-To: <512EDA9E.7060708@oracle.com> References: <512CF7D5.2030300@redhat.com> <512D1D54.7050004@oracle.com> <512DDDAC.7080803@redhat.com> <512E04F0.10106@oracle.com> <512E0CFC.9020507@redhat.com> <512EDA9E.7060708@oracle.com> Message-ID: <512F21ED.6020507@redhat.com> On 02/28/2013 04:18 AM, David Holmes wrote: > Anyway this is on Dmitry's to-do list. Well, it's much more urgent for others. Does this mean that you will refuse a patch from anyone else that fixes his bug? Andrew. From david.holmes at oracle.com Thu Feb 28 01:32:03 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Feb 2013 19:32:03 +1000 Subject: Very poor performance of JNI AttachCurrentThread on Linux In-Reply-To: <512F21ED.6020507@redhat.com> References: <512CF7D5.2030300@redhat.com> <512D1D54.7050004@oracle.com> <512DDDAC.7080803@redhat.com> <512E04F0.10106@oracle.com> <512E0CFC.9020507@redhat.com> <512EDA9E.7060708@oracle.com> <512F21ED.6020507@redhat.com> Message-ID: <512F2413.5050302@oracle.com> On 28/02/2013 7:22 PM, Andrew Haley wrote: > On 02/28/2013 04:18 AM, David Holmes wrote: >> Anyway this is on Dmitry's to-do list. > > Well, it's much more urgent for others. Does this mean that you will > refuse a patch from anyone else that fixes his bug? No. But anyone planning on proposing a patch should liaise with Dmitry as they will need a sponsor anyway and we don't want anyone to be duplicating work unnecessarily. David > Andrew. > From aph at redhat.com Thu Feb 28 01:41:02 2013 From: aph at redhat.com (Andrew Haley) Date: Thu, 28 Feb 2013 09:41:02 +0000 Subject: Very poor performance of JNI AttachCurrentThread on Linux In-Reply-To: <512F2413.5050302@oracle.com> References: <512CF7D5.2030300@redhat.com> <512D1D54.7050004@oracle.com> <512DDDAC.7080803@redhat.com> <512E04F0.10106@oracle.com> <512E0CFC.9020507@redhat.com> <512EDA9E.7060708@oracle.com> <512F21ED.6020507@redhat.com> <512F2413.5050302@oracle.com> Message-ID: <512F262E.20804@redhat.com> On 02/28/2013 09:32 AM, David Holmes wrote: > On 28/02/2013 7:22 PM, Andrew Haley wrote: >> On 02/28/2013 04:18 AM, David Holmes wrote: >>> Anyway this is on Dmitry's to-do list. >> >> Well, it's much more urgent for others. Does this mean that you will >> refuse a patch from anyone else that fixes his bug? > > No. But anyone planning on proposing a patch should liaise with Dmitry > as they will need a sponsor anyway and we don't want anyone to be > duplicating work unnecessarily. OK. Andrew. From bengt.rutisson at oracle.com Thu Feb 28 02:12:59 2013 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Thu, 28 Feb 2013 10:12:59 +0000 Subject: hg: hsx/hotspot-main/hotspot: 10 new changesets Message-ID: <20130228101321.D87AA474AB@hg.openjdk.java.net> Changeset: 0598674c0056 Author: jwilhelm Date: 2013-02-21 11:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0598674c0056 8008314: Unimplemented() Atomic::load breaks the applications Summary: jlong atomics isn't fully implemented om all 32-bit platforms so we try to avoid it. In this case the atomic add wasn't needed. Reviewed-by: dholmes, dlong ! src/share/vm/runtime/atomic.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp Changeset: 96c885895d22 Author: johnc Date: 2013-02-22 11:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/96c885895d22 8007221: G1: concurrent phase durations do not state the time units ("secs") Summary: Add timer units to concurrent marking phases where the units were missing. Reviewed-by: jmasa, ysr ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: 9a8ee5301f33 Author: brutisso Date: 2013-02-26 11:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9a8ee5301f33 Merge Changeset: f1fb03a251e9 Author: poonam Date: 2013-02-21 23:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f1fb03a251e9 8008546: Wrong G1ConfidencePercent results in GUARANTEE(VARIANCE() > -1.0) FAILED Reviewed-by: brutisso, johnc Contributed-by: vladimir.kempik at oracle.com ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: fd32b88a87e9 Author: poonam Date: 2013-02-23 17:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fd32b88a87e9 Merge Changeset: 9289a00709b5 Author: poonam Date: 2013-02-26 08:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9289a00709b5 Merge Changeset: b685ca4f4fb9 Author: ehelin Date: 2013-02-20 16:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b685ca4f4fb9 8008536: Add HotSpot support for printing class loader statistics for JMap Reviewed-by: sla, brutisso + agent/src/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java - agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java Changeset: 3d3379aab292 Author: ehelin Date: 2013-02-26 22:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3d3379aab292 Merge - agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java Changeset: 9a094d29af19 Author: ehelin Date: 2013-02-06 07:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9a094d29af19 8004924: NPG: jmap -heap output should contain ClassMetaspaceSize value Reviewed-by: stefank, mgerdin ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java + test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java Changeset: b5e03c8ead49 Author: brutisso Date: 2013-02-28 09:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b5e03c8ead49 Merge - agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java From zhengyu.gu at oracle.com Thu Feb 28 07:45:53 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 28 Feb 2013 10:45:53 -0500 Subject: Review request 8008257 - NMT: assert(new_rec->is_allocation_record()) failed when running with shared memory option Message-ID: <512F7BB1.8080105@oracle.com> NMT did not probably record memory allocations from os::reserve_memory_special() path, which is usually related to UseLargePages VM option. The symptom of this bug is assertion failure in debug/fastdebug build or missing Java Heap in NMT output in production build. Bug: http://bugs.sun.com/view_bug.do?bug_id=8008257 Webrev: http://cr.openjdk.java.net/~zgu/8008257/webrev.00/ To trigger the failures: 1. On Windows, run with -XX:+UseLargePages (with/without -XX:+UseLargePagesIndividualAllocation) 2. On Linux, run with -XX:+UseLargePages -XX:+UseSHM 3. On Solaris, run with -XX:+UseLargePages -XX:+UseISM 4. On MacOSX, UseLargePages is disabled. Beware that fail to allocate large pages, does not cause JVM to fail. Instead, JVM will fallback to use regular pages. Tests: Many thanks to Christian T?rnqvist to find capable hardware and figure out how to get large pages to work. We were able to test the fix on Solaris sparcv9, Linux x64 and Windows x64. Thanks, -Zhengyu From joseph.provino at oracle.com Thu Feb 28 08:54:10 2013 From: joseph.provino at oracle.com (JOSEPH PROVINO) Date: Thu, 28 Feb 2013 11:54:10 -0500 Subject: Review request 8008310 - Some adjustments needed to, minimal VM warnings and errors for unsupported command line options In-Reply-To: <512EDEDF.2080900@oracle.com> References: <5127F2A0.7010506@oracle.com> <512B8A0A.9050301@oracle.com> <512C1349.1020706@oracle.com> <512CE9F0.6010901@oracle.com> <512D6549.2080406@oracle.com> <512E4530.6010204@oracle.com> <512EDEDF.2080900@oracle.com> Message-ID: <512F8BB2.3080908@oracle.com> On 2/27/2013 11:36 PM, David Holmes wrote: > On 28/02/2013 3:41 AM, JOSEPH PROVINO wrote: >> >> On 2/26/2013 8:45 PM, David Holmes wrote: >>> On 27/02/2013 2:59 AM, JOSEPH PROVINO wrote: >>>> >>>> On 2/25/2013 8:43 PM, David Holmes wrote: >>>>> On 26/02/2013 1:58 AM, JOSEPH PROVINO wrote: >>>>>> Latest webrev is here: >>>>>> http://cr.openjdk.java.net/~jprovino/8008310/webrev.02 >>>>>> >>>>>> - excluded filemap.cpp if CDS is 0. >>>>>> >>>>>> - confined changes for CDS to filemap.hpp. >>>>> >>>>> These changes are good - thanks. >>>>> >>>>> For arguments.cpp: >>>>> >>>>> 1076 FLAG_SET_DEFAULT(RequireSharedSpaces, false); >>>>> >>>>> If we execute this line then the flag is already false. >>>>> >>>>> Also, as discussed in email -Xshare:dump should probably be an error >>>>> not a warning, but note that if left as a warning then this code: >>>>> >>>>> 2518 // -Xshare:dump >>>>> 2519 } else if (match_option(option, "-Xshare:dump", &tail)) { >>>>> 2520 FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true); >>>>> 2521 set_mode_flags(_int); // Prevent compilation, which >>>>> creates objects >>>>> >>>>> would also force us into intepreter mode, so you would still need to >>>>> check INCLUDE_CDS here. >>>> >>>> If DumpSharedSpaces is changed to return JNI_ERR do I still need a >>>> conditional here? >>> >>> ?? You would need the conditional to decide to return JNI_ERR. >> >> I meant do I need #if INCLUDE_CDS around set_mode_flags(_int); > > So I was assuming this was the only place you needed to check this, > but you have to check for -XX:+DumpSharedSpaces as well. So if you > left the -Xshare:dump code alone and later checked for > DumpSharedSpaces and returned with JNI_ERR then it would not matter > that the switch to interpreter mode had already been made. okay, good. joe > > David > >> joe >> >>> >>> David >>> >>>> joe >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> thanks. >>>>>> >>>>>> joe >>>>>> >>>>>> >>>> >> From poonam.bajaj at oracle.com Thu Feb 28 10:26:06 2013 From: poonam.bajaj at oracle.com (poonam.bajaj at oracle.com) Date: Thu, 28 Feb 2013 18:26:06 +0000 Subject: hg: hsx/hsx24/hotspot: 2 new changesets Message-ID: <20130228182612.783D7474BD@hg.openjdk.java.net> Changeset: e8612dc1501b Author: poonam Date: 2013-02-21 23:58 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e8612dc1501b 8008546: Wrong G1ConfidencePercent results in GUARANTEE(VARIANCE() > -1.0) FAILED Reviewed-by: brutisso, johnc Contributed-by: vladimir.kempik at oracle.com ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: d323b9b05997 Author: poonam Date: 2013-02-28 10:50 +0000 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d323b9b05997 Merge From joseph.provino at oracle.com Thu Feb 28 10:54:07 2013 From: joseph.provino at oracle.com (JOSEPH PROVINO) Date: Thu, 28 Feb 2013 13:54:07 -0500 Subject: Review request 8008310 - Some adjustments needed to, minimal VM warnings and errors for unsupported command line options In-Reply-To: <512EDEDF.2080900@oracle.com> References: <5127F2A0.7010506@oracle.com> <512B8A0A.9050301@oracle.com> <512C1349.1020706@oracle.com> <512CE9F0.6010901@oracle.com> <512D6549.2080406@oracle.com> <512E4530.6010204@oracle.com> <512EDEDF.2080900@oracle.com> Message-ID: <512FA7CF.20908@oracle.com> Latest webrev is here: http://cr.openjdk.java.net/~jprovino/8008310/webrev.03 joe On 2/27/2013 11:36 PM, David Holmes wrote: > On 28/02/2013 3:41 AM, JOSEPH PROVINO wrote: >> >> On 2/26/2013 8:45 PM, David Holmes wrote: >>> On 27/02/2013 2:59 AM, JOSEPH PROVINO wrote: >>>> >>>> On 2/25/2013 8:43 PM, David Holmes wrote: >>>>> On 26/02/2013 1:58 AM, JOSEPH PROVINO wrote: >>>>>> Latest webrev is here: >>>>>> http://cr.openjdk.java.net/~jprovino/8008310/webrev.02 >>>>>> >>>>>> - excluded filemap.cpp if CDS is 0. >>>>>> >>>>>> - confined changes for CDS to filemap.hpp. >>>>> >>>>> These changes are good - thanks. >>>>> >>>>> For arguments.cpp: >>>>> >>>>> 1076 FLAG_SET_DEFAULT(RequireSharedSpaces, false); >>>>> >>>>> If we execute this line then the flag is already false. >>>>> >>>>> Also, as discussed in email -Xshare:dump should probably be an error >>>>> not a warning, but note that if left as a warning then this code: >>>>> >>>>> 2518 // -Xshare:dump >>>>> 2519 } else if (match_option(option, "-Xshare:dump", &tail)) { >>>>> 2520 FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true); >>>>> 2521 set_mode_flags(_int); // Prevent compilation, which >>>>> creates objects >>>>> >>>>> would also force us into intepreter mode, so you would still need to >>>>> check INCLUDE_CDS here. >>>> >>>> If DumpSharedSpaces is changed to return JNI_ERR do I still need a >>>> conditional here? >>> >>> ?? You would need the conditional to decide to return JNI_ERR. >> >> I meant do I need #if INCLUDE_CDS around set_mode_flags(_int); > > So I was assuming this was the only place you needed to check this, > but you have to check for -XX:+DumpSharedSpaces as well. So if you > left the -Xshare:dump code alone and later checked for > DumpSharedSpaces and returned with JNI_ERR then it would not matter > that the switch to interpreter mode had already been made. > > David > >> joe >> >>> >>> David >>> >>>> joe >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> thanks. >>>>>> >>>>>> joe >>>>>> >>>>>> >>>> >> From coleen.phillimore at oracle.com Thu Feb 28 11:34:58 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 28 Feb 2013 14:34:58 -0500 Subject: Review request 8008310 - Some adjustments needed to, minimal VM warnings and errors for unsupported command line options In-Reply-To: <512FA7CF.20908@oracle.com> References: <5127F2A0.7010506@oracle.com> <512B8A0A.9050301@oracle.com> <512C1349.1020706@oracle.com> <512CE9F0.6010901@oracle.com> <512D6549.2080406@oracle.com> <512E4530.6010204@oracle.com> <512EDEDF.2080900@oracle.com> <512FA7CF.20908@oracle.com> Message-ID: <512FB162.2060005@oracle.com> This looks better now. Setting Xint for DumpSharedSpaces in the big switch is fine, because you are returning an error for it later. Thanks for your perseverance. Coleen On 02/28/2013 01:54 PM, JOSEPH PROVINO wrote: > Latest webrev is here: > http://cr.openjdk.java.net/~jprovino/8008310/webrev.03 > > joe > > On 2/27/2013 11:36 PM, David Holmes wrote: >> On 28/02/2013 3:41 AM, JOSEPH PROVINO wrote: >>> >>> On 2/26/2013 8:45 PM, David Holmes wrote: >>>> On 27/02/2013 2:59 AM, JOSEPH PROVINO wrote: >>>>> >>>>> On 2/25/2013 8:43 PM, David Holmes wrote: >>>>>> On 26/02/2013 1:58 AM, JOSEPH PROVINO wrote: >>>>>>> Latest webrev is here: >>>>>>> http://cr.openjdk.java.net/~jprovino/8008310/webrev.02 >>>>>>> >>>>>>> - excluded filemap.cpp if CDS is 0. >>>>>>> >>>>>>> - confined changes for CDS to filemap.hpp. >>>>>> >>>>>> These changes are good - thanks. >>>>>> >>>>>> For arguments.cpp: >>>>>> >>>>>> 1076 FLAG_SET_DEFAULT(RequireSharedSpaces, false); >>>>>> >>>>>> If we execute this line then the flag is already false. >>>>>> >>>>>> Also, as discussed in email -Xshare:dump should probably be an error >>>>>> not a warning, but note that if left as a warning then this code: >>>>>> >>>>>> 2518 // -Xshare:dump >>>>>> 2519 } else if (match_option(option, "-Xshare:dump", &tail)) { >>>>>> 2520 FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true); >>>>>> 2521 set_mode_flags(_int); // Prevent compilation, which >>>>>> creates objects >>>>>> >>>>>> would also force us into intepreter mode, so you would still need to >>>>>> check INCLUDE_CDS here. >>>>> >>>>> If DumpSharedSpaces is changed to return JNI_ERR do I still need a >>>>> conditional here? >>>> >>>> ?? You would need the conditional to decide to return JNI_ERR. >>> >>> I meant do I need #if INCLUDE_CDS around set_mode_flags(_int); >> >> So I was assuming this was the only place you needed to check this, >> but you have to check for -XX:+DumpSharedSpaces as well. So if you >> left the -Xshare:dump code alone and later checked for >> DumpSharedSpaces and returned with JNI_ERR then it would not matter >> that the switch to interpreter mode had already been made. >> >> David >> >>> joe >>> >>>> >>>> David >>>> >>>>> joe >>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> thanks. >>>>>>> >>>>>>> joe >>>>>>> >>>>>>> >>>>> >>> > From joseph.provino at oracle.com Thu Feb 28 12:01:04 2013 From: joseph.provino at oracle.com (JOSEPH PROVINO) Date: Thu, 28 Feb 2013 15:01:04 -0500 Subject: Review request 8008310 - Some adjustments needed to, minimal VM warnings and errors for unsupported command line options In-Reply-To: <512FB162.2060005@oracle.com> References: <5127F2A0.7010506@oracle.com> <512B8A0A.9050301@oracle.com> <512C1349.1020706@oracle.com> <512CE9F0.6010901@oracle.com> <512D6549.2080406@oracle.com> <512E4530.6010204@oracle.com> <512EDEDF.2080900@oracle.com> <512FA7CF.20908@oracle.com> <512FB162.2060005@oracle.com> Message-ID: <512FB780.8030305@oracle.com> On 2/28/2013 2:34 PM, Coleen Phillimore wrote: > > This looks better now. Setting Xint for DumpSharedSpaces in the big > switch is fine, because you are returning an error for it later. > Thanks for your perseverance. Thanks for reviewing! joe > > Coleen > > On 02/28/2013 01:54 PM, JOSEPH PROVINO wrote: >> Latest webrev is here: >> http://cr.openjdk.java.net/~jprovino/8008310/webrev.03 >> >> joe >> >> On 2/27/2013 11:36 PM, David Holmes wrote: >>> On 28/02/2013 3:41 AM, JOSEPH PROVINO wrote: >>>> >>>> On 2/26/2013 8:45 PM, David Holmes wrote: >>>>> On 27/02/2013 2:59 AM, JOSEPH PROVINO wrote: >>>>>> >>>>>> On 2/25/2013 8:43 PM, David Holmes wrote: >>>>>>> On 26/02/2013 1:58 AM, JOSEPH PROVINO wrote: >>>>>>>> Latest webrev is here: >>>>>>>> http://cr.openjdk.java.net/~jprovino/8008310/webrev.02 >>>>>>>> >>>>>>>> - excluded filemap.cpp if CDS is 0. >>>>>>>> >>>>>>>> - confined changes for CDS to filemap.hpp. >>>>>>> >>>>>>> These changes are good - thanks. >>>>>>> >>>>>>> For arguments.cpp: >>>>>>> >>>>>>> 1076 FLAG_SET_DEFAULT(RequireSharedSpaces, false); >>>>>>> >>>>>>> If we execute this line then the flag is already false. >>>>>>> >>>>>>> Also, as discussed in email -Xshare:dump should probably be an >>>>>>> error >>>>>>> not a warning, but note that if left as a warning then this code: >>>>>>> >>>>>>> 2518 // -Xshare:dump >>>>>>> 2519 } else if (match_option(option, "-Xshare:dump", &tail)) { >>>>>>> 2520 FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true); >>>>>>> 2521 set_mode_flags(_int); // Prevent compilation, which >>>>>>> creates objects >>>>>>> >>>>>>> would also force us into intepreter mode, so you would still >>>>>>> need to >>>>>>> check INCLUDE_CDS here. >>>>>> >>>>>> If DumpSharedSpaces is changed to return JNI_ERR do I still need a >>>>>> conditional here? >>>>> >>>>> ?? You would need the conditional to decide to return JNI_ERR. >>>> >>>> I meant do I need #if INCLUDE_CDS around set_mode_flags(_int); >>> >>> So I was assuming this was the only place you needed to check this, >>> but you have to check for -XX:+DumpSharedSpaces as well. So if you >>> left the -Xshare:dump code alone and later checked for >>> DumpSharedSpaces and returned with JNI_ERR then it would not matter >>> that the switch to interpreter mode had already been made. >>> >>> David >>> >>>> joe >>>> >>>>> >>>>> David >>>>> >>>>>> joe >>>>>> >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> thanks. >>>>>>>> >>>>>>>> joe >>>>>>>> >>>>>>>> >>>>>> >>>> >> > From chris.plummer at oracle.com Thu Feb 28 14:36:14 2013 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 28 Feb 2013 14:36:14 -0800 Subject: Review request 8008310 - Some adjustments needed to minimal VM warnings and errors for unsupported command line options In-Reply-To: References: Message-ID: <512FDBDE.3060404@oracle.com> Looks good! Chris On 2/28/13 12:00 PM, JOSEPH PROVINO wrote: > Latest webrev is here: > http://cr.openjdk.java.net/~jprovino/8008310/webrev.03 > > joe > > On 2/27/2013 11:36 PM, David Holmes wrote: >> >On 28/02/2013 3:41 AM, JOSEPH PROVINO wrote: >>> >> >>> >>On 2/26/2013 8:45 PM, David Holmes wrote: >>>> >>>On 27/02/2013 2:59 AM, JOSEPH PROVINO wrote: >>>>> >>>> >>>>> >>>>On 2/25/2013 8:43 PM, David Holmes wrote: >>>>>> >>>>>On 26/02/2013 1:58 AM, JOSEPH PROVINO wrote: >>>>>>> >>>>>>Latest webrev is here: >>>>>>> >>>>>>http://cr.openjdk.java.net/~jprovino/8008310/webrev.02 >>>>>>> >>>>>> >>>>>>> >>>>>>- excluded filemap.cpp if CDS is 0. >>>>>>> >>>>>> >>>>>>> >>>>>>- confined changes for CDS to filemap.hpp. >>>>>> >>>>> >>>>>> >>>>>These changes are good - thanks. >>>>>> >>>>> >>>>>> >>>>>For arguments.cpp: >>>>>> >>>>> >>>>>> >>>>>1076 FLAG_SET_DEFAULT(RequireSharedSpaces, false); >>>>>> >>>>> >>>>>> >>>>>If we execute this line then the flag is already false. >>>>>> >>>>> >>>>>> >>>>>Also, as discussed in email -Xshare:dump should probably be an error >>>>>> >>>>>not a warning, but note that if left as a warning then this code: >>>>>> >>>>> >>>>>> >>>>>2518 // -Xshare:dump >>>>>> >>>>>2519 } else if (match_option(option, "-Xshare:dump", &tail)) { >>>>>> >>>>>2520 FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true); >>>>>> >>>>>2521 set_mode_flags(_int); // Prevent compilation, which >>>>>> >>>>>creates objects >>>>>> >>>>> >>>>>> >>>>>would also force us into intepreter mode, so you would still need to >>>>>> >>>>>check INCLUDE_CDS here. >>>>> >>>> >>>>> >>>>If DumpSharedSpaces is changed to return JNI_ERR do I still need a >>>>> >>>>conditional here? >>>> >>> >>>> >>>?? You would need the conditional to decide to return JNI_ERR. >>> >> >>> >>I meant do I need #if INCLUDE_CDS around set_mode_flags(_int); >> > >> >So I was assuming this was the only place you needed to check this, >> >but you have to check for -XX:+DumpSharedSpaces as well. So if you >> >left the -Xshare:dump code alone and later checked for >> >DumpSharedSpaces and returned with JNI_ERR then it would not matter >> >that the switch to interpreter mode had already been made. >> > >> >David >> > >>> >>joe >>> >> >>>> >>> >>>> >>>David >>>> >>> >>>>> >>>>joe >>>>> >>>> >>>>>> >>>>> >>>>>> >>>>>David >>>>>> >>>>>----- >>>>>> >>>>> >>>>>>> >>>>>>thanks. >>>>>>> >>>>>> >>>>>>> >>>>>>joe >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> From alejandro.murillo at oracle.com Thu Feb 28 15:10:11 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 28 Feb 2013 23:10:11 +0000 Subject: hg: hsx/hsx24/hotspot: 22 new changesets Message-ID: <20130228231059.9972F474D4@hg.openjdk.java.net> Changeset: 6767490c06a8 Author: asaha Date: 2012-10-12 11:55 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6767490c06a8 8000822: Fork hs23.7 hsx from hs23.6 for jdk7u11 and reinitialize build number Reviewed-by: jcoomes ! make/hotspot_version Changeset: db7028c8a953 Author: kamg Date: 2012-11-08 17:45 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/db7028c8a953 8001307: Modify ACC_SUPER behavior Summary: Disallow non-virtual calls even when ACC_SUPER is absent. Reviewed-by: kvn, acorn ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/runtime/globals.hpp Changeset: 4d418a1b8be0 Author: katleman Date: 2012-11-13 16:57 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4d418a1b8be0 Added tag jdk7u11-b03 for changeset db7028c8a953 ! .hgtags Changeset: c893d43c9fb1 Author: ewendeli Date: 2012-11-15 14:43 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c893d43c9fb1 Merge Changeset: 2c4f06bc409a Author: ewendeli Date: 2012-11-19 16:27 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2c4f06bc409a Merge ! .hgtags Changeset: f71032f398a3 Author: cl Date: 2012-11-20 18:12 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f71032f398a3 Added tag jdk7u11-b04 for changeset 4d418a1b8be0 ! .hgtags Changeset: 8ecba09e66cd Author: cl Date: 2012-11-20 18:31 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/8ecba09e66cd Added tag jdk7u11-b05 for changeset f71032f398a3 ! .hgtags Changeset: 0cbce123c902 Author: ewendeli Date: 2012-11-22 08:19 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0cbce123c902 Merge ! .hgtags Changeset: c217f85ffff8 Author: katleman Date: 2012-11-28 15:41 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c217f85ffff8 Added tag jdk7u11-b06 for changeset 0cbce123c902 ! .hgtags Changeset: 94bf1e3dafef Author: ewendeli Date: 2012-11-30 04:55 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/94bf1e3dafef Merge ! .hgtags Changeset: c1962395e8f2 Author: katleman Date: 2012-12-04 10:39 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/c1962395e8f2 Added tag jdk7u11-b07 for changeset 94bf1e3dafef ! .hgtags Changeset: 2b543aa340e4 Author: ewendeli Date: 2012-12-06 17:42 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2b543aa340e4 Merge ! .hgtags Changeset: ed328ec14835 Author: katleman Date: 2012-12-11 12:14 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ed328ec14835 Added tag jdk7u11-b08 for changeset 2b543aa340e4 ! .hgtags Changeset: 34a7b6dda06e Author: ewendeli Date: 2013-01-14 18:32 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/34a7b6dda06e Merge ! .hgtags Changeset: e0e52e35e0c5 Author: katleman Date: 2013-01-15 18:57 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e0e52e35e0c5 Added tag jdk7u13-b09 for changeset 34a7b6dda06e ! .hgtags Changeset: b4d1e151243f Author: katleman Date: 2013-02-01 10:25 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b4d1e151243f Added tag jdk7u13-b20 for changeset e0e52e35e0c5 ! .hgtags Changeset: 423f3a828eb5 Author: ewendeli Date: 2013-02-03 22:45 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/423f3a828eb5 Merge ! .hgtags - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java ! make/hotspot_version - src/share/tools/ProjectCreator/DirectoryTree.java - src/share/tools/ProjectCreator/DirectoryTreeNode.java - src/share/tools/ProjectCreator/FileFormatException.java - src/share/tools/ProjectCreator/WinGammaPlatformVC6.java - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp ! src/share/vm/interpreter/linkResolver.cpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/runtime/globals.hpp - src/share/vm/trace/traceEventTypes.hpp Changeset: 960d2e216955 Author: ewendeli Date: 2013-02-08 15:02 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/960d2e216955 Merge ! .hgtags ! make/hotspot_version Changeset: e3d2c238e29c Author: amurillo Date: 2013-02-19 15:21 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/e3d2c238e29c Merge ! .hgtags ! make/hotspot_version Changeset: 375a8c57a7f0 Author: katleman Date: 2013-02-27 16:51 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/375a8c57a7f0 Added tag jdk7u14-b14 for changeset e3d2c238e29c ! .hgtags Changeset: 860ae068f4df Author: amurillo Date: 2013-02-28 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/860ae068f4df Merge ! make/hotspot_version Changeset: 12619005c5e2 Author: amurillo Date: 2013-02-28 10:45 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/12619005c5e2 Added tag hs24-b34 for changeset 860ae068f4df ! .hgtags From calvin.cheung at oracle.com Thu Feb 28 15:24:46 2013 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 28 Feb 2013 15:24:46 -0800 Subject: Review request: 8009174: add class load event tracing Message-ID: <512FE73E.2020709@oracle.com> This change is for adding the class load event tracing. The event will include the following fields: loaded class defining class loader initiating class loader webrev: http://cr.openjdk.java.net/~ccheung/8009174/webrev/ thanks, Calvin From alejandro.murillo at oracle.com Thu Feb 28 17:40:25 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 01 Mar 2013 01:40:25 +0000 Subject: hg: hsx/hsx24/hotspot: 8009225: new hotspot build - hs24-b35 Message-ID: <20130301014030.3D490474DB@hg.openjdk.java.net> Changeset: 90e4826656f8 Author: amurillo Date: 2013-02-28 11:15 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/90e4826656f8 8009225: new hotspot build - hs24-b35 Reviewed-by: jcoomes ! make/hotspot_version From joseph.provino at oracle.com Thu Feb 28 17:56:57 2013 From: joseph.provino at oracle.com (JOSEPH PROVINO) Date: Thu, 28 Feb 2013 20:56:57 -0500 Subject: Please review: 8006498 and 8008474 In-Reply-To: <512BAE75.5080800@oracle.com> References: <5125448B.8090107@oracle.com> <5125685F.5070907@oracle.com> <51261EDD.2020309@oracle.com> <512633D5.6040202@oracle.com> <5126DF09.2040207@oracle.com> <5126E261.6080601@oracle.com> <5127822B.9090208@oracle.com> <512A9B5E.7040401@oracle.com> <512BAE75.5080800@oracle.com> Message-ID: <51300AE9.6080402@oracle.com> Latest webrev is here: http://cr.openjdk.java.net/~jprovino/8006498/webrev.01 joe On 2/25/2013 1:33 PM, Mikael Vidstedt wrote: > > On 2/24/2013 2:59 PM, David Holmes wrote: >> On 23/02/2013 12:35 AM, Joseph Provino wrote: >>> On 02/21/2013 10:13 PM, David Holmes wrote: >>>> On 22/02/2013 12:59 PM, David Holmes wrote: >>>>> On 22/02/2013 12:48 AM, JOSEPH PROVINO wrote: >>>>>> Actually, from looking at this again, I thought David was suggesting >>>>>> that -Wundef >>>>>> should be added to ACCEPTABLE_WARNINGS for linux and bsd. >>>>> >>>>> I was being ambivalent - I just wanted to see consistency. We >>>>> should see >>>>> where Mikael is adding -Wunused >>>> >>>> Ha! Now this really muddies the waters (this is linux only): >>>> >>>> ! ADDITIONAL_WARNINGS = -Wunused-function >>>> ! >>>> ! CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(ACCEPTABLE_WARNINGS) >>>> $(ADDITIONAL_WARNINGS) >>> >>> That's the problem -- it's already inconsistent. >> >> The names do not make sense to me but perhaps I am misunderstanding >> how this works. Are we listing all the warnings that will be errors, >> or are we listing those warnings that we don't want to be errors? I'm >> not understanding what acceptable nor additional are supposed to mean >> here. > > I can't say that I see any real patterns in how these variables are > used either. My guess is that at some point somebody figured out a few > warnings that were "acceptable" - as in warnings that we could turn on > without getting tons of false positives and incorrectly generated > code, but that's just a guess. Unless somebody has insights around why > these are named and split up the way they are I suggest that we > simplify and unify all of it. > > My suggestion is to have all the warning flags go into a variable > called WARNING_FLAGS, leaving only two variables: WARNINGS_ARE_ERRORS > and WARNING_FLAGS. Something like this (for Linux, similar for Solaris): > > WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wunused-functions -Wundef > > # Since GCC 4.3, -Wconversion has changed its meanings to warn these > implicit > # conversions which might affect the values. To avoid that, we do not > use it. > ifeq "$(shell expr \( $(CC_VER_MAJOR) \> 4 \) \| \( \( $(CC_VER_MAJOR) > = 4 \) \& \( $(CC_VER_MINOR) \>= 3 \) \))" "0" > WARNING_FLAGS += -Wconversion > endif > > CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(WARNING_FLAGS) > > Reasonable? > > Cheers, > Mikael > > >> >> David >> >>> joe >>> >>>> >>>> >>>> David >>>> >>>>> >>>>> David >>>>> >>>>>> joe >>>>>> >>>>>> On 2/21/2013 8:19 AM, Zhengyu Gu wrote: >>>>>>> Agree with David, -Wundef should go to CFLAGS_WARN/DEFAULT on >>>>>>> Solaris >>>>>>> if there is not particular reason not to. >>>>>>> >>>>>>> Other than that, look good to me. >>>>>>> >>>>>>> -Zhengyu >>>>>>> >>>>>>> On 2/20/2013 7:20 PM, David Holmes wrote: >>>>>>>> On 21/02/2013 7:47 AM, JOSEPH PROVINO wrote: >>>>>>>>> 8006498: ASSERT and other symbols used incorrectly with #if are >>>>>>>>> supposed to be defined or not >>>>>>>>> >>>>>>>>> 8008474: -Wundef should be added to the build to catch #if >>>>>>>>> references >>>>>>>>> to undefined macros. >>>>>>>>> >>>>>>>>> >>>>>>>>> Webrev is here: >>>>>>>>> http://cr.openjdk.java.net/~jprovino/8006498/webrev.00/ >>>>>>>> >>>>>>>> On bsd and linux you simply added -Wundef directly to the CFLAGS: >>>>>>>> >>>>>>>> +CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) >>>>>>>> $(ACCEPTABLE_WARNINGS) >>>>>>>> -Wundef >>>>>>>> >>>>>>>> but on Solaris you added it to ADDITIONAL_WARNINGS: >>>>>>>> >>>>>>>> +ADDITIONAL_WARNINGS = -Wpointer-arith -Wconversion -Wsign-compare >>>>>>>> -Wundef >>>>>>>> >>>>>>>> I guess it is a little confusing as to whether ACCEPTABLE_WARNINGS >>>>>>>> and ADDITIONAL_WARNINGS are meant to be the same thing. >>>>>>>> >>>>>>>> Otherwise all the #if -> #ifdef etc seem okay. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> joe >>>>>>> >>>>>> >>> > From mikael.vidstedt at oracle.com Thu Feb 28 18:09:29 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 28 Feb 2013 18:09:29 -0800 Subject: Please review: 8006498 and 8008474 In-Reply-To: <51300AE9.6080402@oracle.com> References: <5125448B.8090107@oracle.com> <5125685F.5070907@oracle.com> <51261EDD.2020309@oracle.com> <512633D5.6040202@oracle.com> <5126DF09.2040207@oracle.com> <5126E261.6080601@oracle.com> <5127822B.9090208@oracle.com> <512A9B5E.7040401@oracle.com> <512BAE75.5080800@oracle.com> <51300AE9.6080402@oracle.com> Message-ID: <51300DD9.8060703@oracle.com> Looks good! Do you think it'd make sense to move "-Wpointer-arith -Wsign-compare -Wundef" out of the ifneq for {bsd,linux}/Makefile/gcc.make and only leave the -Wconversion in there? I can do that as part of the pending -Wunused changes if you don't want to update it now. Cheers, Mikael On 2013-02-28 17:56, JOSEPH PROVINO wrote: > Latest webrev is here: > http://cr.openjdk.java.net/~jprovino/8006498/webrev.01 > > joe > > > On 2/25/2013 1:33 PM, Mikael Vidstedt wrote: >> >> On 2/24/2013 2:59 PM, David Holmes wrote: >>> On 23/02/2013 12:35 AM, Joseph Provino wrote: >>>> On 02/21/2013 10:13 PM, David Holmes wrote: >>>>> On 22/02/2013 12:59 PM, David Holmes wrote: >>>>>> On 22/02/2013 12:48 AM, JOSEPH PROVINO wrote: >>>>>>> Actually, from looking at this again, I thought David was >>>>>>> suggesting >>>>>>> that -Wundef >>>>>>> should be added to ACCEPTABLE_WARNINGS for linux and bsd. >>>>>> >>>>>> I was being ambivalent - I just wanted to see consistency. We >>>>>> should see >>>>>> where Mikael is adding -Wunused >>>>> >>>>> Ha! Now this really muddies the waters (this is linux only): >>>>> >>>>> ! ADDITIONAL_WARNINGS = -Wunused-function >>>>> ! >>>>> ! CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(ACCEPTABLE_WARNINGS) >>>>> $(ADDITIONAL_WARNINGS) >>>> >>>> That's the problem -- it's already inconsistent. >>> >>> The names do not make sense to me but perhaps I am misunderstanding >>> how this works. Are we listing all the warnings that will be errors, >>> or are we listing those warnings that we don't want to be errors? >>> I'm not understanding what acceptable nor additional are supposed to >>> mean here. >> >> I can't say that I see any real patterns in how these variables are >> used either. My guess is that at some point somebody figured out a >> few warnings that were "acceptable" - as in warnings that we could >> turn on without getting tons of false positives and incorrectly >> generated code, but that's just a guess. Unless somebody has insights >> around why these are named and split up the way they are I suggest >> that we simplify and unify all of it. >> >> My suggestion is to have all the warning flags go into a variable >> called WARNING_FLAGS, leaving only two variables: WARNINGS_ARE_ERRORS >> and WARNING_FLAGS. Something like this (for Linux, similar for Solaris): >> >> WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wunused-functions >> -Wundef >> >> # Since GCC 4.3, -Wconversion has changed its meanings to warn these >> implicit >> # conversions which might affect the values. To avoid that, we do not >> use it. >> ifeq "$(shell expr \( $(CC_VER_MAJOR) \> 4 \) \| \( \( >> $(CC_VER_MAJOR) = 4 \) \& \( $(CC_VER_MINOR) \>= 3 \) \))" "0" >> WARNING_FLAGS += -Wconversion >> endif >> >> CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(WARNING_FLAGS) >> >> Reasonable? >> >> Cheers, >> Mikael >> >> >>> >>> David >>> >>>> joe >>>> >>>>> >>>>> >>>>> David >>>>> >>>>>> >>>>>> David >>>>>> >>>>>>> joe >>>>>>> >>>>>>> On 2/21/2013 8:19 AM, Zhengyu Gu wrote: >>>>>>>> Agree with David, -Wundef should go to CFLAGS_WARN/DEFAULT on >>>>>>>> Solaris >>>>>>>> if there is not particular reason not to. >>>>>>>> >>>>>>>> Other than that, look good to me. >>>>>>>> >>>>>>>> -Zhengyu >>>>>>>> >>>>>>>> On 2/20/2013 7:20 PM, David Holmes wrote: >>>>>>>>> On 21/02/2013 7:47 AM, JOSEPH PROVINO wrote: >>>>>>>>>> 8006498: ASSERT and other symbols used incorrectly with #if are >>>>>>>>>> supposed to be defined or not >>>>>>>>>> >>>>>>>>>> 8008474: -Wundef should be added to the build to catch #if >>>>>>>>>> references >>>>>>>>>> to undefined macros. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Webrev is here: >>>>>>>>>> http://cr.openjdk.java.net/~jprovino/8006498/webrev.00/ >>>>>>>>> >>>>>>>>> On bsd and linux you simply added -Wundef directly to the CFLAGS: >>>>>>>>> >>>>>>>>> +CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) >>>>>>>>> $(ACCEPTABLE_WARNINGS) >>>>>>>>> -Wundef >>>>>>>>> >>>>>>>>> but on Solaris you added it to ADDITIONAL_WARNINGS: >>>>>>>>> >>>>>>>>> +ADDITIONAL_WARNINGS = -Wpointer-arith -Wconversion >>>>>>>>> -Wsign-compare >>>>>>>>> -Wundef >>>>>>>>> >>>>>>>>> I guess it is a little confusing as to whether >>>>>>>>> ACCEPTABLE_WARNINGS >>>>>>>>> and ADDITIONAL_WARNINGS are meant to be the same thing. >>>>>>>>> >>>>>>>>> Otherwise all the #if -> #ifdef etc seem okay. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> joe >>>>>>>> >>>>>>> >>>> >> > From john.coomes at oracle.com Thu Feb 28 20:31:56 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Mar 2013 04:31:56 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b79 for changeset 91d35211e744 Message-ID: <20130301043156.E6162474DF@hg.openjdk.java.net> Changeset: 85b5b4cc388c Author: katleman Date: 2013-02-28 10:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/85b5b4cc388c Added tag jdk8-b79 for changeset 91d35211e744 ! .hgtags From john.coomes at oracle.com Thu Feb 28 20:32:25 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Mar 2013 04:32:25 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b79 for changeset 70d8658d2a30 Message-ID: <20130301043231.5BB41474E2@hg.openjdk.java.net> Changeset: b0224010e2f0 Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/b0224010e2f0 Added tag jdk8-b79 for changeset 70d8658d2a30 ! .hgtags From john.coomes at oracle.com Thu Feb 28 20:32:09 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Mar 2013 04:32:09 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b79 for changeset 58fa065dd5d6 Message-ID: <20130301043221.3DFAD474E1@hg.openjdk.java.net> Changeset: 4873a0499bc3 Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/4873a0499bc3 Added tag jdk8-b79 for changeset 58fa065dd5d6 ! .hgtags From john.coomes at oracle.com Thu Feb 28 20:32:00 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Mar 2013 04:32:00 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b79 for changeset e41fb1aa0329 Message-ID: <20130301043205.5E92C474E0@hg.openjdk.java.net> Changeset: 5f3d4a6bdd02 Author: katleman Date: 2013-02-28 10:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/5f3d4a6bdd02 Added tag jdk8-b79 for changeset e41fb1aa0329 ! .hgtags From john.coomes at oracle.com Thu Feb 28 20:32:46 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Mar 2013 04:32:46 +0000 Subject: hg: hsx/hotspot-main/jdk: 3 new changesets Message-ID: <20130301043432.59756474E3@hg.openjdk.java.net> Changeset: 5245b2f1c53d Author: ngthomas Date: 2013-02-21 17:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5245b2f1c53d 8008691: Build failure (NEWBUILD=false) on Mac Reviewed-by: art, anthony ! make/sun/lwawt/FILES_export_macosx.gmk Changeset: c933505d75c2 Author: dcherepanov Date: 2013-02-26 12:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c933505d75c2 Merge Changeset: d967dd39a5ca Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d967dd39a5ca Added tag jdk8-b79 for changeset c933505d75c2 ! .hgtags From john.coomes at oracle.com Thu Feb 28 20:37:04 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 01 Mar 2013 04:37:04 +0000 Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b79 for changeset 56dfafbb9e1a Message-ID: <20130301043715.7D356474E4@hg.openjdk.java.net> Changeset: a8227c617684 Author: katleman Date: 2013-02-28 10:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a8227c617684 Added tag jdk8-b79 for changeset 56dfafbb9e1a ! .hgtags From jesper.wilhelmsson at oracle.com Thu Feb 28 21:06:51 2013 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Fri, 01 Mar 2013 05:06:51 +0000 Subject: hg: hsx/hsx24/hotspot: 3 new changesets Message-ID: <20130301050659.BB10947507@hg.openjdk.java.net> Changeset: 1a726a0f001b Author: jwilhelm Date: 2013-02-28 23:30 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1a726a0f001b 8008314: Unimplemented() Atomic::load breaks the applications Summary: jlong atomics isn't fully implemented on all 32-bit platforms so we try to avoid it. In this case the atomic add wasn't needed. Reviewed-by: dholmes, dlong ! src/share/vm/runtime/atomic.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp Changeset: 4ddaaf331af4 Author: jwilhelm Date: 2013-03-01 01:14 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4ddaaf331af4 Merge Changeset: ee712d4e3af6 Author: jwilhelm Date: 2013-03-01 03:54 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/ee712d4e3af6 Merge From christian.thalinger at oracle.com Thu Feb 28 21:43:14 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 28 Feb 2013 21:43:14 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> <512C632B.3070206@oracle.com> Message-ID: <1687588F-E191-4ADD-A932-37079E97B2AF@oracle.com> On Feb 26, 2013, at 6:09 PM, Christian Thalinger wrote: > > On Feb 25, 2013, at 11:24 PM, David Holmes wrote: > >> On 26/02/2013 4:42 AM, Christian Thalinger wrote: >>> On Feb 24, 2013, at 2:54 PM, David Holmes wrote: >>>> On 23/02/2013 1:55 PM, Christian Thalinger wrote: >>>>> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: >>>>> >>>>> http://cr.openjdk.java.net/~twisti/8006965/ >>>>> >>>>> This would be the first of three fixes: >>>>> >>>>> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets >>>> >>>> This logic is not suitable: >>>> >>>> 541 # Testing the built JVM >>>> 542 ifeq ($(JAVA_HOME),) >>>> 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>> 544 else >>>> 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>> 546 endif >>>> >>>> I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! >>> >>> That's not entirely correct. test_gamma uses your JAVA_HOME setting: >> >> This is so confusing. Our makefiles are an abomination! > > I couldn't agree more. > >> >> So this all started because the makefile has: >> >> JAVA_HOME=$(ABS_BOOTDIR) >> >> which was flagged as wrong because gamma would run in the boot JDK. But now it seems the make variable JAVA_HOME is irrelevant anyway because the test_gamma script will use the JAVA_HOME environment variable. >> >> So how did the boot JDK come back into this??? >> >>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 >>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre >>> >>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo >>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>> JAVA_HOME must point to a 64-bit OpenJDK. >>> >>> And here comes this little snippet into play: >>> >>> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) >>> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>> >>> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. >> >> I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is this BOOTDIR value being used? There is no use of it in http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it pre-existing ?? > > I talked to John Coomes about that yesterday and we can remove that line. ABS_BOOTDIR is only used by Windows. Btw. I've updated the webrev. I think we can also remove the -server switch from the run command line because we point the VM to the libjvm anyway. How about this change? -- Chris > > -- Chris > >> >> Thanks, >> David >> >>> I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. >>> >>>> >>>> I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? >>> >>> It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. >>> >>>> >>>> I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. >>> >>> It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. >>> >>> -- Chris >>> >>>> >>>> And this addition still makes no sense to me: >>>> >>>> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>> >>>> Why do you need to add BOOTDIR to the MAKE_ARGS? >>>> >>>> David >>>> >>>> >>>>> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 >>>>> >>>>> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} >>>>> >>>>> -- Chris >>>>> >>>>> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: >>>>> >>>>>> >>>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>>> >>>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>>> >>>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>>>> >>>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>>> >>>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>>> >>>>>>>> 8006965: test_gamma should run with import JDK >>>>>>>> Reviewed-by: >>>>>>>> >>>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>>> >>>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>>> running test_gamma. >>>>>>>> >>>>>>>> make/bsd/makefiles/buildtree.make >>>>>>>> make/defs.make >>>>>>>> make/linux/makefiles/buildtree.make >>>>>>>> make/solaris/makefiles/buildtree.make > From david.holmes at oracle.com Thu Feb 28 22:34:17 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Mar 2013 16:34:17 +1000 Subject: Review request 8008310 - Some adjustments needed to, minimal VM warnings and errors for unsupported command line options In-Reply-To: <512FA7CF.20908@oracle.com> References: <5127F2A0.7010506@oracle.com> <512B8A0A.9050301@oracle.com> <512C1349.1020706@oracle.com> <512CE9F0.6010901@oracle.com> <512D6549.2080406@oracle.com> <512E4530.6010204@oracle.com> <512EDEDF.2080900@oracle.com> <512FA7CF.20908@oracle.com> Message-ID: <51304BE9.9080206@oracle.com> On 1/03/2013 4:54 AM, JOSEPH PROVINO wrote: > Latest webrev is here: > http://cr.openjdk.java.net/~jprovino/8008310/webrev.03 One lingering glitch: 3273 if (DumpSharedSpaces || RequireSharedSpaces) { 3274 jio_fprintf(defaultStream::error_stream(), 3275 "Shared spaces are not supported in this VM\n"); 3276 return JNI_ERR; 3277 } 3278 if (UseSharedSpaces || PrintSharedSpaces) { 3279 warning("Shared spaces are not supported in this VM"); 3280 } 3281 FLAG_SET_DEFAULT(DumpSharedSpaces, false); 3282 FLAG_SET_DEFAULT(RequireSharedSpaces, false); 3283 FLAG_SET_DEFAULT(PrintSharedSpaces, false); The last three lines only need to be these two lines: FLAG_SET_DEFAULT(UseSharedSpaces, false); FLAG_SET_DEFAULT(PrintSharedSpaces, false); and they can move inside the if. DumpSharedSpaces and RequireSharedSpaces must already be false else we exit at #3276. David ----- > joe > > On 2/27/2013 11:36 PM, David Holmes wrote: >> On 28/02/2013 3:41 AM, JOSEPH PROVINO wrote: >>> >>> On 2/26/2013 8:45 PM, David Holmes wrote: >>>> On 27/02/2013 2:59 AM, JOSEPH PROVINO wrote: >>>>> >>>>> On 2/25/2013 8:43 PM, David Holmes wrote: >>>>>> On 26/02/2013 1:58 AM, JOSEPH PROVINO wrote: >>>>>>> Latest webrev is here: >>>>>>> http://cr.openjdk.java.net/~jprovino/8008310/webrev.02 >>>>>>> >>>>>>> - excluded filemap.cpp if CDS is 0. >>>>>>> >>>>>>> - confined changes for CDS to filemap.hpp. >>>>>> >>>>>> These changes are good - thanks. >>>>>> >>>>>> For arguments.cpp: >>>>>> >>>>>> 1076 FLAG_SET_DEFAULT(RequireSharedSpaces, false); >>>>>> >>>>>> If we execute this line then the flag is already false. >>>>>> >>>>>> Also, as discussed in email -Xshare:dump should probably be an error >>>>>> not a warning, but note that if left as a warning then this code: >>>>>> >>>>>> 2518 // -Xshare:dump >>>>>> 2519 } else if (match_option(option, "-Xshare:dump", &tail)) { >>>>>> 2520 FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true); >>>>>> 2521 set_mode_flags(_int); // Prevent compilation, which >>>>>> creates objects >>>>>> >>>>>> would also force us into intepreter mode, so you would still need to >>>>>> check INCLUDE_CDS here. >>>>> >>>>> If DumpSharedSpaces is changed to return JNI_ERR do I still need a >>>>> conditional here? >>>> >>>> ?? You would need the conditional to decide to return JNI_ERR. >>> >>> I meant do I need #if INCLUDE_CDS around set_mode_flags(_int); >> >> So I was assuming this was the only place you needed to check this, >> but you have to check for -XX:+DumpSharedSpaces as well. So if you >> left the -Xshare:dump code alone and later checked for >> DumpSharedSpaces and returned with JNI_ERR then it would not matter >> that the switch to interpreter mode had already been made. >> >> David >> >>> joe >>> >>>> >>>> David >>>> >>>>> joe >>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> thanks. >>>>>>> >>>>>>> joe >>>>>>> >>>>>>> >>>>> >>> > From david.holmes at oracle.com Thu Feb 28 22:57:59 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Mar 2013 16:57:59 +1000 Subject: Review request: 8009174: add class load event tracing In-Reply-To: <512FE73E.2020709@oracle.com> References: <512FE73E.2020709@oracle.com> Message-ID: <51305177.7070302@oracle.com> Hi Calvin, So this adds the code that would allow for the event tracing but it doesn't actually add the code that will do the event tracing ??? Second problem: you can't store raw oops into the event. Even if classloader oops were somehow non-moving, the loader may not exist at the time the event is examined. David On 1/03/2013 9:24 AM, Calvin Cheung wrote: > This change is for adding the class load event tracing. > The event will include the following fields: > loaded class > defining class loader > initiating class loader > > webrev: http://cr.openjdk.java.net/~ccheung/8009174/webrev/ > > thanks, > Calvin From david.holmes at oracle.com Thu Feb 28 23:01:17 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Mar 2013 17:01:17 +1000 Subject: Please review: 8006498 and 8008474 In-Reply-To: <51300AE9.6080402@oracle.com> References: <5125448B.8090107@oracle.com> <5125685F.5070907@oracle.com> <51261EDD.2020309@oracle.com> <512633D5.6040202@oracle.com> <5126DF09.2040207@oracle.com> <5126E261.6080601@oracle.com> <5127822B.9090208@oracle.com> <512A9B5E.7040401@oracle.com> <512BAE75.5080800@oracle.com> <51300AE9.6080402@oracle.com> Message-ID: <5130523D.3010704@oracle.com> Looks good to me. Thanks, David On 1/03/2013 11:56 AM, JOSEPH PROVINO wrote: > Latest webrev is here: > http://cr.openjdk.java.net/~jprovino/8006498/webrev.01 > > joe > > > On 2/25/2013 1:33 PM, Mikael Vidstedt wrote: >> >> On 2/24/2013 2:59 PM, David Holmes wrote: >>> On 23/02/2013 12:35 AM, Joseph Provino wrote: >>>> On 02/21/2013 10:13 PM, David Holmes wrote: >>>>> On 22/02/2013 12:59 PM, David Holmes wrote: >>>>>> On 22/02/2013 12:48 AM, JOSEPH PROVINO wrote: >>>>>>> Actually, from looking at this again, I thought David was suggesting >>>>>>> that -Wundef >>>>>>> should be added to ACCEPTABLE_WARNINGS for linux and bsd. >>>>>> >>>>>> I was being ambivalent - I just wanted to see consistency. We >>>>>> should see >>>>>> where Mikael is adding -Wunused >>>>> >>>>> Ha! Now this really muddies the waters (this is linux only): >>>>> >>>>> ! ADDITIONAL_WARNINGS = -Wunused-function >>>>> ! >>>>> ! CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(ACCEPTABLE_WARNINGS) >>>>> $(ADDITIONAL_WARNINGS) >>>> >>>> That's the problem -- it's already inconsistent. >>> >>> The names do not make sense to me but perhaps I am misunderstanding >>> how this works. Are we listing all the warnings that will be errors, >>> or are we listing those warnings that we don't want to be errors? I'm >>> not understanding what acceptable nor additional are supposed to mean >>> here. >> >> I can't say that I see any real patterns in how these variables are >> used either. My guess is that at some point somebody figured out a few >> warnings that were "acceptable" - as in warnings that we could turn on >> without getting tons of false positives and incorrectly generated >> code, but that's just a guess. Unless somebody has insights around why >> these are named and split up the way they are I suggest that we >> simplify and unify all of it. >> >> My suggestion is to have all the warning flags go into a variable >> called WARNING_FLAGS, leaving only two variables: WARNINGS_ARE_ERRORS >> and WARNING_FLAGS. Something like this (for Linux, similar for Solaris): >> >> WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wunused-functions -Wundef >> >> # Since GCC 4.3, -Wconversion has changed its meanings to warn these >> implicit >> # conversions which might affect the values. To avoid that, we do not >> use it. >> ifeq "$(shell expr \( $(CC_VER_MAJOR) \> 4 \) \| \( \( $(CC_VER_MAJOR) >> = 4 \) \& \( $(CC_VER_MINOR) \>= 3 \) \))" "0" >> WARNING_FLAGS += -Wconversion >> endif >> >> CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) $(WARNING_FLAGS) >> >> Reasonable? >> >> Cheers, >> Mikael >> >> >>> >>> David >>> >>>> joe >>>> >>>>> >>>>> >>>>> David >>>>> >>>>>> >>>>>> David >>>>>> >>>>>>> joe >>>>>>> >>>>>>> On 2/21/2013 8:19 AM, Zhengyu Gu wrote: >>>>>>>> Agree with David, -Wundef should go to CFLAGS_WARN/DEFAULT on >>>>>>>> Solaris >>>>>>>> if there is not particular reason not to. >>>>>>>> >>>>>>>> Other than that, look good to me. >>>>>>>> >>>>>>>> -Zhengyu >>>>>>>> >>>>>>>> On 2/20/2013 7:20 PM, David Holmes wrote: >>>>>>>>> On 21/02/2013 7:47 AM, JOSEPH PROVINO wrote: >>>>>>>>>> 8006498: ASSERT and other symbols used incorrectly with #if are >>>>>>>>>> supposed to be defined or not >>>>>>>>>> >>>>>>>>>> 8008474: -Wundef should be added to the build to catch #if >>>>>>>>>> references >>>>>>>>>> to undefined macros. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Webrev is here: >>>>>>>>>> http://cr.openjdk.java.net/~jprovino/8006498/webrev.00/ >>>>>>>>> >>>>>>>>> On bsd and linux you simply added -Wundef directly to the CFLAGS: >>>>>>>>> >>>>>>>>> +CFLAGS_WARN/DEFAULT = $(WARNINGS_ARE_ERRORS) >>>>>>>>> $(ACCEPTABLE_WARNINGS) >>>>>>>>> -Wundef >>>>>>>>> >>>>>>>>> but on Solaris you added it to ADDITIONAL_WARNINGS: >>>>>>>>> >>>>>>>>> +ADDITIONAL_WARNINGS = -Wpointer-arith -Wconversion -Wsign-compare >>>>>>>>> -Wundef >>>>>>>>> >>>>>>>>> I guess it is a little confusing as to whether ACCEPTABLE_WARNINGS >>>>>>>>> and ADDITIONAL_WARNINGS are meant to be the same thing. >>>>>>>>> >>>>>>>>> Otherwise all the #if -> #ifdef etc seem okay. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> joe >>>>>>>> >>>>>>> >>>> >> > From staffan.larsen at oracle.com Thu Feb 28 23:37:11 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 1 Mar 2013 08:37:11 +0100 Subject: Review request: 8009174: add class load event tracing In-Reply-To: <51305177.7070302@oracle.com> References: <512FE73E.2020709@oracle.com> <51305177.7070302@oracle.com> Message-ID: <4BF5E080-8896-4090-A30B-EEA4494031C3@oracle.com> On 1 mar 2013, at 07:57, David Holmes wrote: > Hi Calvin, > > So this adds the code that would allow for the event tracing but it doesn't actually add the code that will do the event tracing ??? It does add the code that creates the event and pushes it into the event tracing framework. This is all that is required to add a new event to the event tracing. > Second problem: you can't store raw oops into the event. Even if classloader oops were somehow non-moving, the loader may not exist at the time the event is examined. You can store raw oops into the event. We take care to make sure they are never referenced after the commit() is called. /Staffan > > David > > On 1/03/2013 9:24 AM, Calvin Cheung wrote: >> This change is for adding the class load event tracing. >> The event will include the following fields: >> loaded class >> defining class loader >> initiating class loader >> >> webrev: http://cr.openjdk.java.net/~ccheung/8009174/webrev/ >> >> thanks, >> Calvin From staffan.larsen at oracle.com Thu Feb 28 23:37:35 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 1 Mar 2013 08:37:35 +0100 Subject: Review request: 8009174: add class load event tracing In-Reply-To: <512FE73E.2020709@oracle.com> References: <512FE73E.2020709@oracle.com> Message-ID: <9980C754-D305-41D0-93AA-02129FB0629C@oracle.com> Looks good. /Staffan On 1 mar 2013, at 00:24, Calvin Cheung wrote: > This change is for adding the class load event tracing. > The event will include the following fields: > loaded class > defining class loader > initiating class loader > > webrev: http://cr.openjdk.java.net/~ccheung/8009174/webrev/ > > thanks, > Calvin From vladimir.x.ivanov at oracle.com Thu Feb 28 23:51:53 2013 From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com) Date: Fri, 01 Mar 2013 07:51:53 +0000 Subject: hg: hsx/hotspot-main/hotspot: 6 new changesets Message-ID: <20130301075208.9BD7F4750B@hg.openjdk.java.net> Changeset: 6931f425c517 Author: roland Date: 2013-02-25 14:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6931f425c517 8007294: ReduceFieldZeroing doesn't check for dependent load and can lead to incorrect execution Summary: InitializeNode::can_capture_store() must check that the captured store doesn't overwrite a memory location that is loaded before the store. Reviewed-by: kvn ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/phaseX.cpp + test/compiler/8007294/Test8007294.java Changeset: 706c919d3b56 Author: roland Date: 2013-02-26 12:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/706c919d3b56 8007722: C2: "assert(tp->base() != Type::AnyPtr) failed: not a bare pointer" at machnode.cpp:376 Summary: GetAndSetP's MachNode should capture bottom type. Reviewed-by: kvn ! src/share/vm/adlc/formssel.cpp + test/compiler/8007722/Test8007722.java Changeset: a00ed9736260 Author: drchase Date: 2013-02-26 15:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a00ed9736260 8007776: Test6852078.java timeouts Summary: if more than 100 seconds and more than 100 iterations have both passed, then exit is allowed. Reviewed-by: kvn ! test/compiler/6852078/Test6852078.java Changeset: 133bf557ef77 Author: iignatyev Date: 2013-02-27 05:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/133bf557ef77 8007439: C2: adding successful message of inlining Reviewed-by: kvn, vlivanov ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/parse.hpp Changeset: b02157cd249f Author: vlivanov Date: 2013-02-27 08:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b02157cd249f Merge Changeset: 338da89b2592 Author: vlivanov Date: 2013-02-28 15:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/338da89b2592 Merge From david.holmes at oracle.com Thu Feb 28 23:59:28 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Mar 2013 17:59:28 +1000 Subject: Review request: 8009174: add class load event tracing In-Reply-To: <4BF5E080-8896-4090-A30B-EEA4494031C3@oracle.com> References: <512FE73E.2020709@oracle.com> <51305177.7070302@oracle.com> <4BF5E080-8896-4090-A30B-EEA4494031C3@oracle.com> Message-ID: <51305FE0.8080701@oracle.com> On 1/03/2013 5:37 PM, Staffan Larsen wrote: > > On 1 mar 2013, at 07:57, David Holmes wrote: > >> Hi Calvin, >> >> So this adds the code that would allow for the event tracing but it doesn't actually add the code that will do the event tracing ??? > > It does add the code that creates the event and pushes it into the event tracing framework. This is all that is required to add a new event to the event tracing. Now that was weird. When I loaded the webrev the systemDictionary.cpp change stopped just after the post_class_load_event method. I didn't see the changes that used the post_class_load_event method. So now that I can see them ... the event is being recorded prematurely: 816 // If everything was OK (no exceptions, no null return value), 817 // post a class load event. 818 if (!HAS_PENDING_EXCEPTION && !k.is_null()) { 819 // post class load event 820 post_class_load_event(starttime, k, class_loader); 821 822 // class_loader is NOT the defining loader, do a little more bookkeeping. 823 if (k->class_loader() != class_loader()) { 824 825 check_constraints(d_index, d_hash, k, class_loader, false, THREAD); 826 827 // Need to check for a PENDING_EXCEPTION again; check_constraints 828 // can throw and doesn't use the CHECK macro. The class isn't really loaded until it has passed the loader constraint check. And later the protection domain validation check could fail. >> Second problem: you can't store raw oops into the event. Even if classloader oops were somehow non-moving, the loader may not exist at the time the event is examined. > > You can store raw oops into the event. We take care to make sure they are never referenced after the commit() is called. Sorry I misread the code. You don't store the loader oop you store the klass() - so this just records the type of the Loader rather than identifying the actual instance. What do you do with these values - just treat them as addresses that you print? (Same question if you store oops - what can you do with an oop you can't reference?) David > /Staffan > >> >> David >> >> On 1/03/2013 9:24 AM, Calvin Cheung wrote: >>> This change is for adding the class load event tracing. >>> The event will include the following fields: >>> loaded class >>> defining class loader >>> initiating class loader >>> >>> webrev: http://cr.openjdk.java.net/~ccheung/8009174/webrev/ >>> >>> thanks, >>> Calvin >