From serguei.spitsyn at oracle.com Fri Aug 1 00:29:27 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 31 Jul 2014 17:29:27 -0700 Subject: RFR (S) 7187999: dtrace jstack action is broken Message-ID: <53DADF67.1040508@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-7187999 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/7187999-dtrace.1 Summary: The DTrace jstack action support was broken for several years. The issue came when the build flag -Xlazyload was added by request from the Solaris team. This flag was necessary to resolve a performance issue. The jstack action stopped working as the jhelper.d was loaded lazily as well. The idea of this fix was suggested by Junsang Cho from the Solaris team. The jhelper.d and hotspot probes (other USDT scripts) are separated into two different SUNW_DOF sections. Now the jhelper.d is built without the -Xlazyload flag. Testing: Running the adhoc dtrace tests on Solaris sparcv9 and amd64 Thanks, Serguei From david.holmes at oracle.com Fri Aug 1 07:23:47 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Aug 2014 17:23:47 +1000 Subject: RFR (S) 7187999: dtrace jstack action is broken In-Reply-To: <53DADF67.1040508@oracle.com> References: <53DADF67.1040508@oracle.com> Message-ID: <53DB4083.7090204@oracle.com> Hi Serguei, This seems reasonable. One nit: 355 $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -G -o $@ -s $(DTRACE_JHELPER).d There should be a $(QUIETLY) in front of that. Also the copyright year needs updating. Thanks, David On 1/08/2014 10:29 AM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-7187999 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/7187999-dtrace.1 > > > Summary: > > The DTrace jstack action support was broken for several years. > The issue came when the build flag -Xlazyload was added by request > from the Solaris team. > This flag was necessary to resolve a performance issue. > The jstack action stopped working as the jhelper.d was loaded lazily > as well. > > The idea of this fix was suggested by Junsang Cho from the Solaris team. > The jhelper.d and hotspot probes (other USDT scripts) are separated > into two different SUNW_DOF sections. > Now the jhelper.d is built without the -Xlazyload flag. > > Testing: > Running the adhoc dtrace tests on Solaris sparcv9 and amd64 > > > Thanks, > Serguei From serguei.spitsyn at oracle.com Fri Aug 1 08:15:32 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 01 Aug 2014 01:15:32 -0700 Subject: RFR (S) 7187999: dtrace jstack action is broken In-Reply-To: <53DB4083.7090204@oracle.com> References: <53DADF67.1040508@oracle.com> <53DB4083.7090204@oracle.com> Message-ID: <53DB4CA4.9050108@oracle.com> Hi David, I'll fix this. Thank you for the review! Serguei On 8/1/14 12:23 AM, David Holmes wrote: > Hi Serguei, > > This seems reasonable. One nit: > > 355 $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -G -o $@ -s > $(DTRACE_JHELPER).d > > There should be a $(QUIETLY) in front of that. > > Also the copyright year needs updating. > > Thanks, > David > > On 1/08/2014 10:29 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-7187999 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/7187999-dtrace.1 >> >> >> >> Summary: >> >> The DTrace jstack action support was broken for several years. >> The issue came when the build flag -Xlazyload was added by request >> from the Solaris team. >> This flag was necessary to resolve a performance issue. >> The jstack action stopped working as the jhelper.d was loaded lazily >> as well. >> >> The idea of this fix was suggested by Junsang Cho from the Solaris >> team. >> The jhelper.d and hotspot probes (other USDT scripts) are separated >> into two different SUNW_DOF sections. >> Now the jhelper.d is built without the -Xlazyload flag. >> >> Testing: >> Running the adhoc dtrace tests on Solaris sparcv9 and amd64 >> >> >> Thanks, >> Serguei From dmitry.samersoff at oracle.com Fri Aug 1 08:25:43 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 01 Aug 2014 12:25:43 +0400 Subject: RFR (S) 7187999: dtrace jstack action is broken In-Reply-To: <53DADF67.1040508@oracle.com> References: <53DADF67.1040508@oracle.com> Message-ID: <53DB4F07.10504@oracle.com> Serguei, Looks good for me. Could you put comments below into makefile? -Dmitry On 2014-08-01 04:29, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-7187999 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/7187999-dtrace.1 > > > Summary: > > The DTrace jstack action support was broken for several years. > The issue came when the build flag -Xlazyload was added by request > from the Solaris team. > This flag was necessary to resolve a performance issue. > The jstack action stopped working as the jhelper.d was loaded lazily > as well. > > The idea of this fix was suggested by Junsang Cho from the Solaris team. > The jhelper.d and hotspot probes (other USDT scripts) are separated > into two different SUNW_DOF sections. > Now the jhelper.d is built without the -Xlazyload flag. > > Testing: > Running the adhoc dtrace tests on Solaris sparcv9 and amd64 > > > Thanks, > Serguei -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Fri Aug 1 08:41:49 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 01 Aug 2014 01:41:49 -0700 Subject: RFR (S) 7187999: dtrace jstack action is broken In-Reply-To: <53DB4F07.10504@oracle.com> References: <53DADF67.1040508@oracle.com> <53DB4F07.10504@oracle.com> Message-ID: <53DB52CD.9020104@oracle.com> Dmitry, I'll add a part of the comment into make file. Thank you for the review! Serguei On 8/1/14 1:25 AM, Dmitry Samersoff wrote: > Serguei, > > Looks good for me. > > Could you put comments below into makefile? > > -Dmitry > > On 2014-08-01 04:29, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-7187999 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/7187999-dtrace.1 >> >> >> Summary: >> >> The DTrace jstack action support was broken for several years. >> The issue came when the build flag -Xlazyload was added by request >> from the Solaris team. >> This flag was necessary to resolve a performance issue. >> The jstack action stopped working as the jhelper.d was loaded lazily >> as well. >> >> The idea of this fix was suggested by Junsang Cho from the Solaris team. >> The jhelper.d and hotspot probes (other USDT scripts) are separated >> into two different SUNW_DOF sections. >> Now the jhelper.d is built without the -Xlazyload flag. >> >> Testing: >> Running the adhoc dtrace tests on Solaris sparcv9 and amd64 >> >> >> Thanks, >> Serguei > From christian.tornqvist at oracle.com Fri Aug 1 11:29:53 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Fri, 1 Aug 2014 07:29:53 -0400 Subject: RFR(S) : 8051896 : jtreg tests don't use $TESTJAVAOPTS In-Reply-To: <53D82ADF.2020905@oracle.com> References: <53D14A95.5010009@oracle.com> <53D14DF4.2040702@oracle.com> <53D16E74.6090504@oracle.com> <53D17CCC.5010908@oracle.com> <53D82ADF.2020905@oracle.com> Message-ID: <00b401cfad7b$ea782a00$bf687e00$@oracle.com> Hi Igor, The test/runtime/7162488/Test7162488.sh shouldn't be passing on options at all, the test will fail if someone passed in -XX:+IgnoreUnrecognizedVMOptions (which is done in our testing). Otherwise the change looks good. Thanks, Christian -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Igor Ignatyev Sent: Tuesday, July 29, 2014 7:15 PM To: hotspot-runtime-dev Cc: hotspot-dev developers Subject: Re: RFR(S) : 8051896 : jtreg tests don't use $TESTJAVAOPTS Can I have a 2nd review of this changes? I'd prefer to get it from someone from runtime team, since there are several runtime tests are touched. updated webrev: http://cr.openjdk.java.net/~iignatyev/8051896/webrev.02/ Igor On 07/25/2014 01:38 AM, Vladimir Kozlov wrote: > The order of flags on command line is important. I think TESTJAVAOPTS > should be last to take priority: > > TESTOPTS="${TESTVMOPTS} ${TESTJAVAOPTS}" > > Please, add copyright headers to files in compiler/6894807. > > Otherwise look good. > > Thanks, > Vladimir > > On 7/24/14 1:37 PM, Igor Ignatyev wrote: >> // was Re: RFR(XS) : 8051896 : compiler/ciReplay tests don't use >> $TESTJAVAOPTS: >> >> updated webrev: >> http://cr.openjdk.java.net/~iignatyev/8051896/webrev.01/ >> 93 lines changed: 15 ins; 40 del; 38 mod; >> >> On 07/24/2014 10:18 PM, Vladimir Kozlov wrote: >>> Looks good. >>> >>> Is not this a general problem for all our tests? They use only >>> TESTVMOPTS. >> Yeap, it's a general problem, I've updated all tests. >> I thought jtreg merges TESTVMOPTS and TESTJAVAOPTS flags >>> together. >>> >>> Thanks, >>> Vladimir >>> >>> On 7/24/14 11:04 AM, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev/8051896/webrev.00/ >>>> 12 lines changed: 2 ins; 0 del; 10 mod >>>> >>>> Hi all, >>>> >>>> Please review patch: >>>> >>>> Problem: >>>> the tests use only TESTVMOPTS, but jtreg propagates some flags by >>>> TESTJAVAOPTS variable >>>> >>>> Fix: >>>> usages of TESTVMOPTS were replaced by TESTOPTS which is initialized >>>> as concatenated values of TESTVMOPTS and TESTJAVAOPTS >>>> >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8051896 >>>> testing: jprt From igor.ignatyev at oracle.com Sun Aug 3 06:26:05 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sun, 03 Aug 2014 10:26:05 +0400 Subject: [8u40] Request for approval: backports of 8029070(XS), 8038756(S) Message-ID: <53DDD5FD.2070907@oracle.com> Hi all, I would like to request backports of fixes for JDK-8029070[1-3] and JDK-8038756[4-6] to 8u40. The original patches were applied cleanly. testing: jprt [1] https://bugs.openjdk.java.net/browse/JDK-8029070 [2] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6c583aa36bc9 [3] http://cr.openjdk.java.net/~iignatyev/8029070/webrev.01/ [4] https://bugs.openjdk.java.net/browse/JDK-8038756 [5] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7daf195e6193 [6] http://cr.openjdk.java.net/~iignatyev/8038756/webrev.00/ Thanks, Igor From david.holmes at oracle.com Sun Aug 3 23:51:15 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 04 Aug 2014 09:51:15 +1000 Subject: MemNode::unordered/release/acquire use in relation to volatile stores and loads Message-ID: <53DECAF3.4010203@oracle.com> In ./share/vm/opto/library_call.cpp Why is it that for volatile stores we have special checks for which MemNode to use: MemNode::MemOrd mo = is_volatile ? MemNode::release : MemNode::unordered; if (type != T_OBJECT ) { (void) store_to_memory(control(), adr, val, type, adr_type, mo, is_volatile); } else { but for loads it is always unordered eg: Node* p = make_load(control(), adr, value_type, type, adr_type, MemNode::unordered, is_volatile); ?? I would have expected MemNode::acquire as in opto/parse3.cpp // Build the load. // MemNode::MemOrd mo = is_vol ? MemNode::acquire : MemNode::unordered; bool needs_atomic_access = is_vol || AlwaysAtomicAccesses; Node* ld = make_load(NULL, adr, type, bt, adr_type, mo, needs_atomic_access); Thanks, David From sgehwolf at redhat.com Mon Aug 4 11:33:09 2014 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 04 Aug 2014 13:33:09 +0200 Subject: [9] Fix for JDK-8032045 breaks fastdebug/slowdebug builds on Linux (Fedora 20) Message-ID: <1407151989.3128.32.camel@localhost.localdomain> Hi, Vanilla debug builds of the hs-comp tree[1] fails for me on Fedora 20 with glibc-headers version 2.18. Release builds work fine. Any "slowdebug" or "fastdebug" build of an openjdk 9 tree, however, fail with: /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DASSERT -I. -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/prims -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/precompiled -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/cpu/x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/os_cpu/linux_x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/os/linux/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/os/posix/vm -I../generated '-DHOTSPOT_BUILD_USER="sgehwolf"' '-DHOTSPOT_LIB_ARCH="amd64"' '-DHOTSPOT_VM_DISTRO="OpenJDK"' -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -g -fno-omit-frame-pointer -O0 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-all --param ssp-buffer-size=1 -D_NMT_NOINLINE_ -DVM_LITTLE_ENDIAN -D_LP64=1 -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -Wformat=2 -DDTRACE_ENABLED -c -MMD -MP -MF ../generated/dependencies/precompiled.hpp.gch.d -fpch-deps -x c++-header /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/precompiled/precompiled.hpp -o precompiled.hpp.gch In file included from /usr/include/stdio.h:27:0, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/prims/jni.h:39, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/utilities/globalDefinitions_gcc.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/utilities/globalDefinitions.hpp:33, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/utilities/debug.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/runtime/globals.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/memory/allocation.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/memory/iterator.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/memory/genOopClosures.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/oops/klass.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/runtime/handles.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/memory/universe.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/code/oopRecorder.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/asm/codeBuffer.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/asm/assembler.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/precompiled/precompiled.hpp:29: /usr/include/features.h:327:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp] # warning _FORTIFY_SOURCE requires compiling with optimization (-O) ^ cc1plus: all warnings being treated as errors It appears the change which introduced this was: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/d8d7bf7dcaba Related bug is: https://bugs.openjdk.java.net/browse/JDK-8032045 I see this in /usr/include/features.h around line 327: #if defined _FORTIFY_SOURCE && _FORTIFY_SOURCE > 0 # if !defined __OPTIMIZE__ || __OPTIMIZE__ <= 0 # warning _FORTIFY_SOURCE requires compiling with optimization (-O) # elif !__GNUC_PREREQ (4, 1) The GCC version used for building is 4.8.3. It seems line 374 in make/linux/makefiles/gcc.make is breaking F20 debug builds. Thoughts? Thanks, Severin [1] http://hg.openjdk.java.net/jdk9/hs-comp From david.holmes at oracle.com Mon Aug 4 11:49:27 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 04 Aug 2014 21:49:27 +1000 Subject: [9] Fix for JDK-8032045 breaks fastdebug/slowdebug builds on Linux (Fedora 20) In-Reply-To: <1407151989.3128.32.camel@localhost.localdomain> References: <1407151989.3128.32.camel@localhost.localdomain> Message-ID: <53DF7347.4060704@oracle.com> Hi Severin, Known issue - please see: http://mail.openjdk.java.net/pipermail/build-dev/2014-July/012900.html David On 4/08/2014 9:33 PM, Severin Gehwolf wrote: > Hi, > > Vanilla debug builds of the hs-comp tree[1] fails for me on Fedora 20 > with glibc-headers version 2.18. Release builds work fine. Any > "slowdebug" or "fastdebug" build of an openjdk 9 tree, however, fail > with: > > /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DASSERT -I. > -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/prims -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/precompiled -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/cpu/x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/os_cpu/linux_x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/os/linux/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/os/posix/vm -I../generated '-DHOTSPOT_BUILD_USER="sgehwolf"' '-DHOTSPOT_LIB_ARCH="amd64"' '-DHOTSPOT_VM_DISTRO="OpenJDK"' -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fP! IC -fno- rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -g -fno-omit-frame-pointer -O0 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-all --param ssp-buffer-size=1 -D_NMT_NOINLINE_ -DVM_LITTLE_ENDIAN -D_LP64=1 -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -Wformat=2 -DDTRACE_ENABLED -c -MMD -MP -MF ../generated/dependencies/precompiled.hpp.gch.d -fpch-deps -x c++-header /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/precompiled/precompiled.hpp -o precompiled.hpp.gch > > In file included from /usr/include/stdio.h:27:0, > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/prims/jni.h:39, > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/utilities/globalDefinitions_gcc.hpp:28, > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/utilities/globalDefinitions.hpp:33, > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/utilities/debug.hpp:28, > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/runtime/globals.hpp:28, > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/memory/allocation.hpp:28, > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/memory/iterator.hpp:28, > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/memory/genOopClosures.hpp:28, > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/oops/klass.hpp:28, > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/runtime/handles.hpp:28, > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/memory/universe.hpp:28, > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/code/oopRecorder.hpp:28, > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/asm/codeBuffer.hpp:28, > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/asm/assembler.hpp:28, > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/precompiled/precompiled.hpp:29: > /usr/include/features.h:327:4: error: #warning _FORTIFY_SOURCE requires > compiling with optimization (-O) [-Werror=cpp] > # warning _FORTIFY_SOURCE requires compiling with optimization (-O) > ^ > cc1plus: all warnings being treated as errors > > It appears the change which introduced this was: > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/d8d7bf7dcaba > > Related bug is: > https://bugs.openjdk.java.net/browse/JDK-8032045 > > I see this in /usr/include/features.h around line 327: > > #if defined _FORTIFY_SOURCE && _FORTIFY_SOURCE > 0 > # if !defined __OPTIMIZE__ || __OPTIMIZE__ <= 0 > # warning _FORTIFY_SOURCE requires compiling with optimization (-O) > # elif !__GNUC_PREREQ (4, 1) > > The GCC version used for building is 4.8.3. It seems line 374 in > make/linux/makefiles/gcc.make is breaking F20 debug builds. > > Thoughts? > > Thanks, > Severin > > [1] http://hg.openjdk.java.net/jdk9/hs-comp > From sgehwolf at redhat.com Mon Aug 4 11:54:20 2014 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 04 Aug 2014 13:54:20 +0200 Subject: [9] Fix for JDK-8032045 breaks fastdebug/slowdebug builds on Linux (Fedora 20) In-Reply-To: <53DF7347.4060704@oracle.com> References: <1407151989.3128.32.camel@localhost.localdomain> <53DF7347.4060704@oracle.com> Message-ID: <1407153260.3128.34.camel@localhost.localdomain> Hi David, On Mon, 2014-08-04 at 21:49 +1000, David Holmes wrote: > Hi Severin, > > Known issue - please see: > > http://mail.openjdk.java.net/pipermail/build-dev/2014-July/012900.html Thanks for the pointer! Cheers, Severin > David > > On 4/08/2014 9:33 PM, Severin Gehwolf wrote: > > Hi, > > > > Vanilla debug builds of the hs-comp tree[1] fails for me on Fedora 20 > > with glibc-headers version 2.18. Release builds work fine. Any > > "slowdebug" or "fastdebug" build of an openjdk 9 tree, however, fail > > with: > > > > /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DASSERT -I. > > -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/prims -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/precompiled -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/cpu/x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/os_cpu/linux_x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/os/linux/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/os/posix/vm -I../generated '-DHOTSPOT_BUILD_USER="sgehwolf"' '-DHOTSPOT_LIB_ARCH="amd64"' '-DHOTSPOT_VM_DISTRO="OpenJDK"' -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -! fP! > IC -fno- > rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -g -fno-omit-frame-pointer -O0 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-all --param ssp-buffer-size=1 -D_NMT_NOINLINE_ -DVM_LITTLE_ENDIAN -D_LP64=1 -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -Wformat=2 -DDTRACE_ENABLED -c -MMD -MP -MF ../generated/dependencies/precompiled.hpp.gch.d -fpch-deps -x c++-header /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/precompiled/precompiled.hpp -o precompiled.hpp.gch > > > > In file included from /usr/include/stdio.h:27:0, > > > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/prims/jni.h:39, > > > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/utilities/globalDefinitions_gcc.hpp:28, > > > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/utilities/globalDefinitions.hpp:33, > > > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/utilities/debug.hpp:28, > > > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/runtime/globals.hpp:28, > > > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/memory/allocation.hpp:28, > > > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/memory/iterator.hpp:28, > > > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/memory/genOopClosures.hpp:28, > > > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/oops/klass.hpp:28, > > > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/runtime/handles.hpp:28, > > > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/memory/universe.hpp:28, > > > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/code/oopRecorder.hpp:28, > > > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/asm/codeBuffer.hpp:28, > > > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/asm/assembler.hpp:28, > > > > from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/precompiled/precompiled.hpp:29: > > /usr/include/features.h:327:4: error: #warning _FORTIFY_SOURCE requires > > compiling with optimization (-O) [-Werror=cpp] > > # warning _FORTIFY_SOURCE requires compiling with optimization (-O) > > ^ > > cc1plus: all warnings being treated as errors > > > > It appears the change which introduced this was: > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/d8d7bf7dcaba > > > > Related bug is: > > https://bugs.openjdk.java.net/browse/JDK-8032045 > > > > I see this in /usr/include/features.h around line 327: > > > > #if defined _FORTIFY_SOURCE && _FORTIFY_SOURCE > 0 > > # if !defined __OPTIMIZE__ || __OPTIMIZE__ <= 0 > > # warning _FORTIFY_SOURCE requires compiling with optimization (-O) > > # elif !__GNUC_PREREQ (4, 1) > > > > The GCC version used for building is 4.8.3. It seems line 374 in > > make/linux/makefiles/gcc.make is breaking F20 debug builds. > > > > Thoughts? > > > > Thanks, > > Severin > > > > [1] http://hg.openjdk.java.net/jdk9/hs-comp > > From zoltan.majo at oracle.com Mon Aug 4 13:28:14 2014 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 04 Aug 2014 15:28:14 +0200 Subject: [9] RFR(S): 8054013: run hotspot JTREG compiler tests only on fastdebug platforms and also on macosx Message-ID: <53DF8A6E.9020704@oracle.com> Hi, please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8054013 Problem: JTREG tests are currently run on both fastdebug and product platforms. To reduce execution time, only fastdebug should be used. JTREG test should be executed on the platform macosx_x64* as well. Solution: Modify both hotspot/make/jprt.properties and the make/jprt.properties file on the top level to add/remove the relevant platforms. Webrev: (top-level): http://cr.openjdk.java.net/~thartmann/8054013/webrev.00/top/ (hotspot): http://cr.openjdk.java.net/~thartmann/8054013/webrev.00/hotspot/ Testing: Executed all hotspot_comp* targets from within both directories (top-level and hotspot). Thank you and best regards, Zoltan From xerox.time.tech at gmail.com Mon Aug 4 15:45:22 2014 From: xerox.time.tech at gmail.com (Xin Tong) Date: Mon, 4 Aug 2014 10:45:22 -0500 Subject: synonyms and homonyms on java heaps Message-ID: I would like to know whether synonyms and homonyms can happen on the OpenJDK java heaps ? Synonyms are mainly used among multiple processes and homonyms occur when a single virtual address is associated with multiple address spaces. are there any use cases for synonyms and homonyms on the java heap ? Xin From sgehwolf at redhat.com Mon Aug 4 15:50:06 2014 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 04 Aug 2014 17:50:06 +0200 Subject: [9] RFR: JI-9039953 zero variant build is broken. Message-ID: <1407167406.3128.53.camel@localhost.localdomain> Hi, Building a zero variant of hotspot fails for the latest hs-comp tree with ("release"-type build): src/cpu/zero/vm/frame_zero.inline.hpp:59:11: error: ?CodeCache? has not been declared It appears to have been caused by a change of header files (perhaps [1]?). A file which used to be included implicitly does not seem to be included any longer. An explicit include fixes the problem. [2] shows the build failure. I would need a proper JDK bug and a sponsor for this change. An initial bug has been submitted as JI-9039953 via the web interface. Webrev is here: https://jerboaa.fedorapeople.org/bugs/openjdk/JI-9039953/webrev.01/ Thanks, Severin [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/22b98ab2a69f [2] http://builder.classpath.org/jenkins/job/OpenJDK9_hscomp_Zero/47/console From sgehwolf at redhat.com Mon Aug 4 16:11:18 2014 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 04 Aug 2014 18:11:18 +0200 Subject: RFR: 8046765: (s) disable FORTIFY_SOURCE for files with optimization disabled. In-Reply-To: <3F7746F6-B85B-4DFF-95AF-60B442569806@oracle.com> References: <3F7746F6-B85B-4DFF-95AF-60B442569806@oracle.com> Message-ID: <1407168678.3128.60.camel@localhost.localdomain> Hi, On Wed, 2014-07-16 at 10:13 -0700, Mike Duigou wrote: > Hello all; > > In some GCC distributions the FORTIFY_SOURCE option is incompatible > with the -O0. This change disables FORTIFY sources for the files we > know have optimizations disabled. > > jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047952 > webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047952/0/webrev/ > > Unfortunately I don't have a Fedora 19 setup to test the change on the > reported platform but I did verify that the compiler command line is > correct, that fortify is disabled and the resulting build still works > on a number of platforms. Additional verifications on other platforms > is encouraged. As for additional verification: I'm seeing the build failure on Fedora 20. With the webrev patch applied the build still fails for me. /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/make/linux/makefiles/vm.make:289: Building precompiled.hpp.gch /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DASSERT -I. -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/prims -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/precompiled -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/cpu/x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/os_cpu/linux_x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/os/linux/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_BUILD_USER="\"sgehwolf\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -g -fno-omit-frame-pointer -O0 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-all --param ssp-buffer-size=1 -D_NMT_NOINLINE_ -DVM_LITTLE_ENDIAN -D_LP64=1 -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -Wformat=2 -DDTRACE_ENABLED -c -MMD -MP -MF ../generated/dependencies/precompiled.hpp.gch.d -fpch-deps -x c++-header /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/precompiled/precompiled.hpp -o precompiled.hpp.gch + /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DASSERT -I. -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/prims -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/precompiled -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/cpu/x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/os_cpu/linux_x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/os/linux/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/os/posix/vm -I../generated '-DHOTSPOT_BUILD_USER="sgehwolf"' '-DHOTSPOT_LIB_ARCH="amd64"' '-DHOTSPOT_VM_DISTRO="OpenJDK"' -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -pipe -fno-strict-aliasing -g -fno-omit-frame-pointer -O0 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-all --param ssp-buffer-size=1 -D_NMT_NOINLINE_ -DVM_LITTLE_ENDIAN -D_LP64=1 -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -Wformat=2 -DDTRACE_ENABLED -c -MMD -MP -MF ../generated/dependencies/precompiled.hpp.gch.d -fpch-deps -x c++-header /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/precompiled/precompiled.hpp -o precompiled.hpp.gch In file included from /usr/include/stdio.h:27:0, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/prims/jni.h:39, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/utilities/globalDefinitions_gcc.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/utilities/globalDefinitions.hpp:33, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/utilities/debug.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/runtime/globals.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/memory/allocation.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/memory/iterator.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/memory/genOopClosures.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/oops/klass.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/runtime/handles.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/memory/universe.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/code/oopRecorder.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/asm/codeBuffer.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/asm/assembler.hpp:28, from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev-hs-comp/hotspot/src/share/vm/precompiled/precompiled.hpp:29: /usr/include/features.h:327:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp] # warning _FORTIFY_SOURCE requires compiling with optimization (-O) ^ The mentioned bug in $subject should be 8047952, *not* 8046765, I think. JDK-8050803 is also a potential duplicate. FWIW, the proposed patch in the following thread works for me: http://mail.openjdk.java.net/pipermail/build-dev/2014-July/012900.html Cheers, Severin From dan at danny.cz Mon Aug 4 16:18:47 2014 From: dan at danny.cz (Dan =?UTF-8?B?SG9yw6Fr?=) Date: Mon, 4 Aug 2014 18:18:47 +0200 Subject: [9] RFR: JI-9039953 zero variant build is broken. In-Reply-To: <1407167406.3128.53.camel@localhost.localdomain> References: <1407167406.3128.53.camel@localhost.localdomain> Message-ID: <20140804181847.7d4082c445e7b999005817a1@danny.cz> On Mon, 04 Aug 2014 17:50:06 +0200 Severin Gehwolf wrote: > Hi, > > Building a zero variant of hotspot fails for the latest hs-comp tree > with ("release"-type build): > src/cpu/zero/vm/frame_zero.inline.hpp:59:11: error: ?CodeCache? has > not been declared oh, I'm sure I've already seen it, IIRC it is caused when you build with (or without?) precompiled headers Dan > It appears to have been caused by a change of header files (perhaps > [1]?). A file which used to be included implicitly does not seem to be > included any longer. An explicit include fixes the problem. > > [2] shows the build failure. > > I would need a proper JDK bug and a sponsor for this change. An > initial bug has been submitted as JI-9039953 via the web interface. > > Webrev is here: > https://jerboaa.fedorapeople.org/bugs/openjdk/JI-9039953/webrev.01/ > > Thanks, > Severin > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/22b98ab2a69f > [2] > http://builder.classpath.org/jenkins/job/OpenJDK9_hscomp_Zero/47/console > From vladimir.kozlov at oracle.com Mon Aug 4 16:54:07 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 04 Aug 2014 09:54:07 -0700 Subject: [9] RFR(S): 8054013: run hotspot JTREG compiler tests only on fastdebug platforms and also on macosx In-Reply-To: <53DF8A6E.9020704@oracle.com> References: <53DF8A6E.9020704@oracle.com> Message-ID: <53DFBAAF.3030904@oracle.com> Looks good. Thanks, Vladimir On 8/4/14 6:28 AM, Zolt?n Maj? wrote: > Hi, > > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8054013 > > Problem: JTREG tests are currently run on both fastdebug and product platforms. To reduce execution time, only fastdebug > should be used. JTREG test should be executed on the platform macosx_x64* as well. > > Solution: Modify both hotspot/make/jprt.properties and the make/jprt.properties file on the top level to add/remove the > relevant platforms. > > Webrev: > > (top-level): http://cr.openjdk.java.net/~thartmann/8054013/webrev.00/top/ > (hotspot): http://cr.openjdk.java.net/~thartmann/8054013/webrev.00/hotspot/ > > Testing: Executed all hotspot_comp* targets from within both directories (top-level and hotspot). > > Thank you and best regards, > > > Zoltan > From coleen.phillimore at oracle.com Mon Aug 4 17:48:18 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 04 Aug 2014 13:48:18 -0400 Subject: [9] RFR: JI-9039953 zero variant build is broken. In-Reply-To: <1407167406.3128.53.camel@localhost.localdomain> References: <1407167406.3128.53.camel@localhost.localdomain> Message-ID: <53DFC762.2070100@oracle.com> Hi, Did you try to build fastdebug? I found 2 more compilation errors when I did that. http://cr.openjdk.java.net/~coleenp/8003426/src/cpu/zero/vm/cppInterpreter_zero.cpp.udiff.html http://cr.openjdk.java.net/~coleenp/8003426/src/share/vm/interpreter/bytecodeInterpreter.cpp.udiff.html Although the last one could be due to the version of gcc I was using (not sure). Coleen On 8/4/14, 11:50 AM, Severin Gehwolf wrote: > Hi, > > Building a zero variant of hotspot fails for the latest hs-comp tree > with ("release"-type build): > src/cpu/zero/vm/frame_zero.inline.hpp:59:11: error: ?CodeCache? has not > been declared > > It appears to have been caused by a change of header files (perhaps > [1]?). A file which used to be included implicitly does not seem to be > included any longer. An explicit include fixes the problem. > > [2] shows the build failure. > > I would need a proper JDK bug and a sponsor for this change. An initial > bug has been submitted as JI-9039953 via the web interface. > > Webrev is here: > https://jerboaa.fedorapeople.org/bugs/openjdk/JI-9039953/webrev.01/ > > Thanks, > Severin > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/22b98ab2a69f > [2] > http://builder.classpath.org/jenkins/job/OpenJDK9_hscomp_Zero/47/console > From zhengyu.gu at oracle.com Mon Aug 4 18:22:37 2014 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Mon, 04 Aug 2014 14:22:37 -0400 Subject: Updated: RFR(L) 8046598: Scalable Native memory tracking development In-Reply-To: <53C58B14.9010003@oracle.com> References: <53C58B14.9010003@oracle.com> Message-ID: <53DFCF6D.20903@oracle.com> The update is based on code review meetings with Coleen, Christian, George and Harold. http://cr.openjdk.java.net/~zgu/8046598/webrev.01/ Thanks, -Zhengyu On 7/15/2014 4:12 PM, Zhengyu Gu wrote: > This is an update to previous RFR 8028541: Native Memory Tracking > enhancement, the original one is closed as duplicate of current one. > > The update is mainly based on feedback from Coleen and Christian: > - Refactored MemReporter to break up some large functions and > eliminate duplicated code. > - Minor change to MemBaseline for eliminating duplicated code. > - Changed MEMFLAGS type from unsigned short => MemoryType. > > Also added unit tests for LinkedList. > > The note from RFR 8028541: > ========================= > This is significant rework of native memory tracking introduced in > earlier releases. > > The goal of this enhancement is to improve scalability, from both > tracking memory and CPU usage perspectives, so it can scale well with > increased memory allocation in large applications. > > The enhancement is mainly focused on malloc memory tracking, whose > activities are several magnitude higher than virtual memory, and was > the main bottleneck in early implementation. > > Instead of using book keeping records for tracking malloc activities, > new implementation co-locates tracking data along side with user data > by using a prefixed header. The header size is 8 bytes on 32-bit > systems and 16 bytes on 64-bit systems, which ensure that user data > also align properly. > > Virtual memory tracking still uses book keeping records, and > ThreadCritical lock is always acquired to alter the records and > related data structures. > > Summary tracking data is maintained in static data structures, via > atomic operations. Malloc detail tracking call stacks are maintained > in a lock free hashtable. > > The key improvements: > 1. Up-to-date tracking report. > 2. Detail tracking now shows multiple call frames. Number of frames > is compilation time decision, currently default to 4. > 3. Malloc tracking is lock free. > 4. Tracking summary is reported in hs_err file when native memory > tracking is enabled. > 5. Query is faster, uses little memory and need a very little process. > > The drawback is that, malloc tracking header is always needed if > native memory tracking has ever been enabled, even after tracking is > shutdown. > > Impacts: > The most noticeable impact for JVM developers, is that Arena now > also take memory type as constructor parameter, besides the new > operators. > Arena* a = new (mtCode) Arena() => Arena* a = new (mtCode) > Arena(mtCode) > > The webrev shows modification of about 60 files, but most of them are > due to tracking API changes, mainly due to tracking stack, now, is an > object, vs. a single pc. > > The most important files for this implementations are: > > memTracker.hpp/cpp > mallocTracker.hpp/cpp and mallocTracker.inline.hpp > virtualMemoryTracker.hpp/cpp > mallocSiteTable.hpp/cpp > > allocationSite.hpp > nativeCallStack.hpp/cpp > linkedlist.hpp > > > Tests: > - JPRT > - NMT test suite > - vm.quick.testlist > - Kitchensink stability test for 16+ days > - FMW > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8046598 > Webrev: http://cr.openjdk.java.net/~zgu/8046598/webrev.00/ > > > > > Thanks, > > -Zhengyu > From vladimir.kozlov at oracle.com Mon Aug 4 21:13:39 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 04 Aug 2014 14:13:39 -0700 Subject: MemNode::unordered/release/acquire use in relation to volatile stores and loads In-Reply-To: <53DECAF3.4010203@oracle.com> References: <53DECAF3.4010203@oracle.com> Message-ID: <53DFF783.2020703@oracle.com> I would say that you are correct (MemNode::acquire is needed for volatile load). Lets hear Goetz answer. Thanks, Vladimir On 8/3/14 4:51 PM, David Holmes wrote: > In ./share/vm/opto/library_call.cpp > > Why is it that for volatile stores we have special checks for which > MemNode to use: > > MemNode::MemOrd mo = is_volatile ? MemNode::release : > MemNode::unordered; > if (type != T_OBJECT ) { > (void) store_to_memory(control(), adr, val, type, adr_type, mo, > is_volatile); > } else { > > but for loads it is always unordered eg: > > Node* p = make_load(control(), adr, value_type, type, adr_type, > MemNode::unordered, is_volatile); > > ?? I would have expected MemNode::acquire as in opto/parse3.cpp > > // Build the load. > // > MemNode::MemOrd mo = is_vol ? MemNode::acquire : MemNode::unordered; > bool needs_atomic_access = is_vol || AlwaysAtomicAccesses; > Node* ld = make_load(NULL, adr, type, bt, adr_type, mo, > needs_atomic_access); > > > > Thanks, > David > From roland.westrelin at oracle.com Mon Aug 4 23:51:06 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 05 Aug 2014 01:51:06 +0200 Subject: [9] RFR(S): 8054013: run hotspot JTREG compiler tests only on fastdebug platforms and also on macosx In-Reply-To: <53DF8A6E.9020704@oracle.com> References: <53DF8A6E.9020704@oracle.com> Message-ID: <87ha1r95lh.fsf@oracle.com> > Webrev: > > (top-level): http://cr.openjdk.java.net/~thartmann/8054013/webrev.00/top/ > (hotspot): http://cr.openjdk.java.net/~thartmann/8054013/webrev.00/hotspot/ Looks good. Roland. From sgehwolf at redhat.com Tue Aug 5 07:42:41 2014 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 05 Aug 2014 09:42:41 +0200 Subject: [9] RFR: JI-9039953 zero variant build is broken. In-Reply-To: <53DFC762.2070100@oracle.com> References: <1407167406.3128.53.camel@localhost.localdomain> <53DFC762.2070100@oracle.com> Message-ID: <1407224561.4841.7.camel@localhost.localdomain> Hi Coleen, On Mon, 2014-08-04 at 13:48 -0400, Coleen Phillimore wrote: > Hi, > > Did you try to build fastdebug? I found 2 more compilation errors when > I did that. > > http://cr.openjdk.java.net/~coleenp/8003426/src/cpu/zero/vm/cppInterpreter_zero.cpp.udiff.html > http://cr.openjdk.java.net/~coleenp/8003426/src/share/vm/interpreter/bytecodeInterpreter.cpp.udiff.html > > Although the last one could be due to the version of gcc I was using > (not sure). I did not try fastdebug, since both debug builds - fastdebug and slowdebug - are broken for my platform currently (even for non-zero-variant builds). See: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-August/014820.html http://mail.openjdk.java.net/pipermail/build-dev/2014-July/012900.html As for a release type zero variant build I only needed the change in the webrev below. I'll have a look and see if I can work around the generic debug build problem and will report back as soon as I know more. Thanks, Severin > Coleen > > On 8/4/14, 11:50 AM, Severin Gehwolf wrote: > > Hi, > > > > Building a zero variant of hotspot fails for the latest hs-comp tree > > with ("release"-type build): > > src/cpu/zero/vm/frame_zero.inline.hpp:59:11: error: ?CodeCache? has not > > been declared > > > > It appears to have been caused by a change of header files (perhaps > > [1]?). A file which used to be included implicitly does not seem to be > > included any longer. An explicit include fixes the problem. > > > > [2] shows the build failure. > > > > I would need a proper JDK bug and a sponsor for this change. An initial > > bug has been submitted as JI-9039953 via the web interface. > > > > Webrev is here: > > https://jerboaa.fedorapeople.org/bugs/openjdk/JI-9039953/webrev.01/ > > > > Thanks, > > Severin > > > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/22b98ab2a69f > > [2] > > http://builder.classpath.org/jenkins/job/OpenJDK9_hscomp_Zero/47/console > > > From sgehwolf at redhat.com Tue Aug 5 08:24:13 2014 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 05 Aug 2014 10:24:13 +0200 Subject: [9] RFR: JI-9039953 zero variant build is broken. In-Reply-To: <53DFC762.2070100@oracle.com> References: <1407167406.3128.53.camel@localhost.localdomain> <53DFC762.2070100@oracle.com> Message-ID: <1407227053.4841.13.camel@localhost.localdomain> Hi again, On Mon, 2014-08-04 at 13:48 -0400, Coleen Phillimore wrote: > Hi, > > Did you try to build fastdebug? I found 2 more compilation errors when > I did that. > > http://cr.openjdk.java.net/~coleenp/8003426/src/cpu/zero/vm/cppInterpreter_zero.cpp.udiff.html > http://cr.openjdk.java.net/~coleenp/8003426/src/share/vm/interpreter/bytecodeInterpreter.cpp.udiff.html > > Although the last one could be due to the version of gcc I was using > (not sure). Update: I've worked around the debug build problem related to fortify source and tried slowdebug and fastdebug builds. Interestingly, a slowdebug build worked only with the changes required to fix a release zero variant build. fastdebug, on the other hand, required *both* fixes you've mentioned above. Cheers, Severin > Coleen > > On 8/4/14, 11:50 AM, Severin Gehwolf wrote: > > Hi, > > > > Building a zero variant of hotspot fails for the latest hs-comp tree > > with ("release"-type build): > > src/cpu/zero/vm/frame_zero.inline.hpp:59:11: error: ?CodeCache? has not > > been declared > > > > It appears to have been caused by a change of header files (perhaps > > [1]?). A file which used to be included implicitly does not seem to be > > included any longer. An explicit include fixes the problem. > > > > [2] shows the build failure. > > > > I would need a proper JDK bug and a sponsor for this change. An initial > > bug has been submitted as JI-9039953 via the web interface. > > > > Webrev is here: > > https://jerboaa.fedorapeople.org/bugs/openjdk/JI-9039953/webrev.01/ > > > > Thanks, > > Severin > > > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/22b98ab2a69f > > [2] > > http://builder.classpath.org/jenkins/job/OpenJDK9_hscomp_Zero/47/console > > > From tobias.hartmann at oracle.com Tue Aug 5 08:56:24 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 05 Aug 2014 10:56:24 +0200 Subject: [9] RFR(S): 8029443: 'assert(klass->is_loader_alive(_is_alive)) failed: must be alive' during VM_CollectForMetadataAllocation In-Reply-To: <53D2938D.1070205@oracle.com> References: <53C3C584.7070008@oracle.com> <53C4820C.5000300@oracle.com> <53C53B23.6090907@oracle.com> <53C62FCA.8020302@oracle.com> <53C639A2.3050202@oracle.com> <53C90740.40602@oracle.com> <53C937E0.7060304@oracle.com> <53C9614C.8080109@oracle.com> <53C962F3.3070405@oracle.com> <53CCD307.7040806@oracle.com> <53CD62F4.1020904@oracle.com> <53CE2D53.6040006@oracle.com> <53CEA79F.6030004@oracle.com> <53D2619E.8010109@oracle.com> <53D2938D.1070205@oracle.com> Message-ID: <53E09C38.8000009@oracle.com> Mikael, Vladimir, thanks for the review. Please see comments inline. On 25.07.2014 16:13, Mikael Gerdin wrote: > There shouldn't be anything stopping the Klass* from being emitted as > an immediate just as long as the appropriate relocation entry is > created. We don't need to update the immediate in the instruction > stream for the Klass* since we don't move klasses any more. Right, I changed the implementation of 'loadConP_no_oop_cheap' to create a relocation entry if the loaded pointer references (Klass) metadata. On 25.07.2014 19:27, Vladimir Kozlov wrote: > Tobias, you also need to check for general metadata and not just > klassptr - is_metadataptr(). Unfortunately they not inherited from > one-another in C2 types. As Mikael mentioned we can emit the Klass* as an immediate and do not have to use 'loadConP_load'. I removed the changes to 'nmethod::do_unloading' and 'nmethod::do_unloading_parallel' because we now unload the nmethod anyway. New webrev: http://cr.openjdk.java.net/~thartmann/8029443/webrev.03/ As I said, the bug rarely occurs on x86-32 as well, which means that there probably is a similar bug on x86. Unfortunately I'm not able to reproduce it. I'd suggest we fix the Sparc related problem with this bug and open a new one for the x86 related failures. Thanks, Tobias > > Thanks, > Vladimir > > On 7/25/14 6:54 AM, Tobias Hartmann wrote: >> Mikael, Vladimir, thanks for the review. >> >> The problem is indeed caused by a missing check for a metadata pointer >> in sparc.ad. >> >> Adding 'n->bottom_type()->isa_klassptr()' checks to immP_load() and >> immP_no_oop_cheap() fixes the problem. The Klass pointer is then loaded >> from the constant table (loadConP_load()) and a metadata relocation is >> added by Compile::ConstantTable::emit(). >> >> I had a look at the Aurora chessboard and it looks like as if the bug >> recently occured on x86_32 as well. I was not yet able to reproduce it >> but will try again next week. >> >> Thanks, >> Tobias >> >> On 22.07.2014 20:04, Vladimir Kozlov wrote: >>> I agree with Mikael, the case without compressed oops is incorrect. >>> The problem is immP_load() and immP_no_oop_cheap() operands miss the >>> check for metadata pointer, they only check for oop. For class loading >>> loadConP_load() should be used instead of loadConP_no_oop_cheap() and >>> it should check relocation type and do what loadConP_set() does. >>> >>> >>> X64 seems fine. X86_64.ad use $$$emit32$src$$constant; in such case >>> (load_immP31) which is expanded to the same code as load_immP: >>> >>> if ( opnd_array(1)->constant_reloc() != relocInfo::none ) { >>> emit_d32_reloc(cbuf, opnd_array(1)->constant(), >>> opnd_array(1)->constant_reloc(), 0); >>> >>> Thanks, >>> Vladimir >>> >>> On 7/22/14 2:22 AM, Tobias Hartmann wrote: >>>> On 21.07.2014 20:59, Vladimir Kozlov wrote: >>>>> On 7/21/14 1:44 AM, Tobias Hartmann wrote: >>>>>> Vladimir, Coleen, thanks for the reviews! >>>>>> >>>>>> On 18.07.2014 20:09, Vladimir Kozlov wrote: >>>>>>> On 7/18/14 11:02 AM, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> On 7/18/14, 11:06 AM, Vladimir Kozlov wrote: >>>>>>>>> On 7/18/14 4:38 AM, Tobias Hartmann wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I spend some more days and was finally able to implement a test >>>>>>>>>> that >>>>>>>>>> deterministically triggers the bug: >>>>>>>>> >>>>>>>>> Why do you need to switch off compressed oops? Do you need to >>>>>>>>> switch >>>>>>>>> off compressed klass pointers too (UseCompressedClassPointers)? >>>>>>>> >>>>>>>> CompressedOops when off turns off CompressedClassPointers. >>>>>>> >>>>>>> You are right, I forgot that. Still the question is why switch off >>>>>>> coop? >>>>>> >>>>>> I'm only able to reproduce the bug without compressed oops. The >>>>>> original >>>>>> bug also only reproduces with -XX:-UseCompressedOops. I tried to >>>>>> figure >>>>>> out why (on Sparc): >>>>>> >>>>>> With compressed oops enabled, Method* metadata referencing >>>>>> 'WorkerClass' >>>>>> is added to 'doWork' in MacroAssembler::set_narrow_klass(..). In >>>>>> CodeBuffer::finalize_oop_references(..) the metadata is processed >>>>>> and an >>>>>> oop to the class loader 'URLClassLoader' is added. This oop leads >>>>>> to the >>>>>> unloading of 'doWork', hence the verification code is never >>>>>> executed. >>>>>> >>>>>> I'm not sure what set_narrow_klass(..) is used for in this case. I >>>>>> assume it stores a 'WorkerClass' Klass* in a register as part of an >>>>>> optimization? Because 'doWork' potentially works on any class. >>>>>> Apparently this optimization is not performed without compressed >>>>>> oops. >>>>> >>>>> I would suggest to compare 'doWork' assembler >>>>> (-XX:CompileCommand=print,TestMethodUnloading::doWork) with coop and >>>>> without it. Usually loaded into register class is used for klass >>>>> compare do guard inlining code. Or to initialize new object. >>>>> >>>>> I don't see loading (constructing) uncompressed (whole) klass pointer >>>>> from constant in sparc.ad. It could be the reason for different >>>>> behavior. It could be loaded from constants section. But constants >>>>> section should have metadata relocation info in such case. >>>> >>>> I did as you suggested and found the following: >>>> >>>> During the profiling phase the class given to 'doWork' always is >>>> 'WorkerClass'. The C2 compiler therefore optimizes the compiled >>>> version >>>> to expect a 'WorkerClass'. The branch that instantiates a new >>>> object is >>>> guarded by an uncommon trap (class_check). The difference between the >>>> two versions (with and without compressed oops) is the loading of the >>>> 'WorkerClass' Klass to check if the given class is equal: >>>> >>>> With compressed oops: >>>> SET narrowklass: precise klass WorkerClass: >>>> 0x00000001004a0d40:Constant:exact *,R_L1 ! compressed klass ptr >>>> CWBne R_L2,R_L1,B8 ! compressed ptr P=0.000001 C=-1.000000 >>>> >>>> Without: >>>> SET precise klass WorkerClass: >>>> 0x00000001004aeab0:Constant:exact >>>> *,R_L1 ! non-oop ptr >>>> CXBpne R_L2,R_L1,B8 ! ptr P=0.000001 C=-1.000000 >>>> >>>> R_L2: class given as parameter >>>> B8: location of uncommon trap >>>> >>>> In the first case, the Klass is loaded by a 'loadConNKlass' >>>> instruction >>>> that calls MacroAssembler::set_narrow_klass(..) which then creates a >>>> metadata_Relocation for the 'WorkerClass'. This metada_Relocation is >>>> processed by CodeBuffer::finalize_oop_references(..) and an oop to >>>> 'WorkerClass' is added. This oop causes the unloading of the method. >>>> >>>> In the second case, the Klass is loaded by a 'loadConP_no_oop_cheap' >>>> instruction that does not create a metadata_Relocation. >>>> >>>> I don't understand why the metadata_Relocation in the first case is >>>> needed? As the test shows it is better to only unload the method if we >>>> hit the uncommon trap because we could still use other (potentially >>>> complex) branches of the method. >>>> >>>> Thanks, >>>> Tobias >>>> >>>>> >>>>> thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Best, >>>>>> Tobias >>>>>> >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8029443/webrev.02/ >>>>>>>>> >>>>>>>>> Very nice! >>>>>>>> >>>>>>>> Yes, I agree. Impressive. >>>>>>>> >>>>>>>> The refactoring in nmethod.cpp looks good to me. I have no >>>>>>>> further >>>>>>>> comments. >>>>>>>> Thanks! >>>>>>>> Coleen >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> @Vladimir: The test shows why we should only clean the ICs >>>>>>>>>> but not >>>>>>>>>> unload the nmethod if possible. The method ' doWork' >>>>>>>>>> is still valid after WorkerClass was unloaded and depending >>>>>>>>>> on the >>>>>>>>>> complexity of the method we should avoid unloading it. >>>>>>>>> >>>>>>>>> Make sense. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sparc my patch fixes the bug and leads to the nmethod not >>>>>>>>>> being >>>>>>>>>> unloaded. The compiled version is therefore used even >>>>>>>>>> after WorkerClass is unloaded. >>>>>>>>>> >>>>>>>>>> On x86 the nmethod is unloaded anyway because of a dead oop. >>>>>>>>>> This is >>>>>>>>>> probably due to a slightly different implementation >>>>>>>>>> of the ICs. I'll have a closer look to see if we can improve >>>>>>>>>> that. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Tobias >>>>>>>>>> >>>>>>>>>> On 16.07.2014 10:36, Tobias Hartmann wrote: >>>>>>>>>>> Sorry, forgot to answer this question: >>>>>>>>>>>> Were you able to create a small test case for it that would be >>>>>>>>>>>> useful to add? >>>>>>>>>>> Unfortunately I was not able to create a test. The bug only >>>>>>>>>>> reproduces on a particular system with a > 30 minute run >>>>>>>>>>> of runThese. >>>>>>>>>>> >>>>>>>>>>> Best, >>>>>>>>>>> Tobias >>>>>>>>>>> >>>>>>>>>>> On 16.07.2014 09:54, Tobias Hartmann wrote: >>>>>>>>>>>> Hi Coleen, >>>>>>>>>>>> >>>>>>>>>>>> thanks for the review. >>>>>>>>>>>>> *+ if (csc->is_call_to_interpreted() && >>>>>>>>>>>>> stub_contains_dead_metadata(is_alive, csc->destination())) {* >>>>>>>>>>>>> *+ csc->set_to_clean();* >>>>>>>>>>>>> *+ }* >>>>>>>>>>>>> >>>>>>>>>>>>> This appears in each case. Can you fold it and the new >>>>>>>>>>>>> function >>>>>>>>>>>>> into a function like >>>>>>>>>>>>> clean_call_to_interpreted_stub(is_alive, csc)? >>>>>>>>>>>> >>>>>>>>>>>> I folded it into the function >>>>>>>>>>>> clean_call_to_interpreter_stub(..). >>>>>>>>>>>> >>>>>>>>>>>> New webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8029443/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Tobias >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Coleen >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> So before the permgen removal embedded method* were oops and >>>>>>>>>>>>>> they >>>>>>>>>>>>>> were processed in relocInfo::oop_type loop. >>>>>>>>>>>>>> >>>>>>>>>>>>>> May be instead of specializing opt_virtual_call_type and >>>>>>>>>>>>>> static_call_type call site you can simple add a loop for >>>>>>>>>>>>>> relocInfo::metadata_type (similar to oop_type loop)? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 7/14/14 4:56 AM, Tobias Hartmann wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> please review the following patch for JDK-8029443. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029443 >>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8029443/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Problem* >>>>>>>>>>>>>>> After the tracing/marking phase of GC, >>>>>>>>>>>>>>> nmethod::do_unloading(..) >>>>>>>>>>>>>>> checks >>>>>>>>>>>>>>> if a nmethod can be unloaded because it contains dead >>>>>>>>>>>>>>> oops. If >>>>>>>>>>>>>>> class >>>>>>>>>>>>>>> unloading occurred we additionally clear all ICs where the >>>>>>>>>>>>>>> cached >>>>>>>>>>>>>>> metadata refers to an unloaded klass or method. If the >>>>>>>>>>>>>>> nmethod >>>>>>>>>>>>>>> is not >>>>>>>>>>>>>>> unloaded, nmethod::verify_metadata_loaders(..) finally >>>>>>>>>>>>>>> checks if >>>>>>>>>>>>>>> all >>>>>>>>>>>>>>> metadata is alive. The assert in CheckClass::check_class >>>>>>>>>>>>>>> fails >>>>>>>>>>>>>>> because >>>>>>>>>>>>>>> the nmethod contains Method* metadata corresponding to a >>>>>>>>>>>>>>> dead >>>>>>>>>>>>>>> Klass. >>>>>>>>>>>>>>> The Method* belongs to a to-interpreter stub [1] of an >>>>>>>>>>>>>>> optimized >>>>>>>>>>>>>>> compiled IC. Normally we clear those stubs prior to >>>>>>>>>>>>>>> verification to >>>>>>>>>>>>>>> avoid dangling references to Method* [2], but only if the >>>>>>>>>>>>>>> stub >>>>>>>>>>>>>>> is not in >>>>>>>>>>>>>>> use, i.e. if the IC is not in to-interpreted mode. In this >>>>>>>>>>>>>>> case the >>>>>>>>>>>>>>> to-interpreter stub may be executed and hand a stale >>>>>>>>>>>>>>> Method* >>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>> interpreter. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Solution >>>>>>>>>>>>>>> *The implementation of nmethod::do_unloading(..) is >>>>>>>>>>>>>>> changed to >>>>>>>>>>>>>>> clean >>>>>>>>>>>>>>> compiled ICs and compiled static calls if they call into a >>>>>>>>>>>>>>> to-interpreter stub that references dead Method* metadata. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The patch was affected by the G1 class unloading changes >>>>>>>>>>>>>>> (JDK-8048248) >>>>>>>>>>>>>>> because the method nmethod::do_unloading_parallel(..) was >>>>>>>>>>>>>>> added. I >>>>>>>>>>>>>>> adapted the implementation as well. >>>>>>>>>>>>>>> * >>>>>>>>>>>>>>> Testing >>>>>>>>>>>>>>> *Failing test (runThese) >>>>>>>>>>>>>>> JPRT >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Tobias >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [1] see CompiledStaticCall::emit_to_interp_stub(..) >>>>>>>>>>>>>>> [2] see nmethod::verify_metadata_loaders(..), >>>>>>>>>>>>>>> static_stub_reloc()->clear_inline_cache() clears the stub >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> From volker.simonis at gmail.com Tue Aug 5 16:11:04 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 5 Aug 2014 18:11:04 +0200 Subject: MemNode::unordered/release/acquire use in relation to volatile stores and loads In-Reply-To: <53DFF783.2020703@oracle.com> References: <53DECAF3.4010203@oracle.com> <53DFF783.2020703@oracle.com> Message-ID: On Mon, Aug 4, 2014 at 11:13 PM, Vladimir Kozlov wrote: > I would say that you are correct (MemNode::acquire is needed for volatile > load). > Lets hear Goetz answer. > Hi David, Vladimir, unfortunately, Goetz is on a sabbatical leave until mid September... > Thanks, > Vladimir > > > On 8/3/14 4:51 PM, David Holmes wrote: >> >> In ./share/vm/opto/library_call.cpp >> >> Why is it that for volatile stores we have special checks for which >> MemNode to use: >> >> MemNode::MemOrd mo = is_volatile ? MemNode::release : >> MemNode::unordered; >> if (type != T_OBJECT ) { >> (void) store_to_memory(control(), adr, val, type, adr_type, mo, >> is_volatile); >> } else { >> >> but for loads it is always unordered eg: >> >> Node* p = make_load(control(), adr, value_type, type, adr_type, >> MemNode::unordered, is_volatile); >> That seems indeed strange. Especially because in our internal SAP JVM version we have: Node* p = make_load(control(), adr, value_type, type, adr_type, is_volatile ? MemNode::acquire : MemNode::unordered, is_volatile); I've cc-ed Martin who did this change in our sources (unfortunately there's still a little diff between them and the OpenJDK :( He will be back next week and maybe he has some more insights? >> ?? I would have expected MemNode::acquire as in opto/parse3.cpp >> >> // Build the load. >> // >> MemNode::MemOrd mo = is_vol ? MemNode::acquire : MemNode::unordered; >> bool needs_atomic_access = is_vol || AlwaysAtomicAccesses; >> Node* ld = make_load(NULL, adr, type, bt, adr_type, mo, >> needs_atomic_access); >> And there's also another instance of this pattern in the method LibraryCallKit::load_field_from_object() in library_call.cpp which should be probably fixed as well: // Build the load. Node* loadedField = make_load(NULL, adr, type, bt, adr_type, MemNode::unordered, is_vol); Regards, Volker >> >> >> Thanks, >> David >> > From vladimir.kozlov at oracle.com Tue Aug 5 18:03:55 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 05 Aug 2014 11:03:55 -0700 Subject: [9] RFR(S): 8029443: 'assert(klass->is_loader_alive(_is_alive)) failed: must be alive' during VM_CollectForMetadataAllocation In-Reply-To: <53E09C38.8000009@oracle.com> References: <53C3C584.7070008@oracle.com> <53C4820C.5000300@oracle.com> <53C53B23.6090907@oracle.com> <53C62FCA.8020302@oracle.com> <53C639A2.3050202@oracle.com> <53C90740.40602@oracle.com> <53C937E0.7060304@oracle.com> <53C9614C.8080109@oracle.com> <53C962F3.3070405@oracle.com> <53CCD307.7040806@oracle.com> <53CD62F4.1020904@oracle.com> <53CE2D53.6040006@oracle.com> <53CEA79F.6030004@oracle.com> <53D2619E.8010109@oracle.com> <53D2938D.1070205@oracle.com> <53E09C38.8000009@oracle.com> Message-ID: <53E11C8B.5080802@oracle.com> Changes looks ggod. Thank you for solving this hard problem. Thanks, Vladimir On 8/5/14 1:56 AM, Tobias Hartmann wrote: > Mikael, Vladimir, > > thanks for the review. Please see comments inline. > > On 25.07.2014 16:13, Mikael Gerdin wrote: >> There shouldn't be anything stopping the Klass* from being emitted as >> an immediate just as long as the appropriate relocation entry is >> created. We don't need to update the immediate in the instruction >> stream for the Klass* since we don't move klasses any more. > > Right, I changed the implementation of 'loadConP_no_oop_cheap' to create > a relocation entry if the loaded pointer references (Klass) metadata. > > On 25.07.2014 19:27, Vladimir Kozlov wrote: >> Tobias, you also need to check for general metadata and not just >> klassptr - is_metadataptr(). Unfortunately they not inherited from >> one-another in C2 types. > > As Mikael mentioned we can emit the Klass* as an immediate and do not > have to use 'loadConP_load'. I removed the changes to > 'nmethod::do_unloading' and 'nmethod::do_unloading_parallel' because we > now unload the nmethod anyway. > > New webrev: http://cr.openjdk.java.net/~thartmann/8029443/webrev.03/ > > As I said, the bug rarely occurs on x86-32 as well, which means that > there probably is a similar bug on x86. Unfortunately I'm not able to > reproduce it. I'd suggest we fix the Sparc related problem with this bug > and open a new one for the x86 related failures. > > Thanks, > Tobias > >> >> Thanks, >> Vladimir >> >> On 7/25/14 6:54 AM, Tobias Hartmann wrote: >>> Mikael, Vladimir, thanks for the review. >>> >>> The problem is indeed caused by a missing check for a metadata pointer >>> in sparc.ad. >>> >>> Adding 'n->bottom_type()->isa_klassptr()' checks to immP_load() and >>> immP_no_oop_cheap() fixes the problem. The Klass pointer is then loaded >>> from the constant table (loadConP_load()) and a metadata relocation is >>> added by Compile::ConstantTable::emit(). >>> >>> I had a look at the Aurora chessboard and it looks like as if the bug >>> recently occured on x86_32 as well. I was not yet able to reproduce it >>> but will try again next week. >>> >>> Thanks, >>> Tobias >>> >>> On 22.07.2014 20:04, Vladimir Kozlov wrote: >>>> I agree with Mikael, the case without compressed oops is incorrect. >>>> The problem is immP_load() and immP_no_oop_cheap() operands miss the >>>> check for metadata pointer, they only check for oop. For class loading >>>> loadConP_load() should be used instead of loadConP_no_oop_cheap() and >>>> it should check relocation type and do what loadConP_set() does. >>>> >>>> >>>> X64 seems fine. X86_64.ad use $$$emit32$src$$constant; in such case >>>> (load_immP31) which is expanded to the same code as load_immP: >>>> >>>> if ( opnd_array(1)->constant_reloc() != relocInfo::none ) { >>>> emit_d32_reloc(cbuf, opnd_array(1)->constant(), >>>> opnd_array(1)->constant_reloc(), 0); >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 7/22/14 2:22 AM, Tobias Hartmann wrote: >>>>> On 21.07.2014 20:59, Vladimir Kozlov wrote: >>>>>> On 7/21/14 1:44 AM, Tobias Hartmann wrote: >>>>>>> Vladimir, Coleen, thanks for the reviews! >>>>>>> >>>>>>> On 18.07.2014 20:09, Vladimir Kozlov wrote: >>>>>>>> On 7/18/14 11:02 AM, Coleen Phillimore wrote: >>>>>>>>> >>>>>>>>> On 7/18/14, 11:06 AM, Vladimir Kozlov wrote: >>>>>>>>>> On 7/18/14 4:38 AM, Tobias Hartmann wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I spend some more days and was finally able to implement a test >>>>>>>>>>> that >>>>>>>>>>> deterministically triggers the bug: >>>>>>>>>> >>>>>>>>>> Why do you need to switch off compressed oops? Do you need to >>>>>>>>>> switch >>>>>>>>>> off compressed klass pointers too (UseCompressedClassPointers)? >>>>>>>>> >>>>>>>>> CompressedOops when off turns off CompressedClassPointers. >>>>>>>> >>>>>>>> You are right, I forgot that. Still the question is why switch off >>>>>>>> coop? >>>>>>> >>>>>>> I'm only able to reproduce the bug without compressed oops. The >>>>>>> original >>>>>>> bug also only reproduces with -XX:-UseCompressedOops. I tried to >>>>>>> figure >>>>>>> out why (on Sparc): >>>>>>> >>>>>>> With compressed oops enabled, Method* metadata referencing >>>>>>> 'WorkerClass' >>>>>>> is added to 'doWork' in MacroAssembler::set_narrow_klass(..). In >>>>>>> CodeBuffer::finalize_oop_references(..) the metadata is processed >>>>>>> and an >>>>>>> oop to the class loader 'URLClassLoader' is added. This oop leads >>>>>>> to the >>>>>>> unloading of 'doWork', hence the verification code is never >>>>>>> executed. >>>>>>> >>>>>>> I'm not sure what set_narrow_klass(..) is used for in this case. I >>>>>>> assume it stores a 'WorkerClass' Klass* in a register as part of an >>>>>>> optimization? Because 'doWork' potentially works on any class. >>>>>>> Apparently this optimization is not performed without compressed >>>>>>> oops. >>>>>> >>>>>> I would suggest to compare 'doWork' assembler >>>>>> (-XX:CompileCommand=print,TestMethodUnloading::doWork) with coop and >>>>>> without it. Usually loaded into register class is used for klass >>>>>> compare do guard inlining code. Or to initialize new object. >>>>>> >>>>>> I don't see loading (constructing) uncompressed (whole) klass pointer >>>>>> from constant in sparc.ad. It could be the reason for different >>>>>> behavior. It could be loaded from constants section. But constants >>>>>> section should have metadata relocation info in such case. >>>>> >>>>> I did as you suggested and found the following: >>>>> >>>>> During the profiling phase the class given to 'doWork' always is >>>>> 'WorkerClass'. The C2 compiler therefore optimizes the compiled >>>>> version >>>>> to expect a 'WorkerClass'. The branch that instantiates a new >>>>> object is >>>>> guarded by an uncommon trap (class_check). The difference between the >>>>> two versions (with and without compressed oops) is the loading of the >>>>> 'WorkerClass' Klass to check if the given class is equal: >>>>> >>>>> With compressed oops: >>>>> SET narrowklass: precise klass WorkerClass: >>>>> 0x00000001004a0d40:Constant:exact *,R_L1 ! compressed klass ptr >>>>> CWBne R_L2,R_L1,B8 ! compressed ptr P=0.000001 C=-1.000000 >>>>> >>>>> Without: >>>>> SET precise klass WorkerClass: >>>>> 0x00000001004aeab0:Constant:exact >>>>> *,R_L1 ! non-oop ptr >>>>> CXBpne R_L2,R_L1,B8 ! ptr P=0.000001 C=-1.000000 >>>>> >>>>> R_L2: class given as parameter >>>>> B8: location of uncommon trap >>>>> >>>>> In the first case, the Klass is loaded by a 'loadConNKlass' >>>>> instruction >>>>> that calls MacroAssembler::set_narrow_klass(..) which then creates a >>>>> metadata_Relocation for the 'WorkerClass'. This metada_Relocation is >>>>> processed by CodeBuffer::finalize_oop_references(..) and an oop to >>>>> 'WorkerClass' is added. This oop causes the unloading of the method. >>>>> >>>>> In the second case, the Klass is loaded by a 'loadConP_no_oop_cheap' >>>>> instruction that does not create a metadata_Relocation. >>>>> >>>>> I don't understand why the metadata_Relocation in the first case is >>>>> needed? As the test shows it is better to only unload the method if we >>>>> hit the uncommon trap because we could still use other (potentially >>>>> complex) branches of the method. >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>>> >>>>>> thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Best, >>>>>>> Tobias >>>>>>> >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8029443/webrev.02/ >>>>>>>>>> >>>>>>>>>> Very nice! >>>>>>>>> >>>>>>>>> Yes, I agree. Impressive. >>>>>>>>> >>>>>>>>> The refactoring in nmethod.cpp looks good to me. I have no >>>>>>>>> further >>>>>>>>> comments. >>>>>>>>> Thanks! >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> @Vladimir: The test shows why we should only clean the ICs >>>>>>>>>>> but not >>>>>>>>>>> unload the nmethod if possible. The method ' doWork' >>>>>>>>>>> is still valid after WorkerClass was unloaded and depending >>>>>>>>>>> on the >>>>>>>>>>> complexity of the method we should avoid unloading it. >>>>>>>>>> >>>>>>>>>> Make sense. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Sparc my patch fixes the bug and leads to the nmethod not >>>>>>>>>>> being >>>>>>>>>>> unloaded. The compiled version is therefore used even >>>>>>>>>>> after WorkerClass is unloaded. >>>>>>>>>>> >>>>>>>>>>> On x86 the nmethod is unloaded anyway because of a dead oop. >>>>>>>>>>> This is >>>>>>>>>>> probably due to a slightly different implementation >>>>>>>>>>> of the ICs. I'll have a closer look to see if we can improve >>>>>>>>>>> that. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Tobias >>>>>>>>>>> >>>>>>>>>>> On 16.07.2014 10:36, Tobias Hartmann wrote: >>>>>>>>>>>> Sorry, forgot to answer this question: >>>>>>>>>>>>> Were you able to create a small test case for it that would be >>>>>>>>>>>>> useful to add? >>>>>>>>>>>> Unfortunately I was not able to create a test. The bug only >>>>>>>>>>>> reproduces on a particular system with a > 30 minute run >>>>>>>>>>>> of runThese. >>>>>>>>>>>> >>>>>>>>>>>> Best, >>>>>>>>>>>> Tobias >>>>>>>>>>>> >>>>>>>>>>>> On 16.07.2014 09:54, Tobias Hartmann wrote: >>>>>>>>>>>>> Hi Coleen, >>>>>>>>>>>>> >>>>>>>>>>>>> thanks for the review. >>>>>>>>>>>>>> *+ if (csc->is_call_to_interpreted() && >>>>>>>>>>>>>> stub_contains_dead_metadata(is_alive, csc->destination())) {* >>>>>>>>>>>>>> *+ csc->set_to_clean();* >>>>>>>>>>>>>> *+ }* >>>>>>>>>>>>>> >>>>>>>>>>>>>> This appears in each case. Can you fold it and the new >>>>>>>>>>>>>> function >>>>>>>>>>>>>> into a function like >>>>>>>>>>>>>> clean_call_to_interpreted_stub(is_alive, csc)? >>>>>>>>>>>>> >>>>>>>>>>>>> I folded it into the function >>>>>>>>>>>>> clean_call_to_interpreter_stub(..). >>>>>>>>>>>>> >>>>>>>>>>>>> New webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8029443/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Tobias >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Coleen >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So before the permgen removal embedded method* were oops and >>>>>>>>>>>>>>> they >>>>>>>>>>>>>>> were processed in relocInfo::oop_type loop. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> May be instead of specializing opt_virtual_call_type and >>>>>>>>>>>>>>> static_call_type call site you can simple add a loop for >>>>>>>>>>>>>>> relocInfo::metadata_type (similar to oop_type loop)? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 7/14/14 4:56 AM, Tobias Hartmann wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> please review the following patch for JDK-8029443. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029443 >>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8029443/webrev.00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Problem* >>>>>>>>>>>>>>>> After the tracing/marking phase of GC, >>>>>>>>>>>>>>>> nmethod::do_unloading(..) >>>>>>>>>>>>>>>> checks >>>>>>>>>>>>>>>> if a nmethod can be unloaded because it contains dead >>>>>>>>>>>>>>>> oops. If >>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>> unloading occurred we additionally clear all ICs where the >>>>>>>>>>>>>>>> cached >>>>>>>>>>>>>>>> metadata refers to an unloaded klass or method. If the >>>>>>>>>>>>>>>> nmethod >>>>>>>>>>>>>>>> is not >>>>>>>>>>>>>>>> unloaded, nmethod::verify_metadata_loaders(..) finally >>>>>>>>>>>>>>>> checks if >>>>>>>>>>>>>>>> all >>>>>>>>>>>>>>>> metadata is alive. The assert in CheckClass::check_class >>>>>>>>>>>>>>>> fails >>>>>>>>>>>>>>>> because >>>>>>>>>>>>>>>> the nmethod contains Method* metadata corresponding to a >>>>>>>>>>>>>>>> dead >>>>>>>>>>>>>>>> Klass. >>>>>>>>>>>>>>>> The Method* belongs to a to-interpreter stub [1] of an >>>>>>>>>>>>>>>> optimized >>>>>>>>>>>>>>>> compiled IC. Normally we clear those stubs prior to >>>>>>>>>>>>>>>> verification to >>>>>>>>>>>>>>>> avoid dangling references to Method* [2], but only if the >>>>>>>>>>>>>>>> stub >>>>>>>>>>>>>>>> is not in >>>>>>>>>>>>>>>> use, i.e. if the IC is not in to-interpreted mode. In this >>>>>>>>>>>>>>>> case the >>>>>>>>>>>>>>>> to-interpreter stub may be executed and hand a stale >>>>>>>>>>>>>>>> Method* >>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>> interpreter. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Solution >>>>>>>>>>>>>>>> *The implementation of nmethod::do_unloading(..) is >>>>>>>>>>>>>>>> changed to >>>>>>>>>>>>>>>> clean >>>>>>>>>>>>>>>> compiled ICs and compiled static calls if they call into a >>>>>>>>>>>>>>>> to-interpreter stub that references dead Method* metadata. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The patch was affected by the G1 class unloading changes >>>>>>>>>>>>>>>> (JDK-8048248) >>>>>>>>>>>>>>>> because the method nmethod::do_unloading_parallel(..) was >>>>>>>>>>>>>>>> added. I >>>>>>>>>>>>>>>> adapted the implementation as well. >>>>>>>>>>>>>>>> * >>>>>>>>>>>>>>>> Testing >>>>>>>>>>>>>>>> *Failing test (runThese) >>>>>>>>>>>>>>>> JPRT >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Tobias >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [1] see CompiledStaticCall::emit_to_interp_stub(..) >>>>>>>>>>>>>>>> [2] see nmethod::verify_metadata_loaders(..), >>>>>>>>>>>>>>>> static_stub_reloc()->clear_inline_cache() clears the stub >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > From roland.westrelin at oracle.com Tue Aug 5 21:21:53 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 05 Aug 2014 23:21:53 +0200 Subject: [9] RFR(S): 8029443: 'assert(klass->is_loader_alive(_is_alive)) failed: must be alive' during VM_CollectForMetadataAllocation In-Reply-To: <53E09C38.8000009@oracle.com> References: <53C3C584.7070008@oracle.com> <53C4820C.5000300@oracle.com> <53C53B23.6090907@oracle.com> <53C62FCA.8020302@oracle.com> <53C639A2.3050202@oracle.com> <53C90740.40602@oracle.com> <53C937E0.7060304@oracle.com> <53C9614C.8080109@oracle.com> <53C962F3.3070405@oracle.com> <53CCD307.7040806@oracle.com> <53CD62F4.1020904@oracle.com> <53CE2D53.6040006@oracle.com> <53CEA79F.6030004@oracle.com> <53D2619E.8010109@oracle.com> <53D2938D.1070205@oracle.com> <53E09C38.8000009@oracle.com> Message-ID: <87zjfimy32.fsf@oracle.com> > New webrev: http://cr.openjdk.java.net/~thartmann/8029443/webrev.03/ That looks good to me. I think it would better to put both java files for your test in their own subdirectory (under classUnloading): if we add more regression tests for class unloading, it won't be obvious anymore that both files are part of the same test. Roland. From vladimir.kozlov at oracle.com Tue Aug 5 22:29:14 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 05 Aug 2014 15:29:14 -0700 Subject: [8u] backport RFR (XS) 8049252: VerifyStack logic in Deoptimization::unpack_frames does not expect to see invoke bc at the top frame during normal deoptimization Message-ID: <53E15ABA.5010007@oracle.com> 8u (8u40) backport request. The fix was pushed into jdk9 week ago and nightly testing shows no related problems. Changes from jdk9 applied to 8u without conflicts. http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/860d53992be0 https://bugs.openjdk.java.net/browse/JDK-8049252 http://cr.openjdk.java.net/~kvn/8049252/webrev Thanks, Vladimir From roland.westrelin at oracle.com Tue Aug 5 23:46:47 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 06 Aug 2014 01:46:47 +0200 Subject: [8u] backport RFR (XS) 8049252: VerifyStack logic in Deoptimization::unpack_frames does not expect to see invoke bc at the top frame during normal deoptimization In-Reply-To: <53E15ABA.5010007@oracle.com> References: <53E15ABA.5010007@oracle.com> Message-ID: <87wqammrdk.fsf@oracle.com> Ok. Roland. Vladimir Kozlov writes: > 8u (8u40) backport request. The fix was pushed into jdk9 week ago and > nightly testing shows no related problems. > > Changes from jdk9 applied to 8u without conflicts. > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/860d53992be0 > https://bugs.openjdk.java.net/browse/JDK-8049252 > http://cr.openjdk.java.net/~kvn/8049252/webrev > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Wed Aug 6 00:59:45 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 05 Aug 2014 17:59:45 -0700 Subject: [8u] backport RFR (XS) 8049252: VerifyStack logic in Deoptimization::unpack_frames does not expect to see invoke bc at the top frame during normal deoptimization In-Reply-To: <87wqammrdk.fsf@oracle.com> References: <53E15ABA.5010007@oracle.com> <87wqammrdk.fsf@oracle.com> Message-ID: <53E17E01.1050607@oracle.com> Thanks you, Roland Vladimir On 8/5/14 4:46 PM, Roland Westrelin wrote: > > Ok. > > Roland. > > Vladimir Kozlov writes: > >> 8u (8u40) backport request. The fix was pushed into jdk9 week ago and >> nightly testing shows no related problems. >> >> Changes from jdk9 applied to 8u without conflicts. >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/860d53992be0 >> https://bugs.openjdk.java.net/browse/JDK-8049252 >> http://cr.openjdk.java.net/~kvn/8049252/webrev >> >> Thanks, >> Vladimir From tobias.hartmann at oracle.com Wed Aug 6 06:09:43 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 06 Aug 2014 08:09:43 +0200 Subject: [9] RFR(S): 8029443: 'assert(klass->is_loader_alive(_is_alive)) failed: must be alive' during VM_CollectForMetadataAllocation In-Reply-To: <87zjfimy32.fsf@oracle.com> References: <53C3C584.7070008@oracle.com> <53C4820C.5000300@oracle.com> <53C53B23.6090907@oracle.com> <53C62FCA.8020302@oracle.com> <53C639A2.3050202@oracle.com> <53C90740.40602@oracle.com> <53C937E0.7060304@oracle.com> <53C9614C.8080109@oracle.com> <53C962F3.3070405@oracle.com> <53CCD307.7040806@oracle.com> <53CD62F4.1020904@oracle.com> <53CE2D53.6040006@oracle.com> <53CEA79F.6030004@oracle.com> <53D2619E.8010109@oracle.com> <53D2938D.1070205@oracle.com> <53E09C38.8000009@oracle.com> <87zjfimy32.fsf@oracle.com> Message-ID: <53E1C6A7.7000307@oracle.com> Vladimir, Roland, thanks for the review. @Roland: I will move the java files to their own subdirectory before pushing. Thanks, Tobias On 05.08.2014 23:21, Roland Westrelin wrote: >> New webrev: http://cr.openjdk.java.net/~thartmann/8029443/webrev.03/ > That looks good to me. I think it would better to put both java files > for your test in their own subdirectory (under classUnloading): if we > add more regression tests for class unloading, it won't be obvious > anymore that both files are part of the same test. > > Roland. From coleen.phillimore at oracle.com Wed Aug 6 12:47:18 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 06 Aug 2014 08:47:18 -0400 Subject: Updated: RFR(L) 8046598: Scalable Native memory tracking development In-Reply-To: <53DFCF6D.20903@oracle.com> References: <53C58B14.9010003@oracle.com> <53DFCF6D.20903@oracle.com> Message-ID: <53E223D6.70301@oracle.com> memReporter.hpp and cpp copyrights look messed up. Only the latest date should be changed. mallocSiteTable.hpp typo 135 // A very large negnative number. The only possibility to "overflow" mallocTracker.cpp typo chunck 63 // from total chuncks to get total free chunck size virtualMemoryTracker.hpp typo 153 // Move virtual memory from one memorty type to another. virtualMemoryTracker.hpp It looks like you couldn't remove the assignment operator so you should add a copy constructor. You could add the copy constructor as private (with ShouldNotReachHere) to make sure nobody calls it. 365 ReservedMemoryRegion& operator= (const ReservedMemoryRegion& other) { Ship it! Coleen On 8/4/14, 2:22 PM, Zhengyu Gu wrote: > The update is based on code review meetings with Coleen, Christian, > George and Harold. > > http://cr.openjdk.java.net/~zgu/8046598/webrev.01/ > > > > Thanks, > > -Zhengyu > > > > On 7/15/2014 4:12 PM, Zhengyu Gu wrote: >> This is an update to previous RFR 8028541: Native Memory Tracking >> enhancement, the original one is closed as duplicate of current one. >> >> The update is mainly based on feedback from Coleen and Christian: >> - Refactored MemReporter to break up some large functions and >> eliminate duplicated code. >> - Minor change to MemBaseline for eliminating duplicated code. >> - Changed MEMFLAGS type from unsigned short => MemoryType. >> >> Also added unit tests for LinkedList. >> >> The note from RFR 8028541: >> ========================= >> This is significant rework of native memory tracking introduced in >> earlier releases. >> >> The goal of this enhancement is to improve scalability, from both >> tracking memory and CPU usage perspectives, so it can scale well with >> increased memory allocation in large applications. >> >> The enhancement is mainly focused on malloc memory tracking, whose >> activities are several magnitude higher than virtual memory, and was >> the main bottleneck in early implementation. >> >> Instead of using book keeping records for tracking malloc activities, >> new implementation co-locates tracking data along side with user data >> by using a prefixed header. The header size is 8 bytes on 32-bit >> systems and 16 bytes on 64-bit systems, which ensure that user data >> also align properly. >> >> Virtual memory tracking still uses book keeping records, and >> ThreadCritical lock is always acquired to alter the records and >> related data structures. >> >> Summary tracking data is maintained in static data structures, via >> atomic operations. Malloc detail tracking call stacks are maintained >> in a lock free hashtable. >> >> The key improvements: >> 1. Up-to-date tracking report. >> 2. Detail tracking now shows multiple call frames. Number of frames >> is compilation time decision, currently default to 4. >> 3. Malloc tracking is lock free. >> 4. Tracking summary is reported in hs_err file when native memory >> tracking is enabled. >> 5. Query is faster, uses little memory and need a very little process. >> >> The drawback is that, malloc tracking header is always needed if >> native memory tracking has ever been enabled, even after tracking is >> shutdown. >> >> Impacts: >> The most noticeable impact for JVM developers, is that Arena now >> also take memory type as constructor parameter, besides the new >> operators. >> Arena* a = new (mtCode) Arena() => Arena* a = new (mtCode) >> Arena(mtCode) >> >> The webrev shows modification of about 60 files, but most of them are >> due to tracking API changes, mainly due to tracking stack, now, is an >> object, vs. a single pc. >> >> The most important files for this implementations are: >> >> memTracker.hpp/cpp >> mallocTracker.hpp/cpp and mallocTracker.inline.hpp >> virtualMemoryTracker.hpp/cpp >> mallocSiteTable.hpp/cpp >> >> allocationSite.hpp >> nativeCallStack.hpp/cpp >> linkedlist.hpp >> >> >> Tests: >> - JPRT >> - NMT test suite >> - vm.quick.testlist >> - Kitchensink stability test for 16+ days >> - FMW >> >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8046598 >> Webrev: http://cr.openjdk.java.net/~zgu/8046598/webrev.00/ >> >> >> >> >> Thanks, >> >> -Zhengyu >> > From stefan.karlsson at oracle.com Wed Aug 6 12:37:27 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 06 Aug 2014 14:37:27 +0200 Subject: [8u40] Request for Approval: Backport of G1 Class Unloading changesets Message-ID: <53E22187.2070502@oracle.com> Hi all, This is the set of G1 Class Unloading backport patches that should be backported from JDK 9 to JDK 8u40. I've described how well the backports applied and some useful links to the webrevs, bugs, and JDK 9 changesets. IMHO, the only backport that is worth looking at in more detail is the changeset that adds G1 Class Unloading: 8049421, however I think the process mandates that we re-review the patches that failed. Could the old reviewers help out reviewing the changes marked as failed below? The patches are applied in order, against: http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot Patches: http://cr.openjdk.java.net/~stefank/backports/8u40/8034761 http://bugs.openjdk.java.net/bugs/browse/JDK-8032379 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/870aedf4ba4f 8032379: Remove the is_scavenging flag to process_strong_roots Reviewed-by: stefank, tschatzl, ehelin, jmasa clean http://cr.openjdk.java.net/~stefank/backports/8u40/8033764 http://bugs.openjdk.java.net/bugs/browse/JDK-8033764 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/937cf56dede6 8033764: Remove the usage of StarTask from BufferingOopClosure Reviewed-by: mgerdin, brutisso, tschatzl failed jni.cpp: New unit tests had been added. http://cr.openjdk.java.net/~stefank/backports/8u40/8033923 http://bugs.openjdk.java.net/bugs/browse/JDK-8033923 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/79aa45434291 8033923: Use BufferingOopClosure for G1 code root scanning Reviewed-by: mgerdin, brutisso clean http://cr.openjdk.java.net/~stefank/backports/8u40/8034761 http://bugs.openjdk.java.net/bugs/browse/JDK-8034761 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/d166675568f6 8034761: Remove the do_code_roots parameter from process_strong_roots Reviewed-by: tschatzl, mgerdin, jmasa failed g1CollectedHeap.hpp: A function had been removed. http://cr.openjdk.java.net/~stefank/backports/8u40/8034764 http://bugs.openjdk.java.net/bugs/browse/JDK-8034764 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/10c424c5a362 8034764: Use process_strong_roots to adjust the StringTable Reviewed-by: tschatzl, brutisso clean http://cr.openjdk.java.net/~stefank/backports/8u40/8035393 http://bugs.openjdk.java.net/bugs/browse/JDK-8035393 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/be0ac0e8f6e7 8035393: Use CLDClosure instead of CLDToOopClosure in frame::oops_interpreted_do Reviewed-by: tschatzl, coleenp fuzz thread.cpp http://cr.openjdk.java.net/~stefank/backports/8u40/8035412 http://bugs.openjdk.java.net/bugs/browse/JDK-8035412 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/3cdda110bbb5 8035412: Cleanup ClassLoaderData::is_alive Reviewed-by: coleenp, mgerdin clean http://cr.openjdk.java.net/~stefank/backports/8u40/8035648 http://bugs.openjdk.java.net/bugs/browse/JDK-8035648 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/301df27023d4 8035648: Don't use Handle in java_lang_String::print Reviewed-by: coleenp, pliden clean http://cr.openjdk.java.net/~stefank/backports/8u40/8035746 http://bugs.openjdk.java.net/bugs/browse/JDK-8035746 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/7f0e0366ec81 8035746: Add missing Klass::oop_is_instanceClassLoader() function Reviewed-by: mgerdin, coleenp clean http://cr.openjdk.java.net/~stefank/backports/8u40/8037958 http://bugs.openjdk.java.net/bugs/browse/JDK-8037958 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/85151870938f 8037958: ConcurrentMark::cleanup leaks BitMaps if VerifyDuringGC is enabled Reviewed-by: stefank, sjohanss clean http://cr.openjdk.java.net/~stefank/backports/8u40/8037958 http://bugs.openjdk.java.net/bugs/browse/JDK-8037958 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/f3d21f161945 8037958: ConcurrentMark::cleanup leaks BitMaps if VerifyDuringGC is enabled Reviewed-by: tschatzl, stefank failed space.cpp: New PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC interfered http://cr.openjdk.java.net/~stefank/backports/8u40/8038404 http://bugs.openjdk.java.net/bugs/browse/JDK-8038404 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/10a57200ca89 8038404: Move object_iterate_mem from Space to CMS since it is only ever used by CMS Reviewed-by: brutisso, tschatzl, stefank clean http://cr.openjdk.java.net/~stefank/backports/8u40/8038412 http://bugs.openjdk.java.net/bugs/browse/JDK-8038412 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/f0fb74dd59fe 8038412: Move object_iterate_careful down from Space to ContigousSpace and CFLSpace Reviewed-by: tschatzl, stefank failed compactibleFreeListSpace.hpp: Spelling fixes interfered space.hpp: Spelling fixes interfered http://cr.openjdk.java.net/~stefank/backports/8u40/8038405 http://bugs.openjdk.java.net/bugs/browse/JDK-8038405 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/53e2a1b32a62 8038405: Clean up some virtual fucntions in Space class hierarchy Reviewed-by: stefank, jmasa fuzz space.hpp http://cr.openjdk.java.net/~stefank/backports/8u40/8046670 http://bugs.openjdk.java.net/bugs/browse/JDK-8046670 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/f88e914539ff 8046670: Make CMS metadata aware closures applicable for other collectors Reviewed-by: ehelin, mgerdin failed cmsOopClosures.hpp: Spelling fixes interfered http://cr.openjdk.java.net/~stefank/backports/8u40/8047373 http://bugs.openjdk.java.net/bugs/browse/JDK-8047373 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/1b23c821b5e4 8047373: Clean the ExceptionCache in one pass Reviewed-by: jmasa, jwilhelm clean http://cr.openjdk.java.net/~stefank/backports/8u40/8047323 http://bugs.openjdk.java.net/bugs/browse/JDK-8047323 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/b179be81195e 8047323: Remove unused _copy_metadata_obj_cl in G1CopyingKeepAliveClosure Reviewed-by: mgerdin, tschatzl fuzz g1CollectedHeap.cpp http://cr.openjdk.java.net/~stefank/backports/8u40/8047326 http://bugs.openjdk.java.net/bugs/browse/JDK-8047326 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/9960da40c13e 8047326: Consolidate all CompiledIC::CompiledIC implementations and move it to compiledIC.cpp Reviewed-by: vlivanov, ehelin clean http://cr.openjdk.java.net/~stefank/backports/8u40/8047819 http://bugs.openjdk.java.net/bugs/browse/JDK-8047819 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/3f70ca73367d 8047819: G1 HeapRegionDCTOC does not need to inherit ContiguousSpaceDCTOC Reviewed-by: stefank, tschatzl clean http://cr.openjdk.java.net/~stefank/backports/8u40/8047820 http://bugs.openjdk.java.net/bugs/browse/JDK-8047820 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/238820b522f3 8047820: G1 Block offset table does not need to support generic Space classes Reviewed-by: tschatzl, stefank clean http://cr.openjdk.java.net/~stefank/backports/8u40/8047821 http://bugs.openjdk.java.net/bugs/browse/JDK-8047821 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/a326a6240e90 8047821: G1 Does not use the save_marks functionality as intended Reviewed-by: stefank, ehelin clean http://cr.openjdk.java.net/~stefank/backports/8u40/8048214 http://bugs.openjdk.java.net/bugs/browse/JDK-8048214 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/d8d107be209c 8048214: Linker error when compiling G1SATBCardTableModRefBS after include order changes Reviewed-by: stefank, brutisso, tschatzl clean http://cr.openjdk.java.net/~stefank/backports/8u40/8047818 http://bugs.openjdk.java.net/bugs/browse/JDK-8047818 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/f937359961e9 8047818: G1 HeapRegions can no longer be ContiguousSpaces Reviewed-by: stefank, jmasa, tschatzl failed heapRegion.cpp: This line is removed in JDK9: if (cl->abort()) return cur; heapRegion.cpp: Spelling fixes interfered http://cr.openjdk.java.net/~stefank/backports/8u40/8047362 http://bugs.openjdk.java.net/bugs/browse/JDK-8047362 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/1d62ae819013 8047362: Add a version of CompiledIC_at that doesn't create a new RelocIterator Reviewed-by: iveresov, mgerdin clean http://cr.openjdk.java.net/~stefank/backports/8u40/8049421 http://bugs.openjdk.java.net/bugs/browse/JDK-8049421 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/a2122d7912ed 8049421: G1 Class Unloading after completing a concurrent mark cycle Reviewed-by: tschatzl, ehelin, brutisso, coleenp, roland, iveresov failed classLoaderData.hpp: cld_do is missing in 8u stringTable.cpp: All code in stringTable.cpp is in symbolTable.cpp in 8u. concurrentMarkSweepGeneration.cpp: Spelling fixes interfered concurrentMark.cpp: Spelling fixes interfered concurrentMark.cpp: check_bitmaps calls have been added to 9 g1CollectedHeap.cpp: check_bitmaps calls have been added to 9 g1CollectedHeap.hpp: Spelling fixes interfered whitebox.cpp: Different includes in 9 and 8u whitebox.cpp: WB_GetThreadStackSize is not in 8u http://cr.openjdk.java.net/~stefank/backports/8u40/8049426 http://bugs.openjdk.java.net/bugs/browse/JDK-8049426 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/7fdf4173cde4 8049426: Minor cleanups after G1 class unloading Reviewed-by: stefank, brutisso clean http://cr.openjdk.java.net/~stefank/backports/8u40/8049831 http://bugs.openjdk.java.net/bugs/browse/JDK-8049831 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/429516ef23de 8049831: Metadata Full GCs are not triggered when CMSClassUnloadingEnabled is turned off Reviewed-by: brutisso, tschatzl, ehelin, jmasa, dfazunen failed TEST.groups: There's no needs_cmsgc section in 8u http://cr.openjdk.java.net/~stefank/backports/8u40/8051883 http://bugs.openjdk.java.net/bugs/browse/JDK-8051883 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/14e40cb29ca9 8051883: TEST.groups references missing test: gc/class_unloading/TestCMSClassUnloadingDisabledHWM.java Reviewed-by: brutisso, tschatzl, ehelin, jmasa, dfazunen clean http://cr.openjdk.java.net/~stefank/backports/8u40/8048269 http://bugs.openjdk.java.net/bugs/browse/JDK-8048269 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/9d38e660fc7a 8048269: Add flag to turn off class unloading after G1 concurrent mark Reviewed-by: jmasa, brutisso, mgerdin failed TEST.groups: There's no needs_g1gc section in 8u I've tested the patches with JPRT, specjbb2005, Kitchensink, specjvm98, dacapo2006, specjbb2000, gclockertest, gcbasher. thanks, StefanK From zhengyu.gu at oracle.com Wed Aug 6 13:24:06 2014 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 06 Aug 2014 09:24:06 -0400 Subject: Updated: RFR(L) 8046598: Scalable Native memory tracking development In-Reply-To: <53E223D6.70301@oracle.com> References: <53C58B14.9010003@oracle.com> <53DFCF6D.20903@oracle.com> <53E223D6.70301@oracle.com> Message-ID: <53E22C76.40305@oracle.com> Coleen, Thanks for the review. I will cleanup as you suggested. -Zhengyu On 8/6/2014 8:47 AM, Coleen Phillimore wrote: > > memReporter.hpp and cpp copyrights look messed up. Only the latest > date should be changed. > > mallocSiteTable.hpp typo > > 135 // A very large negnative number. The only possibility to > "overflow" > > > mallocTracker.cpp typo chunck > > 63 // from total chuncks to get total free chunck size > > > virtualMemoryTracker.hpp typo > > > 153 // Move virtual memory from one memorty type to another. > > > virtualMemoryTracker.hpp It looks like you couldn't remove the > assignment operator so you should add a copy constructor. You could > add the copy constructor as private (with ShouldNotReachHere) to make > sure nobody calls it. > > 365 ReservedMemoryRegion& operator= (const ReservedMemoryRegion& > other) { > > > Ship it! > Coleen > > On 8/4/14, 2:22 PM, Zhengyu Gu wrote: >> The update is based on code review meetings with Coleen, Christian, >> George and Harold. >> >> http://cr.openjdk.java.net/~zgu/8046598/webrev.01/ >> >> >> >> Thanks, >> >> -Zhengyu >> >> >> >> On 7/15/2014 4:12 PM, Zhengyu Gu wrote: >>> This is an update to previous RFR 8028541: Native Memory Tracking >>> enhancement, the original one is closed as duplicate of current one. >>> >>> The update is mainly based on feedback from Coleen and Christian: >>> - Refactored MemReporter to break up some large functions and >>> eliminate duplicated code. >>> - Minor change to MemBaseline for eliminating duplicated code. >>> - Changed MEMFLAGS type from unsigned short => MemoryType. >>> >>> Also added unit tests for LinkedList. >>> >>> The note from RFR 8028541: >>> ========================= >>> This is significant rework of native memory tracking introduced in >>> earlier releases. >>> >>> The goal of this enhancement is to improve scalability, from both >>> tracking memory and CPU usage perspectives, so it can scale well >>> with increased memory allocation in large applications. >>> >>> The enhancement is mainly focused on malloc memory tracking, whose >>> activities are several magnitude higher than virtual memory, and was >>> the main bottleneck in early implementation. >>> >>> Instead of using book keeping records for tracking malloc >>> activities, new implementation co-locates tracking data along side >>> with user data by using a prefixed header. The header size is 8 >>> bytes on 32-bit systems and 16 bytes on 64-bit systems, which ensure >>> that user data also align properly. >>> >>> Virtual memory tracking still uses book keeping records, and >>> ThreadCritical lock is always acquired to alter the records and >>> related data structures. >>> >>> Summary tracking data is maintained in static data structures, via >>> atomic operations. Malloc detail tracking call stacks are maintained >>> in a lock free hashtable. >>> >>> The key improvements: >>> 1. Up-to-date tracking report. >>> 2. Detail tracking now shows multiple call frames. Number of >>> frames is compilation time decision, currently default to 4. >>> 3. Malloc tracking is lock free. >>> 4. Tracking summary is reported in hs_err file when native memory >>> tracking is enabled. >>> 5. Query is faster, uses little memory and need a very little >>> process. >>> >>> The drawback is that, malloc tracking header is always needed if >>> native memory tracking has ever been enabled, even after tracking is >>> shutdown. >>> >>> Impacts: >>> The most noticeable impact for JVM developers, is that Arena now >>> also take memory type as constructor parameter, besides the new >>> operators. >>> Arena* a = new (mtCode) Arena() => Arena* a = new (mtCode) >>> Arena(mtCode) >>> >>> The webrev shows modification of about 60 files, but most of them >>> are due to tracking API changes, mainly due to tracking stack, now, >>> is an object, vs. a single pc. >>> >>> The most important files for this implementations are: >>> >>> memTracker.hpp/cpp >>> mallocTracker.hpp/cpp and mallocTracker.inline.hpp >>> virtualMemoryTracker.hpp/cpp >>> mallocSiteTable.hpp/cpp >>> >>> allocationSite.hpp >>> nativeCallStack.hpp/cpp >>> linkedlist.hpp >>> >>> >>> Tests: >>> - JPRT >>> - NMT test suite >>> - vm.quick.testlist >>> - Kitchensink stability test for 16+ days >>> - FMW >>> >>> >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046598 >>> Webrev: http://cr.openjdk.java.net/~zgu/8046598/webrev.00/ >>> >>> >>> >>> >>> Thanks, >>> >>> -Zhengyu >>> >> > From christian.tornqvist at oracle.com Wed Aug 6 13:28:43 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 6 Aug 2014 09:28:43 -0400 Subject: Updated: RFR(L) 8046598: Scalable Native memory tracking development In-Reply-To: <53DFCF6D.20903@oracle.com> References: <53C58B14.9010003@oracle.com> <53DFCF6D.20903@oracle.com> Message-ID: <015f01cfb17a$58932b00$09b98100$@oracle.com> Hi Zhengyu, Split the assert at: src/share/vm/services/memBaseline.hpp @136 As mentioned during our code review meetings, "at" is not a good name for a method and should be renamed to be more descriptive (src/share/vm/services/memTracker.cpp @242) Otherwise this looks good. Thanks, Christian -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Zhengyu Gu Sent: Monday, August 4, 2014 2:23 PM To: hotspot-dev at openjdk.java.net Subject: Updated: RFR(L) 8046598: Scalable Native memory tracking development The update is based on code review meetings with Coleen, Christian, George and Harold. http://cr.openjdk.java.net/~zgu/8046598/webrev.01/ Thanks, -Zhengyu On 7/15/2014 4:12 PM, Zhengyu Gu wrote: > This is an update to previous RFR 8028541: Native Memory Tracking > enhancement, the original one is closed as duplicate of current one. > > The update is mainly based on feedback from Coleen and Christian: > - Refactored MemReporter to break up some large functions and > eliminate duplicated code. > - Minor change to MemBaseline for eliminating duplicated code. > - Changed MEMFLAGS type from unsigned short => MemoryType. > > Also added unit tests for LinkedList. > > The note from RFR 8028541: > ========================= > This is significant rework of native memory tracking introduced in > earlier releases. > > The goal of this enhancement is to improve scalability, from both > tracking memory and CPU usage perspectives, so it can scale well with > increased memory allocation in large applications. > > The enhancement is mainly focused on malloc memory tracking, whose > activities are several magnitude higher than virtual memory, and was > the main bottleneck in early implementation. > > Instead of using book keeping records for tracking malloc activities, > new implementation co-locates tracking data along side with user data > by using a prefixed header. The header size is 8 bytes on 32-bit > systems and 16 bytes on 64-bit systems, which ensure that user data > also align properly. > > Virtual memory tracking still uses book keeping records, and > ThreadCritical lock is always acquired to alter the records and > related data structures. > > Summary tracking data is maintained in static data structures, via > atomic operations. Malloc detail tracking call stacks are maintained > in a lock free hashtable. > > The key improvements: > 1. Up-to-date tracking report. > 2. Detail tracking now shows multiple call frames. Number of frames > is compilation time decision, currently default to 4. > 3. Malloc tracking is lock free. > 4. Tracking summary is reported in hs_err file when native memory > tracking is enabled. > 5. Query is faster, uses little memory and need a very little process. > > The drawback is that, malloc tracking header is always needed if > native memory tracking has ever been enabled, even after tracking is > shutdown. > > Impacts: > The most noticeable impact for JVM developers, is that Arena now > also take memory type as constructor parameter, besides the new > operators. > Arena* a = new (mtCode) Arena() => Arena* a = new (mtCode) > Arena(mtCode) > > The webrev shows modification of about 60 files, but most of them are > due to tracking API changes, mainly due to tracking stack, now, is an > object, vs. a single pc. > > The most important files for this implementations are: > > memTracker.hpp/cpp > mallocTracker.hpp/cpp and mallocTracker.inline.hpp > virtualMemoryTracker.hpp/cpp > mallocSiteTable.hpp/cpp > > allocationSite.hpp > nativeCallStack.hpp/cpp > linkedlist.hpp > > > Tests: > - JPRT > - NMT test suite > - vm.quick.testlist > - Kitchensink stability test for 16+ days > - FMW > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8046598 > Webrev: http://cr.openjdk.java.net/~zgu/8046598/webrev.00/ > > > > > Thanks, > > -Zhengyu > From zhengyu.gu at oracle.com Wed Aug 6 14:58:31 2014 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 06 Aug 2014 10:58:31 -0400 Subject: Updated: RFR(L) 8046598: Scalable Native memory tracking development In-Reply-To: <015f01cfb17a$58932b00$09b98100$@oracle.com> References: <53C58B14.9010003@oracle.com> <53DFCF6D.20903@oracle.com> <015f01cfb17a$58932b00$09b98100$@oracle.com> Message-ID: <53E24297.2040803@oracle.com> Hi Christian, Thanks for the review. On 8/6/2014 9:28 AM, Christian Tornqvist wrote: > Hi Zhengyu, > > Split the assert at: > > src/share/vm/services/memBaseline.hpp @136 Will do. > As mentioned during our code review meetings, "at" is not a good name for a > method and should be renamed to be more descriptive > (src/share/vm/services/memTracker.cpp @242) This is a bug, should overwrite virtual function do_malloc_site(), forgot change this one. -Zhengyu > Otherwise this looks good. > > Thanks, > Christian > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of > Zhengyu Gu > Sent: Monday, August 4, 2014 2:23 PM > To: hotspot-dev at openjdk.java.net > Subject: Updated: RFR(L) 8046598: Scalable Native memory tracking > development > > The update is based on code review meetings with Coleen, Christian, George > and Harold. > > http://cr.openjdk.java.net/~zgu/8046598/webrev.01/ > > > > Thanks, > > -Zhengyu > > > > On 7/15/2014 4:12 PM, Zhengyu Gu wrote: >> This is an update to previous RFR 8028541: Native Memory Tracking >> enhancement, the original one is closed as duplicate of current one. >> >> The update is mainly based on feedback from Coleen and Christian: >> - Refactored MemReporter to break up some large functions and >> eliminate duplicated code. >> - Minor change to MemBaseline for eliminating duplicated code. >> - Changed MEMFLAGS type from unsigned short => MemoryType. >> >> Also added unit tests for LinkedList. >> >> The note from RFR 8028541: >> ========================= >> This is significant rework of native memory tracking introduced in >> earlier releases. >> >> The goal of this enhancement is to improve scalability, from both >> tracking memory and CPU usage perspectives, so it can scale well with >> increased memory allocation in large applications. >> >> The enhancement is mainly focused on malloc memory tracking, whose >> activities are several magnitude higher than virtual memory, and was >> the main bottleneck in early implementation. >> >> Instead of using book keeping records for tracking malloc activities, >> new implementation co-locates tracking data along side with user data >> by using a prefixed header. The header size is 8 bytes on 32-bit >> systems and 16 bytes on 64-bit systems, which ensure that user data >> also align properly. >> >> Virtual memory tracking still uses book keeping records, and >> ThreadCritical lock is always acquired to alter the records and >> related data structures. >> >> Summary tracking data is maintained in static data structures, via >> atomic operations. Malloc detail tracking call stacks are maintained >> in a lock free hashtable. >> >> The key improvements: >> 1. Up-to-date tracking report. >> 2. Detail tracking now shows multiple call frames. Number of frames >> is compilation time decision, currently default to 4. >> 3. Malloc tracking is lock free. >> 4. Tracking summary is reported in hs_err file when native memory >> tracking is enabled. >> 5. Query is faster, uses little memory and need a very little process. >> >> The drawback is that, malloc tracking header is always needed if >> native memory tracking has ever been enabled, even after tracking is >> shutdown. >> >> Impacts: >> The most noticeable impact for JVM developers, is that Arena now >> also take memory type as constructor parameter, besides the new >> operators. >> Arena* a = new (mtCode) Arena() => Arena* a = new (mtCode) >> Arena(mtCode) >> >> The webrev shows modification of about 60 files, but most of them are >> due to tracking API changes, mainly due to tracking stack, now, is an >> object, vs. a single pc. >> >> The most important files for this implementations are: >> >> memTracker.hpp/cpp >> mallocTracker.hpp/cpp and mallocTracker.inline.hpp >> virtualMemoryTracker.hpp/cpp >> mallocSiteTable.hpp/cpp >> >> allocationSite.hpp >> nativeCallStack.hpp/cpp >> linkedlist.hpp >> >> >> Tests: >> - JPRT >> - NMT test suite >> - vm.quick.testlist >> - Kitchensink stability test for 16+ days >> - FMW >> >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8046598 >> Webrev: http://cr.openjdk.java.net/~zgu/8046598/webrev.00/ >> >> >> >> >> Thanks, >> >> -Zhengyu >> > From morris.meyer at oracle.com Wed Aug 6 16:34:57 2014 From: morris.meyer at oracle.com (Morris Meyer) Date: Wed, 06 Aug 2014 12:34:57 -0400 Subject: [8u40] Request for Approval: Backport of c1_LinearScan.cpp parfait changeset Message-ID: <53E25931.90503@oracle.com> Folks, This is a backport of a parfait fix (8040921) to c1_LinearScan that should be backported from JDK9 to JDK 8u40. The patch integrated cleanly and has been tested with JPRT. The patches is made against: http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot Thanks! --morris meyer JBS - https://bugs.openjdk.java.net/browse/JDK-8054370 WEBREV - http://cr.openjdk.java.net/~morris/JDK-8054370.01 From george.triantafillou at oracle.com Wed Aug 6 16:40:13 2014 From: george.triantafillou at oracle.com (George Triantafillou) Date: Wed, 06 Aug 2014 12:40:13 -0400 Subject: Updated: RFR(L) 8046598: Scalable Native memory tracking development In-Reply-To: <53DFCF6D.20903@oracle.com> References: <53C58B14.9010003@oracle.com> <53DFCF6D.20903@oracle.com> Message-ID: <53E25A6D.6050909@oracle.com> Hi Zhengyu, I found some typos. Otherwise, it looks good. -George src/share/vm/services/memTracker.hpp: 142 // Launcher only obligates to pass native memory tracking 142 // Launcher only obligated to pass native memory tracking 143 // option value, but not obligates to validate the value, 143 // option value, but not obligated to validate the value, 192 // chuncks that backing up the arena. 192 // chunks backing up the arena. src/share/vm/services/mallocTracker.hpp: 181 // from total chuncks to get total free chunck size 181 // from total chunks to get total free chunk size src/share/vm/services/virtualMemoryTracker.cpp: 75 // the two adjacent regions have to same call stack, merge them 75 // the two adjacent regions have the same call stack, merge them 314 // Overalpped reservation. 314 // Overlapped reservation. src/share/vm/utilities/linkedlist.hpp: 37 // as the linked list what contains this entry. 37 // as the linked list that contains this entry. 57 // any storage type it uses, so all methods involves 57 // any storage type it uses, so all methods involving src/share/vm/services/mallocSiteTable.hpp: 73 // The operation can be failed due to contention from other thread. 73 // The operation can fail due to contention from another thread. src/share/vm/services/mallocSiteTable.cpp: 173 // contented, other thread won 173 // contended, other thread won On 8/4/2014 2:22 PM, Zhengyu Gu wrote: > The update is based on code review meetings with Coleen, Christian, > George and Harold. > > http://cr.openjdk.java.net/~zgu/8046598/webrev.01/ > > > > Thanks, > > -Zhengyu > > > > On 7/15/2014 4:12 PM, Zhengyu Gu wrote: >> This is an update to previous RFR 8028541: Native Memory Tracking >> enhancement, the original one is closed as duplicate of current one. >> >> The update is mainly based on feedback from Coleen and Christian: >> - Refactored MemReporter to break up some large functions and >> eliminate duplicated code. >> - Minor change to MemBaseline for eliminating duplicated code. >> - Changed MEMFLAGS type from unsigned short => MemoryType. >> >> Also added unit tests for LinkedList. >> >> The note from RFR 8028541: >> ========================= >> This is significant rework of native memory tracking introduced in >> earlier releases. >> >> The goal of this enhancement is to improve scalability, from both >> tracking memory and CPU usage perspectives, so it can scale well with >> increased memory allocation in large applications. >> >> The enhancement is mainly focused on malloc memory tracking, whose >> activities are several magnitude higher than virtual memory, and was >> the main bottleneck in early implementation. >> >> Instead of using book keeping records for tracking malloc activities, >> new implementation co-locates tracking data along side with user data >> by using a prefixed header. The header size is 8 bytes on 32-bit >> systems and 16 bytes on 64-bit systems, which ensure that user data >> also align properly. >> >> Virtual memory tracking still uses book keeping records, and >> ThreadCritical lock is always acquired to alter the records and >> related data structures. >> >> Summary tracking data is maintained in static data structures, via >> atomic operations. Malloc detail tracking call stacks are maintained >> in a lock free hashtable. >> >> The key improvements: >> 1. Up-to-date tracking report. >> 2. Detail tracking now shows multiple call frames. Number of frames >> is compilation time decision, currently default to 4. >> 3. Malloc tracking is lock free. >> 4. Tracking summary is reported in hs_err file when native memory >> tracking is enabled. >> 5. Query is faster, uses little memory and need a very little process. >> >> The drawback is that, malloc tracking header is always needed if >> native memory tracking has ever been enabled, even after tracking is >> shutdown. >> >> Impacts: >> The most noticeable impact for JVM developers, is that Arena now >> also take memory type as constructor parameter, besides the new >> operators. >> Arena* a = new (mtCode) Arena() => Arena* a = new (mtCode) >> Arena(mtCode) >> >> The webrev shows modification of about 60 files, but most of them are >> due to tracking API changes, mainly due to tracking stack, now, is an >> object, vs. a single pc. >> >> The most important files for this implementations are: >> >> memTracker.hpp/cpp >> mallocTracker.hpp/cpp and mallocTracker.inline.hpp >> virtualMemoryTracker.hpp/cpp >> mallocSiteTable.hpp/cpp >> >> allocationSite.hpp >> nativeCallStack.hpp/cpp >> linkedlist.hpp >> >> >> Tests: >> - JPRT >> - NMT test suite >> - vm.quick.testlist >> - Kitchensink stability test for 16+ days >> - FMW >> >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8046598 >> Webrev: http://cr.openjdk.java.net/~zgu/8046598/webrev.00/ >> >> >> >> >> Thanks, >> >> -Zhengyu >> > From zhengyu.gu at oracle.com Wed Aug 6 16:45:47 2014 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 06 Aug 2014 12:45:47 -0400 Subject: Updated: RFR(L) 8046598: Scalable Native memory tracking development In-Reply-To: <53E25A6D.6050909@oracle.com> References: <53C58B14.9010003@oracle.com> <53DFCF6D.20903@oracle.com> <53E25A6D.6050909@oracle.com> Message-ID: <53E25BBB.1040008@oracle.com> Thanks, George. I will fix them accordingly. -Zhengyu On 8/6/2014 12:40 PM, George Triantafillou wrote: > Hi Zhengyu, > > I found some typos. Otherwise, it looks good. > > -George > > src/share/vm/services/memTracker.hpp: > > 142 // Launcher only obligates to pass native memory tracking > 142 // Launcher only obligated to pass native memory tracking > > 143 // option value, but not obligates to validate the value, > 143 // option value, but not obligated to validate the value, > > 192 // chuncks that backing up the arena. > 192 // chunks backing up the arena. > > src/share/vm/services/mallocTracker.hpp: > > 181 // from total chuncks to get total free chunck size > 181 // from total chunks to get total free chunk size > > src/share/vm/services/virtualMemoryTracker.cpp: > > 75 // the two adjacent regions have to same call stack, merge them > 75 // the two adjacent regions have the same call stack, > merge them > > 314 // Overalpped reservation. > 314 // Overlapped reservation. > > src/share/vm/utilities/linkedlist.hpp: > > 37 // as the linked list what contains this entry. > 37 // as the linked list that contains this entry. > > 57 // any storage type it uses, so all methods involves > 57 // any storage type it uses, so all methods involving > > src/share/vm/services/mallocSiteTable.hpp: > > 73 // The operation can be failed due to contention from other > thread. > 73 // The operation can fail due to contention from another thread. > > src/share/vm/services/mallocSiteTable.cpp: > > 173 // contented, other thread won > 173 // contended, other thread won > > > On 8/4/2014 2:22 PM, Zhengyu Gu wrote: >> The update is based on code review meetings with Coleen, Christian, >> George and Harold. >> >> http://cr.openjdk.java.net/~zgu/8046598/webrev.01/ >> >> >> >> Thanks, >> >> -Zhengyu >> >> >> >> On 7/15/2014 4:12 PM, Zhengyu Gu wrote: >>> This is an update to previous RFR 8028541: Native Memory Tracking >>> enhancement, the original one is closed as duplicate of current one. >>> >>> The update is mainly based on feedback from Coleen and Christian: >>> - Refactored MemReporter to break up some large functions and >>> eliminate duplicated code. >>> - Minor change to MemBaseline for eliminating duplicated code. >>> - Changed MEMFLAGS type from unsigned short => MemoryType. >>> >>> Also added unit tests for LinkedList. >>> >>> The note from RFR 8028541: >>> ========================= >>> This is significant rework of native memory tracking introduced in >>> earlier releases. >>> >>> The goal of this enhancement is to improve scalability, from both >>> tracking memory and CPU usage perspectives, so it can scale well >>> with increased memory allocation in large applications. >>> >>> The enhancement is mainly focused on malloc memory tracking, whose >>> activities are several magnitude higher than virtual memory, and was >>> the main bottleneck in early implementation. >>> >>> Instead of using book keeping records for tracking malloc >>> activities, new implementation co-locates tracking data along side >>> with user data by using a prefixed header. The header size is 8 >>> bytes on 32-bit systems and 16 bytes on 64-bit systems, which ensure >>> that user data also align properly. >>> >>> Virtual memory tracking still uses book keeping records, and >>> ThreadCritical lock is always acquired to alter the records and >>> related data structures. >>> >>> Summary tracking data is maintained in static data structures, via >>> atomic operations. Malloc detail tracking call stacks are maintained >>> in a lock free hashtable. >>> >>> The key improvements: >>> 1. Up-to-date tracking report. >>> 2. Detail tracking now shows multiple call frames. Number of >>> frames is compilation time decision, currently default to 4. >>> 3. Malloc tracking is lock free. >>> 4. Tracking summary is reported in hs_err file when native memory >>> tracking is enabled. >>> 5. Query is faster, uses little memory and need a very little >>> process. >>> >>> The drawback is that, malloc tracking header is always needed if >>> native memory tracking has ever been enabled, even after tracking is >>> shutdown. >>> >>> Impacts: >>> The most noticeable impact for JVM developers, is that Arena now >>> also take memory type as constructor parameter, besides the new >>> operators. >>> Arena* a = new (mtCode) Arena() => Arena* a = new (mtCode) >>> Arena(mtCode) >>> >>> The webrev shows modification of about 60 files, but most of them >>> are due to tracking API changes, mainly due to tracking stack, now, >>> is an object, vs. a single pc. >>> >>> The most important files for this implementations are: >>> >>> memTracker.hpp/cpp >>> mallocTracker.hpp/cpp and mallocTracker.inline.hpp >>> virtualMemoryTracker.hpp/cpp >>> mallocSiteTable.hpp/cpp >>> >>> allocationSite.hpp >>> nativeCallStack.hpp/cpp >>> linkedlist.hpp >>> >>> >>> Tests: >>> - JPRT >>> - NMT test suite >>> - vm.quick.testlist >>> - Kitchensink stability test for 16+ days >>> - FMW >>> >>> >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046598 >>> Webrev: http://cr.openjdk.java.net/~zgu/8046598/webrev.00/ >>> >>> >>> >>> >>> Thanks, >>> >>> -Zhengyu >>> >> > From vladimir.kozlov at oracle.com Wed Aug 6 16:59:12 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 06 Aug 2014 09:59:12 -0700 Subject: [8u40] Request for Approval: Backport of c1_LinearScan.cpp parfait changeset In-Reply-To: <53E25931.90503@oracle.com> References: <53E25931.90503@oracle.com> Message-ID: <53E25EE0.10408@oracle.com> Morris, Changes are good to backport. For the future backport requests: In the Subject you need to specify bug id (original 8040921) - the same way as in original RFR. The link should be to original bug JBS entry and original 8040921 webrev. You don't need to create special webrev for backport if it is applied cleanly. You should not mention backport bug id at all because bug's description is in main bug report. You have to show the link to the changeset in jdk9 instead of jdk8 repo: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/472cdcd429be Thanks, Vladimir On 8/6/14 9:34 AM, Morris Meyer wrote: > Folks, > > This is a backport of a parfait fix (8040921) to c1_LinearScan that should be backported from JDK9 to JDK 8u40. > > The patch integrated cleanly and has been tested with JPRT. > > The patches is made against: > http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot > > Thanks! > > --morris meyer > > JBS - https://bugs.openjdk.java.net/browse/JDK-8054370 > WEBREV - http://cr.openjdk.java.net/~morris/JDK-8054370.01 > From stefan.karlsson at oracle.com Thu Aug 7 08:28:07 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 07 Aug 2014 10:28:07 +0200 Subject: [8u40] Request for Approval: Backport of G1 Class Unloading changesets In-Reply-To: <53E22187.2070502@oracle.com> References: <53E22187.2070502@oracle.com> Message-ID: <53E33897.5020306@oracle.com> On 2014-08-06 14:37, Stefan Karlsson wrote: > Hi all, > > This is the set of G1 Class Unloading backport patches that should be > backported from JDK 9 to JDK 8u40. > > I've described how well the backports applied and some useful links to > the webrevs, bugs, and JDK 9 changesets. IMHO, the only backport that > is worth looking at in more detail is the changeset that adds G1 Class > Unloading: 8049421, however I think the process mandates that we > re-review the patches that failed. Could the old reviewers help out > reviewing the changes marked as failed below? > > The patches are applied in order, against: > http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot > > Patches: > > http://cr.openjdk.java.net/~stefank/backports/8u40/8034761 > http://bugs.openjdk.java.net/bugs/browse/JDK-8032379 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/870aedf4ba4f > 8032379: Remove the is_scavenging flag to process_strong_roots > Reviewed-by: stefank, tschatzl, ehelin, jmasa > clean > > http://cr.openjdk.java.net/~stefank/backports/8u40/8033764 > http://bugs.openjdk.java.net/bugs/browse/JDK-8033764 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/937cf56dede6 > 8033764: Remove the usage of StarTask from BufferingOopClosure > Reviewed-by: mgerdin, brutisso, tschatzl > failed > jni.cpp: New unit tests had been added. > > http://cr.openjdk.java.net/~stefank/backports/8u40/8033923 > http://bugs.openjdk.java.net/bugs/browse/JDK-8033923 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/79aa45434291 > 8033923: Use BufferingOopClosure for G1 code root scanning > Reviewed-by: mgerdin, brutisso > clean > > http://cr.openjdk.java.net/~stefank/backports/8u40/8034761 > http://bugs.openjdk.java.net/bugs/browse/JDK-8034761 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/d166675568f6 > 8034761: Remove the do_code_roots parameter from process_strong_roots > Reviewed-by: tschatzl, mgerdin, jmasa > failed > g1CollectedHeap.hpp: A function had been removed. > > http://cr.openjdk.java.net/~stefank/backports/8u40/8034764 > http://bugs.openjdk.java.net/bugs/browse/JDK-8034764 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/10c424c5a362 > 8034764: Use process_strong_roots to adjust the StringTable > Reviewed-by: tschatzl, brutisso > clean > > http://cr.openjdk.java.net/~stefank/backports/8u40/8035393 > http://bugs.openjdk.java.net/bugs/browse/JDK-8035393 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/be0ac0e8f6e7 > 8035393: Use CLDClosure instead of CLDToOopClosure in > frame::oops_interpreted_do > Reviewed-by: tschatzl, coleenp > fuzz > thread.cpp > > http://cr.openjdk.java.net/~stefank/backports/8u40/8035412 > http://bugs.openjdk.java.net/bugs/browse/JDK-8035412 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/3cdda110bbb5 > 8035412: Cleanup ClassLoaderData::is_alive > Reviewed-by: coleenp, mgerdin > clean > > http://cr.openjdk.java.net/~stefank/backports/8u40/8035648 > http://bugs.openjdk.java.net/bugs/browse/JDK-8035648 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/301df27023d4 > 8035648: Don't use Handle in java_lang_String::print > Reviewed-by: coleenp, pliden > clean > > http://cr.openjdk.java.net/~stefank/backports/8u40/8035746 > http://bugs.openjdk.java.net/bugs/browse/JDK-8035746 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/7f0e0366ec81 > 8035746: Add missing Klass::oop_is_instanceClassLoader() function > Reviewed-by: mgerdin, coleenp > clean > > http://cr.openjdk.java.net/~stefank/backports/8u40/8037958 > http://bugs.openjdk.java.net/bugs/browse/JDK-8037958 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/85151870938f > 8037958: ConcurrentMark::cleanup leaks BitMaps if VerifyDuringGC is > enabled > Reviewed-by: stefank, sjohanss > clean > > http://cr.openjdk.java.net/~stefank/backports/8u40/8037958 > http://bugs.openjdk.java.net/bugs/browse/JDK-8037958 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/f3d21f161945 > 8037958: ConcurrentMark::cleanup leaks BitMaps if VerifyDuringGC is > enabled > Reviewed-by: tschatzl, stefank > failed > space.cpp: New PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC interfered Thomas Schatzl noticed that this was wrong. The correct info for this changeset should be: http://cr.openjdk.java.net/~stefank/backports/8u40/8038399 https://bugs.openjdk.java.net/browse/JDK-8038399 http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/f3d21f161945 8038399: Remove dead oop_iterate MemRegion variants from SharedHeap, Generation and Space classes Reviewed-by: tschatzl, stefank failed space.cpp: New PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC interfered thanks, StefanK > > http://cr.openjdk.java.net/~stefank/backports/8u40/8038404 > http://bugs.openjdk.java.net/bugs/browse/JDK-8038404 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/10a57200ca89 > 8038404: Move object_iterate_mem from Space to CMS since it is only > ever used by CMS > Reviewed-by: brutisso, tschatzl, stefank > clean > > http://cr.openjdk.java.net/~stefank/backports/8u40/8038412 > http://bugs.openjdk.java.net/bugs/browse/JDK-8038412 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/f0fb74dd59fe > 8038412: Move object_iterate_careful down from Space to ContigousSpace > and CFLSpace > Reviewed-by: tschatzl, stefank > failed > compactibleFreeListSpace.hpp: Spelling fixes interfered > space.hpp: Spelling fixes interfered > > http://cr.openjdk.java.net/~stefank/backports/8u40/8038405 > http://bugs.openjdk.java.net/bugs/browse/JDK-8038405 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/53e2a1b32a62 > 8038405: Clean up some virtual fucntions in Space class hierarchy > Reviewed-by: stefank, jmasa > fuzz > space.hpp > > http://cr.openjdk.java.net/~stefank/backports/8u40/8046670 > http://bugs.openjdk.java.net/bugs/browse/JDK-8046670 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/f88e914539ff > 8046670: Make CMS metadata aware closures applicable for other collectors > Reviewed-by: ehelin, mgerdin > failed > cmsOopClosures.hpp: Spelling fixes interfered > > http://cr.openjdk.java.net/~stefank/backports/8u40/8047373 > http://bugs.openjdk.java.net/bugs/browse/JDK-8047373 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/1b23c821b5e4 > 8047373: Clean the ExceptionCache in one pass > Reviewed-by: jmasa, jwilhelm > clean > > http://cr.openjdk.java.net/~stefank/backports/8u40/8047323 > http://bugs.openjdk.java.net/bugs/browse/JDK-8047323 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/b179be81195e > 8047323: Remove unused _copy_metadata_obj_cl in G1CopyingKeepAliveClosure > Reviewed-by: mgerdin, tschatzl > fuzz > g1CollectedHeap.cpp > > http://cr.openjdk.java.net/~stefank/backports/8u40/8047326 > http://bugs.openjdk.java.net/bugs/browse/JDK-8047326 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/9960da40c13e > 8047326: Consolidate all CompiledIC::CompiledIC implementations and > move it to compiledIC.cpp > Reviewed-by: vlivanov, ehelin > clean > > http://cr.openjdk.java.net/~stefank/backports/8u40/8047819 > http://bugs.openjdk.java.net/bugs/browse/JDK-8047819 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/3f70ca73367d > 8047819: G1 HeapRegionDCTOC does not need to inherit ContiguousSpaceDCTOC > Reviewed-by: stefank, tschatzl > clean > > http://cr.openjdk.java.net/~stefank/backports/8u40/8047820 > http://bugs.openjdk.java.net/bugs/browse/JDK-8047820 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/238820b522f3 > 8047820: G1 Block offset table does not need to support generic Space > classes > Reviewed-by: tschatzl, stefank > clean > > http://cr.openjdk.java.net/~stefank/backports/8u40/8047821 > http://bugs.openjdk.java.net/bugs/browse/JDK-8047821 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/a326a6240e90 > 8047821: G1 Does not use the save_marks functionality as intended > Reviewed-by: stefank, ehelin > clean > > http://cr.openjdk.java.net/~stefank/backports/8u40/8048214 > http://bugs.openjdk.java.net/bugs/browse/JDK-8048214 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/d8d107be209c > 8048214: Linker error when compiling G1SATBCardTableModRefBS after > include order changes > Reviewed-by: stefank, brutisso, tschatzl > clean > > http://cr.openjdk.java.net/~stefank/backports/8u40/8047818 > http://bugs.openjdk.java.net/bugs/browse/JDK-8047818 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/f937359961e9 > 8047818: G1 HeapRegions can no longer be ContiguousSpaces > Reviewed-by: stefank, jmasa, tschatzl > failed > heapRegion.cpp: This line is removed in JDK9: if (cl->abort()) > return cur; > heapRegion.cpp: Spelling fixes interfered > > http://cr.openjdk.java.net/~stefank/backports/8u40/8047362 > http://bugs.openjdk.java.net/bugs/browse/JDK-8047362 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/1d62ae819013 > 8047362: Add a version of CompiledIC_at that doesn't create a new > RelocIterator > Reviewed-by: iveresov, mgerdin > clean > > http://cr.openjdk.java.net/~stefank/backports/8u40/8049421 > http://bugs.openjdk.java.net/bugs/browse/JDK-8049421 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/a2122d7912ed > 8049421: G1 Class Unloading after completing a concurrent mark cycle > Reviewed-by: tschatzl, ehelin, brutisso, coleenp, roland, iveresov > failed > classLoaderData.hpp: cld_do is missing in 8u > stringTable.cpp: All code in stringTable.cpp is > in symbolTable.cpp in 8u. > concurrentMarkSweepGeneration.cpp: Spelling fixes interfered > concurrentMark.cpp: Spelling fixes interfered > concurrentMark.cpp: check_bitmaps calls have been > added to 9 > g1CollectedHeap.cpp: check_bitmaps calls have been > added to 9 > g1CollectedHeap.hpp: Spelling fixes interfered > whitebox.cpp: Different includes in 9 and 8u > whitebox.cpp: WB_GetThreadStackSize is not in 8u > > http://cr.openjdk.java.net/~stefank/backports/8u40/8049426 > http://bugs.openjdk.java.net/bugs/browse/JDK-8049426 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/7fdf4173cde4 > 8049426: Minor cleanups after G1 class unloading > Reviewed-by: stefank, brutisso > clean > > http://cr.openjdk.java.net/~stefank/backports/8u40/8049831 > http://bugs.openjdk.java.net/bugs/browse/JDK-8049831 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/429516ef23de > 8049831: Metadata Full GCs are not triggered when > CMSClassUnloadingEnabled is turned off > Reviewed-by: brutisso, tschatzl, ehelin, jmasa, dfazunen > failed > TEST.groups: There's no needs_cmsgc section in 8u > > http://cr.openjdk.java.net/~stefank/backports/8u40/8051883 > http://bugs.openjdk.java.net/bugs/browse/JDK-8051883 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/14e40cb29ca9 > 8051883: TEST.groups references missing test: > gc/class_unloading/TestCMSClassUnloadingDisabledHWM.java > Reviewed-by: brutisso, tschatzl, ehelin, jmasa, dfazunen > clean > > http://cr.openjdk.java.net/~stefank/backports/8u40/8048269 > http://bugs.openjdk.java.net/bugs/browse/JDK-8048269 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/9d38e660fc7a > 8048269: Add flag to turn off class unloading after G1 concurrent mark > Reviewed-by: jmasa, brutisso, mgerdin > failed > TEST.groups: There's no needs_g1gc section in 8u > > > I've tested the patches with JPRT, specjbb2005, Kitchensink, > specjvm98, dacapo2006, specjbb2000, gclockertest, gcbasher. > > thanks, > StefanK From bengt.rutisson at oracle.com Thu Aug 7 08:48:45 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 07 Aug 2014 10:48:45 +0200 Subject: [8u40] Request for Approval: Backport of G1 Class Unloading changesets In-Reply-To: <53E33897.5020306@oracle.com> References: <53E22187.2070502@oracle.com> <53E33897.5020306@oracle.com> Message-ID: <53E33D6D.3040203@oracle.com> Hi, Sat down with StefanK and went though the changesets that I had reviewed for JDK 9. They all look good. 8033764: Remove the usage of StarTask from BufferingOopClosure 8046670: Make CMS metadata aware closures applicable for other collectors 8049831: Metadata Full GCs are not triggered when CMSClassUnloadingEnabled is turned off 8048269: Add flag to turn off class unloading after G1 concurrent mark 8049421: G1 Class Unloading after completing a concurrent mark cycle Thanks, Bengt On 2014-08-07 10:28, Stefan Karlsson wrote: > > On 2014-08-06 14:37, Stefan Karlsson wrote: >> Hi all, >> >> This is the set of G1 Class Unloading backport patches that should be >> backported from JDK 9 to JDK 8u40. >> >> I've described how well the backports applied and some useful links >> to the webrevs, bugs, and JDK 9 changesets. IMHO, the only backport >> that is worth looking at in more detail is the changeset that adds G1 >> Class Unloading: 8049421, however I think the process mandates that >> we re-review the patches that failed. Could the old reviewers help >> out reviewing the changes marked as failed below? >> >> The patches are applied in order, against: >> http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot >> >> Patches: >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8034761 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8032379 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/870aedf4ba4f >> 8032379: Remove the is_scavenging flag to process_strong_roots >> Reviewed-by: stefank, tschatzl, ehelin, jmasa >> clean >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8033764 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8033764 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/937cf56dede6 >> 8033764: Remove the usage of StarTask from BufferingOopClosure >> Reviewed-by: mgerdin, brutisso, tschatzl >> failed >> jni.cpp: New unit tests had been added. >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8033923 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8033923 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/79aa45434291 >> 8033923: Use BufferingOopClosure for G1 code root scanning >> Reviewed-by: mgerdin, brutisso >> clean >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8034761 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8034761 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/d166675568f6 >> 8034761: Remove the do_code_roots parameter from process_strong_roots >> Reviewed-by: tschatzl, mgerdin, jmasa >> failed >> g1CollectedHeap.hpp: A function had been removed. >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8034764 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8034764 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/10c424c5a362 >> 8034764: Use process_strong_roots to adjust the StringTable >> Reviewed-by: tschatzl, brutisso >> clean >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8035393 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8035393 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/be0ac0e8f6e7 >> 8035393: Use CLDClosure instead of CLDToOopClosure in >> frame::oops_interpreted_do >> Reviewed-by: tschatzl, coleenp >> fuzz >> thread.cpp >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8035412 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8035412 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/3cdda110bbb5 >> 8035412: Cleanup ClassLoaderData::is_alive >> Reviewed-by: coleenp, mgerdin >> clean >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8035648 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8035648 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/301df27023d4 >> 8035648: Don't use Handle in java_lang_String::print >> Reviewed-by: coleenp, pliden >> clean >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8035746 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8035746 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/7f0e0366ec81 >> 8035746: Add missing Klass::oop_is_instanceClassLoader() function >> Reviewed-by: mgerdin, coleenp >> clean >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8037958 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8037958 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/85151870938f >> 8037958: ConcurrentMark::cleanup leaks BitMaps if VerifyDuringGC is >> enabled >> Reviewed-by: stefank, sjohanss >> clean >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8037958 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8037958 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/f3d21f161945 >> 8037958: ConcurrentMark::cleanup leaks BitMaps if VerifyDuringGC is >> enabled >> Reviewed-by: tschatzl, stefank >> failed >> space.cpp: New PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC interfered > > Thomas Schatzl noticed that this was wrong. > > The correct info for this changeset should be: > http://cr.openjdk.java.net/~stefank/backports/8u40/8038399 > https://bugs.openjdk.java.net/browse/JDK-8038399 > http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/f3d21f161945 > 8038399: Remove dead oop_iterate MemRegion variants from SharedHeap, > Generation and Space classes > Reviewed-by: tschatzl, stefank > failed > space.cpp: New PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC interfered > > thanks, > StefanK > >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8038404 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8038404 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/10a57200ca89 >> 8038404: Move object_iterate_mem from Space to CMS since it is only >> ever used by CMS >> Reviewed-by: brutisso, tschatzl, stefank >> clean >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8038412 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8038412 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/f0fb74dd59fe >> 8038412: Move object_iterate_careful down from Space to >> ContigousSpace and CFLSpace >> Reviewed-by: tschatzl, stefank >> failed >> compactibleFreeListSpace.hpp: Spelling fixes interfered >> space.hpp: Spelling fixes interfered >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8038405 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8038405 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/53e2a1b32a62 >> 8038405: Clean up some virtual fucntions in Space class hierarchy >> Reviewed-by: stefank, jmasa >> fuzz >> space.hpp >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8046670 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8046670 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/f88e914539ff >> 8046670: Make CMS metadata aware closures applicable for other >> collectors >> Reviewed-by: ehelin, mgerdin >> failed >> cmsOopClosures.hpp: Spelling fixes interfered >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8047373 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8047373 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/1b23c821b5e4 >> 8047373: Clean the ExceptionCache in one pass >> Reviewed-by: jmasa, jwilhelm >> clean >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8047323 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8047323 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/b179be81195e >> 8047323: Remove unused _copy_metadata_obj_cl in >> G1CopyingKeepAliveClosure >> Reviewed-by: mgerdin, tschatzl >> fuzz >> g1CollectedHeap.cpp >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8047326 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8047326 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/9960da40c13e >> 8047326: Consolidate all CompiledIC::CompiledIC implementations and >> move it to compiledIC.cpp >> Reviewed-by: vlivanov, ehelin >> clean >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8047819 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8047819 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/3f70ca73367d >> 8047819: G1 HeapRegionDCTOC does not need to inherit >> ContiguousSpaceDCTOC >> Reviewed-by: stefank, tschatzl >> clean >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8047820 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8047820 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/238820b522f3 >> 8047820: G1 Block offset table does not need to support generic Space >> classes >> Reviewed-by: tschatzl, stefank >> clean >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8047821 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8047821 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/a326a6240e90 >> 8047821: G1 Does not use the save_marks functionality as intended >> Reviewed-by: stefank, ehelin >> clean >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8048214 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8048214 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/d8d107be209c >> 8048214: Linker error when compiling G1SATBCardTableModRefBS after >> include order changes >> Reviewed-by: stefank, brutisso, tschatzl >> clean >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8047818 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8047818 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/f937359961e9 >> 8047818: G1 HeapRegions can no longer be ContiguousSpaces >> Reviewed-by: stefank, jmasa, tschatzl >> failed >> heapRegion.cpp: This line is removed in JDK9: if (cl->abort()) >> return cur; >> heapRegion.cpp: Spelling fixes interfered >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8047362 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8047362 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/1d62ae819013 >> 8047362: Add a version of CompiledIC_at that doesn't create a new >> RelocIterator >> Reviewed-by: iveresov, mgerdin >> clean >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8049421 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8049421 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/a2122d7912ed >> 8049421: G1 Class Unloading after completing a concurrent mark cycle >> Reviewed-by: tschatzl, ehelin, brutisso, coleenp, roland, iveresov >> failed >> classLoaderData.hpp: cld_do is missing in 8u >> stringTable.cpp: All code in stringTable.cpp is >> in symbolTable.cpp in 8u. >> concurrentMarkSweepGeneration.cpp: Spelling fixes interfered >> concurrentMark.cpp: Spelling fixes interfered >> concurrentMark.cpp: check_bitmaps calls have been >> added to 9 >> g1CollectedHeap.cpp: check_bitmaps calls have been >> added to 9 >> g1CollectedHeap.hpp: Spelling fixes interfered >> whitebox.cpp: Different includes in 9 and 8u >> whitebox.cpp: WB_GetThreadStackSize is not >> in 8u >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8049426 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8049426 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/7fdf4173cde4 >> 8049426: Minor cleanups after G1 class unloading >> Reviewed-by: stefank, brutisso >> clean >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8049831 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8049831 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/429516ef23de >> 8049831: Metadata Full GCs are not triggered when >> CMSClassUnloadingEnabled is turned off >> Reviewed-by: brutisso, tschatzl, ehelin, jmasa, dfazunen >> failed >> TEST.groups: There's no needs_cmsgc section in 8u >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8051883 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8051883 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/14e40cb29ca9 >> 8051883: TEST.groups references missing test: >> gc/class_unloading/TestCMSClassUnloadingDisabledHWM.java >> Reviewed-by: brutisso, tschatzl, ehelin, jmasa, dfazunen >> clean >> >> http://cr.openjdk.java.net/~stefank/backports/8u40/8048269 >> http://bugs.openjdk.java.net/bugs/browse/JDK-8048269 >> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/rev/9d38e660fc7a >> 8048269: Add flag to turn off class unloading after G1 concurrent mark >> Reviewed-by: jmasa, brutisso, mgerdin >> failed >> TEST.groups: There's no needs_g1gc section in 8u >> >> >> I've tested the patches with JPRT, specjbb2005, Kitchensink, >> specjvm98, dacapo2006, specjbb2000, gclockertest, gcbasher. >> >> thanks, >> StefanK > From thomas.schatzl at oracle.com Thu Aug 7 09:02:28 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 07 Aug 2014 11:02:28 +0200 Subject: [8u40] Request for Approval: Backport of G1 Class Unloading changesets In-Reply-To: <53E33D6D.3040203@oracle.com> References: <53E22187.2070502@oracle.com> <53E33897.5020306@oracle.com> <53E33D6D.3040203@oracle.com> Message-ID: <1407402148.2633.3.camel@cirrus> Hi all, On Thu, 2014-08-07 at 10:48 +0200, Bengt Rutisson wrote: > Hi, > > Sat down with StefanK and went though the changesets that I had reviewed > for JDK 9. They all look good. > > 8033764: Remove the usage of StarTask from BufferingOopClosure > 8046670: Make CMS metadata aware closures applicable for other collectors > 8049831: Metadata Full GCs are not triggered when > CMSClassUnloadingEnabled is turned off > 8048269: Add flag to turn off class unloading after G1 concurrent mark > 8049421: G1 Class Unloading after completing a concurrent mark cycle same for me for 8034761, 8038412, 8038399, and 8047818. Thanks, Thomas From stefan.karlsson at oracle.com Thu Aug 7 09:14:16 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 07 Aug 2014 11:14:16 +0200 Subject: [8u40] Request for Approval: Backport of G1 Class Unloading changesets In-Reply-To: <1407402148.2633.3.camel@cirrus> References: <53E22187.2070502@oracle.com> <53E33897.5020306@oracle.com> <53E33D6D.3040203@oracle.com> <1407402148.2633.3.camel@cirrus> Message-ID: <53E34368.5010106@oracle.com> On 2014-08-07 11:02, Thomas Schatzl wrote: > Hi all, > > On Thu, 2014-08-07 at 10:48 +0200, Bengt Rutisson wrote: >> Hi, >> >> Sat down with StefanK and went though the changesets that I had reviewed >> for JDK 9. They all look good. >> >> 8033764: Remove the usage of StarTask from BufferingOopClosure >> 8046670: Make CMS metadata aware closures applicable for other collectors >> 8049831: Metadata Full GCs are not triggered when >> CMSClassUnloadingEnabled is turned off >> 8048269: Add flag to turn off class unloading after G1 concurrent mark >> 8049421: G1 Class Unloading after completing a concurrent mark cycle > same for me for 8034761, 8038412, 8038399, and 8047818. Thanks, Thomas and Bengt. StefanK > > Thanks, > Thomas > > From tobias.hartmann at oracle.com Thu Aug 7 11:30:16 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 07 Aug 2014 13:30:16 +0200 Subject: [8u40] RFR(S): 8040121: Load variable through a pointer of an incompatible type in src/hotspot/src/share/vm: opto/output.cpp [...] Message-ID: <53E36348.1000604@oracle.com> Hi, please review this 8u40 backport request. The changes were pushed on July 29 but nightly testing showed problems with union initialization [1]. I created a new webrev including the fix for JDK-8054054 [2]. Nightly testing with the fix showed no problems. New webrev: http://cr.openjdk.java.net/~thartmann/8040121_8u/webrev.00/ Master bug: https://bugs.openjdk.java.net/browse/JDK-8040121 Old webrev: http://cr.openjdk.java.net/~thartmann/8040121/webrev.01/ Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/26057ecc544b Thanks, Tobias [1] https://bugs.openjdk.java.net/browse/JDK-8054054 [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2c26420129d9 From tobias.hartmann at oracle.com Thu Aug 7 11:30:28 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 07 Aug 2014 13:30:28 +0200 Subject: [8u40] RFR(S): 8049043: Load variable through a pointer of an incompatible type in hotspot/src/share/vm/runtime/sharedRuntimeMath.hpp Message-ID: <53E36354.7090203@oracle.com> Hi, please review this 8u40 backport request. The changes were pushed on July 29 but nightly testing showed problems with union initialization [1]. I created a new webrev including the fix for JDK-8054054 [2]. Nightly testing with the fix showed no problems. The webrev also includes the fix for JDK-8043301 [3], [4] (moves duplicate code to sharedRuntimeMath.hpp) such that the patch cleanly applies. New webrev: http://cr.openjdk.java.net/~thartmann/8049043_8u/webrev.00/ Master bug: https://bugs.openjdk.java.net/browse/JDK-8049043 Old webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.03/ Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/027c333a08ed Thanks, Tobias [1] https://bugs.openjdk.java.net/browse/JDK-8054054 [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2c26420129d9 [3] https://bugs.openjdk.java.net/browse/JDK-8043301 [4] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/886599d8f918 From igor.ignatyev at oracle.com Thu Aug 7 12:12:50 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 07 Aug 2014 16:12:50 +0400 Subject: [8u40] Request for approval: backports of 8029070(XS), 8038756(S) In-Reply-To: <53DDD5FD.2070907@oracle.com> References: <53DDD5FD.2070907@oracle.com> Message-ID: <53E36D42.8070405@oracle.com> // adding hotspot-compiler-dev at openjdk.java.net Igor On 08/03/2014 10:26 AM, Igor Ignatyev wrote: > Hi all, > > I would like to request backports of fixes for JDK-8029070[1-3] and > JDK-8038756[4-6] to 8u40. The original patches were applied cleanly. > > testing: jprt > > [1] https://bugs.openjdk.java.net/browse/JDK-8029070 > [2] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6c583aa36bc9 > [3] http://cr.openjdk.java.net/~iignatyev/8029070/webrev.01/ > [4] https://bugs.openjdk.java.net/browse/JDK-8038756 > [5] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7daf195e6193 > [6] http://cr.openjdk.java.net/~iignatyev/8038756/webrev.00/ > > Thanks, > Igor From coleen.phillimore at oracle.com Thu Aug 7 16:17:40 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 07 Aug 2014 12:17:40 -0400 Subject: RFR 8003426: Remove UseFastAccessors and UseFastEmptyMethods except for zero Message-ID: <53E3A6A4.1020303@oracle.com> Summary: These options have been long disabled in Xmixed mode because they prevent these small methods from being inlined and are subject to bit rot, and we don't need more macro assembler code to maintain and change if the constant pool cache format changes. I ran specjvm98 -Xint and there wasn't a performance improvement with these flags. Zero reportedly needs these flags for performance, so I left them in for zero. I did build zero with some other changes to make zero build (not included in this patch) though. There are PPC64 changes which Volker offered to test. Also built c++ interpreter on x86 and sparc and got same runtime error as already reported. generate_method_entry was at the wrong level of inheritance so I fixed that and made it common. There was also some duplicate comment about frame layout and calling conventions (not sure it it's correct) that I either removed because it's in frame_x86.hpp or moved to before generate_fixed_frame() where it makes more sense. Tested with JPRT, nsk, jck and hotspot jtreg tests. open webrev at http://cr.openjdk.java.net/~coleenp/8003426/ bug link https://bugs.openjdk.java.net/browse/JDK-8003426 Thanks, Coleen From vladimir.kozlov at oracle.com Thu Aug 7 17:31:48 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Aug 2014 10:31:48 -0700 Subject: [8u40] RFR(S): 8049043: Load variable through a pointer of an incompatible type in hotspot/src/share/vm/runtime/sharedRuntimeMath.hpp In-Reply-To: <53E36354.7090203@oracle.com> References: <53E36354.7090203@oracle.com> Message-ID: <53E3B804.4000209@oracle.com> Hi Tobias, I would suggest to keep all 4 fixes 8040121, 8049043, 8054054, and 8043301 are separate but push all of them together. It will help us to keep consistency with jdk9 bugs track. You can send one request for all of them together (with 4 different changesets produced by hg export/import). On 8/7/14 4:30 AM, Tobias Hartmann wrote: > Hi, > > please review this 8u40 backport request. The changes were pushed on July 29 but nightly testing showed problems with > union initialization [1]. I created a new webrev including the fix for JDK-8054054 [2]. Nightly testing with the fix > showed no problems. The webrev also includes the fix for JDK-8043301 [3], [4] (moves duplicate code to > sharedRuntimeMath.hpp) such that the patch cleanly applies. > > New webrev: http://cr.openjdk.java.net/~thartmann/8049043_8u/webrev.00/ > > Master bug: https://bugs.openjdk.java.net/browse/JDK-8049043 > Old webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.03/ > Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/027c333a08ed > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8054054 > [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2c26420129d9 > [3] https://bugs.openjdk.java.net/browse/JDK-8043301 > [4] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/886599d8f918 From vladimir.kozlov at oracle.com Thu Aug 7 17:34:03 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Aug 2014 10:34:03 -0700 Subject: [8u40] Request for approval: backports of 8029070(XS), 8038756(S) In-Reply-To: <53E36D42.8070405@oracle.com> References: <53DDD5FD.2070907@oracle.com> <53E36D42.8070405@oracle.com> Message-ID: <53E3B88B.60608@oracle.com> Looks good. Thanks, Vladimir On 8/7/14 5:12 AM, Igor Ignatyev wrote: > // adding hotspot-compiler-dev at openjdk.java.net > > Igor > > On 08/03/2014 10:26 AM, Igor Ignatyev wrote: >> Hi all, >> >> I would like to request backports of fixes for JDK-8029070[1-3] and >> JDK-8038756[4-6] to 8u40. The original patches were applied cleanly. >> >> testing: jprt >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8029070 >> [2] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6c583aa36bc9 >> [3] http://cr.openjdk.java.net/~iignatyev/8029070/webrev.01/ >> [4] https://bugs.openjdk.java.net/browse/JDK-8038756 >> [5] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7daf195e6193 >> [6] http://cr.openjdk.java.net/~iignatyev/8038756/webrev.00/ >> >> Thanks, >> Igor From igor.ignatyev at oracle.com Thu Aug 7 20:29:27 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 08 Aug 2014 00:29:27 +0400 Subject: [8u40] Request for approval: backports of 8029070(XS), 8038756(S) In-Reply-To: <53E3B88B.60608@oracle.com> References: <53DDD5FD.2070907@oracle.com> <53E36D42.8070405@oracle.com> <53E3B88B.60608@oracle.com> Message-ID: <53E3E1A7.8050004@oracle.com> Vladimir, thank you. Igor On 08/07/2014 09:34 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 8/7/14 5:12 AM, Igor Ignatyev wrote: >> // adding hotspot-compiler-dev at openjdk.java.net >> >> Igor >> >> On 08/03/2014 10:26 AM, Igor Ignatyev wrote: >>> Hi all, >>> >>> I would like to request backports of fixes for JDK-8029070[1-3] and >>> JDK-8038756[4-6] to 8u40. The original patches were applied cleanly. >>> >>> testing: jprt >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8029070 >>> [2] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6c583aa36bc9 >>> [3] http://cr.openjdk.java.net/~iignatyev/8029070/webrev.01/ >>> [4] https://bugs.openjdk.java.net/browse/JDK-8038756 >>> [5] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7daf195e6193 >>> [6] http://cr.openjdk.java.net/~iignatyev/8038756/webrev.00/ >>> >>> Thanks, >>> Igor From mark.reinhold at oracle.com Fri Aug 8 01:03:06 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 7 Aug 2014 18:03:06 -0700 (PDT) Subject: JEP 207: Leverage CPU Instructions to Improve SHA Performance on SPARC Message-ID: <20140808010306.B3BCB331C3@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/207 - Mark From NMWERTZB at up.com Fri Aug 8 01:26:57 2014 From: NMWERTZB at up.com (Nicholas M. Wertzberger) Date: Thu, 7 Aug 2014 20:26:57 -0500 Subject: AUTO: Nicholas M. Wertzberger is out of the office (returning 08/08/2014) Message-ID: I am out of the office until 08/08/2014. I am in a training class until Friday. Please contact Jason Brown for anything JAS Team related. Note: This is an automated response to your message "JEP 207: Leverage CPU Instructions to Improve SHA Performance on SPARC" sent on 8/7/2014 8:03:06 PM. This is the only notification you will receive while this person is away. ** This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies. ** From tobias.hartmann at oracle.com Fri Aug 8 07:21:12 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 08 Aug 2014 09:21:12 +0200 Subject: [8u40] RFR(S): 8049043: Load variable through a pointer of an incompatible type in hotspot/src/share/vm/runtime/sharedRuntimeMath.hpp In-Reply-To: <53E3B804.4000209@oracle.com> References: <53E36354.7090203@oracle.com> <53E3B804.4000209@oracle.com> Message-ID: <53E47A68.7070406@oracle.com> Hi Vladimir, okay, I will send a new request for all 4 fixes. Thanks, Tobias On 07.08.2014 19:31, Vladimir Kozlov wrote: > Hi Tobias, > > I would suggest to keep all 4 fixes 8040121, 8049043, 8054054, and > 8043301 are separate but push all of them together. It will help us to > keep consistency with jdk9 bugs track. > > You can send one request for all of them together (with 4 different > changesets produced by hg export/import). > > On 8/7/14 4:30 AM, Tobias Hartmann wrote: >> Hi, >> >> please review this 8u40 backport request. The changes were pushed on >> July 29 but nightly testing showed problems with >> union initialization [1]. I created a new webrev including the fix >> for JDK-8054054 [2]. Nightly testing with the fix >> showed no problems. The webrev also includes the fix for JDK-8043301 >> [3], [4] (moves duplicate code to >> sharedRuntimeMath.hpp) such that the patch cleanly applies. >> >> New webrev: http://cr.openjdk.java.net/~thartmann/8049043_8u/webrev.00/ >> >> Master bug: https://bugs.openjdk.java.net/browse/JDK-8049043 >> Old webrev: http://cr.openjdk.java.net/~thartmann/8049043/webrev.03/ >> Changeset: >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/027c333a08ed >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8054054 >> [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2c26420129d9 >> [3] https://bugs.openjdk.java.net/browse/JDK-8043301 >> [4] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/886599d8f918 From tobias.hartmann at oracle.com Fri Aug 8 07:23:10 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 08 Aug 2014 09:23:10 +0200 Subject: [8u40] RFR(S): 8040121: Load variable through a pointer of an incompatible type in src/hotspot/src/share/vm: opto/output.cpp [...] In-Reply-To: <53E36348.1000604@oracle.com> References: <53E36348.1000604@oracle.com> Message-ID: <53E47ADE.7060801@oracle.com> Hi, as Vladimir suggested for 8049043, I will send a new RFR including the backports for 8040121, 8049043, 8054054, and 8043301. Thanks, Tobias On 07.08.2014 13:30, Tobias Hartmann wrote: > Hi, > > please review this 8u40 backport request. The changes were pushed on > July 29 but nightly testing showed problems with union initialization > [1]. > > I created a new webrev including the fix for JDK-8054054 [2]. Nightly > testing with the fix showed no problems. > > New webrev: http://cr.openjdk.java.net/~thartmann/8040121_8u/webrev.00/ > > Master bug: https://bugs.openjdk.java.net/browse/JDK-8040121 > Old webrev: http://cr.openjdk.java.net/~thartmann/8040121/webrev.01/ > Changeset: > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/26057ecc544b > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8054054 > [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2c26420129d9 From tobias.hartmann at oracle.com Fri Aug 8 08:11:19 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 08 Aug 2014 10:11:19 +0200 Subject: [8u40] RFR(M): 8043301, 8040121, 8049043, 8054054 Message-ID: <53E48627.5000309@oracle.com> Hi, please review this 8u40 backport request for 8040121 [2] and 8049043 [3] including the backports of 8043301 [1] and 8054054 [4]. Nightly testing showed no problems. The patches apply cleanly to 8u40 when pushed in the sequence listed below. Webrev: http://cr.openjdk.java.net/~thartmann/parfait_8u40/webrev.00/ Thanks, Tobias [1] Remove duplicate definitions in sharedRuntimeTrans.cpp https://bugs.openjdk.java.net/browse/JDK-8043301 http://cr.openjdk.java.net/~lfoltan/bug_jdk8043301_2/ http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/886599d8f918 [2] Parfait fix https://bugs.openjdk.java.net/browse/JDK-8040121 http://cr.openjdk.java.net/~thartmann/8040121/webrev.01/ http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/26057ecc544b [3] Parfait fix https://bugs.openjdk.java.net/browse/JDK-8049043 http://cr.openjdk.java.net/~thartmann/8049043/webrev.03/ http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/027c333a08ed [4] Fix union initialization error in parfait fixes https://bugs.openjdk.java.net/browse/JDK-8054054 http://cr.openjdk.java.net/~roland/8054054/webrev.00/ http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2c26420129d9 From vladimir.kozlov at oracle.com Fri Aug 8 16:03:15 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 08 Aug 2014 09:03:15 -0700 Subject: [8u40] RFR(M): 8043301, 8040121, 8049043, 8054054 In-Reply-To: <53E48627.5000309@oracle.com> References: <53E48627.5000309@oracle.com> Message-ID: <53E4F4C3.3040905@oracle.com> Looks good. Thanks, Vladimir On 8/8/14 1:11 AM, Tobias Hartmann wrote: > Hi, > > please review this 8u40 backport request for 8040121 [2] and 8049043 [3] including the backports of 8043301 [1] and > 8054054 [4]. > > Nightly testing showed no problems. The patches apply cleanly to 8u40 when pushed in the sequence listed below. > > Webrev: http://cr.openjdk.java.net/~thartmann/parfait_8u40/webrev.00/ > > Thanks, > Tobias > > [1] Remove duplicate definitions in sharedRuntimeTrans.cpp > https://bugs.openjdk.java.net/browse/JDK-8043301 > http://cr.openjdk.java.net/~lfoltan/bug_jdk8043301_2/ > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/886599d8f918 > > [2] Parfait fix > https://bugs.openjdk.java.net/browse/JDK-8040121 > http://cr.openjdk.java.net/~thartmann/8040121/webrev.01/ > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/26057ecc544b > > [3] Parfait fix > https://bugs.openjdk.java.net/browse/JDK-8049043 > http://cr.openjdk.java.net/~thartmann/8049043/webrev.03/ > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/027c333a08ed > > [4] Fix union initialization error in parfait fixes > https://bugs.openjdk.java.net/browse/JDK-8054054 > http://cr.openjdk.java.net/~roland/8054054/webrev.00/ > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2c26420129d9 From volker.simonis at gmail.com Fri Aug 8 16:49:20 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 8 Aug 2014 18:49:20 +0200 Subject: RFR 8003426: Remove UseFastAccessors and UseFastEmptyMethods except for zero In-Reply-To: <53E3A6A4.1020303@oracle.com> References: <53E3A6A4.1020303@oracle.com> Message-ID: Hi Coleen, thank you very much for doing the ppc64 changes. I've checked the ppc64 port on Aix/Linux with both opt/dbg and template/cpp interpreter. The only two issues I found can be easily fixed (see attached patch). So for the ppc64 part of your change thumbs up from me! Regards, Volker On Thu, Aug 7, 2014 at 6:17 PM, Coleen Phillimore wrote: > Summary: These options have been long disabled in Xmixed mode because they > prevent these small methods from being inlined and are subject to bit rot, > and we don't need more macro assembler code to maintain and change if the > constant pool cache format changes. > > I ran specjvm98 -Xint and there wasn't a performance improvement with these > flags. Zero reportedly needs these flags for performance, so I left them in > for zero. I did build zero with some other changes to make zero build (not > included in this patch) though. There are PPC64 changes which Volker > offered to test. Also built c++ interpreter on x86 and sparc and got same > runtime error as already reported. > > generate_method_entry was at the wrong level of inheritance so I fixed that > and made it common. There was also some duplicate comment about frame > layout and calling conventions (not sure it it's correct) that I either > removed because it's in frame_x86.hpp or moved to before > generate_fixed_frame() where it makes more sense. > > Tested with JPRT, nsk, jck and hotspot jtreg tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8003426/ > bug link https://bugs.openjdk.java.net/browse/JDK-8003426 > > Thanks, > Coleen > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 8003426_ppc64_addon.patch Type: text/x-patch Size: 1141 bytes Desc: not available URL: From coleen.phillimore at oracle.com Fri Aug 8 17:05:10 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 08 Aug 2014 13:05:10 -0400 Subject: RFR 8003426: Remove UseFastAccessors and UseFastEmptyMethods except for zero In-Reply-To: References: <53E3A6A4.1020303@oracle.com> Message-ID: <53E50346.9000306@oracle.com> Thank you Volker! I applied your patch. Coleen On 8/8/14, 12:49 PM, Volker Simonis wrote: > Hi Coleen, > > thank you very much for doing the ppc64 changes. I've checked the > ppc64 port on Aix/Linux with both opt/dbg and template/cpp > interpreter. The only two issues I found can be easily fixed (see > attached patch). > > So for the ppc64 part of your change thumbs up from me! > > Regards, > Volker > > > > On Thu, Aug 7, 2014 at 6:17 PM, Coleen Phillimore > wrote: >> Summary: These options have been long disabled in Xmixed mode because they >> prevent these small methods from being inlined and are subject to bit rot, >> and we don't need more macro assembler code to maintain and change if the >> constant pool cache format changes. >> >> I ran specjvm98 -Xint and there wasn't a performance improvement with these >> flags. Zero reportedly needs these flags for performance, so I left them in >> for zero. I did build zero with some other changes to make zero build (not >> included in this patch) though. There are PPC64 changes which Volker >> offered to test. Also built c++ interpreter on x86 and sparc and got same >> runtime error as already reported. >> >> generate_method_entry was at the wrong level of inheritance so I fixed that >> and made it common. There was also some duplicate comment about frame >> layout and calling conventions (not sure it it's correct) that I either >> removed because it's in frame_x86.hpp or moved to before >> generate_fixed_frame() where it makes more sense. >> >> Tested with JPRT, nsk, jck and hotspot jtreg tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8003426/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8003426 >> >> Thanks, >> Coleen >> >> From vladimir.kozlov at oracle.com Fri Aug 8 22:23:07 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 08 Aug 2014 15:23:07 -0700 Subject: [8u40] backport RFR (S): 8051344: JVM crashed in Compile::start() during method parsing w/ UseRTMDeopt turned on Message-ID: <53E54DCB.6070807@oracle.com> 8u40 backport request. The fix was pushed into jdk9 more then week ago and nightly testing shows no related problems. Changes from jdk9 applied to 8u without conflicts. Tested with new test. http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4f55d92a7b97 https://bugs.openjdk.java.net/browse/JDK-8051344 http://cr.openjdk.java.net/~fzhinkin/8051344/webrev.01/ Thanks, Vladimir From vladimir.kozlov at oracle.com Fri Aug 8 23:09:37 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 08 Aug 2014 16:09:37 -0700 Subject: RFR 8003426: Remove UseFastAccessors and UseFastEmptyMethods except for zero In-Reply-To: <53E3A6A4.1020303@oracle.com> References: <53E3A6A4.1020303@oracle.com> Message-ID: <53E558B1.9080000@oracle.com> Nice cleanup. Looks good to me. Thanks, Vladimir On 8/7/14 9:17 AM, Coleen Phillimore wrote: > Summary: These options have been long disabled in Xmixed mode because > they prevent these small methods from being inlined and are subject to > bit rot, and we don't need more macro assembler code to maintain and > change if the constant pool cache format changes. > > I ran specjvm98 -Xint and there wasn't a performance improvement with > these flags. Zero reportedly needs these flags for performance, so I > left them in for zero. I did build zero with some other changes to make > zero build (not included in this patch) though. There are PPC64 changes > which Volker offered to test. Also built c++ interpreter on x86 and > sparc and got same runtime error as already reported. > > generate_method_entry was at the wrong level of inheritance so I fixed > that and made it common. There was also some duplicate comment about > frame layout and calling conventions (not sure it it's correct) that I > either removed because it's in frame_x86.hpp or moved to before > generate_fixed_frame() where it makes more sense. > > Tested with JPRT, nsk, jck and hotspot jtreg tests. > > open webrev at http://cr.openjdk.java.net/~coleenp/8003426/ > bug link https://bugs.openjdk.java.net/browse/JDK-8003426 > > Thanks, > Coleen > > From mike.duigou at oracle.com Sat Aug 9 00:23:54 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 8 Aug 2014 17:23:54 -0700 Subject: RFR: 8047952 : (s) Remove FORTIFY_SOURCE from fastdebug and slowdebug builds Message-ID: <40C6E590-CE6C-4782-8C4A-5736E3075B90@oracle.com> Hello all; A previous version of this changeset was focused on disabling FORTIFY_SOURCE only for specific files with optimization disabled. This version entirely disables FORTIFY_SOURCE for all portions of the build. After additional problems; incompatibility of FORTIFY_SOURCE with -O0, lack of consistent support for FORTIFY_SOURCE in some distributions of glibc, etc. this seems like the best course. Should the separate issues with -Od be resolved then FORTIFY_SOURCE could be re-enabled selectively for specific platforms. webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047952/1/webrev/ jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047952 Mike From coleen.phillimore at oracle.com Sat Aug 9 00:29:49 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 08 Aug 2014 20:29:49 -0400 Subject: RFR 8003426: Remove UseFastAccessors and UseFastEmptyMethods except for zero In-Reply-To: <53E558B1.9080000@oracle.com> References: <53E3A6A4.1020303@oracle.com> <53E558B1.9080000@oracle.com> Message-ID: <53E56B7D.4010005@oracle.com> On 8/8/14, 7:09 PM, Vladimir Kozlov wrote: > Nice cleanup. Looks good to me. Thank you! Coleen > > Thanks, > Vladimir > > On 8/7/14 9:17 AM, Coleen Phillimore wrote: >> Summary: These options have been long disabled in Xmixed mode because >> they prevent these small methods from being inlined and are subject to >> bit rot, and we don't need more macro assembler code to maintain and >> change if the constant pool cache format changes. >> >> I ran specjvm98 -Xint and there wasn't a performance improvement with >> these flags. Zero reportedly needs these flags for performance, so I >> left them in for zero. I did build zero with some other changes to make >> zero build (not included in this patch) though. There are PPC64 changes >> which Volker offered to test. Also built c++ interpreter on x86 and >> sparc and got same runtime error as already reported. >> >> generate_method_entry was at the wrong level of inheritance so I fixed >> that and made it common. There was also some duplicate comment about >> frame layout and calling conventions (not sure it it's correct) that I >> either removed because it's in frame_x86.hpp or moved to before >> generate_fixed_frame() where it makes more sense. >> >> Tested with JPRT, nsk, jck and hotspot jtreg tests. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8003426/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8003426 >> >> Thanks, >> Coleen >> >> From yugy23 at 163.com Sat Aug 9 15:16:00 2014 From: yugy23 at 163.com (yugy23) Date: Sat, 9 Aug 2014 23:16:00 +0800 Subject: Glad to join in hotspot-dev@openjdk.java.net mail list Message-ID: <201408092315588764489@163.com> It's my pleasure to be a memeber of hotspot-dev at openjdk.java.net mail list! 2014-08-09 yugy23 From david.holmes at oracle.com Mon Aug 11 02:28:12 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Aug 2014 12:28:12 +1000 Subject: RFR: 8047952 : (s) Remove FORTIFY_SOURCE from fastdebug and slowdebug builds In-Reply-To: <40C6E590-CE6C-4782-8C4A-5736E3075B90@oracle.com> References: <40C6E590-CE6C-4782-8C4A-5736E3075B90@oracle.com> Message-ID: <53E82A3C.5040806@oracle.com> On 9/08/2014 10:23 AM, Mike Duigou wrote: > Hello all; > > A previous version of this changeset was focused on disabling FORTIFY_SOURCE only for specific files with optimization disabled. This version entirely disables FORTIFY_SOURCE for all portions of the build. After additional problems; incompatibility of FORTIFY_SOURCE with -O0, lack of consistent support for FORTIFY_SOURCE in some distributions of glibc, etc. this seems like the best course. Should the separate issues with -Od be resolved then FORTIFY_SOURCE could be re-enabled selectively for specific platforms. > > webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047952/1/webrev/ > jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047952 Thanks Mike. Looks like a clean removal to me. David > Mike > From tobias.hartmann at oracle.com Mon Aug 11 04:50:51 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 11 Aug 2014 06:50:51 +0200 Subject: [8u40] RFR(M): 8043301, 8040121, 8049043, 8054054 In-Reply-To: <53E4F4C3.3040905@oracle.com> References: <53E48627.5000309@oracle.com> <53E4F4C3.3040905@oracle.com> Message-ID: <53E84BAB.50105@oracle.com> Thank you, Vladimir. Best, Tobias On 08.08.2014 18:03, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 8/8/14 1:11 AM, Tobias Hartmann wrote: >> Hi, >> >> please review this 8u40 backport request for 8040121 [2] and 8049043 >> [3] including the backports of 8043301 [1] and >> 8054054 [4]. >> >> Nightly testing showed no problems. The patches apply cleanly to 8u40 >> when pushed in the sequence listed below. >> >> Webrev: http://cr.openjdk.java.net/~thartmann/parfait_8u40/webrev.00/ >> >> Thanks, >> Tobias >> >> [1] Remove duplicate definitions in sharedRuntimeTrans.cpp >> https://bugs.openjdk.java.net/browse/JDK-8043301 >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8043301_2/ >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/886599d8f918 >> >> [2] Parfait fix >> https://bugs.openjdk.java.net/browse/JDK-8040121 >> http://cr.openjdk.java.net/~thartmann/8040121/webrev.01/ >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/26057ecc544b >> >> [3] Parfait fix >> https://bugs.openjdk.java.net/browse/JDK-8049043 >> http://cr.openjdk.java.net/~thartmann/8049043/webrev.03/ >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/027c333a08ed >> >> [4] Fix union initialization error in parfait fixes >> https://bugs.openjdk.java.net/browse/JDK-8054054 >> http://cr.openjdk.java.net/~roland/8054054/webrev.00/ >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2c26420129d9 From roland.westrelin at oracle.com Mon Aug 11 07:34:21 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 11 Aug 2014 09:34:21 +0200 Subject: [8u40] backport RFR (S): 8051344: JVM crashed in Compile::start() during method parsing w/ UseRTMDeopt turned on In-Reply-To: <53E54DCB.6070807@oracle.com> References: <53E54DCB.6070807@oracle.com> Message-ID: Ok. Roland. On Aug 9, 2014, at 12:23 AM, Vladimir Kozlov wrote: > 8u40 backport request. The fix was pushed into jdk9 more then week ago and nightly testing shows no related problems. > > Changes from jdk9 applied to 8u without conflicts. Tested with new test. > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4f55d92a7b97 > https://bugs.openjdk.java.net/browse/JDK-8051344 > http://cr.openjdk.java.net/~fzhinkin/8051344/webrev.01/ > > Thanks, > Vladimir From tobias.hartmann at oracle.com Mon Aug 11 07:48:43 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 11 Aug 2014 09:48:43 +0200 Subject: [8u40] RFR(S): 8029443: 'assert(klass->is_loader_alive(_is_alive)) failed: must be alive' during VM_CollectForMetadataAllocation Message-ID: <53E8755B.9010308@oracle.com> Hi, please review this 8u40 backport request. The changes were pushed on Wednesday and nightly testing showed no problems. Changes for JDK9 applied to 8u40 without conflicts. Master bug: https://bugs.openjdk.java.net/browse/JDK-8029443 Webrev: http://cr.openjdk.java.net/~thartmann/8029443/webrev.03/ Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e6a16cb925ca Thanks, Tobias From andrey.x.zakharov at oracle.com Mon Aug 11 11:09:03 2014 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Mon, 11 Aug 2014 15:09:03 +0400 Subject: RFR: 8011397: JTREG needs to copy additional WhiteBox class file to JTwork/scratch/sun/hotspot In-Reply-To: <53D6638E.4070501@oracle.com> References: <536B7CF0.6010508@oracle.com> <2443586.qRToXKmNqX@mgerdin03> <53C5482A.9090001@oracle.com> <12779611.jBGqJ13gfp@ehelin-laptop> <53C65E4A.4020401@oracle.com> <53D6638E.4070501@oracle.com> Message-ID: <53E8A44F.5090000@oracle.com> Hi, all Is it possible to review this below webrev: http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ Bug: https://bugs.openjdk.java.net/browse/JDK-8011397 Thanks. On 28.07.2014 18:51, Andrey Zakharov wrote: > Hi, all. > I've prepared rechecked and verified fix for subject. > webrev: > http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ > Bug: > https://bugs.openjdk.java.net/browse/JDK-8011397 > > I've grep'ed workspace by sun.hotspot.WhiteBox and fixed every file. > Also I've updated copyright. > Testing was done by aurora batch 538304.ute.hs_jtreg.accept.full > It looks good. > > Thanks. > > > On 16.07.2014 15:13, Andrey Zakharov wrote: >> >> On 16.07.2014 14:39, Erik Helin wrote: >>> On Tuesday 15 July 2014 19:26:34 PM Andrey Zakharov wrote: >>>> Hi, Erik, Bengt. Could you, please, review this too. >>> Andrey, why did you only update a couple of tests to also copy >>> sun.hotspot.WhiteBox$WhiteBoxPermission? You updated 14 tests, there are >>> still 116 tests using sun.hotspot.WhiteBox. >>> >>> Why doesn't these 116 tests have to be updated? >>> >>> Thanks, >>> Erik >> Thanks Erik. Actually this first one patch 8011397.WhiteBoxPermission >> >> is correct. I will rework it and upload to webrev space. >> >> >>>> Thanks. >>>> >>>> On 15.07.2014 17:58, Mikael Gerdin wrote: >>>>> Andrey, >>>>> >>>>> On Monday 07 July 2014 20.48.21 Andrey Zakharov wrote: >>>>>> Hi ,all >>>>>> Mikael, can you please review it. >>>>> Sorry, I was on vacation last week. >>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ >>>>> Looks ok for now. We should consider revisiting this by either switching >>>>> to >>>>> @run main/bootclasspath >>>>> or >>>>> deleting the WhiteboxPermission nested class and using some other way for >>>>> permission checks (if they are at all needed). >>>>> >>>>> /Mikael >>>>> >>>>>> Thanks. >>>>>> >>>>>> On 25.06.2014 19:08, Andrey Zakharov wrote: >>>>>>> Hi, all >>>>>>> So in progress of previous email - >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> On 16.06.2014 19:57, Andrey Zakharov wrote: >>>>>>>> Hi, all >>>>>>>> So issue is that when tests with WhiteBox API has been invoked with >>>>>>>> -Xverify:all it fails with Exception java.lang.NoClassDefFoundError: >>>>>>>> sun/hotspot/WhiteBox$WhiteBoxPermission >>>>>>>> Solutions that are observed: >>>>>>>> 1. Copy WhiteBoxPermission with WhiteBox. But >>>>>>>> >>>>>>>>>> Perhaps this is a good time to get rid of ClassFileInstaller >>>>>>>> altogether? >>>>>>>> >>>>>>>> 2. Using bootclasspath to hook pre-built whitebox (due @library >>>>>>>> /testlibrary/whitebox) . Some tests has @run main/othervm, some uses >>>>>>>> ProcessBuilder. >>>>>>>> >>>>>>>> - main/othervm/bootclasspath adds ${test.src} and >>>>>>>> >>>>>>>> ${test.classes}to options. >>>>>>>> >>>>>>>> - With ProcessBuilder we can just add ${test.classes} >>>>>>>> >>>>>>>> Question here is, can it broke some tests ? While testing this, I >>>>>>>> found onlyhttps://bugs.openjdk.java.net/browse/JDK-8046231, others >>>>>>>> looks fine. >>>>>>>> >>>>>>>> 3. Make ClassFileInstaller deal with inner classes like that: >>>>>>>> diff -r 6ed24aedeef0 -r c01651363ba8 >>>>>>>> test/testlibrary/ClassFileInstaller.java >>>>>>>> --- a/test/testlibrary/ClassFileInstaller.java Thu Jun 05 19:02:56 >>>>>>>> 2014 +0400 >>>>>>>> +++ b/test/testlibrary/ClassFileInstaller.java Fri Jun 06 18:18:11 >>>>>>>> 2014 +0400 >>>>>>>> @@ -50,6 +50,16 @@ >>>>>>>> >>>>>>>> } >>>>>>>> // Create the class file >>>>>>>> Files.copy(is, p, StandardCopyOption.REPLACE_EXISTING); >>>>>>>> >>>>>>>> + >>>>>>>> + for (Class cls : >>>>>>>> Class.forName(arg).getDeclaredClasses()) { >>>>>>>> + //if (!Modifier.isStatic(cls.getModifiers())) { >>>>>>>> + String pathNameSub = >>>>>>>> cls.getCanonicalName().replace('.', '/').concat(".class"); >>>>>>>> + Path pathSub = Paths.get(pathNameSub); >>>>>>>> + InputStream streamSub = >>>>>>>> cl.getResourceAsStream(pathNameSub); >>>>>>>> + Files.copy(streamSub, pathSub, >>>>>>>> StandardCopyOption.REPLACE_EXISTING); >>>>>>>> + //} >>>>>>>> + } >>>>>>>> + >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> Works fine for ordinary classes, but fails for WhiteBox due >>>>>>>> Class.forName initiate Class. WhiteBox has "static" section, and >>>>>>>> initialization fails as it cannot bind to native methods >>>>>>>> "registerNatives" and so on. >>>>>>>> >>>>>>>> >>>>>>>> So, lets return to first one option? Just add everywhere >>>>>>>> >>>>>>>> * @run main ClassFileInstaller sun.hotspot.WhiteBox >>>>>>>> >>>>>>>> + * @run main ClassFileInstaller >>>>>>>> sun.hotspot.WhiteBox$WhiteBoxPermission >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> On 10.06.2014 19:43, Igor Ignatyev wrote: >>>>>>>>> Andrey, >>>>>>>>> >>>>>>>>> I don't like this idea, since it completely changes the tests. >>>>>>>>> 'run/othervm/bootclasspath' adds all paths from CP to BCP, so the >>>>>>>>> tests whose main idea was testing WB methods themselves (sanity, >>>>>>>>> compiler/whitebox, ...) don't check that it's possible to use WB >>>>>>>>> when the application isn't in BCP. >>>>>>>>> >>>>>>>>> Igor >>>>>>>>> >>>>>>>>> On 06/09/2014 06:59 PM, Andrey Zakharov wrote: >>>>>>>>>> Hi, everybody >>>>>>>>>> I have tested my changes on major platforms and found one bug, filed: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046231 >>>>>>>>>> Also, i did another try to make ClassFileInstaller to copy all inner >>>>>>>>>> classes within parent, but this fails for WhiteBox due its static >>>>>>>>>> "registerNatives" dependency. >>>>>>>>>> >>>>>>>>>> Please, review suggested changes: >>>>>>>>>> - replace ClassFileInstaller and run/othervm with >>>>>>>>>> >>>>>>>>>> "run/othervm/bootclasspath". >>>>>>>>>> >>>>>>>>>> bootclasspath parameter for othervm adds-Xbootclasspath/a: >>>>>>>>>> option with ${test.src} and ${test.classes}according to >>>>>>>>>> http://hg.openjdk.java.net/code-tools/jtreg/file/31003a1c46d9/src/sha >>>>>>>>>> re >>>>>>>>>> /classes/com/sun/javatest/regtest/MainAction.java. >>>>>>>>>> >>>>>>>>>> Is this suitable for our needs - give to test compiled WhiteBox? >>>>>>>>>> >>>>>>>>>> - replace explicit -Xbootclasspath option values (".") in >>>>>>>>>> >>>>>>>>>> ProcessBuilder invocations to ${test.classes} where WhiteBox has been >>>>>>>>>> compiled. >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.00/ >>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> On 23.05.2014 15:40, Andrey Zakharov wrote: >>>>>>>>>>> On 22.05.2014 12:47, Igor Ignatyev wrote: >>>>>>>>>>>> Andrey, >>>>>>>>>>>> >>>>>>>>>>>> 1. You changed dozen of tests, have you tested your changes? >>>>>>>>>>> Locally, aurora on the way. >>>>>>>>>>> >>>>>>>>>>>> 2. Your changes of year in copyright is wrong. it has to be >>>>>>>>>>>> $first_year, [$last_year, ], see Mark's email[1] for details. >>>>>>>>>>>> >>>>>>>>>>>> [1] >>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/jdk7-dev/2010-May/001321.htm >>>>>>>>>>>> l >>>>>>>>>>> Thanks, fixed. will be uploaded soon. >>>>>>>>>>> >>>>>>>>>>>> Igor >>>>>>>>>>>> >>>>>>>>>>>> On 05/21/2014 07:37 PM, Andrey Zakharov wrote: >>>>>>>>>>>>> On 13.05.2014 14:43, Andrey Zakharov wrote: >>>>>>>>>>>>>> Hi >>>>>>>>>>>>>> So here is trivial patch - >>>>>>>>>>>>>> removing ClassFileInstaller sun.hotspot.WhiteBox and adding >>>>>>>>>>>>>> main/othervm/bootclasspath >>>>>>>>>>>>>> where this needed >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also, some tests are modified as >>>>>>>>>>>>>> - "-Xbootclasspath/a:.", >>>>>>>>>>>>>> + "-Xbootclasspath/a:" + >>>>>>>>>>>>>> System.getProperty("test.classes"), >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>> webrev:http://cr.openjdk.java.net/~jwilhelm/8011397/webrev.02/ >>>>>>>>>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>> Thanks. >>>>>>>>>>>>> >>>>>>>>>>>>>> On 09.05.2014 12:13, Mikael Gerdin wrote: >>>>>>>>>>>>>>> On Thursday 08 May 2014 19.28.13 Igor Ignatyev wrote: >>>>>>>>>>>>>>>> // cc'ing hotspot-dev instaed of compiler, runtime and gc >>>>>>>>>>>>>>>> lists. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 05/08/2014 07:09 PM, Filipp Zhinkin wrote: >>>>>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I've CC'ed compiler and runtime mailing list, because you're >>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>>> affect test for other components as too. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I don't like your solution (but I'm not a reviewer, so treat >>>>>>>>>>>>>>>>> my >>>>>>>>>>>>>>>>> words >>>>>>>>>>>>>>>>> just as suggestion), >>>>>>>>>>>>>>>>> because we'll have to write more meta information for each >>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>> and it >>>>>>>>>>>>>>>>> is very easy to >>>>>>>>>>>>>>>>> forget to install WhiteBoxPermission if you don't test your >>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>> some security manager. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> From my point of view, it will be better to extend >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ClassFileInstaller >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> so it will copy not only >>>>>>>>>>>>>>>>> a class whose name was passed as an arguments, but also all >>>>>>>>>>>>>>>>> inner >>>>>>>>>>>>>>>>> classes of that class. >>>>>>>>>>>>>>>>> And if someone want copy only specified class without inner >>>>>>>>>>>>>>>>> classes, >>>>>>>>>>>>>>>>> then some option >>>>>>>>>>>>>>>>> could be added to ClassFileInstaller to force such behaviour. >>>>>>>>>>>>>>> Perhaps this is a good time to get rid of ClassFileInstaller >>>>>>>>>>>>>>> altogether? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8009117 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The reason for its existence is that the WhiteBox class needs >>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>> boot class path. >>>>>>>>>>>>>>> If we can live with having all the test's classes on the boot >>>>>>>>>>>>>>> class >>>>>>>>>>>>>>> path then >>>>>>>>>>>>>>> we could use the /bootclasspath option in jtreg as stated in >>>>>>>>>>>>>>> the RFE. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /Mikael >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Filipp. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 05/08/2014 04:47 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>> Hi! >>>>>>>>>>>>>>>>>> Suggesting patch with fixes for >>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20275/8011397 >>>>>>>>>>>>>>>>>> .t >>>>>>>>>>>>>>>>>> gz >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> patch: >>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20274/8011397 >>>>>>>>>>>>>>>>>> .W >>>>>>>>>>>>>>>>>> hiteBoxPer >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> mission >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks. >> > From igor.ignatyev at oracle.com Mon Aug 11 11:18:41 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 11 Aug 2014 15:18:41 +0400 Subject: RFR: 8011397: JTREG needs to copy additional WhiteBox class file to JTwork/scratch/sun/hotspot In-Reply-To: <53E8A44F.5090000@oracle.com> References: <536B7CF0.6010508@oracle.com> <2443586.qRToXKmNqX@mgerdin03> <53C5482A.9090001@oracle.com> <12779611.jBGqJ13gfp@ehelin-laptop> <53C65E4A.4020401@oracle.com> <53D6638E.4070501@oracle.com> <53E8A44F.5090000@oracle.com> Message-ID: <53E8A691.60803@oracle.com> Andrey, could you please look at and fix other tests which use whitebox? $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox" ./test | wc -l 139 $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox\$WhiteBoxPermission" ./test/ | wc -l 10 Thanks Igor On 08/11/2014 03:09 PM, Andrey Zakharov wrote: > Hi, all > > Is it possible to review this below > webrev: > http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ > Bug: > https://bugs.openjdk.java.net/browse/JDK-8011397 > > Thanks. > > On 28.07.2014 18:51, Andrey Zakharov wrote: >> Hi, all. >> I've prepared rechecked and verified fix for subject. >> webrev: >> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8011397 >> >> I've grep'ed workspace by sun.hotspot.WhiteBox and fixed every file. >> Also I've updated copyright. >> Testing was done by aurora batch 538304.ute.hs_jtreg.accept.full >> It looks good. >> >> Thanks. >> >> >> On 16.07.2014 15:13, Andrey Zakharov wrote: >>> >>> On 16.07.2014 14:39, Erik Helin wrote: >>>> On Tuesday 15 July 2014 19:26:34 PM Andrey Zakharov wrote: >>>>> Hi, Erik, Bengt. Could you, please, review this too. >>>> Andrey, why did you only update a couple of tests to also copy >>>> sun.hotspot.WhiteBox$WhiteBoxPermission? You updated 14 tests, there are >>>> still 116 tests using sun.hotspot.WhiteBox. >>>> >>>> Why doesn't these 116 tests have to be updated? >>>> >>>> Thanks, >>>> Erik >>> Thanks Erik. Actually this first one patch 8011397.WhiteBoxPermission >>> >>> is correct. I will rework it and upload to webrev space. >>> >>> >>>>> Thanks. >>>>> >>>>> On 15.07.2014 17:58, Mikael Gerdin wrote: >>>>>> Andrey, >>>>>> >>>>>> On Monday 07 July 2014 20.48.21 Andrey Zakharov wrote: >>>>>>> Hi ,all >>>>>>> Mikael, can you please review it. >>>>>> Sorry, I was on vacation last week. >>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ >>>>>> Looks ok for now. We should consider revisiting this by either switching >>>>>> to >>>>>> @run main/bootclasspath >>>>>> or >>>>>> deleting the WhiteboxPermission nested class and using some other way for >>>>>> permission checks (if they are at all needed). >>>>>> >>>>>> /Mikael >>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> On 25.06.2014 19:08, Andrey Zakharov wrote: >>>>>>>> Hi, all >>>>>>>> So in progress of previous email - >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> On 16.06.2014 19:57, Andrey Zakharov wrote: >>>>>>>>> Hi, all >>>>>>>>> So issue is that when tests with WhiteBox API has been invoked with >>>>>>>>> -Xverify:all it fails with Exception java.lang.NoClassDefFoundError: >>>>>>>>> sun/hotspot/WhiteBox$WhiteBoxPermission >>>>>>>>> Solutions that are observed: >>>>>>>>> 1. Copy WhiteBoxPermission with WhiteBox. But >>>>>>>>> >>>>>>>>>>> Perhaps this is a good time to get rid of ClassFileInstaller >>>>>>>>> altogether? >>>>>>>>> >>>>>>>>> 2. Using bootclasspath to hook pre-built whitebox (due @library >>>>>>>>> /testlibrary/whitebox) . Some tests has @run main/othervm, some uses >>>>>>>>> ProcessBuilder. >>>>>>>>> >>>>>>>>> - main/othervm/bootclasspath adds ${test.src} and >>>>>>>>> >>>>>>>>> ${test.classes}to options. >>>>>>>>> >>>>>>>>> - With ProcessBuilder we can just add ${test.classes} >>>>>>>>> >>>>>>>>> Question here is, can it broke some tests ? While testing this, I >>>>>>>>> found onlyhttps://bugs.openjdk.java.net/browse/JDK-8046231, others >>>>>>>>> looks fine. >>>>>>>>> >>>>>>>>> 3. Make ClassFileInstaller deal with inner classes like that: >>>>>>>>> diff -r 6ed24aedeef0 -r c01651363ba8 >>>>>>>>> test/testlibrary/ClassFileInstaller.java >>>>>>>>> --- a/test/testlibrary/ClassFileInstaller.java Thu Jun 05 19:02:56 >>>>>>>>> 2014 +0400 >>>>>>>>> +++ b/test/testlibrary/ClassFileInstaller.java Fri Jun 06 18:18:11 >>>>>>>>> 2014 +0400 >>>>>>>>> @@ -50,6 +50,16 @@ >>>>>>>>> >>>>>>>>> } >>>>>>>>> // Create the class file >>>>>>>>> Files.copy(is, p, StandardCopyOption.REPLACE_EXISTING); >>>>>>>>> >>>>>>>>> + >>>>>>>>> + for (Class cls : >>>>>>>>> Class.forName(arg).getDeclaredClasses()) { >>>>>>>>> + //if (!Modifier.isStatic(cls.getModifiers())) { >>>>>>>>> + String pathNameSub = >>>>>>>>> cls.getCanonicalName().replace('.', '/').concat(".class"); >>>>>>>>> + Path pathSub = Paths.get(pathNameSub); >>>>>>>>> + InputStream streamSub = >>>>>>>>> cl.getResourceAsStream(pathNameSub); >>>>>>>>> + Files.copy(streamSub, pathSub, >>>>>>>>> StandardCopyOption.REPLACE_EXISTING); >>>>>>>>> + //} >>>>>>>>> + } >>>>>>>>> + >>>>>>>>> >>>>>>>>> } >>>>>>>>> >>>>>>>>> } >>>>>>>>> >>>>>>>>> } >>>>>>>>> >>>>>>>>> Works fine for ordinary classes, but fails for WhiteBox due >>>>>>>>> Class.forName initiate Class. WhiteBox has "static" section, and >>>>>>>>> initialization fails as it cannot bind to native methods >>>>>>>>> "registerNatives" and so on. >>>>>>>>> >>>>>>>>> >>>>>>>>> So, lets return to first one option? Just add everywhere >>>>>>>>> >>>>>>>>> * @run main ClassFileInstaller sun.hotspot.WhiteBox >>>>>>>>> >>>>>>>>> + * @run main ClassFileInstaller >>>>>>>>> sun.hotspot.WhiteBox$WhiteBoxPermission >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> On 10.06.2014 19:43, Igor Ignatyev wrote: >>>>>>>>>> Andrey, >>>>>>>>>> >>>>>>>>>> I don't like this idea, since it completely changes the tests. >>>>>>>>>> 'run/othervm/bootclasspath' adds all paths from CP to BCP, so the >>>>>>>>>> tests whose main idea was testing WB methods themselves (sanity, >>>>>>>>>> compiler/whitebox, ...) don't check that it's possible to use WB >>>>>>>>>> when the application isn't in BCP. >>>>>>>>>> >>>>>>>>>> Igor >>>>>>>>>> >>>>>>>>>> On 06/09/2014 06:59 PM, Andrey Zakharov wrote: >>>>>>>>>>> Hi, everybody >>>>>>>>>>> I have tested my changes on major platforms and found one bug, filed: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046231 >>>>>>>>>>> Also, i did another try to make ClassFileInstaller to copy all inner >>>>>>>>>>> classes within parent, but this fails for WhiteBox due its static >>>>>>>>>>> "registerNatives" dependency. >>>>>>>>>>> >>>>>>>>>>> Please, review suggested changes: >>>>>>>>>>> - replace ClassFileInstaller and run/othervm with >>>>>>>>>>> >>>>>>>>>>> "run/othervm/bootclasspath". >>>>>>>>>>> >>>>>>>>>>> bootclasspath parameter for othervm adds-Xbootclasspath/a: >>>>>>>>>>> option with ${test.src} and ${test.classes}according to >>>>>>>>>>> http://hg.openjdk.java.net/code-tools/jtreg/file/31003a1c46d9/src/sha >>>>>>>>>>> re >>>>>>>>>>> /classes/com/sun/javatest/regtest/MainAction.java. >>>>>>>>>>> >>>>>>>>>>> Is this suitable for our needs - give to test compiled WhiteBox? >>>>>>>>>>> >>>>>>>>>>> - replace explicit -Xbootclasspath option values (".") in >>>>>>>>>>> >>>>>>>>>>> ProcessBuilder invocations to ${test.classes} where WhiteBox has been >>>>>>>>>>> compiled. >>>>>>>>>>> >>>>>>>>>>> Webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.00/ >>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> On 23.05.2014 15:40, Andrey Zakharov wrote: >>>>>>>>>>>> On 22.05.2014 12:47, Igor Ignatyev wrote: >>>>>>>>>>>>> Andrey, >>>>>>>>>>>>> >>>>>>>>>>>>> 1. You changed dozen of tests, have you tested your changes? >>>>>>>>>>>> Locally, aurora on the way. >>>>>>>>>>>> >>>>>>>>>>>>> 2. Your changes of year in copyright is wrong. it has to be >>>>>>>>>>>>> $first_year, [$last_year, ], see Mark's email[1] for details. >>>>>>>>>>>>> >>>>>>>>>>>>> [1] >>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/jdk7-dev/2010-May/001321.htm >>>>>>>>>>>>> l >>>>>>>>>>>> Thanks, fixed. will be uploaded soon. >>>>>>>>>>>> >>>>>>>>>>>>> Igor >>>>>>>>>>>>> >>>>>>>>>>>>> On 05/21/2014 07:37 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>> On 13.05.2014 14:43, Andrey Zakharov wrote: >>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>> So here is trivial patch - >>>>>>>>>>>>>>> removing ClassFileInstaller sun.hotspot.WhiteBox and adding >>>>>>>>>>>>>>> main/othervm/bootclasspath >>>>>>>>>>>>>>> where this needed >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also, some tests are modified as >>>>>>>>>>>>>>> - "-Xbootclasspath/a:.", >>>>>>>>>>>>>>> + "-Xbootclasspath/a:" + >>>>>>>>>>>>>>> System.getProperty("test.classes"), >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>> webrev:http://cr.openjdk.java.net/~jwilhelm/8011397/webrev.02/ >>>>>>>>>>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 09.05.2014 12:13, Mikael Gerdin wrote: >>>>>>>>>>>>>>>> On Thursday 08 May 2014 19.28.13 Igor Ignatyev wrote: >>>>>>>>>>>>>>>>> // cc'ing hotspot-dev instaed of compiler, runtime and gc >>>>>>>>>>>>>>>>> lists. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 05/08/2014 07:09 PM, Filipp Zhinkin wrote: >>>>>>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I've CC'ed compiler and runtime mailing list, because you're >>>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>>>> affect test for other components as too. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I don't like your solution (but I'm not a reviewer, so treat >>>>>>>>>>>>>>>>>> my >>>>>>>>>>>>>>>>>> words >>>>>>>>>>>>>>>>>> just as suggestion), >>>>>>>>>>>>>>>>>> because we'll have to write more meta information for each >>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>> and it >>>>>>>>>>>>>>>>>> is very easy to >>>>>>>>>>>>>>>>>> forget to install WhiteBoxPermission if you don't test your >>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>> some security manager. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> From my point of view, it will be better to extend >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ClassFileInstaller >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> so it will copy not only >>>>>>>>>>>>>>>>>> a class whose name was passed as an arguments, but also all >>>>>>>>>>>>>>>>>> inner >>>>>>>>>>>>>>>>>> classes of that class. >>>>>>>>>>>>>>>>>> And if someone want copy only specified class without inner >>>>>>>>>>>>>>>>>> classes, >>>>>>>>>>>>>>>>>> then some option >>>>>>>>>>>>>>>>>> could be added to ClassFileInstaller to force such behaviour. >>>>>>>>>>>>>>>> Perhaps this is a good time to get rid of ClassFileInstaller >>>>>>>>>>>>>>>> altogether? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8009117 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The reason for its existence is that the WhiteBox class needs >>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>> boot class path. >>>>>>>>>>>>>>>> If we can live with having all the test's classes on the boot >>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>> path then >>>>>>>>>>>>>>>> we could use the /bootclasspath option in jtreg as stated in >>>>>>>>>>>>>>>> the RFE. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /Mikael >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Filipp. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 05/08/2014 04:47 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>>> Hi! >>>>>>>>>>>>>>>>>>> Suggesting patch with fixes for >>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20275/8011397 >>>>>>>>>>>>>>>>>>> .t >>>>>>>>>>>>>>>>>>> gz >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> patch: >>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20274/8011397 >>>>>>>>>>>>>>>>>>> .W >>>>>>>>>>>>>>>>>>> hiteBoxPer >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> mission >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks. >>> >> > From andrey.x.zakharov at oracle.com Mon Aug 11 11:28:59 2014 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Mon, 11 Aug 2014 15:28:59 +0400 Subject: RFR: 8011397: JTREG needs to copy additional WhiteBox class file to JTwork/scratch/sun/hotspot In-Reply-To: <53E8A691.60803@oracle.com> References: <536B7CF0.6010508@oracle.com> <2443586.qRToXKmNqX@mgerdin03> <53C5482A.9090001@oracle.com> <12779611.jBGqJ13gfp@ehelin-laptop> <53C65E4A.4020401@oracle.com> <53D6638E.4070501@oracle.com> <53E8A44F.5090000@oracle.com> <53E8A691.60803@oracle.com> Message-ID: <53E8A8FB.2080505@oracle.com> Hi, Igor. I have another counts with applied patch, but it looks like couple of tests has beed added since last check. $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox\$WhiteBoxPermission" ./test/| wc -l 133 $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox" ./test/| wc -l 142 Will update patch soon. Thanks. On 11.08.2014 15:18, Igor Ignatyev wrote: > Andrey, > > could you please look at and fix other tests which use whitebox? > > $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox" ./test | > wc -l > 139 > $ grep -Rl --exclude-dir=testlibrary > "sun.hotspot.WhiteBox\$WhiteBoxPermission" ./test/ | wc -l > 10 > > Thanks > Igor > > On 08/11/2014 03:09 PM, Andrey Zakharov wrote: >> Hi, all >> >> Is it possible to review this below >> webrev: >> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8011397 >> >> Thanks. >> >> On 28.07.2014 18:51, Andrey Zakharov wrote: >>> Hi, all. >>> I've prepared rechecked and verified fix for subject. >>> webrev: >>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>> >>> I've grep'ed workspace by sun.hotspot.WhiteBox and fixed every file. >>> Also I've updated copyright. >>> Testing was done by aurora batch 538304.ute.hs_jtreg.accept.full >>> It looks good. >>> >>> Thanks. >>> >>> >>> On 16.07.2014 15:13, Andrey Zakharov wrote: >>>> >>>> On 16.07.2014 14:39, Erik Helin wrote: >>>>> On Tuesday 15 July 2014 19:26:34 PM Andrey Zakharov wrote: >>>>>> Hi, Erik, Bengt. Could you, please, review this too. >>>>> Andrey, why did you only update a couple of tests to also copy >>>>> sun.hotspot.WhiteBox$WhiteBoxPermission? You updated 14 tests, >>>>> there are >>>>> still 116 tests using sun.hotspot.WhiteBox. >>>>> >>>>> Why doesn't these 116 tests have to be updated? >>>>> >>>>> Thanks, >>>>> Erik >>>> Thanks Erik. Actually this first one patch 8011397.WhiteBoxPermission >>>> >>>> >>>> is correct. I will rework it and upload to webrev space. >>>> >>>> >>>>>> Thanks. >>>>>> >>>>>> On 15.07.2014 17:58, Mikael Gerdin wrote: >>>>>>> Andrey, >>>>>>> >>>>>>> On Monday 07 July 2014 20.48.21 Andrey Zakharov wrote: >>>>>>>> Hi ,all >>>>>>>> Mikael, can you please review it. >>>>>>> Sorry, I was on vacation last week. >>>>>>> >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ >>>>>>> Looks ok for now. We should consider revisiting this by either >>>>>>> switching >>>>>>> to >>>>>>> @run main/bootclasspath >>>>>>> or >>>>>>> deleting the WhiteboxPermission nested class and using some >>>>>>> other way for >>>>>>> permission checks (if they are at all needed). >>>>>>> >>>>>>> /Mikael >>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> On 25.06.2014 19:08, Andrey Zakharov wrote: >>>>>>>>> Hi, all >>>>>>>>> So in progress of previous email - >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> On 16.06.2014 19:57, Andrey Zakharov wrote: >>>>>>>>>> Hi, all >>>>>>>>>> So issue is that when tests with WhiteBox API has been >>>>>>>>>> invoked with >>>>>>>>>> -Xverify:all it fails with Exception >>>>>>>>>> java.lang.NoClassDefFoundError: >>>>>>>>>> sun/hotspot/WhiteBox$WhiteBoxPermission >>>>>>>>>> Solutions that are observed: >>>>>>>>>> 1. Copy WhiteBoxPermission with WhiteBox. But >>>>>>>>>> >>>>>>>>>>>> Perhaps this is a good time to get rid of ClassFileInstaller >>>>>>>>>> altogether? >>>>>>>>>> >>>>>>>>>> 2. Using bootclasspath to hook pre-built whitebox (due @library >>>>>>>>>> /testlibrary/whitebox) . Some tests has @run main/othervm, >>>>>>>>>> some uses >>>>>>>>>> ProcessBuilder. >>>>>>>>>> >>>>>>>>>> - main/othervm/bootclasspath adds ${test.src} and >>>>>>>>>> >>>>>>>>>> ${test.classes}to options. >>>>>>>>>> >>>>>>>>>> - With ProcessBuilder we can just add ${test.classes} >>>>>>>>>> >>>>>>>>>> Question here is, can it broke some tests ? While testing >>>>>>>>>> this, I >>>>>>>>>> found onlyhttps://bugs.openjdk.java.net/browse/JDK-8046231, >>>>>>>>>> others >>>>>>>>>> looks fine. >>>>>>>>>> >>>>>>>>>> 3. Make ClassFileInstaller deal with inner classes like that: >>>>>>>>>> diff -r 6ed24aedeef0 -r c01651363ba8 >>>>>>>>>> test/testlibrary/ClassFileInstaller.java >>>>>>>>>> --- a/test/testlibrary/ClassFileInstaller.java Thu Jun 05 >>>>>>>>>> 19:02:56 >>>>>>>>>> 2014 +0400 >>>>>>>>>> +++ b/test/testlibrary/ClassFileInstaller.java Fri Jun 06 >>>>>>>>>> 18:18:11 >>>>>>>>>> 2014 +0400 >>>>>>>>>> @@ -50,6 +50,16 @@ >>>>>>>>>> >>>>>>>>>> } >>>>>>>>>> // Create the class file >>>>>>>>>> Files.copy(is, p, >>>>>>>>>> StandardCopyOption.REPLACE_EXISTING); >>>>>>>>>> >>>>>>>>>> + >>>>>>>>>> + for (Class cls : >>>>>>>>>> Class.forName(arg).getDeclaredClasses()) { >>>>>>>>>> + //if (!Modifier.isStatic(cls.getModifiers())) { >>>>>>>>>> + String pathNameSub = >>>>>>>>>> cls.getCanonicalName().replace('.', '/').concat(".class"); >>>>>>>>>> + Path pathSub = Paths.get(pathNameSub); >>>>>>>>>> + InputStream streamSub = >>>>>>>>>> cl.getResourceAsStream(pathNameSub); >>>>>>>>>> + Files.copy(streamSub, pathSub, >>>>>>>>>> StandardCopyOption.REPLACE_EXISTING); >>>>>>>>>> + //} >>>>>>>>>> + } >>>>>>>>>> + >>>>>>>>>> >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> Works fine for ordinary classes, but fails for WhiteBox due >>>>>>>>>> Class.forName initiate Class. WhiteBox has "static" section, and >>>>>>>>>> initialization fails as it cannot bind to native methods >>>>>>>>>> "registerNatives" and so on. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> So, lets return to first one option? Just add everywhere >>>>>>>>>> >>>>>>>>>> * @run main ClassFileInstaller sun.hotspot.WhiteBox >>>>>>>>>> >>>>>>>>>> + * @run main ClassFileInstaller >>>>>>>>>> sun.hotspot.WhiteBox$WhiteBoxPermission >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> On 10.06.2014 19:43, Igor Ignatyev wrote: >>>>>>>>>>> Andrey, >>>>>>>>>>> >>>>>>>>>>> I don't like this idea, since it completely changes the tests. >>>>>>>>>>> 'run/othervm/bootclasspath' adds all paths from CP to BCP, >>>>>>>>>>> so the >>>>>>>>>>> tests whose main idea was testing WB methods themselves >>>>>>>>>>> (sanity, >>>>>>>>>>> compiler/whitebox, ...) don't check that it's possible to >>>>>>>>>>> use WB >>>>>>>>>>> when the application isn't in BCP. >>>>>>>>>>> >>>>>>>>>>> Igor >>>>>>>>>>> >>>>>>>>>>> On 06/09/2014 06:59 PM, Andrey Zakharov wrote: >>>>>>>>>>>> Hi, everybody >>>>>>>>>>>> I have tested my changes on major platforms and found one >>>>>>>>>>>> bug, filed: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046231 >>>>>>>>>>>> Also, i did another try to make ClassFileInstaller to copy >>>>>>>>>>>> all inner >>>>>>>>>>>> classes within parent, but this fails for WhiteBox due its >>>>>>>>>>>> static >>>>>>>>>>>> "registerNatives" dependency. >>>>>>>>>>>> >>>>>>>>>>>> Please, review suggested changes: >>>>>>>>>>>> - replace ClassFileInstaller and run/othervm with >>>>>>>>>>>> >>>>>>>>>>>> "run/othervm/bootclasspath". >>>>>>>>>>>> >>>>>>>>>>>> bootclasspath parameter for othervm >>>>>>>>>>>> adds-Xbootclasspath/a: >>>>>>>>>>>> option with ${test.src} and ${test.classes}according to >>>>>>>>>>>> http://hg.openjdk.java.net/code-tools/jtreg/file/31003a1c46d9/src/sha >>>>>>>>>>>> >>>>>>>>>>>> re >>>>>>>>>>>> /classes/com/sun/javatest/regtest/MainAction.java. >>>>>>>>>>>> >>>>>>>>>>>> Is this suitable for our needs - give to test compiled >>>>>>>>>>>> WhiteBox? >>>>>>>>>>>> >>>>>>>>>>>> - replace explicit -Xbootclasspath option values (".") in >>>>>>>>>>>> >>>>>>>>>>>> ProcessBuilder invocations to ${test.classes} where >>>>>>>>>>>> WhiteBox has been >>>>>>>>>>>> compiled. >>>>>>>>>>>> >>>>>>>>>>>> Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>> Thanks. >>>>>>>>>>>> >>>>>>>>>>>> On 23.05.2014 15:40, Andrey Zakharov wrote: >>>>>>>>>>>>> On 22.05.2014 12:47, Igor Ignatyev wrote: >>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. You changed dozen of tests, have you tested your changes? >>>>>>>>>>>>> Locally, aurora on the way. >>>>>>>>>>>>> >>>>>>>>>>>>>> 2. Your changes of year in copyright is wrong. it has to be >>>>>>>>>>>>>> $first_year, [$last_year, ], see Mark's email[1] for >>>>>>>>>>>>>> details. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [1] >>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/jdk7-dev/2010-May/001321.htm >>>>>>>>>>>>>> >>>>>>>>>>>>>> l >>>>>>>>>>>>> Thanks, fixed. will be uploaded soon. >>>>>>>>>>>>> >>>>>>>>>>>>>> Igor >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 05/21/2014 07:37 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>> On 13.05.2014 14:43, Andrey Zakharov wrote: >>>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>>> So here is trivial patch - >>>>>>>>>>>>>>>> removing ClassFileInstaller sun.hotspot.WhiteBox and >>>>>>>>>>>>>>>> adding >>>>>>>>>>>>>>>> main/othervm/bootclasspath >>>>>>>>>>>>>>>> where this needed >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also, some tests are modified as >>>>>>>>>>>>>>>> - "-Xbootclasspath/a:.", >>>>>>>>>>>>>>>> + "-Xbootclasspath/a:" + >>>>>>>>>>>>>>>> System.getProperty("test.classes"), >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>> webrev:http://cr.openjdk.java.net/~jwilhelm/8011397/webrev.02/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 09.05.2014 12:13, Mikael Gerdin wrote: >>>>>>>>>>>>>>>>> On Thursday 08 May 2014 19.28.13 Igor Ignatyev wrote: >>>>>>>>>>>>>>>>>> // cc'ing hotspot-dev instaed of compiler, runtime >>>>>>>>>>>>>>>>>> and gc >>>>>>>>>>>>>>>>>> lists. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 05/08/2014 07:09 PM, Filipp Zhinkin wrote: >>>>>>>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I've CC'ed compiler and runtime mailing list, >>>>>>>>>>>>>>>>>>> because you're >>>>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>>>>> affect test for other components as too. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I don't like your solution (but I'm not a reviewer, >>>>>>>>>>>>>>>>>>> so treat >>>>>>>>>>>>>>>>>>> my >>>>>>>>>>>>>>>>>>> words >>>>>>>>>>>>>>>>>>> just as suggestion), >>>>>>>>>>>>>>>>>>> because we'll have to write more meta information >>>>>>>>>>>>>>>>>>> for each >>>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>>> and it >>>>>>>>>>>>>>>>>>> is very easy to >>>>>>>>>>>>>>>>>>> forget to install WhiteBoxPermission if you don't >>>>>>>>>>>>>>>>>>> test your >>>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>> some security manager. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> From my point of view, it will be better to extend >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ClassFileInstaller >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> so it will copy not only >>>>>>>>>>>>>>>>>>> a class whose name was passed as an arguments, but >>>>>>>>>>>>>>>>>>> also all >>>>>>>>>>>>>>>>>>> inner >>>>>>>>>>>>>>>>>>> classes of that class. >>>>>>>>>>>>>>>>>>> And if someone want copy only specified class >>>>>>>>>>>>>>>>>>> without inner >>>>>>>>>>>>>>>>>>> classes, >>>>>>>>>>>>>>>>>>> then some option >>>>>>>>>>>>>>>>>>> could be added to ClassFileInstaller to force such >>>>>>>>>>>>>>>>>>> behaviour. >>>>>>>>>>>>>>>>> Perhaps this is a good time to get rid of >>>>>>>>>>>>>>>>> ClassFileInstaller >>>>>>>>>>>>>>>>> altogether? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8009117 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The reason for its existence is that the WhiteBox >>>>>>>>>>>>>>>>> class needs >>>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>>> boot class path. >>>>>>>>>>>>>>>>> If we can live with having all the test's classes on >>>>>>>>>>>>>>>>> the boot >>>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>>> path then >>>>>>>>>>>>>>>>> we could use the /bootclasspath option in jtreg as >>>>>>>>>>>>>>>>> stated in >>>>>>>>>>>>>>>>> the RFE. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> /Mikael >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Filipp. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 05/08/2014 04:47 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>>>> Hi! >>>>>>>>>>>>>>>>>>>> Suggesting patch with fixes for >>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20275/8011397 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> .t >>>>>>>>>>>>>>>>>>>> gz >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> patch: >>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20274/8011397 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> .W >>>>>>>>>>>>>>>>>>>> hiteBoxPer >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> mission >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks. >>>> >>> >> From stefan.karlsson at oracle.com Mon Aug 11 13:48:18 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Aug 2014 15:48:18 +0200 Subject: RFR: 8054823: Add size_t as a valid VM flag type Message-ID: <53E8C9A2.70607@oracle.com> Hi all, I propose that we add 'size_t' as a valid VM flag type. This will help with type safety, since we won't have to cast back and forth between the two types. This patch adds the framework, but only changes one of the flags. I choose to change one of our experimental flags, so that I could write tests for this change. Please, review this patch: http://cr.openjdk.java.net/~stefank/8054823/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8054823 thanks, StefanK From andrey.x.zakharov at oracle.com Mon Aug 11 13:55:53 2014 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Mon, 11 Aug 2014 17:55:53 +0400 Subject: RFR: 8011397: JTREG needs to copy additional WhiteBox class file to JTwork/scratch/sun/hotspot In-Reply-To: <53E8A8FB.2080505@oracle.com> References: <536B7CF0.6010508@oracle.com> <2443586.qRToXKmNqX@mgerdin03> <53C5482A.9090001@oracle.com> <12779611.jBGqJ13gfp@ehelin-laptop> <53C65E4A.4020401@oracle.com> <53D6638E.4070501@oracle.com> <53E8A44F.5090000@oracle.com> <53E8A691.60803@oracle.com> <53E8A8FB.2080505@oracle.com> Message-ID: <53E8CB69.5010003@oracle.com> Hi, all Here is updated patch with recent added tests: * ./test/compiler/classUnloading/methodUnloading/TestMethodUnloading.java * ./test/gc/class_unloading/TestCMSClassUnloadingEnabledHWM.java * ./test/gc/class_unloading/TestG1ClassUnloadingHWM.java webrev: http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.04/ Bug: https://bugs.openjdk.java.net/browse/JDK-8011397 Thanks. On 11.08.2014 15:28, Andrey Zakharov wrote: > Hi, Igor. > I have another counts with applied patch, but it looks like couple of > tests has beed added since last check. > > $ grep -Rl --exclude-dir=testlibrary > "sun.hotspot.WhiteBox\$WhiteBoxPermission" ./test/| wc -l > 133 > > $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox" ./test/| > wc -l > 142 > > Will update patch soon. > Thanks. > > > On 11.08.2014 15:18, Igor Ignatyev wrote: >> Andrey, >> >> could you please look at and fix other tests which use whitebox? >> >> $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox" ./test | >> wc -l >> 139 >> $ grep -Rl --exclude-dir=testlibrary >> "sun.hotspot.WhiteBox\$WhiteBoxPermission" ./test/ | wc -l >> 10 >> >> Thanks >> Igor >> >> On 08/11/2014 03:09 PM, Andrey Zakharov wrote: >>> Hi, all >>> >>> Is it possible to review this below >>> webrev: >>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>> >>> Thanks. >>> >>> On 28.07.2014 18:51, Andrey Zakharov wrote: >>>> Hi, all. >>>> I've prepared rechecked and verified fix for subject. >>>> webrev: >>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>> >>>> I've grep'ed workspace by sun.hotspot.WhiteBox and fixed every file. >>>> Also I've updated copyright. >>>> Testing was done by aurora batch 538304.ute.hs_jtreg.accept.full >>>> It looks good. >>>> >>>> Thanks. >>>> >>>> >>>> On 16.07.2014 15:13, Andrey Zakharov wrote: >>>>> >>>>> On 16.07.2014 14:39, Erik Helin wrote: >>>>>> On Tuesday 15 July 2014 19:26:34 PM Andrey Zakharov wrote: >>>>>>> Hi, Erik, Bengt. Could you, please, review this too. >>>>>> Andrey, why did you only update a couple of tests to also copy >>>>>> sun.hotspot.WhiteBox$WhiteBoxPermission? You updated 14 tests, >>>>>> there are >>>>>> still 116 tests using sun.hotspot.WhiteBox. >>>>>> >>>>>> Why doesn't these 116 tests have to be updated? >>>>>> >>>>>> Thanks, >>>>>> Erik >>>>> Thanks Erik. Actually this first one patch 8011397.WhiteBoxPermission >>>>> >>>>> >>>>> is correct. I will rework it and upload to webrev space. >>>>> >>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> On 15.07.2014 17:58, Mikael Gerdin wrote: >>>>>>>> Andrey, >>>>>>>> >>>>>>>> On Monday 07 July 2014 20.48.21 Andrey Zakharov wrote: >>>>>>>>> Hi ,all >>>>>>>>> Mikael, can you please review it. >>>>>>>> Sorry, I was on vacation last week. >>>>>>>> >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ >>>>>>>> Looks ok for now. We should consider revisiting this by either >>>>>>>> switching >>>>>>>> to >>>>>>>> @run main/bootclasspath >>>>>>>> or >>>>>>>> deleting the WhiteboxPermission nested class and using some >>>>>>>> other way for >>>>>>>> permission checks (if they are at all needed). >>>>>>>> >>>>>>>> /Mikael >>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> On 25.06.2014 19:08, Andrey Zakharov wrote: >>>>>>>>>> Hi, all >>>>>>>>>> So in progress of previous email - >>>>>>>>>> webrev: >>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> On 16.06.2014 19:57, Andrey Zakharov wrote: >>>>>>>>>>> Hi, all >>>>>>>>>>> So issue is that when tests with WhiteBox API has been >>>>>>>>>>> invoked with >>>>>>>>>>> -Xverify:all it fails with Exception >>>>>>>>>>> java.lang.NoClassDefFoundError: >>>>>>>>>>> sun/hotspot/WhiteBox$WhiteBoxPermission >>>>>>>>>>> Solutions that are observed: >>>>>>>>>>> 1. Copy WhiteBoxPermission with WhiteBox. But >>>>>>>>>>> >>>>>>>>>>>>> Perhaps this is a good time to get rid of ClassFileInstaller >>>>>>>>>>> altogether? >>>>>>>>>>> >>>>>>>>>>> 2. Using bootclasspath to hook pre-built whitebox (due @library >>>>>>>>>>> /testlibrary/whitebox) . Some tests has @run main/othervm, >>>>>>>>>>> some uses >>>>>>>>>>> ProcessBuilder. >>>>>>>>>>> >>>>>>>>>>> - main/othervm/bootclasspath adds ${test.src} and >>>>>>>>>>> >>>>>>>>>>> ${test.classes}to options. >>>>>>>>>>> >>>>>>>>>>> - With ProcessBuilder we can just add ${test.classes} >>>>>>>>>>> >>>>>>>>>>> Question here is, can it broke some tests ? While testing >>>>>>>>>>> this, I >>>>>>>>>>> found onlyhttps://bugs.openjdk.java.net/browse/JDK-8046231, >>>>>>>>>>> others >>>>>>>>>>> looks fine. >>>>>>>>>>> >>>>>>>>>>> 3. Make ClassFileInstaller deal with inner classes like that: >>>>>>>>>>> diff -r 6ed24aedeef0 -r c01651363ba8 >>>>>>>>>>> test/testlibrary/ClassFileInstaller.java >>>>>>>>>>> --- a/test/testlibrary/ClassFileInstaller.java Thu Jun 05 >>>>>>>>>>> 19:02:56 >>>>>>>>>>> 2014 +0400 >>>>>>>>>>> +++ b/test/testlibrary/ClassFileInstaller.java Fri Jun 06 >>>>>>>>>>> 18:18:11 >>>>>>>>>>> 2014 +0400 >>>>>>>>>>> @@ -50,6 +50,16 @@ >>>>>>>>>>> >>>>>>>>>>> } >>>>>>>>>>> // Create the class file >>>>>>>>>>> Files.copy(is, p, >>>>>>>>>>> StandardCopyOption.REPLACE_EXISTING); >>>>>>>>>>> >>>>>>>>>>> + >>>>>>>>>>> + for (Class cls : >>>>>>>>>>> Class.forName(arg).getDeclaredClasses()) { >>>>>>>>>>> + //if >>>>>>>>>>> (!Modifier.isStatic(cls.getModifiers())) { >>>>>>>>>>> + String pathNameSub = >>>>>>>>>>> cls.getCanonicalName().replace('.', '/').concat(".class"); >>>>>>>>>>> + Path pathSub = Paths.get(pathNameSub); >>>>>>>>>>> + InputStream streamSub = >>>>>>>>>>> cl.getResourceAsStream(pathNameSub); >>>>>>>>>>> + Files.copy(streamSub, pathSub, >>>>>>>>>>> StandardCopyOption.REPLACE_EXISTING); >>>>>>>>>>> + //} >>>>>>>>>>> + } >>>>>>>>>>> + >>>>>>>>>>> >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Works fine for ordinary classes, but fails for WhiteBox due >>>>>>>>>>> Class.forName initiate Class. WhiteBox has "static" section, >>>>>>>>>>> and >>>>>>>>>>> initialization fails as it cannot bind to native methods >>>>>>>>>>> "registerNatives" and so on. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> So, lets return to first one option? Just add everywhere >>>>>>>>>>> >>>>>>>>>>> * @run main ClassFileInstaller sun.hotspot.WhiteBox >>>>>>>>>>> >>>>>>>>>>> + * @run main ClassFileInstaller >>>>>>>>>>> sun.hotspot.WhiteBox$WhiteBoxPermission >>>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> On 10.06.2014 19:43, Igor Ignatyev wrote: >>>>>>>>>>>> Andrey, >>>>>>>>>>>> >>>>>>>>>>>> I don't like this idea, since it completely changes the tests. >>>>>>>>>>>> 'run/othervm/bootclasspath' adds all paths from CP to BCP, >>>>>>>>>>>> so the >>>>>>>>>>>> tests whose main idea was testing WB methods themselves >>>>>>>>>>>> (sanity, >>>>>>>>>>>> compiler/whitebox, ...) don't check that it's possible to >>>>>>>>>>>> use WB >>>>>>>>>>>> when the application isn't in BCP. >>>>>>>>>>>> >>>>>>>>>>>> Igor >>>>>>>>>>>> >>>>>>>>>>>> On 06/09/2014 06:59 PM, Andrey Zakharov wrote: >>>>>>>>>>>>> Hi, everybody >>>>>>>>>>>>> I have tested my changes on major platforms and found one >>>>>>>>>>>>> bug, filed: >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046231 >>>>>>>>>>>>> Also, i did another try to make ClassFileInstaller to copy >>>>>>>>>>>>> all inner >>>>>>>>>>>>> classes within parent, but this fails for WhiteBox due its >>>>>>>>>>>>> static >>>>>>>>>>>>> "registerNatives" dependency. >>>>>>>>>>>>> >>>>>>>>>>>>> Please, review suggested changes: >>>>>>>>>>>>> - replace ClassFileInstaller and run/othervm with >>>>>>>>>>>>> >>>>>>>>>>>>> "run/othervm/bootclasspath". >>>>>>>>>>>>> >>>>>>>>>>>>> bootclasspath parameter for othervm >>>>>>>>>>>>> adds-Xbootclasspath/a: >>>>>>>>>>>>> option with ${test.src} and ${test.classes}according to >>>>>>>>>>>>> http://hg.openjdk.java.net/code-tools/jtreg/file/31003a1c46d9/src/sha >>>>>>>>>>>>> >>>>>>>>>>>>> re >>>>>>>>>>>>> /classes/com/sun/javatest/regtest/MainAction.java. >>>>>>>>>>>>> >>>>>>>>>>>>> Is this suitable for our needs - give to test compiled >>>>>>>>>>>>> WhiteBox? >>>>>>>>>>>>> >>>>>>>>>>>>> - replace explicit -Xbootclasspath option values (".") in >>>>>>>>>>>>> >>>>>>>>>>>>> ProcessBuilder invocations to ${test.classes} where >>>>>>>>>>>>> WhiteBox has been >>>>>>>>>>>>> compiled. >>>>>>>>>>>>> >>>>>>>>>>>>> Webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>> Thanks. >>>>>>>>>>>>> >>>>>>>>>>>>> On 23.05.2014 15:40, Andrey Zakharov wrote: >>>>>>>>>>>>>> On 22.05.2014 12:47, Igor Ignatyev wrote: >>>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1. You changed dozen of tests, have you tested your >>>>>>>>>>>>>>> changes? >>>>>>>>>>>>>> Locally, aurora on the way. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2. Your changes of year in copyright is wrong. it has to be >>>>>>>>>>>>>>> $first_year, [$last_year, ], see Mark's email[1] for >>>>>>>>>>>>>>> details. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/jdk7-dev/2010-May/001321.htm >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> l >>>>>>>>>>>>>> Thanks, fixed. will be uploaded soon. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Igor >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 05/21/2014 07:37 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>>> On 13.05.2014 14:43, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>>>> So here is trivial patch - >>>>>>>>>>>>>>>>> removing ClassFileInstaller sun.hotspot.WhiteBox and >>>>>>>>>>>>>>>>> adding >>>>>>>>>>>>>>>>> main/othervm/bootclasspath >>>>>>>>>>>>>>>>> where this needed >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Also, some tests are modified as >>>>>>>>>>>>>>>>> - "-Xbootclasspath/a:.", >>>>>>>>>>>>>>>>> + "-Xbootclasspath/a:" + >>>>>>>>>>>>>>>>> System.getProperty("test.classes"), >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>> webrev:http://cr.openjdk.java.net/~jwilhelm/8011397/webrev.02/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 09.05.2014 12:13, Mikael Gerdin wrote: >>>>>>>>>>>>>>>>>> On Thursday 08 May 2014 19.28.13 Igor Ignatyev wrote: >>>>>>>>>>>>>>>>>>> // cc'ing hotspot-dev instaed of compiler, runtime >>>>>>>>>>>>>>>>>>> and gc >>>>>>>>>>>>>>>>>>> lists. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 05/08/2014 07:09 PM, Filipp Zhinkin wrote: >>>>>>>>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I've CC'ed compiler and runtime mailing list, >>>>>>>>>>>>>>>>>>>> because you're >>>>>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>>>>>> affect test for other components as too. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I don't like your solution (but I'm not a reviewer, >>>>>>>>>>>>>>>>>>>> so treat >>>>>>>>>>>>>>>>>>>> my >>>>>>>>>>>>>>>>>>>> words >>>>>>>>>>>>>>>>>>>> just as suggestion), >>>>>>>>>>>>>>>>>>>> because we'll have to write more meta information >>>>>>>>>>>>>>>>>>>> for each >>>>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>>>> and it >>>>>>>>>>>>>>>>>>>> is very easy to >>>>>>>>>>>>>>>>>>>> forget to install WhiteBoxPermission if you don't >>>>>>>>>>>>>>>>>>>> test your >>>>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>> some security manager. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> From my point of view, it will be better to extend >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ClassFileInstaller >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> so it will copy not only >>>>>>>>>>>>>>>>>>>> a class whose name was passed as an arguments, but >>>>>>>>>>>>>>>>>>>> also all >>>>>>>>>>>>>>>>>>>> inner >>>>>>>>>>>>>>>>>>>> classes of that class. >>>>>>>>>>>>>>>>>>>> And if someone want copy only specified class >>>>>>>>>>>>>>>>>>>> without inner >>>>>>>>>>>>>>>>>>>> classes, >>>>>>>>>>>>>>>>>>>> then some option >>>>>>>>>>>>>>>>>>>> could be added to ClassFileInstaller to force such >>>>>>>>>>>>>>>>>>>> behaviour. >>>>>>>>>>>>>>>>>> Perhaps this is a good time to get rid of >>>>>>>>>>>>>>>>>> ClassFileInstaller >>>>>>>>>>>>>>>>>> altogether? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8009117 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The reason for its existence is that the WhiteBox >>>>>>>>>>>>>>>>>> class needs >>>>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>>>> boot class path. >>>>>>>>>>>>>>>>>> If we can live with having all the test's classes on >>>>>>>>>>>>>>>>>> the boot >>>>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>>>> path then >>>>>>>>>>>>>>>>>> we could use the /bootclasspath option in jtreg as >>>>>>>>>>>>>>>>>> stated in >>>>>>>>>>>>>>>>>> the RFE. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> /Mikael >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Filipp. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 05/08/2014 04:47 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>>>>> Hi! >>>>>>>>>>>>>>>>>>>>> Suggesting patch with fixes for >>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20275/8011397 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> .t >>>>>>>>>>>>>>>>>>>>> gz >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> patch: >>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20274/8011397 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> .W >>>>>>>>>>>>>>>>>>>>> hiteBoxPer >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> mission >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks. >>>>> >>>> >>> > From vladimir.kozlov at oracle.com Mon Aug 11 16:14:37 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Aug 2014 09:14:37 -0700 Subject: [8u40] RFR(S): 8029443: 'assert(klass->is_loader_alive(_is_alive)) failed: must be alive' during VM_CollectForMetadataAllocation In-Reply-To: <53E8755B.9010308@oracle.com> References: <53E8755B.9010308@oracle.com> Message-ID: <53E8EBED.9060709@oracle.com> Good. Thanks, Vladimir On 8/11/14 12:48 AM, Tobias Hartmann wrote: > Hi, > > please review this 8u40 backport request. The changes were pushed on Wednesday and nightly testing showed no problems. > > Changes for JDK9 applied to 8u40 without conflicts. > > Master bug: https://bugs.openjdk.java.net/browse/JDK-8029443 > Webrev: http://cr.openjdk.java.net/~thartmann/8029443/webrev.03/ > Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e6a16cb925ca > > Thanks, > Tobias From vladimir.kozlov at oracle.com Mon Aug 11 16:35:37 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Aug 2014 09:35:37 -0700 Subject: RFR: 8054823: Add size_t as a valid VM flag type In-Reply-To: <53E8C9A2.70607@oracle.com> References: <53E8C9A2.70607@oracle.com> Message-ID: <53E8F0D9.6020002@oracle.com> Stefan, Seems fine to me, except new tests don't have correct @bug. 27 * The test helsp verifying that size_t flags can be set/read. ^ typo SizeTTest.java - remove @author Thanks, Vladimir On 8/11/14 6:48 AM, Stefan Karlsson wrote: > Hi all, > > I propose that we add 'size_t' as a valid VM flag type. This will help with type safety, since we won't have to cast > back and forth between the two types. > > This patch adds the framework, but only changes one of the flags. I choose to change one of our experimental flags, so > that I could write tests for this change. > > Please, review this patch: > http://cr.openjdk.java.net/~stefank/8054823/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8054823 > > thanks, > StefanK From vladimir.kozlov at oracle.com Mon Aug 11 16:40:24 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Aug 2014 09:40:24 -0700 Subject: RFR: 8011397: JTREG needs to copy additional WhiteBox class file to JTwork/scratch/sun/hotspot In-Reply-To: <53E8CB69.5010003@oracle.com> References: <536B7CF0.6010508@oracle.com> <2443586.qRToXKmNqX@mgerdin03> <53C5482A.9090001@oracle.com> <12779611.jBGqJ13gfp@ehelin-laptop> <53C65E4A.4020401@oracle.com> <53D6638E.4070501@oracle.com> <53E8A44F.5090000@oracle.com> <53E8A691.60803@oracle.com> <53E8A8FB.2080505@oracle.com> <53E8CB69.5010003@oracle.com> Message-ID: <53E8F1F8.30305@oracle.com> Looks fine. Thanks, Vladimir On 8/11/14 6:55 AM, Andrey Zakharov wrote: > Hi, all > Here is updated patch with recent added tests: > > * ./test/compiler/classUnloading/methodUnloading/TestMethodUnloading.java > * ./test/gc/class_unloading/TestCMSClassUnloadingEnabledHWM.java > * ./test/gc/class_unloading/TestG1ClassUnloadingHWM.java > > webrev: > http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.04/ > Bug: > https://bugs.openjdk.java.net/browse/JDK-8011397 > > Thanks. > > On 11.08.2014 15:28, Andrey Zakharov wrote: >> Hi, Igor. >> I have another counts with applied patch, but it looks like couple of tests has beed added since last check. >> >> $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox\$WhiteBoxPermission" ./test/| wc -l >> 133 >> >> $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox" ./test/| wc -l >> 142 >> >> Will update patch soon. >> Thanks. >> >> >> On 11.08.2014 15:18, Igor Ignatyev wrote: >>> Andrey, >>> >>> could you please look at and fix other tests which use whitebox? >>> >>> $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox" ./test | wc -l >>> 139 >>> $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox\$WhiteBoxPermission" ./test/ | wc -l >>> 10 >>> >>> Thanks >>> Igor >>> >>> On 08/11/2014 03:09 PM, Andrey Zakharov wrote: >>>> Hi, all >>>> >>>> Is it possible to review this below >>>> webrev: >>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>> >>>> Thanks. >>>> >>>> On 28.07.2014 18:51, Andrey Zakharov wrote: >>>>> Hi, all. >>>>> I've prepared rechecked and verified fix for subject. >>>>> webrev: >>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>> >>>>> I've grep'ed workspace by sun.hotspot.WhiteBox and fixed every file. >>>>> Also I've updated copyright. >>>>> Testing was done by aurora batch 538304.ute.hs_jtreg.accept.full >>>>> It looks good. >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> On 16.07.2014 15:13, Andrey Zakharov wrote: >>>>>> >>>>>> On 16.07.2014 14:39, Erik Helin wrote: >>>>>>> On Tuesday 15 July 2014 19:26:34 PM Andrey Zakharov wrote: >>>>>>>> Hi, Erik, Bengt. Could you, please, review this too. >>>>>>> Andrey, why did you only update a couple of tests to also copy >>>>>>> sun.hotspot.WhiteBox$WhiteBoxPermission? You updated 14 tests, there are >>>>>>> still 116 tests using sun.hotspot.WhiteBox. >>>>>>> >>>>>>> Why doesn't these 116 tests have to be updated? >>>>>>> >>>>>>> Thanks, >>>>>>> Erik >>>>>> Thanks Erik. Actually this first one patch 8011397.WhiteBoxPermission >>>>>> >>>>>> is correct. I will rework it and upload to webrev space. >>>>>> >>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> On 15.07.2014 17:58, Mikael Gerdin wrote: >>>>>>>>> Andrey, >>>>>>>>> >>>>>>>>> On Monday 07 July 2014 20.48.21 Andrey Zakharov wrote: >>>>>>>>>> Hi ,all >>>>>>>>>> Mikael, can you please review it. >>>>>>>>> Sorry, I was on vacation last week. >>>>>>>>> >>>>>>>>>> webrev: >>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ >>>>>>>>> Looks ok for now. We should consider revisiting this by either switching >>>>>>>>> to >>>>>>>>> @run main/bootclasspath >>>>>>>>> or >>>>>>>>> deleting the WhiteboxPermission nested class and using some other way for >>>>>>>>> permission checks (if they are at all needed). >>>>>>>>> >>>>>>>>> /Mikael >>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> On 25.06.2014 19:08, Andrey Zakharov wrote: >>>>>>>>>>> Hi, all >>>>>>>>>>> So in progress of previous email - >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> On 16.06.2014 19:57, Andrey Zakharov wrote: >>>>>>>>>>>> Hi, all >>>>>>>>>>>> So issue is that when tests with WhiteBox API has been invoked with >>>>>>>>>>>> -Xverify:all it fails with Exception java.lang.NoClassDefFoundError: >>>>>>>>>>>> sun/hotspot/WhiteBox$WhiteBoxPermission >>>>>>>>>>>> Solutions that are observed: >>>>>>>>>>>> 1. Copy WhiteBoxPermission with WhiteBox. But >>>>>>>>>>>> >>>>>>>>>>>>>> Perhaps this is a good time to get rid of ClassFileInstaller >>>>>>>>>>>> altogether? >>>>>>>>>>>> >>>>>>>>>>>> 2. Using bootclasspath to hook pre-built whitebox (due @library >>>>>>>>>>>> /testlibrary/whitebox) . Some tests has @run main/othervm, some uses >>>>>>>>>>>> ProcessBuilder. >>>>>>>>>>>> >>>>>>>>>>>> - main/othervm/bootclasspath adds ${test.src} and >>>>>>>>>>>> >>>>>>>>>>>> ${test.classes}to options. >>>>>>>>>>>> >>>>>>>>>>>> - With ProcessBuilder we can just add ${test.classes} >>>>>>>>>>>> >>>>>>>>>>>> Question here is, can it broke some tests ? While testing this, I >>>>>>>>>>>> found onlyhttps://bugs.openjdk.java.net/browse/JDK-8046231, others >>>>>>>>>>>> looks fine. >>>>>>>>>>>> >>>>>>>>>>>> 3. Make ClassFileInstaller deal with inner classes like that: >>>>>>>>>>>> diff -r 6ed24aedeef0 -r c01651363ba8 >>>>>>>>>>>> test/testlibrary/ClassFileInstaller.java >>>>>>>>>>>> --- a/test/testlibrary/ClassFileInstaller.java Thu Jun 05 19:02:56 >>>>>>>>>>>> 2014 +0400 >>>>>>>>>>>> +++ b/test/testlibrary/ClassFileInstaller.java Fri Jun 06 18:18:11 >>>>>>>>>>>> 2014 +0400 >>>>>>>>>>>> @@ -50,6 +50,16 @@ >>>>>>>>>>>> >>>>>>>>>>>> } >>>>>>>>>>>> // Create the class file >>>>>>>>>>>> Files.copy(is, p, StandardCopyOption.REPLACE_EXISTING); >>>>>>>>>>>> >>>>>>>>>>>> + >>>>>>>>>>>> + for (Class cls : >>>>>>>>>>>> Class.forName(arg).getDeclaredClasses()) { >>>>>>>>>>>> + //if (!Modifier.isStatic(cls.getModifiers())) { >>>>>>>>>>>> + String pathNameSub = >>>>>>>>>>>> cls.getCanonicalName().replace('.', '/').concat(".class"); >>>>>>>>>>>> + Path pathSub = Paths.get(pathNameSub); >>>>>>>>>>>> + InputStream streamSub = >>>>>>>>>>>> cl.getResourceAsStream(pathNameSub); >>>>>>>>>>>> + Files.copy(streamSub, pathSub, >>>>>>>>>>>> StandardCopyOption.REPLACE_EXISTING); >>>>>>>>>>>> + //} >>>>>>>>>>>> + } >>>>>>>>>>>> + >>>>>>>>>>>> >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> Works fine for ordinary classes, but fails for WhiteBox due >>>>>>>>>>>> Class.forName initiate Class. WhiteBox has "static" section, and >>>>>>>>>>>> initialization fails as it cannot bind to native methods >>>>>>>>>>>> "registerNatives" and so on. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> So, lets return to first one option? Just add everywhere >>>>>>>>>>>> >>>>>>>>>>>> * @run main ClassFileInstaller sun.hotspot.WhiteBox >>>>>>>>>>>> >>>>>>>>>>>> + * @run main ClassFileInstaller >>>>>>>>>>>> sun.hotspot.WhiteBox$WhiteBoxPermission >>>>>>>>>>>> >>>>>>>>>>>> Thanks. >>>>>>>>>>>> >>>>>>>>>>>> On 10.06.2014 19:43, Igor Ignatyev wrote: >>>>>>>>>>>>> Andrey, >>>>>>>>>>>>> >>>>>>>>>>>>> I don't like this idea, since it completely changes the tests. >>>>>>>>>>>>> 'run/othervm/bootclasspath' adds all paths from CP to BCP, so the >>>>>>>>>>>>> tests whose main idea was testing WB methods themselves (sanity, >>>>>>>>>>>>> compiler/whitebox, ...) don't check that it's possible to use WB >>>>>>>>>>>>> when the application isn't in BCP. >>>>>>>>>>>>> >>>>>>>>>>>>> Igor >>>>>>>>>>>>> >>>>>>>>>>>>> On 06/09/2014 06:59 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>> Hi, everybody >>>>>>>>>>>>>> I have tested my changes on major platforms and found one bug, filed: >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046231 >>>>>>>>>>>>>> Also, i did another try to make ClassFileInstaller to copy all inner >>>>>>>>>>>>>> classes within parent, but this fails for WhiteBox due its static >>>>>>>>>>>>>> "registerNatives" dependency. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please, review suggested changes: >>>>>>>>>>>>>> - replace ClassFileInstaller and run/othervm with >>>>>>>>>>>>>> >>>>>>>>>>>>>> "run/othervm/bootclasspath". >>>>>>>>>>>>>> >>>>>>>>>>>>>> bootclasspath parameter for othervm adds-Xbootclasspath/a: >>>>>>>>>>>>>> option with ${test.src} and ${test.classes}according to >>>>>>>>>>>>>> http://hg.openjdk.java.net/code-tools/jtreg/file/31003a1c46d9/src/sha >>>>>>>>>>>>>> re >>>>>>>>>>>>>> /classes/com/sun/javatest/regtest/MainAction.java. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is this suitable for our needs - give to test compiled WhiteBox? >>>>>>>>>>>>>> >>>>>>>>>>>>>> - replace explicit -Xbootclasspath option values (".") in >>>>>>>>>>>>>> >>>>>>>>>>>>>> ProcessBuilder invocations to ${test.classes} where WhiteBox has been >>>>>>>>>>>>>> compiled. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.00/ >>>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 23.05.2014 15:40, Andrey Zakharov wrote: >>>>>>>>>>>>>>> On 22.05.2014 12:47, Igor Ignatyev wrote: >>>>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1. You changed dozen of tests, have you tested your changes? >>>>>>>>>>>>>>> Locally, aurora on the way. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2. Your changes of year in copyright is wrong. it has to be >>>>>>>>>>>>>>>> $first_year, [$last_year, ], see Mark's email[1] for details. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/jdk7-dev/2010-May/001321.htm >>>>>>>>>>>>>>>> l >>>>>>>>>>>>>>> Thanks, fixed. will be uploaded soon. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Igor >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 05/21/2014 07:37 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>> On 13.05.2014 14:43, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>>>>> So here is trivial patch - >>>>>>>>>>>>>>>>>> removing ClassFileInstaller sun.hotspot.WhiteBox and adding >>>>>>>>>>>>>>>>>> main/othervm/bootclasspath >>>>>>>>>>>>>>>>>> where this needed >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Also, some tests are modified as >>>>>>>>>>>>>>>>>> - "-Xbootclasspath/a:.", >>>>>>>>>>>>>>>>>> + "-Xbootclasspath/a:" + >>>>>>>>>>>>>>>>>> System.getProperty("test.classes"), >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>> webrev:http://cr.openjdk.java.net/~jwilhelm/8011397/webrev.02/ >>>>>>>>>>>>>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 09.05.2014 12:13, Mikael Gerdin wrote: >>>>>>>>>>>>>>>>>>> On Thursday 08 May 2014 19.28.13 Igor Ignatyev wrote: >>>>>>>>>>>>>>>>>>>> // cc'ing hotspot-dev instaed of compiler, runtime and gc >>>>>>>>>>>>>>>>>>>> lists. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 05/08/2014 07:09 PM, Filipp Zhinkin wrote: >>>>>>>>>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I've CC'ed compiler and runtime mailing list, because you're >>>>>>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>>>>>>> affect test for other components as too. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I don't like your solution (but I'm not a reviewer, so treat >>>>>>>>>>>>>>>>>>>>> my >>>>>>>>>>>>>>>>>>>>> words >>>>>>>>>>>>>>>>>>>>> just as suggestion), >>>>>>>>>>>>>>>>>>>>> because we'll have to write more meta information for each >>>>>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>>>>> and it >>>>>>>>>>>>>>>>>>>>> is very easy to >>>>>>>>>>>>>>>>>>>>> forget to install WhiteBoxPermission if you don't test your >>>>>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>> some security manager. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> From my point of view, it will be better to extend >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> ClassFileInstaller >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> so it will copy not only >>>>>>>>>>>>>>>>>>>>> a class whose name was passed as an arguments, but also all >>>>>>>>>>>>>>>>>>>>> inner >>>>>>>>>>>>>>>>>>>>> classes of that class. >>>>>>>>>>>>>>>>>>>>> And if someone want copy only specified class without inner >>>>>>>>>>>>>>>>>>>>> classes, >>>>>>>>>>>>>>>>>>>>> then some option >>>>>>>>>>>>>>>>>>>>> could be added to ClassFileInstaller to force such behaviour. >>>>>>>>>>>>>>>>>>> Perhaps this is a good time to get rid of ClassFileInstaller >>>>>>>>>>>>>>>>>>> altogether? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8009117 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The reason for its existence is that the WhiteBox class needs >>>>>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>>>>> boot class path. >>>>>>>>>>>>>>>>>>> If we can live with having all the test's classes on the boot >>>>>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>>>>> path then >>>>>>>>>>>>>>>>>>> we could use the /bootclasspath option in jtreg as stated in >>>>>>>>>>>>>>>>>>> the RFE. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> /Mikael >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> Filipp. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 05/08/2014 04:47 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>>>>>> Hi! >>>>>>>>>>>>>>>>>>>>>> Suggesting patch with fixes for >>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20275/8011397 >>>>>>>>>>>>>>>>>>>>>> .t >>>>>>>>>>>>>>>>>>>>>> gz >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> patch: >>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20274/8011397 >>>>>>>>>>>>>>>>>>>>>> .W >>>>>>>>>>>>>>>>>>>>>> hiteBoxPer >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> mission >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>> >>>>> >>>> >> > From stefan.karlsson at oracle.com Mon Aug 11 17:46:37 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Aug 2014 19:46:37 +0200 Subject: RFR: 8054823: Add size_t as a valid VM flag type In-Reply-To: <53E8F0D9.6020002@oracle.com> References: <53E8C9A2.70607@oracle.com> <53E8F0D9.6020002@oracle.com> Message-ID: <53E9017D.6040902@oracle.com> On 2014-08-11 18:35, Vladimir Kozlov wrote: > Stefan, > > Seems fine to me, Thanks for reviewing! > except new tests don't have correct @bug. > > 27 * The test helsp verifying that size_t flags can be set/read. > ^ typo > > SizeTTest.java - remove @author Too much copy-n-paste. I've updated the patch and did some additional cleanups to the jtreg annotations: http://cr.openjdk.java.net/~stefank/8054823/webrev.01.delta/ http://cr.openjdk.java.net/~stefank/8054823/webrev.01/ thanks, StefanK > > Thanks, > Vladimir > > On 8/11/14 6:48 AM, Stefan Karlsson wrote: >> Hi all, >> >> I propose that we add 'size_t' as a valid VM flag type. This will >> help with type safety, since we won't have to cast >> back and forth between the two types. >> >> This patch adds the framework, but only changes one of the flags. I >> choose to change one of our experimental flags, so >> that I could write tests for this change. >> >> Please, review this patch: >> http://cr.openjdk.java.net/~stefank/8054823/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8054823 >> >> thanks, >> StefanK From vladimir.kozlov at oracle.com Mon Aug 11 18:47:52 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Aug 2014 11:47:52 -0700 Subject: RFR: 8054823: Add size_t as a valid VM flag type In-Reply-To: <53E9017D.6040902@oracle.com> References: <53E8C9A2.70607@oracle.com> <53E8F0D9.6020002@oracle.com> <53E9017D.6040902@oracle.com> Message-ID: <53E90FD8.4000507@oracle.com> Good. Thanks, Vladimir On 8/11/14 10:46 AM, Stefan Karlsson wrote: > On 2014-08-11 18:35, Vladimir Kozlov wrote: >> Stefan, >> >> Seems fine to me, > > Thanks for reviewing! > >> except new tests don't have correct @bug. >> >> 27 * The test helsp verifying that size_t flags can be set/read. >> ^ typo >> >> SizeTTest.java - remove @author > > Too much copy-n-paste. I've updated the patch and did some additional > cleanups to the jtreg annotations: > http://cr.openjdk.java.net/~stefank/8054823/webrev.01.delta/ > http://cr.openjdk.java.net/~stefank/8054823/webrev.01/ > > thanks, > StefanK > >> >> Thanks, >> Vladimir >> >> On 8/11/14 6:48 AM, Stefan Karlsson wrote: >>> Hi all, >>> >>> I propose that we add 'size_t' as a valid VM flag type. This will >>> help with type safety, since we won't have to cast >>> back and forth between the two types. >>> >>> This patch adds the framework, but only changes one of the flags. I >>> choose to change one of our experimental flags, so >>> that I could write tests for this change. >>> >>> Please, review this patch: >>> http://cr.openjdk.java.net/~stefank/8054823/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8054823 >>> >>> thanks, >>> StefanK > From vladimir.kozlov at oracle.com Mon Aug 11 21:02:15 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Aug 2014 14:02:15 -0700 Subject: [8u40] Backport RFR (L) 8035605 and 8035968: C2 support for SHA on SPARC Message-ID: <53E92F57.6030907@oracle.com> 8u40 backport request. Changes were pushed two months ago into jdk9, no problems were found since then. The only few modifications I have to do is due to 8034812 changes which removed Compile* argument from Node::new() in jdk9. And 8026796 which removed 'Parse* parent_parser' argument and is not backported into 8u yet. 8035968: Leverage CPU Instructions to Improve SHA Performance on SPARC https://bugs.openjdk.java.net/browse/JDK-8035968 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/edf93f2ccf99 8035605: Expand functionality of PredictedIntrinsicGenerator https://bugs.openjdk.java.net/browse/JDK-8035605 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/9be8f500449d Thanks, Vladimir From vladimir.x.ivanov at oracle.com Mon Aug 11 21:09:29 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 11 Aug 2014 14:09:29 -0700 Subject: RFR: 8054823: Add size_t as a valid VM flag type In-Reply-To: <53E9017D.6040902@oracle.com> References: <53E8C9A2.70607@oracle.com> <53E8F0D9.6020002@oracle.com> <53E9017D.6040902@oracle.com> Message-ID: <53E93109.8060601@oracle.com> test/gc/arguments/TestArrayAllocatorMallocLimit.java 25 * @test TestArrayAlocatorMallocLimit at test Typo. Otherwise, looks good. Best regards, Vladimir Ivanov On 8/11/14, 10:46 AM, Stefan Karlsson wrote: > On 2014-08-11 18:35, Vladimir Kozlov wrote: >> Stefan, >> >> Seems fine to me, > > Thanks for reviewing! > >> except new tests don't have correct @bug. >> >> 27 * The test helsp verifying that size_t flags can be set/read. >> ^ typo >> >> SizeTTest.java - remove @author > > Too much copy-n-paste. I've updated the patch and did some additional > cleanups to the jtreg annotations: > http://cr.openjdk.java.net/~stefank/8054823/webrev.01.delta/ > http://cr.openjdk.java.net/~stefank/8054823/webrev.01/ > > thanks, > StefanK > >> >> Thanks, >> Vladimir >> >> On 8/11/14 6:48 AM, Stefan Karlsson wrote: >>> Hi all, >>> >>> I propose that we add 'size_t' as a valid VM flag type. This will >>> help with type safety, since we won't have to cast >>> back and forth between the two types. >>> >>> This patch adds the framework, but only changes one of the flags. I >>> choose to change one of our experimental flags, so >>> that I could write tests for this change. >>> >>> Please, review this patch: >>> http://cr.openjdk.java.net/~stefank/8054823/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8054823 >>> >>> thanks, >>> StefanK > From kim.barrett at oracle.com Mon Aug 11 22:05:28 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 11 Aug 2014 18:05:28 -0400 Subject: RFR: 8047952 : (s) Remove FORTIFY_SOURCE from fastdebug and slowdebug builds In-Reply-To: <40C6E590-CE6C-4782-8C4A-5736E3075B90@oracle.com> References: <40C6E590-CE6C-4782-8C4A-5736E3075B90@oracle.com> Message-ID: <75701664-D9E3-4568-8CFC-D8FDFCFEF655@oracle.com> On Aug 8, 2014, at 8:23 PM, Mike Duigou wrote: > > Hello all; > > A previous version of this changeset was focused on disabling FORTIFY_SOURCE only for specific files with optimization disabled. This version entirely disables FORTIFY_SOURCE for all portions of the build. After additional problems; incompatibility of FORTIFY_SOURCE with -O0, lack of consistent support for FORTIFY_SOURCE in some distributions of glibc, etc. this seems like the best course. Should the separate issues with -Od be resolved then FORTIFY_SOURCE could be re-enabled selectively for specific platforms. > > webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047952/1/webrev/ > jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047952 > > Mike In common/autoconf/flags.m4: 339 if test "x$TOOLCHAIN_TYPE" = xgcc; then 340 case $DEBUG_LEVEL in 341 release ) 342 fastdebug ) 343 # no adjustment 344 ;; The bash documentation I'm looking at says each clause must end with ";;", and makes no mention of any sort of fall-through from one clause to the next. "... the ')' operator terminates a pattern list. A list of patterns and an associated command-list is known as a clause. Each clause must be terminated with ';;'" It's not clear from that description what should happen for line 341. From mike.duigou at oracle.com Mon Aug 11 23:09:26 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 11 Aug 2014 16:09:26 -0700 Subject: RFR: 8047952 : (s) Remove FORTIFY_SOURCE from fastdebug and slowdebug builds In-Reply-To: <75701664-D9E3-4568-8CFC-D8FDFCFEF655@oracle.com> References: <40C6E590-CE6C-4782-8C4A-5736E3075B90@oracle.com> <75701664-D9E3-4568-8CFC-D8FDFCFEF655@oracle.com> Message-ID: You are correct. The release and fastdebug need to be combined into one clause. I will fix this. Bash 4.0 doesn't appear to complain about the fallthrough but better to be compliant. Mike On Aug 11 2014, at 15:05 , Kim Barrett wrote: > On Aug 8, 2014, at 8:23 PM, Mike Duigou wrote: >> >> Hello all; >> >> A previous version of this changeset was focused on disabling FORTIFY_SOURCE only for specific files with optimization disabled. This version entirely disables FORTIFY_SOURCE for all portions of the build. After additional problems; incompatibility of FORTIFY_SOURCE with -O0, lack of consistent support for FORTIFY_SOURCE in some distributions of glibc, etc. this seems like the best course. Should the separate issues with -Od be resolved then FORTIFY_SOURCE could be re-enabled selectively for specific platforms. >> >> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047952/1/webrev/ >> jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047952 >> >> Mike > > In common/autoconf/flags.m4: > > 339 if test "x$TOOLCHAIN_TYPE" = xgcc; then > 340 case $DEBUG_LEVEL in > 341 release ) > 342 fastdebug ) > 343 # no adjustment > 344 ;; > > The bash documentation I'm looking at says each clause must end with > ";;", and makes no mention of any sort of fall-through from one clause > to the next. > > "... the ')' operator terminates a pattern list. A list of patterns > and an associated command-list is known as a clause. Each clause > must be terminated with ';;'" > > It's not clear from that description what should happen for line 341. > From tobias.hartmann at oracle.com Tue Aug 12 04:53:26 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 12 Aug 2014 06:53:26 +0200 Subject: [8u40] RFR(S): 8029443: 'assert(klass->is_loader_alive(_is_alive)) failed: must be alive' during VM_CollectForMetadataAllocation In-Reply-To: <53E8EBED.9060709@oracle.com> References: <53E8755B.9010308@oracle.com> <53E8EBED.9060709@oracle.com> Message-ID: <53E99DC6.7030203@oracle.com> Thank you, Vladimir. Best, Tobias On 11.08.2014 18:14, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 8/11/14 12:48 AM, Tobias Hartmann wrote: >> Hi, >> >> please review this 8u40 backport request. The changes were pushed on >> Wednesday and nightly testing showed no problems. >> >> Changes for JDK9 applied to 8u40 without conflicts. >> >> Master bug: https://bugs.openjdk.java.net/browse/JDK-8029443 >> Webrev: http://cr.openjdk.java.net/~thartmann/8029443/webrev.03/ >> Changeset: >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e6a16cb925ca >> >> Thanks, >> Tobias From kim.barrett at oracle.com Tue Aug 12 04:58:52 2014 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 12 Aug 2014 00:58:52 -0400 Subject: RFR: 8047952 : (s) Remove FORTIFY_SOURCE from fastdebug and slowdebug builds In-Reply-To: References: <40C6E590-CE6C-4782-8C4A-5736E3075B90@oracle.com> <75701664-D9E3-4568-8CFC-D8FDFCFEF655@oracle.com> Message-ID: <2DE1AD5B-B1B9-4D71-95B1-44E3765BCD35@oracle.com> On Aug 11, 2014, at 7:09 PM, Mike Duigou wrote: > > You are correct. The release and fastdebug need to be combined into one clause. I will fix this. Bash 4.0 doesn't appear to complain about the fallthrough but better to be compliant. Other than that, looks good. From stefan.karlsson at oracle.com Tue Aug 12 06:14:41 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 12 Aug 2014 08:14:41 +0200 Subject: RFR: 8054823: Add size_t as a valid VM flag type In-Reply-To: <53E93109.8060601@oracle.com> References: <53E8C9A2.70607@oracle.com> <53E8F0D9.6020002@oracle.com> <53E9017D.6040902@oracle.com> <53E93109.8060601@oracle.com> Message-ID: <53E9B0D1.1030403@oracle.com> On 11/08/14 23:09, Vladimir Ivanov wrote: > test/gc/arguments/TestArrayAllocatorMallocLimit.java > 25 * @test TestArrayAlocatorMallocLimit at test > > Typo. Fixed. > > Otherwise, looks good. Great! thanks, StefanK > > Best regards, > Vladimir Ivanov > > On 8/11/14, 10:46 AM, Stefan Karlsson wrote: >> On 2014-08-11 18:35, Vladimir Kozlov wrote: >>> Stefan, >>> >>> Seems fine to me, >> >> Thanks for reviewing! >> >>> except new tests don't have correct @bug. >>> >>> 27 * The test helsp verifying that size_t flags can be set/read. >>> ^ typo >>> >>> SizeTTest.java - remove @author >> >> Too much copy-n-paste. I've updated the patch and did some additional >> cleanups to the jtreg annotations: >> http://cr.openjdk.java.net/~stefank/8054823/webrev.01.delta/ >> http://cr.openjdk.java.net/~stefank/8054823/webrev.01/ >> >> thanks, >> StefanK >> >>> >>> Thanks, >>> Vladimir >>> >>> On 8/11/14 6:48 AM, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> I propose that we add 'size_t' as a valid VM flag type. This will >>>> help with type safety, since we won't have to cast >>>> back and forth between the two types. >>>> >>>> This patch adds the framework, but only changes one of the flags. I >>>> choose to change one of our experimental flags, so >>>> that I could write tests for this change. >>>> >>>> Please, review this patch: >>>> http://cr.openjdk.java.net/~stefank/8054823/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8054823 >>>> >>>> thanks, >>>> StefanK >> From roland.westrelin at oracle.com Tue Aug 12 07:59:07 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 12 Aug 2014 09:59:07 +0200 Subject: [8u40] Backport RFR (L) 8035605 and 8035968: C2 support for SHA on SPARC In-Reply-To: <53E92F57.6030907@oracle.com> References: <53E92F57.6030907@oracle.com> Message-ID: <1A4EEB0E-8DE2-4E40-B535-317322887FE2@oracle.com> Ok. Roland. On Aug 11, 2014, at 11:02 PM, Vladimir Kozlov wrote: > 8u40 backport request. Changes were pushed two months ago into jdk9, no problems were found since then. > > The only few modifications I have to do is due to 8034812 changes which removed Compile* argument from Node::new() in jdk9. And 8026796 which removed 'Parse* parent_parser' argument and is not backported into 8u yet. > > 8035968: Leverage CPU Instructions to Improve SHA Performance on SPARC > https://bugs.openjdk.java.net/browse/JDK-8035968 > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/edf93f2ccf99 > > 8035605: Expand functionality of PredictedIntrinsicGenerator > https://bugs.openjdk.java.net/browse/JDK-8035605 > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/9be8f500449d > > Thanks, > Vladimir From tobias.hartmann at oracle.com Tue Aug 12 09:20:30 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 12 Aug 2014 11:20:30 +0200 Subject: [9] RFR(S): 8054402: "klass->is_loader_alive(_is_alive)) failed: must be alive" for anonymous classes Message-ID: <53E9DC5E.2090604@oracle.com> Hi, please review the following patch that fixes JDK-8054402. Bug: https://bugs.openjdk.java.net/browse/JDK-8054402 Webrev: http://cr.openjdk.java.net/~thartmann/8054402/webrev.00/ == Problem == The test [1] rarely fails with the assert 'klass->is_loader_alive(_is_alive)) failed: must be alive' in 'CheckClass::check_class' (nmethod.cpp) because a IC in a compiled method [2] references an unloaded anonymous Klass* [3] (i.e., the Klass has an unloaded mirror class [4]). Usually, ICs are cleaned in 'nmethod::do_unloading' by 'clean_ic_if_metadata_is_dead' if they reference stale metadata. In this case, the check for stale metadata is not performed because 'unloading_occurred' is set to false and therefore no class unloading should have happened. The error is in 'SystemDictionary::do_unloading'. First, 'ClassLoaderDataGraph::do_unloading ' is invoked to remove the class loader data of unloaded classes. Next, 'Dictionary::do_unloading' is called to remove the system dictionary entries of dead classes. 'unloading_occurred' is only set to true if dead class loaders were found _and_ entries were removed from the system dictionary. The problem is that anonymous classes are not in the system dictionary. In the rare case where only anonymous classes were unloaded, 'unloading_occurred' is set to false even if (anonymous) class unloading occurred. == Solution == The variable 'unloading_occurred' is always set to true if dead class loaders were found. I was able to write a jtreg test that deterministically triggers the bug. == Testing == - New jtreg test - Failing test [1] - JPRT Thanks, Tobias [1] java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java [2] java.util.stream.Streams$RangeIntSpliterator::forEachRemaining [3] java.util.stream.StreamSpliterators$IntWrappingSpliterator$$Lambda$170/25231275 [4] java/util/stream/StreamSpliterators$IntWrappingSpliterator$$Lambda$170 From sgehwolf at redhat.com Tue Aug 12 10:04:22 2014 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 12 Aug 2014 12:04:22 +0200 Subject: RFR: 8047952 : (s) Remove FORTIFY_SOURCE from fastdebug and slowdebug builds In-Reply-To: References: <40C6E590-CE6C-4782-8C4A-5736E3075B90@oracle.com> <75701664-D9E3-4568-8CFC-D8FDFCFEF655@oracle.com> Message-ID: <1407837862.3177.7.camel@localhost.localdomain> On Mon, 2014-08-11 at 16:09 -0700, Mike Duigou wrote: > You are correct. The release and fastdebug need to be combined into one > clause. I will fix this. Bash 4.0 doesn't appear to complain about the > fallthrough but better to be compliant. Correct me if I'm wrong, but aren't you only adjusting flags for "slowdebug" builds? If so why do it with a case-construct rather than a simple if? How about this? diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 --- a/common/autoconf/flags.m4 +++ b/common/autoconf/flags.m4 @@ -337,25 +337,15 @@ # bounds, memory and behavior checking options if test "x$TOOLCHAIN_TYPE" = xgcc; then - case $DEBUG_LEVEL in - release ) - # no adjustment - ;; - fastdebug ) - # Add compile time bounds checks. - CFLAGS_DEBUG_OPTIONS="-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1" - CXXFLAGS_DEBUG_OPTIONS="-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1" - ;; - slowdebug ) - # Add runtime bounds checks and symbol info. - CFLAGS_DEBUG_OPTIONS="-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-all --param ssp-buffer-size=1" - CXXFLAGS_DEBUG_OPTIONS="-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-all --param ssp-buffer-size=1" + if test "x$DEBUG_LEVEL" = xslowdebug; then + # Add runtime stack smashing and undefined behavior checks + CFLAGS_DEBUG_OPTIONS="-fstack-protector-all --param ssp-buffer-size=1" + CXXFLAGS_DEBUG_OPTIONS="-fstack-protector-all --param ssp-buffer-size=1" if test "x$HAS_CFLAG_DETECT_UNDEFINED_BEHAVIOR" = "xtrue"; then CFLAGS_DEBUG_OPTIONS="$CFLAGS_DEBUG_OPTIONS $CFLAG_DETECT_UNDEFINED_BEHAVIOR_FLAG" CXXFLAGS_DEBUG_OPTIONS="$CXXFLAGS_DEBUG_OPTIONS $CFLAG_DETECT_UNDEFINED_BEHAVIOR_FLAG" fi - ;; - esac + fi fi AC_SUBST(CFLAGS_DEBUG_OPTIONS) AC_SUBST(CXXFLAGS_DEBUG_OPTIONS) A slowdebug build builds fine for me on Fedora 20 with this change to your patch. Otherwise I'm seeing the configure error due to the wrong bash snippet as Kim described. Cheers, Severin > Mike > > On Aug 11 2014, at 15:05 , Kim Barrett wrote: > > > On Aug 8, 2014, at 8:23 PM, Mike Duigou wrote: > >> > >> Hello all; > >> > >> A previous version of this changeset was focused on disabling FORTIFY_SOURCE only for specific files with optimization disabled. This version entirely disables FORTIFY_SOURCE for all portions of the build. After additional problems; incompatibility of FORTIFY_SOURCE with -O0, lack of consistent support for FORTIFY_SOURCE in some distributions of glibc, etc. this seems like the best course. Should the separate issues with -Od be resolved then FORTIFY_SOURCE could be re-enabled selectively for specific platforms. > >> > >> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047952/1/webrev/ > >> jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047952 > >> > >> Mike > > > > In common/autoconf/flags.m4: > > > > 339 if test "x$TOOLCHAIN_TYPE" = xgcc; then > > 340 case $DEBUG_LEVEL in > > 341 release ) > > 342 fastdebug ) > > 343 # no adjustment > > 344 ;; > > > > The bash documentation I'm looking at says each clause must end with > > ";;", and makes no mention of any sort of fall-through from one clause > > to the next. > > > > "... the ')' operator terminates a pattern list. A list of patterns > > and an associated command-list is known as a clause. Each clause > > must be terminated with ';;'" > > > > It's not clear from that description what should happen for line 341. > > > From igor.ignatyev at oracle.com Tue Aug 12 10:11:49 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 12 Aug 2014 14:11:49 +0400 Subject: RFR: 8011397: JTREG needs to copy additional WhiteBox class file to JTwork/scratch/sun/hotspot In-Reply-To: <53E8F1F8.30305@oracle.com> References: <536B7CF0.6010508@oracle.com> <2443586.qRToXKmNqX@mgerdin03> <53C5482A.9090001@oracle.com> <12779611.jBGqJ13gfp@ehelin-laptop> <53C65E4A.4020401@oracle.com> <53D6638E.4070501@oracle.com> <53E8A44F.5090000@oracle.com> <53E8A691.60803@oracle.com> <53E8A8FB.2080505@oracle.com> <53E8CB69.5010003@oracle.com> <53E8F1F8.30305@oracle.com> Message-ID: <53E9E865.2080305@oracle.com> Looks good to me. Igor On 08/11/2014 08:40 PM, Vladimir Kozlov wrote: > Looks fine. > > Thanks, > Vladimir > > On 8/11/14 6:55 AM, Andrey Zakharov wrote: >> Hi, all >> Here is updated patch with recent added tests: >> >> * >> ./test/compiler/classUnloading/methodUnloading/TestMethodUnloading.java >> * ./test/gc/class_unloading/TestCMSClassUnloadingEnabledHWM.java >> * ./test/gc/class_unloading/TestG1ClassUnloadingHWM.java >> >> webrev: >> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.04/ >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8011397 >> >> Thanks. >> >> On 11.08.2014 15:28, Andrey Zakharov wrote: >>> Hi, Igor. >>> I have another counts with applied patch, but it looks like couple of >>> tests has beed added since last check. >>> >>> $ grep -Rl --exclude-dir=testlibrary >>> "sun.hotspot.WhiteBox\$WhiteBoxPermission" ./test/| wc -l >>> 133 >>> >>> $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox" ./test/| >>> wc -l >>> 142 >>> >>> Will update patch soon. >>> Thanks. >>> >>> >>> On 11.08.2014 15:18, Igor Ignatyev wrote: >>>> Andrey, >>>> >>>> could you please look at and fix other tests which use whitebox? >>>> >>>> $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox" ./test | >>>> wc -l >>>> 139 >>>> $ grep -Rl --exclude-dir=testlibrary >>>> "sun.hotspot.WhiteBox\$WhiteBoxPermission" ./test/ | wc -l >>>> 10 >>>> >>>> Thanks >>>> Igor >>>> >>>> On 08/11/2014 03:09 PM, Andrey Zakharov wrote: >>>>> Hi, all >>>>> >>>>> Is it possible to review this below >>>>> webrev: >>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>> >>>>> Thanks. >>>>> >>>>> On 28.07.2014 18:51, Andrey Zakharov wrote: >>>>>> Hi, all. >>>>>> I've prepared rechecked and verified fix for subject. >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>> >>>>>> I've grep'ed workspace by sun.hotspot.WhiteBox and fixed every file. >>>>>> Also I've updated copyright. >>>>>> Testing was done by aurora batch 538304.ute.hs_jtreg.accept.full >>>>>> It looks good. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> >>>>>> On 16.07.2014 15:13, Andrey Zakharov wrote: >>>>>>> >>>>>>> On 16.07.2014 14:39, Erik Helin wrote: >>>>>>>> On Tuesday 15 July 2014 19:26:34 PM Andrey Zakharov wrote: >>>>>>>>> Hi, Erik, Bengt. Could you, please, review this too. >>>>>>>> Andrey, why did you only update a couple of tests to also copy >>>>>>>> sun.hotspot.WhiteBox$WhiteBoxPermission? You updated 14 tests, >>>>>>>> there are >>>>>>>> still 116 tests using sun.hotspot.WhiteBox. >>>>>>>> >>>>>>>> Why doesn't these 116 tests have to be updated? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Erik >>>>>>> Thanks Erik. Actually this first one patch >>>>>>> 8011397.WhiteBoxPermission >>>>>>> >>>>>>> >>>>>>> is correct. I will rework it and upload to webrev space. >>>>>>> >>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> On 15.07.2014 17:58, Mikael Gerdin wrote: >>>>>>>>>> Andrey, >>>>>>>>>> >>>>>>>>>> On Monday 07 July 2014 20.48.21 Andrey Zakharov wrote: >>>>>>>>>>> Hi ,all >>>>>>>>>>> Mikael, can you please review it. >>>>>>>>>> Sorry, I was on vacation last week. >>>>>>>>>> >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ >>>>>>>>>>> >>>>>>>>>> Looks ok for now. We should consider revisiting this by either >>>>>>>>>> switching >>>>>>>>>> to >>>>>>>>>> @run main/bootclasspath >>>>>>>>>> or >>>>>>>>>> deleting the WhiteboxPermission nested class and using some >>>>>>>>>> other way for >>>>>>>>>> permission checks (if they are at all needed). >>>>>>>>>> >>>>>>>>>> /Mikael >>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> On 25.06.2014 19:08, Andrey Zakharov wrote: >>>>>>>>>>>> Hi, all >>>>>>>>>>>> So in progress of previous email - >>>>>>>>>>>> webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks. >>>>>>>>>>>> >>>>>>>>>>>> On 16.06.2014 19:57, Andrey Zakharov wrote: >>>>>>>>>>>>> Hi, all >>>>>>>>>>>>> So issue is that when tests with WhiteBox API has been >>>>>>>>>>>>> invoked with >>>>>>>>>>>>> -Xverify:all it fails with Exception >>>>>>>>>>>>> java.lang.NoClassDefFoundError: >>>>>>>>>>>>> sun/hotspot/WhiteBox$WhiteBoxPermission >>>>>>>>>>>>> Solutions that are observed: >>>>>>>>>>>>> 1. Copy WhiteBoxPermission with WhiteBox. But >>>>>>>>>>>>> >>>>>>>>>>>>>>> Perhaps this is a good time to get rid of ClassFileInstaller >>>>>>>>>>>>> altogether? >>>>>>>>>>>>> >>>>>>>>>>>>> 2. Using bootclasspath to hook pre-built whitebox (due >>>>>>>>>>>>> @library >>>>>>>>>>>>> /testlibrary/whitebox) . Some tests has @run main/othervm, >>>>>>>>>>>>> some uses >>>>>>>>>>>>> ProcessBuilder. >>>>>>>>>>>>> >>>>>>>>>>>>> - main/othervm/bootclasspath adds ${test.src} and >>>>>>>>>>>>> >>>>>>>>>>>>> ${test.classes}to options. >>>>>>>>>>>>> >>>>>>>>>>>>> - With ProcessBuilder we can just add ${test.classes} >>>>>>>>>>>>> >>>>>>>>>>>>> Question here is, can it broke some tests ? While testing >>>>>>>>>>>>> this, I >>>>>>>>>>>>> found onlyhttps://bugs.openjdk.java.net/browse/JDK-8046231, >>>>>>>>>>>>> others >>>>>>>>>>>>> looks fine. >>>>>>>>>>>>> >>>>>>>>>>>>> 3. Make ClassFileInstaller deal with inner classes like that: >>>>>>>>>>>>> diff -r 6ed24aedeef0 -r c01651363ba8 >>>>>>>>>>>>> test/testlibrary/ClassFileInstaller.java >>>>>>>>>>>>> --- a/test/testlibrary/ClassFileInstaller.java Thu Jun 05 >>>>>>>>>>>>> 19:02:56 >>>>>>>>>>>>> 2014 +0400 >>>>>>>>>>>>> +++ b/test/testlibrary/ClassFileInstaller.java Fri Jun 06 >>>>>>>>>>>>> 18:18:11 >>>>>>>>>>>>> 2014 +0400 >>>>>>>>>>>>> @@ -50,6 +50,16 @@ >>>>>>>>>>>>> >>>>>>>>>>>>> } >>>>>>>>>>>>> // Create the class file >>>>>>>>>>>>> Files.copy(is, p, >>>>>>>>>>>>> StandardCopyOption.REPLACE_EXISTING); >>>>>>>>>>>>> >>>>>>>>>>>>> + >>>>>>>>>>>>> + for (Class cls : >>>>>>>>>>>>> Class.forName(arg).getDeclaredClasses()) { >>>>>>>>>>>>> + //if >>>>>>>>>>>>> (!Modifier.isStatic(cls.getModifiers())) { >>>>>>>>>>>>> + String pathNameSub = >>>>>>>>>>>>> cls.getCanonicalName().replace('.', '/').concat(".class"); >>>>>>>>>>>>> + Path pathSub = Paths.get(pathNameSub); >>>>>>>>>>>>> + InputStream streamSub = >>>>>>>>>>>>> cl.getResourceAsStream(pathNameSub); >>>>>>>>>>>>> + Files.copy(streamSub, pathSub, >>>>>>>>>>>>> StandardCopyOption.REPLACE_EXISTING); >>>>>>>>>>>>> + //} >>>>>>>>>>>>> + } >>>>>>>>>>>>> + >>>>>>>>>>>>> >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> Works fine for ordinary classes, but fails for WhiteBox due >>>>>>>>>>>>> Class.forName initiate Class. WhiteBox has "static" >>>>>>>>>>>>> section, and >>>>>>>>>>>>> initialization fails as it cannot bind to native methods >>>>>>>>>>>>> "registerNatives" and so on. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> So, lets return to first one option? Just add everywhere >>>>>>>>>>>>> >>>>>>>>>>>>> * @run main ClassFileInstaller sun.hotspot.WhiteBox >>>>>>>>>>>>> >>>>>>>>>>>>> + * @run main ClassFileInstaller >>>>>>>>>>>>> sun.hotspot.WhiteBox$WhiteBoxPermission >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks. >>>>>>>>>>>>> >>>>>>>>>>>>> On 10.06.2014 19:43, Igor Ignatyev wrote: >>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't like this idea, since it completely changes the >>>>>>>>>>>>>> tests. >>>>>>>>>>>>>> 'run/othervm/bootclasspath' adds all paths from CP to BCP, >>>>>>>>>>>>>> so the >>>>>>>>>>>>>> tests whose main idea was testing WB methods themselves >>>>>>>>>>>>>> (sanity, >>>>>>>>>>>>>> compiler/whitebox, ...) don't check that it's possible to >>>>>>>>>>>>>> use WB >>>>>>>>>>>>>> when the application isn't in BCP. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Igor >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 06/09/2014 06:59 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>> Hi, everybody >>>>>>>>>>>>>>> I have tested my changes on major platforms and found one >>>>>>>>>>>>>>> bug, filed: >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046231 >>>>>>>>>>>>>>> Also, i did another try to make ClassFileInstaller to >>>>>>>>>>>>>>> copy all inner >>>>>>>>>>>>>>> classes within parent, but this fails for WhiteBox due >>>>>>>>>>>>>>> its static >>>>>>>>>>>>>>> "registerNatives" dependency. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please, review suggested changes: >>>>>>>>>>>>>>> - replace ClassFileInstaller and run/othervm with >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> "run/othervm/bootclasspath". >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> bootclasspath parameter for othervm >>>>>>>>>>>>>>> adds-Xbootclasspath/a: >>>>>>>>>>>>>>> option with ${test.src} and ${test.classes}according to >>>>>>>>>>>>>>> http://hg.openjdk.java.net/code-tools/jtreg/file/31003a1c46d9/src/sha >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> re >>>>>>>>>>>>>>> /classes/com/sun/javatest/regtest/MainAction.java. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is this suitable for our needs - give to test compiled >>>>>>>>>>>>>>> WhiteBox? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - replace explicit -Xbootclasspath option values >>>>>>>>>>>>>>> (".") in >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ProcessBuilder invocations to ${test.classes} where >>>>>>>>>>>>>>> WhiteBox has been >>>>>>>>>>>>>>> compiled. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 23.05.2014 15:40, Andrey Zakharov wrote: >>>>>>>>>>>>>>>> On 22.05.2014 12:47, Igor Ignatyev wrote: >>>>>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 1. You changed dozen of tests, have you tested your >>>>>>>>>>>>>>>>> changes? >>>>>>>>>>>>>>>> Locally, aurora on the way. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2. Your changes of year in copyright is wrong. it has >>>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>>> $first_year, [$last_year, ], see Mark's email[1] for >>>>>>>>>>>>>>>>> details. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/jdk7-dev/2010-May/001321.htm >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> l >>>>>>>>>>>>>>>> Thanks, fixed. will be uploaded soon. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Igor >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 05/21/2014 07:37 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>> On 13.05.2014 14:43, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>>>>>> So here is trivial patch - >>>>>>>>>>>>>>>>>>> removing ClassFileInstaller sun.hotspot.WhiteBox and >>>>>>>>>>>>>>>>>>> adding >>>>>>>>>>>>>>>>>>> main/othervm/bootclasspath >>>>>>>>>>>>>>>>>>> where this needed >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Also, some tests are modified as >>>>>>>>>>>>>>>>>>> - "-Xbootclasspath/a:.", >>>>>>>>>>>>>>>>>>> + "-Xbootclasspath/a:" + >>>>>>>>>>>>>>>>>>> System.getProperty("test.classes"), >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>> webrev:http://cr.openjdk.java.net/~jwilhelm/8011397/webrev.02/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 09.05.2014 12:13, Mikael Gerdin wrote: >>>>>>>>>>>>>>>>>>>> On Thursday 08 May 2014 19.28.13 Igor Ignatyev wrote: >>>>>>>>>>>>>>>>>>>>> // cc'ing hotspot-dev instaed of compiler, runtime >>>>>>>>>>>>>>>>>>>>> and gc >>>>>>>>>>>>>>>>>>>>> lists. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 05/08/2014 07:09 PM, Filipp Zhinkin wrote: >>>>>>>>>>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I've CC'ed compiler and runtime mailing list, >>>>>>>>>>>>>>>>>>>>>> because you're >>>>>>>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>>>>>>>> affect test for other components as too. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I don't like your solution (but I'm not a >>>>>>>>>>>>>>>>>>>>>> reviewer, so treat >>>>>>>>>>>>>>>>>>>>>> my >>>>>>>>>>>>>>>>>>>>>> words >>>>>>>>>>>>>>>>>>>>>> just as suggestion), >>>>>>>>>>>>>>>>>>>>>> because we'll have to write more meta information >>>>>>>>>>>>>>>>>>>>>> for each >>>>>>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>>>>>> and it >>>>>>>>>>>>>>>>>>>>>> is very easy to >>>>>>>>>>>>>>>>>>>>>> forget to install WhiteBoxPermission if you don't >>>>>>>>>>>>>>>>>>>>>> test your >>>>>>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>>> some security manager. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> From my point of view, it will be better to >>>>>>>>>>>>>>>>>>>>>> extend >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> ClassFileInstaller >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> so it will copy not only >>>>>>>>>>>>>>>>>>>>>> a class whose name was passed as an arguments, but >>>>>>>>>>>>>>>>>>>>>> also all >>>>>>>>>>>>>>>>>>>>>> inner >>>>>>>>>>>>>>>>>>>>>> classes of that class. >>>>>>>>>>>>>>>>>>>>>> And if someone want copy only specified class >>>>>>>>>>>>>>>>>>>>>> without inner >>>>>>>>>>>>>>>>>>>>>> classes, >>>>>>>>>>>>>>>>>>>>>> then some option >>>>>>>>>>>>>>>>>>>>>> could be added to ClassFileInstaller to force such >>>>>>>>>>>>>>>>>>>>>> behaviour. >>>>>>>>>>>>>>>>>>>> Perhaps this is a good time to get rid of >>>>>>>>>>>>>>>>>>>> ClassFileInstaller >>>>>>>>>>>>>>>>>>>> altogether? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8009117 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The reason for its existence is that the WhiteBox >>>>>>>>>>>>>>>>>>>> class needs >>>>>>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>>>>>> boot class path. >>>>>>>>>>>>>>>>>>>> If we can live with having all the test's classes on >>>>>>>>>>>>>>>>>>>> the boot >>>>>>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>>>>>> path then >>>>>>>>>>>>>>>>>>>> we could use the /bootclasspath option in jtreg as >>>>>>>>>>>>>>>>>>>> stated in >>>>>>>>>>>>>>>>>>>> the RFE. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> /Mikael >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> Filipp. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 05/08/2014 04:47 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>>>>>>> Hi! >>>>>>>>>>>>>>>>>>>>>>> Suggesting patch with fixes for >>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20275/8011397 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> .t >>>>>>>>>>>>>>>>>>>>>>> gz >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> patch: >>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20274/8011397 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> .W >>>>>>>>>>>>>>>>>>>>>>> hiteBoxPer >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> mission >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>> >>>>>> >>>>> >>> >> From rickard.backman at oracle.com Tue Aug 12 11:39:30 2014 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Tue, 12 Aug 2014 13:39:30 +0200 Subject: [8u40] Backport 8031994: java/lang/Character/CheckProp test times out Message-ID: <20140812113930.GP7829@rbackman> Hi, requesting reviews for this backport. Webrev: http://cr.openjdk.java.net/~rbackman/8031994/ Bug: https://bugs.openjdk.java.net/browse/JDK-8031994 Commit: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/82a396fba1e6 Thanks /R From mikael.gerdin at oracle.com Tue Aug 12 11:42:04 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 12 Aug 2014 13:42:04 +0200 Subject: RFR: 8011397: JTREG needs to copy additional WhiteBox class file to JTwork/scratch/sun/hotspot In-Reply-To: <53E8CB69.5010003@oracle.com> References: <536B7CF0.6010508@oracle.com> <53E8A8FB.2080505@oracle.com> <53E8CB69.5010003@oracle.com> Message-ID: <1904344.AZu4ofu3BO@mgerdin03> On Monday 11 August 2014 17.55.53 Andrey Zakharov wrote: > Hi, all > Here is updated patch with recent added tests: > > * ./test/compiler/classUnloading/methodUnloading/TestMethodUnloading.java > * ./test/gc/class_unloading/TestCMSClassUnloadingEnabledHWM.java > * ./test/gc/class_unloading/TestG1ClassUnloadingHWM.java > > webrev: > http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.04/ Ok, /Mikael > Bug: > https://bugs.openjdk.java.net/browse/JDK-8011397 > > Thanks. > > On 11.08.2014 15:28, Andrey Zakharov wrote: > > Hi, Igor. > > I have another counts with applied patch, but it looks like couple of > > tests has beed added since last check. > > > > $ grep -Rl --exclude-dir=testlibrary > > "sun.hotspot.WhiteBox\$WhiteBoxPermission" ./test/| wc -l > > 133 > > > > $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox" ./test/| > > wc -l > > 142 > > > > Will update patch soon. > > Thanks. > > > > On 11.08.2014 15:18, Igor Ignatyev wrote: > >> Andrey, > >> > >> could you please look at and fix other tests which use whitebox? > >> > >> $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox" ./test | > >> wc -l > >> 139 > >> $ grep -Rl --exclude-dir=testlibrary > >> "sun.hotspot.WhiteBox\$WhiteBoxPermission" ./test/ | wc -l > >> 10 > >> > >> Thanks > >> Igor > >> > >> On 08/11/2014 03:09 PM, Andrey Zakharov wrote: > >>> Hi, all > >>> > >>> Is it possible to review this below > >>> webrev: > >>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ > >>> Bug: > >>> https://bugs.openjdk.java.net/browse/JDK-8011397 > >>> > >>> Thanks. > >>> > >>> On 28.07.2014 18:51, Andrey Zakharov wrote: > >>>> Hi, all. > >>>> I've prepared rechecked and verified fix for subject. > >>>> webrev: > >>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ > >>>> Bug: > >>>> https://bugs.openjdk.java.net/browse/JDK-8011397 > >>>> > >>>> I've grep'ed workspace by sun.hotspot.WhiteBox and fixed every file. > >>>> Also I've updated copyright. > >>>> Testing was done by aurora batch 538304.ute.hs_jtreg.accept.full > >>>> It looks good. > >>>> > >>>> Thanks. > >>>> > >>>> On 16.07.2014 15:13, Andrey Zakharov wrote: > >>>>> On 16.07.2014 14:39, Erik Helin wrote: > >>>>>> On Tuesday 15 July 2014 19:26:34 PM Andrey Zakharov wrote: > >>>>>>> Hi, Erik, Bengt. Could you, please, review this too. > >>>>>> > >>>>>> Andrey, why did you only update a couple of tests to also copy > >>>>>> sun.hotspot.WhiteBox$WhiteBoxPermission? You updated 14 tests, > >>>>>> there are > >>>>>> still 116 tests using sun.hotspot.WhiteBox. > >>>>>> > >>>>>> Why doesn't these 116 tests have to be updated? > >>>>>> > >>>>>> Thanks, > >>>>>> Erik > >>>>> > >>>>> Thanks Erik. Actually this first one patch 8011397.WhiteBoxPermission > >>>>> >>>>> xPermission> > >>>>> > >>>>> is correct. I will rework it and upload to webrev space. > >>>>> > >>>>>>> Thanks. > >>>>>>> > >>>>>>> On 15.07.2014 17:58, Mikael Gerdin wrote: > >>>>>>>> Andrey, > >>>>>>>> > >>>>>>>> On Monday 07 July 2014 20.48.21 Andrey Zakharov wrote: > >>>>>>>>> Hi ,all > >>>>>>>>> Mikael, can you please review it. > >>>>>>>> > >>>>>>>> Sorry, I was on vacation last week. > >>>>>>>> > >>>>>>>>> webrev: > >>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ > >>>>>>>> > >>>>>>>> Looks ok for now. We should consider revisiting this by either > >>>>>>>> switching > >>>>>>>> to > >>>>>>>> @run main/bootclasspath > >>>>>>>> or > >>>>>>>> deleting the WhiteboxPermission nested class and using some > >>>>>>>> other way for > >>>>>>>> permission checks (if they are at all needed). > >>>>>>>> > >>>>>>>> /Mikael > >>>>>>>> > >>>>>>>>> Thanks. > >>>>>>>>> > >>>>>>>>> On 25.06.2014 19:08, Andrey Zakharov wrote: > >>>>>>>>>> Hi, all > >>>>>>>>>> So in progress of previous email - > >>>>>>>>>> webrev: > >>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Thanks. > >>>>>>>>>> > >>>>>>>>>> On 16.06.2014 19:57, Andrey Zakharov wrote: > >>>>>>>>>>> Hi, all > >>>>>>>>>>> So issue is that when tests with WhiteBox API has been > >>>>>>>>>>> invoked with > >>>>>>>>>>> -Xverify:all it fails with Exception > >>>>>>>>>>> java.lang.NoClassDefFoundError: > >>>>>>>>>>> sun/hotspot/WhiteBox$WhiteBoxPermission > >>>>>>>>>>> Solutions that are observed: > >>>>>>>>>>> 1. Copy WhiteBoxPermission with WhiteBox. But > >>>>>>>>>>> > >>>>>>>>>>>>> Perhaps this is a good time to get rid of ClassFileInstaller > >>>>>>>>>>> > >>>>>>>>>>> altogether? > >>>>>>>>>>> > >>>>>>>>>>> 2. Using bootclasspath to hook pre-built whitebox (due @library > >>>>>>>>>>> /testlibrary/whitebox) . Some tests has @run main/othervm, > >>>>>>>>>>> some uses > >>>>>>>>>>> ProcessBuilder. > >>>>>>>>>>> > >>>>>>>>>>> - main/othervm/bootclasspath adds ${test.src} and > >>>>>>>>>>> > >>>>>>>>>>> ${test.classes}to options. > >>>>>>>>>>> > >>>>>>>>>>> - With ProcessBuilder we can just add ${test.classes} > >>>>>>>>>>> > >>>>>>>>>>> Question here is, can it broke some tests ? While testing > >>>>>>>>>>> this, I > >>>>>>>>>>> found onlyhttps://bugs.openjdk.java.net/browse/JDK-8046231, > >>>>>>>>>>> others > >>>>>>>>>>> looks fine. > >>>>>>>>>>> > >>>>>>>>>>> 3. Make ClassFileInstaller deal with inner classes like that: > >>>>>>>>>>> diff -r 6ed24aedeef0 -r c01651363ba8 > >>>>>>>>>>> test/testlibrary/ClassFileInstaller.java > >>>>>>>>>>> --- a/test/testlibrary/ClassFileInstaller.java Thu Jun 05 > >>>>>>>>>>> 19:02:56 > >>>>>>>>>>> 2014 +0400 > >>>>>>>>>>> +++ b/test/testlibrary/ClassFileInstaller.java Fri Jun 06 > >>>>>>>>>>> 18:18:11 > >>>>>>>>>>> 2014 +0400 > >>>>>>>>>>> @@ -50,6 +50,16 @@ > >>>>>>>>>>> > >>>>>>>>>>> } > >>>>>>>>>>> // Create the class file > >>>>>>>>>>> Files.copy(is, p, > >>>>>>>>>>> > >>>>>>>>>>> StandardCopyOption.REPLACE_EXISTING); > >>>>>>>>>>> > >>>>>>>>>>> + > >>>>>>>>>>> + for (Class cls : > >>>>>>>>>>> Class.forName(arg).getDeclaredClasses()) { > >>>>>>>>>>> + //if > >>>>>>>>>>> (!Modifier.isStatic(cls.getModifiers())) { > >>>>>>>>>>> + String pathNameSub = > >>>>>>>>>>> cls.getCanonicalName().replace('.', '/').concat(".class"); > >>>>>>>>>>> + Path pathSub = Paths.get(pathNameSub); > >>>>>>>>>>> + InputStream streamSub = > >>>>>>>>>>> cl.getResourceAsStream(pathNameSub); > >>>>>>>>>>> + Files.copy(streamSub, pathSub, > >>>>>>>>>>> StandardCopyOption.REPLACE_EXISTING); > >>>>>>>>>>> + //} > >>>>>>>>>>> + } > >>>>>>>>>>> + > >>>>>>>>>>> > >>>>>>>>>>> } > >>>>>>>>>>> > >>>>>>>>>>> } > >>>>>>>>>>> > >>>>>>>>>>> } > >>>>>>>>>>> > >>>>>>>>>>> Works fine for ordinary classes, but fails for WhiteBox due > >>>>>>>>>>> Class.forName initiate Class. WhiteBox has "static" section, > >>>>>>>>>>> and > >>>>>>>>>>> initialization fails as it cannot bind to native methods > >>>>>>>>>>> "registerNatives" and so on. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> So, lets return to first one option? Just add everywhere > >>>>>>>>>>> > >>>>>>>>>>> * @run main ClassFileInstaller sun.hotspot.WhiteBox > >>>>>>>>>>> > >>>>>>>>>>> + * @run main ClassFileInstaller > >>>>>>>>>>> sun.hotspot.WhiteBox$WhiteBoxPermission > >>>>>>>>>>> > >>>>>>>>>>> Thanks. > >>>>>>>>>>> > >>>>>>>>>>> On 10.06.2014 19:43, Igor Ignatyev wrote: > >>>>>>>>>>>> Andrey, > >>>>>>>>>>>> > >>>>>>>>>>>> I don't like this idea, since it completely changes the tests. > >>>>>>>>>>>> 'run/othervm/bootclasspath' adds all paths from CP to BCP, > >>>>>>>>>>>> so the > >>>>>>>>>>>> tests whose main idea was testing WB methods themselves > >>>>>>>>>>>> (sanity, > >>>>>>>>>>>> compiler/whitebox, ...) don't check that it's possible to > >>>>>>>>>>>> use WB > >>>>>>>>>>>> when the application isn't in BCP. > >>>>>>>>>>>> > >>>>>>>>>>>> Igor > >>>>>>>>>>>> > >>>>>>>>>>>> On 06/09/2014 06:59 PM, Andrey Zakharov wrote: > >>>>>>>>>>>>> Hi, everybody > >>>>>>>>>>>>> I have tested my changes on major platforms and found one > >>>>>>>>>>>>> bug, filed: > >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046231 > >>>>>>>>>>>>> Also, i did another try to make ClassFileInstaller to copy > >>>>>>>>>>>>> all inner > >>>>>>>>>>>>> classes within parent, but this fails for WhiteBox due its > >>>>>>>>>>>>> static > >>>>>>>>>>>>> "registerNatives" dependency. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Please, review suggested changes: > >>>>>>>>>>>>> - replace ClassFileInstaller and run/othervm with > >>>>>>>>>>>>> > >>>>>>>>>>>>> "run/othervm/bootclasspath". > >>>>>>>>>>>>> > >>>>>>>>>>>>> bootclasspath parameter for othervm > >>>>>>>>>>>>> > >>>>>>>>>>>>> adds-Xbootclasspath/a: > >>>>>>>>>>>>> option with ${test.src} and ${test.classes}according to > >>>>>>>>>>>>> http://hg.openjdk.java.net/code-tools/jtreg/file/31003a1c46d9/ > >>>>>>>>>>>>> src/sha > >>>>>>>>>>>>> > >>>>>>>>>>>>> re > >>>>>>>>>>>>> /classes/com/sun/javatest/regtest/MainAction.java. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Is this suitable for our needs - give to test compiled > >>>>>>>>>>>>> WhiteBox? > >>>>>>>>>>>>> > >>>>>>>>>>>>> - replace explicit -Xbootclasspath option values (".") in > >>>>>>>>>>>>> > >>>>>>>>>>>>> ProcessBuilder invocations to ${test.classes} where > >>>>>>>>>>>>> WhiteBox has been > >>>>>>>>>>>>> compiled. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Webrev: > >>>>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev. > >>>>>>>>>>>>> 00/ > >>>>>>>>>>>>> > >>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8011397 > >>>>>>>>>>>>> Thanks. > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 23.05.2014 15:40, Andrey Zakharov wrote: > >>>>>>>>>>>>>> On 22.05.2014 12:47, Igor Ignatyev wrote: > >>>>>>>>>>>>>>> Andrey, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 1. You changed dozen of tests, have you tested your > >>>>>>>>>>>>>>> changes? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Locally, aurora on the way. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 2. Your changes of year in copyright is wrong. it has to be > >>>>>>>>>>>>>>> $first_year, [$last_year, ], see Mark's email[1] for > >>>>>>>>>>>>>>> details. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> [1] > >>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/jdk7-dev/2010-May/001 > >>>>>>>>>>>>>>> 321.htm > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> l > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, fixed. will be uploaded soon. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Igor > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 05/21/2014 07:37 PM, Andrey Zakharov wrote: > >>>>>>>>>>>>>>>> On 13.05.2014 14:43, Andrey Zakharov wrote: > >>>>>>>>>>>>>>>>> Hi > >>>>>>>>>>>>>>>>> So here is trivial patch - > >>>>>>>>>>>>>>>>> removing ClassFileInstaller sun.hotspot.WhiteBox and > >>>>>>>>>>>>>>>>> adding > >>>>>>>>>>>>>>>>> main/othervm/bootclasspath > >>>>>>>>>>>>>>>>> where this needed > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Also, some tests are modified as > >>>>>>>>>>>>>>>>> - "-Xbootclasspath/a:.", > >>>>>>>>>>>>>>>>> + "-Xbootclasspath/a:" + > >>>>>>>>>>>>>>>>> System.getProperty("test.classes"), > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Thanks. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> webrev:http://cr.openjdk.java.net/~jwilhelm/8011397/webrev. > >>>>>>>>>>>>>>>> 02/ > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8011397 > >>>>>>>>>>>>>>>> Thanks. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On 09.05.2014 12:13, Mikael Gerdin wrote: > >>>>>>>>>>>>>>>>>> On Thursday 08 May 2014 19.28.13 Igor Ignatyev wrote: > >>>>>>>>>>>>>>>>>>> // cc'ing hotspot-dev instaed of compiler, runtime > >>>>>>>>>>>>>>>>>>> and gc > >>>>>>>>>>>>>>>>>>> lists. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On 05/08/2014 07:09 PM, Filipp Zhinkin wrote: > >>>>>>>>>>>>>>>>>>>> Andrey, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I've CC'ed compiler and runtime mailing list, > >>>>>>>>>>>>>>>>>>>> because you're > >>>>>>>>>>>>>>>>>>>> changes > >>>>>>>>>>>>>>>>>>>> affect test for other components as too. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I don't like your solution (but I'm not a reviewer, > >>>>>>>>>>>>>>>>>>>> so treat > >>>>>>>>>>>>>>>>>>>> my > >>>>>>>>>>>>>>>>>>>> words > >>>>>>>>>>>>>>>>>>>> just as suggestion), > >>>>>>>>>>>>>>>>>>>> because we'll have to write more meta information > >>>>>>>>>>>>>>>>>>>> for each > >>>>>>>>>>>>>>>>>>>> test > >>>>>>>>>>>>>>>>>>>> and it > >>>>>>>>>>>>>>>>>>>> is very easy to > >>>>>>>>>>>>>>>>>>>> forget to install WhiteBoxPermission if you don't > >>>>>>>>>>>>>>>>>>>> test your > >>>>>>>>>>>>>>>>>>>> test > >>>>>>>>>>>>>>>>>>>> with > >>>>>>>>>>>>>>>>>>>> some security manager. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> From my point of view, it will be better to extend > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> ClassFileInstaller > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> so it will copy not only > >>>>>>>>>>>>>>>>>>>> a class whose name was passed as an arguments, but > >>>>>>>>>>>>>>>>>>>> also all > >>>>>>>>>>>>>>>>>>>> inner > >>>>>>>>>>>>>>>>>>>> classes of that class. > >>>>>>>>>>>>>>>>>>>> And if someone want copy only specified class > >>>>>>>>>>>>>>>>>>>> without inner > >>>>>>>>>>>>>>>>>>>> classes, > >>>>>>>>>>>>>>>>>>>> then some option > >>>>>>>>>>>>>>>>>>>> could be added to ClassFileInstaller to force such > >>>>>>>>>>>>>>>>>>>> behaviour. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Perhaps this is a good time to get rid of > >>>>>>>>>>>>>>>>>> ClassFileInstaller > >>>>>>>>>>>>>>>>>> altogether? > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8009117 > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> The reason for its existence is that the WhiteBox > >>>>>>>>>>>>>>>>>> class needs > >>>>>>>>>>>>>>>>>> to be > >>>>>>>>>>>>>>>>>> on the > >>>>>>>>>>>>>>>>>> boot class path. > >>>>>>>>>>>>>>>>>> If we can live with having all the test's classes on > >>>>>>>>>>>>>>>>>> the boot > >>>>>>>>>>>>>>>>>> class > >>>>>>>>>>>>>>>>>> path then > >>>>>>>>>>>>>>>>>> we could use the /bootclasspath option in jtreg as > >>>>>>>>>>>>>>>>>> stated in > >>>>>>>>>>>>>>>>>> the RFE. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> /Mikael > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>> Filipp. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> On 05/08/2014 04:47 PM, Andrey Zakharov wrote: > >>>>>>>>>>>>>>>>>>>>> Hi! > >>>>>>>>>>>>>>>>>>>>> Suggesting patch with fixes for > >>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> webrev: > >>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20275/ > >>>>>>>>>>>>>>>>>>>>> 8011397 > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> .t > >>>>>>>>>>>>>>>>>>>>> gz > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> patch: > >>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20274/ > >>>>>>>>>>>>>>>>>>>>> 8011397 > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> .W > >>>>>>>>>>>>>>>>>>>>> hiteBoxPer > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> mission > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Thanks. From rickard.backman at oracle.com Tue Aug 12 12:11:15 2014 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Tue, 12 Aug 2014 14:11:15 +0200 Subject: [8u40] Backport 8030976: Untaken paths should be more vigorously pruned at highest optimization level Message-ID: <20140812121115.GQ7829@rbackman> Hi, requesting reviews for this backport. Webrev: http://cr.openjdk.java.net/~rbackman/8030976.8u40/ Bug: https://bugs.openjdk.java.net/browse/JDK-8030976 Commit: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/6ad207fd3e26 Thanks /R From rickard.backman at oracle.com Tue Aug 12 12:15:19 2014 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Tue, 12 Aug 2014 14:15:19 +0200 Subject: [8u40] Backport 8046289: compiler/6340864/TestLongVect.java timeout with Message-ID: <20140812121519.GR7829@rbackman> Hi, requesting reviews for this backport. Webrev: http://cr.openjdk.java.net/~rbackman/8046289.3/ Bug: https://bugs.openjdk.java.net/browse/JDK-8046289 Commit: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/08250e173426 Thanks /R From staffan.larsen at oracle.com Tue Aug 12 12:25:55 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 12 Aug 2014 14:25:55 +0200 Subject: RFR: 8054823: Add size_t as a valid VM flag type In-Reply-To: <53E9017D.6040902@oracle.com> References: <53E8C9A2.70607@oracle.com> <53E8F0D9.6020002@oracle.com> <53E9017D.6040902@oracle.com> Message-ID: <6B026DBD-25F2-4B5D-B534-99C356695E98@oracle.com> About the new AttachSetGetFlag test: - To get the pid of the newly launched process use the new Process.getPid() API instead. This is also available cross platform and you can remove the only non-windows restriction. - To avoid the annoying and unstable Thread.sleep(5000) let the started program print that it is ready and wait for that string in the output. This also avoids the need for -XX:+PauseAtStartup. - To quit the started program use Process.destroyForcibly() in addition to having the process end by itself after a long timeout. Thanks, /Staffan On 11 aug 2014, at 19:46, Stefan Karlsson wrote: > On 2014-08-11 18:35, Vladimir Kozlov wrote: >> Stefan, >> >> Seems fine to me, > > Thanks for reviewing! > >> except new tests don't have correct @bug. >> >> 27 * The test helsp verifying that size_t flags can be set/read. >> ^ typo >> >> SizeTTest.java - remove @author > > Too much copy-n-paste. I've updated the patch and did some additional cleanups to the jtreg annotations: > http://cr.openjdk.java.net/~stefank/8054823/webrev.01.delta/ > http://cr.openjdk.java.net/~stefank/8054823/webrev.01/ > > thanks, > StefanK > >> >> Thanks, >> Vladimir >> >> On 8/11/14 6:48 AM, Stefan Karlsson wrote: >>> Hi all, >>> >>> I propose that we add 'size_t' as a valid VM flag type. This will help with type safety, since we won't have to cast >>> back and forth between the two types. >>> >>> This patch adds the framework, but only changes one of the flags. I choose to change one of our experimental flags, so >>> that I could write tests for this change. >>> >>> Please, review this patch: >>> http://cr.openjdk.java.net/~stefank/8054823/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8054823 >>> >>> thanks, >>> StefanK > From stefan.karlsson at oracle.com Tue Aug 12 12:42:17 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 12 Aug 2014 14:42:17 +0200 Subject: RFR: 8054823: Add size_t as a valid VM flag type In-Reply-To: <6B026DBD-25F2-4B5D-B534-99C356695E98@oracle.com> References: <53E8C9A2.70607@oracle.com> <53E8F0D9.6020002@oracle.com> <53E9017D.6040902@oracle.com> <6B026DBD-25F2-4B5D-B534-99C356695E98@oracle.com> Message-ID: <53EA0BA9.5070707@oracle.com> On 12/08/14 14:25, Staffan Larsen wrote: > About the new AttachSetGetFlag test: > > - To get the pid of the newly launched process use the new Process.getPid() API instead. This is also available cross platform and you can remove the only non-windows restriction. > > - To avoid the annoying and unstable Thread.sleep(5000) let the started program print that it is ready and wait for that string in the output. This also avoids the need for -XX:+PauseAtStartup. I just copied the code from the other attach test in the same directory test/serviceability/attach/AttachWithStalePidFile.java, but I can update my test if you want to. > > - To quit the started program use Process.destroyForcibly() in addition to having the process end by itself after a long timeout. The target process is destroyed, so the test "only" takes ~18 seconds with a product build, of which 3 x 5 seconds are the sleep you mention above. thanks, StefanK > > Thanks, > /Staffan > > On 11 aug 2014, at 19:46, Stefan Karlsson wrote: > >> On 2014-08-11 18:35, Vladimir Kozlov wrote: >>> Stefan, >>> >>> Seems fine to me, >> Thanks for reviewing! >> >>> except new tests don't have correct @bug. >>> >>> 27 * The test helsp verifying that size_t flags can be set/read. >>> ^ typo >>> >>> SizeTTest.java - remove @author >> Too much copy-n-paste. I've updated the patch and did some additional cleanups to the jtreg annotations: >> http://cr.openjdk.java.net/~stefank/8054823/webrev.01.delta/ >> http://cr.openjdk.java.net/~stefank/8054823/webrev.01/ >> >> thanks, >> StefanK >> >>> Thanks, >>> Vladimir >>> >>> On 8/11/14 6:48 AM, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> I propose that we add 'size_t' as a valid VM flag type. This will help with type safety, since we won't have to cast >>>> back and forth between the two types. >>>> >>>> This patch adds the framework, but only changes one of the flags. I choose to change one of our experimental flags, so >>>> that I could write tests for this change. >>>> >>>> Please, review this patch: >>>> http://cr.openjdk.java.net/~stefank/8054823/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8054823 >>>> >>>> thanks, >>>> StefanK From staffan.larsen at oracle.com Tue Aug 12 12:58:29 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 12 Aug 2014 14:58:29 +0200 Subject: RFR: 8054823: Add size_t as a valid VM flag type In-Reply-To: <53EA0BA9.5070707@oracle.com> References: <53E8C9A2.70607@oracle.com> <53E8F0D9.6020002@oracle.com> <53E9017D.6040902@oracle.com> <6B026DBD-25F2-4B5D-B534-99C356695E98@oracle.com> <53EA0BA9.5070707@oracle.com> Message-ID: <7F4059F8-008F-4934-8FC1-589532E66281@oracle.com> On 12 aug 2014, at 14:42, Stefan Karlsson wrote: > On 12/08/14 14:25, Staffan Larsen wrote: >> About the new AttachSetGetFlag test: >> >> - To get the pid of the newly launched process use the new Process.getPid() API instead. This is also available cross platform and you can remove the only non-windows restriction. >> >> - To avoid the annoying and unstable Thread.sleep(5000) let the started program print that it is ready and wait for that string in the output. This also avoids the need for -XX:+PauseAtStartup. > > I just copied the code from the other attach test in the same directory test/serviceability/attach/AttachWithStalePidFile.java, but I can update my test if you want to. Yes, please. > >> >> - To quit the started program use Process.destroyForcibly() in addition to having the process end by itself after a long timeout. > > The target process is destroyed, so the test "only" takes ~18 seconds with a product build, of which 3 x 5 seconds are the sleep you mention above. It should be possible to run it in < 1 sec :-) /Staffan > > thanks, > StefanK >> >> Thanks, >> /Staffan >> >> On 11 aug 2014, at 19:46, Stefan Karlsson wrote: >> >>> On 2014-08-11 18:35, Vladimir Kozlov wrote: >>>> Stefan, >>>> >>>> Seems fine to me, >>> Thanks for reviewing! >>> >>>> except new tests don't have correct @bug. >>>> >>>> 27 * The test helsp verifying that size_t flags can be set/read. >>>> ^ typo >>>> >>>> SizeTTest.java - remove @author >>> Too much copy-n-paste. I've updated the patch and did some additional cleanups to the jtreg annotations: >>> http://cr.openjdk.java.net/~stefank/8054823/webrev.01.delta/ >>> http://cr.openjdk.java.net/~stefank/8054823/webrev.01/ >>> >>> thanks, >>> StefanK >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 8/11/14 6:48 AM, Stefan Karlsson wrote: >>>>> Hi all, >>>>> >>>>> I propose that we add 'size_t' as a valid VM flag type. This will help with type safety, since we won't have to cast >>>>> back and forth between the two types. >>>>> >>>>> This patch adds the framework, but only changes one of the flags. I choose to change one of our experimental flags, so >>>>> that I could write tests for this change. >>>>> >>>>> Please, review this patch: >>>>> http://cr.openjdk.java.net/~stefank/8054823/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8054823 >>>>> >>>>> thanks, >>>>> StefanK > From stefan.karlsson at oracle.com Tue Aug 12 13:07:17 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 12 Aug 2014 15:07:17 +0200 Subject: RFR: 8054823: Add size_t as a valid VM flag type In-Reply-To: <7F4059F8-008F-4934-8FC1-589532E66281@oracle.com> References: <53E8C9A2.70607@oracle.com> <53E8F0D9.6020002@oracle.com> <53E9017D.6040902@oracle.com> <6B026DBD-25F2-4B5D-B534-99C356695E98@oracle.com> <53EA0BA9.5070707@oracle.com> <7F4059F8-008F-4934-8FC1-589532E66281@oracle.com> Message-ID: <53EA1185.3030803@oracle.com> On 12/08/14 14:58, Staffan Larsen wrote: > On 12 aug 2014, at 14:42, Stefan Karlsson wrote: > >> On 12/08/14 14:25, Staffan Larsen wrote: >>> About the new AttachSetGetFlag test: >>> >>> - To get the pid of the newly launched process use the new Process.getPid() API instead. This is also available cross platform and you can remove the only non-windows restriction. >>> >>> - To avoid the annoying and unstable Thread.sleep(5000) let the started program print that it is ready and wait for that string in the output. This also avoids the need for -XX:+PauseAtStartup. >> I just copied the code from the other attach test in the same directory test/serviceability/attach/AttachWithStalePidFile.java, but I can update my test if you want to. > Yes, please. Here's the version with the two suggestions above: http://cr.openjdk.java.net/~stefank/8054823/webrev.02.delta http://cr.openjdk.java.net/~stefank/8054823/webrev.02 > >>> - To quit the started program use Process.destroyForcibly() in addition to having the process end by itself after a long timeout. >> The target process is destroyed, so the test "only" takes ~18 seconds with a product build, of which 3 x 5 seconds are the sleep you mention above. > It should be possible to run it in < 1 sec :-) Almost: "elapsed time (seconds): 1.231" =) thanks, StefanK > > /Staffan > >> thanks, >> StefanK >>> Thanks, >>> /Staffan >>> >>> On 11 aug 2014, at 19:46, Stefan Karlsson wrote: >>> >>>> On 2014-08-11 18:35, Vladimir Kozlov wrote: >>>>> Stefan, >>>>> >>>>> Seems fine to me, >>>> Thanks for reviewing! >>>> >>>>> except new tests don't have correct @bug. >>>>> >>>>> 27 * The test helsp verifying that size_t flags can be set/read. >>>>> ^ typo >>>>> >>>>> SizeTTest.java - remove @author >>>> Too much copy-n-paste. I've updated the patch and did some additional cleanups to the jtreg annotations: >>>> http://cr.openjdk.java.net/~stefank/8054823/webrev.01.delta/ >>>> http://cr.openjdk.java.net/~stefank/8054823/webrev.01/ >>>> >>>> thanks, >>>> StefanK >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 8/11/14 6:48 AM, Stefan Karlsson wrote: >>>>>> Hi all, >>>>>> >>>>>> I propose that we add 'size_t' as a valid VM flag type. This will help with type safety, since we won't have to cast >>>>>> back and forth between the two types. >>>>>> >>>>>> This patch adds the framework, but only changes one of the flags. I choose to change one of our experimental flags, so >>>>>> that I could write tests for this change. >>>>>> >>>>>> Please, review this patch: >>>>>> http://cr.openjdk.java.net/~stefank/8054823/webrev.00/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8054823 >>>>>> >>>>>> thanks, >>>>>> StefanK From staffan.larsen at oracle.com Tue Aug 12 13:11:14 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 12 Aug 2014 15:11:14 +0200 Subject: RFR: 8054823: Add size_t as a valid VM flag type In-Reply-To: <53EA1185.3030803@oracle.com> References: <53E8C9A2.70607@oracle.com> <53E8F0D9.6020002@oracle.com> <53E9017D.6040902@oracle.com> <6B026DBD-25F2-4B5D-B534-99C356695E98@oracle.com> <53EA0BA9.5070707@oracle.com> <7F4059F8-008F-4934-8FC1-589532E66281@oracle.com> <53EA1185.3030803@oracle.com> Message-ID: On 12 aug 2014, at 15:07, Stefan Karlsson wrote: > On 12/08/14 14:58, Staffan Larsen wrote: >> On 12 aug 2014, at 14:42, Stefan Karlsson wrote: >> >>> On 12/08/14 14:25, Staffan Larsen wrote: >>>> About the new AttachSetGetFlag test: >>>> >>>> - To get the pid of the newly launched process use the new Process.getPid() API instead. This is also available cross platform and you can remove the only non-windows restriction. >>>> >>>> - To avoid the annoying and unstable Thread.sleep(5000) let the started program print that it is ready and wait for that string in the output. This also avoids the need for -XX:+PauseAtStartup. >>> I just copied the code from the other attach test in the same directory test/serviceability/attach/AttachWithStalePidFile.java, but I can update my test if you want to. >> Yes, please. > > Here's the version with the two suggestions above: > http://cr.openjdk.java.net/~stefank/8054823/webrev.02.delta > http://cr.openjdk.java.net/~stefank/8054823/webrev.02 Thanks you! Looks good. I think you can remove -XX:+UnlockDiagnosticVMOptions. >> >>>> - To quit the started program use Process.destroyForcibly() in addition to having the process end by itself after a long timeout. >>> The target process is destroyed, so the test "only" takes ~18 seconds with a product build, of which 3 x 5 seconds are the sleep you mention above. >> It should be possible to run it in < 1 sec :-) > > Almost: "elapsed time (seconds): 1.231" =) Yeah! > > thanks, > StefanK > >> >> /Staffan >> >>> thanks, >>> StefanK >>>> Thanks, >>>> /Staffan >>>> >>>> On 11 aug 2014, at 19:46, Stefan Karlsson wrote: >>>> >>>>> On 2014-08-11 18:35, Vladimir Kozlov wrote: >>>>>> Stefan, >>>>>> >>>>>> Seems fine to me, >>>>> Thanks for reviewing! >>>>> >>>>>> except new tests don't have correct @bug. >>>>>> >>>>>> 27 * The test helsp verifying that size_t flags can be set/read. >>>>>> ^ typo >>>>>> >>>>>> SizeTTest.java - remove @author >>>>> Too much copy-n-paste. I've updated the patch and did some additional cleanups to the jtreg annotations: >>>>> http://cr.openjdk.java.net/~stefank/8054823/webrev.01.delta/ >>>>> http://cr.openjdk.java.net/~stefank/8054823/webrev.01/ >>>>> >>>>> thanks, >>>>> StefanK >>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 8/11/14 6:48 AM, Stefan Karlsson wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I propose that we add 'size_t' as a valid VM flag type. This will help with type safety, since we won't have to cast >>>>>>> back and forth between the two types. >>>>>>> >>>>>>> This patch adds the framework, but only changes one of the flags. I choose to change one of our experimental flags, so >>>>>>> that I could write tests for this change. >>>>>>> >>>>>>> Please, review this patch: >>>>>>> http://cr.openjdk.java.net/~stefank/8054823/webrev.00/ >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054823 >>>>>>> >>>>>>> thanks, >>>>>>> StefanK From stefan.karlsson at oracle.com Tue Aug 12 13:14:30 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 12 Aug 2014 15:14:30 +0200 Subject: RFR: 8054823: Add size_t as a valid VM flag type In-Reply-To: References: <53E8C9A2.70607@oracle.com> <53E8F0D9.6020002@oracle.com> <53E9017D.6040902@oracle.com> <6B026DBD-25F2-4B5D-B534-99C356695E98@oracle.com> <53EA0BA9.5070707@oracle.com> <7F4059F8-008F-4934-8FC1-589532E66281@oracle.com> <53EA1185.3030803@oracle.com> Message-ID: <53EA1336.4060902@oracle.com> On 12/08/14 15:11, Staffan Larsen wrote: > > On 12 aug 2014, at 15:07, Stefan Karlsson > wrote: > >> On 12/08/14 14:58, Staffan Larsen wrote: >>> On 12 aug 2014, at 14:42, Stefan Karlsson >>> > wrote: >>> >>>> On 12/08/14 14:25, Staffan Larsen wrote: >>>>> About the new AttachSetGetFlag test: >>>>> >>>>> - To get the pid of the newly launched process use the new >>>>> Process.getPid() API instead. This is also available cross >>>>> platform and you can remove the only non-windows restriction. >>>>> >>>>> - To avoid the annoying and unstable Thread.sleep(5000) let the >>>>> started program print that it is ready and wait for that string in >>>>> the output. This also avoids the need for -XX:+PauseAtStartup. >>>> I just copied the code from the other attach test in the same >>>> directory test/serviceability/attach/AttachWithStalePidFile.java, >>>> but I can update my test if you want to. >>> Yes, please. >> >> Here's the version with the two suggestions above: >> http://cr.openjdk.java.net/~stefank/8054823/webrev.02.delta >> >> http://cr.openjdk.java.net/~stefank/8054823/webrev.02 >> > > Thanks you! Looks good. I think you can remove > -XX:+UnlockDiagnosticVMOptions. Thanks. I'll remove it. StefanK > >>> >>>>> - To quit the started program use Process.destroyForcibly() in >>>>> addition to having the process end by itself after a long timeout. >>>> The target process is destroyed, so the test "only" takes ~18 >>>> seconds with a product build, of which 3 x 5 seconds are the sleep >>>> you mention above. >>> It should be possible to run it in < 1 sec :-) >> >> Almost: "elapsed time (seconds): 1.231" =) > > Yeah! > >> >> thanks, >> StefanK >> >>> >>> /Staffan >>> >>>> thanks, >>>> StefanK >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> On 11 aug 2014, at 19:46, Stefan Karlsson >>>>> > >>>>> wrote: >>>>> >>>>>> On 2014-08-11 18:35, Vladimir Kozlov wrote: >>>>>>> Stefan, >>>>>>> >>>>>>> Seems fine to me, >>>>>> Thanks for reviewing! >>>>>> >>>>>>> except new tests don't have correct @bug. >>>>>>> >>>>>>> 27 * The test helsp verifying that size_t flags can be set/read. >>>>>>> ^ typo >>>>>>> >>>>>>> SizeTTest.java - remove @author >>>>>> Too much copy-n-paste. I've updated the patch and did some >>>>>> additional cleanups to the jtreg annotations: >>>>>> http://cr.openjdk.java.net/~stefank/8054823/webrev.01.delta/ >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8054823/webrev.01/ >>>>>> >>>>>> thanks, >>>>>> StefanK >>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 8/11/14 6:48 AM, Stefan Karlsson wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I propose that we add 'size_t' as a valid VM flag type. This >>>>>>>> will help with type safety, since we won't have to cast >>>>>>>> back and forth between the two types. >>>>>>>> >>>>>>>> This patch adds the framework, but only changes one of the >>>>>>>> flags. I choose to change one of our experimental flags, so >>>>>>>> that I could write tests for this change. >>>>>>>> >>>>>>>> Please, review this patch: >>>>>>>> http://cr.openjdk.java.net/~stefank/8054823/webrev.00/ >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054823 >>>>>>>> >>>>>>>> thanks, >>>>>>>> StefanK > From vladimir.kozlov at oracle.com Tue Aug 12 13:20:41 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Aug 2014 06:20:41 -0700 Subject: [8u40] Backport 8031994: java/lang/Character/CheckProp test times out In-Reply-To: <20140812113930.GP7829@rbackman> References: <20140812113930.GP7829@rbackman> Message-ID: <53EA14A9.4040006@oracle.com> Good to backport. Thanks, Vladimir On 8/12/14 4:39 AM, Rickard B?ckman wrote: > Hi, > > requesting reviews for this backport. > > Webrev: http://cr.openjdk.java.net/~rbackman/8031994/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8031994 > Commit: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/82a396fba1e6 > > Thanks > /R > From vladimir.kozlov at oracle.com Tue Aug 12 13:23:08 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Aug 2014 06:23:08 -0700 Subject: [8u40] Backport 8030976: Untaken paths should be more vigorously pruned at highest optimization level In-Reply-To: <20140812121115.GQ7829@rbackman> References: <20140812121115.GQ7829@rbackman> Message-ID: <53EA153C.2020502@oracle.com> Looks good. Thanks, Vladimir On 8/12/14 5:11 AM, Rickard B?ckman wrote: > Hi, > > requesting reviews for this backport. > > Webrev: http://cr.openjdk.java.net/~rbackman/8030976.8u40/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8030976 > Commit: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/6ad207fd3e26 > > Thanks > /R > From vladimir.kozlov at oracle.com Tue Aug 12 13:25:51 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Aug 2014 06:25:51 -0700 Subject: [8u40] Backport 8046289: compiler/6340864/TestLongVect.java timeout with In-Reply-To: <20140812121519.GR7829@rbackman> References: <20140812121519.GR7829@rbackman> Message-ID: <53EA15DF.3090400@oracle.com> Good. Thanks, Vladimir On 8/12/14 5:15 AM, Rickard B?ckman wrote: > Hi, > > requesting reviews for this backport. > > Webrev: http://cr.openjdk.java.net/~rbackman/8046289.3/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8046289 > Commit: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/08250e173426 > > Thanks > /R > From rbonifacio123 at gmail.com Tue Aug 12 13:43:09 2014 From: rbonifacio123 at gmail.com (Rodrigo Bonifacio) Date: Tue, 12 Aug 2014 10:43:09 -0300 Subject: Code convention In-Reply-To: <53AF169E.8030907@oracle.com> References: <9CDFA0E7-3A18-4967-B747-51539ED1B577@gmail.com> <53AF169E.8030907@oracle.com> Message-ID: Dear all, I am conducting a survey about the use of exception handling constructs in C++. I would really appreciate if you could contribute to this research by answering a few questions on the subject. The survey is available on-line: https://pt.surveymonkey.com/s/exceptionHandling All the best, Rodrigo. 2014-06-28 16:25 GMT-03:00 Stefan Karlsson : > Hi Rodrigo, > > > On 2014-06-28 15:52, Rodrigo Bonifacio wrote: >> >> Dear all, is there any code guideline that recommends developers to avoid >> the use of C++ exception handling mechanisms within the open jdk hotspot >> development? > > > See this page: > https://wiki.openjdk.java.net/display/HotSpot/StyleGuide > > StefanK > >> >> All the best, >> >> Rodrigo. > > From vladimir.kozlov at oracle.com Tue Aug 12 13:49:19 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Aug 2014 06:49:19 -0700 Subject: [9] RFR(S): 8054402: "klass->is_loader_alive(_is_alive)) failed: must be alive" for anonymous classes In-Reply-To: <53E9DC5E.2090604@oracle.com> References: <53E9DC5E.2090604@oracle.com> Message-ID: <53EA1B5F.2080502@oracle.com> Nice work, Tobias! Should you also modify Dictionary::do_unloading() since it is the only place where it is called and the result is not used anymore? I don't think you need IgnoreUnrecognizedVMOptions flag in the test. Thanks, Vladimir On 8/12/14 2:20 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch that fixes JDK-8054402. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8054402 > Webrev: http://cr.openjdk.java.net/~thartmann/8054402/webrev.00/ > > == Problem == > The test [1] rarely fails with the assert 'klass->is_loader_alive(_is_alive)) failed: must be alive' in > 'CheckClass::check_class' (nmethod.cpp) because a IC in a compiled method [2] references an unloaded anonymous Klass* > [3] (i.e., the Klass has an unloaded mirror class [4]). Usually, ICs are cleaned in 'nmethod::do_unloading' by > 'clean_ic_if_metadata_is_dead' if they reference stale metadata. In this case, the check for stale metadata is not > performed because 'unloading_occurred' is set to false and therefore no class unloading should have happened. > The error is in 'SystemDictionary::do_unloading'. First, 'ClassLoaderDataGraph::do_unloading ' is invoked to remove the > class loader data of unloaded classes. Next, 'Dictionary::do_unloading' is called to remove the system dictionary > entries of dead classes. 'unloading_occurred' is only set to true if dead class loaders were found _and_ entries were > removed from the system dictionary. The problem is that anonymous classes are not in the system dictionary. In the rare > case where only anonymous classes were unloaded, 'unloading_occurred' is set to false even if (anonymous) class > unloading occurred. > > == Solution == > The variable 'unloading_occurred' is always set to true if dead class loaders were found. > I was able to write a jtreg test that deterministically triggers the bug. > > == Testing == > - New jtreg test > - Failing test [1] > - JPRT > > Thanks, > Tobias > > > [1] java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java > [2] java.util.stream.Streams$RangeIntSpliterator::forEachRemaining > [3] java.util.stream.StreamSpliterators$IntWrappingSpliterator$$Lambda$170/25231275 > [4] java/util/stream/StreamSpliterators$IntWrappingSpliterator$$Lambda$170 From coleen.phillimore at oracle.com Tue Aug 12 14:11:28 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 12 Aug 2014 10:11:28 -0400 Subject: [9] RFR(S): 8054402: "klass->is_loader_alive(_is_alive)) failed: must be alive" for anonymous classes In-Reply-To: <53EA1B5F.2080502@oracle.com> References: <53E9DC5E.2090604@oracle.com> <53EA1B5F.2080502@oracle.com> Message-ID: <53EA2090.9030400@oracle.com> Hi, Yes, I was about to make both of these comments. Thank you for finding this bug! There is some dead code (if statement) in dictionary::do_unloading() when you remove this flag that you can remove also. Also, about the test. I thought AnonymousClass was something we were going to discontinue support for (or was it a different AnonymousClass)? Thanks! Coleen On 8/12/14, 9:49 AM, Vladimir Kozlov wrote: > Nice work, Tobias! > Should you also modify Dictionary::do_unloading() since it is the only > place where it is called and the result is not used anymore? > I don't think you need IgnoreUnrecognizedVMOptions flag in the test. > > Thanks, > Vladimir > > On 8/12/14 2:20 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch that fixes JDK-8054402. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8054402 >> Webrev: http://cr.openjdk.java.net/~thartmann/8054402/webrev.00/ >> >> == Problem == >> The test [1] rarely fails with the assert >> 'klass->is_loader_alive(_is_alive)) failed: must be alive' in >> 'CheckClass::check_class' (nmethod.cpp) because a IC in a compiled >> method [2] references an unloaded anonymous Klass* >> [3] (i.e., the Klass has an unloaded mirror class [4]). Usually, ICs >> are cleaned in 'nmethod::do_unloading' by >> 'clean_ic_if_metadata_is_dead' if they reference stale metadata. In >> this case, the check for stale metadata is not >> performed because 'unloading_occurred' is set to false and therefore >> no class unloading should have happened. >> The error is in 'SystemDictionary::do_unloading'. First, >> 'ClassLoaderDataGraph::do_unloading ' is invoked to remove the >> class loader data of unloaded classes. Next, >> 'Dictionary::do_unloading' is called to remove the system dictionary >> entries of dead classes. 'unloading_occurred' is only set to true if >> dead class loaders were found _and_ entries were >> removed from the system dictionary. The problem is that anonymous >> classes are not in the system dictionary. In the rare >> case where only anonymous classes were unloaded, 'unloading_occurred' >> is set to false even if (anonymous) class >> unloading occurred. >> >> == Solution == >> The variable 'unloading_occurred' is always set to true if dead class >> loaders were found. >> I was able to write a jtreg test that deterministically triggers the >> bug. >> >> == Testing == >> - New jtreg test >> - Failing test [1] >> - JPRT >> >> Thanks, >> Tobias >> >> >> [1] >> java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java >> [2] java.util.stream.Streams$RangeIntSpliterator::forEachRemaining >> [3] >> java.util.stream.StreamSpliterators$IntWrappingSpliterator$$Lambda$170/25231275 >> [4] >> java/util/stream/StreamSpliterators$IntWrappingSpliterator$$Lambda$170 From martin.doerr at sap.com Tue Aug 12 14:35:33 2014 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 12 Aug 2014 14:35:33 +0000 Subject: MemNode::unordered/release/acquire use in relation to volatile stores and loads In-Reply-To: References: <53DECAF3.4010203@oracle.com> <53DFF783.2020703@oracle.com> Message-ID: <7C9B87B351A4BA4AA9EC95BB418116566ACC2DB7@DEWDFEMB19C.global.corp.sap> Hi all, exactly. This should be changed as Volker has written. No clue why this was missed in open jdk. Please note that the 2nd piece of code should be: (LibraryCallKit::load_field_from_object) if (support_IRIW_for_not_multiple_copy_atomic_cpu && is_vol) { insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier } // Build the load. MemNode::MemOrd mo = is_vol ? MemNode::acquire : MemNode::unordered; Node* loadedField = make_load(NULL, adr, type, bt, adr_type, mo, is_vol); Best regards, Martin -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Dienstag, 5. August 2014 18:11 To: Vladimir Kozlov; David Holmes Cc: HotSpot Open Source Developers; Doerr, Martin Subject: Re: MemNode::unordered/release/acquire use in relation to volatile stores and loads On Mon, Aug 4, 2014 at 11:13 PM, Vladimir Kozlov wrote: > I would say that you are correct (MemNode::acquire is needed for volatile > load). > Lets hear Goetz answer. > Hi David, Vladimir, unfortunately, Goetz is on a sabbatical leave until mid September... > Thanks, > Vladimir > > > On 8/3/14 4:51 PM, David Holmes wrote: >> >> In ./share/vm/opto/library_call.cpp >> >> Why is it that for volatile stores we have special checks for which >> MemNode to use: >> >> MemNode::MemOrd mo = is_volatile ? MemNode::release : >> MemNode::unordered; >> if (type != T_OBJECT ) { >> (void) store_to_memory(control(), adr, val, type, adr_type, mo, >> is_volatile); >> } else { >> >> but for loads it is always unordered eg: >> >> Node* p = make_load(control(), adr, value_type, type, adr_type, >> MemNode::unordered, is_volatile); >> That seems indeed strange. Especially because in our internal SAP JVM version we have: Node* p = make_load(control(), adr, value_type, type, adr_type, is_volatile ? MemNode::acquire : MemNode::unordered, is_volatile); I've cc-ed Martin who did this change in our sources (unfortunately there's still a little diff between them and the OpenJDK :( He will be back next week and maybe he has some more insights? >> ?? I would have expected MemNode::acquire as in opto/parse3.cpp >> >> // Build the load. >> // >> MemNode::MemOrd mo = is_vol ? MemNode::acquire : MemNode::unordered; >> bool needs_atomic_access = is_vol || AlwaysAtomicAccesses; >> Node* ld = make_load(NULL, adr, type, bt, adr_type, mo, >> needs_atomic_access); >> And there's also another instance of this pattern in the method LibraryCallKit::load_field_from_object() in library_call.cpp which should be probably fixed as well: // Build the load. Node* loadedField = make_load(NULL, adr, type, bt, adr_type, MemNode::unordered, is_vol); Regards, Volker >> >> >> Thanks, >> David >> > From vladimir.kozlov at oracle.com Tue Aug 12 14:45:26 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Aug 2014 07:45:26 -0700 Subject: MemNode::unordered/release/acquire use in relation to volatile stores and loads In-Reply-To: <7C9B87B351A4BA4AA9EC95BB418116566ACC2DB7@DEWDFEMB19C.global.corp.sap> References: <53DECAF3.4010203@oracle.com> <53DFF783.2020703@oracle.com> <7C9B87B351A4BA4AA9EC95BB418116566ACC2DB7@DEWDFEMB19C.global.corp.sap> Message-ID: <53EA2886.6050400@oracle.com> Thank you, Martin I will file bug then and fix it. Thanks, Vladimir On 8/12/14 7:35 AM, Doerr, Martin wrote: > Hi all, > > exactly. This should be changed as Volker has written. > No clue why this was missed in open jdk. > > Please note that the 2nd piece of code should be: > (LibraryCallKit::load_field_from_object) > > if (support_IRIW_for_not_multiple_copy_atomic_cpu && is_vol) { > insert_mem_bar(Op_MemBarVolatile); // StoreLoad barrier > } > // Build the load. > MemNode::MemOrd mo = is_vol ? MemNode::acquire : MemNode::unordered; > Node* loadedField = make_load(NULL, adr, type, bt, adr_type, mo, is_vol); > > Best regards, > Martin > > > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Dienstag, 5. August 2014 18:11 > To: Vladimir Kozlov; David Holmes > Cc: HotSpot Open Source Developers; Doerr, Martin > Subject: Re: MemNode::unordered/release/acquire use in relation to volatile stores and loads > > On Mon, Aug 4, 2014 at 11:13 PM, Vladimir Kozlov > wrote: >> I would say that you are correct (MemNode::acquire is needed for volatile >> load). >> Lets hear Goetz answer. >> > > Hi David, Vladimir, > > unfortunately, Goetz is on a sabbatical leave until mid September... > >> Thanks, >> Vladimir >> >> >> On 8/3/14 4:51 PM, David Holmes wrote: >>> >>> In ./share/vm/opto/library_call.cpp >>> >>> Why is it that for volatile stores we have special checks for which >>> MemNode to use: >>> >>> MemNode::MemOrd mo = is_volatile ? MemNode::release : >>> MemNode::unordered; >>> if (type != T_OBJECT ) { >>> (void) store_to_memory(control(), adr, val, type, adr_type, mo, >>> is_volatile); >>> } else { >>> >>> but for loads it is always unordered eg: >>> >>> Node* p = make_load(control(), adr, value_type, type, adr_type, >>> MemNode::unordered, is_volatile); >>> > > That seems indeed strange. Especially because in our internal SAP JVM > version we have: > > Node* p = make_load(control(), adr, value_type, type, adr_type, > is_volatile ? MemNode::acquire : MemNode::unordered, is_volatile); > > I've cc-ed Martin who did this change in our sources (unfortunately > there's still a little diff between them and the OpenJDK :( > He will be back next week and maybe he has some more insights? > >>> ?? I would have expected MemNode::acquire as in opto/parse3.cpp >>> >>> // Build the load. >>> // >>> MemNode::MemOrd mo = is_vol ? MemNode::acquire : MemNode::unordered; >>> bool needs_atomic_access = is_vol || AlwaysAtomicAccesses; >>> Node* ld = make_load(NULL, adr, type, bt, adr_type, mo, >>> needs_atomic_access); >>> > > And there's also another instance of this pattern in the method > LibraryCallKit::load_field_from_object() in library_call.cpp which > should be probably fixed as well: > > // Build the load. > Node* loadedField = make_load(NULL, adr, type, bt, adr_type, > MemNode::unordered, is_vol); > > Regards, > Volker > >>> >>> >>> Thanks, >>> David >>> >> From vladimir.kozlov at oracle.com Tue Aug 12 15:18:31 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Aug 2014 08:18:31 -0700 Subject: [8u40] Backport RFR (L) 8035605 and 8035968: C2 support for SHA on SPARC In-Reply-To: <1A4EEB0E-8DE2-4E40-B535-317322887FE2@oracle.com> References: <53E92F57.6030907@oracle.com> <1A4EEB0E-8DE2-4E40-B535-317322887FE2@oracle.com> Message-ID: <53EA3047.4090701@oracle.com> Thank you, Roland Vladimir On 8/12/14 12:59 AM, Roland Westrelin wrote: > Ok. > > Roland. > > On Aug 11, 2014, at 11:02 PM, Vladimir Kozlov wrote: > >> 8u40 backport request. Changes were pushed two months ago into jdk9, no problems were found since then. >> >> The only few modifications I have to do is due to 8034812 changes which removed Compile* argument from Node::new() in jdk9. And 8026796 which removed 'Parse* parent_parser' argument and is not backported into 8u yet. >> >> 8035968: Leverage CPU Instructions to Improve SHA Performance on SPARC >> https://bugs.openjdk.java.net/browse/JDK-8035968 >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/edf93f2ccf99 >> >> 8035605: Expand functionality of PredictedIntrinsicGenerator >> https://bugs.openjdk.java.net/browse/JDK-8035605 >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/9be8f500449d >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Tue Aug 12 16:44:58 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Aug 2014 09:44:58 -0700 Subject: [8u40] backport RFR (M) 8052081: Optimize generated by C2 code for Intel's Atom processor Message-ID: <53EA448A.6040909@oracle.com> 8u40 backport request. Changes were pushed week ago into jdk9, no problems were found since then. Changes are applied to 8u without conflicts. http://cr.openjdk.java.net/~kvn/8052081/webrev/ https://bugs.openjdk.java.net/browse/JDK-8052081 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/76913ad3cd41 Thanks, Vladimir From jesper.wilhelmsson at oracle.com Tue Aug 12 17:27:55 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 12 Aug 2014 19:27:55 +0200 Subject: [8u40] backport RFR (M) 8052081: Optimize generated by C2 code for Intel's Atom processor In-Reply-To: <53EA448A.6040909@oracle.com> References: <53EA448A.6040909@oracle.com> Message-ID: <53EA4E9B.6080005@oracle.com> Hi Vladimir, Since these are hotspot changes only I assume you will push to jdk8u/hs-dev. If the patch applies cleanly you don't need the backport request. You are free to backport at will. Alejandro makes bulk requests for all changes in hs-dev when promoting to jdk8u. /Jesper Vladimir Kozlov skrev 12/8/14 18:44: > 8u40 backport request. Changes were pushed week ago into jdk9, no problems were > found since then. Changes are applied to 8u without conflicts. > > http://cr.openjdk.java.net/~kvn/8052081/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8052081 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/76913ad3cd41 > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Tue Aug 12 18:00:59 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Aug 2014 11:00:59 -0700 Subject: [8u40] backport RFR (M) 8052081: Optimize generated by C2 code for Intel's Atom processor In-Reply-To: <53EA4E9B.6080005@oracle.com> References: <53EA448A.6040909@oracle.com> <53EA4E9B.6080005@oracle.com> Message-ID: <53EA565B.4080100@oracle.com> On 8/12/14 10:27 AM, Jesper Wilhelmsson wrote: > Hi Vladimir, > > Since these are hotspot changes only I assume you will push to > jdk8u/hs-dev. If the patch applies cleanly you don't need the backport > request. You are free to backport at will. Hi Jesper, In Compiler group we require to send such mail to hotspot-dev and get approval from our reviewers even if changes are applied cleanly. It is to keep records that all our backports were approved by our group. Thanks, Vladimir > > Alejandro makes bulk requests for all changes in hs-dev when promoting > to jdk8u. > /Jesper > > > Vladimir Kozlov skrev 12/8/14 18:44: >> 8u40 backport request. Changes were pushed week ago into jdk9, no >> problems were >> found since then. Changes are applied to 8u without conflicts. >> >> http://cr.openjdk.java.net/~kvn/8052081/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8052081 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/76913ad3cd41 >> >> Thanks, >> Vladimir From roland.westrelin at oracle.com Tue Aug 12 18:28:19 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 12 Aug 2014 20:28:19 +0200 Subject: [8u40] backport RFR (M) 8052081: Optimize generated by C2 code for Intel's Atom processor In-Reply-To: <53EA448A.6040909@oracle.com> References: <53EA448A.6040909@oracle.com> Message-ID: <32644C19-8F6D-4BDE-812F-9C812BA5D2D8@oracle.com> Ok. Roland. On Aug 12, 2014, at 6:44 PM, Vladimir Kozlov wrote: > 8u40 backport request. Changes were pushed week ago into jdk9, no problems were found since then. Changes are applied to 8u without conflicts. > > http://cr.openjdk.java.net/~kvn/8052081/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8052081 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/76913ad3cd41 > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Tue Aug 12 18:48:51 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Aug 2014 11:48:51 -0700 Subject: [8u40] backport RFR (M) 8052081: Optimize generated by C2 code for Intel's Atom processor In-Reply-To: <32644C19-8F6D-4BDE-812F-9C812BA5D2D8@oracle.com> References: <53EA448A.6040909@oracle.com> <32644C19-8F6D-4BDE-812F-9C812BA5D2D8@oracle.com> Message-ID: <53EA6193.8090102@oracle.com> Thank you, Roland! Vladimir On 8/12/14 11:28 AM, Roland Westrelin wrote: > Ok. > > Roland. > > > On Aug 12, 2014, at 6:44 PM, Vladimir Kozlov wrote: > >> 8u40 backport request. Changes were pushed week ago into jdk9, no problems were found since then. Changes are applied to 8u without conflicts. >> >> http://cr.openjdk.java.net/~kvn/8052081/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8052081 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/76913ad3cd41 >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Tue Aug 12 21:39:48 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Aug 2014 14:39:48 -0700 Subject: [8u40] RFA(S): 8039498: Add iterators to GrowableArray In-Reply-To: <53EA878E.8040508@oracle.com> References: <53EA878E.8040508@oracle.com> Message-ID: <53EA89A4.3080906@oracle.com> Good to backport. Thanks, Vladimir On 8/12/14 2:30 PM, Morris Meyer wrote: > Folks, > > Could I get approval to backport 8039498 into 8u40? This change set is > necessary for the backport of 8040920: Uninitialised memory in > hotspot/src/share/vm/code/dependencies.cpp > > The original patch applied cleanly. > > Thanks. > > --morris > > JDK9 - http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/758ec32bde1b > JBS - https://bugs.openjdk.java.net/browse/JDK-8039498 > From roland.westrelin at oracle.com Wed Aug 13 09:17:00 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 13 Aug 2014 11:17:00 +0200 Subject: [8u] backport of 8026796: Make replace_in_map() on parent maps generic Message-ID: <25B7AB5B-411D-480E-A1DA-FE04A45C659D@oracle.com> 8u backport request. The change was pushed to jdk9 in June. The change doesn?t apply cleanly to 8u. https://bugs.openjdk.java.net/browse/JDK-8026796 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e38bb04f030d Webrev with the change merged into 8u: http://cr.openjdk.java.net/~roland/8026796/webrev.03/ Roland. From tobias.hartmann at oracle.com Wed Aug 13 09:18:49 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 13 Aug 2014 11:18:49 +0200 Subject: [9] RFR(S): 8054402: "klass->is_loader_alive(_is_alive)) failed: must be alive" for anonymous classes In-Reply-To: <53EA2090.9030400@oracle.com> References: <53E9DC5E.2090604@oracle.com> <53EA1B5F.2080502@oracle.com> <53EA2090.9030400@oracle.com> Message-ID: <53EB2D79.4020400@oracle.com> Vladimir, Coleen, thanks for the review. Please find comments inline. On 12.08.2014 16:11, Coleen Phillimore wrote: > There is some dead code (if statement) in dictionary::do_unloading() > when you remove this flag that you can remove also. Thanks for pointing that out. As you suggested, I also moved the index into the loop statement. > Also, about the test. I thought AnonymousClass was something we were > going to discontinue support for (or was it a different AnonymousClass)? I'm now directly using the corresponding method of the Unsafe API instead of the AnonymousClassLoader. > On 8/12/14, 9:49 AM, Vladimir Kozlov wrote: >> Should you also modify Dictionary::do_unloading() since it is the >> only place where it is called and the result is not used anymore? Yes, I missed that. Done. >> I don't think you need IgnoreUnrecognizedVMOptions flag in the test. I thought we need it for the Whitebox API but that's not the case. I removed it. New webrev: http://cr.openjdk.java.net/~thartmann/8054402/webrev.01/ Thanks, Tobias >> >> Thanks, >> Vladimir >> >> On 8/12/14 2:20 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch that fixes JDK-8054402. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8054402 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8054402/webrev.00/ >>> >>> == Problem == >>> The test [1] rarely fails with the assert >>> 'klass->is_loader_alive(_is_alive)) failed: must be alive' in >>> 'CheckClass::check_class' (nmethod.cpp) because a IC in a compiled >>> method [2] references an unloaded anonymous Klass* >>> [3] (i.e., the Klass has an unloaded mirror class [4]). Usually, ICs >>> are cleaned in 'nmethod::do_unloading' by >>> 'clean_ic_if_metadata_is_dead' if they reference stale metadata. In >>> this case, the check for stale metadata is not >>> performed because 'unloading_occurred' is set to false and therefore >>> no class unloading should have happened. >>> The error is in 'SystemDictionary::do_unloading'. First, >>> 'ClassLoaderDataGraph::do_unloading ' is invoked to remove the >>> class loader data of unloaded classes. Next, >>> 'Dictionary::do_unloading' is called to remove the system dictionary >>> entries of dead classes. 'unloading_occurred' is only set to true if >>> dead class loaders were found _and_ entries were >>> removed from the system dictionary. The problem is that anonymous >>> classes are not in the system dictionary. In the rare >>> case where only anonymous classes were unloaded, >>> 'unloading_occurred' is set to false even if (anonymous) class >>> unloading occurred. >>> >>> == Solution == >>> The variable 'unloading_occurred' is always set to true if dead >>> class loaders were found. >>> I was able to write a jtreg test that deterministically triggers the >>> bug. >>> >>> == Testing == >>> - New jtreg test >>> - Failing test [1] >>> - JPRT >>> >>> Thanks, >>> Tobias >>> >>> >>> [1] >>> java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java >>> [2] java.util.stream.Streams$RangeIntSpliterator::forEachRemaining >>> [3] >>> java.util.stream.StreamSpliterators$IntWrappingSpliterator$$Lambda$170/25231275 >>> [4] >>> java/util/stream/StreamSpliterators$IntWrappingSpliterator$$Lambda$170 > From sgehwolf at redhat.com Wed Aug 13 12:18:00 2014 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 13 Aug 2014 14:18:00 +0200 Subject: [9] RFR: JI-9039953 zero variant build is broken. In-Reply-To: <53DFC762.2070100@oracle.com> References: <1407167406.3128.53.camel@localhost.localdomain> <53DFC762.2070100@oracle.com> Message-ID: <1407932280.3171.30.camel@localhost.localdomain> Hi, On Mon, 2014-08-04 at 13:48 -0400, Coleen Phillimore wrote: > Hi, > > Did you try to build fastdebug? I found 2 more compilation errors when > I did that. > > http://cr.openjdk.java.net/~coleenp/8003426/src/cpu/zero/vm/cppInterpreter_zero.cpp.udiff.html > http://cr.openjdk.java.net/~coleenp/8003426/src/share/vm/interpreter/bytecodeInterpreter.cpp.udiff.html > > Although the last one could be due to the version of gcc I was using > (not sure). > > Coleen > > On 8/4/14, 11:50 AM, Severin Gehwolf wrote: > > Hi, > > > > Building a zero variant of hotspot fails for the latest hs-comp tree > > with ("release"-type build): > > src/cpu/zero/vm/frame_zero.inline.hpp:59:11: error: ?CodeCache? has not > > been declared > > > > It appears to have been caused by a change of header files (perhaps > > [1]?). A file which used to be included implicitly does not seem to be > > included any longer. An explicit include fixes the problem. > > > > [2] shows the build failure. > > > > I would need a proper JDK bug and a sponsor for this change. An initial > > bug has been submitted as JI-9039953 via the web interface. > > > > Webrev is here: > > https://jerboaa.fedorapeople.org/bugs/openjdk/JI-9039953/webrev.01/ I've updated the webrev which now also includes Coleen's fixes. https://jerboaa.fedorapeople.org/bugs/openjdk/JI-9039953/webrev.02/ Testing done: Successfully built zero variants[*]: release, slowdebug, fastdebug Successfully built a regular server JVM release build. Cheers, Severin [*] I've used the attached patches to work-around the generic fortify-source build problem. > > Thanks, > > Severin > > > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/22b98ab2a69f > > [2] > > http://builder.classpath.org/jenkins/job/OpenJDK9_hscomp_Zero/47/console > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: common.patch Type: text/x-patch Size: 1473 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hotspot.patch Type: text/x-patch Size: 2229 bytes Desc: not available URL: From vladimir.kozlov at oracle.com Wed Aug 13 16:11:40 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Aug 2014 09:11:40 -0700 Subject: [8u] backport of 8026796: Make replace_in_map() on parent maps generic In-Reply-To: <25B7AB5B-411D-480E-A1DA-FE04A45C659D@oracle.com> References: <25B7AB5B-411D-480E-A1DA-FE04A45C659D@oracle.com> Message-ID: <53EB8E3C.6030409@oracle.com> I don't see new replacenode.* files. Vladimir On 8/13/14 2:17 AM, Roland Westrelin wrote: > 8u backport request. The change was pushed to jdk9 in June. > > The change doesn?t apply cleanly to 8u. > https://bugs.openjdk.java.net/browse/JDK-8026796 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e38bb04f030d > > Webrev with the change merged into 8u: > http://cr.openjdk.java.net/~roland/8026796/webrev.03/ > > Roland. > From vladimir.kozlov at oracle.com Wed Aug 13 16:14:20 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Aug 2014 09:14:20 -0700 Subject: [9] RFR(S): 8054402: "klass->is_loader_alive(_is_alive)) failed: must be alive" for anonymous classes In-Reply-To: <53EB2D79.4020400@oracle.com> References: <53E9DC5E.2090604@oracle.com> <53EA1B5F.2080502@oracle.com> <53EA2090.9030400@oracle.com> <53EB2D79.4020400@oracle.com> Message-ID: <53EB8EDC.20605@oracle.com> Looks fine to me. Thanks, Vladimir On 8/13/14 2:18 AM, Tobias Hartmann wrote: > Vladimir, Coleen, thanks for the review. > > Please find comments inline. > > On 12.08.2014 16:11, Coleen Phillimore wrote: >> There is some dead code (if statement) in dictionary::do_unloading() when you remove this flag that you can remove also. > > Thanks for pointing that out. As you suggested, I also moved the index into the loop statement. > >> Also, about the test. I thought AnonymousClass was something we were going to discontinue support for (or was it a >> different AnonymousClass)? > > I'm now directly using the corresponding method of the Unsafe API instead of the AnonymousClassLoader. > >> On 8/12/14, 9:49 AM, Vladimir Kozlov wrote: >>> Should you also modify Dictionary::do_unloading() since it is the only place where it is called and the result is not >>> used anymore? > > Yes, I missed that. Done. > >>> I don't think you need IgnoreUnrecognizedVMOptions flag in the test. > > I thought we need it for the Whitebox API but that's not the case. I removed it. > > New webrev: http://cr.openjdk.java.net/~thartmann/8054402/webrev.01/ > > Thanks, > Tobias > >>> >>> Thanks, >>> Vladimir >>> >>> On 8/12/14 2:20 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch that fixes JDK-8054402. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8054402 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8054402/webrev.00/ >>>> >>>> == Problem == >>>> The test [1] rarely fails with the assert 'klass->is_loader_alive(_is_alive)) failed: must be alive' in >>>> 'CheckClass::check_class' (nmethod.cpp) because a IC in a compiled method [2] references an unloaded anonymous Klass* >>>> [3] (i.e., the Klass has an unloaded mirror class [4]). Usually, ICs are cleaned in 'nmethod::do_unloading' by >>>> 'clean_ic_if_metadata_is_dead' if they reference stale metadata. In this case, the check for stale metadata is not >>>> performed because 'unloading_occurred' is set to false and therefore no class unloading should have happened. >>>> The error is in 'SystemDictionary::do_unloading'. First, 'ClassLoaderDataGraph::do_unloading ' is invoked to remove the >>>> class loader data of unloaded classes. Next, 'Dictionary::do_unloading' is called to remove the system dictionary >>>> entries of dead classes. 'unloading_occurred' is only set to true if dead class loaders were found _and_ entries were >>>> removed from the system dictionary. The problem is that anonymous classes are not in the system dictionary. In the rare >>>> case where only anonymous classes were unloaded, 'unloading_occurred' is set to false even if (anonymous) class >>>> unloading occurred. >>>> >>>> == Solution == >>>> The variable 'unloading_occurred' is always set to true if dead class loaders were found. >>>> I was able to write a jtreg test that deterministically triggers the bug. >>>> >>>> == Testing == >>>> - New jtreg test >>>> - Failing test [1] >>>> - JPRT >>>> >>>> Thanks, >>>> Tobias >>>> >>>> >>>> [1] java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java >>>> [2] java.util.stream.Streams$RangeIntSpliterator::forEachRemaining >>>> [3] java.util.stream.StreamSpliterators$IntWrappingSpliterator$$Lambda$170/25231275 >>>> [4] java/util/stream/StreamSpliterators$IntWrappingSpliterator$$Lambda$170 >> > From coleen.phillimore at oracle.com Wed Aug 13 16:22:43 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 13 Aug 2014 12:22:43 -0400 Subject: [9] RFR(S): 8054402: "klass->is_loader_alive(_is_alive)) failed: must be alive" for anonymous classes In-Reply-To: <53EB2D79.4020400@oracle.com> References: <53E9DC5E.2090604@oracle.com> <53EA1B5F.2080502@oracle.com> <53EA2090.9030400@oracle.com> <53EB2D79.4020400@oracle.com> Message-ID: <53EB90D3.4060702@oracle.com> This looks really good. Thank you! Coleen On 8/13/14, 5:18 AM, Tobias Hartmann wrote: > Vladimir, Coleen, thanks for the review. > > Please find comments inline. > > On 12.08.2014 16:11, Coleen Phillimore wrote: >> There is some dead code (if statement) in dictionary::do_unloading() >> when you remove this flag that you can remove also. > > Thanks for pointing that out. As you suggested, I also moved the index > into the loop statement. > >> Also, about the test. I thought AnonymousClass was something we were >> going to discontinue support for (or was it a different AnonymousClass)? > > I'm now directly using the corresponding method of the Unsafe API > instead of the AnonymousClassLoader. > >> On 8/12/14, 9:49 AM, Vladimir Kozlov wrote: >>> Should you also modify Dictionary::do_unloading() since it is the >>> only place where it is called and the result is not used anymore? > > Yes, I missed that. Done. > >>> I don't think you need IgnoreUnrecognizedVMOptions flag in the test. > > I thought we need it for the Whitebox API but that's not the case. I > removed it. > > New webrev: http://cr.openjdk.java.net/~thartmann/8054402/webrev.01/ > > Thanks, > Tobias > >>> >>> Thanks, >>> Vladimir >>> >>> On 8/12/14 2:20 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch that fixes JDK-8054402. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8054402 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8054402/webrev.00/ >>>> >>>> == Problem == >>>> The test [1] rarely fails with the assert >>>> 'klass->is_loader_alive(_is_alive)) failed: must be alive' in >>>> 'CheckClass::check_class' (nmethod.cpp) because a IC in a compiled >>>> method [2] references an unloaded anonymous Klass* >>>> [3] (i.e., the Klass has an unloaded mirror class [4]). Usually, >>>> ICs are cleaned in 'nmethod::do_unloading' by >>>> 'clean_ic_if_metadata_is_dead' if they reference stale metadata. In >>>> this case, the check for stale metadata is not >>>> performed because 'unloading_occurred' is set to false and >>>> therefore no class unloading should have happened. >>>> The error is in 'SystemDictionary::do_unloading'. First, >>>> 'ClassLoaderDataGraph::do_unloading ' is invoked to remove the >>>> class loader data of unloaded classes. Next, >>>> 'Dictionary::do_unloading' is called to remove the system dictionary >>>> entries of dead classes. 'unloading_occurred' is only set to true >>>> if dead class loaders were found _and_ entries were >>>> removed from the system dictionary. The problem is that anonymous >>>> classes are not in the system dictionary. In the rare >>>> case where only anonymous classes were unloaded, >>>> 'unloading_occurred' is set to false even if (anonymous) class >>>> unloading occurred. >>>> >>>> == Solution == >>>> The variable 'unloading_occurred' is always set to true if dead >>>> class loaders were found. >>>> I was able to write a jtreg test that deterministically triggers >>>> the bug. >>>> >>>> == Testing == >>>> - New jtreg test >>>> - Failing test [1] >>>> - JPRT >>>> >>>> Thanks, >>>> Tobias >>>> >>>> >>>> [1] >>>> java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java >>>> [2] java.util.stream.Streams$RangeIntSpliterator::forEachRemaining >>>> [3] >>>> java.util.stream.StreamSpliterators$IntWrappingSpliterator$$Lambda$170/25231275 >>>> [4] >>>> java/util/stream/StreamSpliterators$IntWrappingSpliterator$$Lambda$170 >> > From tobias.hartmann at oracle.com Thu Aug 14 06:59:07 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 14 Aug 2014 08:59:07 +0200 Subject: [9] RFR(S): 8054402: "klass->is_loader_alive(_is_alive)) failed: must be alive" for anonymous classes In-Reply-To: <53EB90D3.4060702@oracle.com> References: <53E9DC5E.2090604@oracle.com> <53EA1B5F.2080502@oracle.com> <53EA2090.9030400@oracle.com> <53EB2D79.4020400@oracle.com> <53EB90D3.4060702@oracle.com> Message-ID: <53EC5E3B.4000105@oracle.com> Vladimir, Coleen, thanks for the review! Best, Tobias On 13.08.2014 18:22, Coleen Phillimore wrote: > > This looks really good. > Thank you! > Coleen > > On 8/13/14, 5:18 AM, Tobias Hartmann wrote: >> Vladimir, Coleen, thanks for the review. >> >> Please find comments inline. >> >> On 12.08.2014 16:11, Coleen Phillimore wrote: >>> There is some dead code (if statement) in dictionary::do_unloading() >>> when you remove this flag that you can remove also. >> >> Thanks for pointing that out. As you suggested, I also moved the >> index into the loop statement. >> >>> Also, about the test. I thought AnonymousClass was something we >>> were going to discontinue support for (or was it a different >>> AnonymousClass)? >> >> I'm now directly using the corresponding method of the Unsafe API >> instead of the AnonymousClassLoader. >> >>> On 8/12/14, 9:49 AM, Vladimir Kozlov wrote: >>>> Should you also modify Dictionary::do_unloading() since it is the >>>> only place where it is called and the result is not used anymore? >> >> Yes, I missed that. Done. >> >>>> I don't think you need IgnoreUnrecognizedVMOptions flag in the test. >> >> I thought we need it for the Whitebox API but that's not the case. I >> removed it. >> >> New webrev: http://cr.openjdk.java.net/~thartmann/8054402/webrev.01/ >> >> Thanks, >> Tobias >> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 8/12/14 2:20 AM, Tobias Hartmann wrote: >>>>> Hi, >>>>> >>>>> please review the following patch that fixes JDK-8054402. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8054402 >>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8054402/webrev.00/ >>>>> >>>>> == Problem == >>>>> The test [1] rarely fails with the assert >>>>> 'klass->is_loader_alive(_is_alive)) failed: must be alive' in >>>>> 'CheckClass::check_class' (nmethod.cpp) because a IC in a compiled >>>>> method [2] references an unloaded anonymous Klass* >>>>> [3] (i.e., the Klass has an unloaded mirror class [4]). Usually, >>>>> ICs are cleaned in 'nmethod::do_unloading' by >>>>> 'clean_ic_if_metadata_is_dead' if they reference stale metadata. >>>>> In this case, the check for stale metadata is not >>>>> performed because 'unloading_occurred' is set to false and >>>>> therefore no class unloading should have happened. >>>>> The error is in 'SystemDictionary::do_unloading'. First, >>>>> 'ClassLoaderDataGraph::do_unloading ' is invoked to remove the >>>>> class loader data of unloaded classes. Next, >>>>> 'Dictionary::do_unloading' is called to remove the system dictionary >>>>> entries of dead classes. 'unloading_occurred' is only set to true >>>>> if dead class loaders were found _and_ entries were >>>>> removed from the system dictionary. The problem is that anonymous >>>>> classes are not in the system dictionary. In the rare >>>>> case where only anonymous classes were unloaded, >>>>> 'unloading_occurred' is set to false even if (anonymous) class >>>>> unloading occurred. >>>>> >>>>> == Solution == >>>>> The variable 'unloading_occurred' is always set to true if dead >>>>> class loaders were found. >>>>> I was able to write a jtreg test that deterministically triggers >>>>> the bug. >>>>> >>>>> == Testing == >>>>> - New jtreg test >>>>> - Failing test [1] >>>>> - JPRT >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>> >>>>> [1] >>>>> java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java >>>>> [2] java.util.stream.Streams$RangeIntSpliterator::forEachRemaining >>>>> [3] >>>>> java.util.stream.StreamSpliterators$IntWrappingSpliterator$$Lambda$170/25231275 >>>>> [4] >>>>> java/util/stream/StreamSpliterators$IntWrappingSpliterator$$Lambda$170 >>>>> >>> >> > From roland.westrelin at oracle.com Thu Aug 14 11:59:08 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 14 Aug 2014 13:59:08 +0200 Subject: [8u] backport of 8026796: Make replace_in_map() on parent maps generic In-Reply-To: <53EB8E3C.6030409@oracle.com> References: <25B7AB5B-411D-480E-A1DA-FE04A45C659D@oracle.com> <53EB8E3C.6030409@oracle.com> Message-ID: <7AB6BFCD-893B-42EF-B288-3754FF1BD694@oracle.com> > I don't see new replacenode.* files. Indeed. Thanks for spotting the missing files. New webrev: http://cr.openjdk.java.net/~roland/8026796/webrev.03/ Roland. > > Vladimir > > On 8/13/14 2:17 AM, Roland Westrelin wrote: >> 8u backport request. The change was pushed to jdk9 in June. >> >> The change doesn?t apply cleanly to 8u. >> https://bugs.openjdk.java.net/browse/JDK-8026796 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e38bb04f030d >> >> Webrev with the change merged into 8u: >> http://cr.openjdk.java.net/~roland/8026796/webrev.03/ >> >> Roland. >> From rkennke at redhat.com Thu Aug 14 14:32:05 2014 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 14 Aug 2014 16:32:05 +0200 Subject: Question about Unsafe.prefetch ... () ? Message-ID: <1408026725.5132.5.camel@localhost> Hello, I noticed that in Hotspot there are intrinsics defined for Unsafe.prefetchRead(), Unsafe.prefetchWrite(), Unsafe.prefetchReadStatic() and Unsafe.prefetchWriteStatic(), but none of them are defined in JDK's Unsafe.java nor is it called anywhere. Is this code used for anything? Why is it there? Thanks and best regards, Roman From christian.thalinger at oracle.com Thu Aug 14 14:46:12 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 14 Aug 2014 07:46:12 -0700 Subject: Question about Unsafe.prefetch ... () ? In-Reply-To: <1408026725.5132.5.camel@localhost> References: <1408026725.5132.5.camel@localhost> Message-ID: <164FBD61-384B-4EEB-B03E-ABFB7BF5E1FD@oracle.com> [#JDK-6807143] Unsafe.java changes corresponding to 6353211 - Java Bug System On Aug 14, 2014, at 7:32 AM, Roman Kennke wrote: > Hello, > > I noticed that in Hotspot there are intrinsics defined for > Unsafe.prefetchRead(), Unsafe.prefetchWrite(), > Unsafe.prefetchReadStatic() and Unsafe.prefetchWriteStatic(), but none > of them are defined in JDK's Unsafe.java nor is it called anywhere. Is > this code used for anything? Why is it there? > > Thanks and best regards, > Roman > > From christian.thalinger at oracle.com Thu Aug 14 14:48:00 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 14 Aug 2014 07:48:00 -0700 Subject: Question about Unsafe.prefetch ... () ? In-Reply-To: <164FBD61-384B-4EEB-B03E-ABFB7BF5E1FD@oracle.com> References: <1408026725.5132.5.camel@localhost> <164FBD61-384B-4EEB-B03E-ABFB7BF5E1FD@oracle.com> Message-ID: Sorry, the link didn?t come through: https://bugs.openjdk.java.net/browse/JDK-6807143 On Aug 14, 2014, at 7:46 AM, Christian Thalinger wrote: > [#JDK-6807143] Unsafe.java changes corresponding to 6353211 - Java Bug System > > On Aug 14, 2014, at 7:32 AM, Roman Kennke wrote: > >> Hello, >> >> I noticed that in Hotspot there are intrinsics defined for >> Unsafe.prefetchRead(), Unsafe.prefetchWrite(), >> Unsafe.prefetchReadStatic() and Unsafe.prefetchWriteStatic(), but none >> of them are defined in JDK's Unsafe.java nor is it called anywhere. Is >> this code used for anything? Why is it there? >> >> Thanks and best regards, >> Roman >> >> > From rkennke at redhat.com Thu Aug 14 14:52:10 2014 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 14 Aug 2014 16:52:10 +0200 Subject: Question about Unsafe.prefetch ... () ? In-Reply-To: <164FBD61-384B-4EEB-B03E-ABFB7BF5E1FD@oracle.com> References: <1408026725.5132.5.camel@localhost> <164FBD61-384B-4EEB-B03E-ABFB7BF5E1FD@oracle.com> Message-ID: <1408027930.5132.7.camel@localhost> Am Donnerstag, den 14.08.2014 um 07:46 -0700 schrieb Christian Thalinger: > [#JDK-6807143] Unsafe.java changes corresponding to 6353211 - Java Bug > System > Interesting! This bug is created in 2009 (if the year entry is correct). Does it make sense to either finish it off (for this it would be good to know what have been the plans...), or remove that code? Roman > On Aug 14, 2014, at 7:32 AM, Roman Kennke wrote: > > > Hello, > > > > I noticed that in Hotspot there are intrinsics defined for > > Unsafe.prefetchRead(), Unsafe.prefetchWrite(), > > Unsafe.prefetchReadStatic() and Unsafe.prefetchWriteStatic(), but > > none > > of them are defined in JDK's Unsafe.java nor is it called anywhere. > > Is > > this code used for anything? Why is it there? > > > > Thanks and best regards, > > Roman > > > > > > From rkennke at redhat.com Thu Aug 14 15:07:59 2014 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 14 Aug 2014 17:07:59 +0200 Subject: Question about Unsafe.prefetch ... () ? In-Reply-To: References: <1408026725.5132.5.camel@localhost> <164FBD61-384B-4EEB-B03E-ABFB7BF5E1FD@oracle.com> Message-ID: <1408028879.5132.8.camel@localhost> I just found that (some of it?) has been taken out in JDK9: http://cr.openjdk.java.net/~psandoz/jdk9/hotspot-unsafe-cleanup/webrev/src/share/vm/prims/unsafe.cpp.udiff.html Roman Am Donnerstag, den 14.08.2014 um 07:48 -0700 schrieb Christian Thalinger: > Sorry, the link didn?t come through: > > https://bugs.openjdk.java.net/browse/JDK-6807143 > > On Aug 14, 2014, at 7:46 AM, Christian Thalinger wrote: > > > [#JDK-6807143] Unsafe.java changes corresponding to 6353211 - Java Bug System > > > > On Aug 14, 2014, at 7:32 AM, Roman Kennke wrote: > > > >> Hello, > >> > >> I noticed that in Hotspot there are intrinsics defined for > >> Unsafe.prefetchRead(), Unsafe.prefetchWrite(), > >> Unsafe.prefetchReadStatic() and Unsafe.prefetchWriteStatic(), but none > >> of them are defined in JDK's Unsafe.java nor is it called anywhere. Is > >> this code used for anything? Why is it there? > >> > >> Thanks and best regards, > >> Roman > >> > >> > > > From vladimir.kozlov at oracle.com Thu Aug 14 15:35:21 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Aug 2014 08:35:21 -0700 Subject: [8u] backport of 8026796: Make replace_in_map() on parent maps generic In-Reply-To: <7AB6BFCD-893B-42EF-B288-3754FF1BD694@oracle.com> References: <25B7AB5B-411D-480E-A1DA-FE04A45C659D@oracle.com> <53EB8E3C.6030409@oracle.com> <7AB6BFCD-893B-42EF-B288-3754FF1BD694@oracle.com> Message-ID: <53ECD739.4090306@oracle.com> Looks good. Thanks, Vladimir On 8/14/14 4:59 AM, Roland Westrelin wrote: >> I don't see new replacenode.* files. > > Indeed. Thanks for spotting the missing files. New webrev: > > http://cr.openjdk.java.net/~roland/8026796/webrev.03/ > > Roland. > >> >> Vladimir >> >> On 8/13/14 2:17 AM, Roland Westrelin wrote: >>> 8u backport request. The change was pushed to jdk9 in June. >>> >>> The change doesn?t apply cleanly to 8u. >>> https://bugs.openjdk.java.net/browse/JDK-8026796 >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e38bb04f030d >>> >>> Webrev with the change merged into 8u: >>> http://cr.openjdk.java.net/~roland/8026796/webrev.03/ >>> >>> Roland. >>> > From christian.thalinger at oracle.com Thu Aug 14 15:43:54 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 14 Aug 2014 08:43:54 -0700 Subject: Question about Unsafe.prefetch ... () ? In-Reply-To: <1408027930.5132.7.camel@localhost> References: <1408026725.5132.5.camel@localhost> <164FBD61-384B-4EEB-B03E-ABFB7BF5E1FD@oracle.com> <1408027930.5132.7.camel@localhost> Message-ID: <3512726F-F729-4C3F-9DD6-C7A2C67689F7@oracle.com> Maybe Alan knows more about it? On Aug 14, 2014, at 7:52 AM, Roman Kennke wrote: > Am Donnerstag, den 14.08.2014 um 07:46 -0700 schrieb Christian > Thalinger: >> [#JDK-6807143] Unsafe.java changes corresponding to 6353211 - Java Bug >> System >> > > Interesting! This bug is created in 2009 (if the year entry is correct). > Does it make sense to either finish it off (for this it would be good to > know what have been the plans...), or remove that code? > > Roman > >> On Aug 14, 2014, at 7:32 AM, Roman Kennke wrote: >> >>> Hello, >>> >>> I noticed that in Hotspot there are intrinsics defined for >>> Unsafe.prefetchRead(), Unsafe.prefetchWrite(), >>> Unsafe.prefetchReadStatic() and Unsafe.prefetchWriteStatic(), but >>> none >>> of them are defined in JDK's Unsafe.java nor is it called anywhere. >>> Is >>> this code used for anything? Why is it there? >>> >>> Thanks and best regards, >>> Roman >>> >>> >> >> > > From christian.tornqvist at oracle.com Thu Aug 14 16:22:45 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 14 Aug 2014 12:22:45 -0400 Subject: RFR(S): 8032999 - [TESTBUG] JT-Reg Runtime tests to be run as part of JPRT submit job Message-ID: <049c01cfb7db$fb5ed250$f21c76f0$@oracle.com> Hi everyone, This change turns on the runtime jtreg tests in JPRT, except for a few tests that were excluded due to taking too long to run/had intermittent timeout issues. I also added @ignore tags to the tests with known issues to prevent them from running. Webrev can be found at: http://cr.openjdk.java.net/~ctornqvi/webrev/8032999/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8032999 Thanks, Christian From Alan.Bateman at oracle.com Thu Aug 14 16:46:39 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Aug 2014 17:46:39 +0100 Subject: Question about Unsafe.prefetch ... () ? In-Reply-To: References: <1408026725.5132.5.camel@localhost> <164FBD61-384B-4EEB-B03E-ABFB7BF5E1FD@oracle.com> Message-ID: <53ECE7EF.7030701@oracle.com> On 14/08/2014 15:48, Christian Thalinger wrote: > Sorry, the link didn?t come through: > > https://bugs.openjdk.java.net/browse/JDK-6807143 > At the time Paul Hohensee was experimenting with prefetching and put the support into HotSpot. As I recall, the intention was to add it to sun.misc.Unsafe when a beneficial use of using it directly in the JDK libraries was identified. -Alan. From daniel.daugherty at oracle.com Thu Aug 14 20:43:39 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Aug 2014 14:43:39 -0600 Subject: RFR(S): 8032999 - [TESTBUG] JT-Reg Runtime tests to be run as part of JPRT submit job In-Reply-To: <049c01cfb7db$fb5ed250$f21c76f0$@oracle.com> References: <049c01cfb7db$fb5ed250$f21c76f0$@oracle.com> Message-ID: <53ED1F7B.1040002@oracle.com> On 8/14/14 10:22 AM, Christian Tornqvist wrote: > Hi everyone, > > > > This change turns on the runtime jtreg tests in JPRT, except for a few tests > that were excluded due to taking too long to run/had intermittent timeout > issues. I also added @ignore tags to the tests with known issues to prevent > them from running. > > > > Webrev can be found at: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8032999/webrev.00/ make/jprt.properties No comments. test/TEST.groups So this syntax means run all runtime/ test except for the ones listed with the '-' prefix? 330 hotspot_runtime = \ 331 runtime/ \ 332 -runtime/6888954/vmerrors.sh \ test/runtime/7158988/FieldMonitor.java No comments. test/runtime/jsig/Test8017498.sh No comments. Thumbs up. Dan > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8032999 > > > > Thanks, > > Christian > From christian.tornqvist at oracle.com Thu Aug 14 21:17:32 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 14 Aug 2014 17:17:32 -0400 Subject: RFR(S): 8032999 - [TESTBUG] JT-Reg Runtime tests to be run as part of JPRT submit job In-Reply-To: <53ED1F7B.1040002@oracle.com> References: <049c01cfb7db$fb5ed250$f21c76f0$@oracle.com> <53ED1F7B.1040002@oracle.com> Message-ID: <051801cfb805$298bd190$7ca374b0$@oracle.com> > So this syntax means run all runtime/ test except for the > ones listed with the '-' prefix? Yes, that's what it does :) Thanks for the review! Thanks, Christian -----Original Message----- From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] Sent: Thursday, August 14, 2014 4:44 PM To: Christian Tornqvist Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8032999 - [TESTBUG] JT-Reg Runtime tests to be run as part of JPRT submit job On 8/14/14 10:22 AM, Christian Tornqvist wrote: > Hi everyone, > > > > This change turns on the runtime jtreg tests in JPRT, except for a few > tests that were excluded due to taking too long to run/had > intermittent timeout issues. I also added @ignore tags to the tests > with known issues to prevent them from running. > > > > Webrev can be found at: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8032999/webrev.00/ make/jprt.properties No comments. test/TEST.groups So this syntax means run all runtime/ test except for the ones listed with the '-' prefix? 330 hotspot_runtime = \ 331 runtime/ \ 332 -runtime/6888954/vmerrors.sh \ test/runtime/7158988/FieldMonitor.java No comments. test/runtime/jsig/Test8017498.sh No comments. Thumbs up. Dan > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8032999 > > > > Thanks, > > Christian > From zhengyu.gu at oracle.com Thu Aug 14 21:49:12 2014 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 14 Aug 2014 17:49:12 -0400 Subject: RFR(S): 8032999 - [TESTBUG] JT-Reg Runtime tests to be run as part of JPRT submit job In-Reply-To: <049c01cfb7db$fb5ed250$f21c76f0$@oracle.com> References: <049c01cfb7db$fb5ed250$f21c76f0$@oracle.com> Message-ID: <53ED2ED8.2050607@oracle.com> Look good to me. -Zhengyu On 8/14/2014 12:22 PM, Christian Tornqvist wrote: > Hi everyone, > > > > This change turns on the runtime jtreg tests in JPRT, except for a few tests > that were excluded due to taking too long to run/had intermittent timeout > issues. I also added @ignore tags to the tests with known issues to prevent > them from running. > > > > Webrev can be found at: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8032999/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8032999 > > > > Thanks, > > Christian > From christian.tornqvist at oracle.com Thu Aug 14 22:33:18 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 14 Aug 2014 18:33:18 -0400 Subject: RFR(S): 8032999 - [TESTBUG] JT-Reg Runtime tests to be run as part of JPRT submit job In-Reply-To: <049c01cfb7db$fb5ed250$f21c76f0$@oracle.com> References: <049c01cfb7db$fb5ed250$f21c76f0$@oracle.com> Message-ID: <053101cfb80f$bf82e300$3e88a900$@oracle.com> After some feedback from Coleen and discussions with Mikael Vidstedt I made some changes to keep OpenJDK builds working through JPRT. I discovered one test that didn't work correctly with the OpenJDK and added an @ignore tag to that test. Updated webrev can be found at: http://cr.openjdk.java.net/~ctornqvi/webrev/8032999/webrev.01/ Thanks, Christian -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Christian Tornqvist Sent: Thursday, August 14, 2014 12:23 PM To: hotspot-dev at openjdk.java.net Subject: RFR(S): 8032999 - [TESTBUG] JT-Reg Runtime tests to be run as part of JPRT submit job Hi everyone, This change turns on the runtime jtreg tests in JPRT, except for a few tests that were excluded due to taking too long to run/had intermittent timeout issues. I also added @ignore tags to the tests with known issues to prevent them from running. Webrev can be found at: http://cr.openjdk.java.net/~ctornqvi/webrev/8032999/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8032999 Thanks, Christian From daniel.daugherty at oracle.com Thu Aug 14 22:37:12 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Aug 2014 16:37:12 -0600 Subject: RFR(S): 8032999 - [TESTBUG] JT-Reg Runtime tests to be run as part of JPRT submit job In-Reply-To: <053101cfb80f$bf82e300$3e88a900$@oracle.com> References: <049c01cfb7db$fb5ed250$f21c76f0$@oracle.com> <053101cfb80f$bf82e300$3e88a900$@oracle.com> Message-ID: <53ED3A18.6040208@oracle.com> test/runtime/CompressedOops/CompressedClassPointers.java No comments. Still thumbs up. Dan On 8/14/14 4:33 PM, Christian Tornqvist wrote: > After some feedback from Coleen and discussions with Mikael Vidstedt I made > some changes to keep OpenJDK builds working through JPRT. I discovered one > test that didn't work correctly with the OpenJDK and added an @ignore tag to > that test. > > Updated webrev can be found at: > http://cr.openjdk.java.net/~ctornqvi/webrev/8032999/webrev.01/ > > Thanks, > Christian > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of > Christian Tornqvist > Sent: Thursday, August 14, 2014 12:23 PM > To: hotspot-dev at openjdk.java.net > Subject: RFR(S): 8032999 - [TESTBUG] JT-Reg Runtime tests to be run as part > of JPRT submit job > > Hi everyone, > > > > This change turns on the runtime jtreg tests in JPRT, except for a few tests > that were excluded due to taking too long to run/had intermittent timeout > issues. I also added @ignore tags to the tests with known issues to prevent > them from running. > > > > Webrev can be found at: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8032999/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8032999 > > > > Thanks, > > Christian > > From mikael.vidstedt at oracle.com Thu Aug 14 22:40:34 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 14 Aug 2014 15:40:34 -0700 Subject: RFR(S): 8032999 - [TESTBUG] JT-Reg Runtime tests to be run as part of JPRT submit job In-Reply-To: <053101cfb80f$bf82e300$3e88a900$@oracle.com> References: <049c01cfb7db$fb5ed250$f21c76f0$@oracle.com> <053101cfb80f$bf82e300$3e88a900$@oracle.com> Message-ID: <53ED3AE2.4080608@oracle.com> Christian, Thank you very much for taking this on! You will need to update the jprt.properties file on the top level too (hs-rt/make/jprt.properties) to reflect the change you made in hs-rt/hotspot/make/jprt.properties. Unfortunately the configuration is effectively copy/pasted in there right now. Otherwise, it looks good! Cheers, Mikael On 2014-08-14 15:33, Christian Tornqvist wrote: > After some feedback from Coleen and discussions with Mikael Vidstedt I made > some changes to keep OpenJDK builds working through JPRT. I discovered one > test that didn't work correctly with the OpenJDK and added an @ignore tag to > that test. > > Updated webrev can be found at: > http://cr.openjdk.java.net/~ctornqvi/webrev/8032999/webrev.01/ > > Thanks, > Christian > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of > Christian Tornqvist > Sent: Thursday, August 14, 2014 12:23 PM > To: hotspot-dev at openjdk.java.net > Subject: RFR(S): 8032999 - [TESTBUG] JT-Reg Runtime tests to be run as part > of JPRT submit job > > Hi everyone, > > > > This change turns on the runtime jtreg tests in JPRT, except for a few tests > that were excluded due to taking too long to run/had intermittent timeout > issues. I also added @ignore tags to the tests with known issues to prevent > them from running. > > > > Webrev can be found at: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8032999/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8032999 > > > > Thanks, > > Christian > > From christian.tornqvist at oracle.com Thu Aug 14 22:45:28 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 14 Aug 2014 18:45:28 -0400 Subject: RFR(S): 8032999 - [TESTBUG] JT-Reg Runtime tests to be run as part of JPRT submit job In-Reply-To: <53ED3AE2.4080608@oracle.com> References: <049c01cfb7db$fb5ed250$f21c76f0$@oracle.com> <053101cfb80f$bf82e300$3e88a900$@oracle.com> <53ED3AE2.4080608@oracle.com> Message-ID: <053301cfb811$727e7a40$577b6ec0$@oracle.com> Thanks Mikael, I've made the same change to top-level jprt.properties too. Thanks, Christian -----Original Message----- From: Mikael Vidstedt [mailto:mikael.vidstedt at oracle.com] Sent: Thursday, August 14, 2014 6:41 PM To: Christian Tornqvist; hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8032999 - [TESTBUG] JT-Reg Runtime tests to be run as part of JPRT submit job Christian, Thank you very much for taking this on! You will need to update the jprt.properties file on the top level too (hs-rt/make/jprt.properties) to reflect the change you made in hs-rt/hotspot/make/jprt.properties. Unfortunately the configuration is effectively copy/pasted in there right now. Otherwise, it looks good! Cheers, Mikael On 2014-08-14 15:33, Christian Tornqvist wrote: > After some feedback from Coleen and discussions with Mikael Vidstedt I > made some changes to keep OpenJDK builds working through JPRT. I > discovered one test that didn't work correctly with the OpenJDK and > added an @ignore tag to that test. > > Updated webrev can be found at: > http://cr.openjdk.java.net/~ctornqvi/webrev/8032999/webrev.01/ > > Thanks, > Christian > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Christian Tornqvist > Sent: Thursday, August 14, 2014 12:23 PM > To: hotspot-dev at openjdk.java.net > Subject: RFR(S): 8032999 - [TESTBUG] JT-Reg Runtime tests to be run as > part of JPRT submit job > > Hi everyone, > > > > This change turns on the runtime jtreg tests in JPRT, except for a few > tests that were excluded due to taking too long to run/had > intermittent timeout issues. I also added @ignore tags to the tests > with known issues to prevent them from running. > > > > Webrev can be found at: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8032999/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8032999 > > > > Thanks, > > Christian > > From paul.hohensee at gmail.com Fri Aug 15 00:34:16 2014 From: paul.hohensee at gmail.com (Paul Hohensee) Date: Thu, 14 Aug 2014 20:34:16 -0400 Subject: Question about Unsafe.prefetch ... () ? Message-ID: Alan wrote: > On 14/08/2014 15:48, Christian Thalinger wrote: > > Sorry, the link didn?t come through: > > > > https://bugs.openjdk.java.net/browse/JDK-6807143 > > > At the time Paul Hohensee was experimenting with prefetching and put the > support into HotSpot. As I recall, the intention was to add it to > sun.misc.Unsafe when a beneficial use of using it directly in the JDK > ibraries was identified. True. As I recall, we had an experimental version of Unsafe which included the prefetch methods, but decided not to ship it because our experiments showed no benefit to using them. Paul From alejandro.murillo at oracle.com Fri Aug 15 17:27:20 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 15 Aug 2014 11:27:20 -0600 Subject: RFR 8055217: Make jdk8u40 the default jprt release for hs25.40 Message-ID: <53EE42F8.9000101@oracle.com> can I get a quick review for this change? http://cr.openjdk.java.net/~amurillo/8u40/8055217/ Thanks -- Alejandro From mikael.vidstedt at oracle.com Fri Aug 15 17:41:03 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 15 Aug 2014 10:41:03 -0700 Subject: RFR 8055217: Make jdk8u40 the default jprt release for hs25.40 In-Reply-To: <53EE42F8.9000101@oracle.com> References: <53EE42F8.9000101@oracle.com> Message-ID: <53EE462F.9010003@oracle.com> Looks good! Cheers, Mikael On 2014-08-15 10:27, Alejandro E Murillo wrote: > can I get a quick review for this change? > > http://cr.openjdk.java.net/~amurillo/8u40/8055217/ > > Thanks > From alejandro.murillo at oracle.com Fri Aug 15 17:54:52 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 15 Aug 2014 11:54:52 -0600 Subject: RFR 8055217: Make jdk8u40 the default jprt release for hs25.40 In-Reply-To: <53EE462F.9010003@oracle.com> References: <53EE42F8.9000101@oracle.com> <53EE462F.9010003@oracle.com> Message-ID: <53EE496B.3070100@oracle.com> Thanks! Alejandro On 8/15/2014 11:41 AM, Mikael Vidstedt wrote: > > Looks good! > > Cheers, > Mikael > > On 2014-08-15 10:27, Alejandro E Murillo wrote: >> can I get a quick review for this change? >> >> http://cr.openjdk.java.net/~amurillo/8u40/8055217/ >> >> Thanks >> > -- Alejandro From vladimir.kozlov at oracle.com Fri Aug 15 18:19:20 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 15 Aug 2014 11:19:20 -0700 Subject: RFR 8055217: Make jdk8u40 the default jprt release for hs25.40 In-Reply-To: <53EE42F8.9000101@oracle.com> References: <53EE42F8.9000101@oracle.com> Message-ID: <53EE4F28.1000907@oracle.com> Good. Vladimir On 8/15/14 10:27 AM, Alejandro E Murillo wrote: > can I get a quick review for this change? > > http://cr.openjdk.java.net/~amurillo/8u40/8055217/ > > Thanks > From coleen.phillimore at oracle.com Fri Aug 15 18:50:02 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 15 Aug 2014 14:50:02 -0400 Subject: [9] RFR: JI-9039953 zero variant build is broken. In-Reply-To: <1407932280.3171.30.camel@localhost.localdomain> References: <1407167406.3128.53.camel@localhost.localdomain> <53DFC762.2070100@oracle.com> <1407932280.3171.30.camel@localhost.localdomain> Message-ID: <53EE565A.2030705@oracle.com> This looks good. I will sponsor it. Thanks, Coleen On 8/13/14, 8:18 AM, Severin Gehwolf wrote: > Hi, > > On Mon, 2014-08-04 at 13:48 -0400, Coleen Phillimore wrote: >> Hi, >> >> Did you try to build fastdebug? I found 2 more compilation errors when >> I did that. >> >> http://cr.openjdk.java.net/~coleenp/8003426/src/cpu/zero/vm/cppInterpreter_zero.cpp.udiff.html >> http://cr.openjdk.java.net/~coleenp/8003426/src/share/vm/interpreter/bytecodeInterpreter.cpp.udiff.html >> >> Although the last one could be due to the version of gcc I was using >> (not sure). >> >> Coleen >> >> On 8/4/14, 11:50 AM, Severin Gehwolf wrote: >>> Hi, >>> >>> Building a zero variant of hotspot fails for the latest hs-comp tree >>> with ("release"-type build): >>> src/cpu/zero/vm/frame_zero.inline.hpp:59:11: error: ?CodeCache? has not >>> been declared >>> >>> It appears to have been caused by a change of header files (perhaps >>> [1]?). A file which used to be included implicitly does not seem to be >>> included any longer. An explicit include fixes the problem. >>> >>> [2] shows the build failure. >>> >>> I would need a proper JDK bug and a sponsor for this change. An initial >>> bug has been submitted as JI-9039953 via the web interface. >>> >>> Webrev is here: >>> https://jerboaa.fedorapeople.org/bugs/openjdk/JI-9039953/webrev.01/ > I've updated the webrev which now also includes Coleen's fixes. > https://jerboaa.fedorapeople.org/bugs/openjdk/JI-9039953/webrev.02/ > > Testing done: > Successfully built zero variants[*]: release, slowdebug, fastdebug > Successfully built a regular server JVM release build. > > Cheers, > Severin > > [*] I've used the attached patches to work-around the generic > fortify-source build problem. > >>> Thanks, >>> Severin >>> >>> [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/22b98ab2a69f >>> [2] >>> http://builder.classpath.org/jenkins/job/OpenJDK9_hscomp_Zero/47/console >>> > From coleen.phillimore at oracle.com Fri Aug 15 20:18:42 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 15 Aug 2014 16:18:42 -0400 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes Message-ID: <53EE6B22.3040107@oracle.com> Summary: Use scratch_class to find EMCP methods for breakpoints if the old methods are still running See bug for more details. This fix also includes a change to nmethod::metadata_do() to not walk the _method multiple times (the _method is added to the metadata section of the nmethod), and an attempt to help the sweeper clean up these scratch_class instance classes sooner. Tested with nsk tests, java/lang/instrument tests and jck tests (which include some jvmti tests). open webrev at http://cr.openjdk.java.net/~coleenp/8055008/ bug link https://bugs.openjdk.java.net/browse/JDK-8055008 Thanks, Coleen From igor.veresov at oracle.com Mon Aug 18 00:01:34 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Sun, 17 Aug 2014 17:01:34 -0700 Subject: [8u] RFR(XS): 8054883 Segmentation error while running program Message-ID: I?d like to backport this to 8u. Webrev: http://cr.openjdk.java.net/~iveresov/8054883/webrev.00/ JDK9: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1d600d0306c6 JBS: https://bugs.openjdk.java.net/browse/JDK-8054883 Thanks! igor From tobias.hartmann at oracle.com Mon Aug 18 06:49:55 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 18 Aug 2014 08:49:55 +0200 Subject: [8u40] RFR(S): 8054402: "klass->is_loader_alive(_is_alive)) failed: must be alive" for anonymous classes Message-ID: <53F1A213.8020106@oracle.com> Hi, please review this 8u40 backport request. The changes were pushed on Thursday. Nightly testing showed no problems. The patch applies cleanly to 8u40. Master bug: https://bugs.openjdk.java.net/browse/JDK-8054402 Webrev: http://cr.openjdk.java.net/~thartmann/8054402/webrev.01/ Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/cf3ccda01fa6 Thanks, Tobias From vladimir.kozlov at oracle.com Mon Aug 18 07:07:59 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Aug 2014 00:07:59 -0700 Subject: [8u40] RFR(S): 8054402: "klass->is_loader_alive(_is_alive)) failed: must be alive" for anonymous classes In-Reply-To: <53F1A213.8020106@oracle.com> References: <53F1A213.8020106@oracle.com> Message-ID: <53F1A64F.60009@oracle.com> Looks good. Please, wait at least one more Nightly. Thanks, Vladimir On 8/17/14 11:49 PM, Tobias Hartmann wrote: > Hi, > > please review this 8u40 backport request. The changes were pushed on Thursday. > > Nightly testing showed no problems. The patch applies cleanly to 8u40. > > Master bug: https://bugs.openjdk.java.net/browse/JDK-8054402 > Webrev: http://cr.openjdk.java.net/~thartmann/8054402/webrev.01/ > Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/cf3ccda01fa6 > > Thanks, > Tobias From vladimir.kozlov at oracle.com Mon Aug 18 07:08:28 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Aug 2014 00:08:28 -0700 Subject: [8u] RFR(XS): 8054883 Segmentation error while running program In-Reply-To: References: Message-ID: <53F1A66C.3000904@oracle.com> Good. Thanks, Vladimir On 8/17/14 5:01 PM, Igor Veresov wrote: > I?d like to backport this to 8u. > > Webrev: http://cr.openjdk.java.net/~iveresov/8054883/webrev.00/ > JDK9: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1d600d0306c6 > JBS: https://bugs.openjdk.java.net/browse/JDK-8054883 > > Thanks! > igor > > From tobias.hartmann at oracle.com Mon Aug 18 07:09:23 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 18 Aug 2014 09:09:23 +0200 Subject: [8u40] RFR(S): 8054402: "klass->is_loader_alive(_is_alive)) failed: must be alive" for anonymous classes In-Reply-To: <53F1A64F.60009@oracle.com> References: <53F1A213.8020106@oracle.com> <53F1A64F.60009@oracle.com> Message-ID: <53F1A6A3.60509@oracle.com> Hi Vladimir, thanks for the review. I"ll wait for another nightly before pushing. Best, Tobias On 18.08.2014 09:07, Vladimir Kozlov wrote: > Looks good. Please, wait at least one more Nightly. > > Thanks, > Vladimir > > On 8/17/14 11:49 PM, Tobias Hartmann wrote: >> Hi, >> >> please review this 8u40 backport request. The changes were pushed on >> Thursday. >> >> Nightly testing showed no problems. The patch applies cleanly to 8u40. >> >> Master bug: https://bugs.openjdk.java.net/browse/JDK-8054402 >> Webrev: http://cr.openjdk.java.net/~thartmann/8054402/webrev.01/ >> Changeset: >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/cf3ccda01fa6 >> >> Thanks, >> Tobias From mikael.gerdin at oracle.com Mon Aug 18 13:30:25 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 18 Aug 2014 15:30:25 +0200 Subject: RFR 8055284: sanity/WhiteBox.java fails with NPE Message-ID: <53F1FFF1.30209@oracle.com> Hi all, sanity/WhiteBox.java was mistakenly modified by a recent mass-update of jtreg whitebox tests to allow them to pass with the -Xverify:all flag. The problem is that sanity/WhiteBox.java is a special test which provides its own version of the sun.hotspot.WhiteBox class. The change is therefore not applicable to the test and the nested WhiteBoxPermission class does not exist, causing the test to fail with an NPE because of the missing class file. Webrev: http://cr.openjdk.java.net/~mgerdin/8055284/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8055284 Thanks to Dmitry Fazunenko for putting the suggested fix into the bug comments, I'll put his name as a contributor on the changeset. /Mikael From erik.helin at oracle.com Mon Aug 18 13:30:29 2014 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 18 Aug 2014 15:30:29 +0200 Subject: RFR 8055284: sanity/WhiteBox.java fails with NPE In-Reply-To: <53F1FFF1.30209@oracle.com> References: <53F1FFF1.30209@oracle.com> Message-ID: <53F1FFF5.7030608@oracle.com> Looks good, Reviewed. Thanks, Erik On 2014-08-18 15:30, Mikael Gerdin wrote: > Hi all, > > sanity/WhiteBox.java was mistakenly modified by a recent mass-update of > jtreg whitebox tests to allow them to pass with the -Xverify:all flag. > The problem is that sanity/WhiteBox.java is a special test which > provides its own version of the sun.hotspot.WhiteBox class. > > The change is therefore not applicable to the test and the nested > WhiteBoxPermission class does not exist, causing the test to fail with > an NPE because of the missing class file. > > Webrev: http://cr.openjdk.java.net/~mgerdin/8055284/webrev.0/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8055284 > > Thanks to Dmitry Fazunenko for putting the suggested fix into the bug > comments, I'll put his name as a contributor on the changeset. > > /Mikael From mikael.gerdin at oracle.com Mon Aug 18 13:46:34 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 18 Aug 2014 15:46:34 +0200 Subject: RFR 8055284: sanity/WhiteBox.java fails with NPE In-Reply-To: <53F1FFF5.7030608@oracle.com> References: <53F1FFF1.30209@oracle.com> <53F1FFF5.7030608@oracle.com> Message-ID: <53F203BA.9060000@oracle.com> Thanks for the quick review, Erik. /Mikael On 2014-08-18 15:30, Erik Helin wrote: > Looks good, Reviewed. > > Thanks, > Erik > > On 2014-08-18 15:30, Mikael Gerdin wrote: >> Hi all, >> >> sanity/WhiteBox.java was mistakenly modified by a recent mass-update of >> jtreg whitebox tests to allow them to pass with the -Xverify:all flag. >> The problem is that sanity/WhiteBox.java is a special test which >> provides its own version of the sun.hotspot.WhiteBox class. >> >> The change is therefore not applicable to the test and the nested >> WhiteBoxPermission class does not exist, causing the test to fail with >> an NPE because of the missing class file. >> >> Webrev: http://cr.openjdk.java.net/~mgerdin/8055284/webrev.0/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8055284 >> >> Thanks to Dmitry Fazunenko for putting the suggested fix into the bug >> comments, I'll put his name as a contributor on the changeset. >> >> /Mikael From bengt.rutisson at oracle.com Mon Aug 18 13:50:39 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 18 Aug 2014 15:50:39 +0200 Subject: RFR 8055284: sanity/WhiteBox.java fails with NPE In-Reply-To: <53F1FFF1.30209@oracle.com> References: <53F1FFF1.30209@oracle.com> Message-ID: <53F204AF.4070507@oracle.com> Looks good. Bengt On 2014-08-18 15:30, Mikael Gerdin wrote: > Hi all, > > sanity/WhiteBox.java was mistakenly modified by a recent mass-update > of jtreg whitebox tests to allow them to pass with the -Xverify:all flag. > The problem is that sanity/WhiteBox.java is a special test which > provides its own version of the sun.hotspot.WhiteBox class. > > The change is therefore not applicable to the test and the nested > WhiteBoxPermission class does not exist, causing the test to fail with > an NPE because of the missing class file. > > Webrev: http://cr.openjdk.java.net/~mgerdin/8055284/webrev.0/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8055284 > > Thanks to Dmitry Fazunenko for putting the suggested fix into the bug > comments, I'll put his name as a contributor on the changeset. > > /Mikael From mikael.gerdin at oracle.com Mon Aug 18 14:24:28 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 18 Aug 2014 16:24:28 +0200 Subject: RFR 8055283: Expand ResourceHashtable with C_HEAP allocation, removal and some unit tests Message-ID: <53F20C9C.5010905@oracle.com> Hi all! For an upcoming change I need to allocate ResourceHashtables as c-heap objects instead of arena objects. Since the ResourceObj allocation type typically supports c-heap allocation I extended ResourceHashtable with the functionality. I also need a remove method and a size estimate, added those as well. Additionally, I took the liberty to fix the default hash function which appears to be a typo: return hash ^ (hash > 3); // just in case we're dealing with aligned ptrs I don't think the intention was to xor with "true" if hash was greater than 3, especially given the comment about aligned ptrs. I assume that the original author meant to shift hash to the right since aligned pointers will have a bunch of zeros in the low bits. I also took the liberty to add some simple unit tests to the class to avoid breaking something. Testing: JPRT (including the new unit test) and vm.defmeth.testlist (since default methods seems to be the only user of the default hash function) Bug: https://bugs.openjdk.java.net/browse/JDK-8055283 Webrev: http://cr.openjdk.java.net/~mgerdin/8055283/webrev.0 /Mikael From coleen.phillimore at oracle.com Mon Aug 18 14:50:12 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 18 Aug 2014 10:50:12 -0400 Subject: RFR 8055283: Expand ResourceHashtable with C_HEAP allocation, removal and some unit tests In-Reply-To: <53F20C9C.5010905@oracle.com> References: <53F20C9C.5010905@oracle.com> Message-ID: <53F212A4.8000803@oracle.com> The default hash table in hashtable.hpp is a C Heap allocated hash table. Coleen On 8/18/14, 10:24 AM, Mikael Gerdin wrote: > Hi all! > > For an upcoming change I need to allocate ResourceHashtables as c-heap > objects instead of arena objects. Since the ResourceObj allocation > type typically supports c-heap allocation I extended ResourceHashtable > with the functionality. > I also need a remove method and a size estimate, added those as well. > > Additionally, I took the liberty to fix the default hash function > which appears to be a typo: > return hash ^ (hash > 3); > // just in case we're dealing with aligned ptrs > > I don't think the intention was to xor with "true" if hash was greater > than 3, especially given the comment about aligned ptrs. > > I assume that the original author meant to shift hash to the right > since aligned pointers will have a bunch of zeros in the low bits. > > I also took the liberty to add some simple unit tests to the class to > avoid breaking something. > > Testing: JPRT (including the new unit test) and vm.defmeth.testlist > (since default methods seems to be the only user of the default hash > function) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8055283 > > Webrev: http://cr.openjdk.java.net/~mgerdin/8055283/webrev.0 > > /Mikael From sgehwolf at redhat.com Mon Aug 18 14:58:16 2014 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 18 Aug 2014 16:58:16 +0200 Subject: [9] RFR: JI-9039953 zero variant build is broken. In-Reply-To: <53EE565A.2030705@oracle.com> References: <1407167406.3128.53.camel@localhost.localdomain> <53DFC762.2070100@oracle.com> <1407932280.3171.30.camel@localhost.localdomain> <53EE565A.2030705@oracle.com> Message-ID: <1408373896.3113.17.camel@localhost.localdomain> On Fri, 2014-08-15 at 14:50 -0400, Coleen Phillimore wrote: > This looks good. I will sponsor it. Thank you, Coleen! Cheers, Severin > Thanks, > Coleen > > On 8/13/14, 8:18 AM, Severin Gehwolf wrote: > > Hi, > > > > On Mon, 2014-08-04 at 13:48 -0400, Coleen Phillimore wrote: > >> Hi, > >> > >> Did you try to build fastdebug? I found 2 more compilation errors when > >> I did that. > >> > >> http://cr.openjdk.java.net/~coleenp/8003426/src/cpu/zero/vm/cppInterpreter_zero.cpp.udiff.html > >> http://cr.openjdk.java.net/~coleenp/8003426/src/share/vm/interpreter/bytecodeInterpreter.cpp.udiff.html > >> > >> Although the last one could be due to the version of gcc I was using > >> (not sure). > >> > >> Coleen > >> > >> On 8/4/14, 11:50 AM, Severin Gehwolf wrote: > >>> Hi, > >>> > >>> Building a zero variant of hotspot fails for the latest hs-comp tree > >>> with ("release"-type build): > >>> src/cpu/zero/vm/frame_zero.inline.hpp:59:11: error: ?CodeCache? has not > >>> been declared > >>> > >>> It appears to have been caused by a change of header files (perhaps > >>> [1]?). A file which used to be included implicitly does not seem to be > >>> included any longer. An explicit include fixes the problem. > >>> > >>> [2] shows the build failure. > >>> > >>> I would need a proper JDK bug and a sponsor for this change. An initial > >>> bug has been submitted as JI-9039953 via the web interface. > >>> > >>> Webrev is here: > >>> https://jerboaa.fedorapeople.org/bugs/openjdk/JI-9039953/webrev.01/ > > I've updated the webrev which now also includes Coleen's fixes. > > https://jerboaa.fedorapeople.org/bugs/openjdk/JI-9039953/webrev.02/ > > > > Testing done: > > Successfully built zero variants[*]: release, slowdebug, fastdebug > > Successfully built a regular server JVM release build. > > > > Cheers, > > Severin > > > > [*] I've used the attached patches to work-around the generic > > fortify-source build problem. > > > >>> Thanks, > >>> Severin > >>> > >>> [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/22b98ab2a69f > >>> [2] > >>> http://builder.classpath.org/jenkins/job/OpenJDK9_hscomp_Zero/47/console > >>> > > > From mikael.gerdin at oracle.com Mon Aug 18 15:22:46 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 18 Aug 2014 17:22:46 +0200 Subject: RFR 8055283: Expand ResourceHashtable with C_HEAP allocation, removal and some unit tests In-Reply-To: <53F212A4.8000803@oracle.com> References: <53F20C9C.5010905@oracle.com> <53F212A4.8000803@oracle.com> Message-ID: <53F21A46.7030700@oracle.com> On 2014-08-18 16:50, Coleen Phillimore wrote: > > The default hash table in hashtable.hpp is a C Heap allocated hash table. It's not so much a hash table as some bits and pieces which can (and have been in some cases) combined to a hash table. You just have to write all the methods for it yourself. Isn't that convenient. > > Coleen > > On 8/18/14, 10:24 AM, Mikael Gerdin wrote: >> Hi all! >> >> For an upcoming change I need to allocate ResourceHashtables as c-heap >> objects instead of arena objects. Since the ResourceObj allocation >> type typically supports c-heap allocation I extended ResourceHashtable >> with the functionality. >> I also need a remove method and a size estimate, added those as well. >> >> Additionally, I took the liberty to fix the default hash function >> which appears to be a typo: >> return hash ^ (hash > 3); >> // just in case we're dealing with aligned ptrs >> >> I don't think the intention was to xor with "true" if hash was greater >> than 3, especially given the comment about aligned ptrs. >> >> I assume that the original author meant to shift hash to the right >> since aligned pointers will have a bunch of zeros in the low bits. >> >> I also took the liberty to add some simple unit tests to the class to >> avoid breaking something. >> >> Testing: JPRT (including the new unit test) and vm.defmeth.testlist >> (since default methods seems to be the only user of the default hash >> function) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8055283 >> >> Webrev: http://cr.openjdk.java.net/~mgerdin/8055283/webrev.0 >> >> /Mikael > From jesper.wilhelmsson at oracle.com Tue Aug 19 14:57:43 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 19 Aug 2014 16:57:43 +0200 Subject: RFR: 8055006 - Store original value of Min/MaxHeapFreeRatio Message-ID: <53F365E7.9050305@oracle.com> Hi, Please review this change to store the original values of Min- and MaxHeapFreeRatio. This change also include some makefile changes to make it possible to override some variables in the make files. This is needed in preparation for the code that will update the Min/MaxHeapFreeRatio later on. Webrev: http://cr.openjdk.java.net/~jwilhelm/8055006/ Bug: https://bugs.openjdk.java.net/browse/JDK-8055006 Thanks! /Jesper From jon.masamitsu at oracle.com Tue Aug 19 19:42:30 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 19 Aug 2014 12:42:30 -0700 Subject: RFR: 8055006 - Store original value of Min/MaxHeapFreeRatio In-Reply-To: <53F365E7.9050305@oracle.com> References: <53F365E7.9050305@oracle.com> Message-ID: <53F3A8A6.1070401@oracle.com> On 08/19/2014 07:57 AM, Jesper Wilhelmsson wrote: > Hi, > > Please review this change to store the original values of Min- and > MaxHeapFreeRatio. > > This change also include some makefile changes to make it possible to > override some variables in the make files. This is needed in > preparation for the code that will update the Min/MaxHeapFreeRatio > later on. > > Webrev: http://cr.openjdk.java.net/~jwilhelm/8055006/ Changes look good. Reviewed. Jon > Bug: https://bugs.openjdk.java.net/browse/JDK-8055006 > > Thanks! > /Jesper From jesper.wilhelmsson at oracle.com Tue Aug 19 21:28:14 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 19 Aug 2014 23:28:14 +0200 Subject: RFR: 8055006 - Store original value of Min/MaxHeapFreeRatio In-Reply-To: <53F3A8A6.1070401@oracle.com> References: <53F365E7.9050305@oracle.com> <53F3A8A6.1070401@oracle.com> Message-ID: <53F3C16E.5090405@oracle.com> Thanks Jon! /Jesper Jon Masamitsu skrev 19/8/14 21:42: > > On 08/19/2014 07:57 AM, Jesper Wilhelmsson wrote: >> Hi, >> >> Please review this change to store the original values of Min- and >> MaxHeapFreeRatio. >> >> This change also include some makefile changes to make it possible to override >> some variables in the make files. This is needed in preparation for the code >> that will update the Min/MaxHeapFreeRatio later on. >> >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8055006/ > > Changes look good. > > Reviewed. > > Jon > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8055006 >> >> Thanks! >> /Jesper > From daniel.daugherty at oracle.com Tue Aug 19 21:39:50 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Aug 2014 15:39:50 -0600 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53EE6B22.3040107@oracle.com> References: <53EE6B22.3040107@oracle.com> Message-ID: <53F3C426.9080408@oracle.com> On 8/15/14 2:18 PM, Coleen Phillimore wrote: > Summary: Use scratch_class to find EMCP methods for breakpoints if the > old methods are still running > > See bug for more details. This fix also includes a change to > nmethod::metadata_do() to not walk the _method multiple times (the > _method is added to the metadata section of the nmethod), and an > attempt to help the sweeper clean up these scratch_class instance > classes sooner. > > Tested with nsk tests, java/lang/instrument tests and jck tests (which > include some jvmti tests). > > open webrev at http://cr.openjdk.java.net/~coleenp/8055008/ src/share/vm/oops/instanceKlass.hpp line 1047 // RedefineClass support Should be 'RedefineClasses'. line 1049: void mark_newly_obsolete_methods(Array* old_methods, int emcp_method_count); The 'obsolete' part of the function name does not match with the 'emcp' part of the parameter name. EMCP methods are 'old', but not 'obsolete'. Update: OK, I think I get it. We want to mark methods that are newly transitioning from EMCP -> obsolete and the emcp_method_count parameter tells us if there is any work to do. src/share/vm/oops/instanceKlass.cpp line 3023: } // pvw is cleaned up 'pvw' no longer exists so comment is stale. line 3455: // check the previous versions array This comment should move above this line: 3453 for (; pv_node != NULL; ) { and 'array' should change to 'list'. Sorry for the bad placement of the original comment. line 3463: last->link_previous_versions(pv_node); So now we've overwritten the previous value of last->previous_versions. How does that InstanceKlass get freed? Maybe a short comment? line 3484: // Mark the emcp method as obsolete if it's not executing I'm not sure about whether this is a good idea. When we had a redefine make a method obsolete before, we knew that we could make all older but previously EMCP methods obsolete because the new method version did make them obsolete. With this optimization, we're saying that no thread is executing the method so we're going to make it obsolete even if the current redefine did not do so. I worry about a method call that is in the early stages of assembling the call stack being caught calling a method that is now obsolete but not because of a redefine made it obsolete. Just FYI, one of the tracing flags catches unexpected calls to obsolete methods today and it does catch the current system's legitimate race. line 3527: // clear out any matching EMCP method entries the hard way. Perhaps "mark" instead of "clear out"? old line 3659: if (!method->is_obsolete() && new line 3546: if (method->is_emcp() && The old code is correct. The old code won't remark a method that was already made obsolete so there won't be more than one trace message for that operation. line 3581: // stack, and set emcp methods on the stack. In comments 'emcp' should be 'EMCP'. We did not do that in the code because of HotSpot's variable name style. Also, set what on EMCP methods on the stack? line 3591: ... If emcp method from line 3592: // a previous redefinition may be made obsolete by this redefinition. Having trouble parsing this comment. src/share/vm/oops/method.hpp line 693: // emcp methods (equivalent method except constant pool is different) line 694: // that are old but not obsolete or deleted. Perhaps: // EMCP methods are old but not obsolete or deleted. Equivalent // Modulo Constant Pool means the method is equivalent except // the constant pool and instructions that access the constant // pool might be different. src/share/vm/prims/jvmtiImpl.cpp No comments. src/share/vm/prims/jvmtiRedefineClasses.cpp No comments. src/share/vm/code/nmethod.cpp So in the original code f(_method) was being called two extra times? (once in the while-loop and once at the end) So I'm guessing that f(_method) is properly called when the rest of the metadata is handled in the nmethod (line 2085)? src/share/vm/memory/universe.cpp No comments (resisting 'The Walking Dead' ref...) test/runtime/RedefineTests/RedefineFinalizer.java No comments. test/runtime/RedefineTests/RedefineRunningMethods.java line 44: " while (!stop) { count2++; }" + line 53: while (!stop) { count1++; } line 56: while (!stop) { count2++; } These may not behave well on OSes with bad threading models. You might want to add a helper function that sleeps for 10ms and have each of these loops call it so the test more well behaved. Dan > bug link https://bugs.openjdk.java.net/browse/JDK-8055008 > > Thanks, > Coleen From daniel.daugherty at oracle.com Tue Aug 19 22:53:37 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Aug 2014 16:53:37 -0600 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F3C426.9080408@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> Message-ID: <53F3D571.7060609@oracle.com> On 8/19/14 3:39 PM, Daniel D. Daugherty wrote: > On 8/15/14 2:18 PM, Coleen Phillimore wrote: >> Summary: Use scratch_class to find EMCP methods for breakpoints if >> the old methods are still running >> >> See bug for more details. This fix also includes a change to >> nmethod::metadata_do() to not walk the _method multiple times (the >> _method is added to the metadata section of the nmethod), and an >> attempt to help the sweeper clean up these scratch_class instance >> classes sooner. >> >> Tested with nsk tests, java/lang/instrument tests and jck tests >> (which include some jvmti tests). >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8055008/ > > src/share/vm/oops/instanceKlass.hpp > line 1047 // RedefineClass support > Should be 'RedefineClasses'. > > line 1049: void mark_newly_obsolete_methods(Array* > old_methods, > int emcp_method_count); > The 'obsolete' part of the function name does not match with > the 'emcp' part of the parameter name. EMCP methods are 'old', > but not 'obsolete'. > > Update: OK, I think I get it. We want to mark methods that are > newly transitioning from EMCP -> obsolete and the > emcp_method_count > parameter tells us if there is any work to do. > > src/share/vm/oops/instanceKlass.cpp > line 3023: } // pvw is cleaned up > 'pvw' no longer exists so comment is stale. > > line 3455: // check the previous versions array > This comment should move above this line: > > 3453 for (; pv_node != NULL; ) { > > and 'array' should change to 'list'. > > Sorry for the bad placement of the original comment. > > line 3463: last->link_previous_versions(pv_node); > So now we've overwritten the previous value of > last->previous_versions. How does that InstanceKlass > get freed? Maybe a short comment? > > line 3484: // Mark the emcp method as obsolete if it's not executing > I'm not sure about whether this is a good idea. When we had a > redefine make a method obsolete before, we knew that we could > make all older but previously EMCP methods obsolete because > the new method version did make them obsolete. > > With this optimization, we're saying that no thread is executing > the method so we're going to make it obsolete even if the current > redefine did not do so. I worry about a method call that is in > the early stages of assembling the call stack being caught > calling a method that is now obsolete but not because of a > redefine made it obsolete. Just FYI, one of the tracing flags > catches unexpected calls to obsolete methods today and it does > catch the current system's legitimate race. JVM/TI has an isMethodObsolete() API: jvmtiError IsMethodObsolete(jvmtiEnv* env, jmethodID method, jboolean* is_obsolete_ptr) It would be possible for an agent to observe a method changing from not obsolete to obsolete when that's not expected. I suspect that this would be a spec violation. Dan > > line 3527: // clear out any matching EMCP method entries the hard > way. > Perhaps "mark" instead of "clear out"? > > old line 3659: if (!method->is_obsolete() && > new line 3546: if (method->is_emcp() && > The old code is correct. The old code won't remark a method that > was already made obsolete so there won't be more than one trace > message for that operation. > > line 3581: // stack, and set emcp methods on the stack. > In comments 'emcp' should be 'EMCP'. We did not do that in the > code because of HotSpot's variable name style. > > Also, set what on EMCP methods on the stack? > > line 3591: ... If emcp method from > line 3592: // a previous redefinition may be made obsolete by this > redefinition. > Having trouble parsing this comment. > > src/share/vm/oops/method.hpp > line 693: // emcp methods (equivalent method except constant pool > is different) > line 694: // that are old but not obsolete or deleted. > Perhaps: > > // EMCP methods are old but not obsolete or deleted. Equivalent > // Modulo Constant Pool means the method is equivalent except > // the constant pool and instructions that access the constant > // pool might be different. > > src/share/vm/prims/jvmtiImpl.cpp > No comments. > > src/share/vm/prims/jvmtiRedefineClasses.cpp > No comments. > > src/share/vm/code/nmethod.cpp > So in the original code f(_method) was being called two extra > times? (once in the while-loop and once at the end) So I'm > guessing that f(_method) is properly called when the rest of > the metadata is handled in the nmethod (line 2085)? > > src/share/vm/memory/universe.cpp > No comments (resisting 'The Walking Dead' ref...) > > test/runtime/RedefineTests/RedefineFinalizer.java > No comments. > > test/runtime/RedefineTests/RedefineRunningMethods.java > line 44: " while (!stop) { count2++; }" + > line 53: while (!stop) { count1++; } > line 56: while (!stop) { count2++; } > > These may not behave well on OSes with bad threading > models. You might want to add a helper function that > sleeps for 10ms and have each of these loops call it > so the test more well behaved. > > Dan > > >> bug link https://bugs.openjdk.java.net/browse/JDK-8055008 >> >> Thanks, >> Coleen > > From christian.tornqvist at oracle.com Tue Aug 19 23:39:01 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 19 Aug 2014 19:39:01 -0400 Subject: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams Message-ID: <038701cfbc06$c1e63930$45b2ab90$@oracle.com> Hi everyone, This change adds /homeparams (http://msdn.microsoft.com/en-us/library/6exwh0y6.aspx) to compiler flags when building fastdebug on Windows x64. This causes the compiler to generate code to spill the first 4 arguments to the stack (they're normally only passed in registers), which should make it easier to debug. I also changed the ProjectCreator to enable building with this using Visual Studio. The size of jvm.dll increases with about 3% (about 504k increase). Verified that it builds correctly using Visual Studio and JPRT, the generation of the spill code has been verified by comparing prologue code for several functions in the JVM with/without using /homeparams. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8027480 Thanks, Christian From david.holmes at oracle.com Tue Aug 19 23:41:02 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Aug 2014 09:41:02 +1000 Subject: RFR: 8055006 - Store original value of Min/MaxHeapFreeRatio In-Reply-To: <53F365E7.9050305@oracle.com> References: <53F365E7.9050305@oracle.com> Message-ID: <53F3E08E.40004@oracle.com> Ok. Thanks, David On 20/08/2014 12:57 AM, Jesper Wilhelmsson wrote: > Hi, > > Please review this change to store the original values of Min- and > MaxHeapFreeRatio. > > This change also include some makefile changes to make it possible to > override some variables in the make files. This is needed in preparation > for the code that will update the Min/MaxHeapFreeRatio later on. > > Webrev: http://cr.openjdk.java.net/~jwilhelm/8055006/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8055006 > > Thanks! > /Jesper From serguei.spitsyn at oracle.com Tue Aug 19 23:52:59 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Aug 2014 16:52:59 -0700 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F3D571.7060609@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> Message-ID: <53F3E35B.5010205@oracle.com> On 8/19/14 3:53 PM, Daniel D. Daugherty wrote: > > On 8/19/14 3:39 PM, Daniel D. Daugherty wrote: >> On 8/15/14 2:18 PM, Coleen Phillimore wrote: >>> Summary: Use scratch_class to find EMCP methods for breakpoints if >>> the old methods are still running >>> >>> See bug for more details. This fix also includes a change to >>> nmethod::metadata_do() to not walk the _method multiple times (the >>> _method is added to the metadata section of the nmethod), and an >>> attempt to help the sweeper clean up these scratch_class instance >>> classes sooner. >>> >>> Tested with nsk tests, java/lang/instrument tests and jck tests >>> (which include some jvmti tests). >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8055008/ >> >> src/share/vm/oops/instanceKlass.hpp >> line 1047 // RedefineClass support >> Should be 'RedefineClasses'. >> >> line 1049: void mark_newly_obsolete_methods(Array* >> old_methods, >> int emcp_method_count); >> The 'obsolete' part of the function name does not match with >> the 'emcp' part of the parameter name. EMCP methods are 'old', >> but not 'obsolete'. >> >> Update: OK, I think I get it. We want to mark methods that are >> newly transitioning from EMCP -> obsolete and the >> emcp_method_count >> parameter tells us if there is any work to do. >> >> src/share/vm/oops/instanceKlass.cpp >> line 3023: } // pvw is cleaned up >> 'pvw' no longer exists so comment is stale. >> >> line 3455: // check the previous versions array >> This comment should move above this line: >> >> 3453 for (; pv_node != NULL; ) { >> >> and 'array' should change to 'list'. >> >> Sorry for the bad placement of the original comment. >> >> line 3463: last->link_previous_versions(pv_node); >> So now we've overwritten the previous value of >> last->previous_versions. How does that InstanceKlass >> get freed? Maybe a short comment? >> >> line 3484: // Mark the emcp method as obsolete if it's not executing >> I'm not sure about whether this is a good idea. When we had a >> redefine make a method obsolete before, we knew that we could >> make all older but previously EMCP methods obsolete because >> the new method version did make them obsolete. >> >> With this optimization, we're saying that no thread is executing >> the method so we're going to make it obsolete even if the >> current >> redefine did not do so. I worry about a method call that is in >> the early stages of assembling the call stack being caught >> calling a method that is now obsolete but not because of a >> redefine made it obsolete. Just FYI, one of the tracing flags >> catches unexpected calls to obsolete methods today and it does >> catch the current system's legitimate race. > > JVM/TI has an isMethodObsolete() API: > > jvmtiError > IsMethodObsolete(jvmtiEnv* env, > jmethodID method, > jboolean* is_obsolete_ptr) > > It would be possible for an agent to observe a method changing from > not obsolete to obsolete when that's not expected. I suspect that > this would be a spec violation. I agree that this looks like a spec violation. The emcp methods by definition are non-obsolete, or in opposite, the obsolete methods are non-emcp: http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#obsoleteMethods Old method versions may become obsolete, not emcp: http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#RedefineClasses But maybe I'm missing something... Thanks, Serguei > > Dan > > >> >> line 3527: // clear out any matching EMCP method entries the hard >> way. >> Perhaps "mark" instead of "clear out"? >> >> old line 3659: if (!method->is_obsolete() && >> new line 3546: if (method->is_emcp() && >> The old code is correct. The old code won't remark a method that >> was already made obsolete so there won't be more than one trace >> message for that operation. >> >> line 3581: // stack, and set emcp methods on the stack. >> In comments 'emcp' should be 'EMCP'. We did not do that in the >> code because of HotSpot's variable name style. >> >> Also, set what on EMCP methods on the stack? >> >> line 3591: ... If emcp method from >> line 3592: // a previous redefinition may be made obsolete by >> this redefinition. >> Having trouble parsing this comment. >> >> src/share/vm/oops/method.hpp >> line 693: // emcp methods (equivalent method except constant pool >> is different) >> line 694: // that are old but not obsolete or deleted. >> Perhaps: >> >> // EMCP methods are old but not obsolete or deleted. Equivalent >> // Modulo Constant Pool means the method is equivalent except >> // the constant pool and instructions that access the constant >> // pool might be different. >> >> src/share/vm/prims/jvmtiImpl.cpp >> No comments. >> >> src/share/vm/prims/jvmtiRedefineClasses.cpp >> No comments. >> >> src/share/vm/code/nmethod.cpp >> So in the original code f(_method) was being called two extra >> times? (once in the while-loop and once at the end) So I'm >> guessing that f(_method) is properly called when the rest of >> the metadata is handled in the nmethod (line 2085)? >> >> src/share/vm/memory/universe.cpp >> No comments (resisting 'The Walking Dead' ref...) >> >> test/runtime/RedefineTests/RedefineFinalizer.java >> No comments. >> >> test/runtime/RedefineTests/RedefineRunningMethods.java >> line 44: " while (!stop) { count2++; }" + >> line 53: while (!stop) { count1++; } >> line 56: while (!stop) { count2++; } >> >> These may not behave well on OSes with bad threading >> models. You might want to add a helper function that >> sleeps for 10ms and have each of these loops call it >> so the test more well behaved. >> >> Dan >> >> >>> bug link https://bugs.openjdk.java.net/browse/JDK-8055008 >>> >>> Thanks, >>> Coleen >> >> > From jesper.wilhelmsson at oracle.com Wed Aug 20 05:55:35 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 20 Aug 2014 07:55:35 +0200 Subject: RFR: 8055006 - Store original value of Min/MaxHeapFreeRatio In-Reply-To: <53F3E08E.40004@oracle.com> References: <53F365E7.9050305@oracle.com> <53F3E08E.40004@oracle.com> Message-ID: <0363B287-DAF2-4EF0-B7EE-6A57B3838B70@oracle.com> Thanks David! /Jesper > 20 aug 2014 kl. 01:41 skrev David Holmes : > > Ok. > > Thanks, > David > >> On 20/08/2014 12:57 AM, Jesper Wilhelmsson wrote: >> Hi, >> >> Please review this change to store the original values of Min- and >> MaxHeapFreeRatio. >> >> This change also include some makefile changes to make it possible to >> override some variables in the make files. This is needed in preparation >> for the code that will update the Min/MaxHeapFreeRatio later on. >> >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8055006/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8055006 >> >> Thanks! >> /Jesper From erik.joelsson at oracle.com Wed Aug 20 08:40:04 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 Aug 2014 10:40:04 +0200 Subject: RFR: 8055006 - Store original value of Min/MaxHeapFreeRatio In-Reply-To: <53F365E7.9050305@oracle.com> References: <53F365E7.9050305@oracle.com> Message-ID: <53F45EE4.4030404@oracle.com> Looks good to me. /Erik On 2014-08-19 16:57, Jesper Wilhelmsson wrote: > Hi, > > Please review this change to store the original values of Min- and > MaxHeapFreeRatio. > > This change also include some makefile changes to make it possible to > override some variables in the make files. This is needed in > preparation for the code that will update the Min/MaxHeapFreeRatio > later on. > > Webrev: http://cr.openjdk.java.net/~jwilhelm/8055006/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8055006 > > Thanks! > /Jesper From erik.helin at oracle.com Wed Aug 20 10:27:25 2014 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 20 Aug 2014 12:27:25 +0200 Subject: RFR: 8049599: MetaspaceGC::_capacity_until_GC can overflow Message-ID: <53F4780D.9040005@oracle.com> Hi all, this patch fixes a problem where Metaspace::_capacityUntilGC can overflow ("wrap around"). Since _capacityUntilGC is treated as a size_t everywhere it used, we won't calculate with negative numbers, but an eventual wrap around will still cause unnecessary GCs. The problem is solved by detecting an eventual wrap around in Metaspace::incCapacityUntilGC. The overflow check means that _capacityUntilGC now must be updated with a CAS. If the CAS fails more than five times due to contention, no update will be done, because this means that other threads must have incremented _capacityUntilGC (it is decremented only during a safepoint). This also means that a thread calling incCapacityUntilGC might have "its" requested memory "stolen" by another thread, but incCapacityUntilGC has never given any fairness guarantees. The patch also adds two functions to the WhiteBox API to be able to update and read Metaspace::_capacityUntilGC from a JTREG test. Bug: https://bugs.openjdk.java.net/browse/JDK-8049599 Webrev: http://cr.openjdk.java.net/~ehelin/8049599/webrev.00/ Testing: - JPRT - Aurora ad-hoc testing (on all platforms, both 32-bit and 64-bit): - Kitchensink, runThese and Dacapo - JTREG tests - Parallel Class Loading testlist - GC, runtime and compiler testlists - OOM and stress testlists - Running newly added JTREG test Thanks, Erik From lois.foltan at oracle.com Wed Aug 20 11:38:21 2014 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 20 Aug 2014 07:38:21 -0400 Subject: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams In-Reply-To: <038701cfbc06$c1e63930$45b2ab90$@oracle.com> References: <038701cfbc06$c1e63930$45b2ab90$@oracle.com> Message-ID: <53F488AD.8090009@oracle.com> Hi Christian, This looks good! Lois On 8/19/2014 7:39 PM, Christian Tornqvist wrote: > Hi everyone, > > > > This change adds /homeparams > (http://msdn.microsoft.com/en-us/library/6exwh0y6.aspx) to compiler flags > when building fastdebug on Windows x64. This causes the compiler to generate > code to spill the first 4 arguments to the stack (they're normally only > passed in registers), which should make it easier to debug. > > > > I also changed the ProjectCreator to enable building with this using Visual > Studio. The size of jvm.dll increases with about 3% (about 504k increase). > > > > Verified that it builds correctly using Visual Studio and JPRT, the > generation of the spill code has been verified by comparing prologue code > for several functions in the JVM with/without using /homeparams. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8027480 > > > > Thanks, > > Christian > > > From zhengyu.gu at oracle.com Wed Aug 20 13:30:33 2014 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 20 Aug 2014 09:30:33 -0400 Subject: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams In-Reply-To: <038701cfbc06$c1e63930$45b2ab90$@oracle.com> References: <038701cfbc06$c1e63930$45b2ab90$@oracle.com> Message-ID: <53F4A2F9.9030903@oracle.com> Looks good to me. -Zhengyu On 8/19/2014 7:39 PM, Christian Tornqvist wrote: > Hi everyone, > > > > This change adds /homeparams > (http://msdn.microsoft.com/en-us/library/6exwh0y6.aspx) to compiler flags > when building fastdebug on Windows x64. This causes the compiler to generate > code to spill the first 4 arguments to the stack (they're normally only > passed in registers), which should make it easier to debug. > > > > I also changed the ProjectCreator to enable building with this using Visual > Studio. The size of jvm.dll increases with about 3% (about 504k increase). > > > > Verified that it builds correctly using Visual Studio and JPRT, the > generation of the spill code has been verified by comparing prologue code > for several functions in the JVM with/without using /homeparams. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8027480 > > > > Thanks, > > Christian > > > From christian.tornqvist at oracle.com Wed Aug 20 13:46:00 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 20 Aug 2014 09:46:00 -0400 Subject: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams In-Reply-To: <038701cfbc06$c1e63930$45b2ab90$@oracle.com> References: <038701cfbc06$c1e63930$45b2ab90$@oracle.com> Message-ID: <045201cfbc7d$14292b50$3c7b81f0$@oracle.com> Adding build-dev as well -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Christian Tornqvist Sent: Tuesday, August 19, 2014 7:39 PM To: hotspot-dev at openjdk.java.net Subject: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams Hi everyone, This change adds /homeparams (http://msdn.microsoft.com/en-us/library/6exwh0y6.aspx) to compiler flags when building fastdebug on Windows x64. This causes the compiler to generate code to spill the first 4 arguments to the stack (they're normally only passed in registers), which should make it easier to debug. I also changed the ProjectCreator to enable building with this using Visual Studio. The size of jvm.dll increases with about 3% (about 504k increase). Verified that it builds correctly using Visual Studio and JPRT, the generation of the spill code has been verified by comparing prologue code for several functions in the JVM with/without using /homeparams. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8027480 Thanks, Christian From daniel.daugherty at oracle.com Wed Aug 20 13:47:30 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Aug 2014 07:47:30 -0600 Subject: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams In-Reply-To: <038701cfbc06$c1e63930$45b2ab90$@oracle.com> References: <038701cfbc06$c1e63930$45b2ab90$@oracle.com> Message-ID: <53F4A6F2.5050609@oracle.com> > http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.00/ General Comment The MSDN note says: > /homeparams does imply a performance disadvantage, because it > does require a cycle to load the register parameters on to the stack. Do we have any idea how much of a change? Do we care? I'm presuming the increased debuggability is worth it. make/windows/makefiles/vm.make line 38: !else line 39: CXX_FLAGS=$(CXX_FLAGS) /D "ASSERT" /homeparams line 40: !endif The above block will also apply to an "ia64" build. We don't support that anymore, but I don't know if any licensees support it. src/share/tools/ProjectCreator/BuildConfig.java No comments. src/share/tools/ProjectCreator/WinGammaPlatformVC10.java line 373: if(!platformName.equals("Win32")) { line 374: addAttr(rv, "AdditionalOptions", "/homeparams"); The above block will also apply to an "ia64" build. src/share/tools/ProjectCreator/WinGammaPlatformVC7.java src/share/tools/ProjectCreator/WinGammaPlatformVC8.java Do we need to do anything about the new, but unused platform to make lint-like tools not squawk? Thumbs up. Dan On 8/19/14 5:39 PM, Christian Tornqvist wrote: > Hi everyone, > > > > This change adds /homeparams > (http://msdn.microsoft.com/en-us/library/6exwh0y6.aspx) to compiler flags > when building fastdebug on Windows x64. This causes the compiler to generate > code to spill the first 4 arguments to the stack (they're normally only > passed in registers), which should make it easier to debug. > > > > I also changed the ProjectCreator to enable building with this using Visual > Studio. The size of jvm.dll increases with about 3% (about 504k increase). > > > > Verified that it builds correctly using Visual Studio and JPRT, the > generation of the spill code has been verified by comparing prologue code > for several functions in the JVM with/without using /homeparams. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8027480 > > > > Thanks, > > Christian > > > From christian.tornqvist at oracle.com Wed Aug 20 14:49:30 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 20 Aug 2014 10:49:30 -0400 Subject: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams In-Reply-To: <53F4A6F2.5050609@oracle.com> References: <038701cfbc06$c1e63930$45b2ab90$@oracle.com> <53F4A6F2.5050609@oracle.com> Message-ID: <04b101cfbc85$f4089870$dc19c950$@oracle.com> > Do we have any idea how much of a change? Do we care? I'm presuming the increased debuggability is worth it. It adds 0-4 additional stack movs in function prologue code which should have a very low impact, it's only on debug/fastdebug builds. > The above block will also apply to an "ia64" build. We don't support that anymore, but I don't know if any licensees support it. I've changed the checks in vm.make and WinGammaPlatformVC10.java > Do we need to do anything about the new, but unused platform to make lint-like tools not squawk? I'll open a new bug to clean up the VC7/8/9 files in ProjectCreator. New webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.01/ Thanks, Christian -----Original Message----- From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] Sent: Wednesday, August 20, 2014 9:48 AM To: Christian Tornqvist Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams > http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.00/ General Comment The MSDN note says: > /homeparams does imply a performance disadvantage, because it > does require a cycle to load the register parameters on to the stack. Do we have any idea how much of a change? Do we care? I'm presuming the increased debuggability is worth it. make/windows/makefiles/vm.make line 38: !else line 39: CXX_FLAGS=$(CXX_FLAGS) /D "ASSERT" /homeparams line 40: !endif The above block will also apply to an "ia64" build. We don't support that anymore, but I don't know if any licensees support it. src/share/tools/ProjectCreator/BuildConfig.java No comments. src/share/tools/ProjectCreator/WinGammaPlatformVC10.java line 373: if(!platformName.equals("Win32")) { line 374: addAttr(rv, "AdditionalOptions", "/homeparams"); The above block will also apply to an "ia64" build. src/share/tools/ProjectCreator/WinGammaPlatformVC7.java src/share/tools/ProjectCreator/WinGammaPlatformVC8.java Do we need to do anything about the new, but unused platform to make lint-like tools not squawk? Thumbs up. Dan On 8/19/14 5:39 PM, Christian Tornqvist wrote: > Hi everyone, > > > > This change adds /homeparams > (http://msdn.microsoft.com/en-us/library/6exwh0y6.aspx) to compiler > flags when building fastdebug on Windows x64. This causes the compiler > to generate code to spill the first 4 arguments to the stack (they're > normally only passed in registers), which should make it easier to debug. > > > > I also changed the ProjectCreator to enable building with this using > Visual Studio. The size of jvm.dll increases with about 3% (about 504k increase). > > > > Verified that it builds correctly using Visual Studio and JPRT, the > generation of the spill code has been verified by comparing prologue > code for several functions in the JVM with/without using /homeparams. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8027480 > > > > Thanks, > > Christian > > > From daniel.daugherty at oracle.com Wed Aug 20 15:17:11 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Aug 2014 09:17:11 -0600 Subject: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams In-Reply-To: <04b101cfbc85$f4089870$dc19c950$@oracle.com> References: <038701cfbc06$c1e63930$45b2ab90$@oracle.com> <53F4A6F2.5050609@oracle.com> <04b101cfbc85$f4089870$dc19c950$@oracle.com> Message-ID: <53F4BBF7.2050509@oracle.com> On 8/20/14 8:49 AM, Christian Tornqvist wrote: >> Do we have any idea how much of a change? Do we care? I'm presuming the > increased debuggability is worth it. > > It adds 0-4 additional stack movs in function prologue code which should > have a very low impact, it's only on debug/fastdebug builds. I missed that this was a non-RELEASE build change in my original review. These two blurbs from the MSDN note: > However, by default in a release build, the register parameters > will not be written to the stack, into the space that is already > provided for the parameters. This makes it difficult to debug an > optimized (release) build of your program. and > In a debug build, the stack is always populated with parameters > passed in registers. indicate that we shouldn't need this change in our debug/fastdebug builds. However, you looked at the generated prologue code before and after turning on this option right? Does this mean that the MSDN note is not correct for the way that we do debug and fastdebug builds? We might have some option enabled that prevents the default /homeparams behavior from working... Dan > >> The above block will also apply to an "ia64" build. We don't support that > anymore, but I don't know if any licensees support it. > > I've changed the checks in vm.make and WinGammaPlatformVC10.java > >> Do we need to do anything about the new, but unused platform to make > lint-like tools not squawk? > > I'll open a new bug to clean up the VC7/8/9 files in ProjectCreator. > > New webrev: > http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.01/ > > Thanks, > Christian > > -----Original Message----- > From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] > Sent: Wednesday, August 20, 2014 9:48 AM > To: Christian Tornqvist > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR(S): 8027480 - Build Windows x64 fastdebug builds using > /homeparams > > > http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.00/ > > General Comment > > The MSDN note says: > > > /homeparams does imply a performance disadvantage, because it > does > require a cycle to load the register parameters on to the stack. > > Do we have any idea how much of a change? Do we care? I'm presuming the > increased debuggability is worth it. > > make/windows/makefiles/vm.make > line 38: !else > line 39: CXX_FLAGS=$(CXX_FLAGS) /D "ASSERT" /homeparams > line 40: !endif > The above block will also apply to an "ia64" build. > We don't support that anymore, but I don't know if > any licensees support it. > > src/share/tools/ProjectCreator/BuildConfig.java > No comments. > > src/share/tools/ProjectCreator/WinGammaPlatformVC10.java > line 373: if(!platformName.equals("Win32")) { > line 374: addAttr(rv, "AdditionalOptions", "/homeparams"); > The above block will also apply to an "ia64" build. > > src/share/tools/ProjectCreator/WinGammaPlatformVC7.java > src/share/tools/ProjectCreator/WinGammaPlatformVC8.java > Do we need to do anything about the new, but unused > platform to make lint-like tools not squawk? > > Thumbs up. > > Dan > > > On 8/19/14 5:39 PM, Christian Tornqvist wrote: >> Hi everyone, >> >> >> >> This change adds /homeparams >> (http://msdn.microsoft.com/en-us/library/6exwh0y6.aspx) to compiler >> flags when building fastdebug on Windows x64. This causes the compiler >> to generate code to spill the first 4 arguments to the stack (they're >> normally only passed in registers), which should make it easier to debug. >> >> >> >> I also changed the ProjectCreator to enable building with this using >> Visual Studio. The size of jvm.dll increases with about 3% (about 504k > increase). >> >> >> Verified that it builds correctly using Visual Studio and JPRT, the >> generation of the spill code has been verified by comparing prologue >> code for several functions in the JVM with/without using /homeparams. >> >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.00/ >> >> >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8027480 >> >> >> >> Thanks, >> >> Christian >> >> >> > From coleen.phillimore at oracle.com Wed Aug 20 15:29:36 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 20 Aug 2014 11:29:36 -0400 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F3C426.9080408@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> Message-ID: <53F4BEE0.60107@oracle.com> Dan, Thanks for taking the time to review this! On 8/19/14, 5:39 PM, Daniel D. Daugherty wrote: > On 8/15/14 2:18 PM, Coleen Phillimore wrote: >> Summary: Use scratch_class to find EMCP methods for breakpoints if >> the old methods are still running >> >> See bug for more details. This fix also includes a change to >> nmethod::metadata_do() to not walk the _method multiple times (the >> _method is added to the metadata section of the nmethod), and an >> attempt to help the sweeper clean up these scratch_class instance >> classes sooner. >> >> Tested with nsk tests, java/lang/instrument tests and jck tests >> (which include some jvmti tests). >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8055008/ > > src/share/vm/oops/instanceKlass.hpp > line 1047 // RedefineClass support > Should be 'RedefineClasses'. Yes, fixed. > > line 1049: void mark_newly_obsolete_methods(Array* > old_methods, > int emcp_method_count); > The 'obsolete' part of the function name does not match with > the 'emcp' part of the parameter name. EMCP methods are 'old', > but not 'obsolete'. > > Update: OK, I think I get it. We want to mark methods that are > newly transitioning from EMCP -> obsolete and the > emcp_method_count > parameter tells us if there is any work to do. Yes, it's not used to figure out which ones are EMCP anymore, just to know if there are any. > > src/share/vm/oops/instanceKlass.cpp > line 3023: } // pvw is cleaned up > 'pvw' no longer exists so comment is stale. fixed. > > line 3455: // check the previous versions array > This comment should move above this line: > > 3453 for (; pv_node != NULL; ) { > > and 'array' should change to 'list'. > > Sorry for the bad placement of the original comment. ok. > > line 3463: last->link_previous_versions(pv_node); > So now we've overwritten the previous value of > last->previous_versions. How does that InstanceKlass > get freed? Maybe a short comment? // The previous version InstanceKlass is on the ClassLoaderData deallocate list // so will be deallocated during the next phase of class unloading. > > line 3484: // Mark the emcp method as obsolete if it's not executing > I'm not sure about whether this is a good idea. When we had a > redefine make a method obsolete before, we knew that we could > make all older but previously EMCP methods obsolete because > the new method version did make them obsolete. > > With this optimization, we're saying that no thread is executing > the method so we're going to make it obsolete even if the current > redefine did not do so. I worry about a method call that is in > the early stages of assembling the call stack being caught > calling a method that is now obsolete but not because of a > redefine made it obsolete. Just FYI, one of the tracing flags > catches unexpected calls to obsolete methods today and it does > catch the current system's legitimate race. I need to study this (I think your next email is about this too). I tried to preserve the behavior before but maybe I didn't. > > line 3527: // clear out any matching EMCP method entries the hard > way. > Perhaps "mark" instead of "clear out"? > > old line 3659: if (!method->is_obsolete() && > new line 3546: if (method->is_emcp() && > The old code is correct. The old code won't remark a method that > was already made obsolete so there won't be more than one trace > message for that operation. Since is_emcp() means !is_obsolete && !is_deleted, so ineffect I changed that to not include the deleted methods. So I think it's equivalent and I think I have to account for deleted methods in the previous_version instanceKlasses. > > line 3581: // stack, and set emcp methods on the stack. > In comments 'emcp' should be 'EMCP'. We did not do that in the > code because of HotSpot's variable name style. Yes, I can change all emcp to EMCP - should I change the is_EMCP() function as well? > > Also, set what on EMCP methods on the stack? This comment doesn't make very much sense. How about: But I may have to rewrite it because I think your point about line 3484: // Mark the emcp method as obsolete if it's not executing > line 3591: ... If emcp method from > line 3592: // a previous redefinition may be made obsolete by this > redefinition. > Having trouble parsing this comment. // Mark newly obsolete methods in remaining previous versions. An EMCP method from // a previous redefinition may be made obsolete by this redefinition. > > src/share/vm/oops/method.hpp > line 693: // emcp methods (equivalent method except constant pool > is different) > line 694: // that are old but not obsolete or deleted. > Perhaps: > > // EMCP methods are old but not obsolete or deleted. Equivalent > // Modulo Constant Pool means the method is equivalent except > // the constant pool and instructions that access the constant > // pool might be different. > Your comment is better, thanks! It's nice to have that comment there. > src/share/vm/prims/jvmtiImpl.cpp > No comments. > > src/share/vm/prims/jvmtiRedefineClasses.cpp > No comments. > > src/share/vm/code/nmethod.cpp > So in the original code f(_method) was being called two extra > times? (once in the while-loop and once at the end) So I'm > guessing that f(_method) is properly called when the rest of > the metadata is handled in the nmethod (line 2085)? Yes. It is added to the metadata_section so didn't need an extra walk. This is only used for checking code and redefine classes, so it's safe to remove this. > > src/share/vm/memory/universe.cpp > No comments (resisting 'The Walking Dead' ref...) Yeah the sematics for zombie nmethods is chilling. > > test/runtime/RedefineTests/RedefineFinalizer.java > No comments. > > test/runtime/RedefineTests/RedefineRunningMethods.java > line 44: " while (!stop) { count2++; }" + > line 53: while (!stop) { count1++; } > line 56: while (!stop) { count2++; } > > These may not behave well on OSes with bad threading > models. You might want to add a helper function that > sleeps for 10ms and have each of these loops call it > so the test more well behaved. I don't like adding sleeps but you are right, we might not be able to interrupt these threads. I'll answer your other mail also. I think that you are right, we may be making EMCP methods obsolete too soon. Thanks for the spending time and thinking hard about this. This is some complicated code. Coleen > > Dan > > >> bug link https://bugs.openjdk.java.net/browse/JDK-8055008 >> >> Thanks, >> Coleen > From christian.tornqvist at oracle.com Wed Aug 20 15:48:02 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 20 Aug 2014 11:48:02 -0400 Subject: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams In-Reply-To: <53F4BBF7.2050509@oracle.com> References: <038701cfbc06$c1e63930$45b2ab90$@oracle.com> <53F4A6F2.5050609@oracle.com> <04b101cfbc85$f4089870$dc19c950$@oracle.com> <53F4BBF7.2050509@oracle.com> Message-ID: <04d801cfbc8e$20a3d720$61eb8560$@oracle.com> > indicate that we shouldn't need this change in our debug/fastdebug builds. However, you looked at the generated prologue code before and after turning on this option right? Our fastdebug builds are compiled with /O2 which doesn't spill the parameters onto the stack, our debug builds (with /Od) will do this so passing /homeparams there is a no-op. Here is a look at the prologue code for ClassFileParser::parse_constant_pool_entries() before /homeparams: mov dword ptr [rsp+10h],edx push rbp push rsi and here is with /homeparams: mov qword ptr [rsp+18h],r8 mov dword ptr [rsp+10h],edx mov qword ptr [rsp+8],rcx push rbp push rsi Thanks, Christian -----Original Message----- From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] Sent: Wednesday, August 20, 2014 11:17 AM To: Christian Tornqvist Cc: hotspot-dev at openjdk.java.net; build-dev at openjdk.java.net Subject: Re: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams On 8/20/14 8:49 AM, Christian Tornqvist wrote: >> Do we have any idea how much of a change? Do we care? I'm presuming >> the > increased debuggability is worth it. > > It adds 0-4 additional stack movs in function prologue code which > should have a very low impact, it's only on debug/fastdebug builds. I missed that this was a non-RELEASE build change in my original review. These two blurbs from the MSDN note: > However, by default in a release build, the register parameters > will not be written to the stack, into the space that is already > provided for the parameters. This makes it difficult to debug an > optimized (release) build of your program. and > In a debug build, the stack is always populated with parameters > passed in registers. indicate that we shouldn't need this change in our debug/fastdebug builds. However, you looked at the generated prologue code before and after turning on this option right? Does this mean that the MSDN note is not correct for the way that we do debug and fastdebug builds? We might have some option enabled that prevents the default /homeparams behavior from working... Dan > >> The above block will also apply to an "ia64" build. We don't support >> that > anymore, but I don't know if any licensees support it. > > I've changed the checks in vm.make and WinGammaPlatformVC10.java > >> Do we need to do anything about the new, but unused platform to make > lint-like tools not squawk? > > I'll open a new bug to clean up the VC7/8/9 files in ProjectCreator. > > New webrev: > http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.01/ > > Thanks, > Christian > > -----Original Message----- > From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] > Sent: Wednesday, August 20, 2014 9:48 AM > To: Christian Tornqvist > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR(S): 8027480 - Build Windows x64 fastdebug builds > using /homeparams > > > http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.00/ > > General Comment > > The MSDN note says: > > > /homeparams does imply a performance disadvantage, because it > > does require a cycle to load the register parameters on to the stack. > > Do we have any idea how much of a change? Do we care? I'm presuming > the increased debuggability is worth it. > > make/windows/makefiles/vm.make > line 38: !else > line 39: CXX_FLAGS=$(CXX_FLAGS) /D "ASSERT" /homeparams > line 40: !endif > The above block will also apply to an "ia64" build. > We don't support that anymore, but I don't know if > any licensees support it. > > src/share/tools/ProjectCreator/BuildConfig.java > No comments. > > src/share/tools/ProjectCreator/WinGammaPlatformVC10.java > line 373: if(!platformName.equals("Win32")) { > line 374: addAttr(rv, "AdditionalOptions", "/homeparams"); > The above block will also apply to an "ia64" build. > > src/share/tools/ProjectCreator/WinGammaPlatformVC7.java > src/share/tools/ProjectCreator/WinGammaPlatformVC8.java > Do we need to do anything about the new, but unused > platform to make lint-like tools not squawk? > > Thumbs up. > > Dan > > > On 8/19/14 5:39 PM, Christian Tornqvist wrote: >> Hi everyone, >> >> >> >> This change adds /homeparams >> (http://msdn.microsoft.com/en-us/library/6exwh0y6.aspx) to compiler >> flags when building fastdebug on Windows x64. This causes the >> compiler to generate code to spill the first 4 arguments to the stack >> (they're normally only passed in registers), which should make it easier to debug. >> >> >> >> I also changed the ProjectCreator to enable building with this using >> Visual Studio. The size of jvm.dll increases with about 3% (about >> 504k > increase). >> >> >> Verified that it builds correctly using Visual Studio and JPRT, the >> generation of the spill code has been verified by comparing prologue >> code for several functions in the JVM with/without using /homeparams. >> >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.00/ >> >> >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8027480 >> >> >> >> Thanks, >> >> Christian >> >> >> > From coleen.phillimore at oracle.com Wed Aug 20 15:54:05 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 20 Aug 2014 11:54:05 -0400 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F3E35B.5010205@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> Message-ID: <53F4C49D.4070404@oracle.com> Hi, it appears that my code is wrong and maybe the existing code is wrong also. I have a spec question below. On 8/19/14, 7:52 PM, serguei.spitsyn at oracle.com wrote: > On 8/19/14 3:53 PM, Daniel D. Daugherty wrote: >> >> On 8/19/14 3:39 PM, Daniel D. Daugherty wrote: >>> On 8/15/14 2:18 PM, Coleen Phillimore wrote: >>>> Summary: Use scratch_class to find EMCP methods for breakpoints if >>>> the old methods are still running >>>> >>>> See bug for more details. This fix also includes a change to >>>> nmethod::metadata_do() to not walk the _method multiple times (the >>>> _method is added to the metadata section of the nmethod), and an >>>> attempt to help the sweeper clean up these scratch_class instance >>>> classes sooner. >>>> >>>> Tested with nsk tests, java/lang/instrument tests and jck tests >>>> (which include some jvmti tests). >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8055008/ >>> >>> src/share/vm/oops/instanceKlass.hpp >>> line 1047 // RedefineClass support >>> Should be 'RedefineClasses'. >>> >>> line 1049: void mark_newly_obsolete_methods(Array* >>> old_methods, >>> int emcp_method_count); >>> The 'obsolete' part of the function name does not match with >>> the 'emcp' part of the parameter name. EMCP methods are 'old', >>> but not 'obsolete'. >>> >>> Update: OK, I think I get it. We want to mark methods that are >>> newly transitioning from EMCP -> obsolete and the >>> emcp_method_count >>> parameter tells us if there is any work to do. >>> >>> src/share/vm/oops/instanceKlass.cpp >>> line 3023: } // pvw is cleaned up >>> 'pvw' no longer exists so comment is stale. >>> >>> line 3455: // check the previous versions array >>> This comment should move above this line: >>> >>> 3453 for (; pv_node != NULL; ) { >>> >>> and 'array' should change to 'list'. >>> >>> Sorry for the bad placement of the original comment. >>> >>> line 3463: last->link_previous_versions(pv_node); >>> So now we've overwritten the previous value of >>> last->previous_versions. How does that InstanceKlass >>> get freed? Maybe a short comment? >>> >>> line 3484: // Mark the emcp method as obsolete if it's not >>> executing >>> I'm not sure about whether this is a good idea. When we had a >>> redefine make a method obsolete before, we knew that we could >>> make all older but previously EMCP methods obsolete because >>> the new method version did make them obsolete. >>> >>> With this optimization, we're saying that no thread is >>> executing >>> the method so we're going to make it obsolete even if the >>> current >>> redefine did not do so. I worry about a method call that is in >>> the early stages of assembling the call stack being caught >>> calling a method that is now obsolete but not because of a >>> redefine made it obsolete. Just FYI, one of the tracing flags >>> catches unexpected calls to obsolete methods today and it does >>> catch the current system's legitimate race. >> >> JVM/TI has an isMethodObsolete() API: >> >> jvmtiError >> IsMethodObsolete(jvmtiEnv* env, >> jmethodID method, >> jboolean* is_obsolete_ptr) >> >> It would be possible for an agent to observe a method changing from >> not obsolete to obsolete when that's not expected. I suspect that >> this would be a spec violation. > > I agree that this looks like a spec violation. > The emcp methods by definition are non-obsolete, > or in opposite, the obsolete methods are non-emcp: > http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#obsoleteMethods > > Old method versions may become obsolete, not emcp: > http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#RedefineClasses > > But maybe I'm missing something... If an EMCP method is not running, should we save it on a previous version list anyway so that we can make it obsolete if it's redefined and made obsolete? Currently we don't save previous versions of methods that are not running. We didn't before permgen elimination either. If GC didn't find the EMCP method, we would remove the entry. Thanks, Coleen > > > Thanks, > Serguei > >> >> Dan >> >> >>> >>> line 3527: // clear out any matching EMCP method entries the >>> hard way. >>> Perhaps "mark" instead of "clear out"? >>> >>> old line 3659: if (!method->is_obsolete() && >>> new line 3546: if (method->is_emcp() && >>> The old code is correct. The old code won't remark a method >>> that >>> was already made obsolete so there won't be more than one trace >>> message for that operation. >>> >>> line 3581: // stack, and set emcp methods on the stack. >>> In comments 'emcp' should be 'EMCP'. We did not do that in the >>> code because of HotSpot's variable name style. >>> >>> Also, set what on EMCP methods on the stack? >>> >>> line 3591: ... If emcp method from >>> line 3592: // a previous redefinition may be made obsolete by >>> this redefinition. >>> Having trouble parsing this comment. >>> >>> src/share/vm/oops/method.hpp >>> line 693: // emcp methods (equivalent method except constant >>> pool is different) >>> line 694: // that are old but not obsolete or deleted. >>> Perhaps: >>> >>> // EMCP methods are old but not obsolete or deleted. Equivalent >>> // Modulo Constant Pool means the method is equivalent except >>> // the constant pool and instructions that access the constant >>> // pool might be different. >>> >>> src/share/vm/prims/jvmtiImpl.cpp >>> No comments. >>> >>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>> No comments. >>> >>> src/share/vm/code/nmethod.cpp >>> So in the original code f(_method) was being called two extra >>> times? (once in the while-loop and once at the end) So I'm >>> guessing that f(_method) is properly called when the rest of >>> the metadata is handled in the nmethod (line 2085)? >>> >>> src/share/vm/memory/universe.cpp >>> No comments (resisting 'The Walking Dead' ref...) >>> >>> test/runtime/RedefineTests/RedefineFinalizer.java >>> No comments. >>> >>> test/runtime/RedefineTests/RedefineRunningMethods.java >>> line 44: " while (!stop) { count2++; }" + >>> line 53: while (!stop) { count1++; } >>> line 56: while (!stop) { count2++; } >>> >>> These may not behave well on OSes with bad threading >>> models. You might want to add a helper function that >>> sleeps for 10ms and have each of these loops call it >>> so the test more well behaved. >>> >>> Dan >>> >>> >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8055008 >>>> >>>> Thanks, >>>> Coleen >>> >>> >> > From daniel.daugherty at oracle.com Wed Aug 20 16:02:08 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Aug 2014 10:02:08 -0600 Subject: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams In-Reply-To: <04d801cfbc8e$20a3d720$61eb8560$@oracle.com> References: <038701cfbc06$c1e63930$45b2ab90$@oracle.com> <53F4A6F2.5050609@oracle.com> <04b101cfbc85$f4089870$dc19c950$@oracle.com> <53F4BBF7.2050509@oracle.com> <04d801cfbc8e$20a3d720$61eb8560$@oracle.com> Message-ID: <53F4C680.3090606@oracle.com> On 8/20/14 9:48 AM, Christian Tornqvist wrote: >> indicate that we shouldn't need this change in our debug/fastdebug builds. > However, you looked at the generated prologue code before and after turning > on this option right? > > Our fastdebug builds are compiled with /O2 which doesn't spill the > parameters onto the stack, our debug builds (with /Od) will do this so > passing /homeparams there is a no-op. > > Here is a look at the prologue code for > ClassFileParser::parse_constant_pool_entries() before /homeparams: > > mov dword ptr [rsp+10h],edx > push rbp > push rsi > > and here is with /homeparams: > > mov qword ptr [rsp+18h],r8 > mov dword ptr [rsp+10h],edx > mov qword ptr [rsp+8],rcx > push rbp > push rsi Cool. When we did the Full Debug Symbols (FDS) project, one of the things we did was try to use the same optimization and debug options with RELEASE/product builds as with fastdebug builds. Since we're generating debug info for all builds configs, we thought this was a really good design goal unless we ran into a performance issue. During the FDS project, we saw no performance change when we switched the optimization options and included the various generate-debug-info options. A long way of saying: I think you should enable /homeparams for RELEASE/product builds. :-) Dan > > Thanks, > Christian > > -----Original Message----- > From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] > Sent: Wednesday, August 20, 2014 11:17 AM > To: Christian Tornqvist > Cc: hotspot-dev at openjdk.java.net; build-dev at openjdk.java.net > Subject: Re: RFR(S): 8027480 - Build Windows x64 fastdebug builds using > /homeparams > > On 8/20/14 8:49 AM, Christian Tornqvist wrote: >>> Do we have any idea how much of a change? Do we care? I'm presuming >>> the >> increased debuggability is worth it. >> >> It adds 0-4 additional stack movs in function prologue code which >> should have a very low impact, it's only on debug/fastdebug builds. > I missed that this was a non-RELEASE build change in my original review. > > These two blurbs from the MSDN note: > > > However, by default in a release build, the register parameters > will > not be written to the stack, into the space that is already > provided for > the parameters. This makes it difficult to debug an > optimized (release) > build of your program. > > and > > > In a debug build, the stack is always populated with parameters > passed > in registers. > > indicate that we shouldn't need this change in our debug/fastdebug builds. > However, you looked at the generated prologue code before and after turning > on this option right? > > Does this mean that the MSDN note is not correct for the way that we do > debug and fastdebug builds? We might have some option enabled that prevents > the default /homeparams behavior from working... > > Dan > > >>> The above block will also apply to an "ia64" build. We don't support >>> that >> anymore, but I don't know if any licensees support it. >> >> I've changed the checks in vm.make and WinGammaPlatformVC10.java >> >>> Do we need to do anything about the new, but unused platform to make >> lint-like tools not squawk? >> >> I'll open a new bug to clean up the VC7/8/9 files in ProjectCreator. >> >> New webrev: >> http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.01/ >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] >> Sent: Wednesday, August 20, 2014 9:48 AM >> To: Christian Tornqvist >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: RFR(S): 8027480 - Build Windows x64 fastdebug builds >> using /homeparams >> >> > http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.00/ >> >> General Comment >> >> The MSDN note says: >> >> > /homeparams does imply a performance disadvantage, because it > >> does require a cycle to load the register parameters on to the stack. >> >> Do we have any idea how much of a change? Do we care? I'm presuming >> the increased debuggability is worth it. >> >> make/windows/makefiles/vm.make >> line 38: !else >> line 39: CXX_FLAGS=$(CXX_FLAGS) /D "ASSERT" /homeparams >> line 40: !endif >> The above block will also apply to an "ia64" build. >> We don't support that anymore, but I don't know if >> any licensees support it. >> >> src/share/tools/ProjectCreator/BuildConfig.java >> No comments. >> >> src/share/tools/ProjectCreator/WinGammaPlatformVC10.java >> line 373: if(!platformName.equals("Win32")) { >> line 374: addAttr(rv, "AdditionalOptions", "/homeparams"); >> The above block will also apply to an "ia64" build. >> >> src/share/tools/ProjectCreator/WinGammaPlatformVC7.java >> src/share/tools/ProjectCreator/WinGammaPlatformVC8.java >> Do we need to do anything about the new, but unused >> platform to make lint-like tools not squawk? >> >> Thumbs up. >> >> Dan >> >> >> On 8/19/14 5:39 PM, Christian Tornqvist wrote: >>> Hi everyone, >>> >>> >>> >>> This change adds /homeparams >>> (http://msdn.microsoft.com/en-us/library/6exwh0y6.aspx) to compiler >>> flags when building fastdebug on Windows x64. This causes the >>> compiler to generate code to spill the first 4 arguments to the stack >>> (they're normally only passed in registers), which should make it easier > to debug. >>> >>> >>> I also changed the ProjectCreator to enable building with this using >>> Visual Studio. The size of jvm.dll increases with about 3% (about >>> 504k >> increase). >>> >>> >>> Verified that it builds correctly using Visual Studio and JPRT, the >>> generation of the spill code has been verified by comparing prologue >>> code for several functions in the JVM with/without using /homeparams. >>> >>> >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.00/ >>> >>> >>> >>> Bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8027480 >>> >>> >>> >>> Thanks, >>> >>> Christian >>> >>> >>> > From jon.masamitsu at oracle.com Wed Aug 20 16:24:05 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 20 Aug 2014 09:24:05 -0700 Subject: RFR: 8049599: MetaspaceGC::_capacity_until_GC can overflow In-Reply-To: <53F4780D.9040005@oracle.com> References: <53F4780D.9040005@oracle.com> Message-ID: <53F4CBA5.5070803@oracle.com> Erik, I think the change is correct as you've done it but could you consider expanding the change a bit. The increment of the _capacity_until_GC is fine. However, instead of having the atomic increment try again if the CAS fails, how about putting the retry around the call to allocate() in expand_and_allocate(). Something like do { inc_capacity_until_GC(delta_bytes) result = allocate(word_size) } while result == NULL AND count <= 5 return result; Even if the increment of _capacity_until_GC fails, the allocate could still succeed and it is the allocate() that is important. I'm not sure about terminating the allocation attempt based on a count. The consequence of the failed allocation is a full GC so maybe we should do something more. Try until _capacity_until_GC hits MaxMetaspaceSize? Maybe something like that plus a higher count. Not sure. Jon On 8/20/2014 3:27 AM, Erik Helin wrote: > Hi all, > > this patch fixes a problem where Metaspace::_capacityUntilGC can > overflow ("wrap around"). Since _capacityUntilGC is treated as a > size_t everywhere it used, we won't calculate with negative numbers, > but an eventual wrap around will still cause unnecessary GCs. > > The problem is solved by detecting an eventual wrap around in > Metaspace::incCapacityUntilGC. The overflow check means that > _capacityUntilGC now must be updated with a CAS. If the CAS fails more > than five times due to contention, no update will be done, because > this means that other threads must have incremented _capacityUntilGC > (it is decremented only during a safepoint). This also means that a > thread calling incCapacityUntilGC might have "its" requested memory > "stolen" by another thread, but incCapacityUntilGC has never given any > fairness guarantees. > > The patch also adds two functions to the WhiteBox API to be able to > update and read Metaspace::_capacityUntilGC from a JTREG test. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8049599 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8049599/webrev.00/ > > Testing: > - JPRT > - Aurora ad-hoc testing (on all platforms, both 32-bit and 64-bit): > - Kitchensink, runThese and Dacapo > - JTREG tests > - Parallel Class Loading testlist > - GC, runtime and compiler testlists > - OOM and stress testlists > - Running newly added JTREG test > > Thanks, > Erik From christian.tornqvist at oracle.com Wed Aug 20 17:05:02 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 20 Aug 2014 13:05:02 -0400 Subject: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams In-Reply-To: <53F4C680.3090606@oracle.com> References: <038701cfbc06$c1e63930$45b2ab90$@oracle.com> <53F4A6F2.5050609@oracle.com> <04b101cfbc85$f4089870$dc19c950$@oracle.com> <53F4BBF7.2050509@oracle.com> <04d801cfbc8e$20a3d720$61eb8560$@oracle.com> <53F4C680.3090606@oracle.com> Message-ID: <053c01cfbc98$e2a10cd0$a7e32670$@oracle.com> I talked to Staffan Friberg (perf tech lead) about enabling this in a release builds and this is his opinion: "For /homeparams I think enable it now in fastdebug, let's use it for a while and understand home much of a benefit it is for debugging. If it is a huge help let's consider it for release, but that will require a lot of performance testing before commiting" I agree with Staffan and think we should only enable it in fastdebug builds for now. Thanks, Christian -----Original Message----- From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] Sent: Wednesday, August 20, 2014 12:02 PM To: Christian Tornqvist Cc: hotspot-dev at openjdk.java.net; build-dev at openjdk.java.net Subject: Re: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams On 8/20/14 9:48 AM, Christian Tornqvist wrote: >> indicate that we shouldn't need this change in our debug/fastdebug builds. > However, you looked at the generated prologue code before and after > turning on this option right? > > Our fastdebug builds are compiled with /O2 which doesn't spill the > parameters onto the stack, our debug builds (with /Od) will do this so > passing /homeparams there is a no-op. > > Here is a look at the prologue code for > ClassFileParser::parse_constant_pool_entries() before /homeparams: > > mov dword ptr [rsp+10h],edx > push rbp > push rsi > > and here is with /homeparams: > > mov qword ptr [rsp+18h],r8 > mov dword ptr [rsp+10h],edx > mov qword ptr [rsp+8],rcx > push rbp > push rsi Cool. When we did the Full Debug Symbols (FDS) project, one of the things we did was try to use the same optimization and debug options with RELEASE/product builds as with fastdebug builds. Since we're generating debug info for all builds configs, we thought this was a really good design goal unless we ran into a performance issue. During the FDS project, we saw no performance change when we switched the optimization options and included the various generate-debug-info options. A long way of saying: I think you should enable /homeparams for RELEASE/product builds. :-) Dan > > Thanks, > Christian > > -----Original Message----- > From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] > Sent: Wednesday, August 20, 2014 11:17 AM > To: Christian Tornqvist > Cc: hotspot-dev at openjdk.java.net; build-dev at openjdk.java.net > Subject: Re: RFR(S): 8027480 - Build Windows x64 fastdebug builds > using /homeparams > > On 8/20/14 8:49 AM, Christian Tornqvist wrote: >>> Do we have any idea how much of a change? Do we care? I'm presuming >>> the >> increased debuggability is worth it. >> >> It adds 0-4 additional stack movs in function prologue code which >> should have a very low impact, it's only on debug/fastdebug builds. > I missed that this was a non-RELEASE build change in my original review. > > These two blurbs from the MSDN note: > > > However, by default in a release build, the register parameters > > will not be written to the stack, into the space that is already > > provided for the parameters. This makes it difficult to debug an > > optimized (release) build of your program. > > and > > > In a debug build, the stack is always populated with parameters > > passed in registers. > > indicate that we shouldn't need this change in our debug/fastdebug builds. > However, you looked at the generated prologue code before and after > turning on this option right? > > Does this mean that the MSDN note is not correct for the way that we > do debug and fastdebug builds? We might have some option enabled that > prevents the default /homeparams behavior from working... > > Dan > > >>> The above block will also apply to an "ia64" build. We don't support >>> that >> anymore, but I don't know if any licensees support it. >> >> I've changed the checks in vm.make and WinGammaPlatformVC10.java >> >>> Do we need to do anything about the new, but unused platform to >>> make >> lint-like tools not squawk? >> >> I'll open a new bug to clean up the VC7/8/9 files in ProjectCreator. >> >> New webrev: >> http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.01/ >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] >> Sent: Wednesday, August 20, 2014 9:48 AM >> To: Christian Tornqvist >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: RFR(S): 8027480 - Build Windows x64 fastdebug builds >> using /homeparams >> >> > http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.00/ >> >> General Comment >> >> The MSDN note says: >> >> > /homeparams does imply a performance disadvantage, because it > >> does require a cycle to load the register parameters on to the stack. >> >> Do we have any idea how much of a change? Do we care? I'm presuming >> the increased debuggability is worth it. >> >> make/windows/makefiles/vm.make >> line 38: !else >> line 39: CXX_FLAGS=$(CXX_FLAGS) /D "ASSERT" /homeparams >> line 40: !endif >> The above block will also apply to an "ia64" build. >> We don't support that anymore, but I don't know if >> any licensees support it. >> >> src/share/tools/ProjectCreator/BuildConfig.java >> No comments. >> >> src/share/tools/ProjectCreator/WinGammaPlatformVC10.java >> line 373: if(!platformName.equals("Win32")) { >> line 374: addAttr(rv, "AdditionalOptions", "/homeparams"); >> The above block will also apply to an "ia64" build. >> >> src/share/tools/ProjectCreator/WinGammaPlatformVC7.java >> src/share/tools/ProjectCreator/WinGammaPlatformVC8.java >> Do we need to do anything about the new, but unused >> platform to make lint-like tools not squawk? >> >> Thumbs up. >> >> Dan >> >> >> On 8/19/14 5:39 PM, Christian Tornqvist wrote: >>> Hi everyone, >>> >>> >>> >>> This change adds /homeparams >>> (http://msdn.microsoft.com/en-us/library/6exwh0y6.aspx) to compiler >>> flags when building fastdebug on Windows x64. This causes the >>> compiler to generate code to spill the first 4 arguments to the >>> stack (they're normally only passed in registers), which should make >>> it easier > to debug. >>> >>> >>> I also changed the ProjectCreator to enable building with this using >>> Visual Studio. The size of jvm.dll increases with about 3% (about >>> 504k >> increase). >>> >>> >>> Verified that it builds correctly using Visual Studio and JPRT, the >>> generation of the spill code has been verified by comparing prologue >>> code for several functions in the JVM with/without using /homeparams. >>> >>> >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.00/ >>> >>> >>> >>> Bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8027480 >>> >>> >>> >>> Thanks, >>> >>> Christian >>> >>> >>> > From daniel.daugherty at oracle.com Wed Aug 20 17:28:18 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Aug 2014 11:28:18 -0600 Subject: RFR(S): 8027480 - Build Windows x64 fastdebug builds using /homeparams In-Reply-To: <053c01cfbc98$e2a10cd0$a7e32670$@oracle.com> References: <038701cfbc06$c1e63930$45b2ab90$@oracle.com> <53F4A6F2.5050609@oracle.com> <04b101cfbc85$f4089870$dc19c950$@oracle.com> <53F4BBF7.2050509@oracle.com> <04d801cfbc8e$20a3d720$61eb8560$@oracle.com> <53F4C680.3090606@oracle.com> <053c01cfbc98$e2a10cd0$a7e32670$@oracle.com> Message-ID: <53F4DAB2.4000708@oracle.com> Your call. Dan On 8/20/14 11:05 AM, Christian Tornqvist wrote: > I talked to Staffan Friberg (perf tech lead) about enabling this in a > release builds and this is his opinion: > > "For /homeparams I think enable it now in fastdebug, let's use it for a > while and understand home much of a benefit it is for debugging. If it is a > huge help let's consider it for release, but that will require a lot of > performance testing before commiting" > > I agree with Staffan and think we should only enable it in fastdebug builds > for now. > > Thanks, > Christian > > -----Original Message----- > From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] > Sent: Wednesday, August 20, 2014 12:02 PM > To: Christian Tornqvist > Cc: hotspot-dev at openjdk.java.net; build-dev at openjdk.java.net > Subject: Re: RFR(S): 8027480 - Build Windows x64 fastdebug builds using > /homeparams > > On 8/20/14 9:48 AM, Christian Tornqvist wrote: >>> indicate that we shouldn't need this change in our debug/fastdebug > builds. >> However, you looked at the generated prologue code before and after >> turning on this option right? >> >> Our fastdebug builds are compiled with /O2 which doesn't spill the >> parameters onto the stack, our debug builds (with /Od) will do this so >> passing /homeparams there is a no-op. >> >> Here is a look at the prologue code for >> ClassFileParser::parse_constant_pool_entries() before /homeparams: >> >> mov dword ptr [rsp+10h],edx >> push rbp >> push rsi >> >> and here is with /homeparams: >> >> mov qword ptr [rsp+18h],r8 >> mov dword ptr [rsp+10h],edx >> mov qword ptr [rsp+8],rcx >> push rbp >> push rsi > Cool. When we did the Full Debug Symbols (FDS) project, one of the things we > did was try to use the same optimization and debug options with > RELEASE/product builds as with fastdebug builds. Since we're generating > debug info for all builds configs, we thought this was a really good design > goal unless we ran into a performance issue. > > During the FDS project, we saw no performance change when we switched the > optimization options and included the various generate-debug-info options. > > A long way of saying: > > I think you should enable /homeparams for RELEASE/product builds. > > :-) > > Dan > > >> Thanks, >> Christian >> >> -----Original Message----- >> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] >> Sent: Wednesday, August 20, 2014 11:17 AM >> To: Christian Tornqvist >> Cc: hotspot-dev at openjdk.java.net; build-dev at openjdk.java.net >> Subject: Re: RFR(S): 8027480 - Build Windows x64 fastdebug builds >> using /homeparams >> >> On 8/20/14 8:49 AM, Christian Tornqvist wrote: >>>> Do we have any idea how much of a change? Do we care? I'm presuming >>>> the >>> increased debuggability is worth it. >>> >>> It adds 0-4 additional stack movs in function prologue code which >>> should have a very low impact, it's only on debug/fastdebug builds. >> I missed that this was a non-RELEASE build change in my original review. >> >> These two blurbs from the MSDN note: >> >> > However, by default in a release build, the register parameters > >> will not be written to the stack, into the space that is already > >> provided for the parameters. This makes it difficult to debug an > >> optimized (release) build of your program. >> >> and >> >> > In a debug build, the stack is always populated with parameters > >> passed in registers. >> >> indicate that we shouldn't need this change in our debug/fastdebug builds. >> However, you looked at the generated prologue code before and after >> turning on this option right? >> >> Does this mean that the MSDN note is not correct for the way that we >> do debug and fastdebug builds? We might have some option enabled that >> prevents the default /homeparams behavior from working... >> >> Dan >> >> >>>> The above block will also apply to an "ia64" build. We don't support >>>> that >>> anymore, but I don't know if any licensees support it. >>> >>> I've changed the checks in vm.make and WinGammaPlatformVC10.java >>> >>>> Do we need to do anything about the new, but unused platform to >>>> make >>> lint-like tools not squawk? >>> >>> I'll open a new bug to clean up the VC7/8/9 files in ProjectCreator. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.01/ >>> >>> Thanks, >>> Christian >>> >>> -----Original Message----- >>> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] >>> Sent: Wednesday, August 20, 2014 9:48 AM >>> To: Christian Tornqvist >>> Cc: hotspot-dev at openjdk.java.net >>> Subject: Re: RFR(S): 8027480 - Build Windows x64 fastdebug builds >>> using /homeparams >>> >>> > http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.00/ >>> >>> General Comment >>> >>> The MSDN note says: >>> >>> > /homeparams does imply a performance disadvantage, because it > >>> does require a cycle to load the register parameters on to the stack. >>> >>> Do we have any idea how much of a change? Do we care? I'm presuming >>> the increased debuggability is worth it. >>> >>> make/windows/makefiles/vm.make >>> line 38: !else >>> line 39: CXX_FLAGS=$(CXX_FLAGS) /D "ASSERT" /homeparams >>> line 40: !endif >>> The above block will also apply to an "ia64" build. >>> We don't support that anymore, but I don't know if >>> any licensees support it. >>> >>> src/share/tools/ProjectCreator/BuildConfig.java >>> No comments. >>> >>> src/share/tools/ProjectCreator/WinGammaPlatformVC10.java >>> line 373: if(!platformName.equals("Win32")) { >>> line 374: addAttr(rv, "AdditionalOptions", "/homeparams"); >>> The above block will also apply to an "ia64" build. >>> >>> src/share/tools/ProjectCreator/WinGammaPlatformVC7.java >>> src/share/tools/ProjectCreator/WinGammaPlatformVC8.java >>> Do we need to do anything about the new, but unused >>> platform to make lint-like tools not squawk? >>> >>> Thumbs up. >>> >>> Dan >>> >>> >>> On 8/19/14 5:39 PM, Christian Tornqvist wrote: >>>> Hi everyone, >>>> >>>> >>>> >>>> This change adds /homeparams >>>> (http://msdn.microsoft.com/en-us/library/6exwh0y6.aspx) to compiler >>>> flags when building fastdebug on Windows x64. This causes the >>>> compiler to generate code to spill the first 4 arguments to the >>>> stack (they're normally only passed in registers), which should make >>>> it easier >> to debug. >>>> >>>> >>>> I also changed the ProjectCreator to enable building with this using >>>> Visual Studio. The size of jvm.dll increases with about 3% (about >>>> 504k >>> increase). >>>> >>>> >>>> Verified that it builds correctly using Visual Studio and JPRT, the >>>> generation of the spill code has been verified by comparing prologue >>>> code for several functions in the JVM with/without using /homeparams. >>>> >>>> >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8027480/webrev.00/ >>>> >>>> >>>> >>>> Bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8027480 >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Christian >>>> >>>> >>>> > From serguei.spitsyn at oracle.com Wed Aug 20 19:49:47 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 20 Aug 2014 12:49:47 -0700 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F4C49D.4070404@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> Message-ID: <53F4FBDB.9080508@oracle.com> On 8/20/14 8:54 AM, Coleen Phillimore wrote: > > Hi, it appears that my code is wrong and maybe the existing code is > wrong also. I have a spec question below. > > On 8/19/14, 7:52 PM, serguei.spitsyn at oracle.com wrote: >> On 8/19/14 3:53 PM, Daniel D. Daugherty wrote: >>> >>> On 8/19/14 3:39 PM, Daniel D. Daugherty wrote: >>>> On 8/15/14 2:18 PM, Coleen Phillimore wrote: >>>>> Summary: Use scratch_class to find EMCP methods for breakpoints if >>>>> the old methods are still running >>>>> >>>>> See bug for more details. This fix also includes a change to >>>>> nmethod::metadata_do() to not walk the _method multiple times (the >>>>> _method is added to the metadata section of the nmethod), and an >>>>> attempt to help the sweeper clean up these scratch_class instance >>>>> classes sooner. >>>>> >>>>> Tested with nsk tests, java/lang/instrument tests and jck tests >>>>> (which include some jvmti tests). >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8055008/ >>>> >>>> src/share/vm/oops/instanceKlass.hpp >>>> line 1047 // RedefineClass support >>>> Should be 'RedefineClasses'. >>>> >>>> line 1049: void mark_newly_obsolete_methods(Array* >>>> old_methods, >>>> int emcp_method_count); >>>> The 'obsolete' part of the function name does not match with >>>> the 'emcp' part of the parameter name. EMCP methods are 'old', >>>> but not 'obsolete'. >>>> >>>> Update: OK, I think I get it. We want to mark methods that are >>>> newly transitioning from EMCP -> obsolete and the >>>> emcp_method_count >>>> parameter tells us if there is any work to do. >>>> >>>> src/share/vm/oops/instanceKlass.cpp >>>> line 3023: } // pvw is cleaned up >>>> 'pvw' no longer exists so comment is stale. >>>> >>>> line 3455: // check the previous versions array >>>> This comment should move above this line: >>>> >>>> 3453 for (; pv_node != NULL; ) { >>>> >>>> and 'array' should change to 'list'. >>>> >>>> Sorry for the bad placement of the original comment. >>>> >>>> line 3463: last->link_previous_versions(pv_node); >>>> So now we've overwritten the previous value of >>>> last->previous_versions. How does that InstanceKlass >>>> get freed? Maybe a short comment? >>>> >>>> line 3484: // Mark the emcp method as obsolete if it's not >>>> executing >>>> I'm not sure about whether this is a good idea. When we had a >>>> redefine make a method obsolete before, we knew that we could >>>> make all older but previously EMCP methods obsolete because >>>> the new method version did make them obsolete. >>>> >>>> With this optimization, we're saying that no thread is >>>> executing >>>> the method so we're going to make it obsolete even if the >>>> current >>>> redefine did not do so. I worry about a method call that is in >>>> the early stages of assembling the call stack being caught >>>> calling a method that is now obsolete but not because of a >>>> redefine made it obsolete. Just FYI, one of the tracing flags >>>> catches unexpected calls to obsolete methods today and it does >>>> catch the current system's legitimate race. >>> >>> JVM/TI has an isMethodObsolete() API: >>> >>> jvmtiError >>> IsMethodObsolete(jvmtiEnv* env, >>> jmethodID method, >>> jboolean* is_obsolete_ptr) >>> >>> It would be possible for an agent to observe a method changing from >>> not obsolete to obsolete when that's not expected. I suspect that >>> this would be a spec violation. >> >> I agree that this looks like a spec violation. >> The emcp methods by definition are non-obsolete, >> or in opposite, the obsolete methods are non-emcp: >> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#obsoleteMethods >> >> Old method versions may become obsolete, not emcp: >> http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#RedefineClasses >> >> But maybe I'm missing something... > > If an EMCP method is not running, should we save it on a previous > version list anyway so that we can make it obsolete if it's redefined > and made obsolete? I hope, Dan will catch me if I'm wrong... I think, we should not. An EMCP method can not be made obsolete if it is not running. BTW, I'm reviewing the webrev too, but probably it'd be better to switch to updated webrev after it is ready. Thanks, Serguei > > Currently we don't save previous versions of methods that are not > running. We didn't before permgen elimination either. If GC didn't > find the EMCP method, we would remove the entry. > > Thanks, > Coleen > >> >> >> Thanks, >> Serguei >> >>> >>> Dan >>> >>> >>>> >>>> line 3527: // clear out any matching EMCP method entries the >>>> hard way. >>>> Perhaps "mark" instead of "clear out"? >>>> >>>> old line 3659: if (!method->is_obsolete() && >>>> new line 3546: if (method->is_emcp() && >>>> The old code is correct. The old code won't remark a method >>>> that >>>> was already made obsolete so there won't be more than one >>>> trace >>>> message for that operation. >>>> >>>> line 3581: // stack, and set emcp methods on the stack. >>>> In comments 'emcp' should be 'EMCP'. We did not do that in the >>>> code because of HotSpot's variable name style. >>>> >>>> Also, set what on EMCP methods on the stack? >>>> >>>> line 3591: ... If emcp method from >>>> line 3592: // a previous redefinition may be made obsolete by >>>> this redefinition. >>>> Having trouble parsing this comment. >>>> >>>> src/share/vm/oops/method.hpp >>>> line 693: // emcp methods (equivalent method except constant >>>> pool is different) >>>> line 694: // that are old but not obsolete or deleted. >>>> Perhaps: >>>> >>>> // EMCP methods are old but not obsolete or deleted. >>>> Equivalent >>>> // Modulo Constant Pool means the method is equivalent except >>>> // the constant pool and instructions that access the constant >>>> // pool might be different. >>>> >>>> src/share/vm/prims/jvmtiImpl.cpp >>>> No comments. >>>> >>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>> No comments. >>>> >>>> src/share/vm/code/nmethod.cpp >>>> So in the original code f(_method) was being called two extra >>>> times? (once in the while-loop and once at the end) So I'm >>>> guessing that f(_method) is properly called when the rest of >>>> the metadata is handled in the nmethod (line 2085)? >>>> >>>> src/share/vm/memory/universe.cpp >>>> No comments (resisting 'The Walking Dead' ref...) >>>> >>>> test/runtime/RedefineTests/RedefineFinalizer.java >>>> No comments. >>>> >>>> test/runtime/RedefineTests/RedefineRunningMethods.java >>>> line 44: " while (!stop) { count2++; }" + >>>> line 53: while (!stop) { count1++; } >>>> line 56: while (!stop) { count2++; } >>>> >>>> These may not behave well on OSes with bad threading >>>> models. You might want to add a helper function that >>>> sleeps for 10ms and have each of these loops call it >>>> so the test more well behaved. >>>> >>>> Dan >>>> >>>> >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8055008 >>>>> >>>>> Thanks, >>>>> Coleen >>>> >>>> >>> >> > From coleen.phillimore at oracle.com Wed Aug 20 20:01:41 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 20 Aug 2014 16:01:41 -0400 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F4FBDB.9080508@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> Message-ID: <53F4FEA5.2090606@oracle.com> On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >> >> If an EMCP method is not running, should we save it on a previous >> version list anyway so that we can make it obsolete if it's redefined >> and made obsolete? > > I hope, Dan will catch me if I'm wrong... > > I think, we should not. > An EMCP method can not be made obsolete if it is not running. > It should be this way otherwise we'd have to hang onto things forever. > > BTW, I'm reviewing the webrev too, but probably it'd be better to > switch to updated webrev after it is ready. Yes, this is a good idea. I figured out why I made emcp methods obsolete, and I'm fixing that as well as Dan's comments. Thanks! Coleen > > Thanks, > Serguei From daniel.daugherty at oracle.com Wed Aug 20 22:26:14 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Aug 2014 16:26:14 -0600 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F4BEE0.60107@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F4BEE0.60107@oracle.com> Message-ID: <53F52086.2070307@oracle.com> On 8/20/14 9:29 AM, Coleen Phillimore wrote: > Dan, > Thanks for taking the time to review this! No problem. More responses below... > > On 8/19/14, 5:39 PM, Daniel D. Daugherty wrote: >> On 8/15/14 2:18 PM, Coleen Phillimore wrote: >>> Summary: Use scratch_class to find EMCP methods for breakpoints if >>> the old methods are still running >>> >>> See bug for more details. This fix also includes a change to >>> nmethod::metadata_do() to not walk the _method multiple times (the >>> _method is added to the metadata section of the nmethod), and an >>> attempt to help the sweeper clean up these scratch_class instance >>> classes sooner. >>> >>> Tested with nsk tests, java/lang/instrument tests and jck tests >>> (which include some jvmti tests). >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8055008/ >> >> src/share/vm/oops/instanceKlass.hpp >> line 1047 // RedefineClass support >> Should be 'RedefineClasses'. > > Yes, fixed. >> >> line 1049: void mark_newly_obsolete_methods(Array* >> old_methods, >> int emcp_method_count); >> The 'obsolete' part of the function name does not match with >> the 'emcp' part of the parameter name. EMCP methods are 'old', >> but not 'obsolete'. >> >> Update: OK, I think I get it. We want to mark methods that are >> newly transitioning from EMCP -> obsolete and the >> emcp_method_count >> parameter tells us if there is any work to do. > > Yes, it's not used to figure out which ones are EMCP anymore, just to > know if there are any. >> >> src/share/vm/oops/instanceKlass.cpp >> line 3023: } // pvw is cleaned up >> 'pvw' no longer exists so comment is stale. > > fixed. >> >> line 3455: // check the previous versions array >> This comment should move above this line: >> >> 3453 for (; pv_node != NULL; ) { >> >> and 'array' should change to 'list'. >> >> Sorry for the bad placement of the original comment. > > ok. > >> >> line 3463: last->link_previous_versions(pv_node); >> So now we've overwritten the previous value of >> last->previous_versions. How does that InstanceKlass >> get freed? Maybe a short comment? > > // The previous version InstanceKlass is on the > ClassLoaderData deallocate list > // so will be deallocated during the next phase of class > unloading. Like the new comment. > >> line 3484: // Mark the emcp method as obsolete if it's not executing >> I'm not sure about whether this is a good idea. When we had a >> redefine make a method obsolete before, we knew that we could >> make all older but previously EMCP methods obsolete because >> the new method version did make them obsolete. >> >> With this optimization, we're saying that no thread is executing >> the method so we're going to make it obsolete even if the >> current >> redefine did not do so. I worry about a method call that is in >> the early stages of assembling the call stack being caught >> calling a method that is now obsolete but not because of a >> redefine made it obsolete. Just FYI, one of the tracing flags >> catches unexpected calls to obsolete methods today and it does >> catch the current system's legitimate race. > > I need to study this (I think your next email is about this too). I > tried to preserve the behavior before but maybe I didn't. I'll pick this one up in the later reply. >> >> line 3527: // clear out any matching EMCP method entries the hard >> way. >> Perhaps "mark" instead of "clear out"? >> >> old line 3659: if (!method->is_obsolete() && >> new line 3546: if (method->is_emcp() && >> The old code is correct. The old code won't remark a method that >> was already made obsolete so there won't be more than one trace >> message for that operation. > > Since is_emcp() means !is_obsolete && !is_deleted, so ineffect I > changed that to not include the deleted methods. So I think it's > equivalent and I think I have to account for deleted methods in the > previous_version instanceKlasses. Thanks for setting me straight and I agree you are right here. >> >> line 3581: // stack, and set emcp methods on the stack. >> In comments 'emcp' should be 'EMCP'. We did not do that in the >> code because of HotSpot's variable name style. > > Yes, I can change all emcp to EMCP - should I change the is_EMCP() > function as well? Just in the comments (I think). I'm fairly certain that we didn't use EMCP in code, but I could be wrong... >> >> Also, set what on EMCP methods on the stack? > > This comment doesn't make very much sense. How about: > > But I may have to rewrite it because I think your point about > > line 3484: // Mark the emcp method as obsolete if it's not executing Right, we'll finalize the comment later. > >> line 3591: ... If emcp method from >> line 3592: // a previous redefinition may be made obsolete by >> this redefinition. >> Having trouble parsing this comment. > > // Mark newly obsolete methods in remaining previous versions. An > EMCP method from > // a previous redefinition may be made obsolete by this redefinition. I like the new comment. > >> src/share/vm/oops/method.hpp >> line 693: // emcp methods (equivalent method except constant pool >> is different) >> line 694: // that are old but not obsolete or deleted. >> Perhaps: >> >> // EMCP methods are old but not obsolete or deleted. Equivalent >> // Modulo Constant Pool means the method is equivalent except >> // the constant pool and instructions that access the constant >> // pool might be different. >> > > Your comment is better, thanks! It's nice to have that comment there. Glad you like it. > >> src/share/vm/prims/jvmtiImpl.cpp >> No comments. >> >> src/share/vm/prims/jvmtiRedefineClasses.cpp >> No comments. >> >> src/share/vm/code/nmethod.cpp >> So in the original code f(_method) was being called two extra >> times? (once in the while-loop and once at the end) So I'm >> guessing that f(_method) is properly called when the rest of >> the metadata is handled in the nmethod (line 2085)? > > Yes. It is added to the metadata_section so didn't need an extra > walk. This is only used for checking code and redefine classes, so > it's safe to remove this. Thanks for confirming. Kinda reminds me of the oop-map stuff... :-) > >> src/share/vm/memory/universe.cpp >> No comments (resisting 'The Walking Dead' ref...) > > Yeah the sematics for zombie nmethods is chilling. Meant to have a :-) in that comment... :-O >> >> test/runtime/RedefineTests/RedefineFinalizer.java >> No comments. >> >> test/runtime/RedefineTests/RedefineRunningMethods.java >> line 44: " while (!stop) { count2++; }" + >> line 53: while (!stop) { count1++; } >> line 56: while (!stop) { count2++; } >> >> These may not behave well on OSes with bad threading >> models. You might want to add a helper function that >> sleeps for 10ms and have each of these loops call it >> so the test more well behaved. > > I don't like adding sleeps but you are right, we might not be able to > interrupt these threads. I agree when the sleep() calls are for timing or "correctness". In this case, they are for not swamping the test machine... > I'll answer your other mail also. I think that you are right, we may > be making EMCP methods obsolete too soon. > > Thanks for the spending time and thinking hard about this. This is > some complicated code. Do It Yourself brain surgery usually is... :-) Dan > > Coleen >> >> Dan >> >> >>> bug link https://bugs.openjdk.java.net/browse/JDK-8055008 >>> >>> Thanks, >>> Coleen >> > From daniel.daugherty at oracle.com Wed Aug 20 22:37:50 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Aug 2014 16:37:50 -0600 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F4C49D.4070404@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> Message-ID: <53F5233E.2070508@oracle.com> On 8/20/14 9:54 AM, Coleen Phillimore wrote: > > Hi, it appears that my code is wrong and maybe the existing code is > wrong also. I have a spec question below. Rely embedded below... > > On 8/19/14, 7:52 PM, serguei.spitsyn at oracle.com wrote: >> On 8/19/14 3:53 PM, Daniel D. Daugherty wrote: >>> >>> On 8/19/14 3:39 PM, Daniel D. Daugherty wrote: >>>> On 8/15/14 2:18 PM, Coleen Phillimore wrote: >>>>> Summary: Use scratch_class to find EMCP methods for breakpoints if >>>>> the old methods are still running >>>>> >>>>> See bug for more details. This fix also includes a change to >>>>> nmethod::metadata_do() to not walk the _method multiple times (the >>>>> _method is added to the metadata section of the nmethod), and an >>>>> attempt to help the sweeper clean up these scratch_class instance >>>>> classes sooner. >>>>> >>>>> Tested with nsk tests, java/lang/instrument tests and jck tests >>>>> (which include some jvmti tests). >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8055008/ >>>> >>>> src/share/vm/oops/instanceKlass.hpp >>>> line 1047 // RedefineClass support >>>> Should be 'RedefineClasses'. >>>> >>>> line 1049: void mark_newly_obsolete_methods(Array* >>>> old_methods, >>>> int emcp_method_count); >>>> The 'obsolete' part of the function name does not match with >>>> the 'emcp' part of the parameter name. EMCP methods are 'old', >>>> but not 'obsolete'. >>>> >>>> Update: OK, I think I get it. We want to mark methods that are >>>> newly transitioning from EMCP -> obsolete and the >>>> emcp_method_count >>>> parameter tells us if there is any work to do. >>>> >>>> src/share/vm/oops/instanceKlass.cpp >>>> line 3023: } // pvw is cleaned up >>>> 'pvw' no longer exists so comment is stale. >>>> >>>> line 3455: // check the previous versions array >>>> This comment should move above this line: >>>> >>>> 3453 for (; pv_node != NULL; ) { >>>> >>>> and 'array' should change to 'list'. >>>> >>>> Sorry for the bad placement of the original comment. >>>> >>>> line 3463: last->link_previous_versions(pv_node); >>>> So now we've overwritten the previous value of >>>> last->previous_versions. How does that InstanceKlass >>>> get freed? Maybe a short comment? >>>> >>>> line 3484: // Mark the emcp method as obsolete if it's not >>>> executing >>>> I'm not sure about whether this is a good idea. When we had a >>>> redefine make a method obsolete before, we knew that we could >>>> make all older but previously EMCP methods obsolete because >>>> the new method version did make them obsolete. >>>> >>>> With this optimization, we're saying that no thread is >>>> executing >>>> the method so we're going to make it obsolete even if the >>>> current >>>> redefine did not do so. I worry about a method call that is in >>>> the early stages of assembling the call stack being caught >>>> calling a method that is now obsolete but not because of a >>>> redefine made it obsolete. Just FYI, one of the tracing flags >>>> catches unexpected calls to obsolete methods today and it does >>>> catch the current system's legitimate race. >>> >>> JVM/TI has an isMethodObsolete() API: >>> >>> jvmtiError >>> IsMethodObsolete(jvmtiEnv* env, >>> jmethodID method, >>> jboolean* is_obsolete_ptr) >>> >>> It would be possible for an agent to observe a method changing from >>> not obsolete to obsolete when that's not expected. I suspect that >>> this would be a spec violation. >> >> I agree that this looks like a spec violation. >> The emcp methods by definition are non-obsolete, >> or in opposite, the obsolete methods are non-emcp: >> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#obsoleteMethods >> >> Old method versions may become obsolete, not emcp: >> http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#RedefineClasses >> >> But maybe I'm missing something... > > If an EMCP method is not running, should we save it on a previous > version list anyway so that we can make it obsolete if it's redefined > and made obsolete? Interesting question. The problem with an EMCP method is that it might not be running right now, but we could have a Java thread that's in the process of invoking it that is stopped on a safepoint. We resume the world and the Java thread finishes calling the EMCP method... It's really hard to catch in-progress uses of jmethodIDs and make sure that the in-progress use switches from the EMCP method to the latest version of the method. A rarely seen race, but it does happen... > Currently we don't save previous versions of methods that are not > running. We didn't before permgen elimination either. If GC didn't > find the EMCP method, we would remove the entry. Not quite true for the pre-PermGen-Removal (PGR) world. We used to save weak refs for all of the EMCP methods in the previous version info. As the EMCP methods became collectible we removed them from the previous version info. This means if GC could find the EMCP method anywhere (stack, jmethodID, JNI handle, etc), then it stayed alive. This means that even if no thread was currently executing an EMCP method, an in-progress call to that method could still complete and poof now we have the EMCP method back on a stack somewhere... Dan > > Thanks, > Coleen > >> >> >> Thanks, >> Serguei >> >>> >>> Dan >>> >>> >>>> >>>> line 3527: // clear out any matching EMCP method entries the >>>> hard way. >>>> Perhaps "mark" instead of "clear out"? >>>> >>>> old line 3659: if (!method->is_obsolete() && >>>> new line 3546: if (method->is_emcp() && >>>> The old code is correct. The old code won't remark a method >>>> that >>>> was already made obsolete so there won't be more than one >>>> trace >>>> message for that operation. >>>> >>>> line 3581: // stack, and set emcp methods on the stack. >>>> In comments 'emcp' should be 'EMCP'. We did not do that in the >>>> code because of HotSpot's variable name style. >>>> >>>> Also, set what on EMCP methods on the stack? >>>> >>>> line 3591: ... If emcp method from >>>> line 3592: // a previous redefinition may be made obsolete by >>>> this redefinition. >>>> Having trouble parsing this comment. >>>> >>>> src/share/vm/oops/method.hpp >>>> line 693: // emcp methods (equivalent method except constant >>>> pool is different) >>>> line 694: // that are old but not obsolete or deleted. >>>> Perhaps: >>>> >>>> // EMCP methods are old but not obsolete or deleted. >>>> Equivalent >>>> // Modulo Constant Pool means the method is equivalent except >>>> // the constant pool and instructions that access the constant >>>> // pool might be different. >>>> >>>> src/share/vm/prims/jvmtiImpl.cpp >>>> No comments. >>>> >>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>> No comments. >>>> >>>> src/share/vm/code/nmethod.cpp >>>> So in the original code f(_method) was being called two extra >>>> times? (once in the while-loop and once at the end) So I'm >>>> guessing that f(_method) is properly called when the rest of >>>> the metadata is handled in the nmethod (line 2085)? >>>> >>>> src/share/vm/memory/universe.cpp >>>> No comments (resisting 'The Walking Dead' ref...) >>>> >>>> test/runtime/RedefineTests/RedefineFinalizer.java >>>> No comments. >>>> >>>> test/runtime/RedefineTests/RedefineRunningMethods.java >>>> line 44: " while (!stop) { count2++; }" + >>>> line 53: while (!stop) { count1++; } >>>> line 56: while (!stop) { count2++; } >>>> >>>> These may not behave well on OSes with bad threading >>>> models. You might want to add a helper function that >>>> sleeps for 10ms and have each of these loops call it >>>> so the test more well behaved. >>>> >>>> Dan >>>> >>>> >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8055008 >>>>> >>>>> Thanks, >>>>> Coleen >>>> >>>> >>> >> > From daniel.daugherty at oracle.com Wed Aug 20 22:45:53 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 20 Aug 2014 16:45:53 -0600 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F4FEA5.2090606@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> Message-ID: <53F52521.1080309@oracle.com> On 8/20/14 2:01 PM, Coleen Phillimore wrote: > On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >>> >>> If an EMCP method is not running, should we save it on a previous >>> version list anyway so that we can make it obsolete if it's >>> redefined and made obsolete? >> >> I hope, Dan will catch me if I'm wrong... >> >> I think, we should not. >> An EMCP method can not be made obsolete if it is not running. >> > > > It should be this way otherwise we'd have to hang onto things forever. An EMCP method should only be made obsolete if a RedefineClasses() or RetransformClasses() operation made it so. We should not be leveraging off the obsolete-ness attribute to solve a life-cycle problem. In the pre-PGR world, we could trust GC to make a completely unused EMCP method collectible and eventually our weak reference would go away. Just because an EMCP method is not on a stack does not mean that it is not used so we need a different way to determine whether it is OK to no longer track an EMCP method. > >> BTW, I'm reviewing the webrev too, but probably it'd be better to >> switch to updated webrev after it is ready. > > Yes, this is a good idea. I figured out why I made emcp methods > obsolete, and I'm fixing that as well as Dan's comments. Thanks! Cool! I'm looking forward to the next review. Dan > > Coleen > >> >> Thanks, >> Serguei > From coleen.phillimore at oracle.com Thu Aug 21 01:20:11 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 20 Aug 2014 21:20:11 -0400 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F5233E.2070508@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F5233E.2070508@oracle.com> Message-ID: <53F5494B.7030008@oracle.com> On 8/20/14, 6:37 PM, Daniel D. Daugherty wrote: > On 8/20/14 9:54 AM, Coleen Phillimore wrote: >> >> Hi, it appears that my code is wrong and maybe the existing code is >> wrong also. I have a spec question below. > > Rely embedded below... Also embedded reply but I cut some stuff out. > ... >> If an EMCP method is not running, should we save it on a previous >> version list anyway so that we can make it obsolete if it's redefined >> and made obsolete? > > Interesting question. The problem with an EMCP method is that it might > not be running right now, but we could have a Java thread that's in > the process of invoking it that is stopped on a safepoint. We resume > the world and the Java thread finishes calling the EMCP method... > > It's really hard to catch in-progress uses of jmethodIDs and make > sure that the in-progress use switches from the EMCP method to the > latest version of the method. A rarely seen race, but it does happen... > Yes, there may be small cases where EMCP methods could be brought back to life, possibly with jmethodIDs. Although the combination of changing Method* in the cpCache for the interpreter, making old methods non-entrant and deoptimized, and replacing jmethodIDs should prevent it mostly if not completely. I wouldn't be surprised if there's leakage though. > >> Currently we don't save previous versions of methods that are not >> running. We didn't before permgen elimination either. If GC didn't >> find the EMCP method, we would remove the entry. > > Not quite true for the pre-PermGen-Removal (PGR) world. We used to > save weak refs for all of the EMCP methods in the previous version > info. As the EMCP methods became collectible we removed them from > the previous version info. This means if GC could find the EMCP > method anywhere (stack, jmethodID, JNI handle, etc), then it stayed > alive. This means that even if no thread was currently executing > an EMCP method, an in-progress call to that method could still > complete and poof now we have the EMCP method back on a stack > somewhere... > True. The case I was worried about is if an EMCP method is made obsolete by redefinition but we don't have a pointer to it anywhere because it's not running or referenced, so we can't mark it obsolete. In this case I guess you can't call the isMethodObsolete() function on it. I think I went down a rabbit hole. Thanks, Coleen > Dan > > >> >> Thanks, >> Coleen >> >>> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Dan >>>> >>>> >>>>> >>>>> line 3527: // clear out any matching EMCP method entries the >>>>> hard way. >>>>> Perhaps "mark" instead of "clear out"? >>>>> >>>>> old line 3659: if (!method->is_obsolete() && >>>>> new line 3546: if (method->is_emcp() && >>>>> The old code is correct. The old code won't remark a >>>>> method that >>>>> was already made obsolete so there won't be more than one >>>>> trace >>>>> message for that operation. >>>>> >>>>> line 3581: // stack, and set emcp methods on the stack. >>>>> In comments 'emcp' should be 'EMCP'. We did not do that in >>>>> the >>>>> code because of HotSpot's variable name style. >>>>> >>>>> Also, set what on EMCP methods on the stack? >>>>> >>>>> line 3591: ... If emcp method from >>>>> line 3592: // a previous redefinition may be made obsolete by >>>>> this redefinition. >>>>> Having trouble parsing this comment. >>>>> >>>>> src/share/vm/oops/method.hpp >>>>> line 693: // emcp methods (equivalent method except constant >>>>> pool is different) >>>>> line 694: // that are old but not obsolete or deleted. >>>>> Perhaps: >>>>> >>>>> // EMCP methods are old but not obsolete or deleted. >>>>> Equivalent >>>>> // Modulo Constant Pool means the method is equivalent except >>>>> // the constant pool and instructions that access the >>>>> constant >>>>> // pool might be different. >>>>> >>>>> src/share/vm/prims/jvmtiImpl.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/code/nmethod.cpp >>>>> So in the original code f(_method) was being called two extra >>>>> times? (once in the while-loop and once at the end) So I'm >>>>> guessing that f(_method) is properly called when the rest of >>>>> the metadata is handled in the nmethod (line 2085)? >>>>> >>>>> src/share/vm/memory/universe.cpp >>>>> No comments (resisting 'The Walking Dead' ref...) >>>>> >>>>> test/runtime/RedefineTests/RedefineFinalizer.java >>>>> No comments. >>>>> >>>>> test/runtime/RedefineTests/RedefineRunningMethods.java >>>>> line 44: " while (!stop) { count2++; }" + >>>>> line 53: while (!stop) { count1++; } >>>>> line 56: while (!stop) { count2++; } >>>>> >>>>> These may not behave well on OSes with bad threading >>>>> models. You might want to add a helper function that >>>>> sleeps for 10ms and have each of these loops call it >>>>> so the test more well behaved. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8055008 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Thu Aug 21 01:26:24 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 20 Aug 2014 21:26:24 -0400 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F52521.1080309@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> <53F52521.1080309@oracle.com> Message-ID: <53F54AC0.7010007@oracle.com> On 8/20/14, 6:45 PM, Daniel D. Daugherty wrote: > On 8/20/14 2:01 PM, Coleen Phillimore wrote: >> On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>> >>>> If an EMCP method is not running, should we save it on a previous >>>> version list anyway so that we can make it obsolete if it's >>>> redefined and made obsolete? >>> >>> I hope, Dan will catch me if I'm wrong... >>> >>> I think, we should not. >>> An EMCP method can not be made obsolete if it is not running. >>> >> >> >> It should be this way otherwise we'd have to hang onto things forever. > > An EMCP method should only be made obsolete if a RedefineClasses() or > RetransformClasses() operation made it so. We should not be leveraging > off the obsolete-ness attribute to solve a life-cycle problem. Yes, this was my error in the change. This is why I made things obsolete if they were not running. I think I can't reuse this flag. My latest changes add a new explicit flag (which we have space for in Method*). > > In the pre-PGR world, we could trust GC to make a completely unused > EMCP method collectible and eventually our weak reference would go > away. Just because an EMCP method is not on a stack does not mean > that it is not used so we need a different way to determine whether > it is OK to no longer track an EMCP method. Our on_stack marking is supposed to look at all the places where GC used to look so I think we can use on_stack to track the lifecycle of EMCP methods. If the EMCP method is somewhere, we will find it! I'm running tests on the latest change, but am also waiting for confirmation from Roland because we were only cleaning out MethodData for EMCP methods and not for running obsolete methods and I think we need to do that for obsolete methods also, which my change does now. I think it was a bug. Thanks Dan for remembering all of this for me! Coleen > > >> >>> BTW, I'm reviewing the webrev too, but probably it'd be better to >>> switch to updated webrev after it is ready. >> >> Yes, this is a good idea. I figured out why I made emcp methods >> obsolete, and I'm fixing that as well as Dan's comments. Thanks! > > Cool! I'm looking forward to the next review. > > Dan > > >> >> Coleen >> >>> >>> Thanks, >>> Serguei >> > From christian.thalinger at oracle.com Thu Aug 21 15:58:17 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 21 Aug 2014 08:58:17 -0700 Subject: RFR: 8011397: JTREG needs to copy additional WhiteBox class file to JTwork/scratch/sun/hotspot In-Reply-To: <1904344.AZu4ofu3BO@mgerdin03> References: <536B7CF0.6010508@oracle.com> <53E8A8FB.2080505@oracle.com> <53E8CB69.5010003@oracle.com> <1904344.AZu4ofu3BO@mgerdin03> Message-ID: Sorry I missed this review but I don?t think that?s a good way to handle this issue; this just doesn?t scale. What if someone adds another inner-class to WhiteBox? Do we have to update all tests again? On Aug 12, 2014, at 4:42 AM, Mikael Gerdin wrote: > On Monday 11 August 2014 17.55.53 Andrey Zakharov wrote: >> Hi, all >> Here is updated patch with recent added tests: >> >> * ./test/compiler/classUnloading/methodUnloading/TestMethodUnloading.java >> * ./test/gc/class_unloading/TestCMSClassUnloadingEnabledHWM.java >> * ./test/gc/class_unloading/TestG1ClassUnloadingHWM.java >> >> webrev: >> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.04/ > > Ok, > > /Mikael > >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8011397 >> >> Thanks. >> >> On 11.08.2014 15:28, Andrey Zakharov wrote: >>> Hi, Igor. >>> I have another counts with applied patch, but it looks like couple of >>> tests has beed added since last check. >>> >>> $ grep -Rl --exclude-dir=testlibrary >>> "sun.hotspot.WhiteBox\$WhiteBoxPermission" ./test/| wc -l >>> 133 >>> >>> $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox" ./test/| >>> wc -l >>> 142 >>> >>> Will update patch soon. >>> Thanks. >>> >>> On 11.08.2014 15:18, Igor Ignatyev wrote: >>>> Andrey, >>>> >>>> could you please look at and fix other tests which use whitebox? >>>> >>>> $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox" ./test | >>>> wc -l >>>> 139 >>>> $ grep -Rl --exclude-dir=testlibrary >>>> "sun.hotspot.WhiteBox\$WhiteBoxPermission" ./test/ | wc -l >>>> 10 >>>> >>>> Thanks >>>> Igor >>>> >>>> On 08/11/2014 03:09 PM, Andrey Zakharov wrote: >>>>> Hi, all >>>>> >>>>> Is it possible to review this below >>>>> webrev: >>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>> >>>>> Thanks. >>>>> >>>>> On 28.07.2014 18:51, Andrey Zakharov wrote: >>>>>> Hi, all. >>>>>> I've prepared rechecked and verified fix for subject. >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>> >>>>>> I've grep'ed workspace by sun.hotspot.WhiteBox and fixed every file. >>>>>> Also I've updated copyright. >>>>>> Testing was done by aurora batch 538304.ute.hs_jtreg.accept.full >>>>>> It looks good. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> On 16.07.2014 15:13, Andrey Zakharov wrote: >>>>>>> On 16.07.2014 14:39, Erik Helin wrote: >>>>>>>> On Tuesday 15 July 2014 19:26:34 PM Andrey Zakharov wrote: >>>>>>>>> Hi, Erik, Bengt. Could you, please, review this too. >>>>>>>> >>>>>>>> Andrey, why did you only update a couple of tests to also copy >>>>>>>> sun.hotspot.WhiteBox$WhiteBoxPermission? You updated 14 tests, >>>>>>>> there are >>>>>>>> still 116 tests using sun.hotspot.WhiteBox. >>>>>>>> >>>>>>>> Why doesn't these 116 tests have to be updated? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Erik >>>>>>> >>>>>>> Thanks Erik. Actually this first one patch 8011397.WhiteBoxPermission >>>>>>> >>>>>> xPermission> >>>>>>> >>>>>>> is correct. I will rework it and upload to webrev space. >>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> On 15.07.2014 17:58, Mikael Gerdin wrote: >>>>>>>>>> Andrey, >>>>>>>>>> >>>>>>>>>> On Monday 07 July 2014 20.48.21 Andrey Zakharov wrote: >>>>>>>>>>> Hi ,all >>>>>>>>>>> Mikael, can you please review it. >>>>>>>>>> >>>>>>>>>> Sorry, I was on vacation last week. >>>>>>>>>> >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ >>>>>>>>>> >>>>>>>>>> Looks ok for now. We should consider revisiting this by either >>>>>>>>>> switching >>>>>>>>>> to >>>>>>>>>> @run main/bootclasspath >>>>>>>>>> or >>>>>>>>>> deleting the WhiteboxPermission nested class and using some >>>>>>>>>> other way for >>>>>>>>>> permission checks (if they are at all needed). >>>>>>>>>> >>>>>>>>>> /Mikael >>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> On 25.06.2014 19:08, Andrey Zakharov wrote: >>>>>>>>>>>> Hi, all >>>>>>>>>>>> So in progress of previous email - >>>>>>>>>>>> webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks. >>>>>>>>>>>> >>>>>>>>>>>> On 16.06.2014 19:57, Andrey Zakharov wrote: >>>>>>>>>>>>> Hi, all >>>>>>>>>>>>> So issue is that when tests with WhiteBox API has been >>>>>>>>>>>>> invoked with >>>>>>>>>>>>> -Xverify:all it fails with Exception >>>>>>>>>>>>> java.lang.NoClassDefFoundError: >>>>>>>>>>>>> sun/hotspot/WhiteBox$WhiteBoxPermission >>>>>>>>>>>>> Solutions that are observed: >>>>>>>>>>>>> 1. Copy WhiteBoxPermission with WhiteBox. But >>>>>>>>>>>>> >>>>>>>>>>>>>>> Perhaps this is a good time to get rid of ClassFileInstaller >>>>>>>>>>>>> >>>>>>>>>>>>> altogether? >>>>>>>>>>>>> >>>>>>>>>>>>> 2. Using bootclasspath to hook pre-built whitebox (due @library >>>>>>>>>>>>> /testlibrary/whitebox) . Some tests has @run main/othervm, >>>>>>>>>>>>> some uses >>>>>>>>>>>>> ProcessBuilder. >>>>>>>>>>>>> >>>>>>>>>>>>> - main/othervm/bootclasspath adds ${test.src} and >>>>>>>>>>>>> >>>>>>>>>>>>> ${test.classes}to options. >>>>>>>>>>>>> >>>>>>>>>>>>> - With ProcessBuilder we can just add ${test.classes} >>>>>>>>>>>>> >>>>>>>>>>>>> Question here is, can it broke some tests ? While testing >>>>>>>>>>>>> this, I >>>>>>>>>>>>> found onlyhttps://bugs.openjdk.java.net/browse/JDK-8046231, >>>>>>>>>>>>> others >>>>>>>>>>>>> looks fine. >>>>>>>>>>>>> >>>>>>>>>>>>> 3. Make ClassFileInstaller deal with inner classes like that: >>>>>>>>>>>>> diff -r 6ed24aedeef0 -r c01651363ba8 >>>>>>>>>>>>> test/testlibrary/ClassFileInstaller.java >>>>>>>>>>>>> --- a/test/testlibrary/ClassFileInstaller.java Thu Jun 05 >>>>>>>>>>>>> 19:02:56 >>>>>>>>>>>>> 2014 +0400 >>>>>>>>>>>>> +++ b/test/testlibrary/ClassFileInstaller.java Fri Jun 06 >>>>>>>>>>>>> 18:18:11 >>>>>>>>>>>>> 2014 +0400 >>>>>>>>>>>>> @@ -50,6 +50,16 @@ >>>>>>>>>>>>> >>>>>>>>>>>>> } >>>>>>>>>>>>> // Create the class file >>>>>>>>>>>>> Files.copy(is, p, >>>>>>>>>>>>> >>>>>>>>>>>>> StandardCopyOption.REPLACE_EXISTING); >>>>>>>>>>>>> >>>>>>>>>>>>> + >>>>>>>>>>>>> + for (Class cls : >>>>>>>>>>>>> Class.forName(arg).getDeclaredClasses()) { >>>>>>>>>>>>> + //if >>>>>>>>>>>>> (!Modifier.isStatic(cls.getModifiers())) { >>>>>>>>>>>>> + String pathNameSub = >>>>>>>>>>>>> cls.getCanonicalName().replace('.', '/').concat(".class"); >>>>>>>>>>>>> + Path pathSub = Paths.get(pathNameSub); >>>>>>>>>>>>> + InputStream streamSub = >>>>>>>>>>>>> cl.getResourceAsStream(pathNameSub); >>>>>>>>>>>>> + Files.copy(streamSub, pathSub, >>>>>>>>>>>>> StandardCopyOption.REPLACE_EXISTING); >>>>>>>>>>>>> + //} >>>>>>>>>>>>> + } >>>>>>>>>>>>> + >>>>>>>>>>>>> >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> Works fine for ordinary classes, but fails for WhiteBox due >>>>>>>>>>>>> Class.forName initiate Class. WhiteBox has "static" section, >>>>>>>>>>>>> and >>>>>>>>>>>>> initialization fails as it cannot bind to native methods >>>>>>>>>>>>> "registerNatives" and so on. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> So, lets return to first one option? Just add everywhere >>>>>>>>>>>>> >>>>>>>>>>>>> * @run main ClassFileInstaller sun.hotspot.WhiteBox >>>>>>>>>>>>> >>>>>>>>>>>>> + * @run main ClassFileInstaller >>>>>>>>>>>>> sun.hotspot.WhiteBox$WhiteBoxPermission >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks. >>>>>>>>>>>>> >>>>>>>>>>>>> On 10.06.2014 19:43, Igor Ignatyev wrote: >>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't like this idea, since it completely changes the tests. >>>>>>>>>>>>>> 'run/othervm/bootclasspath' adds all paths from CP to BCP, >>>>>>>>>>>>>> so the >>>>>>>>>>>>>> tests whose main idea was testing WB methods themselves >>>>>>>>>>>>>> (sanity, >>>>>>>>>>>>>> compiler/whitebox, ...) don't check that it's possible to >>>>>>>>>>>>>> use WB >>>>>>>>>>>>>> when the application isn't in BCP. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Igor >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 06/09/2014 06:59 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>> Hi, everybody >>>>>>>>>>>>>>> I have tested my changes on major platforms and found one >>>>>>>>>>>>>>> bug, filed: >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046231 >>>>>>>>>>>>>>> Also, i did another try to make ClassFileInstaller to copy >>>>>>>>>>>>>>> all inner >>>>>>>>>>>>>>> classes within parent, but this fails for WhiteBox due its >>>>>>>>>>>>>>> static >>>>>>>>>>>>>>> "registerNatives" dependency. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please, review suggested changes: >>>>>>>>>>>>>>> - replace ClassFileInstaller and run/othervm with >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> "run/othervm/bootclasspath". >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> bootclasspath parameter for othervm >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> adds-Xbootclasspath/a: >>>>>>>>>>>>>>> option with ${test.src} and ${test.classes}according to >>>>>>>>>>>>>>> http://hg.openjdk.java.net/code-tools/jtreg/file/31003a1c46d9/ >>>>>>>>>>>>>>> src/sha >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> re >>>>>>>>>>>>>>> /classes/com/sun/javatest/regtest/MainAction.java. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is this suitable for our needs - give to test compiled >>>>>>>>>>>>>>> WhiteBox? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - replace explicit -Xbootclasspath option values (".") in >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ProcessBuilder invocations to ${test.classes} where >>>>>>>>>>>>>>> WhiteBox has been >>>>>>>>>>>>>>> compiled. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev. >>>>>>>>>>>>>>> 00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 23.05.2014 15:40, Andrey Zakharov wrote: >>>>>>>>>>>>>>>> On 22.05.2014 12:47, Igor Ignatyev wrote: >>>>>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 1. You changed dozen of tests, have you tested your >>>>>>>>>>>>>>>>> changes? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Locally, aurora on the way. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2. Your changes of year in copyright is wrong. it has to be >>>>>>>>>>>>>>>>> $first_year, [$last_year, ], see Mark's email[1] for >>>>>>>>>>>>>>>>> details. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/jdk7-dev/2010-May/001 >>>>>>>>>>>>>>>>> 321.htm >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> l >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, fixed. will be uploaded soon. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Igor >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 05/21/2014 07:37 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>> On 13.05.2014 14:43, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>>>>>> So here is trivial patch - >>>>>>>>>>>>>>>>>>> removing ClassFileInstaller sun.hotspot.WhiteBox and >>>>>>>>>>>>>>>>>>> adding >>>>>>>>>>>>>>>>>>> main/othervm/bootclasspath >>>>>>>>>>>>>>>>>>> where this needed >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Also, some tests are modified as >>>>>>>>>>>>>>>>>>> - "-Xbootclasspath/a:.", >>>>>>>>>>>>>>>>>>> + "-Xbootclasspath/a:" + >>>>>>>>>>>>>>>>>>> System.getProperty("test.classes"), >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> webrev:http://cr.openjdk.java.net/~jwilhelm/8011397/webrev. >>>>>>>>>>>>>>>>>> 02/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 09.05.2014 12:13, Mikael Gerdin wrote: >>>>>>>>>>>>>>>>>>>> On Thursday 08 May 2014 19.28.13 Igor Ignatyev wrote: >>>>>>>>>>>>>>>>>>>>> // cc'ing hotspot-dev instaed of compiler, runtime >>>>>>>>>>>>>>>>>>>>> and gc >>>>>>>>>>>>>>>>>>>>> lists. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 05/08/2014 07:09 PM, Filipp Zhinkin wrote: >>>>>>>>>>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I've CC'ed compiler and runtime mailing list, >>>>>>>>>>>>>>>>>>>>>> because you're >>>>>>>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>>>>>>>> affect test for other components as too. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I don't like your solution (but I'm not a reviewer, >>>>>>>>>>>>>>>>>>>>>> so treat >>>>>>>>>>>>>>>>>>>>>> my >>>>>>>>>>>>>>>>>>>>>> words >>>>>>>>>>>>>>>>>>>>>> just as suggestion), >>>>>>>>>>>>>>>>>>>>>> because we'll have to write more meta information >>>>>>>>>>>>>>>>>>>>>> for each >>>>>>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>>>>>> and it >>>>>>>>>>>>>>>>>>>>>> is very easy to >>>>>>>>>>>>>>>>>>>>>> forget to install WhiteBoxPermission if you don't >>>>>>>>>>>>>>>>>>>>>> test your >>>>>>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>>> some security manager. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> From my point of view, it will be better to extend >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> ClassFileInstaller >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> so it will copy not only >>>>>>>>>>>>>>>>>>>>>> a class whose name was passed as an arguments, but >>>>>>>>>>>>>>>>>>>>>> also all >>>>>>>>>>>>>>>>>>>>>> inner >>>>>>>>>>>>>>>>>>>>>> classes of that class. >>>>>>>>>>>>>>>>>>>>>> And if someone want copy only specified class >>>>>>>>>>>>>>>>>>>>>> without inner >>>>>>>>>>>>>>>>>>>>>> classes, >>>>>>>>>>>>>>>>>>>>>> then some option >>>>>>>>>>>>>>>>>>>>>> could be added to ClassFileInstaller to force such >>>>>>>>>>>>>>>>>>>>>> behaviour. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Perhaps this is a good time to get rid of >>>>>>>>>>>>>>>>>>>> ClassFileInstaller >>>>>>>>>>>>>>>>>>>> altogether? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8009117 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The reason for its existence is that the WhiteBox >>>>>>>>>>>>>>>>>>>> class needs >>>>>>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>>>>>> boot class path. >>>>>>>>>>>>>>>>>>>> If we can live with having all the test's classes on >>>>>>>>>>>>>>>>>>>> the boot >>>>>>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>>>>>> path then >>>>>>>>>>>>>>>>>>>> we could use the /bootclasspath option in jtreg as >>>>>>>>>>>>>>>>>>>> stated in >>>>>>>>>>>>>>>>>>>> the RFE. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> /Mikael >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> Filipp. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 05/08/2014 04:47 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>>>>>>> Hi! >>>>>>>>>>>>>>>>>>>>>>> Suggesting patch with fixes for >>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20275/ >>>>>>>>>>>>>>>>>>>>>>> 8011397 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> .t >>>>>>>>>>>>>>>>>>>>>>> gz >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> patch: >>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20274/ >>>>>>>>>>>>>>>>>>>>>>> 8011397 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> .W >>>>>>>>>>>>>>>>>>>>>>> hiteBoxPer >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> mission >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks. > From jesper.wilhelmsson at oracle.com Thu Aug 21 16:19:21 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 21 Aug 2014 18:19:21 +0200 Subject: RFR[P1]: 8055744 - 8u-dev nightly solaris builds failed on 08/20 Message-ID: <53F61C09.4060300@oracle.com> Hi, On Solaris the HS_ALT_MAKE variable was not passed to vm.make when creating the mapfiles which lead to mapfile-ext not being found and later a linker error due to symbols declared in the extra mapfile not being found. The hotspot makefiles are .. interesting .. yes. The proposed solution is to include defs.make where HS_ALT_MAKE is set up into vm.make on Solaris. Webrev: http://cr.openjdk.java.net/~jwilhelm/8055744/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8055744#comment-13542110 This is a P1 so if you feel comfortable with the hotspot makefiles, please have a look. Thanks! /Jesper From daniel.daugherty at oracle.com Thu Aug 21 16:42:12 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 21 Aug 2014 10:42:12 -0600 Subject: RFR[P1]: 8055744 - 8u-dev nightly solaris builds failed on 08/20 In-Reply-To: <53F61C09.4060300@oracle.com> References: <53F61C09.4060300@oracle.com> Message-ID: <53F62164.2030001@oracle.com> On 8/21/14 10:19 AM, Jesper Wilhelmsson wrote: > Hi, > > On Solaris the HS_ALT_MAKE variable was not passed to vm.make when > creating the mapfiles which lead to mapfile-ext not being found and > later a linker error due to symbols declared in the extra mapfile not > being found. > > The hotspot makefiles are .. interesting .. yes. > > The proposed solution is to include defs.make where HS_ALT_MAKE is set > up into vm.make on Solaris. > > > Webrev: > http://cr.openjdk.java.net/~jwilhelm/8055744/webrev/ Unfortunately, including defs.make in make/solaris/makefiles/vm.make isn't the "right" way to get a top-level variable down into the HotSpot build system. I cannot remember what breaks when you do that, but it doesn't work right in all the ways that we build HotSpot. For the HotSpot build system, you'll want to: - update make/solaris/Makefile and add HS_ALT_MAKE to the BUILDTREE_VARS list: BUILDTREE_VARS += HS_ALT_MAKE=$(HS_ALT_MAKE) - update make/solaris/makefiles/buildtree.make and add HS_ALT_MAKE to the rule that creates flags.make: [ -n "$(HS_ALT_MAKE)" ] && \ echo && echo "HS_ALT_MAKE = $(HS_ALT_MAKE)"; \ The way I usually find all the right spots is I look for where ZIPEXE is added to the above files and follow those examples. Dan > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8055744#comment-13542110 > > This is a P1 so if you feel comfortable with the hotspot makefiles, > please have a look. > > Thanks! > /Jesper From jesper.wilhelmsson at oracle.com Thu Aug 21 17:04:58 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 21 Aug 2014 19:04:58 +0200 Subject: RFR[P1]: 8055744 - 8u-dev nightly solaris builds failed on 08/20 In-Reply-To: <53F62164.2030001@oracle.com> References: <53F61C09.4060300@oracle.com> <53F62164.2030001@oracle.com> Message-ID: <53F626BA.70204@oracle.com> Thank you for the quick reply Dan! A new webrev with your suggested change is available here: http://cr.openjdk.java.net/~jwilhelm/8055744/webrev.02/ /Jesper Daniel D. Daugherty skrev 21/8/14 18:42: > On 8/21/14 10:19 AM, Jesper Wilhelmsson wrote: >> Hi, >> >> On Solaris the HS_ALT_MAKE variable was not passed to vm.make when creating >> the mapfiles which lead to mapfile-ext not being found and later a linker >> error due to symbols declared in the extra mapfile not being found. >> >> The hotspot makefiles are .. interesting .. yes. >> >> The proposed solution is to include defs.make where HS_ALT_MAKE is set up into >> vm.make on Solaris. >> >> >> Webrev: >> http://cr.openjdk.java.net/~jwilhelm/8055744/webrev/ > > Unfortunately, including defs.make in make/solaris/makefiles/vm.make > isn't the "right" way to get a top-level variable down into the > HotSpot build system. I cannot remember what breaks when you do that, > but it doesn't work right in all the ways that we build HotSpot. > > For the HotSpot build system, you'll want to: > > - update make/solaris/Makefile and add HS_ALT_MAKE to > the BUILDTREE_VARS list: > > BUILDTREE_VARS += HS_ALT_MAKE=$(HS_ALT_MAKE) > > - update make/solaris/makefiles/buildtree.make and add > HS_ALT_MAKE to the rule that creates flags.make: > > [ -n "$(HS_ALT_MAKE)" ] && \ > echo && echo "HS_ALT_MAKE = $(HS_ALT_MAKE)"; \ > > The way I usually find all the right spots is I look for > where ZIPEXE is added to the above files and follow those > examples. > > Dan > > > > >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8055744#comment-13542110 >> >> This is a P1 so if you feel comfortable with the hotspot makefiles, please >> have a look. >> >> Thanks! >> /Jesper > From andrey.x.zakharov at oracle.com Thu Aug 21 17:05:22 2014 From: andrey.x.zakharov at oracle.com (Andrey Zakharov) Date: Thu, 21 Aug 2014 21:05:22 +0400 Subject: RFR: 8011397: JTREG needs to copy additional WhiteBox class file to JTwork/scratch/sun/hotspot In-Reply-To: References: <536B7CF0.6010508@oracle.com> <53E8A8FB.2080505@oracle.com> <53E8CB69.5010003@oracle.com> <1904344.AZu4ofu3BO@mgerdin03> Message-ID: <53F626D2.2020606@oracle.com> Hi, Christian. Sure. Let me quote my own email from this thread: > Hi, all > So issue is that when tests with WhiteBox API has been invoked with > -Xverify:all it fails with Exception java.lang.NoClassDefFoundError: > sun/hotspot/WhiteBox$WhiteBoxPermission > Solutions that are observed: > 1. Copy WhiteBoxPermission with WhiteBox. But > >> Perhaps this is a good time to get rid of ClassFileInstaller > altogether? > > 2. Using bootclasspath to hook pre-built whitebox (due @library > /testlibrary/whitebox) . Some tests has @run main/othervm, some uses > ProcessBuilder. > - main/othervm/bootclasspath adds ${test.src} and ${test.classes}to > options. > - With ProcessBuilder we can just add ${test.classes} > Question here is, can it broke some tests ? While testing this, I > found only https://bugs.openjdk.java.net/browse/JDK-8046231, others > looks fine. > > 3. Make ClassFileInstaller deal with inner classes like that: > diff -r 6ed24aedeef0 -r c01651363ba8 > test/testlibrary/ClassFileInstaller.java > --- a/test/testlibrary/ClassFileInstaller.java Thu Jun 05 19:02:56 > 2014 +0400 > +++ b/test/testlibrary/ClassFileInstaller.java Fri Jun 06 18:18:11 > 2014 +0400 > @@ -50,6 +50,16 @@ > } > // Create the class file > Files.copy(is, p, StandardCopyOption.REPLACE_EXISTING); > + > + for (Class cls : > Class.forName(arg).getDeclaredClasses()) { > + //if (!Modifier.isStatic(cls.getModifiers())) { > + String pathNameSub = > cls.getCanonicalName().replace('.', '/').concat(".class"); > + Path pathSub = Paths.get(pathNameSub); > + InputStream streamSub = > cl.getResourceAsStream(pathNameSub); > + Files.copy(streamSub, pathSub, > StandardCopyOption.REPLACE_EXISTING); > + //} > + } > + > } > } > } > > Works fine for ordinary classes, but fails for WhiteBox due > Class.forName initiate Class. WhiteBox has "static" section, and > initialization fails as it cannot bind to native methods > "registerNatives" and so on. > > > So, lets return to first one option? Just add everywhere > * @run main ClassFileInstaller sun.hotspot.WhiteBox > + * @run main ClassFileInstaller sun.hotspot.WhiteBox$WhiteBoxPermission > > Thanks. > If you have any suggestions, please share it. Thanks. On 21.08.2014 19:58, Christian Thalinger wrote: > Sorry I missed this review but I don?t think that?s a good way to handle this issue; this just doesn?t scale. What if someone adds another inner-class to WhiteBox? Do we have to update all tests again? > > On Aug 12, 2014, at 4:42 AM, Mikael Gerdin wrote: > >> On Monday 11 August 2014 17.55.53 Andrey Zakharov wrote: >>> Hi, all >>> Here is updated patch with recent added tests: >>> >>> * ./test/compiler/classUnloading/methodUnloading/TestMethodUnloading.java >>> * ./test/gc/class_unloading/TestCMSClassUnloadingEnabledHWM.java >>> * ./test/gc/class_unloading/TestG1ClassUnloadingHWM.java >>> >>> webrev: >>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.04/ >> Ok, >> >> /Mikael >> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>> >>> Thanks. >>> >>> On 11.08.2014 15:28, Andrey Zakharov wrote: >>>> Hi, Igor. >>>> I have another counts with applied patch, but it looks like couple of >>>> tests has beed added since last check. >>>> >>>> $ grep -Rl --exclude-dir=testlibrary >>>> "sun.hotspot.WhiteBox\$WhiteBoxPermission" ./test/| wc -l >>>> 133 >>>> >>>> $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox" ./test/| >>>> wc -l >>>> 142 >>>> >>>> Will update patch soon. >>>> Thanks. >>>> >>>> On 11.08.2014 15:18, Igor Ignatyev wrote: >>>>> Andrey, >>>>> >>>>> could you please look at and fix other tests which use whitebox? >>>>> >>>>> $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox" ./test | >>>>> wc -l >>>>> 139 >>>>> $ grep -Rl --exclude-dir=testlibrary >>>>> "sun.hotspot.WhiteBox\$WhiteBoxPermission" ./test/ | wc -l >>>>> 10 >>>>> >>>>> Thanks >>>>> Igor >>>>> >>>>> On 08/11/2014 03:09 PM, Andrey Zakharov wrote: >>>>>> Hi, all >>>>>> >>>>>> Is it possible to review this below >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>> >>>>>> Thanks. >>>>>> >>>>>> On 28.07.2014 18:51, Andrey Zakharov wrote: >>>>>>> Hi, all. >>>>>>> I've prepared rechecked and verified fix for subject. >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>> >>>>>>> I've grep'ed workspace by sun.hotspot.WhiteBox and fixed every file. >>>>>>> Also I've updated copyright. >>>>>>> Testing was done by aurora batch 538304.ute.hs_jtreg.accept.full >>>>>>> It looks good. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> On 16.07.2014 15:13, Andrey Zakharov wrote: >>>>>>>> On 16.07.2014 14:39, Erik Helin wrote: >>>>>>>>> On Tuesday 15 July 2014 19:26:34 PM Andrey Zakharov wrote: >>>>>>>>>> Hi, Erik, Bengt. Could you, please, review this too. >>>>>>>>> Andrey, why did you only update a couple of tests to also copy >>>>>>>>> sun.hotspot.WhiteBox$WhiteBoxPermission? You updated 14 tests, >>>>>>>>> there are >>>>>>>>> still 116 tests using sun.hotspot.WhiteBox. >>>>>>>>> >>>>>>>>> Why doesn't these 116 tests have to be updated? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Erik >>>>>>>> Thanks Erik. Actually this first one patch 8011397.WhiteBoxPermission >>>>>>>> >>>>>>> xPermission> >>>>>>>> >>>>>>>> is correct. I will rework it and upload to webrev space. >>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> On 15.07.2014 17:58, Mikael Gerdin wrote: >>>>>>>>>>> Andrey, >>>>>>>>>>> >>>>>>>>>>> On Monday 07 July 2014 20.48.21 Andrey Zakharov wrote: >>>>>>>>>>>> Hi ,all >>>>>>>>>>>> Mikael, can you please review it. >>>>>>>>>>> Sorry, I was on vacation last week. >>>>>>>>>>> >>>>>>>>>>>> webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ >>>>>>>>>>> Looks ok for now. We should consider revisiting this by either >>>>>>>>>>> switching >>>>>>>>>>> to >>>>>>>>>>> @run main/bootclasspath >>>>>>>>>>> or >>>>>>>>>>> deleting the WhiteboxPermission nested class and using some >>>>>>>>>>> other way for >>>>>>>>>>> permission checks (if they are at all needed). >>>>>>>>>>> >>>>>>>>>>> /Mikael >>>>>>>>>>> >>>>>>>>>>>> Thanks. >>>>>>>>>>>> >>>>>>>>>>>> On 25.06.2014 19:08, Andrey Zakharov wrote: >>>>>>>>>>>>> Hi, all >>>>>>>>>>>>> So in progress of previous email - >>>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks. >>>>>>>>>>>>> >>>>>>>>>>>>> On 16.06.2014 19:57, Andrey Zakharov wrote: >>>>>>>>>>>>>> Hi, all >>>>>>>>>>>>>> So issue is that when tests with WhiteBox API has been >>>>>>>>>>>>>> invoked with >>>>>>>>>>>>>> -Xverify:all it fails with Exception >>>>>>>>>>>>>> java.lang.NoClassDefFoundError: >>>>>>>>>>>>>> sun/hotspot/WhiteBox$WhiteBoxPermission >>>>>>>>>>>>>> Solutions that are observed: >>>>>>>>>>>>>> 1. Copy WhiteBoxPermission with WhiteBox. But >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Perhaps this is a good time to get rid of ClassFileInstaller >>>>>>>>>>>>>> altogether? >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2. Using bootclasspath to hook pre-built whitebox (due @library >>>>>>>>>>>>>> /testlibrary/whitebox) . Some tests has @run main/othervm, >>>>>>>>>>>>>> some uses >>>>>>>>>>>>>> ProcessBuilder. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - main/othervm/bootclasspath adds ${test.src} and >>>>>>>>>>>>>> >>>>>>>>>>>>>> ${test.classes}to options. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - With ProcessBuilder we can just add ${test.classes} >>>>>>>>>>>>>> >>>>>>>>>>>>>> Question here is, can it broke some tests ? While testing >>>>>>>>>>>>>> this, I >>>>>>>>>>>>>> found onlyhttps://bugs.openjdk.java.net/browse/JDK-8046231, >>>>>>>>>>>>>> others >>>>>>>>>>>>>> looks fine. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3. Make ClassFileInstaller deal with inner classes like that: >>>>>>>>>>>>>> diff -r 6ed24aedeef0 -r c01651363ba8 >>>>>>>>>>>>>> test/testlibrary/ClassFileInstaller.java >>>>>>>>>>>>>> --- a/test/testlibrary/ClassFileInstaller.java Thu Jun 05 >>>>>>>>>>>>>> 19:02:56 >>>>>>>>>>>>>> 2014 +0400 >>>>>>>>>>>>>> +++ b/test/testlibrary/ClassFileInstaller.java Fri Jun 06 >>>>>>>>>>>>>> 18:18:11 >>>>>>>>>>>>>> 2014 +0400 >>>>>>>>>>>>>> @@ -50,6 +50,16 @@ >>>>>>>>>>>>>> >>>>>>>>>>>>>> } >>>>>>>>>>>>>> // Create the class file >>>>>>>>>>>>>> Files.copy(is, p, >>>>>>>>>>>>>> >>>>>>>>>>>>>> StandardCopyOption.REPLACE_EXISTING); >>>>>>>>>>>>>> >>>>>>>>>>>>>> + >>>>>>>>>>>>>> + for (Class cls : >>>>>>>>>>>>>> Class.forName(arg).getDeclaredClasses()) { >>>>>>>>>>>>>> + //if >>>>>>>>>>>>>> (!Modifier.isStatic(cls.getModifiers())) { >>>>>>>>>>>>>> + String pathNameSub = >>>>>>>>>>>>>> cls.getCanonicalName().replace('.', '/').concat(".class"); >>>>>>>>>>>>>> + Path pathSub = Paths.get(pathNameSub); >>>>>>>>>>>>>> + InputStream streamSub = >>>>>>>>>>>>>> cl.getResourceAsStream(pathNameSub); >>>>>>>>>>>>>> + Files.copy(streamSub, pathSub, >>>>>>>>>>>>>> StandardCopyOption.REPLACE_EXISTING); >>>>>>>>>>>>>> + //} >>>>>>>>>>>>>> + } >>>>>>>>>>>>>> + >>>>>>>>>>>>>> >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> Works fine for ordinary classes, but fails for WhiteBox due >>>>>>>>>>>>>> Class.forName initiate Class. WhiteBox has "static" section, >>>>>>>>>>>>>> and >>>>>>>>>>>>>> initialization fails as it cannot bind to native methods >>>>>>>>>>>>>> "registerNatives" and so on. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> So, lets return to first one option? Just add everywhere >>>>>>>>>>>>>> >>>>>>>>>>>>>> * @run main ClassFileInstaller sun.hotspot.WhiteBox >>>>>>>>>>>>>> >>>>>>>>>>>>>> + * @run main ClassFileInstaller >>>>>>>>>>>>>> sun.hotspot.WhiteBox$WhiteBoxPermission >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 10.06.2014 19:43, Igor Ignatyev wrote: >>>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I don't like this idea, since it completely changes the tests. >>>>>>>>>>>>>>> 'run/othervm/bootclasspath' adds all paths from CP to BCP, >>>>>>>>>>>>>>> so the >>>>>>>>>>>>>>> tests whose main idea was testing WB methods themselves >>>>>>>>>>>>>>> (sanity, >>>>>>>>>>>>>>> compiler/whitebox, ...) don't check that it's possible to >>>>>>>>>>>>>>> use WB >>>>>>>>>>>>>>> when the application isn't in BCP. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Igor >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 06/09/2014 06:59 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>>> Hi, everybody >>>>>>>>>>>>>>>> I have tested my changes on major platforms and found one >>>>>>>>>>>>>>>> bug, filed: >>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046231 >>>>>>>>>>>>>>>> Also, i did another try to make ClassFileInstaller to copy >>>>>>>>>>>>>>>> all inner >>>>>>>>>>>>>>>> classes within parent, but this fails for WhiteBox due its >>>>>>>>>>>>>>>> static >>>>>>>>>>>>>>>> "registerNatives" dependency. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please, review suggested changes: >>>>>>>>>>>>>>>> - replace ClassFileInstaller and run/othervm with >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> "run/othervm/bootclasspath". >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> bootclasspath parameter for othervm >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> adds-Xbootclasspath/a: >>>>>>>>>>>>>>>> option with ${test.src} and ${test.classes}according to >>>>>>>>>>>>>>>> http://hg.openjdk.java.net/code-tools/jtreg/file/31003a1c46d9/ >>>>>>>>>>>>>>>> src/sha >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> re >>>>>>>>>>>>>>>> /classes/com/sun/javatest/regtest/MainAction.java. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is this suitable for our needs - give to test compiled >>>>>>>>>>>>>>>> WhiteBox? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - replace explicit -Xbootclasspath option values (".") in >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ProcessBuilder invocations to ${test.classes} where >>>>>>>>>>>>>>>> WhiteBox has been >>>>>>>>>>>>>>>> compiled. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev. >>>>>>>>>>>>>>>> 00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 23.05.2014 15:40, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>> On 22.05.2014 12:47, Igor Ignatyev wrote: >>>>>>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 1. You changed dozen of tests, have you tested your >>>>>>>>>>>>>>>>>> changes? >>>>>>>>>>>>>>>>> Locally, aurora on the way. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2. Your changes of year in copyright is wrong. it has to be >>>>>>>>>>>>>>>>>> $first_year, [$last_year, ], see Mark's email[1] for >>>>>>>>>>>>>>>>>> details. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/jdk7-dev/2010-May/001 >>>>>>>>>>>>>>>>>> 321.htm >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> l >>>>>>>>>>>>>>>>> Thanks, fixed. will be uploaded soon. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Igor >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 05/21/2014 07:37 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>>> On 13.05.2014 14:43, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>>>>>>> So here is trivial patch - >>>>>>>>>>>>>>>>>>>> removing ClassFileInstaller sun.hotspot.WhiteBox and >>>>>>>>>>>>>>>>>>>> adding >>>>>>>>>>>>>>>>>>>> main/othervm/bootclasspath >>>>>>>>>>>>>>>>>>>> where this needed >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Also, some tests are modified as >>>>>>>>>>>>>>>>>>>> - "-Xbootclasspath/a:.", >>>>>>>>>>>>>>>>>>>> + "-Xbootclasspath/a:" + >>>>>>>>>>>>>>>>>>>> System.getProperty("test.classes"), >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>> webrev:http://cr.openjdk.java.net/~jwilhelm/8011397/webrev. >>>>>>>>>>>>>>>>>>> 02/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 09.05.2014 12:13, Mikael Gerdin wrote: >>>>>>>>>>>>>>>>>>>>> On Thursday 08 May 2014 19.28.13 Igor Ignatyev wrote: >>>>>>>>>>>>>>>>>>>>>> // cc'ing hotspot-dev instaed of compiler, runtime >>>>>>>>>>>>>>>>>>>>>> and gc >>>>>>>>>>>>>>>>>>>>>> lists. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 05/08/2014 07:09 PM, Filipp Zhinkin wrote: >>>>>>>>>>>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I've CC'ed compiler and runtime mailing list, >>>>>>>>>>>>>>>>>>>>>>> because you're >>>>>>>>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>>>>>>>>> affect test for other components as too. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I don't like your solution (but I'm not a reviewer, >>>>>>>>>>>>>>>>>>>>>>> so treat >>>>>>>>>>>>>>>>>>>>>>> my >>>>>>>>>>>>>>>>>>>>>>> words >>>>>>>>>>>>>>>>>>>>>>> just as suggestion), >>>>>>>>>>>>>>>>>>>>>>> because we'll have to write more meta information >>>>>>>>>>>>>>>>>>>>>>> for each >>>>>>>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>>>>>>> and it >>>>>>>>>>>>>>>>>>>>>>> is very easy to >>>>>>>>>>>>>>>>>>>>>>> forget to install WhiteBoxPermission if you don't >>>>>>>>>>>>>>>>>>>>>>> test your >>>>>>>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>>>> some security manager. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> From my point of view, it will be better to extend >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> ClassFileInstaller >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> so it will copy not only >>>>>>>>>>>>>>>>>>>>>>> a class whose name was passed as an arguments, but >>>>>>>>>>>>>>>>>>>>>>> also all >>>>>>>>>>>>>>>>>>>>>>> inner >>>>>>>>>>>>>>>>>>>>>>> classes of that class. >>>>>>>>>>>>>>>>>>>>>>> And if someone want copy only specified class >>>>>>>>>>>>>>>>>>>>>>> without inner >>>>>>>>>>>>>>>>>>>>>>> classes, >>>>>>>>>>>>>>>>>>>>>>> then some option >>>>>>>>>>>>>>>>>>>>>>> could be added to ClassFileInstaller to force such >>>>>>>>>>>>>>>>>>>>>>> behaviour. >>>>>>>>>>>>>>>>>>>>> Perhaps this is a good time to get rid of >>>>>>>>>>>>>>>>>>>>> ClassFileInstaller >>>>>>>>>>>>>>>>>>>>> altogether? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8009117 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The reason for its existence is that the WhiteBox >>>>>>>>>>>>>>>>>>>>> class needs >>>>>>>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>>>>>>> boot class path. >>>>>>>>>>>>>>>>>>>>> If we can live with having all the test's classes on >>>>>>>>>>>>>>>>>>>>> the boot >>>>>>>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>>>>>>> path then >>>>>>>>>>>>>>>>>>>>> we could use the /bootclasspath option in jtreg as >>>>>>>>>>>>>>>>>>>>> stated in >>>>>>>>>>>>>>>>>>>>> the RFE. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> /Mikael >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> Filipp. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 05/08/2014 04:47 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>>>>>>>> Hi! >>>>>>>>>>>>>>>>>>>>>>>> Suggesting patch with fixes for >>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20275/ >>>>>>>>>>>>>>>>>>>>>>>> 8011397 >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> .t >>>>>>>>>>>>>>>>>>>>>>>> gz >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> patch: >>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20274/ >>>>>>>>>>>>>>>>>>>>>>>> 8011397 >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> .W >>>>>>>>>>>>>>>>>>>>>>>> hiteBoxPer >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> mission >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks. From christian.thalinger at oracle.com Thu Aug 21 17:29:48 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 21 Aug 2014 10:29:48 -0700 Subject: RFR: 8011397: JTREG needs to copy additional WhiteBox class file to JTwork/scratch/sun/hotspot In-Reply-To: <53F626D2.2020606@oracle.com> References: <536B7CF0.6010508@oracle.com> <53E8A8FB.2080505@oracle.com> <53E8CB69.5010003@oracle.com> <1904344.AZu4ofu3BO@mgerdin03> <53F626D2.2020606@oracle.com> Message-ID: <5170524B-A9C3-4313-8940-F3584AF2B3C6@oracle.com> On Aug 21, 2014, at 10:05 AM, Andrey Zakharov wrote: > Hi, Christian. > Sure. Let me quote my own email from this thread: > >> Hi, all >> So issue is that when tests with WhiteBox API has been invoked with -Xverify:all it fails with Exception java.lang.NoClassDefFoundError: sun/hotspot/WhiteBox$WhiteBoxPermission >> Solutions that are observed: >> 1. Copy WhiteBoxPermission with WhiteBox. But >> >> Perhaps this is a good time to get rid of ClassFileInstaller altogether? What would be the replacement for ClassFileInstaller? One of the options below? >> >> 2. Using bootclasspath to hook pre-built whitebox (due @library /testlibrary/whitebox) . Some tests has @run main/othervm, some uses ProcessBuilder. >> - main/othervm/bootclasspath adds ${test.src} and ${test.classes}to options. >> - With ProcessBuilder we can just add ${test.classes} >> Question here is, can it broke some tests ? While testing this, I found only https://bugs.openjdk.java.net/browse/JDK-8046231, others looks fine. Why did it break? >> >> 3. Make ClassFileInstaller deal with inner classes like that: >> diff -r 6ed24aedeef0 -r c01651363ba8 test/testlibrary/ClassFileInstaller.java >> --- a/test/testlibrary/ClassFileInstaller.java Thu Jun 05 19:02:56 2014 +0400 >> +++ b/test/testlibrary/ClassFileInstaller.java Fri Jun 06 18:18:11 2014 +0400 >> @@ -50,6 +50,16 @@ >> } >> // Create the class file >> Files.copy(is, p, StandardCopyOption.REPLACE_EXISTING); >> + >> + for (Class cls : Class.forName(arg).getDeclaredClasses()) { >> + //if (!Modifier.isStatic(cls.getModifiers())) { >> + String pathNameSub = cls.getCanonicalName().replace('.', '/').concat(".class"); >> + Path pathSub = Paths.get(pathNameSub); >> + InputStream streamSub = cl.getResourceAsStream(pathNameSub); >> + Files.copy(streamSub, pathSub, StandardCopyOption.REPLACE_EXISTING); >> + //} >> + } >> + >> } >> } >> } >> >> Works fine for ordinary classes, but fails for WhiteBox due Class.forName initiate Class. WhiteBox has "static" section, and initialization fails as it cannot bind to native methods "registerNatives" and so on. Could that be fixed? >> >> >> So, lets return to first one option? Just add everywhere >> * @run main ClassFileInstaller sun.hotspot.WhiteBox >> + * @run main ClassFileInstaller sun.hotspot.WhiteBox$WhiteBoxPermission >> >> Thanks. >> > > If you have any suggestions, please share it. > Thanks. > > > On 21.08.2014 19:58, Christian Thalinger wrote: >> Sorry I missed this review but I don?t think that?s a good way to handle this issue; this just doesn?t scale. What if someone adds another inner-class to WhiteBox? Do we have to update all tests again? >> >> On Aug 12, 2014, at 4:42 AM, Mikael Gerdin wrote: >> >>> On Monday 11 August 2014 17.55.53 Andrey Zakharov wrote: >>>> Hi, all >>>> Here is updated patch with recent added tests: >>>> >>>> * ./test/compiler/classUnloading/methodUnloading/TestMethodUnloading.java >>>> * ./test/gc/class_unloading/TestCMSClassUnloadingEnabledHWM.java >>>> * ./test/gc/class_unloading/TestG1ClassUnloadingHWM.java >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.04/ >>> Ok, >>> >>> /Mikael >>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>> >>>> Thanks. >>>> >>>> On 11.08.2014 15:28, Andrey Zakharov wrote: >>>>> Hi, Igor. >>>>> I have another counts with applied patch, but it looks like couple of >>>>> tests has beed added since last check. >>>>> >>>>> $ grep -Rl --exclude-dir=testlibrary >>>>> "sun.hotspot.WhiteBox\$WhiteBoxPermission" ./test/| wc -l >>>>> 133 >>>>> >>>>> $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox" ./test/| >>>>> wc -l >>>>> 142 >>>>> >>>>> Will update patch soon. >>>>> Thanks. >>>>> >>>>> On 11.08.2014 15:18, Igor Ignatyev wrote: >>>>>> Andrey, >>>>>> >>>>>> could you please look at and fix other tests which use whitebox? >>>>>> >>>>>> $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox" ./test | >>>>>> wc -l >>>>>> 139 >>>>>> $ grep -Rl --exclude-dir=testlibrary >>>>>> "sun.hotspot.WhiteBox\$WhiteBoxPermission" ./test/ | wc -l >>>>>> 10 >>>>>> >>>>>> Thanks >>>>>> Igor >>>>>> >>>>>> On 08/11/2014 03:09 PM, Andrey Zakharov wrote: >>>>>>> Hi, all >>>>>>> >>>>>>> Is it possible to review this below >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> On 28.07.2014 18:51, Andrey Zakharov wrote: >>>>>>>> Hi, all. >>>>>>>> I've prepared rechecked and verified fix for subject. >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ >>>>>>>> Bug: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>> >>>>>>>> I've grep'ed workspace by sun.hotspot.WhiteBox and fixed every file. >>>>>>>> Also I've updated copyright. >>>>>>>> Testing was done by aurora batch 538304.ute.hs_jtreg.accept.full >>>>>>>> It looks good. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> On 16.07.2014 15:13, Andrey Zakharov wrote: >>>>>>>>> On 16.07.2014 14:39, Erik Helin wrote: >>>>>>>>>> On Tuesday 15 July 2014 19:26:34 PM Andrey Zakharov wrote: >>>>>>>>>>> Hi, Erik, Bengt. Could you, please, review this too. >>>>>>>>>> Andrey, why did you only update a couple of tests to also copy >>>>>>>>>> sun.hotspot.WhiteBox$WhiteBoxPermission? You updated 14 tests, >>>>>>>>>> there are >>>>>>>>>> still 116 tests using sun.hotspot.WhiteBox. >>>>>>>>>> >>>>>>>>>> Why doesn't these 116 tests have to be updated? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Erik >>>>>>>>> Thanks Erik. Actually this first one patch 8011397.WhiteBoxPermission >>>>>>>>> >>>>>>>> xPermission> >>>>>>>>> >>>>>>>>> is correct. I will rework it and upload to webrev space. >>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> On 15.07.2014 17:58, Mikael Gerdin wrote: >>>>>>>>>>>> Andrey, >>>>>>>>>>>> >>>>>>>>>>>> On Monday 07 July 2014 20.48.21 Andrey Zakharov wrote: >>>>>>>>>>>>> Hi ,all >>>>>>>>>>>>> Mikael, can you please review it. >>>>>>>>>>>> Sorry, I was on vacation last week. >>>>>>>>>>>> >>>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ >>>>>>>>>>>> Looks ok for now. We should consider revisiting this by either >>>>>>>>>>>> switching >>>>>>>>>>>> to >>>>>>>>>>>> @run main/bootclasspath >>>>>>>>>>>> or >>>>>>>>>>>> deleting the WhiteboxPermission nested class and using some >>>>>>>>>>>> other way for >>>>>>>>>>>> permission checks (if they are at all needed). >>>>>>>>>>>> >>>>>>>>>>>> /Mikael >>>>>>>>>>>> >>>>>>>>>>>>> Thanks. >>>>>>>>>>>>> >>>>>>>>>>>>> On 25.06.2014 19:08, Andrey Zakharov wrote: >>>>>>>>>>>>>> Hi, all >>>>>>>>>>>>>> So in progress of previous email - >>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 16.06.2014 19:57, Andrey Zakharov wrote: >>>>>>>>>>>>>>> Hi, all >>>>>>>>>>>>>>> So issue is that when tests with WhiteBox API has been >>>>>>>>>>>>>>> invoked with >>>>>>>>>>>>>>> -Xverify:all it fails with Exception >>>>>>>>>>>>>>> java.lang.NoClassDefFoundError: >>>>>>>>>>>>>>> sun/hotspot/WhiteBox$WhiteBoxPermission >>>>>>>>>>>>>>> Solutions that are observed: >>>>>>>>>>>>>>> 1. Copy WhiteBoxPermission with WhiteBox. But >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Perhaps this is a good time to get rid of ClassFileInstaller >>>>>>>>>>>>>>> altogether? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2. Using bootclasspath to hook pre-built whitebox (due @library >>>>>>>>>>>>>>> /testlibrary/whitebox) . Some tests has @run main/othervm, >>>>>>>>>>>>>>> some uses >>>>>>>>>>>>>>> ProcessBuilder. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - main/othervm/bootclasspath adds ${test.src} and >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ${test.classes}to options. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - With ProcessBuilder we can just add ${test.classes} >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Question here is, can it broke some tests ? While testing >>>>>>>>>>>>>>> this, I >>>>>>>>>>>>>>> found onlyhttps://bugs.openjdk.java.net/browse/JDK-8046231, >>>>>>>>>>>>>>> others >>>>>>>>>>>>>>> looks fine. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 3. Make ClassFileInstaller deal with inner classes like that: >>>>>>>>>>>>>>> diff -r 6ed24aedeef0 -r c01651363ba8 >>>>>>>>>>>>>>> test/testlibrary/ClassFileInstaller.java >>>>>>>>>>>>>>> --- a/test/testlibrary/ClassFileInstaller.java Thu Jun 05 >>>>>>>>>>>>>>> 19:02:56 >>>>>>>>>>>>>>> 2014 +0400 >>>>>>>>>>>>>>> +++ b/test/testlibrary/ClassFileInstaller.java Fri Jun 06 >>>>>>>>>>>>>>> 18:18:11 >>>>>>>>>>>>>>> 2014 +0400 >>>>>>>>>>>>>>> @@ -50,6 +50,16 @@ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> // Create the class file >>>>>>>>>>>>>>> Files.copy(is, p, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> StandardCopyOption.REPLACE_EXISTING); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> + >>>>>>>>>>>>>>> + for (Class cls : >>>>>>>>>>>>>>> Class.forName(arg).getDeclaredClasses()) { >>>>>>>>>>>>>>> + //if >>>>>>>>>>>>>>> (!Modifier.isStatic(cls.getModifiers())) { >>>>>>>>>>>>>>> + String pathNameSub = >>>>>>>>>>>>>>> cls.getCanonicalName().replace('.', '/').concat(".class"); >>>>>>>>>>>>>>> + Path pathSub = Paths.get(pathNameSub); >>>>>>>>>>>>>>> + InputStream streamSub = >>>>>>>>>>>>>>> cl.getResourceAsStream(pathNameSub); >>>>>>>>>>>>>>> + Files.copy(streamSub, pathSub, >>>>>>>>>>>>>>> StandardCopyOption.REPLACE_EXISTING); >>>>>>>>>>>>>>> + //} >>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>> + >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Works fine for ordinary classes, but fails for WhiteBox due >>>>>>>>>>>>>>> Class.forName initiate Class. WhiteBox has "static" section, >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> initialization fails as it cannot bind to native methods >>>>>>>>>>>>>>> "registerNatives" and so on. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So, lets return to first one option? Just add everywhere >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * @run main ClassFileInstaller sun.hotspot.WhiteBox >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> + * @run main ClassFileInstaller >>>>>>>>>>>>>>> sun.hotspot.WhiteBox$WhiteBoxPermission >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 10.06.2014 19:43, Igor Ignatyev wrote: >>>>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I don't like this idea, since it completely changes the tests. >>>>>>>>>>>>>>>> 'run/othervm/bootclasspath' adds all paths from CP to BCP, >>>>>>>>>>>>>>>> so the >>>>>>>>>>>>>>>> tests whose main idea was testing WB methods themselves >>>>>>>>>>>>>>>> (sanity, >>>>>>>>>>>>>>>> compiler/whitebox, ...) don't check that it's possible to >>>>>>>>>>>>>>>> use WB >>>>>>>>>>>>>>>> when the application isn't in BCP. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Igor >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 06/09/2014 06:59 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>> Hi, everybody >>>>>>>>>>>>>>>>> I have tested my changes on major platforms and found one >>>>>>>>>>>>>>>>> bug, filed: >>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046231 >>>>>>>>>>>>>>>>> Also, i did another try to make ClassFileInstaller to copy >>>>>>>>>>>>>>>>> all inner >>>>>>>>>>>>>>>>> classes within parent, but this fails for WhiteBox due its >>>>>>>>>>>>>>>>> static >>>>>>>>>>>>>>>>> "registerNatives" dependency. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please, review suggested changes: >>>>>>>>>>>>>>>>> - replace ClassFileInstaller and run/othervm with >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> "run/othervm/bootclasspath". >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> bootclasspath parameter for othervm >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> adds-Xbootclasspath/a: >>>>>>>>>>>>>>>>> option with ${test.src} and ${test.classes}according to >>>>>>>>>>>>>>>>> http://hg.openjdk.java.net/code-tools/jtreg/file/31003a1c46d9/ >>>>>>>>>>>>>>>>> src/sha >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> re >>>>>>>>>>>>>>>>> /classes/com/sun/javatest/regtest/MainAction.java. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Is this suitable for our needs - give to test compiled >>>>>>>>>>>>>>>>> WhiteBox? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - replace explicit -Xbootclasspath option values (".") in >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ProcessBuilder invocations to ${test.classes} where >>>>>>>>>>>>>>>>> WhiteBox has been >>>>>>>>>>>>>>>>> compiled. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev. >>>>>>>>>>>>>>>>> 00/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 23.05.2014 15:40, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>> On 22.05.2014 12:47, Igor Ignatyev wrote: >>>>>>>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 1. You changed dozen of tests, have you tested your >>>>>>>>>>>>>>>>>>> changes? >>>>>>>>>>>>>>>>>> Locally, aurora on the way. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 2. Your changes of year in copyright is wrong. it has to be >>>>>>>>>>>>>>>>>>> $first_year, [$last_year, ], see Mark's email[1] for >>>>>>>>>>>>>>>>>>> details. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/jdk7-dev/2010-May/001 >>>>>>>>>>>>>>>>>>> 321.htm >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> l >>>>>>>>>>>>>>>>>> Thanks, fixed. will be uploaded soon. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Igor >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 05/21/2014 07:37 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>>>> On 13.05.2014 14:43, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>>>>>>>> So here is trivial patch - >>>>>>>>>>>>>>>>>>>>> removing ClassFileInstaller sun.hotspot.WhiteBox and >>>>>>>>>>>>>>>>>>>>> adding >>>>>>>>>>>>>>>>>>>>> main/othervm/bootclasspath >>>>>>>>>>>>>>>>>>>>> where this needed >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Also, some tests are modified as >>>>>>>>>>>>>>>>>>>>> - "-Xbootclasspath/a:.", >>>>>>>>>>>>>>>>>>>>> + "-Xbootclasspath/a:" + >>>>>>>>>>>>>>>>>>>>> System.getProperty("test.classes"), >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>>> webrev:http://cr.openjdk.java.net/~jwilhelm/8011397/webrev. >>>>>>>>>>>>>>>>>>>> 02/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 09.05.2014 12:13, Mikael Gerdin wrote: >>>>>>>>>>>>>>>>>>>>>> On Thursday 08 May 2014 19.28.13 Igor Ignatyev wrote: >>>>>>>>>>>>>>>>>>>>>>> // cc'ing hotspot-dev instaed of compiler, runtime >>>>>>>>>>>>>>>>>>>>>>> and gc >>>>>>>>>>>>>>>>>>>>>>> lists. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 05/08/2014 07:09 PM, Filipp Zhinkin wrote: >>>>>>>>>>>>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I've CC'ed compiler and runtime mailing list, >>>>>>>>>>>>>>>>>>>>>>>> because you're >>>>>>>>>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>>>>>>>>>> affect test for other components as too. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I don't like your solution (but I'm not a reviewer, >>>>>>>>>>>>>>>>>>>>>>>> so treat >>>>>>>>>>>>>>>>>>>>>>>> my >>>>>>>>>>>>>>>>>>>>>>>> words >>>>>>>>>>>>>>>>>>>>>>>> just as suggestion), >>>>>>>>>>>>>>>>>>>>>>>> because we'll have to write more meta information >>>>>>>>>>>>>>>>>>>>>>>> for each >>>>>>>>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>>>>>>>> and it >>>>>>>>>>>>>>>>>>>>>>>> is very easy to >>>>>>>>>>>>>>>>>>>>>>>> forget to install WhiteBoxPermission if you don't >>>>>>>>>>>>>>>>>>>>>>>> test your >>>>>>>>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>>>>> some security manager. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> From my point of view, it will be better to extend >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> ClassFileInstaller >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> so it will copy not only >>>>>>>>>>>>>>>>>>>>>>>> a class whose name was passed as an arguments, but >>>>>>>>>>>>>>>>>>>>>>>> also all >>>>>>>>>>>>>>>>>>>>>>>> inner >>>>>>>>>>>>>>>>>>>>>>>> classes of that class. >>>>>>>>>>>>>>>>>>>>>>>> And if someone want copy only specified class >>>>>>>>>>>>>>>>>>>>>>>> without inner >>>>>>>>>>>>>>>>>>>>>>>> classes, >>>>>>>>>>>>>>>>>>>>>>>> then some option >>>>>>>>>>>>>>>>>>>>>>>> could be added to ClassFileInstaller to force such >>>>>>>>>>>>>>>>>>>>>>>> behaviour. >>>>>>>>>>>>>>>>>>>>>> Perhaps this is a good time to get rid of >>>>>>>>>>>>>>>>>>>>>> ClassFileInstaller >>>>>>>>>>>>>>>>>>>>>> altogether? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8009117 >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> The reason for its existence is that the WhiteBox >>>>>>>>>>>>>>>>>>>>>> class needs >>>>>>>>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>>>>>>>> boot class path. >>>>>>>>>>>>>>>>>>>>>> If we can live with having all the test's classes on >>>>>>>>>>>>>>>>>>>>>> the boot >>>>>>>>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>>>>>>>> path then >>>>>>>>>>>>>>>>>>>>>> we could use the /bootclasspath option in jtreg as >>>>>>>>>>>>>>>>>>>>>> stated in >>>>>>>>>>>>>>>>>>>>>> the RFE. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> /Mikael >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>> Filipp. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On 05/08/2014 04:47 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>>>>>>>>> Hi! >>>>>>>>>>>>>>>>>>>>>>>>> Suggesting patch with fixes for >>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20275/ >>>>>>>>>>>>>>>>>>>>>>>>> 8011397 >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> .t >>>>>>>>>>>>>>>>>>>>>>>>> gz >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> patch: >>>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20274/ >>>>>>>>>>>>>>>>>>>>>>>>> 8011397 >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> .W >>>>>>>>>>>>>>>>>>>>>>>>> hiteBoxPer >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> mission >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks. > From daniel.daugherty at oracle.com Thu Aug 21 17:43:07 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 21 Aug 2014 11:43:07 -0600 Subject: RFR[P1]: 8055744 - 8u-dev nightly solaris builds failed on 08/20 In-Reply-To: <53F626BA.70204@oracle.com> References: <53F61C09.4060300@oracle.com> <53F62164.2030001@oracle.com> <53F626BA.70204@oracle.com> Message-ID: <53F62FAB.3090606@oracle.com> > http://cr.openjdk.java.net/~jwilhelm/8055744/webrev.02/ make/solaris/Makefile No comments. make/solaris/makefiles/buildtree.make No comments. A product build with the above changes shows this: $ cat solaris_amd64_compiler2/product/mapfile_ext # Extended set of symbols. JVM_SetVmMemoryPressure; Looks right to me. Dan On 8/21/14 11:04 AM, Jesper Wilhelmsson wrote: > Thank you for the quick reply Dan! > > A new webrev with your suggested change is available here: > > http://cr.openjdk.java.net/~jwilhelm/8055744/webrev.02/ > > /Jesper > > > Daniel D. Daugherty skrev 21/8/14 18:42: >> On 8/21/14 10:19 AM, Jesper Wilhelmsson wrote: >>> Hi, >>> >>> On Solaris the HS_ALT_MAKE variable was not passed to vm.make when >>> creating >>> the mapfiles which lead to mapfile-ext not being found and later a >>> linker >>> error due to symbols declared in the extra mapfile not being found. >>> >>> The hotspot makefiles are .. interesting .. yes. >>> >>> The proposed solution is to include defs.make where HS_ALT_MAKE is >>> set up into >>> vm.make on Solaris. >>> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~jwilhelm/8055744/webrev/ >> >> Unfortunately, including defs.make in make/solaris/makefiles/vm.make >> isn't the "right" way to get a top-level variable down into the >> HotSpot build system. I cannot remember what breaks when you do that, >> but it doesn't work right in all the ways that we build HotSpot. >> >> For the HotSpot build system, you'll want to: >> >> - update make/solaris/Makefile and add HS_ALT_MAKE to >> the BUILDTREE_VARS list: >> >> BUILDTREE_VARS += HS_ALT_MAKE=$(HS_ALT_MAKE) >> >> - update make/solaris/makefiles/buildtree.make and add >> HS_ALT_MAKE to the rule that creates flags.make: >> >> [ -n "$(HS_ALT_MAKE)" ] && \ >> echo && echo "HS_ALT_MAKE = $(HS_ALT_MAKE)"; \ >> >> The way I usually find all the right spots is I look for >> where ZIPEXE is added to the above files and follow those >> examples. >> >> Dan >> >> >> >> >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8055744#comment-13542110 >>> >>> This is a P1 so if you feel comfortable with the hotspot makefiles, >>> please >>> have a look. >>> >>> Thanks! >>> /Jesper >> From jesper.wilhelmsson at oracle.com Thu Aug 21 18:09:29 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 21 Aug 2014 20:09:29 +0200 Subject: RFR[P1]: 8055744 - 8u-dev nightly solaris builds failed on 08/20 In-Reply-To: <53F62FAB.3090606@oracle.com> References: <53F61C09.4060300@oracle.com> <53F62164.2030001@oracle.com> <53F626BA.70204@oracle.com> <53F62FAB.3090606@oracle.com> Message-ID: <53F635D9.6000908@oracle.com> Yep, that's how it's supposed to look :) Thanks! /Jesper Daniel D. Daugherty skrev 21/8/14 19:43: > > http://cr.openjdk.java.net/~jwilhelm/8055744/webrev.02/ > > make/solaris/Makefile > No comments. > > make/solaris/makefiles/buildtree.make > No comments. > > A product build with the above changes shows this: > > $ cat solaris_amd64_compiler2/product/mapfile_ext > > # Extended set of symbols. > JVM_SetVmMemoryPressure; > > Looks right to me. > > Dan > > > On 8/21/14 11:04 AM, Jesper Wilhelmsson wrote: >> Thank you for the quick reply Dan! >> >> A new webrev with your suggested change is available here: >> >> http://cr.openjdk.java.net/~jwilhelm/8055744/webrev.02/ >> >> /Jesper >> >> >> Daniel D. Daugherty skrev 21/8/14 18:42: >>> On 8/21/14 10:19 AM, Jesper Wilhelmsson wrote: >>>> Hi, >>>> >>>> On Solaris the HS_ALT_MAKE variable was not passed to vm.make when creating >>>> the mapfiles which lead to mapfile-ext not being found and later a linker >>>> error due to symbols declared in the extra mapfile not being found. >>>> >>>> The hotspot makefiles are .. interesting .. yes. >>>> >>>> The proposed solution is to include defs.make where HS_ALT_MAKE is set up into >>>> vm.make on Solaris. >>>> >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~jwilhelm/8055744/webrev/ >>> >>> Unfortunately, including defs.make in make/solaris/makefiles/vm.make >>> isn't the "right" way to get a top-level variable down into the >>> HotSpot build system. I cannot remember what breaks when you do that, >>> but it doesn't work right in all the ways that we build HotSpot. >>> >>> For the HotSpot build system, you'll want to: >>> >>> - update make/solaris/Makefile and add HS_ALT_MAKE to >>> the BUILDTREE_VARS list: >>> >>> BUILDTREE_VARS += HS_ALT_MAKE=$(HS_ALT_MAKE) >>> >>> - update make/solaris/makefiles/buildtree.make and add >>> HS_ALT_MAKE to the rule that creates flags.make: >>> >>> [ -n "$(HS_ALT_MAKE)" ] && \ >>> echo && echo "HS_ALT_MAKE = $(HS_ALT_MAKE)"; \ >>> >>> The way I usually find all the right spots is I look for >>> where ZIPEXE is added to the above files and follow those >>> examples. >>> >>> Dan >>> >>> >>> >>> >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8055744#comment-13542110 >>>> >>>> This is a P1 so if you feel comfortable with the hotspot makefiles, please >>>> have a look. >>>> >>>> Thanks! >>>> /Jesper >>> > From tobias.hartmann at oracle.com Fri Aug 22 07:15:41 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 22 Aug 2014 09:15:41 +0200 Subject: [8u40] RFR(S): 8054402: "klass->is_loader_alive(_is_alive)) failed: must be alive" for anonymous classes In-Reply-To: <53F1A6A3.60509@oracle.com> References: <53F1A213.8020106@oracle.com> <53F1A64F.60009@oracle.com> <53F1A6A3.60509@oracle.com> Message-ID: <53F6EE1D.70409@oracle.com> Hi, due to JDK-8055751 [1] I had to fix the backport. I added the class 'sun.hotspot.WhiteBox$WhiteBoxPermission' to the tests ClassFileInstaller. New webrev: http://cr.openjdk.java.net/~thartmann/8054402_8u/webrev.00/ Thanks, Tobias [1] https://bugs.openjdk.java.net/browse/JDK-8055751 On 18.08.2014 09:09, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review. I"ll wait for another nightly before pushing. > > Best, > Tobias > > On 18.08.2014 09:07, Vladimir Kozlov wrote: >> Looks good. Please, wait at least one more Nightly. >> >> Thanks, >> Vladimir >> >> On 8/17/14 11:49 PM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review this 8u40 backport request. The changes were pushed on >>> Thursday. >>> >>> Nightly testing showed no problems. The patch applies cleanly to 8u40. >>> >>> Master bug: https://bugs.openjdk.java.net/browse/JDK-8054402 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8054402/webrev.01/ >>> Changeset: >>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/cf3ccda01fa6 >>> >>> Thanks, >>> Tobias > From stefan.karlsson at oracle.com Fri Aug 22 07:51:14 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 22 Aug 2014 09:51:14 +0200 Subject: RFR: 8011397: JTREG needs to copy additional WhiteBox class file to JTwork/scratch/sun/hotspot In-Reply-To: References: <536B7CF0.6010508@oracle.com> <53E8A8FB.2080505@oracle.com> <53E8CB69.5010003@oracle.com> <1904344.AZu4ofu3BO@mgerdin03> Message-ID: <53F6F672.1000706@oracle.com> Would it make sense to create a WhiteBoxInstaller and have the class lists/logic inside that file instead? If we ever have to add more files, we would just have to fix one file. StefanK On 2014-08-21 17:58, Christian Thalinger wrote: > Sorry I missed this review but I don?t think that?s a good way to handle this issue; this just doesn?t scale. What if someone adds another inner-class to WhiteBox? Do we have to update all tests again? > > On Aug 12, 2014, at 4:42 AM, Mikael Gerdin wrote: > >> On Monday 11 August 2014 17.55.53 Andrey Zakharov wrote: >>> Hi, all >>> Here is updated patch with recent added tests: >>> >>> * ./test/compiler/classUnloading/methodUnloading/TestMethodUnloading.java >>> * ./test/gc/class_unloading/TestCMSClassUnloadingEnabledHWM.java >>> * ./test/gc/class_unloading/TestG1ClassUnloadingHWM.java >>> >>> webrev: >>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.04/ >> Ok, >> >> /Mikael >> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>> >>> Thanks. >>> >>> On 11.08.2014 15:28, Andrey Zakharov wrote: >>>> Hi, Igor. >>>> I have another counts with applied patch, but it looks like couple of >>>> tests has beed added since last check. >>>> >>>> $ grep -Rl --exclude-dir=testlibrary >>>> "sun.hotspot.WhiteBox\$WhiteBoxPermission" ./test/| wc -l >>>> 133 >>>> >>>> $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox" ./test/| >>>> wc -l >>>> 142 >>>> >>>> Will update patch soon. >>>> Thanks. >>>> >>>> On 11.08.2014 15:18, Igor Ignatyev wrote: >>>>> Andrey, >>>>> >>>>> could you please look at and fix other tests which use whitebox? >>>>> >>>>> $ grep -Rl --exclude-dir=testlibrary "sun.hotspot.WhiteBox" ./test | >>>>> wc -l >>>>> 139 >>>>> $ grep -Rl --exclude-dir=testlibrary >>>>> "sun.hotspot.WhiteBox\$WhiteBoxPermission" ./test/ | wc -l >>>>> 10 >>>>> >>>>> Thanks >>>>> Igor >>>>> >>>>> On 08/11/2014 03:09 PM, Andrey Zakharov wrote: >>>>>> Hi, all >>>>>> >>>>>> Is it possible to review this below >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>> >>>>>> Thanks. >>>>>> >>>>>> On 28.07.2014 18:51, Andrey Zakharov wrote: >>>>>>> Hi, all. >>>>>>> I've prepared rechecked and verified fix for subject. >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.03/ >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>> >>>>>>> I've grep'ed workspace by sun.hotspot.WhiteBox and fixed every file. >>>>>>> Also I've updated copyright. >>>>>>> Testing was done by aurora batch 538304.ute.hs_jtreg.accept.full >>>>>>> It looks good. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> On 16.07.2014 15:13, Andrey Zakharov wrote: >>>>>>>> On 16.07.2014 14:39, Erik Helin wrote: >>>>>>>>> On Tuesday 15 July 2014 19:26:34 PM Andrey Zakharov wrote: >>>>>>>>>> Hi, Erik, Bengt. Could you, please, review this too. >>>>>>>>> Andrey, why did you only update a couple of tests to also copy >>>>>>>>> sun.hotspot.WhiteBox$WhiteBoxPermission? You updated 14 tests, >>>>>>>>> there are >>>>>>>>> still 116 tests using sun.hotspot.WhiteBox. >>>>>>>>> >>>>>>>>> Why doesn't these 116 tests have to be updated? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Erik >>>>>>>> Thanks Erik. Actually this first one patch 8011397.WhiteBoxPermission >>>>>>>> >>>>>>> xPermission> >>>>>>>> >>>>>>>> is correct. I will rework it and upload to webrev space. >>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> On 15.07.2014 17:58, Mikael Gerdin wrote: >>>>>>>>>>> Andrey, >>>>>>>>>>> >>>>>>>>>>> On Monday 07 July 2014 20.48.21 Andrey Zakharov wrote: >>>>>>>>>>>> Hi ,all >>>>>>>>>>>> Mikael, can you please review it. >>>>>>>>>>> Sorry, I was on vacation last week. >>>>>>>>>>> >>>>>>>>>>>> webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ >>>>>>>>>>> Looks ok for now. We should consider revisiting this by either >>>>>>>>>>> switching >>>>>>>>>>> to >>>>>>>>>>> @run main/bootclasspath >>>>>>>>>>> or >>>>>>>>>>> deleting the WhiteboxPermission nested class and using some >>>>>>>>>>> other way for >>>>>>>>>>> permission checks (if they are at all needed). >>>>>>>>>>> >>>>>>>>>>> /Mikael >>>>>>>>>>> >>>>>>>>>>>> Thanks. >>>>>>>>>>>> >>>>>>>>>>>> On 25.06.2014 19:08, Andrey Zakharov wrote: >>>>>>>>>>>>> Hi, all >>>>>>>>>>>>> So in progress of previous email - >>>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks. >>>>>>>>>>>>> >>>>>>>>>>>>> On 16.06.2014 19:57, Andrey Zakharov wrote: >>>>>>>>>>>>>> Hi, all >>>>>>>>>>>>>> So issue is that when tests with WhiteBox API has been >>>>>>>>>>>>>> invoked with >>>>>>>>>>>>>> -Xverify:all it fails with Exception >>>>>>>>>>>>>> java.lang.NoClassDefFoundError: >>>>>>>>>>>>>> sun/hotspot/WhiteBox$WhiteBoxPermission >>>>>>>>>>>>>> Solutions that are observed: >>>>>>>>>>>>>> 1. Copy WhiteBoxPermission with WhiteBox. But >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Perhaps this is a good time to get rid of ClassFileInstaller >>>>>>>>>>>>>> altogether? >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2. Using bootclasspath to hook pre-built whitebox (due @library >>>>>>>>>>>>>> /testlibrary/whitebox) . Some tests has @run main/othervm, >>>>>>>>>>>>>> some uses >>>>>>>>>>>>>> ProcessBuilder. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - main/othervm/bootclasspath adds ${test.src} and >>>>>>>>>>>>>> >>>>>>>>>>>>>> ${test.classes}to options. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - With ProcessBuilder we can just add ${test.classes} >>>>>>>>>>>>>> >>>>>>>>>>>>>> Question here is, can it broke some tests ? While testing >>>>>>>>>>>>>> this, I >>>>>>>>>>>>>> found onlyhttps://bugs.openjdk.java.net/browse/JDK-8046231, >>>>>>>>>>>>>> others >>>>>>>>>>>>>> looks fine. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3. Make ClassFileInstaller deal with inner classes like that: >>>>>>>>>>>>>> diff -r 6ed24aedeef0 -r c01651363ba8 >>>>>>>>>>>>>> test/testlibrary/ClassFileInstaller.java >>>>>>>>>>>>>> --- a/test/testlibrary/ClassFileInstaller.java Thu Jun 05 >>>>>>>>>>>>>> 19:02:56 >>>>>>>>>>>>>> 2014 +0400 >>>>>>>>>>>>>> +++ b/test/testlibrary/ClassFileInstaller.java Fri Jun 06 >>>>>>>>>>>>>> 18:18:11 >>>>>>>>>>>>>> 2014 +0400 >>>>>>>>>>>>>> @@ -50,6 +50,16 @@ >>>>>>>>>>>>>> >>>>>>>>>>>>>> } >>>>>>>>>>>>>> // Create the class file >>>>>>>>>>>>>> Files.copy(is, p, >>>>>>>>>>>>>> >>>>>>>>>>>>>> StandardCopyOption.REPLACE_EXISTING); >>>>>>>>>>>>>> >>>>>>>>>>>>>> + >>>>>>>>>>>>>> + for (Class cls : >>>>>>>>>>>>>> Class.forName(arg).getDeclaredClasses()) { >>>>>>>>>>>>>> + //if >>>>>>>>>>>>>> (!Modifier.isStatic(cls.getModifiers())) { >>>>>>>>>>>>>> + String pathNameSub = >>>>>>>>>>>>>> cls.getCanonicalName().replace('.', '/').concat(".class"); >>>>>>>>>>>>>> + Path pathSub = Paths.get(pathNameSub); >>>>>>>>>>>>>> + InputStream streamSub = >>>>>>>>>>>>>> cl.getResourceAsStream(pathNameSub); >>>>>>>>>>>>>> + Files.copy(streamSub, pathSub, >>>>>>>>>>>>>> StandardCopyOption.REPLACE_EXISTING); >>>>>>>>>>>>>> + //} >>>>>>>>>>>>>> + } >>>>>>>>>>>>>> + >>>>>>>>>>>>>> >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> Works fine for ordinary classes, but fails for WhiteBox due >>>>>>>>>>>>>> Class.forName initiate Class. WhiteBox has "static" section, >>>>>>>>>>>>>> and >>>>>>>>>>>>>> initialization fails as it cannot bind to native methods >>>>>>>>>>>>>> "registerNatives" and so on. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> So, lets return to first one option? Just add everywhere >>>>>>>>>>>>>> >>>>>>>>>>>>>> * @run main ClassFileInstaller sun.hotspot.WhiteBox >>>>>>>>>>>>>> >>>>>>>>>>>>>> + * @run main ClassFileInstaller >>>>>>>>>>>>>> sun.hotspot.WhiteBox$WhiteBoxPermission >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 10.06.2014 19:43, Igor Ignatyev wrote: >>>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I don't like this idea, since it completely changes the tests. >>>>>>>>>>>>>>> 'run/othervm/bootclasspath' adds all paths from CP to BCP, >>>>>>>>>>>>>>> so the >>>>>>>>>>>>>>> tests whose main idea was testing WB methods themselves >>>>>>>>>>>>>>> (sanity, >>>>>>>>>>>>>>> compiler/whitebox, ...) don't check that it's possible to >>>>>>>>>>>>>>> use WB >>>>>>>>>>>>>>> when the application isn't in BCP. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Igor >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 06/09/2014 06:59 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>>> Hi, everybody >>>>>>>>>>>>>>>> I have tested my changes on major platforms and found one >>>>>>>>>>>>>>>> bug, filed: >>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046231 >>>>>>>>>>>>>>>> Also, i did another try to make ClassFileInstaller to copy >>>>>>>>>>>>>>>> all inner >>>>>>>>>>>>>>>> classes within parent, but this fails for WhiteBox due its >>>>>>>>>>>>>>>> static >>>>>>>>>>>>>>>> "registerNatives" dependency. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please, review suggested changes: >>>>>>>>>>>>>>>> - replace ClassFileInstaller and run/othervm with >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> "run/othervm/bootclasspath". >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> bootclasspath parameter for othervm >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> adds-Xbootclasspath/a: >>>>>>>>>>>>>>>> option with ${test.src} and ${test.classes}according to >>>>>>>>>>>>>>>> http://hg.openjdk.java.net/code-tools/jtreg/file/31003a1c46d9/ >>>>>>>>>>>>>>>> src/sha >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> re >>>>>>>>>>>>>>>> /classes/com/sun/javatest/regtest/MainAction.java. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is this suitable for our needs - give to test compiled >>>>>>>>>>>>>>>> WhiteBox? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - replace explicit -Xbootclasspath option values (".") in >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ProcessBuilder invocations to ${test.classes} where >>>>>>>>>>>>>>>> WhiteBox has been >>>>>>>>>>>>>>>> compiled. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/azakharov/8011397/webrev. >>>>>>>>>>>>>>>> 00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 23.05.2014 15:40, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>> On 22.05.2014 12:47, Igor Ignatyev wrote: >>>>>>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 1. You changed dozen of tests, have you tested your >>>>>>>>>>>>>>>>>> changes? >>>>>>>>>>>>>>>>> Locally, aurora on the way. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2. Your changes of year in copyright is wrong. it has to be >>>>>>>>>>>>>>>>>> $first_year, [$last_year, ], see Mark's email[1] for >>>>>>>>>>>>>>>>>> details. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/jdk7-dev/2010-May/001 >>>>>>>>>>>>>>>>>> 321.htm >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> l >>>>>>>>>>>>>>>>> Thanks, fixed. will be uploaded soon. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Igor >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 05/21/2014 07:37 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>>> On 13.05.2014 14:43, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>>>>>>> So here is trivial patch - >>>>>>>>>>>>>>>>>>>> removing ClassFileInstaller sun.hotspot.WhiteBox and >>>>>>>>>>>>>>>>>>>> adding >>>>>>>>>>>>>>>>>>>> main/othervm/bootclasspath >>>>>>>>>>>>>>>>>>>> where this needed >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Also, some tests are modified as >>>>>>>>>>>>>>>>>>>> - "-Xbootclasspath/a:.", >>>>>>>>>>>>>>>>>>>> + "-Xbootclasspath/a:" + >>>>>>>>>>>>>>>>>>>> System.getProperty("test.classes"), >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>> webrev:http://cr.openjdk.java.net/~jwilhelm/8011397/webrev. >>>>>>>>>>>>>>>>>>> 02/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 09.05.2014 12:13, Mikael Gerdin wrote: >>>>>>>>>>>>>>>>>>>>> On Thursday 08 May 2014 19.28.13 Igor Ignatyev wrote: >>>>>>>>>>>>>>>>>>>>>> // cc'ing hotspot-dev instaed of compiler, runtime >>>>>>>>>>>>>>>>>>>>>> and gc >>>>>>>>>>>>>>>>>>>>>> lists. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 05/08/2014 07:09 PM, Filipp Zhinkin wrote: >>>>>>>>>>>>>>>>>>>>>>> Andrey, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I've CC'ed compiler and runtime mailing list, >>>>>>>>>>>>>>>>>>>>>>> because you're >>>>>>>>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>>>>>>>>> affect test for other components as too. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I don't like your solution (but I'm not a reviewer, >>>>>>>>>>>>>>>>>>>>>>> so treat >>>>>>>>>>>>>>>>>>>>>>> my >>>>>>>>>>>>>>>>>>>>>>> words >>>>>>>>>>>>>>>>>>>>>>> just as suggestion), >>>>>>>>>>>>>>>>>>>>>>> because we'll have to write more meta information >>>>>>>>>>>>>>>>>>>>>>> for each >>>>>>>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>>>>>>> and it >>>>>>>>>>>>>>>>>>>>>>> is very easy to >>>>>>>>>>>>>>>>>>>>>>> forget to install WhiteBoxPermission if you don't >>>>>>>>>>>>>>>>>>>>>>> test your >>>>>>>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>>>> some security manager. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> From my point of view, it will be better to extend >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> ClassFileInstaller >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> so it will copy not only >>>>>>>>>>>>>>>>>>>>>>> a class whose name was passed as an arguments, but >>>>>>>>>>>>>>>>>>>>>>> also all >>>>>>>>>>>>>>>>>>>>>>> inner >>>>>>>>>>>>>>>>>>>>>>> classes of that class. >>>>>>>>>>>>>>>>>>>>>>> And if someone want copy only specified class >>>>>>>>>>>>>>>>>>>>>>> without inner >>>>>>>>>>>>>>>>>>>>>>> classes, >>>>>>>>>>>>>>>>>>>>>>> then some option >>>>>>>>>>>>>>>>>>>>>>> could be added to ClassFileInstaller to force such >>>>>>>>>>>>>>>>>>>>>>> behaviour. >>>>>>>>>>>>>>>>>>>>> Perhaps this is a good time to get rid of >>>>>>>>>>>>>>>>>>>>> ClassFileInstaller >>>>>>>>>>>>>>>>>>>>> altogether? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8009117 >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The reason for its existence is that the WhiteBox >>>>>>>>>>>>>>>>>>>>> class needs >>>>>>>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>>>>>>> on the >>>>>>>>>>>>>>>>>>>>> boot class path. >>>>>>>>>>>>>>>>>>>>> If we can live with having all the test's classes on >>>>>>>>>>>>>>>>>>>>> the boot >>>>>>>>>>>>>>>>>>>>> class >>>>>>>>>>>>>>>>>>>>> path then >>>>>>>>>>>>>>>>>>>>> we could use the /bootclasspath option in jtreg as >>>>>>>>>>>>>>>>>>>>> stated in >>>>>>>>>>>>>>>>>>>>> the RFE. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> /Mikael >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> Filipp. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 05/08/2014 04:47 PM, Andrey Zakharov wrote: >>>>>>>>>>>>>>>>>>>>>>>> Hi! >>>>>>>>>>>>>>>>>>>>>>>> Suggesting patch with fixes for >>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8011397 >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20275/ >>>>>>>>>>>>>>>>>>>>>>>> 8011397 >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> .t >>>>>>>>>>>>>>>>>>>>>>>> gz >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> patch: >>>>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/secure/attachment/20274/ >>>>>>>>>>>>>>>>>>>>>>>> 8011397 >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> .W >>>>>>>>>>>>>>>>>>>>>>>> hiteBoxPer >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> mission >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks. From vladimir.kempik at oracle.com Fri Aug 22 10:50:04 2014 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Fri, 22 Aug 2014 14:50:04 +0400 Subject: Request Review: 6883953: java -client -XX:ValueMapInitialSize=0 crashes Message-ID: <53F7205C.4030307@oracle.com> Hello! I'd like to get a review for this backport of 6883953 into jdk7. The patch does not apply cleanly, the required modifications are quite small. I will need a review for this. The webrev for jdk7: http://cr.openjdk.java.net/~vkempik/6883953/webrev.00/ The difference, compared to jdk9 is the code around the added lines. Bug: https://bugs.openjdk.java.net/browse/JDK-6883953 Jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/b97166f236bd Jdk9 review: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-May/011630.html http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-May/014527.html JDK8 change is on the way as well. The change was tested with jprt on all supported platforms. Thanks, Vladimir. From erik.joelsson at oracle.com Fri Aug 22 11:02:23 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 22 Aug 2014 13:02:23 +0200 Subject: RFR[P1]: 8055744 - 8u-dev nightly solaris builds failed on 08/20 In-Reply-To: <53F62FAB.3090606@oracle.com> References: <53F61C09.4060300@oracle.com> <53F62164.2030001@oracle.com> <53F626BA.70204@oracle.com> <53F62FAB.3090606@oracle.com> Message-ID: <53F7233F.6040100@oracle.com> Hello, Looks ok from me too. /Erik On 2014-08-21 19:43, Daniel D. Daugherty wrote: > > http://cr.openjdk.java.net/~jwilhelm/8055744/webrev.02/ > > make/solaris/Makefile > No comments. > > make/solaris/makefiles/buildtree.make > No comments. > > A product build with the above changes shows this: > > $ cat solaris_amd64_compiler2/product/mapfile_ext > > # Extended set of symbols. > JVM_SetVmMemoryPressure; > > Looks right to me. > > Dan > > > On 8/21/14 11:04 AM, Jesper Wilhelmsson wrote: >> Thank you for the quick reply Dan! >> >> A new webrev with your suggested change is available here: >> >> http://cr.openjdk.java.net/~jwilhelm/8055744/webrev.02/ >> >> /Jesper >> >> >> Daniel D. Daugherty skrev 21/8/14 18:42: >>> On 8/21/14 10:19 AM, Jesper Wilhelmsson wrote: >>>> Hi, >>>> >>>> On Solaris the HS_ALT_MAKE variable was not passed to vm.make when >>>> creating >>>> the mapfiles which lead to mapfile-ext not being found and later a >>>> linker >>>> error due to symbols declared in the extra mapfile not being found. >>>> >>>> The hotspot makefiles are .. interesting .. yes. >>>> >>>> The proposed solution is to include defs.make where HS_ALT_MAKE is >>>> set up into >>>> vm.make on Solaris. >>>> >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~jwilhelm/8055744/webrev/ >>> >>> Unfortunately, including defs.make in make/solaris/makefiles/vm.make >>> isn't the "right" way to get a top-level variable down into the >>> HotSpot build system. I cannot remember what breaks when you do that, >>> but it doesn't work right in all the ways that we build HotSpot. >>> >>> For the HotSpot build system, you'll want to: >>> >>> - update make/solaris/Makefile and add HS_ALT_MAKE to >>> the BUILDTREE_VARS list: >>> >>> BUILDTREE_VARS += HS_ALT_MAKE=$(HS_ALT_MAKE) >>> >>> - update make/solaris/makefiles/buildtree.make and add >>> HS_ALT_MAKE to the rule that creates flags.make: >>> >>> [ -n "$(HS_ALT_MAKE)" ] && \ >>> echo && echo "HS_ALT_MAKE = $(HS_ALT_MAKE)"; \ >>> >>> The way I usually find all the right spots is I look for >>> where ZIPEXE is added to the above files and follow those >>> examples. >>> >>> Dan >>> >>> >>> >>> >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8055744#comment-13542110 >>>> >>>> This is a P1 so if you feel comfortable with the hotspot makefiles, >>>> please >>>> have a look. >>>> >>>> Thanks! >>>> /Jesper >>> > From jesper.wilhelmsson at oracle.com Fri Aug 22 11:03:04 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 22 Aug 2014 13:03:04 +0200 Subject: RFR[P1]: 8055744 - 8u-dev nightly solaris builds failed on 08/20 In-Reply-To: <53F7233F.6040100@oracle.com> References: <53F61C09.4060300@oracle.com> <53F62164.2030001@oracle.com> <53F626BA.70204@oracle.com> <53F62FAB.3090606@oracle.com> <53F7233F.6040100@oracle.com> Message-ID: <53F72368.4020001@oracle.com> Thanks Erik! /Jesper Erik Joelsson skrev 22/8/14 13:02: > Hello, > > Looks ok from me too. > > /Erik > > On 2014-08-21 19:43, Daniel D. Daugherty wrote: >> > http://cr.openjdk.java.net/~jwilhelm/8055744/webrev.02/ >> >> make/solaris/Makefile >> No comments. >> >> make/solaris/makefiles/buildtree.make >> No comments. >> >> A product build with the above changes shows this: >> >> $ cat solaris_amd64_compiler2/product/mapfile_ext >> >> # Extended set of symbols. >> JVM_SetVmMemoryPressure; >> >> Looks right to me. >> >> Dan >> >> >> On 8/21/14 11:04 AM, Jesper Wilhelmsson wrote: >>> Thank you for the quick reply Dan! >>> >>> A new webrev with your suggested change is available here: >>> >>> http://cr.openjdk.java.net/~jwilhelm/8055744/webrev.02/ >>> >>> /Jesper >>> >>> >>> Daniel D. Daugherty skrev 21/8/14 18:42: >>>> On 8/21/14 10:19 AM, Jesper Wilhelmsson wrote: >>>>> Hi, >>>>> >>>>> On Solaris the HS_ALT_MAKE variable was not passed to vm.make when creating >>>>> the mapfiles which lead to mapfile-ext not being found and later a linker >>>>> error due to symbols declared in the extra mapfile not being found. >>>>> >>>>> The hotspot makefiles are .. interesting .. yes. >>>>> >>>>> The proposed solution is to include defs.make where HS_ALT_MAKE is set up into >>>>> vm.make on Solaris. >>>>> >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~jwilhelm/8055744/webrev/ >>>> >>>> Unfortunately, including defs.make in make/solaris/makefiles/vm.make >>>> isn't the "right" way to get a top-level variable down into the >>>> HotSpot build system. I cannot remember what breaks when you do that, >>>> but it doesn't work right in all the ways that we build HotSpot. >>>> >>>> For the HotSpot build system, you'll want to: >>>> >>>> - update make/solaris/Makefile and add HS_ALT_MAKE to >>>> the BUILDTREE_VARS list: >>>> >>>> BUILDTREE_VARS += HS_ALT_MAKE=$(HS_ALT_MAKE) >>>> >>>> - update make/solaris/makefiles/buildtree.make and add >>>> HS_ALT_MAKE to the rule that creates flags.make: >>>> >>>> [ -n "$(HS_ALT_MAKE)" ] && \ >>>> echo && echo "HS_ALT_MAKE = $(HS_ALT_MAKE)"; \ >>>> >>>> The way I usually find all the right spots is I look for >>>> where ZIPEXE is added to the above files and follow those >>>> examples. >>>> >>>> Dan >>>> >>>> >>>> >>>> >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8055744#comment-13542110 >>>>> >>>>> This is a P1 so if you feel comfortable with the hotspot makefiles, please >>>>> have a look. >>>>> >>>>> Thanks! >>>>> /Jesper >>>> >> > From coleen.phillimore at oracle.com Fri Aug 22 14:26:01 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 22 Aug 2014 10:26:01 -0400 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F54AC0.7010007@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> <53F52521.1080309@oracle.com> <53F54AC0.7010007@oracle.com> Message-ID: <53F752F9.9090908@oracle.com> Thanks Dan, Serguei and Roland for discussion on this change. The latest version is here: open webrev at http://cr.openjdk.java.net/~coleenp/8055008_2/ Changes from the last version (don't have the setup to do a diff webrev, sorry) are that I have a new flag to mark running emcp methods so we can set breakpoints in only those. Also, confirmed that we need to clean_weak_method_links in obsolete methods too. Made changes per review comments. Also, added more to the test so that all tracing in InstanceKlass comes out. Reran all tests (nsk, jck, jtreg, java/lang/instrument). Thanks to whoever made command line processing handle hex numbers! Thanks, Coleen On 8/20/14, 9:26 PM, Coleen Phillimore wrote: > > On 8/20/14, 6:45 PM, Daniel D. Daugherty wrote: >> On 8/20/14 2:01 PM, Coleen Phillimore wrote: >>> On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>>> >>>>> If an EMCP method is not running, should we save it on a previous >>>>> version list anyway so that we can make it obsolete if it's >>>>> redefined and made obsolete? >>>> >>>> I hope, Dan will catch me if I'm wrong... >>>> >>>> I think, we should not. >>>> An EMCP method can not be made obsolete if it is not running. >>>> >>> >>> >>> It should be this way otherwise we'd have to hang onto things forever. >> >> An EMCP method should only be made obsolete if a RedefineClasses() or >> RetransformClasses() operation made it so. We should not be leveraging >> off the obsolete-ness attribute to solve a life-cycle problem. > > Yes, this was my error in the change. This is why I made things > obsolete if they were not running. I think I can't reuse this flag. > My latest changes add a new explicit flag (which we have space for in > Method*). >> >> In the pre-PGR world, we could trust GC to make a completely unused >> EMCP method collectible and eventually our weak reference would go >> away. Just because an EMCP method is not on a stack does not mean >> that it is not used so we need a different way to determine whether >> it is OK to no longer track an EMCP method. > > Our on_stack marking is supposed to look at all the places where GC > used to look so I think we can use on_stack to track the lifecycle of > EMCP methods. If the EMCP method is somewhere, we will find it! > > I'm running tests on the latest change, but am also waiting for > confirmation from Roland because we were only cleaning out MethodData > for EMCP methods and not for running obsolete methods and I think we > need to do that for obsolete methods also, which my change does now. > I think it was a bug. > > Thanks Dan for remembering all of this for me! > > Coleen >> >> >>> >>>> BTW, I'm reviewing the webrev too, but probably it'd be better to >>>> switch to updated webrev after it is ready. >>> >>> Yes, this is a good idea. I figured out why I made emcp methods >>> obsolete, and I'm fixing that as well as Dan's comments. Thanks! >> >> Cool! I'm looking forward to the next review. >> >> Dan >> >> >>> >>> Coleen >>> >>>> >>>> Thanks, >>>> Serguei >>> >> > From vladimir.kozlov at oracle.com Fri Aug 22 16:00:24 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Aug 2014 09:00:24 -0700 Subject: Request Review: 6883953: java -client -XX:ValueMapInitialSize=0 crashes In-Reply-To: <53F7205C.4030307@oracle.com> References: <53F7205C.4030307@oracle.com> Message-ID: <53F76918.1050403@oracle.com> Looks good. Thanks, Vladimir On 8/22/14 3:50 AM, Vladimir Kempik wrote: > Hello! > > I'd like to get a review for this backport of 6883953 into jdk7. > > The patch does not apply cleanly, the required modifications are > quite small. > I will need a review for this. > > The webrev for jdk7: http://cr.openjdk.java.net/~vkempik/6883953/webrev.00/ > > The difference, compared to jdk9 is the code around the added lines. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6883953 > Jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/b97166f236bd > Jdk9 review: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-May/011630.html > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-May/014527.html > > JDK8 change is on the way as well. > > The change was tested with jprt on all supported platforms. > > Thanks, Vladimir. > From vladimir.kozlov at oracle.com Fri Aug 22 16:05:31 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Aug 2014 09:05:31 -0700 Subject: [8u40] RFR(S): 8054402: "klass->is_loader_alive(_is_alive)) failed: must be alive" for anonymous classes In-Reply-To: <53F6EE1D.70409@oracle.com> References: <53F1A213.8020106@oracle.com> <53F1A64F.60009@oracle.com> <53F1A6A3.60509@oracle.com> <53F6EE1D.70409@oracle.com> Message-ID: <53F76A4B.2010202@oracle.com> Looks good. Thanks, Vladimir On 8/22/14 12:15 AM, Tobias Hartmann wrote: > Hi, > > due to JDK-8055751 [1] I had to fix the backport. I added the class 'sun.hotspot.WhiteBox$WhiteBoxPermission' to the > tests ClassFileInstaller. > > New webrev: http://cr.openjdk.java.net/~thartmann/8054402_8u/webrev.00/ > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8055751 > > > On 18.08.2014 09:09, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review. I"ll wait for another nightly before pushing. >> >> Best, >> Tobias >> >> On 18.08.2014 09:07, Vladimir Kozlov wrote: >>> Looks good. Please, wait at least one more Nightly. >>> >>> Thanks, >>> Vladimir >>> >>> On 8/17/14 11:49 PM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review this 8u40 backport request. The changes were pushed on Thursday. >>>> >>>> Nightly testing showed no problems. The patch applies cleanly to 8u40. >>>> >>>> Master bug: https://bugs.openjdk.java.net/browse/JDK-8054402 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8054402/webrev.01/ >>>> Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/cf3ccda01fa6 >>>> >>>> Thanks, >>>> Tobias >> > From roland.westrelin at oracle.com Fri Aug 22 16:29:53 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 22 Aug 2014 18:29:53 +0200 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F752F9.9090908@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> <53F52521.1080309@oracle.com> <53F54AC0.7010007@oracle.com> <53F752F9.9090908@oracle.com> Message-ID: <3F4637F3-DBD3-45B9-8156-D4FC28632407@oracle.com> Hi Coleen, > open webrev at http://cr.openjdk.java.net/~coleenp/8055008_2/ The MDO change looks good to me. Thanks for fixing it! Roland. From alejandro.murillo at oracle.com Fri Aug 22 20:23:59 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 22 Aug 2014 14:23:59 -0600 Subject: All jdk9 hotspot group repos now have the jigsaw changes Message-ID: <53F7A6DF.7080808@oracle.com> All jdk9 hotspot group repos now have the jigsaw changes, please synch your local versions of whole repo clones as there are significant changes in some of the non hotspot components. All group repos have been synched with jdk9/hs/hotspot as well, so beside the changes coming from other group repos, the single hotspot change related to jigsaw is now in the group repos as well. Thanks -- Alejandro From david.holmes at oracle.com Mon Aug 25 00:50:09 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Aug 2014 10:50:09 +1000 Subject: RFR[P1]: 8055744 - 8u-dev nightly solaris builds failed on 08/20 In-Reply-To: <53F626BA.70204@oracle.com> References: <53F61C09.4060300@oracle.com> <53F62164.2030001@oracle.com> <53F626BA.70204@oracle.com> Message-ID: <53FA8841.1030604@oracle.com> Sorry I'm late but had a long weekend and was off last Friday. On 22/08/2014 3:04 AM, Jesper Wilhelmsson wrote: > Thank you for the quick reply Dan! > > A new webrev with your suggested change is available here: > > http://cr.openjdk.java.net/~jwilhelm/8055744/webrev.02/ The change in make/solaris/Makefile isn't necessary. buildtree.make already includes defs.make which defines HS_ALT_MAKE. If this is already pushed please follow up with a correction. But don't push this part of 8u. Thanks, David > /Jesper > > > Daniel D. Daugherty skrev 21/8/14 18:42: >> On 8/21/14 10:19 AM, Jesper Wilhelmsson wrote: >>> Hi, >>> >>> On Solaris the HS_ALT_MAKE variable was not passed to vm.make when >>> creating >>> the mapfiles which lead to mapfile-ext not being found and later a >>> linker >>> error due to symbols declared in the extra mapfile not being found. >>> >>> The hotspot makefiles are .. interesting .. yes. >>> >>> The proposed solution is to include defs.make where HS_ALT_MAKE is >>> set up into >>> vm.make on Solaris. >>> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~jwilhelm/8055744/webrev/ >> >> Unfortunately, including defs.make in make/solaris/makefiles/vm.make >> isn't the "right" way to get a top-level variable down into the >> HotSpot build system. I cannot remember what breaks when you do that, >> but it doesn't work right in all the ways that we build HotSpot. >> >> For the HotSpot build system, you'll want to: >> >> - update make/solaris/Makefile and add HS_ALT_MAKE to >> the BUILDTREE_VARS list: >> >> BUILDTREE_VARS += HS_ALT_MAKE=$(HS_ALT_MAKE) >> >> - update make/solaris/makefiles/buildtree.make and add >> HS_ALT_MAKE to the rule that creates flags.make: >> >> [ -n "$(HS_ALT_MAKE)" ] && \ >> echo && echo "HS_ALT_MAKE = $(HS_ALT_MAKE)"; \ >> >> The way I usually find all the right spots is I look for >> where ZIPEXE is added to the above files and follow those >> examples. >> >> Dan >> >> >> >> >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8055744#comment-13542110 >>> >>> This is a P1 so if you feel comfortable with the hotspot makefiles, >>> please >>> have a look. >>> >>> Thanks! >>> /Jesper >> From david.holmes at oracle.com Mon Aug 25 02:18:08 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Aug 2014 12:18:08 +1000 Subject: OpenJDK9 - build errors on Linux/Ubuntu 12.04 In-Reply-To: References: Message-ID: <53FA9CE0.20908@oracle.com> cc'ing hotspot-dev Which forest are you trying to build and is it fully up to date? David On 23/08/2014 9:10 AM, Mani Sarkar wrote: > Hi, > > Lately I have been getting a lot of build failures and the most recent ones > are the below (snippets of the error messages from the logs): > > *First instance after running make images* > . > . > . > make[4]: warning: -jN forced in submake: disabling jobserver mode. > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > Compiling 163 files for BUILD_TOOLS_JDK > Compiling 1492 files for BUILD_INTERIM_CORBA > Rescanned ../generated/adfiles/linux_x86_64.ad but encountered no changes. > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > **NOTICE** Dtrace support disabled: //usr/include/sys/sdt.h not found > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/cpu/x86/vm/assembler_x86.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/atomic.cpp > In file included from > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp:28:0: > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp: > In member function ?virtual Generation::Name ASParNewGeneration::kind()?: > . > . > . > In file included from > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp:28:0: > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp: > In member function ?virtual Generation::Name ASParNewGeneration::kind()?: > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp:81:44: > error: ?ASParNew? was not declared in this scope > /home/satyasai/sources/jdk9/jdk/make/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java:274: > error: incompatible types: Month cannot be converted to int > LocalDate adjustedDate = LocalDate.of(year, month, > dayOfMonth).minusDays(6); > . > . > . > 15 errors > make[3]: *** > [/home/satyasai/sources/jdk9/build/linux-x86_64-normal-server-release/jdk/btclasses/_the.BUILD_TOOLS_JDK_batch] > Error 1 > make[2]: *** [build-tools-jdk] Error 2 > make[2]: *** Waiting for unfinished jobs.... > make[8]: *** [asParNewGeneration.o] Error 1 > make[8]: *** Waiting for unfinished jobs.... > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Creating corba/dist/interim_corba.jar > make[7]: *** [the_vm] Error 2 > make[6]: *** [product] Error 2 > make[5]: *** [generic_build2] Error 2 > make[4]: *** [product] Error 2 > make[3]: *** > [/home/satyasai/sources/jdk9/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] > Error 2 > make[2]: *** [hotspot] Error 2 > make[1]: *** [main-wrapper] Error 2 > make: *** [images] Error 2 > > > *Second instance after running make clean followed by make images* > . > . > . > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > Generating precompiled header precompiled.hpp.gch > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/compiler/abstractCompiler.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/utilities/accessFlags.cpp > Compiling ../generated/adfiles/ad_x86_64.cpp > Compiling ../generated/adfiles/ad_x86_64_clone.cpp > Compiling ../generated/adfiles/ad_x86_64_expand.cpp > Compiling ../generated/adfiles/ad_x86_64_format.cpp > Compiling ../generated/adfiles/ad_x86_64_gen.cpp > Compiling ../generated/adfiles/ad_x86_64_misc.cpp > Compiling ../generated/adfiles/ad_x86_64_peephole.cpp > Compiling ../generated/adfiles/ad_x86_64_pipeline.cpp > > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp > > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp > Compiling /home/satyasai/sources/jdk9/hotspot/src/share/vm/opto/addnode.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/advancedThresholdPolicy.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/shared/ageTable.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_interface/allocTracer.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/memory/allocation.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/shared/allocationStats.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/classfile/altHashing.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/oops/annotations.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/arguments.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/arguments_ext.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/utilities/array.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/oops/arrayKlass.cpp > Compiling /home/satyasai/sources/jdk9/hotspot/src/share/vm/oops/arrayOop.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp > > In file included from > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp:28:0: > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp: > In member function ?virtual Generation::Name ASParNewGeneration::kind()?: > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp:81:44: > error: ?ASParNew? was not declared in this scope > Compiling /home/satyasai/sources/jdk9/hotspot/src/share/vm/asm/assembler.cpp > make[8]: *** [asParNewGeneration.o] Error 1 > make[8]: *** Waiting for unfinished jobs.... > make[7]: *** [the_vm] Error 2 > make[6]: *** [product] Error 2 > make[5]: *** [generic_build2] Error 2 > make[4]: *** [product] Error 2 > make[3]: *** > [/home/satyasai/sources/jdk9/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] > Error 2 > make[2]: *** [hotspot] Error 2 > make[1]: *** [main-wrapper] Error 2 > make: *** [images] Error 2 > > > My sources is updated on a regular-basis, and the above are on the most > recent version of the source. If you need anything else to help with > investigating the the above error please let me know. > > Cheers, > Mani > From martinrb at google.com Mon Aug 25 02:36:28 2014 From: martinrb at google.com (Martin Buchholz) Date: Sun, 24 Aug 2014 19:36:28 -0700 Subject: OpenJDK9 - build errors on Linux/Ubuntu 12.04 In-Reply-To: <53FA9CE0.20908@oracle.com> References: <53FA9CE0.20908@oracle.com> Message-ID: I tried again today ( with jdk9/jdk9-dev ) and everything works now. I believe the problem was fixed by the following, which replaced erroneous references to SetupJava.gmk # HG changeset patch # User erikj # Date 1408611935 -7200 # Thu Aug 21 11:05:35 2014 +0200 # Node ID b8f27b54cc51c17c7debcf7048c8b81b221f931c # Parent 0aa1bc5db42cb7b66678181bc32fefdb8bafcba8 8055188: General cleanup of minor issues from source restructure Reviewed-by: tbell On Sun, Aug 24, 2014 at 7:18 PM, David Holmes wrote: > cc'ing hotspot-dev > > Which forest are you trying to build and is it fully up to date? > > David > > > On 23/08/2014 9:10 AM, Mani Sarkar wrote: > >> Hi, >> >> Lately I have been getting a lot of build failures and the most recent >> ones >> are the below (snippets of the error messages from the logs): >> >> *First instance after running make images* >> . >> . >> . >> make[4]: warning: -jN forced in submake: disabling jobserver mode. >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> Compiling 163 files for BUILD_TOOLS_JDK >> Compiling 1492 files for BUILD_INTERIM_CORBA >> Rescanned ../generated/adfiles/linux_x86_64.ad but encountered no >> changes. >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> **NOTICE** Dtrace support disabled: //usr/include/sys/sdt.h not found >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_ >> implementation/parNew/asParNewGeneration.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/os_cpu/linux_x86/ >> vm/assembler_linux_x86.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/cpu/x86/vm/assembler_x86.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/atomic.cpp >> In file included from >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_ >> implementation/parNew/asParNewGeneration.cpp:28:0: >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_ >> implementation/parNew/asParNewGeneration.hpp: >> In member function ?virtual Generation::Name ASParNewGeneration::kind()?: >> . >> . >> . >> In file included from >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_ >> implementation/parNew/asParNewGeneration.cpp:28:0: >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_ >> implementation/parNew/asParNewGeneration.hpp: >> In member function ?virtual Generation::Name ASParNewGeneration::kind()?: >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_ >> implementation/parNew/asParNewGeneration.hpp:81:44: >> error: ?ASParNew? was not declared in this scope >> /home/satyasai/sources/jdk9/jdk/make/src/classes/build/tools/tzdb/ >> TzdbZoneRulesProvider.java:274: >> error: incompatible types: Month cannot be converted to int >> LocalDate adjustedDate = LocalDate.of(year, month, >> dayOfMonth).minusDays(6); >> . >> . >> . >> 15 errors >> make[3]: *** >> [/home/satyasai/sources/jdk9/build/linux-x86_64-normal- >> server-release/jdk/btclasses/_the.BUILD_TOOLS_JDK_batch] >> Error 1 >> make[2]: *** [build-tools-jdk] Error 2 >> make[2]: *** Waiting for unfinished jobs.... >> make[8]: *** [asParNewGeneration.o] Error 1 >> make[8]: *** Waiting for unfinished jobs.... >> Note: Some input files use or override a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> Creating corba/dist/interim_corba.jar >> make[7]: *** [the_vm] Error 2 >> make[6]: *** [product] Error 2 >> make[5]: *** [generic_build2] Error 2 >> make[4]: *** [product] Error 2 >> make[3]: *** >> [/home/satyasai/sources/jdk9/build/linux-x86_64-normal- >> server-release/hotspot/_hotspot.timestamp] >> Error 2 >> make[2]: *** [hotspot] Error 2 >> make[1]: *** [main-wrapper] Error 2 >> make: *** [images] Error 2 >> >> >> *Second instance after running make clean followed by make images* >> . >> . >> . >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> Generating precompiled header precompiled.hpp.gch >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/compiler/ >> abstractCompiler.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/ >> utilities/accessFlags.cpp >> Compiling ../generated/adfiles/ad_x86_64.cpp >> Compiling ../generated/adfiles/ad_x86_64_clone.cpp >> Compiling ../generated/adfiles/ad_x86_64_expand.cpp >> Compiling ../generated/adfiles/ad_x86_64_format.cpp >> Compiling ../generated/adfiles/ad_x86_64_gen.cpp >> Compiling ../generated/adfiles/ad_x86_64_misc.cpp >> Compiling ../generated/adfiles/ad_x86_64_peephole.cpp >> Compiling ../generated/adfiles/ad_x86_64_pipeline.cpp >> >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/ >> concurrentMarkSweep/adaptiveFreeList.cpp >> >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_ >> implementation/shared/adaptiveSizePolicy.cpp >> Compiling /home/satyasai/sources/jdk9/hotspot/src/share/vm/opto/ >> addnode.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/ >> parallelScavenge/adjoiningGenerations.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/ >> parallelScavenge/adjoiningVirtualSpaces.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/ >> advancedThresholdPolicy.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_ >> implementation/shared/ageTable.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_ >> interface/allocTracer.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/memory/allocation.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_ >> implementation/shared/allocationStats.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/classfile/altHashing.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/oops/annotations.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/arguments.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/ >> arguments_ext.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/utilities/array.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/oops/arrayKlass.cpp >> Compiling /home/satyasai/sources/jdk9/hotspot/src/share/vm/oops/ >> arrayOop.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/ >> parallelScavenge/asPSOldGen.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/ >> parallelScavenge/asPSYoungGen.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_ >> implementation/parNew/asParNewGeneration.cpp >> >> In file included from >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_ >> implementation/parNew/asParNewGeneration.cpp:28:0: >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_ >> implementation/parNew/asParNewGeneration.hpp: >> In member function ?virtual Generation::Name ASParNewGeneration::kind()?: >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_ >> implementation/parNew/asParNewGeneration.hpp:81:44: >> error: ?ASParNew? was not declared in this scope >> Compiling /home/satyasai/sources/jdk9/hotspot/src/share/vm/asm/ >> assembler.cpp >> make[8]: *** [asParNewGeneration.o] Error 1 >> make[8]: *** Waiting for unfinished jobs.... >> make[7]: *** [the_vm] Error 2 >> make[6]: *** [product] Error 2 >> make[5]: *** [generic_build2] Error 2 >> make[4]: *** [product] Error 2 >> make[3]: *** >> [/home/satyasai/sources/jdk9/build/linux-x86_64-normal- >> server-release/hotspot/_hotspot.timestamp] >> Error 2 >> make[2]: *** [hotspot] Error 2 >> make[1]: *** [main-wrapper] Error 2 >> make: *** [images] Error 2 >> >> >> My sources is updated on a regular-basis, and the above are on the most >> recent version of the source. If you need anything else to help with >> investigating the the above error please let me know. >> >> Cheers, >> Mani >> >> From tobias.hartmann at oracle.com Mon Aug 25 04:56:01 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 25 Aug 2014 06:56:01 +0200 Subject: [8u40] RFR(S): 8054402: "klass->is_loader_alive(_is_alive)) failed: must be alive" for anonymous classes In-Reply-To: <53F76A4B.2010202@oracle.com> References: <53F1A213.8020106@oracle.com> <53F1A64F.60009@oracle.com> <53F1A6A3.60509@oracle.com> <53F6EE1D.70409@oracle.com> <53F76A4B.2010202@oracle.com> Message-ID: <53FAC1E1.8010608@oracle.com> Thanks, Vladimir. Best, Tobias On 22.08.2014 18:05, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 8/22/14 12:15 AM, Tobias Hartmann wrote: >> Hi, >> >> due to JDK-8055751 [1] I had to fix the backport. I added the class >> 'sun.hotspot.WhiteBox$WhiteBoxPermission' to the >> tests ClassFileInstaller. >> >> New webrev: http://cr.openjdk.java.net/~thartmann/8054402_8u/webrev.00/ >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8055751 >> >> >> On 18.08.2014 09:09, Tobias Hartmann wrote: >>> Hi Vladimir, >>> >>> thanks for the review. I"ll wait for another nightly before pushing. >>> >>> Best, >>> Tobias >>> >>> On 18.08.2014 09:07, Vladimir Kozlov wrote: >>>> Looks good. Please, wait at least one more Nightly. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 8/17/14 11:49 PM, Tobias Hartmann wrote: >>>>> Hi, >>>>> >>>>> please review this 8u40 backport request. The changes were pushed >>>>> on Thursday. >>>>> >>>>> Nightly testing showed no problems. The patch applies cleanly to >>>>> 8u40. >>>>> >>>>> Master bug: https://bugs.openjdk.java.net/browse/JDK-8054402 >>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8054402/webrev.01/ >>>>> Changeset: >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/cf3ccda01fa6 >>>>> >>>>> Thanks, >>>>> Tobias >>> >> From erik.joelsson at oracle.com Mon Aug 25 09:04:42 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 25 Aug 2014 11:04:42 +0200 Subject: OpenJDK9 - build errors on Linux/Ubuntu 12.04 In-Reply-To: References: <53FA9CE0.20908@oracle.com> Message-ID: <53FAFC2A.4080901@oracle.com> I renamed the file make/common/SetupJava.gmk to make/common/SetupJavaCompilers.gmk. This required changes in both the root repo and the jdk repo and AFAIK I pushed both more or less at the same time. I'm guessing you still managed to hit the race condition when pulling changes. /Erik On 2014-08-25 04:36, Martin Buchholz wrote: > I tried again today ( with jdk9/jdk9-dev ) and everything works now. > I believe the problem was fixed by the following, which replaced > erroneous references to SetupJava.gmk > > # HG changeset patch > # User erikj > # Date 1408611935 -7200 > # Thu Aug 21 11:05:35 2014 +0200 > # Node ID b8f27b54cc51c17c7debcf7048c8b81b221f931c > # Parent 0aa1bc5db42cb7b66678181bc32fefdb8bafcba8 > 8055188: General cleanup of minor issues from source restructure > Reviewed-by: tbell > > > > On Sun, Aug 24, 2014 at 7:18 PM, David Holmes > wrote: > > cc'ing hotspot-dev > > Which forest are you trying to build and is it fully up to date? > > David > > > On 23/08/2014 9:10 AM, Mani Sarkar wrote: > > Hi, > > Lately I have been getting a lot of build failures and the > most recent ones > are the below (snippets of the error messages from the logs): > > *First instance after running make images* > . > . > . > make[4]: warning: -jN forced in submake: disabling jobserver mode. > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > Compiling 163 files for BUILD_TOOLS_JDK > Compiling 1492 files for BUILD_INTERIM_CORBA > Rescanned ../generated/adfiles/linux_x86_64.ad > but encountered no changes. > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > **NOTICE** Dtrace support disabled: //usr/include/sys/sdt.h > not found > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/cpu/x86/vm/assembler_x86.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/atomic.cpp > In file included from > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp:28:0: > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp: > In member function ?virtual Generation::Name > ASParNewGeneration::kind()?: > . > . > . > In file included from > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp:28:0: > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp: > In member function ?virtual Generation::Name > ASParNewGeneration::kind()?: > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp:81:44: > error: ?ASParNew? was not declared in this scope > /home/satyasai/sources/jdk9/jdk/make/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java:274: > error: incompatible types: Month cannot be converted to int > LocalDate adjustedDate = LocalDate.of(year, > month, > dayOfMonth).minusDays(6); > . > . > . > 15 errors > make[3]: *** > [/home/satyasai/sources/jdk9/build/linux-x86_64-normal-server-release/jdk/btclasses/_the.BUILD_TOOLS_JDK_batch] > Error 1 > make[2]: *** [build-tools-jdk] Error 2 > make[2]: *** Waiting for unfinished jobs.... > make[8]: *** [asParNewGeneration.o] Error 1 > make[8]: *** Waiting for unfinished jobs.... > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Creating corba/dist/interim_corba.jar > make[7]: *** [the_vm] Error 2 > make[6]: *** [product] Error 2 > make[5]: *** [generic_build2] Error 2 > make[4]: *** [product] Error 2 > make[3]: *** > [/home/satyasai/sources/jdk9/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] > Error 2 > make[2]: *** [hotspot] Error 2 > make[1]: *** [main-wrapper] Error 2 > make: *** [images] Error 2 > > > *Second instance after running make clean followed by make images* > . > . > . > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > Generating precompiled header precompiled.hpp.gch > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/compiler/abstractCompiler.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/utilities/accessFlags.cpp > Compiling ../generated/adfiles/ad_x86_64.cpp > Compiling ../generated/adfiles/ad_x86_64_clone.cpp > Compiling ../generated/adfiles/ad_x86_64_expand.cpp > Compiling ../generated/adfiles/ad_x86_64_format.cpp > Compiling ../generated/adfiles/ad_x86_64_gen.cpp > Compiling ../generated/adfiles/ad_x86_64_misc.cpp > Compiling ../generated/adfiles/ad_x86_64_peephole.cpp > Compiling ../generated/adfiles/ad_x86_64_pipeline.cpp > > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp > > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/opto/addnode.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/advancedThresholdPolicy.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/shared/ageTable.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_interface/allocTracer.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/memory/allocation.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/shared/allocationStats.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/classfile/altHashing.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/oops/annotations.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/arguments.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/arguments_ext.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/utilities/array.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/oops/arrayKlass.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/oops/arrayOop.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp > > In file included from > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp:28:0: > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp: > In member function ?virtual Generation::Name > ASParNewGeneration::kind()?: > /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp:81:44: > error: ?ASParNew? was not declared in this scope > Compiling > /home/satyasai/sources/jdk9/hotspot/src/share/vm/asm/assembler.cpp > make[8]: *** [asParNewGeneration.o] Error 1 > make[8]: *** Waiting for unfinished jobs.... > make[7]: *** [the_vm] Error 2 > make[6]: *** [product] Error 2 > make[5]: *** [generic_build2] Error 2 > make[4]: *** [product] Error 2 > make[3]: *** > [/home/satyasai/sources/jdk9/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] > Error 2 > make[2]: *** [hotspot] Error 2 > make[1]: *** [main-wrapper] Error 2 > make: *** [images] Error 2 > > > My sources is updated on a regular-basis, and the above are on > the most > recent version of the source. If you need anything else to > help with > investigating the the above error please let me know. > > Cheers, > Mani > > From sadhak001 at gmail.com Mon Aug 25 10:06:11 2014 From: sadhak001 at gmail.com (Mani Sarkar) Date: Mon, 25 Aug 2014 11:06:11 +0100 Subject: OpenJDK9 - build errors on Linux/Ubuntu 12.04 In-Reply-To: <53FAFC2A.4080901@oracle.com> References: <53FA9CE0.20908@oracle.com> <53FAFC2A.4080901@oracle.com> Message-ID: I;m building jdk9/jdk9 - as always (is that not the right forest) and yes its getting the latest changes from the repo. I can try zapping all the folders and re-apply getsource. Cheers, Mani On Mon, Aug 25, 2014 at 10:04 AM, Erik Joelsson wrote: > I renamed the file make/common/SetupJava.gmk to > make/common/SetupJavaCompilers.gmk. This required changes in both the root > repo and the jdk repo and AFAIK I pushed both more or less at the same > time. I'm guessing you still managed to hit the race condition when pulling > changes. > > /Erik > > > On 2014-08-25 04:36, Martin Buchholz wrote: > > I tried again today ( with jdk9/jdk9-dev ) and everything works now. I > believe the problem was fixed by the following, which replaced erroneous > references to SetupJava.gmk > > # HG changeset patch > # User erikj > # Date 1408611935 -7200 > # Thu Aug 21 11:05:35 2014 +0200 > # Node ID b8f27b54cc51c17c7debcf7048c8b81b221f931c > # Parent 0aa1bc5db42cb7b66678181bc32fefdb8bafcba8 > 8055188: General cleanup of minor issues from source restructure > Reviewed-by: tbell > > > > On Sun, Aug 24, 2014 at 7:18 PM, David Holmes > wrote: > >> cc'ing hotspot-dev >> >> Which forest are you trying to build and is it fully up to date? >> >> David >> >> >> On 23/08/2014 9:10 AM, Mani Sarkar wrote: >> >>> Hi, >>> >>> Lately I have been getting a lot of build failures and the most recent >>> ones >>> are the below (snippets of the error messages from the logs): >>> >>> *First instance after running make images* >>> . >>> . >>> . >>> make[4]: warning: -jN forced in submake: disabling jobserver mode. >>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>> INFO: ALT_OBJCOPY=/usr/bin/objcopy >>> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >>> INFO: STRIP_POLICY=min_strip >>> INFO: ZIP_DEBUGINFO_FILES=1 >>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>> INFO: ALT_OBJCOPY=/usr/bin/objcopy >>> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >>> INFO: STRIP_POLICY=min_strip >>> INFO: ZIP_DEBUGINFO_FILES=1 >>> Compiling 163 files for BUILD_TOOLS_JDK >>> Compiling 1492 files for BUILD_INTERIM_CORBA >>> Rescanned ../generated/adfiles/linux_x86_64.ad but encountered no >>> changes. >>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>> INFO: ALT_OBJCOPY=/usr/bin/objcopy >>> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >>> INFO: STRIP_POLICY=min_strip >>> INFO: ZIP_DEBUGINFO_FILES=1 >>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>> INFO: ALT_OBJCOPY=/usr/bin/objcopy >>> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >>> INFO: STRIP_POLICY=min_strip >>> INFO: ZIP_DEBUGINFO_FILES=1 >>> **NOTICE** Dtrace support disabled: //usr/include/sys/sdt.h not found >>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>> INFO: ALT_OBJCOPY=/usr/bin/objcopy >>> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >>> INFO: STRIP_POLICY=min_strip >>> INFO: ZIP_DEBUGINFO_FILES=1 >>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>> INFO: ALT_OBJCOPY=/usr/bin/objcopy >>> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >>> INFO: STRIP_POLICY=min_strip >>> INFO: ZIP_DEBUGINFO_FILES=1 >>> Compiling >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp >>> Compiling >>> >>> /home/satyasai/sources/jdk9/hotspot/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp >>> Compiling >>> /home/satyasai/sources/jdk9/hotspot/src/cpu/x86/vm/assembler_x86.cpp >>> Compiling >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/atomic.cpp >>> In file included from >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp:28:0: >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp: >>> In member function ?virtual Generation::Name ASParNewGeneration::kind()?: >>> . >>> . >>> . >>> In file included from >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp:28:0: >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp: >>> In member function ?virtual Generation::Name ASParNewGeneration::kind()?: >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp:81:44: >>> error: ?ASParNew? was not declared in this scope >>> >>> /home/satyasai/sources/jdk9/jdk/make/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java:274: >>> error: incompatible types: Month cannot be converted to int >>> LocalDate adjustedDate = LocalDate.of(year, month, >>> dayOfMonth).minusDays(6); >>> . >>> . >>> . >>> 15 errors >>> make[3]: *** >>> >>> [/home/satyasai/sources/jdk9/build/linux-x86_64-normal-server-release/jdk/btclasses/_the.BUILD_TOOLS_JDK_batch] >>> Error 1 >>> make[2]: *** [build-tools-jdk] Error 2 >>> make[2]: *** Waiting for unfinished jobs.... >>> make[8]: *** [asParNewGeneration.o] Error 1 >>> make[8]: *** Waiting for unfinished jobs.... >>> Note: Some input files use or override a deprecated API. >>> Note: Recompile with -Xlint:deprecation for details. >>> Note: Some input files use unchecked or unsafe operations. >>> Note: Recompile with -Xlint:unchecked for details. >>> Creating corba/dist/interim_corba.jar >>> make[7]: *** [the_vm] Error 2 >>> make[6]: *** [product] Error 2 >>> make[5]: *** [generic_build2] Error 2 >>> make[4]: *** [product] Error 2 >>> make[3]: *** >>> >>> [/home/satyasai/sources/jdk9/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >>> Error 2 >>> make[2]: *** [hotspot] Error 2 >>> make[1]: *** [main-wrapper] Error 2 >>> make: *** [images] Error 2 >>> >>> >>> *Second instance after running make clean followed by make images* >>> . >>> . >>> . >>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>> INFO: ALT_OBJCOPY=/usr/bin/objcopy >>> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >>> INFO: STRIP_POLICY=min_strip >>> INFO: ZIP_DEBUGINFO_FILES=1 >>> Generating precompiled header precompiled.hpp.gch >>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>> INFO: ALT_OBJCOPY=/usr/bin/objcopy >>> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >>> INFO: STRIP_POLICY=min_strip >>> INFO: ZIP_DEBUGINFO_FILES=1 >>> Compiling >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/compiler/abstractCompiler.cpp >>> Compiling >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/utilities/accessFlags.cpp >>> Compiling ../generated/adfiles/ad_x86_64.cpp >>> Compiling ../generated/adfiles/ad_x86_64_clone.cpp >>> Compiling ../generated/adfiles/ad_x86_64_expand.cpp >>> Compiling ../generated/adfiles/ad_x86_64_format.cpp >>> Compiling ../generated/adfiles/ad_x86_64_gen.cpp >>> Compiling ../generated/adfiles/ad_x86_64_misc.cpp >>> Compiling ../generated/adfiles/ad_x86_64_peephole.cpp >>> Compiling ../generated/adfiles/ad_x86_64_pipeline.cpp >>> >>> Compiling >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp >>> >>> Compiling >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp >>> Compiling >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/opto/addnode.cpp >>> Compiling >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.cpp >>> Compiling >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp >>> Compiling >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/advancedThresholdPolicy.cpp >>> Compiling >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/shared/ageTable.cpp >>> Compiling >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_interface/allocTracer.cpp >>> Compiling >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/memory/allocation.cpp >>> Compiling >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/shared/allocationStats.cpp >>> Compiling >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/classfile/altHashing.cpp >>> Compiling >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/oops/annotations.cpp >>> Compiling >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/arguments.cpp >>> Compiling >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/arguments_ext.cpp >>> Compiling >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/utilities/array.cpp >>> Compiling >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/oops/arrayKlass.cpp >>> Compiling >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/oops/arrayOop.cpp >>> Compiling >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp >>> Compiling >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp >>> Compiling >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp >>> >>> In file included from >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp:28:0: >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp: >>> In member function ?virtual Generation::Name ASParNewGeneration::kind()?: >>> >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp:81:44: >>> error: ?ASParNew? was not declared in this scope >>> Compiling >>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/asm/assembler.cpp >>> make[8]: *** [asParNewGeneration.o] Error 1 >>> make[8]: *** Waiting for unfinished jobs.... >>> make[7]: *** [the_vm] Error 2 >>> make[6]: *** [product] Error 2 >>> make[5]: *** [generic_build2] Error 2 >>> make[4]: *** [product] Error 2 >>> make[3]: *** >>> >>> [/home/satyasai/sources/jdk9/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >>> Error 2 >>> make[2]: *** [hotspot] Error 2 >>> make[1]: *** [main-wrapper] Error 2 >>> make: *** [images] Error 2 >>> >>> >>> My sources is updated on a regular-basis, and the above are on the most >>> recent version of the source. If you need anything else to help with >>> investigating the the above error please let me know. >>> >>> Cheers, >>> Mani >>> >>> > > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2014:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From erik.joelsson at oracle.com Mon Aug 25 11:05:09 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 25 Aug 2014 13:05:09 +0200 Subject: OpenJDK9 - build errors on Linux/Ubuntu 12.04 In-Reply-To: References: <53FA9CE0.20908@oracle.com> <53FAFC2A.4080901@oracle.com> Message-ID: <53FB1865.1000103@oracle.com> Helo Mani, I don't think your problem was the same as Martin's. Recloning might be a good idea still. /Erik On 2014-08-25 12:06, Mani Sarkar wrote: > I;m building jdk9/jdk9 - as always (is that not the right forest) and > yes its getting the latest changes from the repo. I can try zapping > all the folders and re-apply getsource. > > Cheers, > Mani > > > On Mon, Aug 25, 2014 at 10:04 AM, Erik Joelsson > > wrote: > > I renamed the file make/common/SetupJava.gmk to > make/common/SetupJavaCompilers.gmk. This required changes in both > the root repo and the jdk repo and AFAIK I pushed both more or > less at the same time. I'm guessing you still managed to hit the > race condition when pulling changes. > > /Erik > > > On 2014-08-25 04:36, Martin Buchholz wrote: >> I tried again today ( with jdk9/jdk9-dev ) and everything works >> now. I believe the problem was fixed by the following, which >> replaced erroneous references to SetupJava.gmk >> >> # HG changeset patch >> # User erikj >> # Date 1408611935 -7200 >> # Thu Aug 21 11:05:35 2014 +0200 >> # Node ID b8f27b54cc51c17c7debcf7048c8b81b221f931c >> # Parent 0aa1bc5db42cb7b66678181bc32fefdb8bafcba8 >> 8055188: General cleanup of minor issues from source restructure >> Reviewed-by: tbell >> >> >> >> On Sun, Aug 24, 2014 at 7:18 PM, David Holmes >> > wrote: >> >> cc'ing hotspot-dev >> >> Which forest are you trying to build and is it fully up to date? >> >> David >> >> >> On 23/08/2014 9:10 AM, Mani Sarkar wrote: >> >> Hi, >> >> Lately I have been getting a lot of build failures and >> the most recent ones >> are the below (snippets of the error messages from the logs): >> >> *First instance after running make images* >> . >> . >> . >> make[4]: warning: -jN forced in submake: disabling >> jobserver mode. >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create >> .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create >> .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> Compiling 163 files for BUILD_TOOLS_JDK >> Compiling 1492 files for BUILD_INTERIM_CORBA >> Rescanned ../generated/adfiles/linux_x86_64.ad >> but encountered no changes. >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create >> .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create >> .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> **NOTICE** Dtrace support disabled: >> //usr/include/sys/sdt.h not found >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create >> .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create >> .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/cpu/x86/vm/assembler_x86.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/atomic.cpp >> In file included from >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp:28:0: >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp: >> In member function ?virtual Generation::Name >> ASParNewGeneration::kind()?: >> . >> . >> . >> In file included from >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp:28:0: >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp: >> In member function ?virtual Generation::Name >> ASParNewGeneration::kind()?: >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp:81:44: >> error: ?ASParNew? was not declared in this scope >> /home/satyasai/sources/jdk9/jdk/make/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java:274: >> error: incompatible types: Month cannot be converted to int >> LocalDate adjustedDate = >> LocalDate.of(year, month, >> dayOfMonth).minusDays(6); >> . >> . >> . >> 15 errors >> make[3]: *** >> [/home/satyasai/sources/jdk9/build/linux-x86_64-normal-server-release/jdk/btclasses/_the.BUILD_TOOLS_JDK_batch] >> Error 1 >> make[2]: *** [build-tools-jdk] Error 2 >> make[2]: *** Waiting for unfinished jobs.... >> make[8]: *** [asParNewGeneration.o] Error 1 >> make[8]: *** Waiting for unfinished jobs.... >> Note: Some input files use or override a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> Creating corba/dist/interim_corba.jar >> make[7]: *** [the_vm] Error 2 >> make[6]: *** [product] Error 2 >> make[5]: *** [generic_build2] Error 2 >> make[4]: *** [product] Error 2 >> make[3]: *** >> [/home/satyasai/sources/jdk9/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >> Error 2 >> make[2]: *** [hotspot] Error 2 >> make[1]: *** [main-wrapper] Error 2 >> make: *** [images] Error 2 >> >> >> *Second instance after running make clean followed by >> make images* >> . >> . >> . >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create >> .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> Generating precompiled header precompiled.hpp.gch >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create >> .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/compiler/abstractCompiler.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/utilities/accessFlags.cpp >> Compiling ../generated/adfiles/ad_x86_64.cpp >> Compiling ../generated/adfiles/ad_x86_64_clone.cpp >> Compiling ../generated/adfiles/ad_x86_64_expand.cpp >> Compiling ../generated/adfiles/ad_x86_64_format.cpp >> Compiling ../generated/adfiles/ad_x86_64_gen.cpp >> Compiling ../generated/adfiles/ad_x86_64_misc.cpp >> Compiling ../generated/adfiles/ad_x86_64_peephole.cpp >> Compiling ../generated/adfiles/ad_x86_64_pipeline.cpp >> >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp >> >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/opto/addnode.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/advancedThresholdPolicy.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/shared/ageTable.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_interface/allocTracer.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/memory/allocation.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/shared/allocationStats.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/classfile/altHashing.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/oops/annotations.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/arguments.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/arguments_ext.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/utilities/array.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/oops/arrayKlass.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/oops/arrayOop.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp >> >> In file included from >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp:28:0: >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp: >> In member function ?virtual Generation::Name >> ASParNewGeneration::kind()?: >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp:81:44: >> error: ?ASParNew? was not declared in this scope >> Compiling >> /home/satyasai/sources/jdk9/hotspot/src/share/vm/asm/assembler.cpp >> make[8]: *** [asParNewGeneration.o] Error 1 >> make[8]: *** Waiting for unfinished jobs.... >> make[7]: *** [the_vm] Error 2 >> make[6]: *** [product] Error 2 >> make[5]: *** [generic_build2] Error 2 >> make[4]: *** [product] Error 2 >> make[3]: *** >> [/home/satyasai/sources/jdk9/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >> Error 2 >> make[2]: *** [hotspot] Error 2 >> make[1]: *** [main-wrapper] Error 2 >> make: *** [images] Error 2 >> >> >> My sources is updated on a regular-basis, and the above >> are on the most >> recent version of the source. If you need anything else >> to help with >> investigating the the above error please let me know. >> >> Cheers, >> Mani >> >> > > > > > -- > @theNeomatrix369 *| **Blog > **| *LJC Associate & LJC Advocate > (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project - *MutabilityDetector > *| **Bitbucket > * * | **Github > ** | **LinkedIn > * > *Come to Devoxx UK 2014:* http://www.devoxx.co.uk/ > > */Don't chase success, rather aim for "Excellence", and success will > come chasing after you!/* From sadhak001 at gmail.com Mon Aug 25 11:12:57 2014 From: sadhak001 at gmail.com (Mani Sarkar) Date: Mon, 25 Aug 2014 12:12:57 +0100 Subject: OpenJDK9 - build errors on Linux/Ubuntu 12.04 In-Reply-To: <53FB1865.1000103@oracle.com> References: <53FA9CE0.20908@oracle.com> <53FAFC2A.4080901@oracle.com> <53FB1865.1000103@oracle.com> Message-ID: Hey Erik, Build finished successfully, I rarely take this approach so thanks for confirming. Can I attribute this to some sort of 'Mercurial changesets not trickling down to my machine' problem ;) Cheers Mani On Mon, Aug 25, 2014 at 12:05 PM, Erik Joelsson wrote: > Helo Mani, > > I don't think your problem was the same as Martin's. Recloning might be a > good idea still. > > /Erik > > On 2014-08-25 12:06, Mani Sarkar wrote: > > I;m building jdk9/jdk9 - as always (is that not the right forest) and yes > its getting the latest changes from the repo. I can try zapping all the > folders and re-apply getsource. > > Cheers, > Mani > > > On Mon, Aug 25, 2014 at 10:04 AM, Erik Joelsson > wrote: > >> I renamed the file make/common/SetupJava.gmk to >> make/common/SetupJavaCompilers.gmk. This required changes in both the root >> repo and the jdk repo and AFAIK I pushed both more or less at the same >> time. I'm guessing you still managed to hit the race condition when pulling >> changes. >> >> /Erik >> >> >> On 2014-08-25 04:36, Martin Buchholz wrote: >> >> I tried again today ( with jdk9/jdk9-dev ) and everything works now. I >> believe the problem was fixed by the following, which replaced erroneous >> references to SetupJava.gmk >> >> # HG changeset patch >> # User erikj >> # Date 1408611935 -7200 >> # Thu Aug 21 11:05:35 2014 +0200 >> # Node ID b8f27b54cc51c17c7debcf7048c8b81b221f931c >> # Parent 0aa1bc5db42cb7b66678181bc32fefdb8bafcba8 >> 8055188: General cleanup of minor issues from source restructure >> Reviewed-by: tbell >> >> >> >> On Sun, Aug 24, 2014 at 7:18 PM, David Holmes >> wrote: >> >>> cc'ing hotspot-dev >>> >>> Which forest are you trying to build and is it fully up to date? >>> >>> David >>> >>> >>> On 23/08/2014 9:10 AM, Mani Sarkar wrote: >>> >>>> Hi, >>>> >>>> Lately I have been getting a lot of build failures and the most recent >>>> ones >>>> are the below (snippets of the error messages from the logs): >>>> >>>> *First instance after running make images* >>>> . >>>> . >>>> . >>>> make[4]: warning: -jN forced in submake: disabling jobserver mode. >>>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>>> INFO: ALT_OBJCOPY=/usr/bin/objcopy >>>> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >>>> INFO: STRIP_POLICY=min_strip >>>> INFO: ZIP_DEBUGINFO_FILES=1 >>>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>>> INFO: ALT_OBJCOPY=/usr/bin/objcopy >>>> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >>>> INFO: STRIP_POLICY=min_strip >>>> INFO: ZIP_DEBUGINFO_FILES=1 >>>> Compiling 163 files for BUILD_TOOLS_JDK >>>> Compiling 1492 files for BUILD_INTERIM_CORBA >>>> Rescanned ../generated/adfiles/linux_x86_64.ad but encountered no >>>> changes. >>>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>>> INFO: ALT_OBJCOPY=/usr/bin/objcopy >>>> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >>>> INFO: STRIP_POLICY=min_strip >>>> INFO: ZIP_DEBUGINFO_FILES=1 >>>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>>> INFO: ALT_OBJCOPY=/usr/bin/objcopy >>>> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >>>> INFO: STRIP_POLICY=min_strip >>>> INFO: ZIP_DEBUGINFO_FILES=1 >>>> **NOTICE** Dtrace support disabled: //usr/include/sys/sdt.h not found >>>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>>> INFO: ALT_OBJCOPY=/usr/bin/objcopy >>>> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >>>> INFO: STRIP_POLICY=min_strip >>>> INFO: ZIP_DEBUGINFO_FILES=1 >>>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>>> INFO: ALT_OBJCOPY=/usr/bin/objcopy >>>> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >>>> INFO: STRIP_POLICY=min_strip >>>> INFO: ZIP_DEBUGINFO_FILES=1 >>>> Compiling >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp >>>> Compiling >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp >>>> Compiling >>>> /home/satyasai/sources/jdk9/hotspot/src/cpu/x86/vm/assembler_x86.cpp >>>> Compiling >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/atomic.cpp >>>> In file included from >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp:28:0: >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp: >>>> In member function ?virtual Generation::Name >>>> ASParNewGeneration::kind()?: >>>> . >>>> . >>>> . >>>> In file included from >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp:28:0: >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp: >>>> In member function ?virtual Generation::Name >>>> ASParNewGeneration::kind()?: >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp:81:44: >>>> error: ?ASParNew? was not declared in this scope >>>> >>>> /home/satyasai/sources/jdk9/jdk/make/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java:274: >>>> error: incompatible types: Month cannot be converted to int >>>> LocalDate adjustedDate = LocalDate.of(year, month, >>>> dayOfMonth).minusDays(6); >>>> . >>>> . >>>> . >>>> 15 errors >>>> make[3]: *** >>>> >>>> [/home/satyasai/sources/jdk9/build/linux-x86_64-normal-server-release/jdk/btclasses/_the.BUILD_TOOLS_JDK_batch] >>>> Error 1 >>>> make[2]: *** [build-tools-jdk] Error 2 >>>> make[2]: *** Waiting for unfinished jobs.... >>>> make[8]: *** [asParNewGeneration.o] Error 1 >>>> make[8]: *** Waiting for unfinished jobs.... >>>> Note: Some input files use or override a deprecated API. >>>> Note: Recompile with -Xlint:deprecation for details. >>>> Note: Some input files use unchecked or unsafe operations. >>>> Note: Recompile with -Xlint:unchecked for details. >>>> Creating corba/dist/interim_corba.jar >>>> make[7]: *** [the_vm] Error 2 >>>> make[6]: *** [product] Error 2 >>>> make[5]: *** [generic_build2] Error 2 >>>> make[4]: *** [product] Error 2 >>>> make[3]: *** >>>> >>>> [/home/satyasai/sources/jdk9/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >>>> Error 2 >>>> make[2]: *** [hotspot] Error 2 >>>> make[1]: *** [main-wrapper] Error 2 >>>> make: *** [images] Error 2 >>>> >>>> >>>> *Second instance after running make clean followed by make images* >>>> . >>>> . >>>> . >>>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>>> INFO: ALT_OBJCOPY=/usr/bin/objcopy >>>> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >>>> INFO: STRIP_POLICY=min_strip >>>> INFO: ZIP_DEBUGINFO_FILES=1 >>>> Generating precompiled header precompiled.hpp.gch >>>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>>> INFO: ALT_OBJCOPY=/usr/bin/objcopy >>>> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >>>> INFO: STRIP_POLICY=min_strip >>>> INFO: ZIP_DEBUGINFO_FILES=1 >>>> Compiling >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/compiler/abstractCompiler.cpp >>>> Compiling >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/utilities/accessFlags.cpp >>>> Compiling ../generated/adfiles/ad_x86_64.cpp >>>> Compiling ../generated/adfiles/ad_x86_64_clone.cpp >>>> Compiling ../generated/adfiles/ad_x86_64_expand.cpp >>>> Compiling ../generated/adfiles/ad_x86_64_format.cpp >>>> Compiling ../generated/adfiles/ad_x86_64_gen.cpp >>>> Compiling ../generated/adfiles/ad_x86_64_misc.cpp >>>> Compiling ../generated/adfiles/ad_x86_64_peephole.cpp >>>> Compiling ../generated/adfiles/ad_x86_64_pipeline.cpp >>>> >>>> Compiling >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp >>>> >>>> Compiling >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp >>>> Compiling >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/opto/addnode.cpp >>>> Compiling >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.cpp >>>> Compiling >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp >>>> Compiling >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/advancedThresholdPolicy.cpp >>>> Compiling >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/shared/ageTable.cpp >>>> Compiling >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_interface/allocTracer.cpp >>>> Compiling >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/memory/allocation.cpp >>>> Compiling >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/shared/allocationStats.cpp >>>> Compiling >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/classfile/altHashing.cpp >>>> Compiling >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/oops/annotations.cpp >>>> Compiling >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/arguments.cpp >>>> Compiling >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/runtime/arguments_ext.cpp >>>> Compiling >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/utilities/array.cpp >>>> Compiling >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/oops/arrayKlass.cpp >>>> Compiling >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/oops/arrayOop.cpp >>>> Compiling >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp >>>> Compiling >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp >>>> Compiling >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp >>>> >>>> In file included from >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp:28:0: >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp: >>>> In member function ?virtual Generation::Name >>>> ASParNewGeneration::kind()?: >>>> >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp:81:44: >>>> error: ?ASParNew? was not declared in this scope >>>> Compiling >>>> /home/satyasai/sources/jdk9/hotspot/src/share/vm/asm/assembler.cpp >>>> make[8]: *** [asParNewGeneration.o] Error 1 >>>> make[8]: *** Waiting for unfinished jobs.... >>>> make[7]: *** [the_vm] Error 2 >>>> make[6]: *** [product] Error 2 >>>> make[5]: *** [generic_build2] Error 2 >>>> make[4]: *** [product] Error 2 >>>> make[3]: *** >>>> >>>> [/home/satyasai/sources/jdk9/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >>>> Error 2 >>>> make[2]: *** [hotspot] Error 2 >>>> make[1]: *** [main-wrapper] Error 2 >>>> make: *** [images] Error 2 >>>> >>>> >>>> My sources is updated on a regular-basis, and the above are on the most >>>> recent version of the source. If you need anything else to help with >>>> investigating the the above error please let me know. >>>> >>>> Cheers, >>>> Mani >>>> >>>> >> >> > > > -- > @theNeomatrix369 * | **Blog > ** | *LJC Associate & LJC Advocate > (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project - *MutabilityDetector > * | **Bitbucket > * * | **Github > * * | **LinkedIn > * > *Come to Devoxx UK 2014:* http://www.devoxx.co.uk/ > > *Don't chase success, rather aim for "Excellence", and success will come > chasing after you!* > > > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2014:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From thomas.stuefe at gmail.com Mon Aug 25 14:55:57 2014 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 25 Aug 2014 16:55:57 +0200 Subject: linux, os::current_thread_id() vs os::Linux::gettid() Message-ID: Hi, I wonder about the implementation of os::current_thread_id() on Linux. There is os::Linux::gettid() and os::current_thread_id(). os::Linux::gettid() returns the kernel thread id, os::current_thread_id() returns the pthread id. os::Linux::gettid() is used to initialize OSThread::_thread_id, so that contains the kernel thread id. So now we get conflicting information from OSThread::thread_id and os::current_thread_id(). As far as I see, all other platforms consistently return the kernel thread id on both code paths. Am I overlooking something or is this behaviour intentional? Kind Regards, ..Thomas From david.holmes at oracle.com Tue Aug 26 03:46:54 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Aug 2014 13:46:54 +1000 Subject: linux, os::current_thread_id() vs os::Linux::gettid() In-Reply-To: References: Message-ID: <53FC032E.7010507@oracle.com> Hi Thomas, On 26/08/2014 12:55 AM, Thomas St?fe wrote: > Hi, > > I wonder about the implementation of os::current_thread_id() on Linux. > > There is os::Linux::gettid() and os::current_thread_id(). > os::Linux::gettid() returns the kernel thread id, os::current_thread_id() > returns the pthread id. > > os::Linux::gettid() is used to initialize OSThread::_thread_id, so that > contains the kernel thread id. So now we get conflicting information from > OSThread::thread_id and os::current_thread_id(). > > As far as I see, all other platforms consistently return the kernel thread > id on both code paths. Only AIX and BSD have gettid and both those ports were based on the Linux code. > Am I overlooking something or is this behaviour intentional? Intentional but historical, going back to old LinuxThreads. Probably one of many cleanups that can be done in the linux code. David > > Kind Regards, > > ..Thomas > From david.holmes at oracle.com Tue Aug 26 03:57:57 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Aug 2014 13:57:57 +1000 Subject: linux, os::current_thread_id() vs os::Linux::gettid() In-Reply-To: <53FC032E.7010507@oracle.com> References: <53FC032E.7010507@oracle.com> Message-ID: <53FC05C5.4060809@oracle.com> On 26/08/2014 1:46 PM, David Holmes wrote: > Hi Thomas, > > On 26/08/2014 12:55 AM, Thomas St?fe wrote: >> Hi, >> >> I wonder about the implementation of os::current_thread_id() on Linux. >> >> There is os::Linux::gettid() and os::current_thread_id(). >> os::Linux::gettid() returns the kernel thread id, os::current_thread_id() >> returns the pthread id. >> >> os::Linux::gettid() is used to initialize OSThread::_thread_id, so that >> contains the kernel thread id. So now we get conflicting information from >> OSThread::thread_id and os::current_thread_id(). >> >> As far as I see, all other platforms consistently return the kernel >> thread id on both code paths. > > Only AIX and BSD have gettid and both those ports were based on the > Linux code. Sorry misunderstood your comment. Yes other platforms currently use the same low-level thread id for the OSThread and os::current_thread_id(). I suspect if you could look back in time that Solaris would have also had different usages eg for LWP id versus user-level thread id. David ----- >> Am I overlooking something or is this behaviour intentional? > > Intentional but historical, going back to old LinuxThreads. Probably one > of many cleanups that can be done in the linux code. > > David > >> >> Kind Regards, >> >> ..Thomas >> From thomas.stuefe at gmail.com Tue Aug 26 06:24:31 2014 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 26 Aug 2014 08:24:31 +0200 Subject: linux, os::current_thread_id() vs os::Linux::gettid() In-Reply-To: <53FC05C5.4060809@oracle.com> References: <53FC032E.7010507@oracle.com> <53FC05C5.4060809@oracle.com> Message-ID: Hi David, Thank you for answering. The reason I ask is that I work on the AIX port and would like to remove the use of kernel thread ids. For one, AIX kernel thread ids are 64bit, so we have a truncation error by casting them to 32bit pid_t; also, a pthread may be scheduled to multiple kernel threads during its lifetime by the AIX scheduler. I think the reason we introduced kernel thread ids was because other platform ports do it too, so I wanted to know the reason. Thomas On Tue, Aug 26, 2014 at 5:57 AM, David Holmes wrote: > On 26/08/2014 1:46 PM, David Holmes wrote: > >> Hi Thomas, >> >> On 26/08/2014 12:55 AM, Thomas St?fe wrote: >> >>> Hi, >>> >>> I wonder about the implementation of os::current_thread_id() on Linux. >>> >>> There is os::Linux::gettid() and os::current_thread_id(). >>> os::Linux::gettid() returns the kernel thread id, os::current_thread_id() >>> returns the pthread id. >>> >>> os::Linux::gettid() is used to initialize OSThread::_thread_id, so that >>> contains the kernel thread id. So now we get conflicting information from >>> OSThread::thread_id and os::current_thread_id(). >>> >>> As far as I see, all other platforms consistently return the kernel >>> thread id on both code paths. >>> >> >> Only AIX and BSD have gettid and both those ports were based on the >> Linux code. >> > > Sorry misunderstood your comment. Yes other platforms currently use the > same low-level thread id for the OSThread and os::current_thread_id(). I > suspect if you could look back in time that Solaris would have also had > different usages eg for LWP id versus user-level thread id. > > David > ----- > > > Am I overlooking something or is this behaviour intentional? >>> >> >> Intentional but historical, going back to old LinuxThreads. Probably one >> of many cleanups that can be done in the linux code. >> >> David >> >> >>> Kind Regards, >>> >>> ..Thomas >>> >>> From david.holmes at oracle.com Tue Aug 26 06:33:15 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Aug 2014 16:33:15 +1000 Subject: linux, os::current_thread_id() vs os::Linux::gettid() In-Reply-To: References: <53FC032E.7010507@oracle.com> <53FC05C5.4060809@oracle.com> Message-ID: <53FC2A2B.20800@oracle.com> On 26/08/2014 4:24 PM, Thomas St?fe wrote: > Hi David, > > Thank you for answering. > > The reason I ask is that I work on the AIX port and would like to remove > the use of kernel thread ids. > > For one, AIX kernel thread ids are 64bit, so we have a truncation error > by casting them to 32bit pid_t; also, a pthread may be scheduled to > multiple kernel threads during its lifetime by the AIX scheduler. I > think the reason we introduced kernel thread ids was because other > platform ports do it too, so I wanted to know the reason. I think it would be safe to remove them. Any port that started from the linux code tends to inherit its historical baggage. David > > Thomas > > > > > > > > > On Tue, Aug 26, 2014 at 5:57 AM, David Holmes > wrote: > > On 26/08/2014 1:46 PM, David Holmes wrote: > > Hi Thomas, > > On 26/08/2014 12:55 AM, Thomas St?fe wrote: > > Hi, > > I wonder about the implementation of os::current_thread_id() > on Linux. > > There is os::Linux::gettid() and os::current_thread_id(). > os::Linux::gettid() returns the kernel thread id, > os::current_thread_id() > returns the pthread id. > > os::Linux::gettid() is used to initialize > OSThread::_thread_id, so that > contains the kernel thread id. So now we get conflicting > information from > OSThread::thread_id and os::current_thread_id(). > > As far as I see, all other platforms consistently return the > kernel > thread id on both code paths. > > > Only AIX and BSD have gettid and both those ports were based on the > Linux code. > > > Sorry misunderstood your comment. Yes other platforms currently use > the same low-level thread id for the OSThread and > os::current_thread_id(). I suspect if you could look back in time > that Solaris would have also had different usages eg for LWP id > versus user-level thread id. > > David > ----- > > > Am I overlooking something or is this behaviour intentional? > > > Intentional but historical, going back to old LinuxThreads. > Probably one > of many cleanups that can be done in the linux code. > > David > > > Kind Regards, > > ..Thomas > > From thomas.stuefe at gmail.com Tue Aug 26 07:18:01 2014 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 26 Aug 2014 09:18:01 +0200 Subject: linux, os::current_thread_id() vs os::Linux::gettid() In-Reply-To: <53FC2A2B.20800@oracle.com> References: <53FC032E.7010507@oracle.com> <53FC05C5.4060809@oracle.com> <53FC2A2B.20800@oracle.com> Message-ID: Ok, I will change this first in our code base and then Goetz or me will port it to the OpenJdk. Thank you for clarification! ..Thomas On Tue, Aug 26, 2014 at 8:33 AM, David Holmes wrote: > On 26/08/2014 4:24 PM, Thomas St?fe wrote: > >> Hi David, >> >> Thank you for answering. >> >> The reason I ask is that I work on the AIX port and would like to remove >> the use of kernel thread ids. >> >> For one, AIX kernel thread ids are 64bit, so we have a truncation error >> by casting them to 32bit pid_t; also, a pthread may be scheduled to >> multiple kernel threads during its lifetime by the AIX scheduler. I >> think the reason we introduced kernel thread ids was because other >> platform ports do it too, so I wanted to know the reason. >> > > I think it would be safe to remove them. Any port that started from the > linux code tends to inherit its historical baggage. > > David > > >> Thomas >> >> >> >> >> >> >> >> >> On Tue, Aug 26, 2014 at 5:57 AM, David Holmes > > wrote: >> >> On 26/08/2014 1:46 PM, David Holmes wrote: >> >> Hi Thomas, >> >> On 26/08/2014 12:55 AM, Thomas St?fe wrote: >> >> Hi, >> >> I wonder about the implementation of os::current_thread_id() >> on Linux. >> >> There is os::Linux::gettid() and os::current_thread_id(). >> os::Linux::gettid() returns the kernel thread id, >> os::current_thread_id() >> returns the pthread id. >> >> os::Linux::gettid() is used to initialize >> OSThread::_thread_id, so that >> contains the kernel thread id. So now we get conflicting >> information from >> OSThread::thread_id and os::current_thread_id(). >> >> As far as I see, all other platforms consistently return the >> kernel >> thread id on both code paths. >> >> >> Only AIX and BSD have gettid and both those ports were based on >> the >> Linux code. >> >> >> Sorry misunderstood your comment. Yes other platforms currently use >> the same low-level thread id for the OSThread and >> os::current_thread_id(). I suspect if you could look back in time >> that Solaris would have also had different usages eg for LWP id >> versus user-level thread id. >> >> David >> ----- >> >> >> Am I overlooking something or is this behaviour intentional? >> >> >> Intentional but historical, going back to old LinuxThreads. >> Probably one >> of many cleanups that can be done in the linux code. >> >> David >> >> >> Kind Regards, >> >> ..Thomas >> >> >> From mikael.gerdin at oracle.com Tue Aug 26 10:17:32 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 26 Aug 2014 12:17:32 +0200 Subject: RFR 8056039: Hotspot does not compile with clang 3.4 on Linux Message-ID: <1593876.cxpFjnnrsK@mgerdin03> Hi all, In order to get clang's (sometimes) more helpful error messages when compiling I'd like to fix the few remaining places where clang fails to compile Hotspot. The culprit in this case was "local_vsnprintf" in os_linux.cpp, an unused function which wasn't annotaded with the PRINTF_FORMAT macro. Since the function was unused I decided to remove it instead, then I found it in the other os_*nix.cpp files as well. Digging into the Teamware history it looks like it first appeared in the Solaris port because vsnprintf did not exist on some very old versions of Solaris, so it was dynamically looked up through dlsym. For a few years vsnprintf has been present in the Solaris header files, so I think it's safe to remove the workaround now some 17 years later. I also need a SCANF_FORMAT for an internal file, so I added that to globalDefinitions. Webrev: http://cr.openjdk.java.net/~mgerdin/8056039/webrev/ Buglink: https://bugs.openjdk.java.net/browse/JDK-8056039 Thanks /Mikael From erik.joelsson at oracle.com Tue Aug 26 10:53:34 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 26 Aug 2014 12:53:34 +0200 Subject: RFR: JDK-8056053: Disable HOTSPOT_BUILD_JOBS when building with configure Message-ID: <53FC672E.4020907@oracle.com> Hello, Please review this proposed fix for the Hotspot build. In the new jdk9 build, we utilize the gnu make job server, which automatically makes sure the -j flag gets propagated and shared between all recursive make calls. In the hotspot build, this gets overridden by the HOTSPOT_BUILD_JOBS variable. Configure estimates a reasonable number of parallel make jobs into the JOBS variable, which gets propagated to the HOTSPOT_BUILD_JOBS variable. This used to work well enough, but in the new build, the hotspot build is happening concurrently with other parts of the build and the consequence is that the hotspot build gets JOBS number of jobs and the rest of the build also gets JOBS number of jobs, all of which are used at the same time. We would like the whole build to share in the same job pool. To fix this, the setting of -j$(HOTSPOT_BUILD_JOBS) needs to be made conditional and we need to add .NOTPARALLEL: to a number of makefiles in hotspot that currently can't handle being executed in parallel. Lastly, the + sign must be added first to recipe lines that call make recursively but are not explicitly using the MAKE variable directly. The result will be that the active -j flag in the root makefiles will just automatically propagate down to the hotspot makefiles. Bug: https://bugs.openjdk.java.net/browse/JDK-8056053 Webrev: http://cr.openjdk.java.net/~erikj/8056053/webrev.01/ /Erik From jesper.wilhelmsson at oracle.com Tue Aug 26 11:28:04 2014 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 26 Aug 2014 13:28:04 +0200 Subject: RFR[P1]: 8055744 - 8u-dev nightly solaris builds failed on 08/20 In-Reply-To: <53FA8841.1030604@oracle.com> References: <53F61C09.4060300@oracle.com> <53F62164.2030001@oracle.com> <53F626BA.70204@oracle.com> <53FA8841.1030604@oracle.com> Message-ID: <53FC6F44.2030405@oracle.com> Hi David, The change was pushed on Friday so it included the change in the Makefile. I filed JDK-8056056 to remove it. Thanks! /Jesper David Holmes skrev 25/8/14 02:50: > Sorry I'm late but had a long weekend and was off last Friday. > > On 22/08/2014 3:04 AM, Jesper Wilhelmsson wrote: >> Thank you for the quick reply Dan! >> >> A new webrev with your suggested change is available here: >> >> http://cr.openjdk.java.net/~jwilhelm/8055744/webrev.02/ > > The change in make/solaris/Makefile isn't necessary. buildtree.make already > includes defs.make which defines HS_ALT_MAKE. > > If this is already pushed please follow up with a correction. But don't push > this part of 8u. > > Thanks, > David > >> /Jesper >> >> >> Daniel D. Daugherty skrev 21/8/14 18:42: >>> On 8/21/14 10:19 AM, Jesper Wilhelmsson wrote: >>>> Hi, >>>> >>>> On Solaris the HS_ALT_MAKE variable was not passed to vm.make when >>>> creating >>>> the mapfiles which lead to mapfile-ext not being found and later a >>>> linker >>>> error due to symbols declared in the extra mapfile not being found. >>>> >>>> The hotspot makefiles are .. interesting .. yes. >>>> >>>> The proposed solution is to include defs.make where HS_ALT_MAKE is >>>> set up into >>>> vm.make on Solaris. >>>> >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~jwilhelm/8055744/webrev/ >>> >>> Unfortunately, including defs.make in make/solaris/makefiles/vm.make >>> isn't the "right" way to get a top-level variable down into the >>> HotSpot build system. I cannot remember what breaks when you do that, >>> but it doesn't work right in all the ways that we build HotSpot. >>> >>> For the HotSpot build system, you'll want to: >>> >>> - update make/solaris/Makefile and add HS_ALT_MAKE to >>> the BUILDTREE_VARS list: >>> >>> BUILDTREE_VARS += HS_ALT_MAKE=$(HS_ALT_MAKE) >>> >>> - update make/solaris/makefiles/buildtree.make and add >>> HS_ALT_MAKE to the rule that creates flags.make: >>> >>> [ -n "$(HS_ALT_MAKE)" ] && \ >>> echo && echo "HS_ALT_MAKE = $(HS_ALT_MAKE)"; \ >>> >>> The way I usually find all the right spots is I look for >>> where ZIPEXE is added to the above files and follow those >>> examples. >>> >>> Dan >>> >>> >>> >>> >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8055744#comment-13542110 >>>> >>>> This is a P1 so if you feel comfortable with the hotspot makefiles, >>>> please >>>> have a look. >>>> >>>> Thanks! >>>> /Jesper >>> From david.holmes at oracle.com Tue Aug 26 12:09:18 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Aug 2014 22:09:18 +1000 Subject: RFR: JDK-8056053: Disable HOTSPOT_BUILD_JOBS when building with configure In-Reply-To: <53FC672E.4020907@oracle.com> References: <53FC672E.4020907@oracle.com> Message-ID: <53FC78EE.9050506@oracle.com> Hi Erik, On 26/08/2014 8:53 PM, Erik Joelsson wrote: > Hello, > > Please review this proposed fix for the Hotspot build. > > In the new jdk9 build, we utilize the gnu make job server, which > automatically makes sure the -j flag gets propagated and shared between > all recursive make calls. In the hotspot build, this gets overridden by > the HOTSPOT_BUILD_JOBS variable. Configure estimates a reasonable number > of parallel make jobs into the JOBS variable, which gets propagated to > the HOTSPOT_BUILD_JOBS variable. This used to work well enough, but in > the new build, the hotspot build is happening concurrently with other > parts of the build and the consequence is that the hotspot build gets > JOBS number of jobs and the rest of the build also gets JOBS number of > jobs, all of which are used at the same time. We would like the whole > build to share in the same job pool. > > To fix this, the setting of -j$(HOTSPOT_BUILD_JOBS) needs to be made > conditional and we need to add .NOTPARALLEL: to a number of makefiles in > hotspot that currently can't handle being executed in parallel. Lastly, > the + sign must be added first to recipe lines that call make > recursively but are not explicitly using the MAKE variable directly. The > result will be that the active -j flag in the root makefiles will just > automatically propagate down to the hotspot makefiles. I don't know how make handles -j propagation but from your description it sounds like we will still generate too much concurrency as the submakes will be run with the same -j value as the top-level. ?? I'm also unclear how we used to pass HOTSPOT_BUILD_JOBS and didn't need .NOTPARALLEL, but now we pass -j from the top we do need .NOTPARALLEL ?? Thanks, David > Bug: https://bugs.openjdk.java.net/browse/JDK-8056053 > Webrev: http://cr.openjdk.java.net/~erikj/8056053/webrev.01/ > > /Erik From erik.joelsson at oracle.com Tue Aug 26 12:38:31 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 26 Aug 2014 14:38:31 +0200 Subject: RFR: JDK-8056053: Disable HOTSPOT_BUILD_JOBS when building with configure In-Reply-To: <53FC78EE.9050506@oracle.com> References: <53FC672E.4020907@oracle.com> <53FC78EE.9050506@oracle.com> Message-ID: <53FC7FC7.2090201@oracle.com> Hello David, I realize my description was not very clear and will try to make a better one. It used to be (before make 3.78), that recursive make calls and the -j flag were tricky to use together. The Hotspot makefiles solved this by asking people not to use -j, and instead set the variable HOTSPOT_BUILD_JOBS. The calls to the leaf make invocations would then set -j$(HOTSPOT_BUILD_JOBS) so that the bulk of the work would be run in parallel, but one makefile at a time. Modern versions of gnu make has a solution to this problem called the Job Server. (Read more about it here: http://mad-scientist.net/make/jobserver.html) In short it enables multiple make processes to share a single pool of job tokens through a pipe, making sure that concurrency is kept within the limitations set by -j to the root process. Note that make never sends the -j flag on to sub invocations, but instead does a secret transfer of the Job Server pipe. In the "new" jdk9 build, I introduced using the Job Server across the whole build. Unfortunately, this didn't work well for Hotspot because as soon as one sub make gets an explicit -j flag, or is invoked from a recipe line without either a + sign or explicit use of the $(MAKE) variable, that subtree is outside the job server sharing pool and will govern its own concurrency. The result of this is that while the rest of the build is sharing JOBS number of parallel jobs, vm.make will execute HOTSPOT_BUILD_NUMBER number of parallel jobs on its own. The reason .NOTPARALLEL wasn't need before is that until this patch, HotspotWrapper.gmk and the user building Hotspot alone has always run make with -j1. In this patch, I removed that -j1 from HotspotWrapper.gmk so that the Job Server would get propagated into the Hotspot build. To protect the makefiles that aren't able to run in parallel, I had to add .NOTPARALLEL: in a couple of places. /Erik On 2014-08-26 14:09, David Holmes wrote: > Hi Erik, > > On 26/08/2014 8:53 PM, Erik Joelsson wrote: >> Hello, >> >> Please review this proposed fix for the Hotspot build. >> >> In the new jdk9 build, we utilize the gnu make job server, which >> automatically makes sure the -j flag gets propagated and shared between >> all recursive make calls. In the hotspot build, this gets overridden by >> the HOTSPOT_BUILD_JOBS variable. Configure estimates a reasonable number >> of parallel make jobs into the JOBS variable, which gets propagated to >> the HOTSPOT_BUILD_JOBS variable. This used to work well enough, but in >> the new build, the hotspot build is happening concurrently with other >> parts of the build and the consequence is that the hotspot build gets >> JOBS number of jobs and the rest of the build also gets JOBS number of >> jobs, all of which are used at the same time. We would like the whole >> build to share in the same job pool. >> >> To fix this, the setting of -j$(HOTSPOT_BUILD_JOBS) needs to be made >> conditional and we need to add .NOTPARALLEL: to a number of makefiles in >> hotspot that currently can't handle being executed in parallel. Lastly, >> the + sign must be added first to recipe lines that call make >> recursively but are not explicitly using the MAKE variable directly. The >> result will be that the active -j flag in the root makefiles will just >> automatically propagate down to the hotspot makefiles. > > I don't know how make handles -j propagation but from your description > it sounds like we will still generate too much concurrency as the > submakes will be run with the same -j value as the top-level. ?? > > I'm also unclear how we used to pass HOTSPOT_BUILD_JOBS and didn't > need .NOTPARALLEL, but now we pass -j from the top we do need > .NOTPARALLEL ?? > > Thanks, > David > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8056053 >> Webrev: http://cr.openjdk.java.net/~erikj/8056053/webrev.01/ >> >> /Erik From coleen.phillimore at oracle.com Tue Aug 26 13:56:12 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 26 Aug 2014 09:56:12 -0400 Subject: RFR 8049105: Move array component mirror to instance of java/lang/Class (hotspot part 2) Message-ID: <53FC91FC.1070700@oracle.com> Summary: This removes component mirrors from arrayKlass metadata and the C2 intrinsic for them. I'm sending this out to hotspot-dev so I can get someone from the compiler to review this (again). Chris Thalinger, you already saw this once, it's the same thing, but I had to hold this change until it was okay'd by licensees. Can you re-review? Also GC team note that Klass::oops_do() is now non-virtual. Will that help? Tested with jck, nsk and jtreg tests. Also, ran refworkload with no difference in performance. open webrev at http://cr.openjdk.java.net/~coleenp/8049105/ bug link https://bugs.openjdk.java.net/browse/JDK-8049105 Thanks, Coleen From mikael.gerdin at oracle.com Tue Aug 26 15:26:29 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 26 Aug 2014 17:26:29 +0200 Subject: RFR 8056084: Refactor Hashtable to allow implementations without rehashing support Message-ID: <2174664.Dc28FTrABg@mgerdin03> Hi all, For JDK-8048268 I need to do some refactoring of the Hashtable class template. >From the bug description: In order to simplify usage of the Hashtable class the code to perform rehashing of the SymbolTable and StringTable should be factored out to an intermediate class common to those two tables. Also factor out HashtableEntry freelist allocation to allow implementors an easier route for providing their own memory management. Introducing the new intermediary superclass requires some calls to superclass functions to be qualified using the "this->" syntax due to the C++ template name lookup rules. a comment about hashtable.cpp RehashableHashtable::dump_table: - int bucket_bytes = (int)num_buckets * sizeof(bucket(0)); + int bucket_bytes = (int)num_buckets * sizeof(HashtableBucket); I decided to change the sizeof to count the size of the hashtable bucket class instead of the HashtableEntry* returned by bucket(0), even though they may be of the same size currently. Note that the webrev url refers to another bug. Webrev: http://cr.openjdk.java.net/~mgerdin/8048268/hashtable-refactor/webrev/ Buglink: https://bugs.openjdk.java.net/browse/JDK-8056084 Testing: JPRT. From daniel.daugherty at oracle.com Tue Aug 26 16:13:10 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 26 Aug 2014 10:13:10 -0600 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F752F9.9090908@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> <53F52521.1080309@oracle.com> <53F54AC0.7010007@oracle.com> <53F752F9.9090908@oracle.com> Message-ID: <53FCB216.7010004@oracle.com> On 8/22/14 8:26 AM, Coleen Phillimore wrote: > > Thanks Dan, Serguei and Roland for discussion on this change. The > latest version is here: > > open webrev at http://cr.openjdk.java.net/~coleenp/8055008_2/ src/share/vm/oops/instanceKlass.hpp No comments. src/share/vm/oops/instanceKlass.cpp line 3616: // we add breakpoints for it. "we add breakpoints" -> "we can add breakpoints" line 3618: // At least one emcp method is still running Do we still need this comment line? Or move it between these lines: line 3611: } else { // At least one EMCP method is still running line 3612: for (int i = 0; i < old_methods->length(); i++) { src/share/vm/oops/method.hpp No comments. src/share/vm/prims/jvmtiRedefineClasses.hpp line 407: // counts the number of methods are EMCP (Equivalent Module Constant Pool). Typo: 'methods are EMCP' -> 'methods that are EMCP' src/share/vm/prims/jvmtiRedefineClasses.cpp line 3381: // track number of methods are EMCP for add_previous_version() call below Typo: 'methods are EMCP' -> 'methods that are EMCP' src/share/vm/prims/jvmtiImpl.cpp line 304: meth_act == &Method::set_breakpoint ? "set" : "clear", Typo: "set" should be "sett" so that the output is "setting" instead of "seting". src/share/vm/code/nmethod.cpp No comments. src/share/vm/memory/universe.cpp No comments. test/runtime/RedefineTests/RedefineFinalizer.java No comments. test/runtime/RedefineTests/RedefineRunningMethods.java line 61: " Thread.currentThread().sleep(1);" + Should the '1' be '10'? line 74: public static boolean stop = false; This should also be volatile. line 77: Thread.currentThread().sleep(10);//sleep for 10 ms So the original has a comment, but 'newB' and 'evenNewerB' don't have a comment. Are you testing to see the effect of a comment change on the EMCP'ness of the resulting redefine? line 109: B.infinite(); So the idea with this call, is that if the redefine to "newB" doesn't work right, the test will hang in this call. Do I have this right? Dan > > Changes from the last version (don't have the setup to do a diff > webrev, sorry) are that I have a new flag to mark running emcp methods > so we can set breakpoints in only those. Also, confirmed that we need > to clean_weak_method_links in obsolete methods too. Made changes per > review comments. Also, added more to the test so that all tracing in > InstanceKlass comes out. Reran all tests (nsk, jck, jtreg, > java/lang/instrument). > > Thanks to whoever made command line processing handle hex numbers! > > Thanks, > Coleen > > On 8/20/14, 9:26 PM, Coleen Phillimore wrote: >> >> On 8/20/14, 6:45 PM, Daniel D. Daugherty wrote: >>> On 8/20/14 2:01 PM, Coleen Phillimore wrote: >>>> On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>>>> >>>>>> If an EMCP method is not running, should we save it on a previous >>>>>> version list anyway so that we can make it obsolete if it's >>>>>> redefined and made obsolete? >>>>> >>>>> I hope, Dan will catch me if I'm wrong... >>>>> >>>>> I think, we should not. >>>>> An EMCP method can not be made obsolete if it is not running. >>>>> >>>> >>>> >>>> It should be this way otherwise we'd have to hang onto things forever. >>> >>> An EMCP method should only be made obsolete if a RedefineClasses() or >>> RetransformClasses() operation made it so. We should not be leveraging >>> off the obsolete-ness attribute to solve a life-cycle problem. >> >> Yes, this was my error in the change. This is why I made things >> obsolete if they were not running. I think I can't reuse this flag. >> My latest changes add a new explicit flag (which we have space for in >> Method*). >>> >>> In the pre-PGR world, we could trust GC to make a completely unused >>> EMCP method collectible and eventually our weak reference would go >>> away. Just because an EMCP method is not on a stack does not mean >>> that it is not used so we need a different way to determine whether >>> it is OK to no longer track an EMCP method. >> >> Our on_stack marking is supposed to look at all the places where GC >> used to look so I think we can use on_stack to track the lifecycle of >> EMCP methods. If the EMCP method is somewhere, we will find it! >> >> I'm running tests on the latest change, but am also waiting for >> confirmation from Roland because we were only cleaning out MethodData >> for EMCP methods and not for running obsolete methods and I think we >> need to do that for obsolete methods also, which my change does now. >> I think it was a bug. >> >> Thanks Dan for remembering all of this for me! >> >> Coleen >>> >>> >>>> >>>>> BTW, I'm reviewing the webrev too, but probably it'd be better to >>>>> switch to updated webrev after it is ready. >>>> >>>> Yes, this is a good idea. I figured out why I made emcp methods >>>> obsolete, and I'm fixing that as well as Dan's comments. Thanks! >>> >>> Cool! I'm looking forward to the next review. >>> >>> Dan >>> >>> >>>> >>>> Coleen >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>> >>> >> > From coleen.phillimore at oracle.com Tue Aug 26 20:33:34 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 26 Aug 2014 16:33:34 -0400 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53FCB216.7010004@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> <53F52521.1080309@oracle.com> <53F54AC0.7010007@oracle.com> <53F752F9.9090908@oracle.com> <53FCB216.7010004@oracle.com> Message-ID: <53FCEF1E.40006@oracle.com> Thank you for another in-depth look at this code. On 8/26/14, 12:13 PM, Daniel D. Daugherty wrote: > On 8/22/14 8:26 AM, Coleen Phillimore wrote: >> >> Thanks Dan, Serguei and Roland for discussion on this change. The >> latest version is here: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8055008_2/ > > src/share/vm/oops/instanceKlass.hpp > No comments. > > src/share/vm/oops/instanceKlass.cpp > line 3616: // we add breakpoints for it. > "we add breakpoints" -> "we can add breakpoints" Yes, that's better. > > line 3618: // At least one emcp method is still running > Do we still need this comment line? Or move it between these > lines: > > line 3611: } else { > // At least one EMCP method is still running > line 3612: for (int i = 0; i < old_methods->length(); > i++) { I moved it up but adjusted the comment because we're trying to find any emcp running methods. // At least one method is still running, check for EMCP methods > > src/share/vm/oops/method.hpp > No comments. > > src/share/vm/prims/jvmtiRedefineClasses.hpp > line 407: // counts the number of methods are EMCP (Equivalent > Module Constant Pool). > Typo: 'methods are EMCP' -> 'methods that are EMCP' > > src/share/vm/prims/jvmtiRedefineClasses.cpp > line 3381: // track number of methods are EMCP for > add_previous_version() call below > Typo: 'methods are EMCP' -> 'methods that are EMCP' yes. added two "that"s. > > src/share/vm/prims/jvmtiImpl.cpp > line 304: meth_act == &Method::set_breakpoint ? "set" : > "clear", > Typo: "set" should be "sett" so that the output is "setting" > instead of "seting". > OH. I thought sett was a typo! Now I get it. LOL. > src/share/vm/code/nmethod.cpp > No comments. > > src/share/vm/memory/universe.cpp > No comments. > > test/runtime/RedefineTests/RedefineFinalizer.java > No comments. > > test/runtime/RedefineTests/RedefineRunningMethods.java > line 61: " Thread.currentThread().sleep(1);" + > Should the '1' be '10'? I made this 1 so it'd be EMCP but still not sleep a lot. I could have gone with 5. > > line 74: public static boolean stop = false; > This should also be volatile. Okay, I changed them all. I think we can't change qualifiers on static variables (although I'm going to write another test to see what happens). > > line 77: Thread.currentThread().sleep(10);//sleep for > 10 ms > So the original has a comment, but 'newB' and 'evenNewerB' don't > have a comment. Are you testing to see the effect of a comment > change on the EMCP'ness of the resulting redefine? No, the way this harness is written a comment in newB and evenNewerB will mess up the new class. I don't expect comments to have any effect whatsoever for EMCPness. > > line 109: B.infinite(); > So the idea with this call, is that if the redefine to "newB" > doesn't work right, the test will hang in this call. Do I have > this right? That is true. The output I want to see is the print for "infinite". Most of this test was for visual verification that the tracing came out right but I thought it should be added because it hits all the code and the test exists in the repository. Thanks for the code review again! Coleen > > Dan > > > >> >> Changes from the last version (don't have the setup to do a diff >> webrev, sorry) are that I have a new flag to mark running emcp >> methods so we can set breakpoints in only those. Also, confirmed >> that we need to clean_weak_method_links in obsolete methods too. Made >> changes per review comments. Also, added more to the test so that >> all tracing in InstanceKlass comes out. Reran all tests (nsk, jck, >> jtreg, java/lang/instrument). >> >> Thanks to whoever made command line processing handle hex numbers! >> >> Thanks, >> Coleen >> >> On 8/20/14, 9:26 PM, Coleen Phillimore wrote: >>> >>> On 8/20/14, 6:45 PM, Daniel D. Daugherty wrote: >>>> On 8/20/14 2:01 PM, Coleen Phillimore wrote: >>>>> On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> >>>>>>> If an EMCP method is not running, should we save it on a >>>>>>> previous version list anyway so that we can make it obsolete if >>>>>>> it's redefined and made obsolete? >>>>>> >>>>>> I hope, Dan will catch me if I'm wrong... >>>>>> >>>>>> I think, we should not. >>>>>> An EMCP method can not be made obsolete if it is not running. >>>>>> >>>>> >>>>> >>>>> It should be this way otherwise we'd have to hang onto things >>>>> forever. >>>> >>>> An EMCP method should only be made obsolete if a RedefineClasses() or >>>> RetransformClasses() operation made it so. We should not be leveraging >>>> off the obsolete-ness attribute to solve a life-cycle problem. >>> >>> Yes, this was my error in the change. This is why I made things >>> obsolete if they were not running. I think I can't reuse this >>> flag. My latest changes add a new explicit flag (which we have >>> space for in Method*). >>>> >>>> In the pre-PGR world, we could trust GC to make a completely unused >>>> EMCP method collectible and eventually our weak reference would go >>>> away. Just because an EMCP method is not on a stack does not mean >>>> that it is not used so we need a different way to determine whether >>>> it is OK to no longer track an EMCP method. >>> >>> Our on_stack marking is supposed to look at all the places where GC >>> used to look so I think we can use on_stack to track the lifecycle >>> of EMCP methods. If the EMCP method is somewhere, we will find it! >>> >>> I'm running tests on the latest change, but am also waiting for >>> confirmation from Roland because we were only cleaning out >>> MethodData for EMCP methods and not for running obsolete methods and >>> I think we need to do that for obsolete methods also, which my >>> change does now. I think it was a bug. >>> >>> Thanks Dan for remembering all of this for me! >>> >>> Coleen >>>> >>>> >>>>> >>>>>> BTW, I'm reviewing the webrev too, but probably it'd be better to >>>>>> switch to updated webrev after it is ready. >>>>> >>>>> Yes, this is a good idea. I figured out why I made emcp methods >>>>> obsolete, and I'm fixing that as well as Dan's comments. Thanks! >>>> >>>> Cool! I'm looking forward to the next review. >>>> >>>> Dan >>>> >>>> >>>>> >>>>> Coleen >>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>> >>>> >>> >> > From david.holmes at oracle.com Wed Aug 27 06:00:59 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Aug 2014 16:00:59 +1000 Subject: RFR: JDK-8056053: Disable HOTSPOT_BUILD_JOBS when building with configure In-Reply-To: <53FC7FC7.2090201@oracle.com> References: <53FC672E.4020907@oracle.com> <53FC78EE.9050506@oracle.com> <53FC7FC7.2090201@oracle.com> Message-ID: <53FD741B.9000903@oracle.com> On 26/08/2014 10:38 PM, Erik Joelsson wrote: > Hello David, > > I realize my description was not very clear and will try to make a > better one. Thanks for the detailed explanation. Changes seem good. David > It used to be (before make 3.78), that recursive make calls and the -j > flag were tricky to use together. The Hotspot makefiles solved this by > asking people not to use -j, and instead set the variable > HOTSPOT_BUILD_JOBS. The calls to the leaf make invocations would then > set -j$(HOTSPOT_BUILD_JOBS) so that the bulk of the work would be run in > parallel, but one makefile at a time. > > Modern versions of gnu make has a solution to this problem called the > Job Server. (Read more about it here: > http://mad-scientist.net/make/jobserver.html) In short it enables > multiple make processes to share a single pool of job tokens through a > pipe, making sure that concurrency is kept within the limitations set by > -j to the root process. Note that make never sends the -j flag on to sub > invocations, but instead does a secret transfer of the Job Server pipe. > > In the "new" jdk9 build, I introduced using the Job Server across the > whole build. Unfortunately, this didn't work well for Hotspot because as > soon as one sub make gets an explicit -j flag, or is invoked from a > recipe line without either a + sign or explicit use of the $(MAKE) > variable, that subtree is outside the job server sharing pool and will > govern its own concurrency. The result of this is that while the rest of > the build is sharing JOBS number of parallel jobs, vm.make will execute > HOTSPOT_BUILD_NUMBER number of parallel jobs on its own. > > The reason .NOTPARALLEL wasn't need before is that until this patch, > HotspotWrapper.gmk and the user building Hotspot alone has always run > make with -j1. In this patch, I removed that -j1 from HotspotWrapper.gmk > so that the Job Server would get propagated into the Hotspot build. To > protect the makefiles that aren't able to run in parallel, I had to add > .NOTPARALLEL: in a couple of places. > > /Erik > > On 2014-08-26 14:09, David Holmes wrote: >> Hi Erik, >> >> On 26/08/2014 8:53 PM, Erik Joelsson wrote: >>> Hello, >>> >>> Please review this proposed fix for the Hotspot build. >>> >>> In the new jdk9 build, we utilize the gnu make job server, which >>> automatically makes sure the -j flag gets propagated and shared between >>> all recursive make calls. In the hotspot build, this gets overridden by >>> the HOTSPOT_BUILD_JOBS variable. Configure estimates a reasonable number >>> of parallel make jobs into the JOBS variable, which gets propagated to >>> the HOTSPOT_BUILD_JOBS variable. This used to work well enough, but in >>> the new build, the hotspot build is happening concurrently with other >>> parts of the build and the consequence is that the hotspot build gets >>> JOBS number of jobs and the rest of the build also gets JOBS number of >>> jobs, all of which are used at the same time. We would like the whole >>> build to share in the same job pool. >>> >>> To fix this, the setting of -j$(HOTSPOT_BUILD_JOBS) needs to be made >>> conditional and we need to add .NOTPARALLEL: to a number of makefiles in >>> hotspot that currently can't handle being executed in parallel. Lastly, >>> the + sign must be added first to recipe lines that call make >>> recursively but are not explicitly using the MAKE variable directly. The >>> result will be that the active -j flag in the root makefiles will just >>> automatically propagate down to the hotspot makefiles. >> >> I don't know how make handles -j propagation but from your description >> it sounds like we will still generate too much concurrency as the >> submakes will be run with the same -j value as the top-level. ?? >> >> I'm also unclear how we used to pass HOTSPOT_BUILD_JOBS and didn't >> need .NOTPARALLEL, but now we pass -j from the top we do need >> .NOTPARALLEL ?? >> >> Thanks, >> David >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8056053 >>> Webrev: http://cr.openjdk.java.net/~erikj/8056053/webrev.01/ >>> >>> /Erik > From paul.sandoz at oracle.com Wed Aug 27 09:31:31 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 27 Aug 2014 11:31:31 +0200 Subject: Question about Unsafe.prefetch ... () ? In-Reply-To: <1408028879.5132.8.camel@localhost> References: <1408026725.5132.5.camel@localhost> <164FBD61-384B-4EEB-B03E-ABFB7BF5E1FD@oracle.com> <1408028879.5132.8.camel@localhost> Message-ID: <914AF7CD-2B81-4DC9-86F6-DFB1AEEB7FA4@oracle.com> On Aug 14, 2014, at 5:07 PM, Roman Kennke wrote: > I just found that (some of it?) has been taken out in JDK9: > > http://cr.openjdk.java.net/~psandoz/jdk9/hotspot-unsafe-cleanup/webrev/src/share/vm/prims/unsafe.cpp.udiff.html > That patch has not been pushed yet. I do plan at some point to submit an updated patch for review. Preferably when it becomes easier to push combined JDK and hotspot changes :-) which i believe is the where we will be eventually be heading? Paul. From magnus.ihse.bursie at oracle.com Wed Aug 27 10:40:42 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 27 Aug 2014 12:40:42 +0200 Subject: RFR: JDK-8056053: Disable HOTSPOT_BUILD_JOBS when building with configure In-Reply-To: <53FC672E.4020907@oracle.com> References: <53FC672E.4020907@oracle.com> Message-ID: <53FDB5AA.2010908@oracle.com> On 2014-08-26 12:53, Erik Joelsson wrote: > Hello, > > Please review this proposed fix for the Hotspot build. > > In the new jdk9 build, we utilize the gnu make job server, which > automatically makes sure the -j flag gets propagated and shared > between all recursive make calls. In the hotspot build, this gets > overridden by the HOTSPOT_BUILD_JOBS variable. Configure estimates a > reasonable number of parallel make jobs into the JOBS variable, which > gets propagated to the HOTSPOT_BUILD_JOBS variable. This used to work > well enough, but in the new build, the hotspot build is happening > concurrently with other parts of the build and the consequence is that > the hotspot build gets JOBS number of jobs and the rest of the build > also gets JOBS number of jobs, all of which are used at the same time. > We would like the whole build to share in the same job pool. > > To fix this, the setting of -j$(HOTSPOT_BUILD_JOBS) needs to be made > conditional and we need to add .NOTPARALLEL: to a number of makefiles > in hotspot that currently can't handle being executed in parallel. > Lastly, the + sign must be added first to recipe lines that call make > recursively but are not explicitly using the MAKE variable directly. > The result will be that the active -j flag in the root makefiles will > just automatically propagate down to the hotspot makefiles. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8056053 > Webrev: http://cr.openjdk.java.net/~erikj/8056053/webrev.01/ > > /Erik Looks good to me. /Magnus From serguei.spitsyn at oracle.com Wed Aug 27 11:29:36 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Aug 2014 04:29:36 -0700 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F5233E.2070508@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F5233E.2070508@oracle.com> Message-ID: <53FDC120.5060203@oracle.com> Dan, Sorry for the big delay in reply... It is because I did not have my arguments ready. :( Please, see below. On 8/20/14 3:37 PM, Daniel D. Daugherty wrote: > On 8/20/14 9:54 AM, Coleen Phillimore wrote: >> >> Hi, it appears that my code is wrong and maybe the existing code is >> wrong also. I have a spec question below. > > Rely embedded below... > > >> >> On 8/19/14, 7:52 PM, serguei.spitsyn at oracle.com wrote: >>> On 8/19/14 3:53 PM, Daniel D. Daugherty wrote: >>>> >>>> On 8/19/14 3:39 PM, Daniel D. Daugherty wrote: >>>>> On 8/15/14 2:18 PM, Coleen Phillimore wrote: >>>>>> Summary: Use scratch_class to find EMCP methods for breakpoints >>>>>> if the old methods are still running >>>>>> >>>>>> See bug for more details. This fix also includes a change to >>>>>> nmethod::metadata_do() to not walk the _method multiple times >>>>>> (the _method is added to the metadata section of the nmethod), >>>>>> and an attempt to help the sweeper clean up these scratch_class >>>>>> instance classes sooner. >>>>>> >>>>>> Tested with nsk tests, java/lang/instrument tests and jck tests >>>>>> (which include some jvmti tests). >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8055008/ >>>>> >>>>> src/share/vm/oops/instanceKlass.hpp >>>>> line 1047 // RedefineClass support >>>>> Should be 'RedefineClasses'. >>>>> >>>>> line 1049: void mark_newly_obsolete_methods(Array* >>>>> old_methods, >>>>> int emcp_method_count); >>>>> The 'obsolete' part of the function name does not match with >>>>> the 'emcp' part of the parameter name. EMCP methods are >>>>> 'old', >>>>> but not 'obsolete'. >>>>> >>>>> Update: OK, I think I get it. We want to mark methods that >>>>> are >>>>> newly transitioning from EMCP -> obsolete and the >>>>> emcp_method_count >>>>> parameter tells us if there is any work to do. >>>>> >>>>> src/share/vm/oops/instanceKlass.cpp >>>>> line 3023: } // pvw is cleaned up >>>>> 'pvw' no longer exists so comment is stale. >>>>> >>>>> line 3455: // check the previous versions array >>>>> This comment should move above this line: >>>>> >>>>> 3453 for (; pv_node != NULL; ) { >>>>> >>>>> and 'array' should change to 'list'. >>>>> >>>>> Sorry for the bad placement of the original comment. >>>>> >>>>> line 3463: last->link_previous_versions(pv_node); >>>>> So now we've overwritten the previous value of >>>>> last->previous_versions. How does that InstanceKlass >>>>> get freed? Maybe a short comment? >>>>> >>>>> line 3484: // Mark the emcp method as obsolete if it's not >>>>> executing >>>>> I'm not sure about whether this is a good idea. When we had a >>>>> redefine make a method obsolete before, we knew that we could >>>>> make all older but previously EMCP methods obsolete because >>>>> the new method version did make them obsolete. >>>>> >>>>> With this optimization, we're saying that no thread is >>>>> executing >>>>> the method so we're going to make it obsolete even if the >>>>> current >>>>> redefine did not do so. I worry about a method call that >>>>> is in >>>>> the early stages of assembling the call stack being caught >>>>> calling a method that is now obsolete but not because of a >>>>> redefine made it obsolete. Just FYI, one of the tracing flags >>>>> catches unexpected calls to obsolete methods today and it >>>>> does >>>>> catch the current system's legitimate race. >>>> >>>> JVM/TI has an isMethodObsolete() API: >>>> >>>> jvmtiError >>>> IsMethodObsolete(jvmtiEnv* env, >>>> jmethodID method, >>>> jboolean* is_obsolete_ptr) >>>> >>>> It would be possible for an agent to observe a method changing from >>>> not obsolete to obsolete when that's not expected. I suspect that >>>> this would be a spec violation. >>> >>> I agree that this looks like a spec violation. >>> The emcp methods by definition are non-obsolete, >>> or in opposite, the obsolete methods are non-emcp: >>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#obsoleteMethods >>> >>> Old method versions may become obsolete, not emcp: >>> http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#RedefineClasses >>> >>> But maybe I'm missing something... >> >> If an EMCP method is not running, should we save it on a previous >> version list anyway so that we can make it obsolete if it's redefined >> and made obsolete? > > Interesting question. The problem with an EMCP method is that it might > not be running right now, but we could have a Java thread that's in > the process of invoking it that is stopped on a safepoint. We resume > the world and the Java thread finishes calling the EMCP method... > > It's really hard to catch in-progress uses of jmethodIDs and make > sure that the in-progress use switches from the EMCP method to the > latest version of the method. A rarely seen race, but it does happen... It has to be invariant that if an EMCP is not running at redefinition time then it has to be gone and can not become running in the future. Otherwise, everything becomes overcomplicated. This also means that non-running EMCP method can never be made obsolete. The JVMTI spec is clear about the jmethodIDs and obsolete methods: Obsolete Methods The functions |RetransformClasses| and |RedefineClasses| can cause new versions of methods to be installed. An original version of a method is considered equivalent to the new version if: * their bytecodes are the same except for indices into the constant pool and * the referenced constants are equal. An original method version which is not equivalent to the new method version is called obsolete and is assigned a new method ID; the original method ID now refers to the new method version. A method ID can be tested for obsolescence with |IsMethodObsolete| . From the above, it seems that the EMCP methods do not get new jmethodIDs. It means that any use of jmethodID that referred to the EMCP method before the redefinition after redefinition should refer to the new (non-EMCP) method version. We must treat it as a bug if this invariant is broken. However, if an EMCP method is already running (there is a frame on the stack) then it can not be replaced with the new method version. Next redefinition can make such EMCP method to become obsolete, and so, it should get new methodID if it is still running. > > >> Currently we don't save previous versions of methods that are not >> running. We didn't before permgen elimination either. If GC didn't >> find the EMCP method, we would remove the entry. > > Not quite true for the pre-PermGen-Removal (PGR) world. We used to > save weak refs for all of the EMCP methods in the previous version > info. As the EMCP methods became collectible we removed them from > the previous version info. This means if GC could find the EMCP > method anywhere (stack, jmethodID, JNI handle, etc), then it stayed > alive. This means that even if no thread was currently executing > an EMCP method, an in-progress call to that method could still > complete and poof now we have the EMCP method back on a stack > somewhere... Do we have any test that demonstrate this behavior? Should we treat this behavior as a bug? If we decide to treat it as a bug then is it possible to fix such issues? Thanks, Serguei > > Dan > > >> >> Thanks, >> Coleen >> >>> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Dan >>>> >>>> >>>>> >>>>> line 3527: // clear out any matching EMCP method entries the >>>>> hard way. >>>>> Perhaps "mark" instead of "clear out"? >>>>> >>>>> old line 3659: if (!method->is_obsolete() && >>>>> new line 3546: if (method->is_emcp() && >>>>> The old code is correct. The old code won't remark a >>>>> method that >>>>> was already made obsolete so there won't be more than one >>>>> trace >>>>> message for that operation. >>>>> >>>>> line 3581: // stack, and set emcp methods on the stack. >>>>> In comments 'emcp' should be 'EMCP'. We did not do that in >>>>> the >>>>> code because of HotSpot's variable name style. >>>>> >>>>> Also, set what on EMCP methods on the stack? >>>>> >>>>> line 3591: ... If emcp method from >>>>> line 3592: // a previous redefinition may be made obsolete by >>>>> this redefinition. >>>>> Having trouble parsing this comment. >>>>> >>>>> src/share/vm/oops/method.hpp >>>>> line 693: // emcp methods (equivalent method except constant >>>>> pool is different) >>>>> line 694: // that are old but not obsolete or deleted. >>>>> Perhaps: >>>>> >>>>> // EMCP methods are old but not obsolete or deleted. >>>>> Equivalent >>>>> // Modulo Constant Pool means the method is equivalent except >>>>> // the constant pool and instructions that access the >>>>> constant >>>>> // pool might be different. >>>>> >>>>> src/share/vm/prims/jvmtiImpl.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/code/nmethod.cpp >>>>> So in the original code f(_method) was being called two extra >>>>> times? (once in the while-loop and once at the end) So I'm >>>>> guessing that f(_method) is properly called when the rest of >>>>> the metadata is handled in the nmethod (line 2085)? >>>>> >>>>> src/share/vm/memory/universe.cpp >>>>> No comments (resisting 'The Walking Dead' ref...) >>>>> >>>>> test/runtime/RedefineTests/RedefineFinalizer.java >>>>> No comments. >>>>> >>>>> test/runtime/RedefineTests/RedefineRunningMethods.java >>>>> line 44: " while (!stop) { count2++; }" + >>>>> line 53: while (!stop) { count1++; } >>>>> line 56: while (!stop) { count2++; } >>>>> >>>>> These may not behave well on OSes with bad threading >>>>> models. You might want to add a helper function that >>>>> sleeps for 10ms and have each of these loops call it >>>>> so the test more well behaved. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8055008 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>> >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Wed Aug 27 11:40:44 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Aug 2014 04:40:44 -0700 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F52521.1080309@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> <53F52521.1080309@oracle.com> Message-ID: <53FDC3BC.3030605@oracle.com> On 8/20/14 3:45 PM, Daniel D. Daugherty wrote: > On 8/20/14 2:01 PM, Coleen Phillimore wrote: >> On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>> >>>> If an EMCP method is not running, should we save it on a previous >>>> version list anyway so that we can make it obsolete if it's >>>> redefined and made obsolete? >>> >>> I hope, Dan will catch me if I'm wrong... >>> >>> I think, we should not. >>> An EMCP method can not be made obsolete if it is not running. >>> >> >> >> It should be this way otherwise we'd have to hang onto things forever. > > An EMCP method should only be made obsolete if a RedefineClasses() or > RetransformClasses() operation made it so. We should not be leveraging > off the obsolete-ness attribute to solve a life-cycle problem. > > In the pre-PGR world, we could trust GC to make a completely unused > EMCP method collectible and eventually our weak reference would go > away. Just because an EMCP method is not on a stack does not mean > that it is not used so we need a different way to determine whether > it is OK to no longer track an EMCP method. Most likely, you are right. But I'm not convinced yet. Sorry. A convincing point would be a test that shows this behavior. I understand that it is not an easy task to write such a test though. However, such a test would serve nicely if we want a different way to determine whether it is OK to no longer track an EMCP method. Thanks, Serguei > > >> >>> BTW, I'm reviewing the webrev too, but probably it'd be better to >>> switch to updated webrev after it is ready. >> >> Yes, this is a good idea. I figured out why I made emcp methods >> obsolete, and I'm fixing that as well as Dan's comments. Thanks! > > Cool! I'm looking forward to the next review. > > Dan > > >> >> Coleen >> >>> >>> Thanks, >>> Serguei >> > From serguei.spitsyn at oracle.com Wed Aug 27 12:20:21 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Aug 2014 05:20:21 -0700 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53F752F9.9090908@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> <53F52521.1080309@oracle.com> <53F54AC0.7010007@oracle.com> <53F752F9.9090908@oracle.com> Message-ID: <53FDCD05.1080307@oracle.com> Hi Coleen, src/share/vm/code/nmethod.cpp Nice simplification. src/share/vm/memory/universe.cpp No comments src/share/vm/oops/instanceKlass.cpp A minor question about two related fragments: 3505 // next previous version 3506 last = pv_node; 3507 pv_node = pv_node->previous_versions(); 3508 version++; Should the version be incremented to the case 3462-3469 as at the line 3508? It is not a big issue as the version number is used at the RC_TRACE line only: 3496 method->signature()->as_C_string(), j, version)); We still have no consensus on the following question: Can a non-running EMCP method become running again after the flag was cleared? 3487 if (!method->on_stack()) { 3488 if (method->is_running_emcp()) { 3489 method->set_running_emcp(false); // no breakpoints for non-running methods 3490 } Just wanted to be sure what is the current view on this. :) src/share/vm/oops/instanceKlass.hpp No comments src/share/vm/oops/method.hpp Just some questions. Usefulness of this new function depends on basic ability of a non-running method to become running again: is_running_emcp() The questions are: - How precise is the control of this bit? - Should we clear this bit after all method invocations have been finished? - Can a EMCP method become running again after the bit was cleared or not set? src/share/vm/prims/jvmtiImpl.cpp 300 if (method->is_running_emcp() && Is it possible that an EMCP method becomes running after the bit is_running_emcp() is set? Do we miss breakpoints in such a case? 303 RC_TRACE(0x00000800, ("%sing breakpoint in %s(%s)", 304 meth_act == &Method::set_breakpoint ? "set" : "clear", The change from "sett" to "set" seems to be wrong (see the line 303): src/share/vm/prims/jvmtiRedefineClasses.cpp src/share/vm/prims/jvmtiRedefineClasses.hpp No comments Thanks, Serguei On 8/22/14 7:26 AM, Coleen Phillimore wrote: > > Thanks Dan, Serguei and Roland for discussion on this change. The > latest version is here: > > open webrev at http://cr.openjdk.java.net/~coleenp/8055008_2/ > > Changes from the last version (don't have the setup to do a diff > webrev, sorry) are that I have a new flag to mark running emcp methods > so we can set breakpoints in only those. Also, confirmed that we need > to clean_weak_method_links in obsolete methods too. Made changes per > review comments. Also, added more to the test so that all tracing in > InstanceKlass comes out. Reran all tests (nsk, jck, jtreg, > java/lang/instrument). > > Thanks to whoever made command line processing handle hex numbers! > > Thanks, > Coleen > > On 8/20/14, 9:26 PM, Coleen Phillimore wrote: >> >> On 8/20/14, 6:45 PM, Daniel D. Daugherty wrote: >>> On 8/20/14 2:01 PM, Coleen Phillimore wrote: >>>> On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>>>> >>>>>> If an EMCP method is not running, should we save it on a previous >>>>>> version list anyway so that we can make it obsolete if it's >>>>>> redefined and made obsolete? >>>>> >>>>> I hope, Dan will catch me if I'm wrong... >>>>> >>>>> I think, we should not. >>>>> An EMCP method can not be made obsolete if it is not running. >>>>> >>>> >>>> >>>> It should be this way otherwise we'd have to hang onto things forever. >>> >>> An EMCP method should only be made obsolete if a RedefineClasses() or >>> RetransformClasses() operation made it so. We should not be leveraging >>> off the obsolete-ness attribute to solve a life-cycle problem. >> >> Yes, this was my error in the change. This is why I made things >> obsolete if they were not running. I think I can't reuse this flag. >> My latest changes add a new explicit flag (which we have space for in >> Method*). >>> >>> In the pre-PGR world, we could trust GC to make a completely unused >>> EMCP method collectible and eventually our weak reference would go >>> away. Just because an EMCP method is not on a stack does not mean >>> that it is not used so we need a different way to determine whether >>> it is OK to no longer track an EMCP method. >> >> Our on_stack marking is supposed to look at all the places where GC >> used to look so I think we can use on_stack to track the lifecycle of >> EMCP methods. If the EMCP method is somewhere, we will find it! >> >> I'm running tests on the latest change, but am also waiting for >> confirmation from Roland because we were only cleaning out MethodData >> for EMCP methods and not for running obsolete methods and I think we >> need to do that for obsolete methods also, which my change does now. >> I think it was a bug. >> >> Thanks Dan for remembering all of this for me! >> >> Coleen >>> >>> >>>> >>>>> BTW, I'm reviewing the webrev too, but probably it'd be better to >>>>> switch to updated webrev after it is ready. >>>> >>>> Yes, this is a good idea. I figured out why I made emcp methods >>>> obsolete, and I'm fixing that as well as Dan's comments. Thanks! >>> >>> Cool! I'm looking forward to the next review. >>> >>> Dan >>> >>> >>>> >>>> Coleen >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>> >>> >> > From erik.joelsson at oracle.com Wed Aug 27 12:53:52 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 Aug 2014 14:53:52 +0200 Subject: RFR: JDK-8056053: Disable HOTSPOT_BUILD_JOBS when building with configure In-Reply-To: <53FC672E.4020907@oracle.com> References: <53FC672E.4020907@oracle.com> Message-ID: <53FDD4E0.7090004@oracle.com> Thanks David and Magnus for the reviews! Now for pushing this. The changes in root and hotspot need to go together. They should not affect the standalone hotspot build, nor the resulting built bits. I think it is safe to push both to jdk9/hs-rt as it would not affect testing compatibility with the promoted jdk build. Is it ok to do so? /Erik On 2014-08-26 12:53, Erik Joelsson wrote: > Hello, > > Please review this proposed fix for the Hotspot build. > > In the new jdk9 build, we utilize the gnu make job server, which > automatically makes sure the -j flag gets propagated and shared > between all recursive make calls. In the hotspot build, this gets > overridden by the HOTSPOT_BUILD_JOBS variable. Configure estimates a > reasonable number of parallel make jobs into the JOBS variable, which > gets propagated to the HOTSPOT_BUILD_JOBS variable. This used to work > well enough, but in the new build, the hotspot build is happening > concurrently with other parts of the build and the consequence is that > the hotspot build gets JOBS number of jobs and the rest of the build > also gets JOBS number of jobs, all of which are used at the same time. > We would like the whole build to share in the same job pool. > > To fix this, the setting of -j$(HOTSPOT_BUILD_JOBS) needs to be made > conditional and we need to add .NOTPARALLEL: to a number of makefiles > in hotspot that currently can't handle being executed in parallel. > Lastly, the + sign must be added first to recipe lines that call make > recursively but are not explicitly using the MAKE variable directly. > The result will be that the active -j flag in the root makefiles will > just automatically propagate down to the hotspot makefiles. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8056053 > Webrev: http://cr.openjdk.java.net/~erikj/8056053/webrev.01/ > > /Erik From daniel.daugherty at oracle.com Wed Aug 27 13:09:19 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 27 Aug 2014 07:09:19 -0600 Subject: RFR: JDK-8056053: Disable HOTSPOT_BUILD_JOBS when building with configure In-Reply-To: <53FDD4E0.7090004@oracle.com> References: <53FC672E.4020907@oracle.com> <53FDD4E0.7090004@oracle.com> Message-ID: <53FDD87F.4040907@oracle.com> On 8/27/14 6:53 AM, Erik Joelsson wrote: > Thanks David and Magnus for the reviews! > > Now for pushing this. The changes in root and hotspot need to go > together. They should not affect the standalone hotspot build, nor the > resulting built bits. I think it is safe to push both to jdk9/hs-rt as > it would not affect testing compatibility with the promoted jdk build. > Is it ok to do so? Not only OK, but also the preferred way to go! Alejandro prefers that HotSpot makefile changes come up through HotSpot repos so we don't get any surprises... Dan > > /Erik > > > On 2014-08-26 12:53, Erik Joelsson wrote: >> Hello, >> >> Please review this proposed fix for the Hotspot build. >> >> In the new jdk9 build, we utilize the gnu make job server, which >> automatically makes sure the -j flag gets propagated and shared >> between all recursive make calls. In the hotspot build, this gets >> overridden by the HOTSPOT_BUILD_JOBS variable. Configure estimates a >> reasonable number of parallel make jobs into the JOBS variable, which >> gets propagated to the HOTSPOT_BUILD_JOBS variable. This used to work >> well enough, but in the new build, the hotspot build is happening >> concurrently with other parts of the build and the consequence is >> that the hotspot build gets JOBS number of jobs and the rest of the >> build also gets JOBS number of jobs, all of which are used at the >> same time. We would like the whole build to share in the same job pool. >> >> To fix this, the setting of -j$(HOTSPOT_BUILD_JOBS) needs to be made >> conditional and we need to add .NOTPARALLEL: to a number of makefiles >> in hotspot that currently can't handle being executed in parallel. >> Lastly, the + sign must be added first to recipe lines that call make >> recursively but are not explicitly using the MAKE variable directly. >> The result will be that the active -j flag in the root makefiles will >> just automatically propagate down to the hotspot makefiles. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8056053 >> Webrev: http://cr.openjdk.java.net/~erikj/8056053/webrev.01/ >> >> /Erik > From daniel.daugherty at oracle.com Wed Aug 27 13:38:35 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 27 Aug 2014 07:38:35 -0600 Subject: RFR: JDK-8056053: Disable HOTSPOT_BUILD_JOBS when building with configure In-Reply-To: <53FDD87F.4040907@oracle.com> References: <53FC672E.4020907@oracle.com> <53FDD4E0.7090004@oracle.com> <53FDD87F.4040907@oracle.com> Message-ID: <53FDDF5B.9060204@oracle.com> On 8/27/14 7:09 AM, Daniel D. Daugherty wrote: > On 8/27/14 6:53 AM, Erik Joelsson wrote: >> Thanks David and Magnus for the reviews! >> >> Now for pushing this. The changes in root and hotspot need to go >> together. They should not affect the standalone hotspot build, nor >> the resulting built bits. I think it is safe to push both to >> jdk9/hs-rt as it would not affect testing compatibility with the >> promoted jdk build. Is it ok to do so? > > Not only OK, but also the preferred way to go! Alejandro prefers that > HotSpot makefile changes come up through HotSpot repos so we don't > get any surprises... Forgot to say: Thumbs up! on the changes. Dan > > Dan > > >> >> /Erik >> >> >> On 2014-08-26 12:53, Erik Joelsson wrote: >>> Hello, >>> >>> Please review this proposed fix for the Hotspot build. >>> >>> In the new jdk9 build, we utilize the gnu make job server, which >>> automatically makes sure the -j flag gets propagated and shared >>> between all recursive make calls. In the hotspot build, this gets >>> overridden by the HOTSPOT_BUILD_JOBS variable. Configure estimates a >>> reasonable number of parallel make jobs into the JOBS variable, >>> which gets propagated to the HOTSPOT_BUILD_JOBS variable. This used >>> to work well enough, but in the new build, the hotspot build is >>> happening concurrently with other parts of the build and the >>> consequence is that the hotspot build gets JOBS number of jobs and >>> the rest of the build also gets JOBS number of jobs, all of which >>> are used at the same time. We would like the whole build to share in >>> the same job pool. >>> >>> To fix this, the setting of -j$(HOTSPOT_BUILD_JOBS) needs to be made >>> conditional and we need to add .NOTPARALLEL: to a number of >>> makefiles in hotspot that currently can't handle being executed in >>> parallel. Lastly, the + sign must be added first to recipe lines >>> that call make recursively but are not explicitly using the MAKE >>> variable directly. The result will be that the active -j flag in the >>> root makefiles will just automatically propagate down to the hotspot >>> makefiles. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8056053 >>> Webrev: http://cr.openjdk.java.net/~erikj/8056053/webrev.01/ >>> >>> /Erik >> > > From daniel.daugherty at oracle.com Wed Aug 27 13:54:57 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 27 Aug 2014 07:54:57 -0600 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53FDC3BC.3030605@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> <53F52521.1080309@oracle.com> <53FDC3BC.3030605@oracle.com> Message-ID: <53FDE331.9050502@oracle.com> On 8/27/14 5:40 AM, serguei.spitsyn at oracle.com wrote: > On 8/20/14 3:45 PM, Daniel D. Daugherty wrote: >> On 8/20/14 2:01 PM, Coleen Phillimore wrote: >>> On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>>> >>>>> If an EMCP method is not running, should we save it on a previous >>>>> version list anyway so that we can make it obsolete if it's >>>>> redefined and made obsolete? >>>> >>>> I hope, Dan will catch me if I'm wrong... >>>> >>>> I think, we should not. >>>> An EMCP method can not be made obsolete if it is not running. >>>> >>> >>> >>> It should be this way otherwise we'd have to hang onto things forever. >> >> An EMCP method should only be made obsolete if a RedefineClasses() or >> RetransformClasses() operation made it so. We should not be leveraging >> off the obsolete-ness attribute to solve a life-cycle problem. >> >> In the pre-PGR world, we could trust GC to make a completely unused >> EMCP method collectible and eventually our weak reference would go >> away. Just because an EMCP method is not on a stack does not mean >> that it is not used so we need a different way to determine whether >> it is OK to no longer track an EMCP method. > > Most likely, you are right. > But I'm not convinced yet. Sorry. > A convincing point would be a test that shows this behavior. > I understand that it is not an easy task to write such a test though. > However, such a test would serve nicely if we want a different way > to determine whether it is OK to no longer track an EMCP method. Running the Serviceability stack of tests with the following -XX:TraceRedefineClasses=NN flags: // 0x00001000 | 4096 - detect calls to obsolete methods // 0x00002000 | 8192 - fail a guarantee() in addition to detection will show failures of the guarantee(). I used to do this periodically and then chase down the failures to make sure only the "legitimate" races were happening. The reason that we had to add these flags was to find all the places where folks were caching methods in the VM. I think the last place I found and fixed was in reflection. Dan > > > Thanks, > Serguei > >> >> >>> >>>> BTW, I'm reviewing the webrev too, but probably it'd be better to >>>> switch to updated webrev after it is ready. >>> >>> Yes, this is a good idea. I figured out why I made emcp methods >>> obsolete, and I'm fixing that as well as Dan's comments. Thanks! >> >> Cool! I'm looking forward to the next review. >> >> Dan >> >> >>> >>> Coleen >>> >>>> >>>> Thanks, >>>> Serguei >>> >> > From volker.simonis at gmail.com Wed Aug 27 14:58:30 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 27 Aug 2014 18:58:30 +0400 Subject: RFR(XXS): 8056175: Change "8048150: Allow easy configurations for large CDS archives" triggers conversion warning with older GCC Message-ID: Hi, could somebody please review and sponsor the following tiny change which fixes the HotSpot build on older versions of GCC after change "8048150: Allow easy configurations for large CDS archives": http://cr.openjdk.java.net/~simonis/webrevs/8056175/ https://bugs.openjdk.java.net/browse/JDK-8056175 For GCC versions before 4.3 we still use the "-Wconversion" flag so if we build with such a GCC the code introduced by "8048150: Allow easy configurations for large CDS archives" will trigger the following warnings which are treated as errors: /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp: In static member function 'static void MetaspaceShared::estimate_regions_size()': /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1124: warning: converting to 'uintx' from 'double' /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1125: warning: converting to 'uintx' from 'double' /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1126: warning: converting to 'uintx' from 'double' /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1127: warning: converting to 'uintx' from 'double' /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1129: warning: converting to 'uintx' from 'double' /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1130: warning: converting to 'uintx' from 'double' /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1131: warning: converting to 'uintx' from 'double' /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1132: warning: converting to 'uintx' from 'double' The fix is trivial - just implicitly cast the result of the conversion to uintx. Thank you and best regards, Volker From christian.thalinger at oracle.com Wed Aug 27 15:57:48 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 27 Aug 2014 08:57:48 -0700 Subject: RFR 8056039: Hotspot does not compile with clang 3.4 on Linux In-Reply-To: <1593876.cxpFjnnrsK@mgerdin03> References: <1593876.cxpFjnnrsK@mgerdin03> Message-ID: Maybe you want to fix this one too: [#JDK-8025688] Clang: enable return type warnings on Linux - Java Bug System https://bugs.openjdk.java.net/browse/JDK-8025688 On Aug 26, 2014, at 3:17 AM, Mikael Gerdin wrote: > Hi all, > > In order to get clang's (sometimes) more helpful error messages when compiling > I'd like to fix the few remaining places where clang fails to compile Hotspot. > > The culprit in this case was "local_vsnprintf" in os_linux.cpp, an unused > function which wasn't annotaded with the PRINTF_FORMAT macro. > Since the function was unused I decided to remove it instead, then I found it > in the other os_*nix.cpp files as well. > > Digging into the Teamware history it looks like it first appeared in the > Solaris port because vsnprintf did not exist on some very old versions of > Solaris, so it was dynamically looked up through dlsym. For a few years > vsnprintf has been present in the Solaris header files, so I think it's safe > to remove the workaround now some 17 years later. > > I also need a SCANF_FORMAT for an internal file, so I added that to > globalDefinitions. > > Webrev: http://cr.openjdk.java.net/~mgerdin/8056039/webrev/ > Buglink: https://bugs.openjdk.java.net/browse/JDK-8056039 > > Thanks > /Mikael > > From gerard.ziemski at oracle.com Wed Aug 27 16:24:58 2014 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 27 Aug 2014 11:24:58 -0500 Subject: RFR 8056084: Refactor Hashtable to allow implementations without rehashing support In-Reply-To: <2174664.Dc28FTrABg@mgerdin03> References: <2174664.Dc28FTrABg@mgerdin03> Message-ID: <53FE065A.9000807@oracle.com> hi Mikael, I like the changes, even though I will have to merge my code with this change later ;-) The only thing that I don't understand, however, is the removed"#if defined(SOLARIS)" clause at the bottom of hashtable.cpp I am not a Reviewer (capital R), but please consider it reviewed (lowercase r) cheers On 8/26/2014 10:26 AM, Mikael Gerdin wrote: > Hi all, > > For JDK-8048268 I need to do some refactoring of the Hashtable class template. > > >From the bug description: > In order to simplify usage of the Hashtable class the code to perform > rehashing of the SymbolTable and StringTable should be factored out to an > intermediate class common to those two tables. > Also factor out HashtableEntry freelist allocation to allow implementors an > easier route for providing their own memory management. > > Introducing the new intermediary superclass requires some calls to superclass > functions to be qualified using the "this->" syntax due to the C++ template > name lookup rules. > > a comment about hashtable.cpp RehashableHashtable::dump_table: > > - int bucket_bytes = (int)num_buckets * sizeof(bucket(0)); > + int bucket_bytes = (int)num_buckets * sizeof(HashtableBucket); > > I decided to change the sizeof to count the size of the hashtable bucket class > instead of the HashtableEntry* returned by bucket(0), even though they may be > of the same size currently. > > Note that the webrev url refers to another bug. > Webrev: http://cr.openjdk.java.net/~mgerdin/8048268/hashtable-refactor/webrev/ > Buglink: https://bugs.openjdk.java.net/browse/JDK-8056084 > > Testing: JPRT. > > > From calvin.cheung at oracle.com Wed Aug 27 16:46:06 2014 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 27 Aug 2014 09:46:06 -0700 Subject: RFR(XXS): 8056175: Change "8048150: Allow easy configurations for large CDS archives" triggers conversion warning with older GCC In-Reply-To: References: Message-ID: <53FE0B4E.90801@oracle.com> Hi Volker, Your fix looks good and thanks for fixing it. I can sponsor your fix after another 'R'eviewer has reviewed it. thanks, Calvin On 8/27/2014 7:58 AM, Volker Simonis wrote: > Hi, > > could somebody please review and sponsor the following tiny change > which fixes the HotSpot build on older versions of GCC after change > "8048150: Allow easy configurations for large CDS archives": > > http://cr.openjdk.java.net/~simonis/webrevs/8056175/ > https://bugs.openjdk.java.net/browse/JDK-8056175 > > For GCC versions before 4.3 we still use the "-Wconversion" flag so if > we build with such a GCC the code introduced by "8048150: Allow easy > configurations for large CDS archives" will trigger the following > warnings which are treated as errors: > > /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp: In static > member function 'static void > MetaspaceShared::estimate_regions_size()': > /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1124: warning: > converting to 'uintx' from 'double' > /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1125: warning: > converting to 'uintx' from 'double' > /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1126: warning: > converting to 'uintx' from 'double' > /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1127: warning: > converting to 'uintx' from 'double' > /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1129: warning: > converting to 'uintx' from 'double' > /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1130: warning: > converting to 'uintx' from 'double' > /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1131: warning: > converting to 'uintx' from 'double' > /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1132: warning: > converting to 'uintx' from 'double' > > The fix is trivial - just implicitly cast the result of the conversion to uintx. > > Thank you and best regards, > Volker From jon.masamitsu at oracle.com Wed Aug 27 16:54:34 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 27 Aug 2014 09:54:34 -0700 Subject: Fwd: Re: RFR 8056084: Refactor Hashtable to allow implementations without rehashing support In-Reply-To: <53FCF1DA.4010504@oracle.com> References: <53FCF1DA.4010504@oracle.com> Message-ID: <53FE0D4A.1050307@oracle.com> Mikael, Just a resend since I forgot the mailing list on my reply. Jon -------- Original Message -------- Subject: Re: RFR 8056084: Refactor Hashtable to allow implementations without rehashing support Date: Tue, 26 Aug 2014 13:45:14 -0700 From: Jon Masamitsu To: Mikael Gerdin http://cr.openjdk.java.net/~mgerdin/8048268/hashtable-refactor/webrev/src/share/vm/utilities/hashtable.cpp.frames.html On right side 372 #endif // SOLARIS || CHECK_UNHANDLED_OOPS to 372 #endif CHECK_UNHANDLED_OOPS Otherwise, looks good. Reviewed. Jon On 08/26/2014 08:26 AM, Mikael Gerdin wrote: > Hi all, > > For JDK-8048268 I need to do some refactoring of the Hashtable class template. > > From the bug description: > In order to simplify usage of the Hashtable class the code to perform > rehashing of the SymbolTable and StringTable should be factored out to an > intermediate class common to those two tables. > Also factor out HashtableEntry freelist allocation to allow implementors an > easier route for providing their own memory management. > > Introducing the new intermediary superclass requires some calls to superclass > functions to be qualified using the "this->" syntax due to the C++ template > name lookup rules. > > a comment about hashtable.cpp RehashableHashtable::dump_table: > > - int bucket_bytes = (int)num_buckets * sizeof(bucket(0)); > + int bucket_bytes = (int)num_buckets * sizeof(HashtableBucket); > > I decided to change the sizeof to count the size of the hashtable bucket class > instead of the HashtableEntry* returned by bucket(0), even though they may be > of the same size currently. > > Note that the webrev url refers to another bug. > Webrev: http://cr.openjdk.java.net/~mgerdin/8048268/hashtable-refactor/webrev/ > Buglink: https://bugs.openjdk.java.net/browse/JDK-8056084 > > Testing: JPRT. > From stefan.karlsson at oracle.com Wed Aug 27 16:59:00 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 27 Aug 2014 18:59:00 +0200 Subject: RFR 8056039: Hotspot does not compile with clang 3.4 on Linux In-Reply-To: References: <1593876.cxpFjnnrsK@mgerdin03> Message-ID: <53FE0E54.8000208@oracle.com> On 27/08/14 17:57, Christian Thalinger wrote: > Maybe you want to fix this one too: > > [#JDK-8025688] Clang: enable return type warnings on Linux - Java Bug System > https://bugs.openjdk.java.net/browse/JDK-8025688 I've created a prototype to make sure ShouldNotReachHere(), and friends, never return. With that in place we only need a few small changes and then we can enable -Wreturn-type on Linux. The prototype uses __attribute__((noreturn)). thanks, StefanK > > On Aug 26, 2014, at 3:17 AM, Mikael Gerdin wrote: > >> Hi all, >> >> In order to get clang's (sometimes) more helpful error messages when compiling >> I'd like to fix the few remaining places where clang fails to compile Hotspot. >> >> The culprit in this case was "local_vsnprintf" in os_linux.cpp, an unused >> function which wasn't annotaded with the PRINTF_FORMAT macro. >> Since the function was unused I decided to remove it instead, then I found it >> in the other os_*nix.cpp files as well. >> >> Digging into the Teamware history it looks like it first appeared in the >> Solaris port because vsnprintf did not exist on some very old versions of >> Solaris, so it was dynamically looked up through dlsym. For a few years >> vsnprintf has been present in the Solaris header files, so I think it's safe >> to remove the workaround now some 17 years later. >> >> I also need a SCANF_FORMAT for an internal file, so I added that to >> globalDefinitions. >> >> Webrev: http://cr.openjdk.java.net/~mgerdin/8056039/webrev/ >> Buglink: https://bugs.openjdk.java.net/browse/JDK-8056039 >> >> Thanks >> /Mikael >> >> From christian.thalinger at oracle.com Wed Aug 27 17:00:15 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 27 Aug 2014 10:00:15 -0700 Subject: RFR 8056039: Hotspot does not compile with clang 3.4 on Linux In-Reply-To: <53FE0E54.8000208@oracle.com> References: <1593876.cxpFjnnrsK@mgerdin03> <53FE0E54.8000208@oracle.com> Message-ID: On Aug 27, 2014, at 9:59 AM, Stefan Karlsson wrote: > On 27/08/14 17:57, Christian Thalinger wrote: >> Maybe you want to fix this one too: >> >> [#JDK-8025688] Clang: enable return type warnings on Linux - Java Bug System >> https://bugs.openjdk.java.net/browse/JDK-8025688 > > I've created a prototype to make sure ShouldNotReachHere(), and friends, never return. With that in place we only need a few small changes and then we can enable -Wreturn-type on Linux. The prototype uses __attribute__((noreturn)). Great, thanks! > > thanks, > StefanK > > >> >> On Aug 26, 2014, at 3:17 AM, Mikael Gerdin wrote: >> >>> Hi all, >>> >>> In order to get clang's (sometimes) more helpful error messages when compiling >>> I'd like to fix the few remaining places where clang fails to compile Hotspot. >>> >>> The culprit in this case was "local_vsnprintf" in os_linux.cpp, an unused >>> function which wasn't annotaded with the PRINTF_FORMAT macro. >>> Since the function was unused I decided to remove it instead, then I found it >>> in the other os_*nix.cpp files as well. >>> >>> Digging into the Teamware history it looks like it first appeared in the >>> Solaris port because vsnprintf did not exist on some very old versions of >>> Solaris, so it was dynamically looked up through dlsym. For a few years >>> vsnprintf has been present in the Solaris header files, so I think it's safe >>> to remove the workaround now some 17 years later. >>> >>> I also need a SCANF_FORMAT for an internal file, so I added that to >>> globalDefinitions. >>> >>> Webrev: http://cr.openjdk.java.net/~mgerdin/8056039/webrev/ >>> Buglink: https://bugs.openjdk.java.net/browse/JDK-8056039 >>> >>> Thanks >>> /Mikael >>> >>> > From coleen.phillimore at oracle.com Wed Aug 27 17:12:53 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 27 Aug 2014 13:12:53 -0400 Subject: RFR(XXS): 8056175: Change "8048150: Allow easy configurations for large CDS archives" triggers conversion warning with older GCC In-Reply-To: <53FE0B4E.90801@oracle.com> References: <53FE0B4E.90801@oracle.com> Message-ID: <53FE1195.7060602@oracle.com> This looks good to me. Thank you for fixing it and Calvin, thanks for sponsoring it. Coleen On 8/27/14, 12:46 PM, Calvin Cheung wrote: > Hi Volker, > > Your fix looks good and thanks for fixing it. > I can sponsor your fix after another 'R'eviewer has reviewed it. > > thanks, > Calvin > > On 8/27/2014 7:58 AM, Volker Simonis wrote: >> Hi, >> >> could somebody please review and sponsor the following tiny change >> which fixes the HotSpot build on older versions of GCC after change >> "8048150: Allow easy configurations for large CDS archives": >> >> http://cr.openjdk.java.net/~simonis/webrevs/8056175/ >> https://bugs.openjdk.java.net/browse/JDK-8056175 >> >> For GCC versions before 4.3 we still use the "-Wconversion" flag so if >> we build with such a GCC the code introduced by "8048150: Allow easy >> configurations for large CDS archives" will trigger the following >> warnings which are treated as errors: >> >> /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp: In static >> member function 'static void >> MetaspaceShared::estimate_regions_size()': >> /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1124: warning: >> converting to 'uintx' from 'double' >> /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1125: warning: >> converting to 'uintx' from 'double' >> /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1126: warning: >> converting to 'uintx' from 'double' >> /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1127: warning: >> converting to 'uintx' from 'double' >> /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1129: warning: >> converting to 'uintx' from 'double' >> /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1130: warning: >> converting to 'uintx' from 'double' >> /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1131: warning: >> converting to 'uintx' from 'double' >> /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1132: warning: >> converting to 'uintx' from 'double' >> >> The fix is trivial - just implicitly cast the result of the >> conversion to uintx. >> >> Thank you and best regards, >> Volker > From vladimir.kozlov at oracle.com Wed Aug 27 17:20:36 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Aug 2014 10:20:36 -0700 Subject: RFR 8049105: Move array component mirror to instance of java/lang/Class (hotspot part 2) In-Reply-To: <53FC91FC.1070700@oracle.com> References: <53FC91FC.1070700@oracle.com> Message-ID: <53FE1364.7010703@oracle.com> On 8/26/14 6:56 AM, Coleen Phillimore wrote: > Summary: This removes component mirrors from arrayKlass metadata and the > C2 intrinsic for them. > > I'm sending this out to hotspot-dev so I can get someone from the > compiler to review this (again). Chris Thalinger, you already saw this > once, it's the same thing, but I had to hold this change until it was > okay'd by licensees. Can you re-review? Looks fine to me. > > Also GC team note that Klass::oops_do() is now non-virtual. Will that > help? Yes, it helps. It reduce virtual table size for Klass and the method could be inlined. > > Tested with jck, nsk and jtreg tests. Also, ran refworkload with no > difference in performance. Thanks, Vladimir > > open webrev at http://cr.openjdk.java.net/~coleenp/8049105/ > bug link https://bugs.openjdk.java.net/browse/JDK-8049105 > > Thanks, > Coleen From coleen.phillimore at oracle.com Wed Aug 27 17:27:03 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 27 Aug 2014 13:27:03 -0400 Subject: RFR 8049105: Move array component mirror to instance of java/lang/Class (hotspot part 2) In-Reply-To: <53FE1364.7010703@oracle.com> References: <53FC91FC.1070700@oracle.com> <53FE1364.7010703@oracle.com> Message-ID: <53FE14E7.8070001@oracle.com> Thank you, Vladimir! Coleen On 8/27/14, 1:20 PM, Vladimir Kozlov wrote: > > > On 8/26/14 6:56 AM, Coleen Phillimore wrote: >> Summary: This removes component mirrors from arrayKlass metadata and the >> C2 intrinsic for them. >> >> I'm sending this out to hotspot-dev so I can get someone from the >> compiler to review this (again). Chris Thalinger, you already saw this >> once, it's the same thing, but I had to hold this change until it was >> okay'd by licensees. Can you re-review? > > Looks fine to me. > >> >> Also GC team note that Klass::oops_do() is now non-virtual. Will that >> help? > > Yes, it helps. It reduce virtual table size for Klass and the method > could be inlined. > >> >> Tested with jck, nsk and jtreg tests. Also, ran refworkload with no >> difference in performance. > > Thanks, > Vladimir > >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8049105/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8049105 >> >> Thanks, >> Coleen From christian.thalinger at oracle.com Wed Aug 27 17:49:55 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 27 Aug 2014 10:49:55 -0700 Subject: RFR 8049105: Move array component mirror to instance of java/lang/Class (hotspot part 2) In-Reply-To: <53FC91FC.1070700@oracle.com> References: <53FC91FC.1070700@oracle.com> Message-ID: <9E38509C-E087-46C9-9339-C9C32C6BA2FD@oracle.com> On Aug 26, 2014, at 6:56 AM, Coleen Phillimore wrote: > Summary: This removes component mirrors from arrayKlass metadata and the C2 intrinsic for them. > > I'm sending this out to hotspot-dev so I can get someone from the compiler to review this (again). Chris Thalinger, you already saw this once, it's the same thing, but I had to hold this change until it was okay'd by licensees. Can you re-review? Yes, still looks good. > > Also GC team note that Klass::oops_do() is now non-virtual. Will that help? > > Tested with jck, nsk and jtreg tests. Also, ran refworkload with no difference in performance. > > open webrev at http://cr.openjdk.java.net/~coleenp/8049105/ > bug link https://bugs.openjdk.java.net/browse/JDK-8049105 > > Thanks, > Coleen From serguei.spitsyn at oracle.com Wed Aug 27 18:41:28 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 27 Aug 2014 11:41:28 -0700 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53FDE331.9050502@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> <53F52521.1080309@oracle.com> <53FDC3BC.3030605@oracle.com> <53FDE331.9050502@oracle.com> Message-ID: <53FE2658.1090302@oracle.com> On 8/27/14 6:54 AM, Daniel D. Daugherty wrote: > > On 8/27/14 5:40 AM, serguei.spitsyn at oracle.com wrote: >> On 8/20/14 3:45 PM, Daniel D. Daugherty wrote: >>> On 8/20/14 2:01 PM, Coleen Phillimore wrote: >>>> On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>>>> >>>>>> If an EMCP method is not running, should we save it on a previous >>>>>> version list anyway so that we can make it obsolete if it's >>>>>> redefined and made obsolete? >>>>> >>>>> I hope, Dan will catch me if I'm wrong... >>>>> >>>>> I think, we should not. >>>>> An EMCP method can not be made obsolete if it is not running. >>>>> >>>> >>>> >>>> It should be this way otherwise we'd have to hang onto things forever. >>> >>> An EMCP method should only be made obsolete if a RedefineClasses() or >>> RetransformClasses() operation made it so. We should not be leveraging >>> off the obsolete-ness attribute to solve a life-cycle problem. >>> >>> In the pre-PGR world, we could trust GC to make a completely unused >>> EMCP method collectible and eventually our weak reference would go >>> away. Just because an EMCP method is not on a stack does not mean >>> that it is not used so we need a different way to determine whether >>> it is OK to no longer track an EMCP method. >> >> Most likely, you are right. >> But I'm not convinced yet. Sorry. >> A convincing point would be a test that shows this behavior. >> I understand that it is not an easy task to write such a test though. >> However, such a test would serve nicely if we want a different way >> to determine whether it is OK to no longer track an EMCP method. > > Running the Serviceability stack of tests with the following > -XX:TraceRedefineClasses=NN flags: > > // 0x00001000 | 4096 - detect calls to obsolete methods > // 0x00002000 | 8192 - fail a guarantee() in addition to > detection > > will show failures of the guarantee(). I used to do this > periodically and then chase down the failures to make sure > only the "legitimate" races were happening. The reason that > we had to add these flags was to find all the places where > folks were caching methods in the VM. I think the last place > I found and fixed was in reflection. Ok, thanks. We threat this as buggy behavior, right? Thanks, Serguei > > Dan > > >> >> >> Thanks, >> Serguei >> >>> >>> >>>> >>>>> BTW, I'm reviewing the webrev too, but probably it'd be better to >>>>> switch to updated webrev after it is ready. >>>> >>>> Yes, this is a good idea. I figured out why I made emcp methods >>>> obsolete, and I'm fixing that as well as Dan's comments. Thanks! >>> >>> Cool! I'm looking forward to the next review. >>> >>> Dan >>> >>> >>>> >>>> Coleen >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>> >>> >> > From daniel.daugherty at oracle.com Wed Aug 27 19:33:43 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 27 Aug 2014 13:33:43 -0600 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53FE2658.1090302@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> <53F52521.1080309@oracle.com> <53FDC3BC.3030605@oracle.com> <53FDE331.9050502@oracle.com> <53FE2658.1090302@oracle.com> Message-ID: <53FE3297.6000006@oracle.com> On 8/27/14 12:41 PM, serguei.spitsyn at oracle.com wrote: > On 8/27/14 6:54 AM, Daniel D. Daugherty wrote: >> >> On 8/27/14 5:40 AM, serguei.spitsyn at oracle.com wrote: >>> On 8/20/14 3:45 PM, Daniel D. Daugherty wrote: >>>> On 8/20/14 2:01 PM, Coleen Phillimore wrote: >>>>> On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> >>>>>>> If an EMCP method is not running, should we save it on a >>>>>>> previous version list anyway so that we can make it obsolete if >>>>>>> it's redefined and made obsolete? >>>>>> >>>>>> I hope, Dan will catch me if I'm wrong... >>>>>> >>>>>> I think, we should not. >>>>>> An EMCP method can not be made obsolete if it is not running. >>>>>> >>>>> >>>>> >>>>> It should be this way otherwise we'd have to hang onto things >>>>> forever. >>>> >>>> An EMCP method should only be made obsolete if a RedefineClasses() or >>>> RetransformClasses() operation made it so. We should not be leveraging >>>> off the obsolete-ness attribute to solve a life-cycle problem. >>>> >>>> In the pre-PGR world, we could trust GC to make a completely unused >>>> EMCP method collectible and eventually our weak reference would go >>>> away. Just because an EMCP method is not on a stack does not mean >>>> that it is not used so we need a different way to determine whether >>>> it is OK to no longer track an EMCP method. >>> >>> Most likely, you are right. >>> But I'm not convinced yet. Sorry. >>> A convincing point would be a test that shows this behavior. >>> I understand that it is not an easy task to write such a test though. >>> However, such a test would serve nicely if we want a different way >>> to determine whether it is OK to no longer track an EMCP method. >> >> Running the Serviceability stack of tests with the following >> -XX:TraceRedefineClasses=NN flags: >> >> // 0x00001000 | 4096 - detect calls to obsolete methods >> // 0x00002000 | 8192 - fail a guarantee() in addition to >> detection >> >> will show failures of the guarantee(). I used to do this >> periodically and then chase down the failures to make sure >> only the "legitimate" races were happening. The reason that >> we had to add these flags was to find all the places where >> folks were caching methods in the VM. I think the last place >> I found and fixed was in reflection. > > Ok, thanks. > We threat this as buggy behavior, right? Not necessarily. If it's because of a cached method that didn't get updated to the new version, then that's a bug. However, if it's because of a call that is in progress, then we have not considered that a bug in the past. I don't remember the exact details, but the dance is something like this: - jmethodID converted to methodHandle - call to methodHandle prepared: - methodHandle -> methodOop - parameters marshalled - methodOop converted to method impl - method called - somewhere in the middle of call sequence the method is redefined - jmethodID and methodHandle are updated to refer to the new method, but we already converted to the methodOop and the underlying method implementation for the final stages of the call - when we've actually called the now obsolete method, the guarantee() mentioned above fires and we have a false positive for the tracing code Of course, now that we don't have methodOops, maybe this doesn't happen anymore. I haven't done a test run with the above flags enabled in quite some time... Dan > > Thanks, > Serguei > >> >> Dan >> >> >>> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> >>>>> >>>>>> BTW, I'm reviewing the webrev too, but probably it'd be better to >>>>>> switch to updated webrev after it is ready. >>>>> >>>>> Yes, this is a good idea. I figured out why I made emcp methods >>>>> obsolete, and I'm fixing that as well as Dan's comments. Thanks! >>>> >>>> Cool! I'm looking forward to the next review. >>>> >>>> Dan >>>> >>>> >>>>> >>>>> Coleen >>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Wed Aug 27 20:27:54 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 27 Aug 2014 16:27:54 -0400 Subject: RFR 8049105: Move array component mirror to instance of java/lang/Class (hotspot part 2) In-Reply-To: <9E38509C-E087-46C9-9339-C9C32C6BA2FD@oracle.com> References: <53FC91FC.1070700@oracle.com> <9E38509C-E087-46C9-9339-C9C32C6BA2FD@oracle.com> Message-ID: <53FE3F4A.6070204@oracle.com> Thank you Chris! Coleen On 8/27/14, 1:49 PM, Christian Thalinger wrote: > On Aug 26, 2014, at 6:56 AM, Coleen Phillimore wrote: > >> Summary: This removes component mirrors from arrayKlass metadata and the C2 intrinsic for them. >> >> I'm sending this out to hotspot-dev so I can get someone from the compiler to review this (again). Chris Thalinger, you already saw this once, it's the same thing, but I had to hold this change until it was okay'd by licensees. Can you re-review? > Yes, still looks good. > >> Also GC team note that Klass::oops_do() is now non-virtual. Will that help? >> >> Tested with jck, nsk and jtreg tests. Also, ran refworkload with no difference in performance. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8049105/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8049105 >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Wed Aug 27 21:16:14 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 27 Aug 2014 17:16:14 -0400 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53FE3297.6000006@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> <53F52521.1080309@oracle.com> <53FDC3BC.3030605@oracle.com> <53FDE331.9050502@oracle.com> <53FE2658.1090302@oracle.com> <53FE3297.6000006@oracle.com> Message-ID: <53FE4A9E.8000903@oracle.com> On 8/27/14, 3:33 PM, Daniel D. Daugherty wrote: > On 8/27/14 12:41 PM, serguei.spitsyn at oracle.com wrote: >> On 8/27/14 6:54 AM, Daniel D. Daugherty wrote: >>> >>> On 8/27/14 5:40 AM, serguei.spitsyn at oracle.com wrote: >>>> On 8/20/14 3:45 PM, Daniel D. Daugherty wrote: >>>>> On 8/20/14 2:01 PM, Coleen Phillimore wrote: >>>>>> On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> >>>>>>>> If an EMCP method is not running, should we save it on a >>>>>>>> previous version list anyway so that we can make it obsolete if >>>>>>>> it's redefined and made obsolete? >>>>>>> >>>>>>> I hope, Dan will catch me if I'm wrong... >>>>>>> >>>>>>> I think, we should not. >>>>>>> An EMCP method can not be made obsolete if it is not running. >>>>>>> >>>>>> >>>>>> >>>>>> It should be this way otherwise we'd have to hang onto things >>>>>> forever. >>>>> >>>>> An EMCP method should only be made obsolete if a RedefineClasses() or >>>>> RetransformClasses() operation made it so. We should not be >>>>> leveraging >>>>> off the obsolete-ness attribute to solve a life-cycle problem. >>>>> >>>>> In the pre-PGR world, we could trust GC to make a completely unused >>>>> EMCP method collectible and eventually our weak reference would go >>>>> away. Just because an EMCP method is not on a stack does not mean >>>>> that it is not used so we need a different way to determine whether >>>>> it is OK to no longer track an EMCP method. >>>> >>>> Most likely, you are right. >>>> But I'm not convinced yet. Sorry. >>>> A convincing point would be a test that shows this behavior. >>>> I understand that it is not an easy task to write such a test though. >>>> However, such a test would serve nicely if we want a different way >>>> to determine whether it is OK to no longer track an EMCP method. >>> >>> Running the Serviceability stack of tests with the following >>> -XX:TraceRedefineClasses=NN flags: >>> >>> // 0x00001000 | 4096 - detect calls to obsolete methods >>> // 0x00002000 | 8192 - fail a guarantee() in addition to >>> detection >>> >>> will show failures of the guarantee(). I used to do this >>> periodically and then chase down the failures to make sure >>> only the "legitimate" races were happening. The reason that >>> we had to add these flags was to find all the places where >>> folks were caching methods in the VM. I think the last place >>> I found and fixed was in reflection. >> >> Ok, thanks. >> We threat this as buggy behavior, right? > > Not necessarily. If it's because of a cached method that didn't > get updated to the new version, then that's a bug. However, if > it's because of a call that is in progress, then we have not > considered that a bug in the past. > > I don't remember the exact details, but the dance is something > like this: > > - jmethodID converted to methodHandle > - call to methodHandle prepared: > - methodHandle -> methodOop > - parameters marshalled > - methodOop converted to method impl > - method called > - somewhere in the middle of call sequence the > method is redefined > - jmethodID and methodHandle are updated to refer to the > new method, but we already converted to the methodOop > and the underlying method implementation for the final > stages of the call > - when we've actually called the now obsolete method, > the guarantee() mentioned above fires and we have a > false positive for the tracing code > > Of course, now that we don't have methodOops, maybe this > doesn't happen anymore. I haven't done a test run with the > above flags enabled in quite some time... Do you mean methodHandle or MethodHandle above? Or java_lang_reflect_Method? The methodOop in little m methodHandles are not updated to refer to the new method, and Method* isn't either, so that really hasn't changed. I'm not following the call sequence above. But yes, I believe we could get into javaCalls::call() with an method, stop for a safepoint, and end up calling an obsolete method. But that obsolete method is considered already running at that stage because the methodHandle logic marks it as such, so it's not considered a bug. I ran the tests with the -XX:TraceRedefineClasses=0x2000 and didn't get the guarantee though, but that doesn't mean much. I'm reading these mails in reverse... Thanks, Coleen > > Dan > > >> >> Thanks, >> Serguei >> >>> >>> Dan >>> >>> >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> >>>>>> >>>>>>> BTW, I'm reviewing the webrev too, but probably it'd be better >>>>>>> to switch to updated webrev after it is ready. >>>>>> >>>>>> Yes, this is a good idea. I figured out why I made emcp methods >>>>>> obsolete, and I'm fixing that as well as Dan's comments. Thanks! >>>>> >>>>> Cool! I'm looking forward to the next review. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>> >>>>> >>>> >>> >> > From mikael.gerdin at oracle.com Thu Aug 28 06:03:09 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 28 Aug 2014 08:03:09 +0200 Subject: RFR 8056084: Refactor Hashtable to allow implementations without rehashing support In-Reply-To: <53FE065A.9000807@oracle.com> References: <2174664.Dc28FTrABg@mgerdin03> <53FE065A.9000807@oracle.com> Message-ID: <53FEC61D.80104@oracle.com> Hi Gerard, On 08/27/2014 06:24 PM, Gerard Ziemski wrote: > hi Mikael, > > I like the changes, even though I will have to merge my code with this > change later ;-) Great! > > The only thing that I don't understand, however, is the removed"#if > defined(SOLARIS)" clause at the bottom of hashtable.cpp That is indeed a bit strange. I was having a bit of template trouble when getting this to compile across all platforms, I think I misread the code as defined(SOLARIS) && defined(CHECK_UNHANDLED_OOPS) and removed the Solaris part. I'll revert the #ifdef change. > > I am not a Reviewer (capital R), but please consider it reviewed > (lowercase r) Thanks /Mikael > > > cheers > > On 8/26/2014 10:26 AM, Mikael Gerdin wrote: >> Hi all, >> >> For JDK-8048268 I need to do some refactoring of the Hashtable class >> template. >> >> >From the bug description: >> In order to simplify usage of the Hashtable class the code to >> perform >> rehashing of the SymbolTable and StringTable should be factored out to an >> intermediate class common to those two tables. >> Also factor out HashtableEntry freelist allocation to allow >> implementors an >> easier route for providing their own memory management. >> >> Introducing the new intermediary superclass requires some calls to >> superclass >> functions to be qualified using the "this->" syntax due to the C++ >> template >> name lookup rules. >> >> a comment about hashtable.cpp RehashableHashtable::dump_table: >> >> - int bucket_bytes = (int)num_buckets * sizeof(bucket(0)); >> + int bucket_bytes = (int)num_buckets * sizeof(HashtableBucket); >> >> I decided to change the sizeof to count the size of the hashtable >> bucket class >> instead of the HashtableEntry* returned by bucket(0), even though they >> may be >> of the same size currently. >> >> Note that the webrev url refers to another bug. >> Webrev: >> http://cr.openjdk.java.net/~mgerdin/8048268/hashtable-refactor/webrev/ >> Buglink: https://bugs.openjdk.java.net/browse/JDK-8056084 >> >> Testing: JPRT. >> >> >> > From mikael.gerdin at oracle.com Thu Aug 28 06:05:24 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 28 Aug 2014 08:05:24 +0200 Subject: Fwd: Re: RFR 8056084: Refactor Hashtable to allow implementations without rehashing support In-Reply-To: <53FE0D4A.1050307@oracle.com> References: <53FCF1DA.4010504@oracle.com> <53FE0D4A.1050307@oracle.com> Message-ID: <53FEC6A4.5020909@oracle.com> Hi Jon, On 08/27/2014 06:54 PM, Jon Masamitsu wrote: > Mikael, > > Just a resend since I forgot the mailing list on my > reply. > > Jon > > > -------- Original Message -------- > Subject: Re: RFR 8056084: Refactor Hashtable to allow > implementations without rehashing support > Date: Tue, 26 Aug 2014 13:45:14 -0700 > From: Jon Masamitsu > To: Mikael Gerdin > > > > http://cr.openjdk.java.net/~mgerdin/8048268/hashtable-refactor/webrev/src/share/vm/utilities/hashtable.cpp.frames.html > > > On right side > > 372 #endif // SOLARIS || CHECK_UNHANDLED_OOPS > > to > > 372 #endif CHECK_UNHANDLED_OOPS As I wrote in my reply to Gerard I've decided to revert the #ifdef change since I can't really motivate doing it, it seems to be unnecessary. Thanks /Mikael > > > Otherwise, looks good. > > Reviewed. > > Jon > > > On 08/26/2014 08:26 AM, Mikael Gerdin wrote: >> Hi all, >> >> For JDK-8048268 I need to do some refactoring of the Hashtable class >> template. >> >> From the bug description: >> In order to simplify usage of the Hashtable class the code to >> perform >> rehashing of the SymbolTable and StringTable should be factored out to an >> intermediate class common to those two tables. >> Also factor out HashtableEntry freelist allocation to allow >> implementors an >> easier route for providing their own memory management. >> >> Introducing the new intermediary superclass requires some calls to >> superclass >> functions to be qualified using the "this->" syntax due to the C++ >> template >> name lookup rules. >> >> a comment about hashtable.cpp RehashableHashtable::dump_table: >> >> - int bucket_bytes = (int)num_buckets * sizeof(bucket(0)); >> + int bucket_bytes = (int)num_buckets * sizeof(HashtableBucket); >> >> I decided to change the sizeof to count the size of the hashtable >> bucket class >> instead of the HashtableEntry* returned by bucket(0), even though they >> may be >> of the same size currently. >> >> Note that the webrev url refers to another bug. >> Webrev: >> http://cr.openjdk.java.net/~mgerdin/8048268/hashtable-refactor/webrev/ >> Buglink: https://bugs.openjdk.java.net/browse/JDK-8056084 >> >> Testing: JPRT. >> > > > From mikael.gerdin at oracle.com Thu Aug 28 06:21:00 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 28 Aug 2014 08:21:00 +0200 Subject: RFR 8049105: Move array component mirror to instance of java/lang/Class (hotspot part 2) In-Reply-To: <53FC91FC.1070700@oracle.com> References: <53FC91FC.1070700@oracle.com> Message-ID: <53FECA4C.60307@oracle.com> Coleen, On 08/26/2014 03:56 PM, Coleen Phillimore wrote: > Summary: This removes component mirrors from arrayKlass metadata and the > C2 intrinsic for them. > > I'm sending this out to hotspot-dev so I can get someone from the > compiler to review this (again). Chris Thalinger, you already saw this > once, it's the same thing, but I had to hold this change until it was > okay'd by licensees. Can you re-review? > > Also GC team note that Klass::oops_do() is now non-virtual. Will that > help? It may. But the oops_do code is riddled with closures and indirect calls through callbacks so I don't think it will gain us any significant performance boost. > > Tested with jck, nsk and jtreg tests. Also, ran refworkload with no > difference in performance. > > open webrev at http://cr.openjdk.java.net/~coleenp/8049105/ Looks good to me too. /Mikael > bug link https://bugs.openjdk.java.net/browse/JDK-8049105 > > Thanks, > Coleen From volker.simonis at gmail.com Thu Aug 28 07:06:07 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 28 Aug 2014 09:06:07 +0200 Subject: RFR(XXS): 8056175: Change "8048150: Allow easy configurations for large CDS archives" triggers conversion warning with older GCC In-Reply-To: <53FE0B4E.90801@oracle.com> References: <53FE0B4E.90801@oracle.com> Message-ID: Hi Calvin, Coleen, thanks a lot for the ultra-fast reviewing and pushing! @Calvin: just as a side node, 'hg import', 'hg commit' and 'hg qrefresh' can all be used with the '-u ' option. That way you can set the authors user name and avoid the necessity to have an extra "Contributed-by:" line for contributors who already are OpenJDK authors. Regards, Volker On Wed, Aug 27, 2014 at 6:46 PM, Calvin Cheung wrote: > Hi Volker, > > Your fix looks good and thanks for fixing it. > I can sponsor your fix after another 'R'eviewer has reviewed it. > > thanks, > Calvin > > > On 8/27/2014 7:58 AM, Volker Simonis wrote: >> >> Hi, >> >> could somebody please review and sponsor the following tiny change >> which fixes the HotSpot build on older versions of GCC after change >> "8048150: Allow easy configurations for large CDS archives": >> >> http://cr.openjdk.java.net/~simonis/webrevs/8056175/ >> https://bugs.openjdk.java.net/browse/JDK-8056175 >> >> For GCC versions before 4.3 we still use the "-Wconversion" flag so if >> we build with such a GCC the code introduced by "8048150: Allow easy >> configurations for large CDS archives" will trigger the following >> warnings which are treated as errors: >> >> /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp: In static >> member function 'static void >> MetaspaceShared::estimate_regions_size()': >> /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1124: warning: >> converting to 'uintx' from 'double' >> /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1125: warning: >> converting to 'uintx' from 'double' >> /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1126: warning: >> converting to 'uintx' from 'double' >> /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1127: warning: >> converting to 'uintx' from 'double' >> /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1129: warning: >> converting to 'uintx' from 'double' >> /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1130: warning: >> converting to 'uintx' from 'double' >> /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1131: warning: >> converting to 'uintx' from 'double' >> /src/hotspot-rt/src/share/vm/memory/metaspaceShared.cpp:1132: warning: >> converting to 'uintx' from 'double' >> >> The fix is trivial - just implicitly cast the result of the conversion to >> uintx. >> >> Thank you and best regards, >> Volker > > From mikael.gerdin at oracle.com Thu Aug 28 10:46:42 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 28 Aug 2014 12:46:42 +0200 Subject: RFR 8056039: Hotspot does not compile with clang 3.4 on Linux In-Reply-To: References: <1593876.cxpFjnnrsK@mgerdin03> <53FE0E54.8000208@oracle.com> Message-ID: <53FF0892.6040100@oracle.com> Christian, On 08/27/2014 07:00 PM, Christian Thalinger wrote: > > On Aug 27, 2014, at 9:59 AM, Stefan Karlsson wrote: > >> On 27/08/14 17:57, Christian Thalinger wrote: >>> Maybe you want to fix this one too: >>> >>> [#JDK-8025688] Clang: enable return type warnings on Linux - Java Bug System >>> https://bugs.openjdk.java.net/browse/JDK-8025688 >> >> I've created a prototype to make sure ShouldNotReachHere(), and friends, never return. With that in place we only need a few small changes and then we can enable -Wreturn-type on Linux. The prototype uses __attribute__((noreturn)). > > Great, thanks! Since Stefan has already put some effort into 8025688, are you ok with fixing that as a separate issue? -Wreturn-type is not specific to clang AFAIK, it's available in (and should be enabled with ) gcc as well. /Mikael > >> >> thanks, >> StefanK >> >> >>> >>> On Aug 26, 2014, at 3:17 AM, Mikael Gerdin wrote: >>> >>>> Hi all, >>>> >>>> In order to get clang's (sometimes) more helpful error messages when compiling >>>> I'd like to fix the few remaining places where clang fails to compile Hotspot. >>>> >>>> The culprit in this case was "local_vsnprintf" in os_linux.cpp, an unused >>>> function which wasn't annotaded with the PRINTF_FORMAT macro. >>>> Since the function was unused I decided to remove it instead, then I found it >>>> in the other os_*nix.cpp files as well. >>>> >>>> Digging into the Teamware history it looks like it first appeared in the >>>> Solaris port because vsnprintf did not exist on some very old versions of >>>> Solaris, so it was dynamically looked up through dlsym. For a few years >>>> vsnprintf has been present in the Solaris header files, so I think it's safe >>>> to remove the workaround now some 17 years later. >>>> >>>> I also need a SCANF_FORMAT for an internal file, so I added that to >>>> globalDefinitions. >>>> >>>> Webrev: http://cr.openjdk.java.net/~mgerdin/8056039/webrev/ >>>> Buglink: https://bugs.openjdk.java.net/browse/JDK-8056039 >>>> >>>> Thanks >>>> /Mikael >>>> >>>> >> > From bengt.rutisson at oracle.com Thu Aug 28 10:51:51 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 28 Aug 2014 12:51:51 +0200 Subject: RFR 8056084: Refactor Hashtable to allow implementations without rehashing support In-Reply-To: <2174664.Dc28FTrABg@mgerdin03> References: <2174664.Dc28FTrABg@mgerdin03> Message-ID: <53FF09C7.9050003@oracle.com> Hi Mikael, Looks good. One very minor nit if you feel like it. hashtable.cpp 50 if (_free_list) { Would you mind changing to "if (_free_list != NULL) {" ? I know it is not your code, but you are changing code in that method and did take me some extra brain cycles to realize that _free_list was not a bool indicating whether we were using a free list or not. Thanks, Bengt On 2014-08-26 17:26, Mikael Gerdin wrote: > Hi all, > > For JDK-8048268 I need to do some refactoring of the Hashtable class template. > > From the bug description: > In order to simplify usage of the Hashtable class the code to perform > rehashing of the SymbolTable and StringTable should be factored out to an > intermediate class common to those two tables. > Also factor out HashtableEntry freelist allocation to allow implementors an > easier route for providing their own memory management. > > Introducing the new intermediary superclass requires some calls to superclass > functions to be qualified using the "this->" syntax due to the C++ template > name lookup rules. > > a comment about hashtable.cpp RehashableHashtable::dump_table: > > - int bucket_bytes = (int)num_buckets * sizeof(bucket(0)); > + int bucket_bytes = (int)num_buckets * sizeof(HashtableBucket); > > I decided to change the sizeof to count the size of the hashtable bucket class > instead of the HashtableEntry* returned by bucket(0), even though they may be > of the same size currently. > > Note that the webrev url refers to another bug. > Webrev: http://cr.openjdk.java.net/~mgerdin/8048268/hashtable-refactor/webrev/ > Buglink: https://bugs.openjdk.java.net/browse/JDK-8056084 > > Testing: JPRT. > From mikael.gerdin at oracle.com Thu Aug 28 11:20:36 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 28 Aug 2014 13:20:36 +0200 Subject: RFR 8056084: Refactor Hashtable to allow implementations without rehashing support In-Reply-To: <53FF09C7.9050003@oracle.com> References: <2174664.Dc28FTrABg@mgerdin03> <53FF09C7.9050003@oracle.com> Message-ID: <53FF1084.3010207@oracle.com> Hi Bengt, On 08/28/2014 12:51 PM, Bengt Rutisson wrote: > > Hi Mikael, > > Looks good. > > One very minor nit if you feel like it. > > hashtable.cpp > 50 if (_free_list) { > > Would you mind changing to "if (_free_list != NULL) {" ? I know it is > not your code, but you are changing code in that method and did take me > some extra brain cycles to realize that _free_list was not a bool > indicating whether we were using a free list or not. That seems like a good suggestion. The HotSpot style also explicitly mentions that using pointers as booleans should be avoided. New webrev at: http://cr.openjdk.java.net/~mgerdin/8048268/hashtable-refactor/webrev.1/ /Mikael > > Thanks, > Bengt > > > On 2014-08-26 17:26, Mikael Gerdin wrote: >> Hi all, >> >> For JDK-8048268 I need to do some refactoring of the Hashtable class >> template. >> >> From the bug description: >> In order to simplify usage of the Hashtable class the code to >> perform >> rehashing of the SymbolTable and StringTable should be factored out to an >> intermediate class common to those two tables. >> Also factor out HashtableEntry freelist allocation to allow >> implementors an >> easier route for providing their own memory management. >> >> Introducing the new intermediary superclass requires some calls to >> superclass >> functions to be qualified using the "this->" syntax due to the C++ >> template >> name lookup rules. >> >> a comment about hashtable.cpp RehashableHashtable::dump_table: >> >> - int bucket_bytes = (int)num_buckets * sizeof(bucket(0)); >> + int bucket_bytes = (int)num_buckets * sizeof(HashtableBucket); >> >> I decided to change the sizeof to count the size of the hashtable >> bucket class >> instead of the HashtableEntry* returned by bucket(0), even though they >> may be >> of the same size currently. >> >> Note that the webrev url refers to another bug. >> Webrev: >> http://cr.openjdk.java.net/~mgerdin/8048268/hashtable-refactor/webrev/ >> Buglink: https://bugs.openjdk.java.net/browse/JDK-8056084 >> >> Testing: JPRT. >> > From bengt.rutisson at oracle.com Thu Aug 28 11:20:01 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 28 Aug 2014 13:20:01 +0200 Subject: RFR 8056084: Refactor Hashtable to allow implementations without rehashing support In-Reply-To: <53FF1084.3010207@oracle.com> References: <2174664.Dc28FTrABg@mgerdin03> <53FF09C7.9050003@oracle.com> <53FF1084.3010207@oracle.com> Message-ID: <53FF1061.1030207@oracle.com> Hi Mikael, On 2014-08-28 13:20, Mikael Gerdin wrote: > Hi Bengt, > > On 08/28/2014 12:51 PM, Bengt Rutisson wrote: >> >> Hi Mikael, >> >> Looks good. >> >> One very minor nit if you feel like it. >> >> hashtable.cpp >> 50 if (_free_list) { >> >> Would you mind changing to "if (_free_list != NULL) {" ? I know it is >> not your code, but you are changing code in that method and did take me >> some extra brain cycles to realize that _free_list was not a bool >> indicating whether we were using a free list or not. > > That seems like a good suggestion. The HotSpot style also explicitly > mentions that using pointers as booleans should be avoided. > > New webrev at: > http://cr.openjdk.java.net/~mgerdin/8048268/hashtable-refactor/webrev.1/ Great! Thanks! Reviewed. Bengt > > /Mikael > >> >> Thanks, >> Bengt >> >> >> On 2014-08-26 17:26, Mikael Gerdin wrote: >>> Hi all, >>> >>> For JDK-8048268 I need to do some refactoring of the Hashtable class >>> template. >>> >>> From the bug description: >>> In order to simplify usage of the Hashtable class the code to >>> perform >>> rehashing of the SymbolTable and StringTable should be factored out >>> to an >>> intermediate class common to those two tables. >>> Also factor out HashtableEntry freelist allocation to allow >>> implementors an >>> easier route for providing their own memory management. >>> >>> Introducing the new intermediary superclass requires some calls to >>> superclass >>> functions to be qualified using the "this->" syntax due to the C++ >>> template >>> name lookup rules. >>> >>> a comment about hashtable.cpp RehashableHashtable::dump_table: >>> >>> - int bucket_bytes = (int)num_buckets * sizeof(bucket(0)); >>> + int bucket_bytes = (int)num_buckets * sizeof(HashtableBucket); >>> >>> I decided to change the sizeof to count the size of the hashtable >>> bucket class >>> instead of the HashtableEntry* returned by bucket(0), even though they >>> may be >>> of the same size currently. >>> >>> Note that the webrev url refers to another bug. >>> Webrev: >>> http://cr.openjdk.java.net/~mgerdin/8048268/hashtable-refactor/webrev/ >>> Buglink: https://bugs.openjdk.java.net/browse/JDK-8056084 >>> >>> Testing: JPRT. >>> >> > From bengt.rutisson at oracle.com Thu Aug 28 11:36:35 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 28 Aug 2014 13:36:35 +0200 Subject: RFR 8056039: Hotspot does not compile with clang 3.4 on Linux In-Reply-To: <1593876.cxpFjnnrsK@mgerdin03> References: <1593876.cxpFjnnrsK@mgerdin03> Message-ID: <53FF1443.4000600@oracle.com> Hi Mikael, Looks good. Bengt On 2014-08-26 12:17, Mikael Gerdin wrote: > Hi all, > > In order to get clang's (sometimes) more helpful error messages when compiling > I'd like to fix the few remaining places where clang fails to compile Hotspot. > > The culprit in this case was "local_vsnprintf" in os_linux.cpp, an unused > function which wasn't annotaded with the PRINTF_FORMAT macro. > Since the function was unused I decided to remove it instead, then I found it > in the other os_*nix.cpp files as well. > > Digging into the Teamware history it looks like it first appeared in the > Solaris port because vsnprintf did not exist on some very old versions of > Solaris, so it was dynamically looked up through dlsym. For a few years > vsnprintf has been present in the Solaris header files, so I think it's safe > to remove the workaround now some 17 years later. > > I also need a SCANF_FORMAT for an internal file, so I added that to > globalDefinitions. > > Webrev: http://cr.openjdk.java.net/~mgerdin/8056039/webrev/ > Buglink: https://bugs.openjdk.java.net/browse/JDK-8056039 > > Thanks > /Mikael > > From tobias.hartmann at oracle.com Thu Aug 28 12:09:26 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 28 Aug 2014 14:09:26 +0200 Subject: [9] RFR (L): 8015774: Add support for multiple code heaps Message-ID: <53FF1BF6.8070600@oracle.com> Hi, the segmented code cache JEP is now targeted. Please review the final implementation before integration. The previous RFR, including a short description, can be found here [1]. JEP: https://bugs.openjdk.java.net/browse/JDK-8043304 Bug: https://bugs.openjdk.java.net/browse/JDK-8015774 Implementation: http://cr.openjdk.java.net/~thartmann/8015774/webrev.03/ JDK-Test fix: http://cr.openjdk.java.net/~thartmann/8015774_jdk_test/webrev.00/ Changes since the last review: - Merged with other changes (for example, G1 class unloading changes [2]) - Fixed some minor bugs that showed up during testing - Refactoring of 'NMethodIterator' and CodeCache implementation - Non-method CodeHeap size increased to 5 MB - Fallback solution: Store non-method code in the non-profiled code heap if there is not enough space in the non-method code heap (see 'CodeCache::allocate') Additional testing: - BigApps (Weblogic, Dacapo, runThese, Kitchensink) - Compiler and GC nightlies - jtreg tests - VM (NSK) Testbase - More performance testing (results attached to the bug) Thanks, Tobias [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-April/014098.html [2] https://bugs.openjdk.java.net/browse/JDK-8049421 From tobias.hartmann at oracle.com Thu Aug 28 13:07:06 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 28 Aug 2014 15:07:06 +0200 Subject: [8u40] RFR(XS): 8055657: Test compiler/classUnloading/methodUnloading/TestMethodUnloading.java does not work with non-default GC Message-ID: <53FF297A.8050507@oracle.com> Hi, please review this 8u40 backport request. The changes were pushed on Monday. Nightly testing showed no problems. Unfortunately, the patch does not apply cleanly due to [1] which was not (yet) backported. Master bug: https://bugs.openjdk.java.net/browse/JDK-8055657 Old webrev: http://cr.openjdk.java.net/~thartmann/8055657/webrev.00/ New webrev: http://cr.openjdk.java.net/~thartmann/8055657_8u/webrev.00/ Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3ce2966392ef Thanks, Tobias [1] https://bugs.openjdk.java.net/browse/JDK-8011397 From coleen.phillimore at oracle.com Thu Aug 28 15:32:47 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 28 Aug 2014 11:32:47 -0400 Subject: RFR 8049105: Move array component mirror to instance of java/lang/Class (hotspot part 2) In-Reply-To: <53FECA4C.60307@oracle.com> References: <53FC91FC.1070700@oracle.com> <53FECA4C.60307@oracle.com> Message-ID: <53FF4B9F.1040300@oracle.com> Thanks, Mikael! On 8/28/14, 2:21 AM, Mikael Gerdin wrote: > Coleen, > > On 08/26/2014 03:56 PM, Coleen Phillimore wrote: >> Summary: This removes component mirrors from arrayKlass metadata and the >> C2 intrinsic for them. >> >> I'm sending this out to hotspot-dev so I can get someone from the >> compiler to review this (again). Chris Thalinger, you already saw this >> once, it's the same thing, but I had to hold this change until it was >> okay'd by licensees. Can you re-review? >> >> Also GC team note that Klass::oops_do() is now non-virtual. Will that >> help? > > It may. But the oops_do code is riddled with closures and indirect > calls through callbacks so I don't think it will gain us any > significant performance boost. > Too bad. Thanks for the code review. Coleen >> >> Tested with jck, nsk and jtreg tests. Also, ran refworkload with no >> difference in performance. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8049105/ > > Looks good to me too. > /Mikael > >> bug link https://bugs.openjdk.java.net/browse/JDK-8049105 >> >> Thanks, >> Coleen > From vladimir.kozlov at oracle.com Thu Aug 28 16:02:33 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 28 Aug 2014 09:02:33 -0700 Subject: [8u40] RFR(XS): 8055657: Test compiler/classUnloading/methodUnloading/TestMethodUnloading.java does not work with non-default GC In-Reply-To: <53FF297A.8050507@oracle.com> References: <53FF297A.8050507@oracle.com> Message-ID: <53FF5299.5030200@oracle.com> Looks good. Thanks, Vladimir On 8/28/14 6:07 AM, Tobias Hartmann wrote: > Hi, > > please review this 8u40 backport request. The changes were pushed on Monday. > > Nightly testing showed no problems. Unfortunately, the patch does not apply cleanly due to [1] which was not (yet) > backported. > > Master bug: https://bugs.openjdk.java.net/browse/JDK-8055657 > Old webrev: http://cr.openjdk.java.net/~thartmann/8055657/webrev.00/ > New webrev: http://cr.openjdk.java.net/~thartmann/8055657_8u/webrev.00/ > Changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3ce2966392ef > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8011397 From christian.thalinger at oracle.com Thu Aug 28 18:21:58 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 28 Aug 2014 11:21:58 -0700 Subject: RFR 8056039: Hotspot does not compile with clang 3.4 on Linux In-Reply-To: <53FF0892.6040100@oracle.com> References: <1593876.cxpFjnnrsK@mgerdin03> <53FE0E54.8000208@oracle.com> <53FF0892.6040100@oracle.com> Message-ID: On Aug 28, 2014, at 3:46 AM, Mikael Gerdin wrote: > Christian, > > On 08/27/2014 07:00 PM, Christian Thalinger wrote: >> >> On Aug 27, 2014, at 9:59 AM, Stefan Karlsson wrote: >> >>> On 27/08/14 17:57, Christian Thalinger wrote: >>>> Maybe you want to fix this one too: >>>> >>>> [#JDK-8025688] Clang: enable return type warnings on Linux - Java Bug System >>>> https://bugs.openjdk.java.net/browse/JDK-8025688 >>> >>> I've created a prototype to make sure ShouldNotReachHere(), and friends, never return. With that in place we only need a few small changes and then we can enable -Wreturn-type on Linux. The prototype uses __attribute__((noreturn)). >> >> Great, thanks! > > Since Stefan has already put some effort into 8025688, are you ok with fixing that as a separate issue? Sure. > -Wreturn-type is not specific to clang AFAIK, it's available in (and should be enabled with ) gcc as well. > > /Mikael > >> >>> >>> thanks, >>> StefanK >>> >>> >>>> >>>> On Aug 26, 2014, at 3:17 AM, Mikael Gerdin wrote: >>>> >>>>> Hi all, >>>>> >>>>> In order to get clang's (sometimes) more helpful error messages when compiling >>>>> I'd like to fix the few remaining places where clang fails to compile Hotspot. >>>>> >>>>> The culprit in this case was "local_vsnprintf" in os_linux.cpp, an unused >>>>> function which wasn't annotaded with the PRINTF_FORMAT macro. >>>>> Since the function was unused I decided to remove it instead, then I found it >>>>> in the other os_*nix.cpp files as well. >>>>> >>>>> Digging into the Teamware history it looks like it first appeared in the >>>>> Solaris port because vsnprintf did not exist on some very old versions of >>>>> Solaris, so it was dynamically looked up through dlsym. For a few years >>>>> vsnprintf has been present in the Solaris header files, so I think it's safe >>>>> to remove the workaround now some 17 years later. >>>>> >>>>> I also need a SCANF_FORMAT for an internal file, so I added that to >>>>> globalDefinitions. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~mgerdin/8056039/webrev/ >>>>> Buglink: https://bugs.openjdk.java.net/browse/JDK-8056039 >>>>> >>>>> Thanks >>>>> /Mikael >>>>> >>>>> >>> >> > From coleen.phillimore at oracle.com Thu Aug 28 20:39:12 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 28 Aug 2014 16:39:12 -0400 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53FDCD05.1080307@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> <53F52521.1080309@oracle.com> <53F54AC0.7010007@oracle.com> <53F752F9.9090908@oracle.com> <53FDCD05.1080307@oracle.com> Message-ID: <53FF9370.9090603@oracle.com> Serguei, Thank you for the code review and discussions! This led me to find a bug and here is the new webrev, but there are comments below to explain: open webrev at http://cr.openjdk.java.net/~coleenp/8055008_3/ On 8/27/14, 8:20 AM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > > src/share/vm/code/nmethod.cpp > > Nice simplification. > > > src/share/vm/memory/universe.cpp > > No comments > > > src/share/vm/oops/instanceKlass.cpp > > A minor question about two related fragments: > > 3505 // next previous version > 3506 last = pv_node; > 3507 pv_node = pv_node->previous_versions(); > 3508 version++; > > Should the version be incremented to the case 3462-3469 as at the > line 3508? > It is not a big issue as the version number is used at the RC_TRACE > line only: > 3496 method->signature()->as_C_string(), j, version)); > > Yes, I fixed that. > We still have no consensus on the following question: > Can a non-running EMCP method become running again after the flag > was cleared? > > 3487 if (!method->on_stack()) { > 3488 if (method->is_running_emcp()) { > 3489 method->set_running_emcp(false); // no breakpoints > for non-running methods > 3490 } > > Just wanted to be sure what is the current view on this. :) > Not unless there is a bug, such that we hit a safepoint with the EMCP method not in any place that MetadataOnStackMark can get to it but we have a Method* pointer to it. This situation could result in the EMCP Method* getting deallocated as well. Stefan filed a bug a while ago that Method* pointers are not safe without a methodHandle but we currently don't have any verification that they are properly handled, such as CheckUnhandledOops. > > src/share/vm/oops/instanceKlass.hpp > > No comments > > > src/share/vm/oops/method.hpp > > Just some questions. > Usefulness of this new function depends on basic ability of a > non-running method to become running again: > is_running_emcp() > > The questions are: > - How precise is the control of this bit? This bit is set during purging previous versions when all methods have been marked on_stack() if found in various places. The bit is only used for setting breakpoints. > - Should we clear this bit after all method invocations have been > finished? > - Can a EMCP method become running again after the bit was cleared > or not set? > > > src/share/vm/prims/jvmtiImpl.cpp > > 300 if (method->is_running_emcp() && > > Is it possible that an EMCP method becomes running after the bit > is_running_emcp() is set? > Do we miss breakpoints in such a case? > I do think this is only possible if there is a bug and the Method* would probably be deallocated first and crash. Since this code is called during class unloading, a crash is something I'd expect to see. So I added an additional check to find resurrected emcp methods: if (!method->on_stack()) { if (method->is_running_emcp()) { method->set_running_emcp(false); // no breakpoints for non-running methods } } else { assert (method->is_obsolete() || method->is_running_emcp(), "emcp method cannot run after emcp bit is cleared"); // RC_TRACE macro has an embedded ResourceMark RC_TRACE(0x00000200, ("purge: %s(%s): prev method @%d in version @%d is alive", Unfortunately, this assert did fire in NSK testing. And I just now found the bug and fixed it (see above webrev). We weren't walking the code cache for the first redefinition, and an emcp method was in the code cache. The methods in the code cache are not exactly running but we don't know if they could be called directly by running compiled code. This fix is to add a boolean flag to MetadataOnStackMark. I reran the consistently failing tests, nsk.quick tests, and the jtreg tests in java/lang/instrument on the fix. > > 303 RC_TRACE(0x00000800, ("%sing breakpoint in %s(%s)", > 304 meth_act == &Method::set_breakpoint ? "set" : "clear", > > The change from "sett" to "set" seems to be wrong (see the line 303): > Yes, I didn't realize that. Dan pointed this out to me also. > > src/share/vm/prims/jvmtiRedefineClasses.cpp > src/share/vm/prims/jvmtiRedefineClasses.hpp > > No comments > Thank you Serguei for the in-depth comments and pushing on these issues. I think this has improved the code tremendously. I really appreciate it! Coleen > > Thanks, > Serguei > > > On 8/22/14 7:26 AM, Coleen Phillimore wrote: >> >> Thanks Dan, Serguei and Roland for discussion on this change. The >> latest version is here: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8055008_2/ >> >> Changes from the last version (don't have the setup to do a diff >> webrev, sorry) are that I have a new flag to mark running emcp >> methods so we can set breakpoints in only those. Also, confirmed >> that we need to clean_weak_method_links in obsolete methods too. Made >> changes per review comments. Also, added more to the test so that >> all tracing in InstanceKlass comes out. Reran all tests (nsk, jck, >> jtreg, java/lang/instrument). >> >> Thanks to whoever made command line processing handle hex numbers! >> >> Thanks, >> Coleen >> >> On 8/20/14, 9:26 PM, Coleen Phillimore wrote: >>> >>> On 8/20/14, 6:45 PM, Daniel D. Daugherty wrote: >>>> On 8/20/14 2:01 PM, Coleen Phillimore wrote: >>>>> On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> >>>>>>> If an EMCP method is not running, should we save it on a >>>>>>> previous version list anyway so that we can make it obsolete if >>>>>>> it's redefined and made obsolete? >>>>>> >>>>>> I hope, Dan will catch me if I'm wrong... >>>>>> >>>>>> I think, we should not. >>>>>> An EMCP method can not be made obsolete if it is not running. >>>>>> >>>>> >>>>> >>>>> It should be this way otherwise we'd have to hang onto things >>>>> forever. >>>> >>>> An EMCP method should only be made obsolete if a RedefineClasses() or >>>> RetransformClasses() operation made it so. We should not be leveraging >>>> off the obsolete-ness attribute to solve a life-cycle problem. >>> >>> Yes, this was my error in the change. This is why I made things >>> obsolete if they were not running. I think I can't reuse this >>> flag. My latest changes add a new explicit flag (which we have >>> space for in Method*). >>>> >>>> In the pre-PGR world, we could trust GC to make a completely unused >>>> EMCP method collectible and eventually our weak reference would go >>>> away. Just because an EMCP method is not on a stack does not mean >>>> that it is not used so we need a different way to determine whether >>>> it is OK to no longer track an EMCP method. >>> >>> Our on_stack marking is supposed to look at all the places where GC >>> used to look so I think we can use on_stack to track the lifecycle >>> of EMCP methods. If the EMCP method is somewhere, we will find it! >>> >>> I'm running tests on the latest change, but am also waiting for >>> confirmation from Roland because we were only cleaning out >>> MethodData for EMCP methods and not for running obsolete methods and >>> I think we need to do that for obsolete methods also, which my >>> change does now. I think it was a bug. >>> >>> Thanks Dan for remembering all of this for me! >>> >>> Coleen >>>> >>>> >>>>> >>>>>> BTW, I'm reviewing the webrev too, but probably it'd be better to >>>>>> switch to updated webrev after it is ready. >>>>> >>>>> Yes, this is a good idea. I figured out why I made emcp methods >>>>> obsolete, and I'm fixing that as well as Dan's comments. Thanks! >>>> >>>> Cool! I'm looking forward to the next review. >>>> >>>> Dan >>>> >>>> >>>>> >>>>> Coleen >>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>> >>>> >>> >> > From christian.tornqvist at oracle.com Thu Aug 28 20:57:41 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 28 Aug 2014 16:57:41 -0400 Subject: RFR(S): 8055719 - Clean out support for old VC versions from ProjectCreator Message-ID: <070601cfc302$b59cd960$20d68c20$@oracle.com> Hi everyone, This change removes support for old VC versions from ProjectCreator. I've verified the change by building project files using VS2010 and VS2013 x86/x64, I've also diffed the generated project files before and after my change. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8055719/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8055719 Thanks, Christian From vladimir.kozlov at oracle.com Thu Aug 28 21:32:01 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 28 Aug 2014 14:32:01 -0700 Subject: [8u40] backport RFR (S) 8055069: TSX and RTM should be deprecated more strongly until hardware is corrected Message-ID: <53FF9FD1.5010100@oracle.com> 8u40 backport request. Changes were pushed week ago into jdk9, no problems were found since then. Changes are applied to 8u almost without conflicts - I had to exclude changes in TestPrintPreciseRTMLocking*.java because this file in 8u already has this code. https://bugs.openjdk.java.net/browse/JDK-8055069 http://cr.openjdk.java.net/~kvn/8055069/webrev/ http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/820608bf2902 Thanks, Vladimir From serguei.spitsyn at oracle.com Thu Aug 28 21:43:29 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 28 Aug 2014 14:43:29 -0700 Subject: RFR 8055008: Clean up code that saves the previous versions of redefined classes In-Reply-To: <53FF9370.9090603@oracle.com> References: <53EE6B22.3040107@oracle.com> <53F3C426.9080408@oracle.com> <53F3D571.7060609@oracle.com> <53F3E35B.5010205@oracle.com> <53F4C49D.4070404@oracle.com> <53F4FBDB.9080508@oracle.com> <53F4FEA5.2090606@oracle.com> <53F52521.1080309@oracle.com> <53F54AC0.7010007@oracle.com> <53F752F9.9090908@oracle.com> <53FDCD05.1080307@oracle.com> <53FF9370.9090603@oracle.com> Message-ID: <53FFA281.7050701@oracle.com> Coleen, On 8/28/14 1:39 PM, Coleen Phillimore wrote: > > Serguei, Thank you for the code review and discussions! You're always welcome! :) > > This led me to find a bug and here is the new webrev, but there are > comments below to explain: > > open webrev at http://cr.openjdk.java.net/~coleenp/8055008_3/ > > > On 8/27/14, 8:20 AM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> >> src/share/vm/code/nmethod.cpp >> >> Nice simplification. >> >> >> src/share/vm/memory/universe.cpp >> >> No comments >> >> >> src/share/vm/oops/instanceKlass.cpp >> >> A minor question about two related fragments: >> >> 3505 // next previous version >> 3506 last = pv_node; >> 3507 pv_node = pv_node->previous_versions(); >> 3508 version++; >> >> Should the version be incremented to the case 3462-3469 as at the >> line 3508? >> It is not a big issue as the version number is used at the RC_TRACE >> line only: >> 3496 method->signature()->as_C_string(), j, version)); >> >> > > Yes, I fixed that. Thanks! > >> We still have no consensus on the following question: >> Can a non-running EMCP method become running again after the flag >> was cleared? >> >> 3487 if (!method->on_stack()) { >> 3488 if (method->is_running_emcp()) { >> 3489 method->set_running_emcp(false); // no >> breakpoints for non-running methods >> 3490 } >> >> Just wanted to be sure what is the current view on this. :) >> > > Not unless there is a bug, such that we hit a safepoint with the EMCP > method not in any place that MetadataOnStackMark can get to it but we > have a Method* pointer to it. This situation could result in the EMCP > Method* getting deallocated as well. Good. Thank you for confirmation. > > Stefan filed a bug a while ago that Method* pointers are not safe > without a methodHandle but we currently don't have any verification > that they are properly handled, such as CheckUnhandledOops. > >> >> src/share/vm/oops/instanceKlass.hpp >> >> No comments >> >> >> src/share/vm/oops/method.hpp >> >> Just some questions. >> Usefulness of this new function depends on basic ability of a >> non-running method to become running again: >> is_running_emcp() >> >> The questions are: >> - How precise is the control of this bit? > > This bit is set during purging previous versions when all methods have > been marked on_stack() if found in various places. The bit is only > used for setting breakpoints. I had to ask slightly different. "How precise must be the control of this bit?" Part of this question is the question below about what happens when the method invocation is finished. I realized now that it can impact only setting breakpoints. Suppose, we did not clear the bit in time and then another breakpoint is set. The only bad thing is that this new breakpoint will be useless. But let me look at new webrev first to see if any update is needed here. > >> - Should we clear this bit after all method invocations have been >> finished? >> - Can a EMCP method become running again after the bit was cleared >> or not set? >> >> >> src/share/vm/prims/jvmtiImpl.cpp >> >> 300 if (method->is_running_emcp() && >> >> Is it possible that an EMCP method becomes running after the bit >> is_running_emcp() is set? >> Do we miss breakpoints in such a case? >> > > I do think this is only possible if there is a bug and the Method* > would probably be deallocated first and crash. Since this code is > called during class unloading, a crash is something I'd expect to see. Ok, we are in sync. :) > > So I added an additional check to find resurrected emcp methods: > > if (!method->on_stack()) { > if (method->is_running_emcp()) { > method->set_running_emcp(false); // no breakpoints for > non-running methods > } > } else { > assert (method->is_obsolete() || method->is_running_emcp(), > "emcp method cannot run after emcp bit is cleared"); > // RC_TRACE macro has an embedded ResourceMark > RC_TRACE(0x00000200, > ("purge: %s(%s): prev method @%d in version @%d is alive", > > > Unfortunately, this assert did fire in NSK testing. And I just now > found the bug and fixed it (see above webrev). We weren't walking the > code cache for the first redefinition, and an emcp method was in the > code cache. The methods in the code cache are not exactly running but > we don't know if they could be called directly by running compiled code. Wow, this is great! I'd not be surprised if this bug can manifest itself without your fix too. > This fix is to add a boolean flag to MetadataOnStackMark. I reran the > consistently failing tests, nsk.quick tests, and the jtreg tests in > java/lang/instrument on the fix. >> >> 303 RC_TRACE(0x00000800, ("%sing breakpoint in %s(%s)", >> 304 meth_act == &Method::set_breakpoint ? "set" : "clear", >> >> The change from "sett" to "set" seems to be wrong (see the line >> 303): >> > > Yes, I didn't realize that. Dan pointed this out to me also. Ok. >> >> src/share/vm/prims/jvmtiRedefineClasses.cpp >> src/share/vm/prims/jvmtiRedefineClasses.hpp >> >> No comments >> > > Thank you Serguei for the in-depth comments and pushing on these > issues. I think this has improved the code tremendously. I really > appreciate it! No problem. I'm happy it was useful. Thanks! Serguei > > Coleen >> >> Thanks, >> Serguei >> >> >> On 8/22/14 7:26 AM, Coleen Phillimore wrote: >>> >>> Thanks Dan, Serguei and Roland for discussion on this change. The >>> latest version is here: >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8055008_2/ >>> >>> Changes from the last version (don't have the setup to do a diff >>> webrev, sorry) are that I have a new flag to mark running emcp >>> methods so we can set breakpoints in only those. Also, confirmed >>> that we need to clean_weak_method_links in obsolete methods too. >>> Made changes per review comments. Also, added more to the test so >>> that all tracing in InstanceKlass comes out. Reran all tests (nsk, >>> jck, jtreg, java/lang/instrument). >>> >>> Thanks to whoever made command line processing handle hex numbers! >>> >>> Thanks, >>> Coleen >>> >>> On 8/20/14, 9:26 PM, Coleen Phillimore wrote: >>>> >>>> On 8/20/14, 6:45 PM, Daniel D. Daugherty wrote: >>>>> On 8/20/14 2:01 PM, Coleen Phillimore wrote: >>>>>> On 8/20/14, 3:49 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> >>>>>>>> If an EMCP method is not running, should we save it on a >>>>>>>> previous version list anyway so that we can make it obsolete if >>>>>>>> it's redefined and made obsolete? >>>>>>> >>>>>>> I hope, Dan will catch me if I'm wrong... >>>>>>> >>>>>>> I think, we should not. >>>>>>> An EMCP method can not be made obsolete if it is not running. >>>>>>> >>>>>> >>>>>> >>>>>> It should be this way otherwise we'd have to hang onto things >>>>>> forever. >>>>> >>>>> An EMCP method should only be made obsolete if a RedefineClasses() or >>>>> RetransformClasses() operation made it so. We should not be >>>>> leveraging >>>>> off the obsolete-ness attribute to solve a life-cycle problem. >>>> >>>> Yes, this was my error in the change. This is why I made things >>>> obsolete if they were not running. I think I can't reuse this >>>> flag. My latest changes add a new explicit flag (which we have >>>> space for in Method*). >>>>> >>>>> In the pre-PGR world, we could trust GC to make a completely unused >>>>> EMCP method collectible and eventually our weak reference would go >>>>> away. Just because an EMCP method is not on a stack does not mean >>>>> that it is not used so we need a different way to determine whether >>>>> it is OK to no longer track an EMCP method. >>>> >>>> Our on_stack marking is supposed to look at all the places where GC >>>> used to look so I think we can use on_stack to track the lifecycle >>>> of EMCP methods. If the EMCP method is somewhere, we will find it! >>>> >>>> I'm running tests on the latest change, but am also waiting for >>>> confirmation from Roland because we were only cleaning out >>>> MethodData for EMCP methods and not for running obsolete methods >>>> and I think we need to do that for obsolete methods also, which my >>>> change does now. I think it was a bug. >>>> >>>> Thanks Dan for remembering all of this for me! >>>> >>>> Coleen >>>>> >>>>> >>>>>> >>>>>>> BTW, I'm reviewing the webrev too, but probably it'd be better >>>>>>> to switch to updated webrev after it is ready. >>>>>> >>>>>> Yes, this is a good idea. I figured out why I made emcp methods >>>>>> obsolete, and I'm fixing that as well as Dan's comments. Thanks! >>>>> >>>>> Cool! I'm looking forward to the next review. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Thu Aug 28 21:56:41 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 28 Aug 2014 17:56:41 -0400 Subject: RFR 8056084: Refactor Hashtable to allow implementations without rehashing support In-Reply-To: <2174664.Dc28FTrABg@mgerdin03> References: <2174664.Dc28FTrABg@mgerdin03> Message-ID: <53FFA599.4050805@oracle.com> Mikael, Thank you for doing this. Can you remove the comments in hashtable.hpp: 34 // This is a generic hashtable, designed to be used for the symbol 35 // and string tables. also this comment is outdated so should be removed. 38 // 39 // %note: 40 // - TableEntrys are allocated in blocks to reduce the space overhead. 41 This refactoring looks good. Thanks! Coleen On 8/26/14, 11:26 AM, Mikael Gerdin wrote: > Hi all, > > For JDK-8048268 I need to do some refactoring of the Hashtable class template. > > From the bug description: > In order to simplify usage of the Hashtable class the code to perform > rehashing of the SymbolTable and StringTable should be factored out to an > intermediate class common to those two tables. > Also factor out HashtableEntry freelist allocation to allow implementors an > easier route for providing their own memory management. > > Introducing the new intermediary superclass requires some calls to superclass > functions to be qualified using the "this->" syntax due to the C++ template > name lookup rules. > > a comment about hashtable.cpp RehashableHashtable::dump_table: > > - int bucket_bytes = (int)num_buckets * sizeof(bucket(0)); > + int bucket_bytes = (int)num_buckets * sizeof(HashtableBucket); > > I decided to change the sizeof to count the size of the hashtable bucket class > instead of the HashtableEntry* returned by bucket(0), even though they may be > of the same size currently. > > Note that the webrev url refers to another bug. > Webrev: http://cr.openjdk.java.net/~mgerdin/8048268/hashtable-refactor/webrev/ > Buglink: https://bugs.openjdk.java.net/browse/JDK-8056084 > > Testing: JPRT. > From vladimir.kozlov at oracle.com Thu Aug 28 23:13:16 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 28 Aug 2014 16:13:16 -0700 Subject: [9] RFR (L): 8015774: Add support for multiple code heaps In-Reply-To: <53FF1BF6.8070600@oracle.com> References: <53FF1BF6.8070600@oracle.com> Message-ID: <53FFB78C.9060805@oracle.com> For the record, SegmentedCodeCache is enabled by default when TieredCompilation is enabled and ReservedCodeCacheSize >= 240 MB. Otherwise it is false by default. arguments.cpp - in set_tiered_flags() swap SegmentedCodeCache setting and segments size adjustment - do adjustment only if SegmentedCodeCache is enabled. Also I think each flag should be checked and adjusted separately. You may bail out (vm_exit_during_initialization) if sizes do not add up. And use Align second line: 2461 } else if ((!FLAG_IS_DEFAULT(NonMethodCodeHeapSize) || !FLAG_IS_DEFAULT(ProfiledCodeHeapSize) || !FLAG_IS_DEFAULT(NonProfiledCodeHeapSize)) 2462 && (NonMethodCodeHeapSize + NonProfiledCodeHeapSize + ProfiledCodeHeapSize) != ReservedCodeCacheSize) { codeCache.cpp - in initialize_heaps() add new methods in C1 and C2 to return buffer_size they need. Add assert(SegmentedCodeCache) to this method to show that we call it only in such case. You do adjustment only when all flags are default. But you still need to check that you have space in NonMethodCodeHeap for scratch buffers. codeCache.hpp - comment alignment: + // Creates a new heap with the given name and size, containing CodeBlobs of the given type ! static void add_heap(ReservedSpace rs, const char* name, size_t size_initial, int code_blob_type); nmethod.cpp - in new() can we mark nmethod allocation critical only when SegmentedCodeCache is enabled? Thanks, Vladimir On 8/28/14 5:09 AM, Tobias Hartmann wrote: > Hi, > > the segmented code cache JEP is now targeted. Please review the final > implementation before integration. The previous RFR, including a short > description, can be found here [1]. > > JEP: https://bugs.openjdk.java.net/browse/JDK-8043304 > Bug: https://bugs.openjdk.java.net/browse/JDK-8015774 > Implementation: http://cr.openjdk.java.net/~thartmann/8015774/webrev.03/ > JDK-Test fix: > http://cr.openjdk.java.net/~thartmann/8015774_jdk_test/webrev.00/ > > Changes since the last review: > - Merged with other changes (for example, G1 class unloading changes [2]) > - Fixed some minor bugs that showed up during testing > - Refactoring of 'NMethodIterator' and CodeCache implementation > - Non-method CodeHeap size increased to 5 MB > - Fallback solution: Store non-method code in the non-profiled code heap > if there is not enough space in the non-method code heap (see > 'CodeCache::allocate') > > Additional testing: > - BigApps (Weblogic, Dacapo, runThese, Kitchensink) > - Compiler and GC nightlies > - jtreg tests > - VM (NSK) Testbase > - More performance testing (results attached to the bug) > > Thanks, > Tobias > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-April/014098.html > > [2] https://bugs.openjdk.java.net/browse/JDK-8049421 From tobias.hartmann at oracle.com Fri Aug 29 06:58:45 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 29 Aug 2014 08:58:45 +0200 Subject: [8u40] RFR(XS): 8055657: Test compiler/classUnloading/methodUnloading/TestMethodUnloading.java does not work with non-default GC In-Reply-To: <53FF5299.5030200@oracle.com> References: <53FF297A.8050507@oracle.com> <53FF5299.5030200@oracle.com> Message-ID: <540024A5.2070206@oracle.com> Thank you, Vladimir. Best, Tobias On 28.08.2014 18:02, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 8/28/14 6:07 AM, Tobias Hartmann wrote: >> Hi, >> >> please review this 8u40 backport request. The changes were pushed on >> Monday. >> >> Nightly testing showed no problems. Unfortunately, the patch does not >> apply cleanly due to [1] which was not (yet) >> backported. >> >> Master bug: https://bugs.openjdk.java.net/browse/JDK-8055657 >> Old webrev: http://cr.openjdk.java.net/~thartmann/8055657/webrev.00/ >> New webrev: http://cr.openjdk.java.net/~thartmann/8055657_8u/webrev.00/ >> Changeset: >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3ce2966392ef >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8011397 From mikael.gerdin at oracle.com Fri Aug 29 07:06:49 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 29 Aug 2014 09:06:49 +0200 Subject: RFR 8056084: Refactor Hashtable to allow implementations without rehashing support In-Reply-To: <53FFA599.4050805@oracle.com> References: <2174664.Dc28FTrABg@mgerdin03> <53FFA599.4050805@oracle.com> Message-ID: <54002689.4070002@oracle.com> Coleen, On 2014-08-28 23:56, Coleen Phillimore wrote: > > Mikael, Thank you for doing this. > > Can you remove the comments in hashtable.hpp: > > 34 // This is a generic hashtable, designed to be used for the symbol > 35 // and string tables. Will do. > > also this comment is outdated so should be removed. > > 38 // > 39 // %note: > 40 // - TableEntrys are allocated in blocks to reduce the space > overhead. > 41 That comment is still correct for callers of BasicHashtableEntry* BasicHashtable::new_entry > > This refactoring looks good. Thanks /Mikael > > Thanks! > Coleen > > > On 8/26/14, 11:26 AM, Mikael Gerdin wrote: >> Hi all, >> >> For JDK-8048268 I need to do some refactoring of the Hashtable class >> template. >> >> From the bug description: >> In order to simplify usage of the Hashtable class the code to >> perform >> rehashing of the SymbolTable and StringTable should be factored out to an >> intermediate class common to those two tables. >> Also factor out HashtableEntry freelist allocation to allow >> implementors an >> easier route for providing their own memory management. >> >> Introducing the new intermediary superclass requires some calls to >> superclass >> functions to be qualified using the "this->" syntax due to the C++ >> template >> name lookup rules. >> >> a comment about hashtable.cpp RehashableHashtable::dump_table: >> >> - int bucket_bytes = (int)num_buckets * sizeof(bucket(0)); >> + int bucket_bytes = (int)num_buckets * sizeof(HashtableBucket); >> >> I decided to change the sizeof to count the size of the hashtable >> bucket class >> instead of the HashtableEntry* returned by bucket(0), even though they >> may be >> of the same size currently. >> >> Note that the webrev url refers to another bug. >> Webrev: >> http://cr.openjdk.java.net/~mgerdin/8048268/hashtable-refactor/webrev/ >> Buglink: https://bugs.openjdk.java.net/browse/JDK-8056084 >> >> Testing: JPRT. >> > From mikael.gerdin at oracle.com Fri Aug 29 11:17:44 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 29 Aug 2014 13:17:44 +0200 Subject: RFR 8056084: Refactor Hashtable to allow implementations without rehashing support In-Reply-To: <54002689.4070002@oracle.com> References: <2174664.Dc28FTrABg@mgerdin03> <53FFA599.4050805@oracle.com> <54002689.4070002@oracle.com> Message-ID: <54006158.7090503@oracle.com> Coleen, On 2014-08-29 09:06, Mikael Gerdin wrote: > Coleen, > > On 2014-08-28 23:56, Coleen Phillimore wrote: >> >> Mikael, Thank you for doing this. >> >> Can you remove the comments in hashtable.hpp: >> >> 34 // This is a generic hashtable, designed to be used for the symbol >> 35 // and string tables. > > Will do. > >> >> also this comment is outdated so should be removed. >> >> 38 // >> 39 // %note: >> 40 // - TableEntrys are allocated in blocks to reduce the space >> overhead. >> 41 > > That comment is still correct for callers of > BasicHashtableEntry* BasicHashtable::new_entry I changed it to: +// HashtableEntrys are allocated in blocks to reduce the space overhead. +template BasicHashtableEntry* BasicHashtable::new_entry(unsigned int hashValue) { + BasicHashtableEntry* entry = new_entry_free_list(); + Is that ok? /Mikael > > >> >> This refactoring looks good. > > Thanks > /Mikael > >> >> Thanks! >> Coleen >> >> >> On 8/26/14, 11:26 AM, Mikael Gerdin wrote: >>> Hi all, >>> >>> For JDK-8048268 I need to do some refactoring of the Hashtable class >>> template. >>> >>> From the bug description: >>> In order to simplify usage of the Hashtable class the code to >>> perform >>> rehashing of the SymbolTable and StringTable should be factored out >>> to an >>> intermediate class common to those two tables. >>> Also factor out HashtableEntry freelist allocation to allow >>> implementors an >>> easier route for providing their own memory management. >>> >>> Introducing the new intermediary superclass requires some calls to >>> superclass >>> functions to be qualified using the "this->" syntax due to the C++ >>> template >>> name lookup rules. >>> >>> a comment about hashtable.cpp RehashableHashtable::dump_table: >>> >>> - int bucket_bytes = (int)num_buckets * sizeof(bucket(0)); >>> + int bucket_bytes = (int)num_buckets * sizeof(HashtableBucket); >>> >>> I decided to change the sizeof to count the size of the hashtable >>> bucket class >>> instead of the HashtableEntry* returned by bucket(0), even though they >>> may be >>> of the same size currently. >>> >>> Note that the webrev url refers to another bug. >>> Webrev: >>> http://cr.openjdk.java.net/~mgerdin/8048268/hashtable-refactor/webrev/ >>> Buglink: https://bugs.openjdk.java.net/browse/JDK-8056084 >>> >>> Testing: JPRT. >>> >> From thomas.schatzl at oracle.com Fri Aug 29 11:59:53 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 29 Aug 2014 13:59:53 +0200 Subject: RFR 8056084: Refactor Hashtable to allow implementations without rehashing support In-Reply-To: <53FF1061.1030207@oracle.com> References: <2174664.Dc28FTrABg@mgerdin03> <53FF09C7.9050003@oracle.com> <53FF1084.3010207@oracle.com> <53FF1061.1030207@oracle.com> Message-ID: <1409313593.2663.33.camel@cirrus> Hi Mikael, On Thu, 2014-08-28 at 13:20 +0200, Bengt Rutisson wrote: > Hi Mikael, > > >> One very minor nit if you feel like it. > >> > >> hashtable.cpp > >> 50 if (_free_list) { > >> > >> Would you mind changing to "if (_free_list != NULL) {" ? I know it is > >> not your code, but you are changing code in that method and did take me > >> some extra brain cycles to realize that _free_list was not a bool > >> indicating whether we were using a free list or not. > > > > That seems like a good suggestion. The HotSpot style also explicitly > > mentions that using pointers as booleans should be avoided. > > > > New webrev at: > > http://cr.openjdk.java.net/~mgerdin/8048268/hashtable-refactor/webrev.1/ > Looks good to me. Thomas From erik.gahlin at oracle.com Fri Aug 29 13:36:09 2014 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Fri, 29 Aug 2014 15:36:09 +0200 Subject: [9] RFR (L): 8015774: Add support for multiple code heaps In-Reply-To: <53FF1BF6.8070600@oracle.com> References: <53FF1BF6.8070600@oracle.com> Message-ID: <540081C9.7020307@oracle.com> Only looked at event tracing metadata, but trace.xml and tracetypes.xml looks good /Erik Tobias Hartmann skrev 2014-08-28 14:09: > Hi, > > the segmented code cache JEP is now targeted. Please review the final > implementation before integration. The previous RFR, including a short > description, can be found here [1]. > > JEP: https://bugs.openjdk.java.net/browse/JDK-8043304 > Bug: https://bugs.openjdk.java.net/browse/JDK-8015774 > Implementation: http://cr.openjdk.java.net/~thartmann/8015774/webrev.03/ > JDK-Test fix: > http://cr.openjdk.java.net/~thartmann/8015774_jdk_test/webrev.00/ > > Changes since the last review: > - Merged with other changes (for example, G1 class unloading changes [2]) > - Fixed some minor bugs that showed up during testing > - Refactoring of 'NMethodIterator' and CodeCache implementation > - Non-method CodeHeap size increased to 5 MB > - Fallback solution: Store non-method code in the non-profiled code > heap if there is not enough space in the non-method code heap (see > 'CodeCache::allocate') > > Additional testing: > - BigApps (Weblogic, Dacapo, runThese, Kitchensink) > - Compiler and GC nightlies > - jtreg tests > - VM (NSK) Testbase > - More performance testing (results attached to the bug) > > Thanks, > Tobias > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-April/014098.html > [2] https://bugs.openjdk.java.net/browse/JDK-8049421 From coleen.phillimore at oracle.com Fri Aug 29 13:55:45 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 29 Aug 2014 09:55:45 -0400 Subject: RFR 8056084: Refactor Hashtable to allow implementations without rehashing support In-Reply-To: <54006158.7090503@oracle.com> References: <2174664.Dc28FTrABg@mgerdin03> <53FFA599.4050805@oracle.com> <54002689.4070002@oracle.com> <54006158.7090503@oracle.com> Message-ID: <54008661.4020305@oracle.com> Yes, your new comment is fine. Coleen On 8/29/14, 7:17 AM, Mikael Gerdin wrote: > Coleen, > > On 2014-08-29 09:06, Mikael Gerdin wrote: >> Coleen, >> >> On 2014-08-28 23:56, Coleen Phillimore wrote: >>> >>> Mikael, Thank you for doing this. >>> >>> Can you remove the comments in hashtable.hpp: >>> >>> 34 // This is a generic hashtable, designed to be used for the >>> symbol >>> 35 // and string tables. >> >> Will do. >> >>> >>> also this comment is outdated so should be removed. >>> >>> 38 // >>> 39 // %note: >>> 40 // - TableEntrys are allocated in blocks to reduce the space >>> overhead. >>> 41 >> >> That comment is still correct for callers of >> BasicHashtableEntry* BasicHashtable::new_entry > > I changed it to: > +// HashtableEntrys are allocated in blocks to reduce the space overhead. > +template BasicHashtableEntry* > BasicHashtable::new_entry(unsigned int hashValue) { > + BasicHashtableEntry* entry = new_entry_free_list(); > + > > Is that ok? > > /Mikael > >> >> >>> >>> This refactoring looks good. >> >> Thanks >> /Mikael >> >>> >>> Thanks! >>> Coleen >>> >>> >>> On 8/26/14, 11:26 AM, Mikael Gerdin wrote: >>>> Hi all, >>>> >>>> For JDK-8048268 I need to do some refactoring of the Hashtable class >>>> template. >>>> >>>> From the bug description: >>>> In order to simplify usage of the Hashtable class the code to >>>> perform >>>> rehashing of the SymbolTable and StringTable should be factored out >>>> to an >>>> intermediate class common to those two tables. >>>> Also factor out HashtableEntry freelist allocation to allow >>>> implementors an >>>> easier route for providing their own memory management. >>>> >>>> Introducing the new intermediary superclass requires some calls to >>>> superclass >>>> functions to be qualified using the "this->" syntax due to the C++ >>>> template >>>> name lookup rules. >>>> >>>> a comment about hashtable.cpp RehashableHashtable::dump_table: >>>> >>>> - int bucket_bytes = (int)num_buckets * sizeof(bucket(0)); >>>> + int bucket_bytes = (int)num_buckets * sizeof(HashtableBucket); >>>> >>>> I decided to change the sizeof to count the size of the hashtable >>>> bucket class >>>> instead of the HashtableEntry* returned by bucket(0), even though they >>>> may be >>>> of the same size currently. >>>> >>>> Note that the webrev url refers to another bug. >>>> Webrev: >>>> http://cr.openjdk.java.net/~mgerdin/8048268/hashtable-refactor/webrev/ >>>> Buglink: https://bugs.openjdk.java.net/browse/JDK-8056084 >>>> >>>> Testing: JPRT. >>>> >>> From tobias.hartmann at oracle.com Fri Aug 29 14:10:25 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 29 Aug 2014 16:10:25 +0200 Subject: [9] RFR (L): 8015774: Add support for multiple code heaps In-Reply-To: <53FFB78C.9060805@oracle.com> References: <53FF1BF6.8070600@oracle.com> <53FFB78C.9060805@oracle.com> Message-ID: <540089D1.4060600@oracle.com> Hi Vladimir, thanks for the review. On 29.08.2014 01:13, Vladimir Kozlov wrote: > For the record, SegmentedCodeCache is enabled by default when > TieredCompilation is enabled and ReservedCodeCacheSize >= 240 MB. > Otherwise it is false by default. Exactly. > arguments.cpp - in set_tiered_flags() swap SegmentedCodeCache setting > and segments size adjustment - do adjustment only if > SegmentedCodeCache is enabled. Done. > Also I think each flag should be checked and adjusted separately. You > may bail out (vm_exit_during_initialization) if sizes do not add up. I think we should only increase the sizes if they are all default. Otherwise we would for example fail if the user sets the NonMethodCodeHeapSize and the ProfiledCodeHeapSize because the NonProfiledCodeHeap size is multiplied by 5. What do you think? > And use I think the rest of this sentence is missing :) > Align second line: > > 2461 } else if ((!FLAG_IS_DEFAULT(NonMethodCodeHeapSize) || > !FLAG_IS_DEFAULT(ProfiledCodeHeapSize) || > !FLAG_IS_DEFAULT(NonProfiledCodeHeapSize)) > 2462 && (NonMethodCodeHeapSize + NonProfiledCodeHeapSize + > ProfiledCodeHeapSize) != ReservedCodeCacheSize) { Done. > codeCache.cpp - in initialize_heaps() add new methods in C1 and C2 to > return buffer_size they need. Add assert(SegmentedCodeCache) to this > method to show that we call it only in such case. Done. > You do adjustment only when all flags are default. But you still need > to check that you have space in NonMethodCodeHeap for scratch buffers. I added a the following check: // Make sure we have enough space for the code buffers if (NonMethodCodeHeapSize < code_buffers_size) { vm_exit_during_initialization("Not enough space for code buffers in CodeCache"); } > codeCache.hpp - comment alignment: > + // Creates a new heap with the given name and size, containing > CodeBlobs of the given type > ! static void add_heap(ReservedSpace rs, const char* name, size_t > size_initial, int code_blob_type); Done. > nmethod.cpp - in new() can we mark nmethod allocation critical only > when SegmentedCodeCache is enabled? Yes, that's what we do with: 809 bool is_critical = SegmentedCodeCache; Or what are you referring to? New webrev: http://cr.openjdk.java.net/~thartmann/8015774/webrev.04 Thanks, Tobias > Thanks, > Vladimir > > On 8/28/14 5:09 AM, Tobias Hartmann wrote: >> Hi, >> >> the segmented code cache JEP is now targeted. Please review the final >> implementation before integration. The previous RFR, including a short >> description, can be found here [1]. >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8043304 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8015774 >> Implementation: http://cr.openjdk.java.net/~thartmann/8015774/webrev.03/ >> JDK-Test fix: >> http://cr.openjdk.java.net/~thartmann/8015774_jdk_test/webrev.00/ >> >> Changes since the last review: >> - Merged with other changes (for example, G1 class unloading changes >> [2]) >> - Fixed some minor bugs that showed up during testing >> - Refactoring of 'NMethodIterator' and CodeCache implementation >> - Non-method CodeHeap size increased to 5 MB >> - Fallback solution: Store non-method code in the non-profiled code heap >> if there is not enough space in the non-method code heap (see >> 'CodeCache::allocate') >> >> Additional testing: >> - BigApps (Weblogic, Dacapo, runThese, Kitchensink) >> - Compiler and GC nightlies >> - jtreg tests >> - VM (NSK) Testbase >> - More performance testing (results attached to the bug) >> >> Thanks, >> Tobias >> >> [1] >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-April/014098.html >> >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8049421 From tobias.hartmann at oracle.com Fri Aug 29 14:11:42 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 29 Aug 2014 16:11:42 +0200 Subject: [9] RFR (L): 8015774: Add support for multiple code heaps In-Reply-To: <540081C9.7020307@oracle.com> References: <53FF1BF6.8070600@oracle.com> <540081C9.7020307@oracle.com> Message-ID: <54008A1E.3000105@oracle.com> Thank you, Erik. Best, Tobias On 29.08.2014 15:36, Erik Gahlin wrote: > Only looked at event tracing metadata, but trace.xml and > tracetypes.xml looks good > > /Erik > > Tobias Hartmann skrev 2014-08-28 14:09: >> Hi, >> >> the segmented code cache JEP is now targeted. Please review the final >> implementation before integration. The previous RFR, including a >> short description, can be found here [1]. >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8043304 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8015774 >> Implementation: http://cr.openjdk.java.net/~thartmann/8015774/webrev.03/ >> JDK-Test fix: >> http://cr.openjdk.java.net/~thartmann/8015774_jdk_test/webrev.00/ >> >> Changes since the last review: >> - Merged with other changes (for example, G1 class unloading changes >> [2]) >> - Fixed some minor bugs that showed up during testing >> - Refactoring of 'NMethodIterator' and CodeCache implementation >> - Non-method CodeHeap size increased to 5 MB >> - Fallback solution: Store non-method code in the non-profiled code >> heap if there is not enough space in the non-method code heap (see >> 'CodeCache::allocate') >> >> Additional testing: >> - BigApps (Weblogic, Dacapo, runThese, Kitchensink) >> - Compiler and GC nightlies >> - jtreg tests >> - VM (NSK) Testbase >> - More performance testing (results attached to the bug) >> >> Thanks, >> Tobias >> >> [1] >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-April/014098.html >> [2] https://bugs.openjdk.java.net/browse/JDK-8049421 > From mikael.gerdin at oracle.com Fri Aug 29 14:16:28 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 29 Aug 2014 16:16:28 +0200 Subject: RFR 8056084: Refactor Hashtable to allow implementations without rehashing support In-Reply-To: <54008661.4020305@oracle.com> References: <2174664.Dc28FTrABg@mgerdin03> <53FFA599.4050805@oracle.com> <54002689.4070002@oracle.com> <54006158.7090503@oracle.com> <54008661.4020305@oracle.com> Message-ID: <54008B3C.6010807@oracle.com> Thanks everyone for the reviews! /Mikael On 2014-08-29 15:55, Coleen Phillimore wrote: > > > Yes, your new comment is fine. > Coleen > > On 8/29/14, 7:17 AM, Mikael Gerdin wrote: >> Coleen, >> >> On 2014-08-29 09:06, Mikael Gerdin wrote: >>> Coleen, >>> >>> On 2014-08-28 23:56, Coleen Phillimore wrote: >>>> >>>> Mikael, Thank you for doing this. >>>> >>>> Can you remove the comments in hashtable.hpp: >>>> >>>> 34 // This is a generic hashtable, designed to be used for the >>>> symbol >>>> 35 // and string tables. >>> >>> Will do. >>> >>>> >>>> also this comment is outdated so should be removed. >>>> >>>> 38 // >>>> 39 // %note: >>>> 40 // - TableEntrys are allocated in blocks to reduce the space >>>> overhead. >>>> 41 >>> >>> That comment is still correct for callers of >>> BasicHashtableEntry* BasicHashtable::new_entry >> >> I changed it to: >> +// HashtableEntrys are allocated in blocks to reduce the space overhead. >> +template BasicHashtableEntry* >> BasicHashtable::new_entry(unsigned int hashValue) { >> + BasicHashtableEntry* entry = new_entry_free_list(); >> + >> >> Is that ok? >> >> /Mikael >> >>> >>> >>>> >>>> This refactoring looks good. >>> >>> Thanks >>> /Mikael >>> >>>> >>>> Thanks! >>>> Coleen >>>> >>>> >>>> On 8/26/14, 11:26 AM, Mikael Gerdin wrote: >>>>> Hi all, >>>>> >>>>> For JDK-8048268 I need to do some refactoring of the Hashtable class >>>>> template. >>>>> >>>>> From the bug description: >>>>> In order to simplify usage of the Hashtable class the code to >>>>> perform >>>>> rehashing of the SymbolTable and StringTable should be factored out >>>>> to an >>>>> intermediate class common to those two tables. >>>>> Also factor out HashtableEntry freelist allocation to allow >>>>> implementors an >>>>> easier route for providing their own memory management. >>>>> >>>>> Introducing the new intermediary superclass requires some calls to >>>>> superclass >>>>> functions to be qualified using the "this->" syntax due to the C++ >>>>> template >>>>> name lookup rules. >>>>> >>>>> a comment about hashtable.cpp RehashableHashtable::dump_table: >>>>> >>>>> - int bucket_bytes = (int)num_buckets * sizeof(bucket(0)); >>>>> + int bucket_bytes = (int)num_buckets * sizeof(HashtableBucket); >>>>> >>>>> I decided to change the sizeof to count the size of the hashtable >>>>> bucket class >>>>> instead of the HashtableEntry* returned by bucket(0), even though they >>>>> may be >>>>> of the same size currently. >>>>> >>>>> Note that the webrev url refers to another bug. >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mgerdin/8048268/hashtable-refactor/webrev/ >>>>> Buglink: https://bugs.openjdk.java.net/browse/JDK-8056084 >>>>> >>>>> Testing: JPRT. >>>>> >>>> > From vladimir.kozlov at oracle.com Fri Aug 29 17:33:41 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Aug 2014 10:33:41 -0700 Subject: [9] RFR (L): 8015774: Add support for multiple code heaps In-Reply-To: <540089D1.4060600@oracle.com> References: <53FF1BF6.8070600@oracle.com> <53FFB78C.9060805@oracle.com> <540089D1.4060600@oracle.com> Message-ID: <5400B975.5030703@oracle.com> On 8/29/14 7:10 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review. > > On 29.08.2014 01:13, Vladimir Kozlov wrote: >> For the record, SegmentedCodeCache is enabled by default when TieredCompilation is enabled and ReservedCodeCacheSize >> >= 240 MB. Otherwise it is false by default. > > Exactly. > >> arguments.cpp - in set_tiered_flags() swap SegmentedCodeCache setting and segments size adjustment - do adjustment >> only if SegmentedCodeCache is enabled. > > Done. > >> Also I think each flag should be checked and adjusted separately. You may bail out (vm_exit_during_initialization) if >> sizes do not add up. > > I think we should only increase the sizes if they are all default. Otherwise we would for example fail if the user sets > the NonMethodCodeHeapSize and the ProfiledCodeHeapSize because the NonProfiledCodeHeap size is multiplied by 5. What do > you think? But ReservedCodeCacheSize is scaled anyway and you will get sum of sizes != whole size. We need to do something. BTW the error message for next check should print all sizes, user may not know the default value of some which he did not specified on command line. (NonMethodCodeHeapSize + NonProfiledCodeHeapSize + ProfiledCodeHeapSize) != ReservedCodeCacheSize) > >> And use > > I think the rest of this sentence is missing :) And use FLAG_SET_ERGO() when you scale. :) > >> Align second line: >> >> 2461 } else if ((!FLAG_IS_DEFAULT(NonMethodCodeHeapSize) || !FLAG_IS_DEFAULT(ProfiledCodeHeapSize) || >> !FLAG_IS_DEFAULT(NonProfiledCodeHeapSize)) >> 2462 && (NonMethodCodeHeapSize + NonProfiledCodeHeapSize + ProfiledCodeHeapSize) != ReservedCodeCacheSize) { > > Done. > >> codeCache.cpp - in initialize_heaps() add new methods in C1 and C2 to return buffer_size they need. Add >> assert(SegmentedCodeCache) to this method to show that we call it only in such case. > > Done. > >> You do adjustment only when all flags are default. But you still need to check that you have space in >> NonMethodCodeHeap for scratch buffers. > > I added a the following check: > > // Make sure we have enough space for the code buffers > if (NonMethodCodeHeapSize < code_buffers_size) { > vm_exit_during_initialization("Not enough space for code buffers in CodeCache"); > } I think, you need to take into account min_code_cache_size as in arguments.cpp: uint min_code_cache_size = (CodeCacheMinimumUseSpace DEBUG_ONLY(* 3)) + CodeCacheMinimumFreeSpace; if (NonMethodCodeHeapSize < (min_code_cache_size+code_buffers_size)) { I would be nice if this code in initialize_heaps() could be moved called during arguments parsing if we could get number of compiler threads there. But I understand that we can't do that until compilation policy is set :( > >> codeCache.hpp - comment alignment: >> + // Creates a new heap with the given name and size, containing CodeBlobs of the given type >> ! static void add_heap(ReservedSpace rs, const char* name, size_t size_initial, int code_blob_type); > > Done. > >> nmethod.cpp - in new() can we mark nmethod allocation critical only when SegmentedCodeCache is enabled? > > Yes, that's what we do with: > > 809 bool is_critical = SegmentedCodeCache; > > Or what are you referring to? Somehow I missed that SegmentedCodeCache is used already. It is fine then. Thanks, Vladimir > > New webrev: http://cr.openjdk.java.net/~thartmann/8015774/webrev.04 > > Thanks, > Tobias > >> Thanks, >> Vladimir >> >> On 8/28/14 5:09 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> the segmented code cache JEP is now targeted. Please review the final >>> implementation before integration. The previous RFR, including a short >>> description, can be found here [1]. >>> >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8043304 >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8015774 >>> Implementation: http://cr.openjdk.java.net/~thartmann/8015774/webrev.03/ >>> JDK-Test fix: >>> http://cr.openjdk.java.net/~thartmann/8015774_jdk_test/webrev.00/ >>> >>> Changes since the last review: >>> - Merged with other changes (for example, G1 class unloading changes [2]) >>> - Fixed some minor bugs that showed up during testing >>> - Refactoring of 'NMethodIterator' and CodeCache implementation >>> - Non-method CodeHeap size increased to 5 MB >>> - Fallback solution: Store non-method code in the non-profiled code heap >>> if there is not enough space in the non-method code heap (see >>> 'CodeCache::allocate') >>> >>> Additional testing: >>> - BigApps (Weblogic, Dacapo, runThese, Kitchensink) >>> - Compiler and GC nightlies >>> - jtreg tests >>> - VM (NSK) Testbase >>> - More performance testing (results attached to the bug) >>> >>> Thanks, >>> Tobias >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-April/014098.html >>> >>> [2] https://bugs.openjdk.java.net/browse/JDK-8049421 > From igor.veresov at oracle.com Fri Aug 29 22:49:06 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 29 Aug 2014 15:49:06 -0700 Subject: [8u40] backport RFR (S) 8055069: TSX and RTM should be deprecated more strongly until hardware is corrected In-Reply-To: <53FF9FD1.5010100@oracle.com> References: <53FF9FD1.5010100@oracle.com> Message-ID: Good. igor On Aug 28, 2014, at 2:32 PM, Vladimir Kozlov wrote: > 8u40 backport request. Changes were pushed week ago into jdk9, no problems were found since then. Changes are applied to 8u almost without conflicts - I had to exclude changes in TestPrintPreciseRTMLocking*.java because this file in 8u already has this code. > > https://bugs.openjdk.java.net/browse/JDK-8055069 > http://cr.openjdk.java.net/~kvn/8055069/webrev/ > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/820608bf2902 > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Fri Aug 29 22:52:01 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Aug 2014 15:52:01 -0700 Subject: [8u40] backport RFR (S) 8055069: TSX and RTM should be deprecated more strongly until hardware is corrected In-Reply-To: References: <53FF9FD1.5010100@oracle.com> Message-ID: <54010411.8040508@oracle.com> Thanks! Vladimir On 8/29/14 3:49 PM, Igor Veresov wrote: > Good. > > igor > > On Aug 28, 2014, at 2:32 PM, Vladimir Kozlov wrote: > >> 8u40 backport request. Changes were pushed week ago into jdk9, no problems were found since then. Changes are applied to 8u almost without conflicts - I had to exclude changes in TestPrintPreciseRTMLocking*.java because this file in 8u already has this code. >> >> https://bugs.openjdk.java.net/browse/JDK-8055069 >> http://cr.openjdk.java.net/~kvn/8055069/webrev/ >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/820608bf2902 >> >> Thanks, >> Vladimir > From wojciech.kudla at gmail.com Sat Aug 30 14:36:16 2014 From: wojciech.kudla at gmail.com (Wojciech Kudla) Date: Sat, 30 Aug 2014 15:36:16 +0100 Subject: Narrow oop base Message-ID: Hi, Is there any way to obtain or calculate (raw pointer to) narrow oop base at runtime without using JDI? Could /proc/sef/maps be of any use to me for this purpose? Thanks in advance for any hints. Wojtek