From aph at redhat.com Fri Apr 1 09:31:05 2011 From: aph at redhat.com (Andrew Haley) Date: Fri, 01 Apr 2011 17:31:05 +0100 Subject: PING: Linux: Support transparent hugepages Message-ID: <4D95FDC9.8070704@redhat.com> Hi all, A little while ago I posted this question about adding support for Linux's transparent hugepages to HotSpot. I'd really appreciate comments. Thanks, Andrew. -------------- next part -------------- An embedded message was scrubbed... From: Andrew Haley Subject: Linux: Support transparent hugepages Date: Tue, 11 Jan 2011 19:17:58 +0000 Size: 3414 Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110401/911f52d5/attachment.eml From igor.veresov at oracle.com Fri Apr 1 11:24:14 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 01 Apr 2011 11:24:14 -0700 Subject: PING: Linux: Support transparent hugepages In-Reply-To: <4D95FDC9.8070704@redhat.com> References: <4D95FDC9.8070704@redhat.com> Message-ID: <4D96184E.3090903@oracle.com> Why is alignment required? Afaik it's perfectly fine to have mixed page sizes in a single segment. Also, if use use +UseLargePages, all the heap and generation sizes will be largepage-alinged anyway. Also, some things like the NUMA-allocator will work better is they know kind of pages the underlying segment has. What I would've done is put some logic to distinguish kernels that support transparent large pages and instead of using all the SHM stuff just use a mmap + madvise(MADV_HUGEPAGE). On Solaris we do kind of the same thing, but there you have to do mmap + memcntl(MC_HAT_ADVISE). Although Solaris 10 also supports out-of-the-box large pages, so in theory you don't have to do anything, but I guess it's always better to hint the OS that you really want it. igor On 4/1/11 9:31 AM, Andrew Haley wrote: > Hi all, > > A little while ago I posted this question about adding support for > Linux's transparent hugepages to HotSpot. I'd really appreciate comments. > > Thanks, > Andrew. From aph at redhat.com Fri Apr 1 11:38:09 2011 From: aph at redhat.com (Andrew Haley) Date: Fri, 01 Apr 2011 19:38:09 +0100 Subject: PING: Linux: Support transparent hugepages In-Reply-To: <4D96184E.3090903@oracle.com> References: <4D95FDC9.8070704@redhat.com> <4D96184E.3090903@oracle.com> Message-ID: <4D961B91.3030507@redhat.com> On 04/01/2011 07:24 PM, Igor Veresov wrote: > Why is alignment required? Afaik it's perfectly fine to have mixed page > sizes in a single segment. Alignment is the only way to guarantee that all pages are huge pages. > Also, if use use +UseLargePages, all the heap and generation sizes > will be largepage-alinged anyway. Also, some things like the > NUMA-allocator will work better is they know kind of pages the > underlying segment has. Yes, but on Linux at least +UseLargePages (using all that SHM stuff) needs special permissions, so it tends not to be used as much as it could. > What I would've done is put some logic to distinguish kernels that > support transparent large pages and instead of using all the SHM > stuff just use a mmap + madvise(MADV_HUGEPAGE). Actually, I did! I tried both of these, and simply aligning and letting transparent hugepages do the work seemed easier. If you prefer mmap + madvise I'll submit a patch that does that instead. Both ways solve the problem of needing special permissions. > On Solaris we do kind of the > same thing, but there you have to do mmap + memcntl(MC_HAT_ADVISE). > Although Solaris 10 also supports out-of-the-box large pages, so in > theory you don't have to do anything, but I guess it's always better to > hint the OS that you really want it. OK. Andrew. From igor.veresov at oracle.com Fri Apr 1 12:01:16 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 01 Apr 2011 12:01:16 -0700 Subject: PING: Linux: Support transparent hugepages In-Reply-To: <4D961B91.3030507@redhat.com> References: <4D95FDC9.8070704@redhat.com> <4D96184E.3090903@oracle.com> <4D961B91.3030507@redhat.com> Message-ID: <4D9620FC.2030709@oracle.com> On 4/1/11 11:38 AM, Andrew Haley wrote: > On 04/01/2011 07:24 PM, Igor Veresov wrote: >> Why is alignment required? Afaik it's perfectly fine to have mixed page >> sizes in a single segment. > > Alignment is the only way to guarantee that all pages are huge pages. Right, but my point was that +UseLargePages option would do that guaranteeing alignment. > >> Also, if use use +UseLargePages, all the heap and generation sizes >> will be largepage-alinged anyway. Also, some things like the >> NUMA-allocator will work better is they know kind of pages the >> underlying segment has. > > Yes, but on Linux at least +UseLargePages (using all that SHM stuff) > needs special permissions, so it tends not to be used as much as it > could. Right, but you can choose whether to do via SHM or by just doing madvise at runtime. This way your code will nicely fit into the existing framework - you'll get automatic page size detection and hence all the requests from the runtime for memory will come properly aligned. > >> What I would've done is put some logic to distinguish kernels that >> support transparent large pages and instead of using all the SHM >> stuff just use a mmap + madvise(MADV_HUGEPAGE). > > Actually, I did! I tried both of these, and simply aligning and > letting transparent hugepages do the work seemed easier. Perhaps, but the rest of the runtime has no idea that you have large pages. So, for example, the NUMA allocator will case accumulation of small pages on the borders of per-node chunks because it would think that we're using small pages and will adapt the sizes with small page granularity, causing fragmentation. > If you > prefer mmap + madvise I'll submit a patch that does that instead. I think this would make it fit in the existing framework better. Take a look at os_solaris.cpp, it has exactly all the same problems. First there was the SHM implementation (grep for UseISM) , that is still used for ancient Solaris versions, and then there is the MPSS version, which is similar to what's now in Linux. So, basically I would like the code for both OSes look similar and follow the same logic. igor > > Both ways solve the problem of needing special permissions. > >> On Solaris we do kind of the >> same thing, but there you have to do mmap + memcntl(MC_HAT_ADVISE). >> Although Solaris 10 also supports out-of-the-box large pages, so in >> theory you don't have to do anything, but I guess it's always better to >> hint the OS that you really want it. > > OK. > > Andrew. From vladimir.kozlov at oracle.com Fri Apr 1 20:23:20 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 02 Apr 2011 03:23:20 +0000 Subject: hg: jdk7/hotspot/hotspot: 27 new changesets Message-ID: <20110402032410.49D1647701@hg.openjdk.java.net> Changeset: 151da0c145a8 Author: twisti Date: 2011-03-24 02:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/151da0c145a8 7030207: Zero tweak to remove accidentally incorporated code Summary: IcedTea contains a now-unmaintained ARM-specific interpreter and part of that interpreter was accidentally incorporated in one of the webrevs when Zero was initially imported. Reviewed-by: twisti Contributed-by: Gary Benson ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: b868d9928221 Author: twisti Date: 2011-03-24 23:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b868d9928221 Merge - test/compiler/6987555/Test6987555.java - test/compiler/6991596/Test6991596.java Changeset: f731b22cd52d Author: jcoomes Date: 2011-03-24 23:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f731b22cd52d Merge ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: 322a41ec766c Author: never Date: 2011-03-25 11:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/322a41ec766c 7025708: Assertion if using "-XX:+CITraceTypeFlow -XX:+Verbose" together Reviewed-by: never Contributed-by: volker.simonis at gmail.com ! src/share/vm/ci/ciTypeFlow.cpp Changeset: b2949bf39900 Author: never Date: 2011-03-25 18:19 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b2949bf39900 Merge Changeset: 29524004ce17 Author: never Date: 2011-03-25 18:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/29524004ce17 7022204: LogFile wildcarding should use %p instead of star Reviewed-by: coleenp, jrose ! src/share/vm/utilities/ostream.cpp Changeset: 7e88bdae86ec Author: roland Date: 2011-03-25 09:35 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7e88bdae86ec 7029017: Additional architecture support for c2 compiler Summary: Enables cross building of a c2 VM. Support masking of shift counts when the processor architecture mandates it. Reviewed-by: kvn, never ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/sparcWorks.make ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/main.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp Changeset: 244bf8afbbd3 Author: roland Date: 2011-03-26 08:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/244bf8afbbd3 Merge Changeset: 1927db75dd85 Author: never Date: 2011-03-27 00:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1927db75dd85 7024475: loop doesn't terminate when compiled Reviewed-by: kvn ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/idealGraphPrinter.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/runtime/globals.hpp + test/compiler/7024475/Test7024475.java Changeset: b40d4fa697bf Author: iveresov Date: 2011-03-27 13:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b40d4fa697bf 6964776: c2 should ensure the polling page is reachable on 64 bit Summary: Materialize the pointer to the polling page in a register instead of using rip-relative addressing when the distance from the code cache is larger than disp32. Reviewed-by: never, kvn ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.hpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/x86/vm/x86_64.ad Changeset: 3d58a4983660 Author: twisti Date: 2011-03-28 03:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3d58a4983660 7022998: JSR 292 recursive method handle calls inline themselves infinitely Reviewed-by: never, kvn ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: a988a7bb3b8a Author: kvn Date: 2011-03-29 09:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a988a7bb3b8a 7032133: Enable sse4.2 for new AMD processors Summary: New AMD processors support sse4.2. Enable corresponding instructions in Hotspot. Reviewed-by: kvn Contributed-by: eric.caspole at amd.com ! src/cpu/x86/vm/vm_version_x86.cpp Changeset: b1c22848507b Author: iveresov Date: 2011-03-29 17:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b1c22848507b 6741940: Nonvolatile XMM registers not preserved across JNI calls Summary: Save xmm6-xmm15 in call stub on win64 Reviewed-by: kvn, never ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 2cd0180da6e1 Author: never Date: 2011-03-29 22:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2cd0180da6e1 7032306: Fastdebug build failure on Solaris with SS11 compilers Reviewed-by: kvn, iveresov ! src/share/vm/oops/instanceKlass.cpp Changeset: 348c0df561a9 Author: iveresov Date: 2011-03-29 22:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/348c0df561a9 7026307: DEBUG MESSAGE: broken null klass on amd64 Summary: Correct typo introduces in 7020521 Reviewed-by: never, kvn ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: fe1dbd98e18f Author: iveresov Date: 2011-03-30 03:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fe1dbd98e18f Merge Changeset: 63997f575155 Author: never Date: 2011-03-30 07:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/63997f575155 7031614: jmap -permstat fails with java.lang.InternalError in sun.jvm.hotspot.oops.OopField.getValue Reviewed-by: kvn, dcubed ! agent/src/share/classes/sun/jvm/hotspot/jdi/ClassObjectReferenceImpl.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Instance.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java + agent/src/share/classes/sun/jvm/hotspot/oops/InstanceMirrorKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java + agent/src/share/classes/sun/jvm/hotspot/oops/java_lang_Class.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapGXLWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ReversePtrsAnalysis.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaFactoryImpl.java ! src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f9424955eb18 Author: kvn Date: 2011-03-30 12:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f9424955eb18 7029152: Ideal nodes for String intrinsics miss memory edge optimization Summary: In Ideal() method of String intrinsics nodes look for TypeAryPtr::CHARS memory slice if memory is MergeMem. Do not unroll a loop with String intrinsics code. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp + test/compiler/7029152/Test.java Changeset: e2eb7f986c64 Author: iveresov Date: 2011-03-30 15:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e2eb7f986c64 6564610: assert(UseCompiler || CompileTheWorld, "UseCompiler should be set by now.") Summary: Remove invalid asserts Reviewed-by: never, kvn ! src/share/vm/runtime/compilationPolicy.cpp Changeset: 9d343b8113db Author: iveresov Date: 2011-03-30 18:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9d343b8113db Merge Changeset: 09f96c3ff1ad Author: twisti Date: 2011-03-31 00:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/09f96c3ff1ad 7032388: guarantee(VM_Version::supports_cmov()) failed: illegal instruction on i586 after 6919934 Summary: 6919934 added some unguarded cmov instructions which hit a guarantee on older hardware. Reviewed-by: never, iveresov, kvn, phh ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp Changeset: 38fea01eb669 Author: twisti Date: 2011-03-31 02:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/38fea01eb669 6817525: turn on method handle functionality by default for JSR 292 Summary: After appropriate testing, we need to turn on EnableMethodHandles and EnableInvokeDynamic by default. Reviewed-by: never, kvn, jrose, phh ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp Changeset: cb162b348743 Author: kvn Date: 2011-03-31 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cb162b348743 7032696: Fix for 7029152 broke VM Summary: StrIntrinsicNode::Ideal() should not optimize memory during Parse. Reviewed-by: jrose, never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/memnode.cpp Changeset: 352622fd140a Author: never Date: 2011-03-31 14:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/352622fd140a 7032129: Native memory usage grow unexpectedly for vm/oom/*InternedString tests Reviewed-by: kvn, kamg, jcoomes ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/memory/dump.cpp Changeset: 2a5104162671 Author: never Date: 2011-03-31 15:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2a5104162671 Merge Changeset: 8010c8c623ac Author: kvn Date: 2011-03-31 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8010c8c623ac 7032849: 7022998 changes broke hs_err compile task print Summary: Initialize the time stamp on ostream used for hs_err dumping. Reviewed-by: never ! src/share/vm/utilities/ostream.cpp Changeset: 6b9eb6d07c62 Author: kvn Date: 2011-04-01 15:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6b9eb6d07c62 Merge From erik.trimble at oracle.com Fri Apr 1 21:10:15 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Sat, 02 Apr 2011 04:10:15 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20110402041023.CE7CD47708@hg.openjdk.java.net> Changeset: a1615ff22854 Author: schien Date: 2011-03-31 18:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a1615ff22854 Added tag jdk7-b136 for changeset bd586e392d93 ! .hgtags Changeset: 2ffcf94550d5 Author: trims Date: 2011-04-01 12:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2ffcf94550d5 Added tag hs21-b06 for changeset bd586e392d93 ! .hgtags Changeset: 7ea7c9c0305c Author: trims Date: 2011-04-01 20:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7ea7c9c0305c Merge Changeset: 2dbcb4a4d8da Author: trims Date: 2011-04-01 20:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2dbcb4a4d8da 7033237: Bump the HS21 build number to 07 Summary: Update the HS21 build number to 07 Reviewed-by: jcoomes ! make/hotspot_version From john.r.rose at oracle.com Sat Apr 2 14:52:36 2011 From: john.r.rose at oracle.com (John Rose) Date: Sat, 2 Apr 2011 14:52:36 -0700 Subject: review request (S): 6817525/JDK turn on method handle functionality by default for JSR 292 Message-ID: These are the JDK changes which correspond to Christian's fixes. They depend on the JVM changes. Like the JVM changes, they will be staged through hotspot-comp. 6817525 turn on method handle functionality by default for JSR 292 http://cr.openjdk.java.net/~jrose/6817525/webrev.jdk.00/ The changes to Indify also remove transitional support, since the unit tests (for which Indify is used) no longer exercise transitional forms of the API. -- John From vladimir.kozlov at oracle.com Sun Apr 3 09:28:09 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sun, 03 Apr 2011 09:28:09 -0700 Subject: review request (S): 6817525/JDK turn on method handle functionality by default for JSR 292 In-Reply-To: References: Message-ID: <4D98A019.8010009@oracle.com> Looks good. what is this comment '@@' in InvokeDynamicPrintArgs.java?: + "--verbose",//@@ Vladimir On 4/2/11 2:52 PM, John Rose wrote: > These are the JDK changes which correspond to Christian's fixes. They depend on the JVM changes. Like the JVM changes, they will be staged through hotspot-comp. > > 6817525 turn on method handle functionality by default for JSR 292 > http://cr.openjdk.java.net/~jrose/6817525/webrev.jdk.00/ > > The changes to Indify also remove transitional support, since the unit tests (for which Indify is used) no longer exercise transitional forms of the API. > > -- John > From christian.thalinger at oracle.com Mon Apr 4 02:33:04 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 4 Apr 2011 11:33:04 +0200 Subject: review request (S): 6817525/JDK turn on method handle functionality by default for JSR 292 In-Reply-To: References: Message-ID: On Apr 2, 2011, at 11:52 PM, John Rose wrote: > These are the JDK changes which correspond to Christian's fixes. They depend on the JVM changes. Like the JVM changes, they will be staged through hotspot-comp. > > 6817525 turn on method handle functionality by default for JSR 292 > http://cr.openjdk.java.net/~jrose/6817525/webrev.jdk.00/ > > The changes to Indify also remove transitional support, since the unit tests (for which Indify is used) no longer exercise transitional forms of the API. Looks good. Thanks for doing this! -- Christian From aph at redhat.com Mon Apr 4 06:18:04 2011 From: aph at redhat.com (Andrew Haley) Date: Mon, 04 Apr 2011 14:18:04 +0100 Subject: PING: Linux: Support transparent hugepages In-Reply-To: <4D9620FC.2030709@oracle.com> References: <4D95FDC9.8070704@redhat.com> <4D96184E.3090903@oracle.com> <4D961B91.3030507@redhat.com> <4D9620FC.2030709@oracle.com> Message-ID: <4D99C50C.5050504@redhat.com> On 04/01/2011 08:01 PM, Igor Veresov wrote: > On 4/1/11 11:38 AM, Andrew Haley wrote: >> On 04/01/2011 07:24 PM, Igor Veresov wrote: >>> Why is alignment required? Afaik it's perfectly fine to have mixed page >>> sizes in a single segment. >> >> Alignment is the only way to guarantee that all pages are huge pages. > > Right, but my point was that +UseLargePages option would do that > guaranteeing alignment. > >> >>> Also, if use use +UseLargePages, all the heap and generation sizes >>> will be largepage-alinged anyway. Also, some things like the >>> NUMA-allocator will work better is they know kind of pages the >>> underlying segment has. >> >> Yes, but on Linux at least +UseLargePages (using all that SHM stuff) >> needs special permissions, so it tends not to be used as much as it >> could. > > Right, but you can choose whether to do via SHM or by just doing madvise > at runtime. This way your code will nicely fit into the existing > framework - you'll get automatic page size detection and hence all the > requests from the runtime for memory will come properly aligned. > >> >>> What I would've done is put some logic to distinguish kernels that >>> support transparent large pages and instead of using all the SHM >>> stuff just use a mmap + madvise(MADV_HUGEPAGE). I'm afraid I've been unable to find that work in http://hg.openjdk.java.net/jdk7/hotspot//hotspot Is there some other tree that I should be looking at? Andrew. From igor.veresov at oracle.com Mon Apr 4 09:43:41 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 04 Apr 2011 09:43:41 -0700 Subject: PING: Linux: Support transparent hugepages In-Reply-To: <4D99C50C.5050504@redhat.com> References: <4D95FDC9.8070704@redhat.com> <4D96184E.3090903@oracle.com> <4D961B91.3030507@redhat.com> <4D9620FC.2030709@oracle.com> <4D99C50C.5050504@redhat.com> Message-ID: <4D99F53D.80202@oracle.com> On 4/4/11 6:18 AM, Andrew Haley wrote: > On 04/01/2011 08:01 PM, Igor Veresov wrote: >> On 4/1/11 11:38 AM, Andrew Haley wrote: >>> On 04/01/2011 07:24 PM, Igor Veresov wrote: >>>> Why is alignment required? Afaik it's perfectly fine to have mixed page >>>> sizes in a single segment. >>> >>> Alignment is the only way to guarantee that all pages are huge pages. >> >> Right, but my point was that +UseLargePages option would do that >> guaranteeing alignment. >> >>> >>>> Also, if use use +UseLargePages, all the heap and generation sizes >>>> will be largepage-alinged anyway. Also, some things like the >>>> NUMA-allocator will work better is they know kind of pages the >>>> underlying segment has. >>> >>> Yes, but on Linux at least +UseLargePages (using all that SHM stuff) >>> needs special permissions, so it tends not to be used as much as it >>> could. >> >> Right, but you can choose whether to do via SHM or by just doing madvise >> at runtime. This way your code will nicely fit into the existing >> framework - you'll get automatic page size detection and hence all the >> requests from the runtime for memory will come properly aligned. >> >>> >>>> What I would've done is put some logic to distinguish kernels that >>>> support transparent large pages and instead of using all the SHM >>>> stuff just use a mmap + madvise(MADV_HUGEPAGE). > > I'm afraid I've been unable to find that work in http://hg.openjdk.java.net/jdk7/hotspot//hotspot > > Is there some other tree that I should be looking at? I didn't mean the work I mentioned in the last paragraph that you quoted exists, I rather meant that it should be done in order to implement proper transparent pages support in linux (because we want the older linux kernels work too). I think it should be analogous to the Solaris implementation, which can be found here: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/2dbcb4a4d8da/src/os/solaris/vm/os_solaris.cpp igor > > Andrew. From y.s.ramakrishna at oracle.com Mon Apr 4 09:54:17 2011 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Mon, 04 Apr 2011 09:54:17 -0700 Subject: precise and imprecise card marking? Message-ID: <4D99F7B9.4080901@oracle.com> Sorry for a somewhat naive question, but i have forgotten a few old history lessons, which i'll need to relearn... As I understand, array objects in hotspot are always precisely marked, but non-array objects are sometimes precisely and sometimes imprecisely marked. (Is this understanding correct?) I ask because there is some card-scanning code in GC that gets quite convoluted on account of the latter (imprecise and precise marking of non-array objects), which has recently turned up a(n apparently long-standing) bug in parallel card-scanning with ParNew, re 6883834. While it is possible to fix this bug assuming the current card-marking constraints, I wanted to check what people thought of the (im)possibility (or otherwise) of making the JVM always precisely card-mark all updates. (This would simplify the code in card-scanning, allow us to throw away a bunch of somewhat convoluted code in ParNew's parallel card-scanning, and eliminate the bug in 6883834.) So, what is the fundamental reason for sometimes marking objects imprecisely? Does it make generated code much faster, or ..., or ... ? thanks! -- ramki From tom.rodriguez at oracle.com Mon Apr 4 10:20:35 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 4 Apr 2011 10:20:35 -0700 Subject: precise and imprecise card marking? In-Reply-To: <4D99F7B9.4080901@oracle.com> References: <4D99F7B9.4080901@oracle.com> Message-ID: tom On Apr 4, 2011, at 9:54 AM, Y. Srinivas Ramakrishna wrote: > > Sorry for a somewhat naive question, but i have forgotten a few old > history lessons, which i'll need to relearn... > > As I understand, array objects in hotspot are always precisely marked, > but non-array objects are sometimes precisely and sometimes imprecisely > marked. (Is this understanding correct?) For Java code both the compilers and interpreter always do imprecise marks for regular Java object and precise marks for array. However, Unsafe operations always do precise card marks because they don't necessarily know whether they are operating on arrays or not. oop_stores in the C++ source are done as precise card marks. > > I ask because there is some card-scanning code in GC that gets quite > convoluted on account of the latter (imprecise and precise marking > of non-array objects), which has recently turned up a(n apparently > long-standing) bug in parallel card-scanning with ParNew, re 6883834. > While it is possible to fix this bug assuming the current card-marking > constraints, I wanted to check what people thought of the (im)possibility > (or otherwise) of making the JVM always precisely card-mark all > updates. (This would simplify the code in card-scanning, > allow us to throw away a bunch of somewhat convoluted code in > ParNew's parallel card-scanning, and eliminate the bug in 6883834.) > > So, what is the fundamental reason for sometimes marking objects > imprecisely? Does it make generated code much faster, or ..., or ... ? The code is much better when doing imprecise marks since you don't have the extra add, shift and store. Precise card marks also makes elminating redundant card marks hard when updating multiple fields in the same object since they might span a card. You'd have to do something more clever like keeping the highest and lowest card marks, assuming the offsets are less the card size. So for a simple example of updating two regular Java fields instead of this: set cardtable, %i2 st %i0, [%i4 + 12] st %i1, [%i4 + 16] sll %i4, 9, %i3 stb %g0 [%i3 + %i2] you have to do this: set cardtable, %i2 st %i0, [%i4 + 12] add %i4, 12, %i3 sll %i3, 9, %i3 stb %g0 [%i3 + %i2] st %i1, [%i4 + 16] add %i4, 16, %i3 sll %i3, 9, %i3 stb %g0 [%i3 + %i2] You could simply always update the next card at the cost of some overscanning. Anyway, I think imprecise marking for regular Java object would definitely have a performance impact on mutator speed. It would be easy to do the experiment though if you are interested. For C2 you can probably just change the handling of the use_precise flag in GraphKit::post_barrier to make it always true. tom > > thanks! > -- ramki From y.s.ramakrishna at oracle.com Mon Apr 4 11:08:54 2011 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Mon, 04 Apr 2011 11:08:54 -0700 Subject: precise and imprecise card marking? In-Reply-To: References: <4D99F7B9.4080901@oracle.com> Message-ID: <4D9A0936.6080000@oracle.com> Tom, thanks for the as always prompt and comprehensive response, and the advice on how to make C2 generate code for precise marking of regular objects etc. I'll check out the performance difference (but for now i'll plan to quickly fix 6883834 while keeping the imprecision unchanged at its current status quo). -- ramki On 4/4/2011 10:20 AM, Tom Rodriguez wrote: > > > tom > > On Apr 4, 2011, at 9:54 AM, Y. Srinivas Ramakrishna wrote: > >> >> Sorry for a somewhat naive question, but i have forgotten a few old >> history lessons, which i'll need to relearn... >> >> As I understand, array objects in hotspot are always precisely marked, >> but non-array objects are sometimes precisely and sometimes imprecisely >> marked. (Is this understanding correct?) > > For Java code both the compilers and interpreter always do imprecise marks for regular Java object and precise marks for array. However, Unsafe operations always do precise card marks because they don't necessarily know whether they are operating on arrays or not. oop_stores in the C++ source are done as precise card marks. > >> >> I ask because there is some card-scanning code in GC that gets quite >> convoluted on account of the latter (imprecise and precise marking >> of non-array objects), which has recently turned up a(n apparently >> long-standing) bug in parallel card-scanning with ParNew, re 6883834. >> While it is possible to fix this bug assuming the current card-marking >> constraints, I wanted to check what people thought of the (im)possibility >> (or otherwise) of making the JVM always precisely card-mark all >> updates. (This would simplify the code in card-scanning, >> allow us to throw away a bunch of somewhat convoluted code in >> ParNew's parallel card-scanning, and eliminate the bug in 6883834.) >> >> So, what is the fundamental reason for sometimes marking objects >> imprecisely? Does it make generated code much faster, or ..., or ... ? > > The code is much better when doing imprecise marks since you don't have the extra add, shift and store. Precise card marks also makes elminating redundant card marks hard when updating multiple fields in the same object since they might span a card. You'd have to do something more clever like keeping the highest and lowest card marks, assuming the offsets are less the card size. So for a simple example of updating two regular Java fields instead of this: > > set cardtable, %i2 > st %i0, [%i4 + 12] > st %i1, [%i4 + 16] > sll %i4, 9, %i3 > stb %g0 [%i3 + %i2] > > you have to do this: > > set cardtable, %i2 > st %i0, [%i4 + 12] > add %i4, 12, %i3 > sll %i3, 9, %i3 > stb %g0 [%i3 + %i2] > st %i1, [%i4 + 16] > add %i4, 16, %i3 > sll %i3, 9, %i3 > stb %g0 [%i3 + %i2] > > You could simply always update the next card at the cost of some overscanning. Anyway, I think imprecise marking for regular Java object would definitely have a performance impact on mutator speed. It would be easy to do the experiment though if you are interested. For C2 you can probably just change the handling of the use_precise flag in GraphKit::post_barrier to make it always true. > > tom > > >> >> thanks! >> -- ramki > From john.cuthbertson at oracle.com Mon Apr 4 16:43:16 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 04 Apr 2011 16:43:16 -0700 Subject: RFR(M): 7009266: G1: assert(obj->is_oop_or_null(true )) failed: Error In-Reply-To: <4D90C6E0.9000901@oracle.com> References: <4D7ACDBA.7020003@oracle.com> <4D90C6E0.9000901@oracle.com> Message-ID: <4D9A5794.1030507@oracle.com> Hi Everyone, A new webrev for this fix can be found at: http://cr.openjdk.java.net/~johnc/7009266/webrev.5/ The changes in this revision include: * Revised barrier set calls in JNI_GetObjectField and Unsafe_getObject so that the value that is returned is the value that gets recorded in an SATB buffer. The code in the previous revision re-read the value of the field potentially causing the value the is logged to be different from that returned. * Added the static checks, suggested by Tom, in library_call.cpp. * Removed the complicated control flow from the C1 LIR implementation of Unsafe.getObject. Instead the checks have been moved into a code stub while some static checks have been added. * Re-enabled reference discovery (and therefore reference processing) during concurrent marking as a result of pushing the changes for 7020042 to hs21. Thanks, JohnC On 03/28/11 10:35, John Cuthbertson wrote: > Hi Everyone, > > A new webrev with changes based upon comments from Tom can be found > at: http://cr.openjdk.java.net/~johnc/7009266/webrev.4/. > > The latest changes include inserting a suitably guarded barrier call > in case the referent field of a Reference object is being read/fetched > using JNI, reflection, or Unsafe. > > Thanks, > > JohnC > > On 3/11/2011 5:34 PM, John Cuthbertson wrote: >> Hi Everyone, >> >> I'm looking for a few of volunteers to review the changes that fix >> this assertion failure. The latest changes can be found at: >> http://cr.openjdk.java.net/~johnc/7009266/webrev.3/ and include >> changes based upon earlier internal reviews. The earlier changes are >> also on cr.openjdk.java.net for reference. >> >> Background: >> The G1 garbage collector includes a concurrent marking algorithm that >> makes use of snapshot-at-the-beginning or SATB. With this algorithm >> the GC will mark all objects that are reachable at the start of >> marking; objects that are allocated since the start of marking are >> implicitly considered live. In order to populate the "snapshot" of >> the object graph that existed at the start of marking, G1 employs a >> write barrier. When an object is stored into another object's field >> the write-barrier records the previous value of that field as it was >> part of the "snapshot" and concurrent marking will trace the >> sub-graph that is reachable from this previous value. >> >> Unfortunately, in the presence of Reference objects, SATB might not >> be sufficient to mark a referent object as live. Consider that, at >> the start of marking, we have a weakly reachable object i.e. an >> object where the only pointer to that object. If the referent is >> obtained from the Reference object and stored to another object's >> field (making the referent now strongly reachable and hence live) the >> G1 write barrier will record the field's previous value but not the >> value of the referent. >> >> If the referent object is strongly reachable from some other object >> that will be traced by concurrent marking, _or_ there is a subsequent >> assignment to the field where we have written the referent (in which >> case we record the previous value - the referent - in an SATB buffer) >> then the referent will be marked live. Otherwise the referent will >> not be marked. >> >> That is the issue that was causing the failure in this CR. There was >> a Logger object that was only reachable through a WeakReference at >> the start of concurrent marking. During marking the Logger object is >> obtained from the WeakReference and stored into a field of a live >> object. The G1 write barrier recorded the previous value in the field >> (as it is part of the snapshot at the start of marking). Since there >> was no other assignment to the live object's field and there was no >> other strong reference to the Logger object, the Logger object was >> not marked. At the end of concurrent marking the Logger object was >> considered dead and the link between the WeakReference and the Logger >> was severed by clearing the referent field during reference processing. >> >> To solve this (entirely in Hotspot and causing a performance overhead >> for G1 only) it was decided that the best approach was to intrinsify >> the Reference.get() method in the JIT compilers and add new >> interpreter entry points so that the value in the referent field will >> be recorded in an SATB buffer by the G1 pre-barrier code. >> >> The changes for Zero and the C++ interpreters are place holder >> routines but should be straight forward to implement. >> >> None of the individual changes is large - they are just well >> distributed around the JVM. :) >> >> Testing: white box test; eyeballing the generated compiled and >> interpreter code; the failing Kitchensink big-app on x86 (32/64 bit), >> sparc (32/64 bit), Xint, Xcomp (client and server), with and without >> G1; the GC test suite with and without G1; and jprt. >> >> Thanks and regards, >> >> JohnC > From john.r.rose at oracle.com Mon Apr 4 17:54:38 2011 From: john.r.rose at oracle.com (John Rose) Date: Mon, 4 Apr 2011 17:54:38 -0700 Subject: review request (S): 6817525/JDK turn on method handle functionality by default for JSR 292 In-Reply-To: <4D98A019.8010009@oracle.com> References: <4D98A019.8010009@oracle.com> Message-ID: <9F0AA47A-26BF-4B6D-A348-1DE89C45C719@oracle.com> On Apr 3, 2011, at 9:28 AM, Vladimir Kozlov wrote: > what is this comment '@@' in InvokeDynamicPrintArgs.java?: A leftover from development; fixed. -- John From tom.rodriguez at oracle.com Tue Apr 5 11:56:32 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 5 Apr 2011 11:56:32 -0700 Subject: RFR(M): 7009266: G1: assert(obj->is_oop_or_null(true )) failed: Error In-Reply-To: <4D9A5794.1030507@oracle.com> References: <4D7ACDBA.7020003@oracle.com> <4D90C6E0.9000901@oracle.com> <4D9A5794.1030507@oracle.com> Message-ID: <48D28564-37FA-4DC7-A0C2-3531844EB152@oracle.com> Looks good. tom On Apr 4, 2011, at 4:43 PM, John Cuthbertson wrote: > Hi Everyone, > > A new webrev for this fix can be found at: http://cr.openjdk.java.net/~johnc/7009266/webrev.5/ > > The changes in this revision include: > > * Revised barrier set calls in JNI_GetObjectField and Unsafe_getObject so that the value that is returned is the value that gets recorded in an SATB buffer. The code in the previous revision re-read the value of the field potentially causing the value the is logged to be different from that returned. > > * Added the static checks, suggested by Tom, in library_call.cpp. > > * Removed the complicated control flow from the C1 LIR implementation of Unsafe.getObject. Instead the checks have been moved into a code stub while some static checks have been added. > > * Re-enabled reference discovery (and therefore reference processing) during concurrent marking as a result of pushing the changes for 7020042 to hs21. > > Thanks, > > JohnC > > On 03/28/11 10:35, John Cuthbertson wrote: >> Hi Everyone, >> >> A new webrev with changes based upon comments from Tom can be found at: http://cr.openjdk.java.net/~johnc/7009266/webrev.4/. >> >> The latest changes include inserting a suitably guarded barrier call in case the referent field of a Reference object is being read/fetched using JNI, reflection, or Unsafe. >> >> Thanks, >> >> JohnC >> >> On 3/11/2011 5:34 PM, John Cuthbertson wrote: >>> Hi Everyone, >>> >>> I'm looking for a few of volunteers to review the changes that fix this assertion failure. The latest changes can be found at: http://cr.openjdk.java.net/~johnc/7009266/webrev.3/ and include changes based upon earlier internal reviews. The earlier changes are also on cr.openjdk.java.net for reference. >>> >>> Background: >>> The G1 garbage collector includes a concurrent marking algorithm that makes use of snapshot-at-the-beginning or SATB. With this algorithm the GC will mark all objects that are reachable at the start of marking; objects that are allocated since the start of marking are implicitly considered live. In order to populate the "snapshot" of the object graph that existed at the start of marking, G1 employs a write barrier. When an object is stored into another object's field the write-barrier records the previous value of that field as it was part of the "snapshot" and concurrent marking will trace the sub-graph that is reachable from this previous value. >>> >>> Unfortunately, in the presence of Reference objects, SATB might not be sufficient to mark a referent object as live. Consider that, at the start of marking, we have a weakly reachable object i.e. an object where the only pointer to that object. If the referent is obtained from the Reference object and stored to another object's field (making the referent now strongly reachable and hence live) the G1 write barrier will record the field's previous value but not the value of the referent. >>> >>> If the referent object is strongly reachable from some other object that will be traced by concurrent marking, _or_ there is a subsequent assignment to the field where we have written the referent (in which case we record the previous value - the referent - in an SATB buffer) then the referent will be marked live. Otherwise the referent will not be marked. >>> >>> That is the issue that was causing the failure in this CR. There was a Logger object that was only reachable through a WeakReference at the start of concurrent marking. During marking the Logger object is obtained from the WeakReference and stored into a field of a live object. The G1 write barrier recorded the previous value in the field (as it is part of the snapshot at the start of marking). Since there was no other assignment to the live object's field and there was no other strong reference to the Logger object, the Logger object was not marked. At the end of concurrent marking the Logger object was considered dead and the link between the WeakReference and the Logger was severed by clearing the referent field during reference processing. >>> >>> To solve this (entirely in Hotspot and causing a performance overhead for G1 only) it was decided that the best approach was to intrinsify the Reference.get() method in the JIT compilers and add new interpreter entry points so that the value in the referent field will be recorded in an SATB buffer by the G1 pre-barrier code. >>> >>> The changes for Zero and the C++ interpreters are place holder routines but should be straight forward to implement. >>> >>> None of the individual changes is large - they are just well distributed around the JVM. :) >>> >>> Testing: white box test; eyeballing the generated compiled and interpreter code; the failing Kitchensink big-app on x86 (32/64 bit), sparc (32/64 bit), Xint, Xcomp (client and server), with and without G1; the GC test suite with and without G1; and jprt. >>> >>> Thanks and regards, >>> >>> JohnC >> > From erik.trimble at oracle.com Tue Apr 5 19:08:36 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Wed, 06 Apr 2011 02:08:36 +0000 Subject: hg: jdk7/hotspot/hotspot: 7010070: Update all 2010 Oracle-changed OpenJDK files to have the proper copyright dates - second pass Message-ID: <20110406020838.7CD3D47815@hg.openjdk.java.net> Changeset: 1d1603768966 Author: trims Date: 2011-04-05 14:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1d1603768966 7010070: Update all 2010 Oracle-changed OpenJDK files to have the proper copyright dates - second pass Summary: Update the copyright to be 2010 on all changed files in OpenJDK Reviewed-by: ohair ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithKlass.java ! agent/src/share/classes/sun/jvm/hotspot/memory/DictionaryEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/PlaceholderEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/StringTable.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Symbol.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/types/Field.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableEntry.java ! make/linux/Makefile ! make/linux/makefiles/arm.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/linux/makefiles/ppc.make ! make/linux/makefiles/sparcWorks.make ! make/linux/makefiles/top.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/top.make ! make/solaris/makefiles/vm.make ! make/windows/create_obj_files.sh ! make/windows/makefiles/launcher.make ! make/windows/makefiles/vm.make ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/dump_sparc.cpp ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/x86/vm/jni_x86.h ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/zero/vm/jni_zero.h ! src/os/linux/vm/jvm_linux.cpp ! src/os/linux/vm/osThread_linux.cpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/linux/vm/thread_linux.inline.hpp ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/jhelper.d ! src/os/solaris/dtrace/libjvm_db.c ! src/os/solaris/vm/dtraceJSDT_solaris.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/tools/hsdis/hsdis-demo.c ! src/share/tools/hsdis/hsdis.c ! src/share/vm/adlc/main.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_Defs.hpp ! src/share/vm/c1/c1_FpuStackSim.hpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/c1/c1_MacroAssembler.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/ci/compilerInterface.hpp ! src/share/vm/classfile/classFileError.cpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/javaAssertions.cpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/resolutionErrors.cpp ! src/share/vm/classfile/resolutionErrors.hpp ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.cpp ! src/share/vm/classfile/stackMapTable.hpp ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verificationType.hpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/icBuffer.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/code/vmreg.hpp ! src/share/vm/compiler/compileLog.hpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/compilerOracle.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/gcUtil.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp ! src/share/vm/interpreter/cppInterpreter.hpp ! src/share/vm/interpreter/cppInterpreterGenerator.hpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/interpreterGenerator.hpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/memory/barrierSet.cpp ! src/share/vm/memory/classify.cpp ! src/share/vm/memory/compactingPermGenGen.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/restore.cpp ! src/share/vm/memory/serialize.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/cpCacheKlass.hpp ! src/share/vm/oops/generateOopMap.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/markOop.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/precompiled.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/prims/jni_md.h ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/dtraceJSDT.hpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/fieldType.cpp ! src/share/vm/runtime/fieldType.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/frame.inline.hpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/icache.hpp ! src/share/vm/runtime/interfaceSupport.cpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/javaFrameAnchor.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/reflection.hpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/registerMap.hpp ! src/share/vm/runtime/rframe.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/stackValueCollection.cpp ! src/share/vm/runtime/statSampler.cpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/threadLocalStorage.hpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vmStructs.hpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/management.hpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/shark/sharkNativeWrapper.cpp ! src/share/vm/utilities/copy.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/elfSymbolTable.cpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/hashtable.inline.hpp ! src/share/vm/utilities/ostream.hpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/utf8.cpp ! src/share/vm/utilities/utf8.hpp ! src/share/vm/utilities/xmlstream.cpp ! src/share/vm/utilities/xmlstream.hpp From christian.thalinger at oracle.com Wed Apr 6 00:53:20 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 6 Apr 2011 09:53:20 +0200 Subject: Output register allocation constrain fix for HotSpot In-Reply-To: <4D8D5910.6010901@oracle.com> References: <20110326025952.GA31265@redhat.com> <4D8D5910.6010901@oracle.com> Message-ID: <51FE2466-A003-4DB0-86CD-5C4ED45512BB@oracle.com> On Mar 26, 2011, at 4:10 AM, David Holmes wrote: > Hi Deepak, > > I've filed "7031385 incorrect register allocation in release_store_fence on linux x86" for this issue. I just stumbled over this same bug on one of our Ubuntu machines using GCC 4.5.1. What's the status of this fix? /home/twisti/hotspot-comp/7018355/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp: Assembler messages: /home/twisti/hotspot-comp/7018355/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp:160: Error: bad register name `%dil' /home/twisti/hotspot-comp/7018355/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp:160: Error: bad register name `%dil' -- Christian > > David Holmes > > Deepak Bhole said the following on 03/26/11 12:59: >> Hi, >> When trying to build IcedTea with GCC 4.6, we encountered an error that >> stems from incorrect register allocation in release_store_fence(volatile >> jbyte* p, jbyte v) in orderAccess_linux_x86.inline.hpp. >> Specifically, the inline assembly call trying to do an atomic 8-bit >> exchange sets the output register constrain to r. The older versions GCC >> (by chance) ended up assigning the l-part of one of the a/b/c/d >> registers. However with 4.6, it attempts to do this with the >> %*bp register. This is fine on x86_64, but on i686 the bp register >> cannot be addressed in 8-bit (%bpl). This leads to a compilation >> failure: >> /builddir/build/BUILD/icedtea6-1.10/openjdk-ecj/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp: Assembler messages: >> /builddir/build/BUILD/icedtea6-1.10/openjdk-ecj/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp:160: Error: bad register name `%bpl' >> /builddir/build/BUILD/icedtea6-1.10/openjdk-ecj/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp:160: Error: bad register name `%bpl' >> It is possible to make it work on both 32 and 64-bit by constraining the >> output register further to only be one of a/b/c/d (=q). >> Though it was only that function that caused an error, I think it'd be >> best to change both uses of xchgb in orderAccess_linux_x86.inline.hpp to >> use =q. Here is the webrev for it: >> http://cr.openjdk.java.net/~dbhole/register-allocation-fix/webrev.00/ >> If there are no issues, I'd be happy to push the above change. >> Cheers, >> Deepak From aph at redhat.com Wed Apr 6 08:21:55 2011 From: aph at redhat.com (Andrew Haley) Date: Wed, 06 Apr 2011 16:21:55 +0100 Subject: PING: Linux: Support transparent hugepages In-Reply-To: <4D99F53D.80202@oracle.com> References: <4D95FDC9.8070704@redhat.com> <4D96184E.3090903@oracle.com> <4D961B91.3030507@redhat.com> <4D9620FC.2030709@oracle.com> <4D99C50C.5050504@redhat.com> <4D99F53D.80202@oracle.com> Message-ID: <4D9C8513.7000306@redhat.com> On 04/04/2011 05:43 PM, Igor Veresov wrote: > I didn't mean the work I mentioned in the last paragraph that you quoted > exists, I rather meant that it should be done in order to implement > proper transparent pages support in linux (because we want the older > linux kernels work too). > > I think it should be analogous to the Solaris implementation, which can > be found here: > http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/2dbcb4a4d8da/src/os/solaris/vm/os_solaris.cpp Here is the full patch, with backwards compatibility. It builds on old and new systems, preferring MAP_HUGETLB but falling back to the old SysV shmget() if that doesn't work. If this looks right to you, I'll prepare a CR for pushing. I'll need a bug ID, please. Thanks, Andrew. diff -r 2dbcb4a4d8da src/os/linux/vm/globals_linux.hpp --- a/src/os/linux/vm/globals_linux.hpp Fri Apr 01 20:44:31 2011 -0700 +++ b/src/os/linux/vm/globals_linux.hpp Wed Apr 06 15:46:23 2011 +0100 @@ -33,9 +33,15 @@ "enable support for Oprofile profiler") \ \ product(bool, UseLinuxPosixThreadCPUClocks, true, \ - "enable fast Linux Posix clocks where available") -// NB: The default value of UseLinuxPosixThreadCPUClocks may be -// overridden in Arguments::parse_each_vm_init_arg. + "enable fast Linux Posix clocks where available") \ +/* NB: The default value of UseLinuxPosixThreadCPUClocks may be \ + overridden in Arguments::parse_each_vm_init_arg. */ \ + \ + product(bool, UseHugeTLBFS, false, \ + "Use MAP_HUGETLB for large pages") \ + \ + product(bool, UseSHM, false, \ + "Use SYSV shared memory for large pages") // // Defines Linux-specific default values. The flags are available on all diff -r 2dbcb4a4d8da src/os/linux/vm/os_linux.cpp --- a/src/os/linux/vm/os_linux.cpp Fri Apr 01 20:44:31 2011 -0700 +++ b/src/os/linux/vm/os_linux.cpp Wed Apr 06 15:46:23 2011 +0100 @@ -2465,8 +2465,22 @@ return res != (uintptr_t) MAP_FAILED; } +// Define MAP_HUGETLB here so we can build HotSpot on old systems. +#ifndef MAP_HUGETLB +#define MAP_HUGETLB 0x40000 +#endif + bool os::commit_memory(char* addr, size_t size, size_t alignment_hint, bool exec) { + if (UseHugeTLBFS && alignment_hint > (size_t)vm_page_size()) { + int prot = exec ? PROT_READ|PROT_WRITE|PROT_EXEC : PROT_READ|PROT_WRITE; + uintptr_t res = + (uintptr_t) ::mmap(addr, size, prot, + MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_HUGETLB, + -1, 0); + return res != (uintptr_t) MAP_FAILED; + } + return commit_memory(addr, size, exec); } @@ -2818,6 +2832,42 @@ return linux_mprotect(addr, size, PROT_READ|PROT_WRITE); } +bool os::Linux::hugetlbfs_sanity_check(bool warn, size_t page_size) { + bool result = false; + void *p = mmap (NULL, page_size, PROT_READ|PROT_WRITE, + MAP_ANONYMOUS|MAP_PRIVATE|MAP_HUGETLB, + -1, 0); + + if (p != (void *) -1) { + // We don't know if this really is a huge page or not. + FILE *fp = fopen("/proc/self/maps", "r"); + if (fp) { + while (!feof(fp)) { + char chars[257]; + long x = 0; + if (fgets(chars, sizeof chars, fp)) { + if (sscanf(chars, "%lx-%*lx", &x) == 1 + && x == (long)p) { + if (strstr (chars, "hugepage")) { + result = true; + break; + } + } + } + } + fclose(fp); + } + munmap (p, page_size); + if (result) + return true; + } + + if (warn) { + warning("HugeTLBFS is not supported by the operating system."); + } +} + + /* * Set the coredump_filter bits to include largepages in core dump (bit 6) * @@ -2860,7 +2910,16 @@ static size_t _large_page_size = 0; bool os::large_page_init() { - if (!UseLargePages) return false; + if (!UseLargePages) { + UseHugeTLBFS = false; + UseSHM = false; + return false; + } + + if (FLAG_IS_DEFAULT(UseHugeTLBFS) && FLAG_IS_DEFAULT(UseSHM)) { + // Our user has not expressed a preference, so we'll try both. + UseHugeTLBFS = UseSHM = true; + } if (LargePageSizeInBytes) { _large_page_size = LargePageSizeInBytes; @@ -2905,6 +2964,9 @@ } } + // print a warning if any large page related flag is specified on command line + bool warn_on_failure = !FLAG_IS_DEFAULT(UseHugeTLBFS); + const size_t default_page_size = (size_t)Linux::page_size(); if (_large_page_size > default_page_size) { _page_sizes[0] = _large_page_size; @@ -2912,6 +2974,14 @@ _page_sizes[2] = 0; } + UseHugeTLBFS = UseHugeTLBFS && + Linux::hugetlbfs_sanity_check(warn_on_failure, _large_page_size); + + if (UseHugeTLBFS) + UseSHM = false; + + UseLargePages = UseHugeTLBFS || UseSHM; + set_coredump_filter(); // Large page support is available on 2.6 or newer kernel, some vendors @@ -2928,7 +2998,7 @@ char* os::reserve_memory_special(size_t bytes, char* req_addr, bool exec) { // "exec" is passed in but not used. Creating the shared image for // the code cache doesn't have an SHM_X executable permission to check. - assert(UseLargePages, "only for large pages"); + assert(UseLargePages && UseSHM, "only for SHM large pages"); key_t key = IPC_PRIVATE; char *addr; @@ -2995,16 +3065,15 @@ return _large_page_size; } -// Linux does not support anonymous mmap with large page memory. The only way -// to reserve large page memory without file backing is through SysV shared -// memory API. The entire memory region is committed and pinned upfront. -// Hopefully this will change in the future... +// HugeTLBFS allows application to commit large page memory on demand; +// with SysV SHM the entire memory region must be allocated as shared +// memory. bool os::can_commit_large_page_memory() { - return false; + return UseHugeTLBFS; } bool os::can_execute_large_page_memory() { - return false; + return UseHugeTLBFS; } // Reserve memory at an arbitrary address, only if that area is diff -r 2dbcb4a4d8da src/os/linux/vm/os_linux.hpp --- a/src/os/linux/vm/os_linux.hpp Fri Apr 01 20:44:31 2011 -0700 +++ b/src/os/linux/vm/os_linux.hpp Wed Apr 06 15:46:23 2011 +0100 @@ -86,6 +86,9 @@ static void rebuild_cpu_to_node_map(); static GrowableArray* cpu_to_node() { return _cpu_to_node; } + + static bool hugetlbfs_sanity_check(bool warn, size_t page_size); + public: static void init_thread_fpu_state(); static int get_fpu_control_word(); From igor.veresov at oracle.com Wed Apr 6 13:53:28 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 06 Apr 2011 13:53:28 -0700 Subject: PING: Linux: Support transparent hugepages In-Reply-To: <4D9C8513.7000306@redhat.com> References: <4D95FDC9.8070704@redhat.com> <4D96184E.3090903@oracle.com> <4D961B91.3030507@redhat.com> <4D9620FC.2030709@oracle.com> <4D99C50C.5050504@redhat.com> <4D99F53D.80202@oracle.com> <4D9C8513.7000306@redhat.com> Message-ID: <4D9CD2C8.90504@oracle.com> I think this looks ok. So, older kernels wouldn't return an error if you use MAP_HUGETLB? I filed: 7034464 Support transparent large pages on Linux igor On 4/6/11 8:21 AM, Andrew Haley wrote: > On 04/04/2011 05:43 PM, Igor Veresov wrote: > >> I didn't mean the work I mentioned in the last paragraph that you quoted >> exists, I rather meant that it should be done in order to implement >> proper transparent pages support in linux (because we want the older >> linux kernels work too). >> >> I think it should be analogous to the Solaris implementation, which can >> be found here: >> http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/2dbcb4a4d8da/src/os/solaris/vm/os_solaris.cpp > > Here is the full patch, with backwards compatibility. It builds on > old and new systems, preferring MAP_HUGETLB but falling back to the > old SysV shmget() if that doesn't work. > > If this looks right to you, I'll prepare a CR for pushing. I'll need > a bug ID, please. > > Thanks, > Andrew. > > From jon.masamitsu at oracle.com Thu Apr 7 16:18:33 2011 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Thu, 07 Apr 2011 23:18:33 +0000 Subject: hg: jdk7/hotspot/hotspot: 11 new changesets Message-ID: <20110407231854.29D5E478B2@hg.openjdk.java.net> Changeset: a0de1dfd1933 Author: ysr Date: 2011-03-24 15:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a0de1dfd1933 7030435: Some oop_oop_iterate_m() methods iterate outside of specified memory bounds Summary: Filter ref-containing locations through the memory-interval specified in the call. Reviewed-by: jcoomes, jwilhelm, tonyp ! src/share/vm/oops/constantPoolKlass.cpp Changeset: 5134fa1cfe63 Author: ysr Date: 2011-03-24 15:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5134fa1cfe63 7029036: Card-table verification hangs with all framework collectors, except G1, even before the first GC Summary: When verifying clean card ranges, use memory-range-bounded iteration over oops of objects overlapping that range, thus avoiding the otherwise quadratic worst-case cost of scanning large object arrays. Reviewed-by: jmasa, jwilhelm, tonyp ! src/share/vm/memory/cardTableRS.cpp Changeset: c6580380076b Author: jcoomes Date: 2011-03-25 17:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c6580380076b Merge Changeset: 5c0b591e1074 Author: brutisso Date: 2011-03-23 14:12 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5c0b591e1074 6948149: G1: Imbalance in termination times Summary: Changed default value of WorkStealingYieldsBeforeSleep from 1000 to 5000. Added more information to G1 pause logging. Reviewed-by: jwilhelm, tonyp, jmasa ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/runtime/globals.hpp Changeset: 02f49b66361a Author: johnc Date: 2011-03-28 10:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/02f49b66361a 7026932: G1: No need to abort VM when card count cache expansion fails Summary: Manage allocation/freeing of the card cache counts and epochs arrays directly so that an allocation failure while attempting to expand these arrays does not abort the JVM. Failure to expand these arrays is not fatal. Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 455328d90876 Author: tonyp Date: 2011-03-29 22:36 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/455328d90876 7029458: G1: Add newly-reclaimed regions to the beginning of the region free list, not the end Summary: What the synopsis says. Reviewed-by: jwilhelm, iveresov, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp Changeset: abdfc822206f Author: tonyp Date: 2011-03-30 10:26 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/abdfc822206f 7023069: G1: Introduce symmetric locking in the slow allocation path 7023151: G1: refactor the code that operates on _cur_alloc_region to be re-used for allocs by the GC threads 7018286: G1: humongous allocation attempts should take the GC locker into account Summary: First, this change replaces the asymmetric locking scheme in the G1 slow alloc path by a summetric one. Second, it factors out the code that operates on _cur_alloc_region so that it can be re-used for allocations by the GC threads in the future. Reviewed-by: stefank, brutisso, johnc + src/share/vm/gc_implementation/g1/g1AllocRegion.cpp + src/share/vm/gc_implementation/g1/g1AllocRegion.hpp + src/share/vm/gc_implementation/g1/g1AllocRegion.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/space.cpp Changeset: c84ee870e0b9 Author: tonyp Date: 2011-04-04 13:18 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c84ee870e0b9 7033292: G1: nightly failure: Non-dirty cards in region that should be dirty Summary: The epochs on the card cache array are initialized to 0 and our initial epoch also starts at 0. So, until the first GC, it might be possible to successfully "claim" a card which was in fact never initialized. Reviewed-by: johnc, iveresov, ysr ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp Changeset: 371bbc844bf1 Author: tonyp Date: 2011-04-04 14:23 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/371bbc844bf1 7027766: G1: introduce flag to dump the liveness information per region at the end of marking Summary: Repurpose the existing flag G1PrintRegionLivenessInfo to print out the liveness distribution across the regions in the heap at the end of marking. Reviewed-by: iveresov, jwilhelm ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 8f1042ff784d Author: johnc Date: 2011-02-18 10:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8f1042ff784d 7020042: G1: Partially remove fix for 6994628 Summary: Disable reference discovery and processing during concurrent marking by disabling fix for 6994628. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 4f978fb6c81a Author: jmasa Date: 2011-04-06 16:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4f978fb6c81a Merge ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/runtime/globals.hpp From john.r.rose at oracle.com Thu Apr 7 22:16:47 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 08 Apr 2011 05:16:47 +0000 Subject: hg: jdk7/hotspot/jdk: 6817525: turn on method handle functionality by default for JSR 292 Message-ID: <20110408051721.C2023478C8@hg.openjdk.java.net> Changeset: fa9c8e314f10 Author: jrose Date: 2011-04-07 22:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fa9c8e314f10 6817525: turn on method handle functionality by default for JSR 292 Summary: JVM bug 6817525 requires changes to some JDK unit tests; update test invocation flags and "Indify" snapshot Reviewed-by: kvn, twisti ! test/java/lang/invoke/6987555/Test6987555.java ! test/java/lang/invoke/6991596/Test6991596.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/MethodTypeTest.java ! test/java/lang/invoke/indify/Indify.java From erik.trimble at oracle.com Sat Apr 9 04:59:21 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Sat, 09 Apr 2011 11:59:21 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20110409115932.E060947926@hg.openjdk.java.net> Changeset: 9e6733fb56f8 Author: schien Date: 2011-04-07 15:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9e6733fb56f8 Added tag jdk7-b137 for changeset 2dbcb4a4d8da ! .hgtags Changeset: 987d9d10a30a Author: trims Date: 2011-04-08 15:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/987d9d10a30a Added tag hs21-b07 for changeset 2dbcb4a4d8da ! .hgtags Changeset: 24fbb4b7c2d3 Author: trims Date: 2011-04-08 16:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/24fbb4b7c2d3 Merge Changeset: 0930dc920c18 Author: trims Date: 2011-04-08 16:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0930dc920c18 7035259: Bump the HS21 build number to 08 Summary: Update the HS21 build number to 08 Reviewed-by: jcoomes ! make/hotspot_version From john.r.rose at oracle.com Sat Apr 9 21:40:37 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 10 Apr 2011 04:40:37 +0000 Subject: hg: jdk7/hotspot/jdk: 7019529: JSR292: java/dyn/ClassValueTest.java depends on sub-test execution order Message-ID: <20110410044121.3BFC947950@hg.openjdk.java.net> Changeset: fb1d421c1e97 Author: jrose Date: 2011-04-09 21:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fb1d421c1e97 7019529: JSR292: java/dyn/ClassValueTest.java depends on sub-test execution order Summary: Test should not use static variables, because they may contain stale values. Reviewed-by: twisti ! test/java/lang/invoke/ClassValueTest.java From john.r.rose at oracle.com Sun Apr 10 01:49:59 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 10 Apr 2011 08:49:59 +0000 Subject: hg: jdk7/hotspot/hotspot: 27 new changesets Message-ID: <20110410085048.065F74795D@hg.openjdk.java.net> Changeset: c2323e2ea62b Author: never Date: 2011-03-31 21:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c2323e2ea62b 6385687: UseFastEmptyMethods/UseFastAccessorMethods considered harmful Reviewed-by: kvn, jrose, phh ! src/share/vm/prims/jvmtiManageCapabilities.cpp ! src/share/vm/runtime/globals.hpp Changeset: f8b038506985 Author: never Date: 2011-04-01 21:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f8b038506985 6909440: C2 fails with assertion (_always_cold->is_cold(),"must always be cold") Reviewed-by: kvn ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp Changeset: 07acc51c1d2a Author: kvn Date: 2011-04-02 09:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/07acc51c1d2a 7032314: Allow to generate CallLeafNoFPNode in IdealKit Summary: Added CallLeafNoFPNode generation to IdealKit. Added i_o synchronization. Reviewed-by: never ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/library_call.cpp Changeset: 08eb13460b3a Author: kvn Date: 2011-04-02 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/08eb13460b3a 7004535: Clone loop predicate during loop unswitch Summary: Clone loop predicate for clonned loops Reviewed-by: never ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/ifnode.cpp + src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/split_if.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.hpp Changeset: 13bc79b5c9c8 Author: roland Date: 2011-04-03 12:00 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/13bc79b5c9c8 7033154: Improve C1 arraycopy performance Summary: better static analysis. Take advantage of array copy stubs. Reviewed-by: never ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp Changeset: e863062e521d Author: twisti Date: 2011-04-04 03:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e863062e521d 7032458: Zero and Shark fixes Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/globals_zero.hpp ! src/cpu/zero/vm/relocInfo_zero.cpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkCompiler.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp Changeset: 8b2317d732ec Author: never Date: 2011-04-04 12:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8b2317d732ec 7026957: assert(type2aelembytes(store->as_Mem()->memory_type(), true) == 1 << shift->in(2)->get_int()) failed Reviewed-by: kvn, jrose ! src/share/vm/opto/loopTransform.cpp Changeset: bb22629531fa Author: iveresov Date: 2011-04-04 16:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bb22629531fa 7033732: C1: When calling c2 arraycopy stubs offsets and length must have clear upper 32bits Summary: With 7033154 we started calling c2 arraycopy stubs from c1. On sparcv9 we must clear the upper 32bits for offset (src_pos, dst_pos) and length parameters when calling them. Reviewed-by: never, kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp Changeset: a54519951ff6 Author: iveresov Date: 2011-04-04 18:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a54519951ff6 Merge Changeset: 87ce328c6a21 Author: never Date: 2011-04-04 19:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/87ce328c6a21 6528013: C1 CTW failure with -XX:+VerifyOops assert(allocates2(pc),"") Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_LIRAssembler.cpp Changeset: fb37e3eabfd0 Author: never Date: 2011-04-04 22:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fb37e3eabfd0 Merge Changeset: d7a3fed1c1c9 Author: kvn Date: 2011-04-04 19:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d7a3fed1c1c9 7004547: regular loop unroll should not unroll more than max unrolling Summary: Take into account that after unroll conjoined heads and tails will fold. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp Changeset: 03f2be00fa21 Author: kvn Date: 2011-04-05 00:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/03f2be00fa21 Merge Changeset: 479b4b4b6950 Author: never Date: 2011-04-05 00:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/479b4b4b6950 6777083: assert(target != __null,"must not be null") Reviewed-by: iveresov, kvn ! src/cpu/x86/vm/assembler_x86.hpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp Changeset: 8e77e1f26188 Author: never Date: 2011-04-05 02:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8e77e1f26188 Merge Changeset: 527977d4f740 Author: never Date: 2011-04-05 19:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/527977d4f740 7033779: CodeCache::largest_free_block may need to hold the CodeCache lock Reviewed-by: kvn ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp Changeset: 98c560260039 Author: never Date: 2011-04-06 16:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/98c560260039 7034513: enable fast accessors and empty methods for ZERO and -Xint Reviewed-by: kvn, iveresov ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 55973726c600 Author: kvn Date: 2011-04-06 17:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/55973726c600 6992789: assert(phi->_idx >= nodes_size()) failed: only new Phi per instance memory slice Summary: Swap checks: check for regular memory slice first and keep input phi. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: ed69575596ac Author: jrose Date: 2011-04-07 17:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ed69575596ac 6981791: remove experimental code for JSR 292 Reviewed-by: twisti ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: 758ba0bf7bcc Author: jrose Date: 2011-04-07 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/758ba0bf7bcc 7012087: JSR 292 Misleading exception message for a non-bound MH for a virtual method Summary: Improve error message formatting to give more information to user. Also, catch a corner case related to 6930553 and 6844449. Reviewed-by: kvn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 4124a5a27707 Author: jrose Date: 2011-04-07 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4124a5a27707 7009600: JSR 292 Server compiler crashes in Compile::find_intrinsic(ciMethod*, bool) Summary: catch errors during the compile-time processing of method handles; back out cleanly Reviewed-by: twisti ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/opto/doCall.cpp Changeset: 3f49d30f8184 Author: never Date: 2011-04-07 21:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3f49d30f8184 7034957: acquiring lock CodeCache_lock/1 out of order with lock tty_lock/0 -- possible deadlock Reviewed-by: iveresov ! src/share/vm/code/codeCache.cpp Changeset: d86923d96dca Author: iveresov Date: 2011-04-08 17:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d86923d96dca 7034967: C1: assert(false) failed: error (assembler_sparc.cpp:2043) Summary: Fix -XX:+VerifyOops Reviewed-by: kvn, never ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 3af54845df98 Author: kvn Date: 2011-04-08 14:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3af54845df98 7004555: Add new policy for one iteration loops Summary: Add new policy for one iteration loops (mostly formal pre- loops). Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp Changeset: 46d145ee8e68 Author: kvn Date: 2011-04-08 20:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/46d145ee8e68 Merge Changeset: 3fa3c7e4d4f3 Author: never Date: 2011-04-08 23:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3fa3c7e4d4f3 7035161: assert(!o->is_null_object()) failed: null object not yet handled here. Reviewed-by: kvn ! src/share/vm/ci/ciInstance.cpp Changeset: 6c97c830fb6f Author: jrose Date: 2011-04-09 21:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6c97c830fb6f Merge ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp From xerxes at zafena.se Wed Apr 13 03:27:27 2011 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Wed, 13 Apr 2011 12:27:27 +0200 Subject: Review Request: Shark fails to find LLVM 2.9 System headers during build. Message-ID: <4DA57A8F.4050206@zafena.se> Hi all, In LLVM 2.9 llvm/System/Threading.h and llvm/System/Host.h have been moved to llvm/Support/Threading.h and llvm/Support/Host.h http://llvm.org/viewvc/llvm-project?view=rev&revision=120298 This webrev fix: http://labb.zafena.se/openjdk/shark-llvm-2.9/ I don't have a bug id for this. This are my first patch submission to hotspot-dev. I have signed the SCA. http://sca.java.net/CA_signatories.htm Cheers and have a great day! Xerxes From christian.thalinger at oracle.com Wed Apr 13 03:34:32 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 13 Apr 2011 12:34:32 +0200 Subject: Review Request: Shark fails to find LLVM 2.9 System headers during build. In-Reply-To: <4DA57A8F.4050206@zafena.se> References: <4DA57A8F.4050206@zafena.se> Message-ID: On Apr 13, 2011, at 12:27 PM, Xerxes R?nby wrote: > Hi all, > > In LLVM 2.9 > llvm/System/Threading.h and llvm/System/Host.h > have been moved to > llvm/Support/Threading.h and llvm/Support/Host.h > http://llvm.org/viewvc/llvm-project?view=rev&revision=120298 > > This webrev fix: > > http://labb.zafena.se/openjdk/shark-llvm-2.9/ > > I don't have a bug id for this. > > This are my first patch submission to hotspot-dev. > I have signed the SCA. > http://sca.java.net/CA_signatories.htm Looks good to me. Gary? It seems like this LLVM header thing is a great pain... -- Christian From gbenson at redhat.com Wed Apr 13 03:55:17 2011 From: gbenson at redhat.com (Gary Benson) Date: Wed, 13 Apr 2011 11:55:17 +0100 Subject: Review Request: Shark fails to find LLVM 2.9 System headers during build. In-Reply-To: References: <4DA57A8F.4050206@zafena.se> Message-ID: <20110413105517.GB5337@redhat.com> Christian Thalinger wrote: > On Apr 13, 2011, at 12:27 PM, Xerxes R?nby wrote: > > In LLVM 2.9 > > llvm/System/Threading.h and llvm/System/Host.h > > have been moved to > > llvm/Support/Threading.h and llvm/Support/Host.h > > http://llvm.org/viewvc/llvm-project?view=rev&revision=120298 > > > > This webrev fix: > > > > http://labb.zafena.se/openjdk/shark-llvm-2.9/ > > > > I don't have a bug id for this. > > > > This are my first patch submission to hotspot-dev. > > I have signed the SCA. > > http://sca.java.net/CA_signatories.htm > > Looks good to me. Gary? Looks good to me too. > It seems like this LLVM header thing is a great pain... You said it :) Cheers, Gary -- http://gbenson.net/ From christian.thalinger at oracle.com Wed Apr 13 04:19:09 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 13 Apr 2011 13:19:09 +0200 Subject: Review Request: Shark fails to find LLVM 2.9 System headers during build. In-Reply-To: <20110413105517.GB5337@redhat.com> References: <4DA57A8F.4050206@zafena.se> <20110413105517.GB5337@redhat.com> Message-ID: <0540CE06-0021-42C1-BED4-8856DC5C6BE3@oracle.com> On Apr 13, 2011, at 12:55 PM, Gary Benson wrote: > Christian Thalinger wrote: >> On Apr 13, 2011, at 12:27 PM, Xerxes R?nby wrote: >>> In LLVM 2.9 >>> llvm/System/Threading.h and llvm/System/Host.h >>> have been moved to >>> llvm/Support/Threading.h and llvm/Support/Host.h >>> http://llvm.org/viewvc/llvm-project?view=rev&revision=120298 >>> >>> This webrev fix: >>> >>> http://labb.zafena.se/openjdk/shark-llvm-2.9/ >>> >>> I don't have a bug id for this. 7036220: Shark fails to find LLVM 2.9 System headers during build -- Christian >>> >>> This are my first patch submission to hotspot-dev. >>> I have signed the SCA. >>> http://sca.java.net/CA_signatories.htm >> >> Looks good to me. Gary? > > Looks good to me too. > >> It seems like this LLVM header thing is a great pain... > > You said it :) > > Cheers, > Gary From xerxes at zafena.se Wed Apr 13 04:25:36 2011 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Wed, 13 Apr 2011 13:25:36 +0200 Subject: Review Request: Shark fails to find LLVM 2.9 System headers during build. In-Reply-To: <0540CE06-0021-42C1-BED4-8856DC5C6BE3@oracle.com> References: <4DA57A8F.4050206@zafena.se> <20110413105517.GB5337@redhat.com> <0540CE06-0021-42C1-BED4-8856DC5C6BE3@oracle.com> Message-ID: <4DA58830.6090601@zafena.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-04-13 13:19, Christian Thalinger wrote: > On Apr 13, 2011, at 12:55 PM, Gary Benson wrote: >> Christian Thalinger wrote: >>> On Apr 13, 2011, at 12:27 PM, Xerxes R?nby wrote: >>>> In LLVM 2.9 >>>> llvm/System/Threading.h and llvm/System/Host.h >>>> have been moved to >>>> llvm/Support/Threading.h and llvm/Support/Host.h >>>> http://llvm.org/viewvc/llvm-project?view=rev&revision=120298 >>>> >>>> This webrev fix: >>>> >>>> http://labb.zafena.se/openjdk/shark-llvm-2.9/ >>>> >>>> I don't have a bug id for this. > > 7036220: Shark fails to find LLVM 2.9 System headers during build > > -- Christian > Thank you Christian! What happens now? Cheers Xerxes >>>> >>>> This are my first patch submission to hotspot-dev. >>>> I have signed the SCA. >>>> http://sca.java.net/CA_signatories.htm >>> >>> Looks good to me. Gary? >> >> Looks good to me too. >> >>> It seems like this LLVM header thing is a great pain... >> >> You said it :) >> >> Cheers, >> Gary > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNpYgwAAoJEDcXY6gdvX/Qk4wH/0YkHPYoWBLE6QNqO2g4eKh3 I+yQ9mCwcmCI2qMJoHrWq7fnkuHPlIR/zOBYhY1ou3nsIQE4FGx3zs9IzmCe+NL+ bogpmmmPI3kgVZ9IkMTfP/cyptNlI8zT/+OXXDGTeCU7G/3rlmtVQFD1NqeUWWjY UaJgzvwY0AsX/5+VWc8/Zyduhaz5Y1mQhTCeOZNAv831BS0J+YO9aSVtHj48PSny 5big1j1yb7re7FZdpJTD21K4dgKU5Nwww5JgnrfT22aYyoVYZbRuHkhkBTe6ctrH bfaI5fR5VXc3XSfRlGClHHYwiW5O2hVJ9VxlM9zmLTvjLUBkWrKmZn3Vrk3dN9c= =LT+U -----END PGP SIGNATURE----- From chris.burroughs at gmail.com Wed Apr 13 18:30:28 2011 From: chris.burroughs at gmail.com (Chris Burroughs) Date: Wed, 13 Apr 2011 21:30:28 -0400 Subject: Debugging Resident Set Size growth Message-ID: <4DA64E34.9000800@gmail.com> Hello all. I am experiencing a problem with a java program on running 1.6.0_23 on RHEL5. The resident set size (as reported by /proc/$PID/status for example) of the process continues to grow. For example here [1] is the RES of the process from approximately the 24th to 72nd hours of operation with min and max heap equal to 1.5 GB. This corresponds to a an decrease in "-/+ buffers/cache free" memory as reported by `free`. Jconsole reports that the max heap limit is being respected. This continues over a few weeks until their is so little page cache that performance degrades or the kernel oom killer steps in. The program (Apache Cassandra) is not configured to use mmap or as far as I can tell anything improper with direct allocation. I understand that the JVM has internal structures that take memory, that GC can only periodically compact the heap, etc. However, unless I am missing something the RES should eventually (say within days) come down. This is the case with every other java program I have monitored, but again unless I'm missing something it should not be possible for any Java program to induce this different behaviour. Since bugs in the JVM or libc level seem unlikely I have been searching for a document along the lines of "you are probaly wrong, here are all the things you should do before claiming you found a memory leak in a JVM", but have been unable to find one. The "Java Trouble-Shooting and Diagnostic Guide" contains section on OOM Exceptions and JIN, but not hotspot itself. If someone could point me in the direction of one I would appreciate it. Short of that are there steps to make a useful bug report short of "run the program with valgrind for n days"? Thank you for your time, Chris Burroughs [1] http://img16.imageshack.us/img16/4813/cassandrarsssmooth.png From y.s.ramakrishna at oracle.com Wed Apr 13 18:55:37 2011 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Wed, 13 Apr 2011 18:55:37 -0700 Subject: Debugging Resident Set Size growth In-Reply-To: <4DA64E34.9000800@gmail.com> References: <4DA64E34.9000800@gmail.com> Message-ID: <4DA65419.8070701@oracle.com> Can you use pmap -x to see where and what the growth is in? For example, if your Java heap needs increase then the committed part of the heap will become resident as and when those pages are actually touched or used. So with a program that eventually grows to occupy the heap it's been given, one would eventually expect to reach 1.5 G and some more (for the perm gen, the C-heap and so forth). I am assuming that the unit on the y-axis of your graph is KB, so that at the right end of your graph you are reaching an RSS of a bit over 2 G. (I also assume from you description that your x-axis is about 72 hours, although there are no labels.) Did you look at the GC logs or at the Java heap with jmap or jconsole? In summary, without more detaiol, I do not see that there is necessarily a problem here to solve (although i do sympathise with the Linux OOM killer, I am sure it will not step in just because your RSS is 2 GB for a program that you seek to give 1.5 GB of java heap; how much RAM does your machine have?) -- ramki On 04/13/11 18:30, Chris Burroughs wrote: > Hello all. I am experiencing a problem with a java program on running > 1.6.0_23 on RHEL5. The resident set size (as reported by > /proc/$PID/status for example) of the process continues to grow. For > example here [1] is the RES of the process from approximately the 24th > to 72nd hours of operation with min and max heap equal to 1.5 GB. This > corresponds to a an decrease in "-/+ buffers/cache free" memory as > reported by `free`. Jconsole reports that the max heap limit is being > respected. This continues over a few weeks until their is so little > page cache that performance degrades or the kernel oom killer steps in. > > The program (Apache Cassandra) is not configured to use mmap or as far > as I can tell anything improper with direct allocation. I understand > that the JVM has internal structures that take memory, that GC can only > periodically compact the heap, etc. However, unless I am missing > something the RES should eventually (say within days) come down. This > is the case with every other java program I have monitored, but again > unless I'm missing something it should not be possible for any Java > program to induce this different behaviour. > > Since bugs in the JVM or libc level seem unlikely I have been searching > for a document along the lines of "you are probaly wrong, here are all > the things you should do before claiming you found a memory leak in a > JVM", but have been unable to find one. The "Java Trouble-Shooting and > Diagnostic Guide" contains section on OOM Exceptions and JIN, but not > hotspot itself. If someone could point me in the direction of one I > would appreciate it. > > Short of that are there steps to make a useful bug report short of "run > the program with valgrind for n days"? > > Thank you for your time, > Chris Burroughs > > [1] http://img16.imageshack.us/img16/4813/cassandrarsssmooth.png From christian.thalinger at oracle.com Thu Apr 14 01:40:54 2011 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 14 Apr 2011 10:40:54 +0200 Subject: Review Request: Shark fails to find LLVM 2.9 System headers during build. In-Reply-To: <4DA58830.6090601@zafena.se> References: <4DA57A8F.4050206@zafena.se> <20110413105517.GB5337@redhat.com> <0540CE06-0021-42C1-BED4-8856DC5C6BE3@oracle.com> <4DA58830.6090601@zafena.se> Message-ID: [Xerxes' mail didn't make it to the list.] On Apr 13, 2011, at 1:25 PM, Xerxes R?nby wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2011-04-13 13:19, Christian Thalinger wrote: >> On Apr 13, 2011, at 12:55 PM, Gary Benson wrote: >>> Christian Thalinger wrote: >>>> On Apr 13, 2011, at 12:27 PM, Xerxes R?nby wrote: >>>>> In LLVM 2.9 >>>>> llvm/System/Threading.h and llvm/System/Host.h >>>>> have been moved to >>>>> llvm/Support/Threading.h and llvm/Support/Host.h >>>>> http://llvm.org/viewvc/llvm-project?view=rev&revision=120298 >>>>> >>>>> This webrev fix: >>>>> >>>>> http://labb.zafena.se/openjdk/shark-llvm-2.9/ >>>>> >>>>> I don't have a bug id for this. >> >> 7036220: Shark fails to find LLVM 2.9 System headers during build >> >> -- Christian >> > > Thank you Christian! > What happens now? I will apply your patch, send it to our testing system (JPRT) and it will be pushed to hotspot-comp. -- Christian > > Cheers > Xerxes > >>>>> >>>>> This are my first patch submission to hotspot-dev. >>>>> I have signed the SCA. >>>>> http://sca.java.net/CA_signatories.htm >>>> >>>> Looks good to me. Gary? >>> >>> Looks good to me too. >>> >>>> It seems like this LLVM header thing is a great pain... >>> >>> You said it :) >>> >>> Cheers, >>> Gary >> >> >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJNpYgwAAoJEDcXY6gdvX/Qk4wH/0YkHPYoWBLE6QNqO2g4eKh3 > I+yQ9mCwcmCI2qMJoHrWq7fnkuHPlIR/zOBYhY1ou3nsIQE4FGx3zs9IzmCe+NL+ > bogpmmmPI3kgVZ9IkMTfP/cyptNlI8zT/+OXXDGTeCU7G/3rlmtVQFD1NqeUWWjY > UaJgzvwY0AsX/5+VWc8/Zyduhaz5Y1mQhTCeOZNAv831BS0J+YO9aSVtHj48PSny > 5big1j1yb7re7FZdpJTD21K4dgKU5Nwww5JgnrfT22aYyoVYZbRuHkhkBTe6ctrH > bfaI5fR5VXc3XSfRlGClHHYwiW5O2hVJ9VxlM9zmLTvjLUBkWrKmZn3Vrk3dN9c= > =LT+U > -----END PGP SIGNATURE----- From coleen.phillimore at oracle.com Thu Apr 14 13:41:17 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 14 Apr 2011 20:41:17 +0000 Subject: hg: jdk7/hotspot/hotspot: 9 new changesets Message-ID: <20110414204134.0B74047AAE@hg.openjdk.java.net> Changeset: 677234770800 Author: dsamersoff Date: 2011-03-30 19:38 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/677234770800 7017193: Small memory leak in get_stack_bounds os::create_stack_guard_pages Summary: getline() returns -1 but still allocate memory for str Reviewed-by: dcubed, coleenp ! src/os/linux/vm/os_linux.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp Changeset: b025bffd6c2c Author: dholmes Date: 2011-03-31 06:54 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b025bffd6c2c 7032775: Include Shark code in the build again Reviewed-by: ohair Contributed-by: gbenson at redhat.com, ahughes at redhat.com ! make/linux/makefiles/vm.make Changeset: 37be97a58393 Author: andrew Date: 2011-04-01 15:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/37be97a58393 7010849: 5/5 Extraneous javac source/target options when building sa-jdi Summary: Make code changes necessary to get rid of the '-source 1.4 -target 1.4' options. Reviewed-by: dholmes, dcubed ! agent/src/share/classes/sun/jvm/hotspot/HelloWorld.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/ByteValueImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/CharValueImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/ConnectorImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/DoubleValueImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/FieldImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/FloatValueImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/IntegerValueImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/LocalVariableImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/LocationImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/LongValueImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/MethodImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/ReferenceTypeImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/ShortValueImpl.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/VirtualMachineImpl.java ! make/linux/makefiles/sa.make ! make/solaris/makefiles/sa.make ! make/windows/makefiles/sa.make Changeset: 7144a1d6e0a9 Author: kamg Date: 2011-03-31 08:08 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7144a1d6e0a9 7030388: JCK test failed to reject invalid class check01304m10n. Summary: Restrict fix for 7020118 to only when checking exception handlers Reviewed-by: dcubed, dholmes ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.cpp Changeset: 11427f216063 Author: dholmes Date: 2011-04-04 18:15 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/11427f216063 7009276: Add -XX:+IgnoreUnrecognizedVMOptions to several tests Reviewed-by: kvn ! test/compiler/6795161/Test.java Changeset: 1dac0f3af89f Author: ohair Date: 2011-04-07 20:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1dac0f3af89f 7019210: Fix misc references to /bugreport websites Reviewed-by: skannan ! src/share/vm/runtime/arguments.cpp Changeset: c49c3947b98a Author: brutisso Date: 2011-04-11 11:12 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c49c3947b98a 7034625: Product builds in Visual Studio projects should produce full symbol information Summary: Add the /debug flag to the linker command in Visual Studio Reviewed-by: mgronlun, poonam, hosterda ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java Changeset: 6a615eae2f34 Author: dholmes Date: 2011-04-12 02:53 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6a615eae2f34 7034585: Adjust fillInStackTrace filtering to assist 6998871 Summary: Allow for one or more fillInStackTrace frames to be skipped Reviewed-by: mchung, kvn ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/vmSymbols.hpp Changeset: 3449f5e02cc4 Author: coleenp Date: 2011-04-12 14:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3449f5e02cc4 Merge ! make/linux/makefiles/vm.make ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/arguments.cpp From coleen.phillimore at oracle.com Fri Apr 15 09:04:10 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 15 Apr 2011 12:04:10 -0400 Subject: Debugging Resident Set Size growth In-Reply-To: <4DA64E34.9000800@gmail.com> References: <4DA64E34.9000800@gmail.com> Message-ID: <4DA86C7A.5050807@oracle.com> Hi, We had another unverifiable sighting of this sort, so I'd like to follow up and see if we can figure out what is going on. A couple of questions: 1. Was this not a problem with earlier releases of jdk6 on RHEL5? Did this just start with 1.6.0_23? 2. Running with valgrind would be a good idea. It has been used to find leaks in the VM in the past (6980262) but the VM mostly uses fixed memory in the permgen for internal VM structures and other fixed size arenas, so the leak may also be in the jdk native libraries or the application native libraries. This isn't really a hotspot open source development question, can you file a bug? http://java.sun.com/webapps/bugreport/crash.jsp Thanks, Coleen On 4/13/2011 9:30 PM, Chris Burroughs wrote: > Hello all. I am experiencing a problem with a java program on running > 1.6.0_23 on RHEL5. The resident set size (as reported by > /proc/$PID/status for example) of the process continues to grow. For > example here [1] is the RES of the process from approximately the 24th > to 72nd hours of operation with min and max heap equal to 1.5 GB. This > corresponds to a an decrease in "-/+ buffers/cache free" memory as > reported by `free`. Jconsole reports that the max heap limit is being > respected. This continues over a few weeks until their is so little > page cache that performance degrades or the kernel oom killer steps in. > > The program (Apache Cassandra) is not configured to use mmap or as far > as I can tell anything improper with direct allocation. I understand > that the JVM has internal structures that take memory, that GC can only > periodically compact the heap, etc. However, unless I am missing > something the RES should eventually (say within days) come down. This > is the case with every other java program I have monitored, but again > unless I'm missing something it should not be possible for any Java > program to induce this different behaviour. > > Since bugs in the JVM or libc level seem unlikely I have been searching > for a document along the lines of "you are probaly wrong, here are all > the things you should do before claiming you found a memory leak in a > JVM", but have been unable to find one. The "Java Trouble-Shooting and > Diagnostic Guide" contains section on OOM Exceptions and JIN, but not > hotspot itself. If someone could point me in the direction of one I > would appreciate it. > > Short of that are there steps to make a useful bug report short of "run > the program with valgrind for n days"? > > Thank you for your time, > Chris Burroughs > > [1] http://img16.imageshack.us/img16/4813/cassandrarsssmooth.png From y.s.ramakrishna at oracle.com Fri Apr 15 09:37:39 2011 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Fri, 15 Apr 2011 09:37:39 -0700 Subject: Debugging Resident Set Size growth In-Reply-To: <4DA65419.8070701@oracle.com> References: <4DA64E34.9000800@gmail.com> <4DA65419.8070701@oracle.com> Message-ID: <4DA87453.806@oracle.com> On 4/13/2011 6:55 PM, Y. S. Ramakrishna wrote: > Can you use pmap -x to see where and what the growth is in? BTW, did you ever happen to get the pmap's to see where the growth was happening? -- ramki > For example, if your Java heap needs increase then the > committed part of the heap will become resident as and > when those pages are actually touched or used. So > with a program that eventually grows to occupy the heap > it's been given, one would eventually expect to reach 1.5 G > and some more (for the perm gen, the C-heap and so forth). > I am assuming that the unit on the y-axis of your graph is > KB, so that at the right end of your graph you are > reaching an RSS of a bit over 2 G. (I also assume from > you description that your x-axis is about 72 hours, although > there are no labels.) > > Did you look at the GC logs or at the Java heap with jmap or jconsole? > > In summary, without more detaiol, I do not see that there is > necessarily a problem here to solve (although i do sympathise > with the Linux OOM killer, I am sure it will not step in > just because your RSS is 2 GB for a program that you seek > to give 1.5 GB of java heap; how much RAM does your machine > have?) > > -- ramki > > On 04/13/11 18:30, Chris Burroughs wrote: >> Hello all. I am experiencing a problem with a java program on running >> 1.6.0_23 on RHEL5. The resident set size (as reported by >> /proc/$PID/status for example) of the process continues to grow. For >> example here [1] is the RES of the process from approximately the 24th >> to 72nd hours of operation with min and max heap equal to 1.5 GB. This >> corresponds to a an decrease in "-/+ buffers/cache free" memory as >> reported by `free`. Jconsole reports that the max heap limit is being >> respected. This continues over a few weeks until their is so little >> page cache that performance degrades or the kernel oom killer steps in. >> >> The program (Apache Cassandra) is not configured to use mmap or as far >> as I can tell anything improper with direct allocation. I understand >> that the JVM has internal structures that take memory, that GC can only >> periodically compact the heap, etc. However, unless I am missing >> something the RES should eventually (say within days) come down. This >> is the case with every other java program I have monitored, but again >> unless I'm missing something it should not be possible for any Java >> program to induce this different behaviour. >> >> Since bugs in the JVM or libc level seem unlikely I have been searching >> for a document along the lines of "you are probaly wrong, here are all >> the things you should do before claiming you found a memory leak in a >> JVM", but have been unable to find one. The "Java Trouble-Shooting and >> Diagnostic Guide" contains section on OOM Exceptions and JIN, but not >> hotspot itself. If someone could point me in the direction of one I >> would appreciate it. >> >> Short of that are there steps to make a useful bug report short of "run >> the program with valgrind for n days"? >> >> Thank you for your time, >> Chris Burroughs >> >> [1] http://img16.imageshack.us/img16/4813/cassandrarsssmooth.png From chris.burroughs at gmail.com Fri Apr 15 11:42:00 2011 From: chris.burroughs at gmail.com (Chris Burroughs) Date: Fri, 15 Apr 2011 14:42:00 -0400 Subject: Debugging Resident Set Size growth In-Reply-To: <4DA86C7A.5050807@oracle.com> References: <4DA64E34.9000800@gmail.com> <4DA86C7A.5050807@oracle.com> Message-ID: <4DA89178.1080807@gmail.com> On 04/15/2011 12:04 PM, Coleen Phillimore wrote: > Hi, > We had another unverifiable sighting of this sort, so I'd like to follow > up and see if we can figure out what is going on. A couple of questions: > Thanks, as I said in the ticket below I know there probably isn't enough to figure out the problem, but I'm happy to set up further instrumentation as needed. > 1. Was this not a problem with earlier releases of jdk6 on RHEL5? Did > this just start with 1.6.0_23? > It occurred with 1.6.0_20 as well. > 2. Running with valgrind would be a good idea. It has been used to > find leaks in the VM in the past (6980262) but the VM mostly uses fixed > memory in the permgen for internal VM structures and other fixed size > arenas, so the leak may also be in the jdk native libraries or the > application native libraries. > I'll look into doing this. > This isn't really a hotspot open source development question, can you > file a bug? > http://java.sun.com/webapps/bugreport/crash.jsp > Created but not yet visible. I'll move any further discussion there: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7037080 From chris.burroughs at gmail.com Fri Apr 15 11:52:11 2011 From: chris.burroughs at gmail.com (Chris Burroughs) Date: Fri, 15 Apr 2011 14:52:11 -0400 Subject: Debugging Resident Set Size growth In-Reply-To: <4DA65419.8070701@oracle.com> References: <4DA64E34.9000800@gmail.com> <4DA65419.8070701@oracle.com> Message-ID: <4DA893DB.7010208@gmail.com> Thanks you for your suggestions. I didn't think to use pmap before. On 04/13/2011 09:55 PM, Y. S. Ramakrishna wrote: > Can you use pmap -x to see where and what the growth is in? Individual calls to pmap as of right now. Will look into measuring changes over time. http://pastebin.com/G0SQ7mQQ http://pastebin.com/ARPF8gPk > > Did you look at the GC logs or at the Java heap with jmap or jconsole? > I don't see GC large looking pauses dangerous looking GC pressure, or running close to max heap size from logs or jconsole. > In summary, without more detaiol, I do not see that there is > necessarily a problem here to solve (although i do sympathise > with the Linux OOM killer, I am sure it will not step in > just because your RSS is 2 GB for a program that you seek > to give 1.5 GB of java heap; how much RAM does your machine > have?) > Box has 4 GB of RAM, 2 GB swap. There is another .5 gig java (tomcat) process. As requested I'll move further discussion here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7037080 From john.r.rose at oracle.com Fri Apr 15 18:12:16 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 16 Apr 2011 01:12:16 +0000 Subject: hg: jdk7/hotspot/hotspot: 8 new changesets Message-ID: <20110416011231.B16D347B1C@hg.openjdk.java.net> Changeset: 328926869b15 Author: jrose Date: 2011-04-09 22:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/328926869b15 6987991: JSR 292 phpreboot test/testtracefun2.phpr segfaults Summary: Make MH verification tests more correct, robust, and informative. Fix lingering symbol refcount problems. Reviewed-by: twisti ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp Changeset: 15c9a0e16269 Author: kvn Date: 2011-04-11 15:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/15c9a0e16269 7035713: 3DNow Prefetch Instruction Support Summary: The upcoming processors from AMD are the first that support 3dnow prefetch without supporting the 3dnow instruction set. Reviewed-by: kvn Contributed-by: tom.deneau at amd.com ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad Changeset: 4b95bbb36464 Author: twisti Date: 2011-04-12 02:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4b95bbb36464 7035870: JSR 292: Zero support Summary: This adds support for JSR 292 to Zero. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/bytecodeInterpreter_zero.hpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp ! src/cpu/zero/vm/interpreter_zero.cpp ! src/cpu/zero/vm/methodHandles_zero.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp Changeset: 3a808be061ff Author: iveresov Date: 2011-04-13 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3a808be061ff 6988308: assert((cnt > 0.0f) && (prob > 0.0f)) failed: Bad frequency assignment in if Summary: Make sure cnt doesn't become negative and integer overflow doesn't happen. Reviewed-by: kvn, twisti ! src/share/vm/opto/parse2.cpp Changeset: dbccacb79c63 Author: iveresov Date: 2011-04-14 00:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/dbccacb79c63 7036236: VM crashes assert((!inside_attrs()) || is_error_reported()) failed ... Summary: Eliminate the race condition. Reviewed-by: kvn ! src/share/vm/code/codeCache.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/sweeper.cpp Changeset: 1fcd6e9c3965 Author: twisti Date: 2011-04-14 01:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1fcd6e9c3965 7036220: Shark fails to find LLVM 2.9 System headers during build Reviewed-by: gbenson, twisti Contributed-by: Xerxes Ranby ! src/share/vm/shark/llvmHeaders.hpp Changeset: e9b9554f7fc3 Author: twisti Date: 2011-04-14 06:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e9b9554f7fc3 Merge Changeset: 97e8046e2562 Author: jrose Date: 2011-04-15 08:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/97e8046e2562 Merge From David.Holmes at oracle.com Fri Apr 15 20:32:36 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 16 Apr 2011 13:32:36 +1000 Subject: Debugging Resident Set Size growth In-Reply-To: <4DA893DB.7010208@gmail.com> References: <4DA64E34.9000800@gmail.com> <4DA65419.8070701@oracle.com> <4DA893DB.7010208@gmail.com> Message-ID: <4DA90DD4.7020204@oracle.com> Chris, Chris Burroughs said the following on 04/16/11 04:52: > As requested I'll move further discussion here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7037080 That isn't a discussion forum. Discussion can continue here, or offline with individuals. Further info can be used to update the bug report. David From lux-integ at btconnect.com Mon Apr 18 10:32:33 2011 From: lux-integ at btconnect.com (luxInteg) Date: Mon, 18 Apr 2011 18:32:33 +0100 Subject: howto jvn openjdk-b138 64bit amd64 Message-ID: <201104181832.33243.lux-integ@btconnect.com> Greetings, I just 'built?' openJDK-b138 on a computer with these (cpu amd64, OS bblfs 64-bit lnux, gcc-4.5.2, make 3.82,Xorg-7.6 I had some help from the build-list) I installed the j2sdk-image like so cd build/linux-amd64/j2sdk-image cp -vR bin include jre lib man demo /path/to/wherever chmod root:root /path/to/wherever when I then tried to run ant ( with ant -v ) I discovered there is no j-vm " There was an error trying to initialize the HPI library. Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. #--------- an ls of ~/jre/bin shows there is no jvm root [ /opt/openJDK/jre/bin ]# ls -l total 244 -rwxr-xr-x 1 root root 6832 Apr 17 22:40 java -rwxr-xr-x 1 root root 7023 Apr 17 22:40 keytool -rwxr-xr-x 1 root root 7215 Apr 17 22:40 orbd -rwxr-xr-x 1 root root 7055 Apr 17 22:40 pack200 -rwxr-xr-x 1 root root 7071 Apr 17 22:40 policytool -rwxr-xr-x 1 root root 7023 Apr 17 22:40 rmid -rwxr-xr-x 1 root root 7023 Apr 17 22:40 rmiregistry -rwxr-xr-x 1 root root 7039 Apr 17 22:40 servertool -rwxr-xr-x 1 root root 7247 Apr 17 22:40 tnameserv -rwxr-xr-x 1 root root 170103 Apr 17 22:40 unpack200 root [ /opt/openJDK/jre/bin ] A closer inspection of the prebuild sanity check showed WARNING: You are not building the HOTSPOT sources. Hotspot libs will be obtained from the location set in ALT_HOTSPOT_IMPORT_PATH. All attempts to set build variables (for HOTSPOT-building) descrided in the build.html file have not been successful. I would be grateful for some advice of how a JVM can be built from the current sources of openjdk7. yours sincerely luxInteg From David.Holmes at oracle.com Mon Apr 18 18:25:13 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 19 Apr 2011 11:25:13 +1000 Subject: howto jvn openjdk-b138 64bit amd64 In-Reply-To: <201104181832.33243.lux-integ@btconnect.com> References: <201104181832.33243.lux-integ@btconnect.com> Message-ID: <4DACE479.20307@oracle.com> I've answered this back on the build list where it was originally asked. David luxInteg said the following on 04/19/11 03:32: > Greetings, > > I just 'built?' openJDK-b138 on a computer with these > (cpu amd64, OS bblfs 64-bit lnux, gcc-4.5.2, make 3.82,Xorg-7.6 I had some > help from the build-list) > > I installed the j2sdk-image like so > > cd build/linux-amd64/j2sdk-image > cp -vR bin include jre lib man demo /path/to/wherever > chmod root:root /path/to/wherever > > when I then tried to run ant ( with ant -v ) I discovered there is no j-vm > " > There was an error trying to initialize the HPI library. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > #--------- an ls of ~/jre/bin shows there is no jvm > > root [ /opt/openJDK/jre/bin ]# ls -l > total 244 > -rwxr-xr-x 1 root root 6832 Apr 17 22:40 java > -rwxr-xr-x 1 root root 7023 Apr 17 22:40 keytool > -rwxr-xr-x 1 root root 7215 Apr 17 22:40 orbd > -rwxr-xr-x 1 root root 7055 Apr 17 22:40 pack200 > -rwxr-xr-x 1 root root 7071 Apr 17 22:40 policytool > -rwxr-xr-x 1 root root 7023 Apr 17 22:40 rmid > -rwxr-xr-x 1 root root 7023 Apr 17 22:40 rmiregistry > -rwxr-xr-x 1 root root 7039 Apr 17 22:40 servertool > -rwxr-xr-x 1 root root 7247 Apr 17 22:40 tnameserv > -rwxr-xr-x 1 root root 170103 Apr 17 22:40 unpack200 > root [ /opt/openJDK/jre/bin ] > > > A closer inspection of the prebuild sanity check showed > > WARNING: You are not building the HOTSPOT sources. > Hotspot libs will be obtained from > the location set in ALT_HOTSPOT_IMPORT_PATH. > > All attempts to set build variables (for HOTSPOT-building) descrided in > the build.html file have not been successful. > > I would be grateful for some advice of how a JVM can be built from the > current sources of openjdk7. > > yours sincerely > luxInteg From lists at laerad.com Tue Apr 19 12:31:39 2011 From: lists at laerad.com (Benedict Elliott Smith) Date: Tue, 19 Apr 2011 20:31:39 +0100 Subject: Poor G1 performance when no collection possible Message-ID: Hi, I've been comparing the GC overhead of a couple of algorithms under different GC settings, and I have found what seems to be fairly negative behaviour from G1, which I would like to understand if possible. Firstly, if I allocate a huge number of objects and guarantee that none of them can be reclaimed, G1 will still spend a huge amount of energy (around about 50% of the real time of the test, more if I parallelise the test) attempting to collect nothing at all. This is the main head scratcher; in fact, many of the collections indicate negative work being achieved (e.g. [GC pause (young) 1221M->1222M(3044M), 0.1388195 secs]). The second issue is that the only difference between the two algorithms wrt garbage collection, when running the test serially, is that one of them jumbles up new and old object pointers, whereas the other doesn't. This seems to have a really drastic effect on the performance of G1, as the break down below shows. The first two lines of each section are the time spent doing non-GC and GC work respectively; the second two lines indicate the amount of space reclaimed in total by all of the GCs combined ("orig samples" indicates the number of distinct GCs performed). These are relatively brief tests, but after giving everything a couple of runs through to warm up, and the behaviour I'm seeing is very consistent across repeats. Test1 EXCL. GC (ms): total=43982, avg=21991, stdev=314 Test1 GC (ms): total=42322, avg=21161, stdev=299 Test1 partial (K): total=1000, avg=500, stdev=500, repeats=2 (orig samples=2) Test1 young (K): total=-33000, avg=-16500, stdev=3500, repeats=2 (orig samples=1010) Test2 EXCL. GC (ms): total=43838, avg=21919, stdev=133 Test2 GC (ms): total=49132, avg=12283, stdev=8880 Test2 partial (K): total=6000, avg=3000, stdev=3000, repeats=2 (orig samples=1) Test2 young (K): total=-20000, avg=-10000, stdev=1000, repeats=2 (orig samples=80) So, would you say this behaviour is expected? Cheers, Benedict P.S. I have uploaded the verbose gc log output from a separate run, in case that offers any useful information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110419/5ec2f915/attachment.html From chris.burroughs at gmail.com Mon Apr 11 13:10:46 2011 From: chris.burroughs at gmail.com (Chris Burroughs) Date: Mon, 11 Apr 2011 16:10:46 -0400 Subject: Debugging Resident Set Size growth Message-ID: <4DA36046.2030003@gmail.com> Hello all. I am experiencing a problem with a java program on running 1.6.0_23 on RHEL5. The resident set size (as reported by /proc/$PID/status for example) of the process continues to grow. For example here [1] is the RES of the process from approximately the 24th to 72nd hours of operation with min and max heap equal to 1.5 GB. This corresponds to a an decrease in "-/+ buffers/cache free" memory as reported by `free`. Jconsole reports that the max heap limit is being respected. This continues over a few weeks until their is so little page cache that performance degrades or the kernel oom killer steps in. The program (Apache Cassandra) is not configured to use mmap or as far as I can tell anything improper with direct allocation. I understand that the JVM has internal structures that take memory, that GC can only periodically compact the heap, etc. However, unless I am missing something the RES should eventually (say within days) come down. This is the case with every other java program I have monitored, but again unless I'm missing something it should not be possible for any Java program to induce this different behaviour. Since bugs in the JVM or libc level seem unlikely I have been searching for a document along the lines of "you are probaly wrong, here are all the things you should do before claiming you found a memory leak in a JVM", but have been unable to find one. The "Java Trouble-Shooting and Diagnostic Guide" contains section on OOM Exceptions and JIN, but not hotspot itself. If someone could point me in the direction of one I would appreciate it. Short of that are there steps to make a useful bug report short of "run the program with valgrind for n days"? Thank you for your time, Chris Burroughs [1] http://img16.imageshack.us/img16/4813/cassandrarsssmooth.png From arlinenn at miscgroup.com Tue Apr 19 11:09:06 2011 From: arlinenn at miscgroup.com (=?Windows-1251?B?0mHp7C3s5e1l5Obs5e3y?=) Date: Tue, 19 Apr 2011 22:09:06 +0400 Subject: =?Windows-1251?B?0+9wYeLr5e3o5SDicOXsZe3l7A==?= Message-ID: <398226756.20110419431523@miscgroup.com> > ????-?EH??????? ??? ?EP??? ??? > C????a? ? 27 ???e?? ? 2011 ?. > ?. ??e? ? ?????. ????e??o 4 ? o???? ?Ca??? ????p????? > ?e?.: (044) 223-4882 ? 223-5141 -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- ??????????c?? ?a?o?? ?pe??p????? ?a 80% ????c?? o? ????o? ?????????o??? ??p???? ???a. ?a? ???o???????? ????a??? ??pa????? ??o?? ?pe?????, ?a?a???? ???e??????? c?c???? ?o??po?? ?op??????, ????p??? c?a??a??? ????-???e??????? ? p??o?? ?o?p???????? ??E??? * ??e? ?p??????????? - (?o????) ?????a?o? p?c???????? ?? (?a?? ???e???e??)-????????, ???o?????? ????-?e?e????????? coo???????, ????a???? ?????e??e?? ? ???ep???? ?p?e??? ?o ???a??e??? ?pe????? ? Improvement.ru. P??o?o?????? ?op?o???????? ??-?p?e???? ? ?e????? ?o??????x, ?????pe???? ????a????????? ?o?????? ?Op????????? ?pe????? ? e??????????? ? ?oc???, ??e??a???????????? ?c??????e???o ?a ???????e ????-?e?????????. B ?P??????? * ?e?e?o???????, o????, ??pa?????? ??ep???? * ??????e? ? ??????a???e? ?e?? * ???????p?????? ?????x ?e??oc??? * ????a? ??cc?? * ?a???? ?a????? ? ??p?????? ?e??? ? ?????c?????? ??p???????? * ??p??????? ?a?o??? ?a?p???o? * ?ex?o????? ???????????o o????? ? p????? ???o???? ??? * Pa?o?? c ?p?????? ?????c??????? ??e?o????????? ?a?a?a?? * P??o?? c ?e????????? ?a?a???? * ?P???????? ?a?????? * H???????? ?a ???o??e??? ???p?e???? ?a??? * K???p??? ??ep??????? ?op??????, ??c?p???? ?e?????????? * ????e?? ?????o?? o?e???????? ?o??????? ?a ?a?e Outlook * ?????e??e o????o? ?o ??p??e???? ? pa????? ?c??????e???, ?po?????, ?a?????????, ? ?.?. * C???? c?c???? ?o?????? ??p?????? c ?o???a???? ??p?????? ? ?c??????e?????? ??c???????? * Ha??????? c???????????: ?c?????? ????ec-??????, ????p?? ????o ?pe?o???? o? ?????x ?o?o????o? * ????????e???? o?????o??? ?o p??????? ?pe???? ?a ?c?pe?? c ?o?????????? ? ???e????? * ???e??? ?o??a???o? ?a??, ????o??e??? o ???x ????e???, ?po?e??????????? ??a??????? * ??????o??? ???pe?, ???a????????, ?epo??????? ? coo????????? c? ??a??a???? pa???? ce?????????? * Ko??????????? ?????a??? ????-?e?e??????? * ?p?????? ?????e??? ??a??-???????????? ?a?????? ? ?o??a??? * ??p? ?o?? ?a???e????: ?a? ??e???? ??e??e??? ?? p????????????? * C?p?????? ?o??o???????? ??-c????a???? * C?a??a??? ??a??po????? ??e???? * C???????? ?????o?e?????? ? ?e?e????? ???o??a??? * C????a??? ?o???????? ? ?p?????? ?a?a? * ??a?a? a????????????? - ?a??????? ?o?o??x ?o?? ??? ?o???e??? ? o?????o??? * ?o???????????????? ??e?pe??? ??a??a??? ? ????a??? * ?o?????? ???a????? ? ?o????p??? ??oe???? c ?o????? ?????????-?a?? * ?a?o??e ?p?????? ??c??????? ? pa?o?? ???e??e??-???? * ???a??? ????e????? ? ?o??o??o??? ??o?????? Mind Manager 8 * ?p?????? ?oc??????? ??p? ? Mind Manager 8: ????p?????? ???a, ?e???, ?c????????, ????e??a???, ?c???? ? ?p. * C???a??? c???????? ? ????e ?a??? MindManager * ?o???o???? ??oe???? ? ??????o??????? ?e?????????? ?o?????? c ?o?o??? MindManager. ?E??B?? A???????? * K ???c??? ? ??e????e ?p???a?????? ?e?e??????? ??pe??o??, ????e???? ?o??a??? ? p??o???????? ??c?e?o ??e?a. O??????? ?E?? * ????a? ???e?????o??? ??p?o?? ???a: ?????e??e ???e???? ??e????, ?????e??e ?o??o??????????? ???e??p??????? ???a?, ?????????oe ?c?????o????? ????o???a ? ?ap?a????? ???????ep?, pe??a????? ????po?? ?a??? ??? ?e?p?????, ? ?.?. * B?e?????? ?a??-???e??????? ? pa???? ??????????x: ???-?a?????? ? pa?????? ?o??????????? ??????p?; ?o??????e ? ?op?o???????? ??-c?a??????; a????????? ??-?a????? ???c?????. K???O?? ?????H??? ?PE???????????? * Ko???e?? ??????-?e?????????? ???ep?????; * ????o? o ?o???e??? ????????a??? ?o ?a???? ?e??????. ?E??A???? * 9.30-18.00 * ??p???? 13.30-14.30 * ?e????????? c 9.00 ? xo???. ??O??O??? * 3200.00 ?p?. ?a ?????o ???c?????. * ??? ??op??? ? ?pe??e?? ??ac????a c????? ? 5% ? 7% c?????????????. * B c????o??? ?x????: ???op????????-???????????????? o???????a??? ?a c????a??, ???p??? ?a?ep?????, ?o??-?????, o?e? ? p????????, o?c???e??? ?o????o? ? ???e? ??e????? c ?e??op??. ??KA?????? O? PAC????? * ???????e, e??? ??o ??c??o ?p??????o Ba? ??????c???. * ?a? a??e? ???? ?? o??p???? ?c????????: ?a? ?a???x ?????p?????, ?o?????, ?e?-?a???? ? ?. ?. * ??o?? ?????a???? o? p?c?????, ???a??????, co?????? ?a? ?a? ??e???????? ???e? ?o ?e?e?o??. PE??C?????? * ?e?.: (044) 223-4882 ? 223-5141 * ?a??: (044) 280-1044 * K????? ??ac???? ?e???a?? ?o???a?? ??x?a???????? ?o???e?? ? op????a?? ?????e??o?: ???o?o?, a??, ??????a? ????a, ?o??? ????e?e?????. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110419/b63df16a/attachment.html From xerxes at zafena.se Wed Apr 20 07:00:22 2011 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Wed, 20 Apr 2011 16:00:22 +0200 Subject: Review Request: Regression Shark fails to JIT in hs20 Message-ID: <4DAEE6F6.7090704@zafena.se> Hi Shark JIT fails to work when using HotSpot 20. This webrev fix by backporting Shark fixes from OpenJDK bug 7032458. http://labb.zafena.se/openjdk/pr690-shark-jit-regression-hs20/ The webrev are made against hsx20 http://hg.openjdk.java.net/hsx/hsx20/master/ I don't have a bug id for this. Cheers Xerxes From xerxes at zafena.se Wed Apr 20 07:00:32 2011 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Wed, 20 Apr 2011 16:00:32 +0200 Subject: Review Request: Regression Zero fails to handle fast_aldc and fast_aldc_w in hs20 Message-ID: <4DAEE700.6010501@zafena.se> Hi hs20 uses two new internal instructions fast_aldc and fast_aldc_w. see: openjdk/hotspot/src/share/vm/interpreter/bytecodes.hpp This webrev fix by backporting Zero fixes from OpenJDK bug 7032458 and 7030207. http://labb.zafena.se/openjdk/pr696-zero-fast_aldc-and-fast_aldc_w-regression-hs20/ The webrev are made against hsx20 http://hg.openjdk.java.net/hsx/hsx20/master/ I don't have a bug id for this. Cheers Xerxes From ahughes at redhat.com Wed Apr 20 15:38:51 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 20 Apr 2011 23:38:51 +0100 Subject: Review Request: Regression Shark fails to JIT in hs20 In-Reply-To: <4DAEE6F6.7090704@zafena.se> References: <4DAEE6F6.7090704@zafena.se> Message-ID: <20110420223851.GU29985@rivendell.middle-earth.co.uk> On 16:00 Wed 20 Apr , Xerxes R?nby wrote: > Hi > > Shark JIT fails to work when using HotSpot 20. > > This webrev fix by backporting Shark fixes from OpenJDK bug 7032458. > http://labb.zafena.se/openjdk/pr690-shark-jit-regression-hs20/ > > The webrev are made against hsx20 > http://hg.openjdk.java.net/hsx/hsx20/master/ > > I don't have a bug id for this. > AIUI, commits to hs20 are only allowed by Oracle employees. At least, that's what I've been told in the past. So this will need to go into the OpenJDK6 HotSpot tree once hs20 is merged. If this is a backport of 7032458, why do you need a bug ID? As a side note, the server you are uploading the webrev to does not have mime types set up correctly. I couldn't view the patch without being asked to download it. It is viewable on cr.openjdk.java.net. Is there a reason you aren't using this? > Cheers > Xerxes -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Wed Apr 20 15:39:23 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 20 Apr 2011 23:39:23 +0100 Subject: Review Request: Regression Zero fails to handle fast_aldc and fast_aldc_w in hs20 In-Reply-To: <4DAEE700.6010501@zafena.se> References: <4DAEE700.6010501@zafena.se> Message-ID: <20110420223922.GV29985@rivendell.middle-earth.co.uk> On 16:00 Wed 20 Apr , Xerxes R?nby wrote: > Hi > > hs20 uses two new internal instructions fast_aldc and fast_aldc_w. > see: openjdk/hotspot/src/share/vm/interpreter/bytecodes.hpp > > This webrev fix by backporting Zero fixes from OpenJDK bug 7032458 and 7030207. > http://labb.zafena.se/openjdk/pr696-zero-fast_aldc-and-fast_aldc_w-regression-hs20/ > > The webrev are made against hsx20 > http://hg.openjdk.java.net/hsx/hsx20/master/ > > I don't have a bug id for this. > > Cheers > Xerxes Why are you merging together two different changesets? -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From coleen.phillimore at oracle.com Wed Apr 20 16:24:10 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 20 Apr 2011 23:24:10 +0000 Subject: hg: jdk7/hotspot/hotspot: 8 new changesets Message-ID: <20110420232425.09AF947CBB@hg.openjdk.java.net> Changeset: 5504afd15955 Author: zgu Date: 2011-04-14 11:50 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5504afd15955 7033100: CreateMinidumpOnCrash does not work for failed asserts Summary: Passing NULL as MINIDUMP_EXCEPTION_INFORMATION when calling MiniDumpWriteDump when crash is due to assertion instead of real exception to avoid creating zero-length mini dump file. Reviewed-by: acorn, dcubed, poonam, coleenp ! src/os/windows/vm/os_windows.cpp Changeset: 6c9cec219ce4 Author: vladidan Date: 2011-04-11 23:02 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6c9cec219ce4 7005865: Crash when running with PrintIRWithLIR Summary: the failure is caused by uninitialized bci number Reviewed-by: iveresov ! src/share/vm/c1/c1_Instruction.cpp Changeset: c737922fd8bb Author: vladidan Date: 2011-04-12 10:32 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c737922fd8bb Merge Changeset: 208b6c560ff4 Author: vladidan Date: 2011-04-14 11:02 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/208b6c560ff4 Merge ! src/share/vm/c1/c1_Instruction.cpp Changeset: a534c140904e Author: vladidan Date: 2011-04-14 23:06 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a534c140904e Merge Changeset: 8ce625481709 Author: coleenp Date: 2011-04-15 09:36 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8ce625481709 7032407: Crash in LinkResolver::runtime_resolve_virtual_method() Summary: Make CDS reorder vtables so that dump time vtables match run time order, so when redefine classes reinitializes them, they aren't in the wrong order. Reviewed-by: dcubed, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp Changeset: fcc932c8238c Author: thurka Date: 2011-04-16 11:59 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fcc932c8238c 7007254: NullPointerException occurs with jvisualvm placed under a dir. including Japanese chars Summary: use java_lang_String::create_from_platform_dependent_str() instead of java_lang_String::create_from_str() in JvmtiEnv::AddToSystemClassLoaderSearch() Reviewed-by: dcubed ! src/share/vm/prims/jvmtiEnv.cpp Changeset: df8a1555b1ea Author: coleenp Date: 2011-04-19 20:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/df8a1555b1ea Merge From xerxes at zafena.se Wed Apr 20 16:43:04 2011 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Thu, 21 Apr 2011 01:43:04 +0200 Subject: Review Request: Regression Shark fails to JIT in hs20 In-Reply-To: <20110420223851.GU29985@rivendell.middle-earth.co.uk> References: <4DAEE6F6.7090704@zafena.se> <20110420223851.GU29985@rivendell.middle-earth.co.uk> Message-ID: <4DAF6F88.5040705@zafena.se> On 2011-04-21 00:38, Dr Andrew John Hughes wrote: > On 16:00 Wed 20 Apr , Xerxes R?nby wrote: >> Hi >> >> Shark JIT fails to work when using HotSpot 20. >> >> This webrev fix by backporting Shark fixes from OpenJDK bug 7032458. >> http://labb.zafena.se/openjdk/pr690-shark-jit-regression-hs20/ >> >> The webrev are made against hsx20 >> http://hg.openjdk.java.net/hsx/hsx20/master/ >> >> I don't have a bug id for this. >> > > AIUI, commits to hs20 are only allowed by Oracle employees. > At least, that's what I've been told in the past. So this > will need to go into the OpenJDK6 HotSpot tree once hs20 is > merged. I agree its not clear how to file patches for regressions to the hsXX branches. I got recommended by Chris Phillips on IRC to send in the patch for review with a long cc list. > > If this is a backport of 7032458, why do you need a bug ID? 7032458 contains more than one fix (one zero fix, this shark fix and one parts that do not belong in hs20 at all). Preferably i would like a bug ID that handles this Shark regression for the hs20 branch. > > As a side note, the server you are uploading the webrev to does > not have mime types set up correctly. I couldn't view the patch > without being asked to download it. odd, my server used the correct patch mime type of text/x-diff for diff and patch files. I have now changed my server to instead use text/plain for diff and patch files to ease review. It is viewable on cr.openjdk.java.net. > Is there a reason you aren't using this? I do not have an account on that server. Only users with push access to the OpenJDK mercurial server can use the cr.openjdk.java.net server: http://openjdk.java.net/guide/codeReview.html > >> Cheers >> Xerxes > From xerxes at zafena.se Wed Apr 20 17:07:01 2011 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Thu, 21 Apr 2011 02:07:01 +0200 Subject: Review Request: Regression Zero fails to handle fast_aldc and fast_aldc_w in hs20 In-Reply-To: <20110420223922.GV29985@rivendell.middle-earth.co.uk> References: <4DAEE700.6010501@zafena.se> <20110420223922.GV29985@rivendell.middle-earth.co.uk> Message-ID: <4DAF7525.4020509@zafena.se> On 2011-04-21 00:39, Dr Andrew John Hughes wrote: > On 16:00 Wed 20 Apr , Xerxes R?nby wrote: >> Hi >> >> hs20 uses two new internal instructions fast_aldc and fast_aldc_w. >> see: openjdk/hotspot/src/share/vm/interpreter/bytecodes.hpp >> >> This webrev fix by backporting Zero fixes from OpenJDK bug 7032458 and 7030207. >> http://labb.zafena.se/openjdk/pr696-zero-fast_aldc-and-fast_aldc_w-regression-hs20/ >> >> The webrev are made against hsx20 >> http://hg.openjdk.java.net/hsx/hsx20/master/ >> >> I don't have a bug id for this. > > Why are you merging together two different changesets? Because they both contain parts that are needed to properly fix this Zero regression on hs20 and prevent it from happening again. One part that fixes the regression by making the instruction table in sync again from 7032458, and another part from 7030207 that reveals the error if the table gets out of sync again. If I quote Gary: "It two new internal instructions, _fast_aldc and _fast_aldc_w, but it added them *before* _return_register_finalizer, which broke the instructions table in bytecodeInterpreter.cpp. It meant that when the C++ interpreter saw _return_register_finalizer it would execute opc_default, which should have thrown an error but for the piece of the ARM interpreter which hid the error by rewriting the instruction to a plain _return. I didn't see it before because I was doing debug builds, and the C++ interpreter only uses the instructions table for product builds." http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-March/005074.html Cheers Xerxes From ahughes at redhat.com Wed Apr 20 17:13:46 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 21 Apr 2011 01:13:46 +0100 Subject: Review Request: Regression Shark fails to JIT in hs20 In-Reply-To: <4DAF6F88.5040705@zafena.se> References: <4DAEE6F6.7090704@zafena.se> <20110420223851.GU29985@rivendell.middle-earth.co.uk> <4DAF6F88.5040705@zafena.se> Message-ID: <20110421001346.GF29985@rivendell.middle-earth.co.uk> On 01:43 Thu 21 Apr , Xerxes R?nby wrote: > On 2011-04-21 00:38, Dr Andrew John Hughes wrote: > > On 16:00 Wed 20 Apr , Xerxes R?nby wrote: > >> Hi > >> > >> Shark JIT fails to work when using HotSpot 20. > >> > >> This webrev fix by backporting Shark fixes from OpenJDK bug 7032458. > >> http://labb.zafena.se/openjdk/pr690-shark-jit-regression-hs20/ > >> > >> The webrev are made against hsx20 > >> http://hg.openjdk.java.net/hsx/hsx20/master/ > >> > >> I don't have a bug id for this. > >> > > > > AIUI, commits to hs20 are only allowed by Oracle employees. > > At least, that's what I've been told in the past. So this > > will need to go into the OpenJDK6 HotSpot tree once hs20 is > > merged. > I agree its not clear how to file patches for regressions to the hsXX > branches. > I got recommended by Chris Phillips on IRC to send in the patch for > review with a long cc list. > I'm just repeating what I was told when I wanted to do the same thing. I don't agree with it FWIW. > > > > If this is a backport of 7032458, why do you need a bug ID? > 7032458 contains more than one fix (one zero fix, this shark fix and one > parts that do not belong in hs20 at all). Preferably i would like a bug > ID that handles this Shark regression for the hs20 branch. > I agree with your reasoning. I complained about this patch at the time: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-March/005021.html > > > > As a side note, the server you are uploading the webrev to does > > not have mime types set up correctly. I couldn't view the patch > > without being asked to download it. > odd, my server used the correct patch mime type of > text/x-diff for diff and patch files. > I have now changed my server to instead use > text/plain for diff and patch files to ease review. > Thanks. It works now. text/x-diff is probably right but both Firefox and Chromium don't seem to think so. Or rather, they are too stupid to realise they can display it. > > It is viewable on cr.openjdk.java.net. > > Is there a reason you aren't using this? > I do not have an account on that server. Only users with push access to > the OpenJDK mercurial server can use the cr.openjdk.java.net server: > http://openjdk.java.net/guide/codeReview.html > I kinda assumed you had push access as you posted a patch for review... But I or someone else can easily push it for you once it is approved and has a bug ID. jdk6 patches have to be reviewed by Kelly for some reason, otherwise I could just be the reviewer on this one. And also, as I mentioned before, OpenJDK6 needs to have the merge approved first: http://mail.openjdk.java.net/pipermail/jdk6-dev/2011-April/002392.html > > > >> Cheers > >> Xerxes > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Wed Apr 20 17:15:49 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 21 Apr 2011 01:15:49 +0100 Subject: Review Request: Regression Zero fails to handle fast_aldc and fast_aldc_w in hs20 In-Reply-To: <4DAF7525.4020509@zafena.se> References: <4DAEE700.6010501@zafena.se> <20110420223922.GV29985@rivendell.middle-earth.co.uk> <4DAF7525.4020509@zafena.se> Message-ID: <20110421001549.GG29985@rivendell.middle-earth.co.uk> On 02:07 Thu 21 Apr , Xerxes R?nby wrote: > On 2011-04-21 00:39, Dr Andrew John Hughes wrote: > > On 16:00 Wed 20 Apr , Xerxes R?nby wrote: > >> Hi > >> > >> hs20 uses two new internal instructions fast_aldc and fast_aldc_w. > >> see: openjdk/hotspot/src/share/vm/interpreter/bytecodes.hpp > >> > >> This webrev fix by backporting Zero fixes from OpenJDK bug 7032458 and 7030207. > >> http://labb.zafena.se/openjdk/pr696-zero-fast_aldc-and-fast_aldc_w-regression-hs20/ > >> > >> The webrev are made against hsx20 > >> http://hg.openjdk.java.net/hsx/hsx20/master/ > >> > >> I don't have a bug id for this. > > > > Why are you merging together two different changesets? > > Because they both contain parts that are needed to properly fix this > Zero regression on hs20 and prevent it from happening again. > > One part that fixes the regression by making the instruction table in > sync again from 7032458, and another part from 7030207 that reveals the > error if the table gets out of sync again. > > If I quote Gary: > "It two new internal instructions, _fast_aldc and _fast_aldc_w, but > it added them *before* _return_register_finalizer, which broke the > instructions table in bytecodeInterpreter.cpp. It meant that when > the C++ interpreter saw _return_register_finalizer it would execute > opc_default, which should have thrown an error but for the piece of > the ARM interpreter which hid the error by rewriting the instruction > to a plain _return. I didn't see it before because I was doing > debug builds, and the C++ interpreter only uses the instructions > table for product builds." > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-March/005074.html > Are there bits of each changeset being left out? It's just it's easier to track if there is a 1-to-1 correspondence. > Cheers > Xerxes -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From xerxes at zafena.se Wed Apr 20 17:40:09 2011 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Thu, 21 Apr 2011 02:40:09 +0200 Subject: Review Request: Regression Zero fails to handle fast_aldc and fast_aldc_w in hs20 In-Reply-To: <20110421001549.GG29985@rivendell.middle-earth.co.uk> References: <4DAEE700.6010501@zafena.se> <20110420223922.GV29985@rivendell.middle-earth.co.uk> <4DAF7525.4020509@zafena.se> <20110421001549.GG29985@rivendell.middle-earth.co.uk> Message-ID: <4DAF7CE9.50209@zafena.se> On 2011-04-21 02:15, Dr Andrew John Hughes wrote: > On 02:07 Thu 21 Apr , Xerxes R?nby wrote: >> On 2011-04-21 00:39, Dr Andrew John Hughes wrote: >>> On 16:00 Wed 20 Apr , Xerxes R?nby wrote: >>>> Hi >>>> >>>> hs20 uses two new internal instructions fast_aldc and fast_aldc_w. >>>> see: openjdk/hotspot/src/share/vm/interpreter/bytecodes.hpp >>>> >>>> This webrev fix by backporting Zero fixes from OpenJDK bug 7032458 and 7030207. >>>> http://labb.zafena.se/openjdk/pr696-zero-fast_aldc-and-fast_aldc_w-regression-hs20/ >>>> >>>> The webrev are made against hsx20 >>>> http://hg.openjdk.java.net/hsx/hsx20/master/ >>>> >>>> I don't have a bug id for this. >>> >>> Why are you merging together two different changesets? >> >> Because they both contain parts that are needed to properly fix this >> Zero regression on hs20 and prevent it from happening again. >> >> One part that fixes the regression by making the instruction table in >> sync again from 7032458, and another part from 7030207 that reveals the >> error if the table gets out of sync again. >> >> If I quote Gary: >> "It two new internal instructions, _fast_aldc and _fast_aldc_w, but >> it added them *before* _return_register_finalizer, which broke the >> instructions table in bytecodeInterpreter.cpp. It meant that when >> the C++ interpreter saw _return_register_finalizer it would execute >> opc_default, which should have thrown an error but for the piece of >> the ARM interpreter which hid the error by rewriting the instruction >> to a plain _return. I didn't see it before because I was doing >> debug builds, and the C++ interpreter only uses the instructions >> table for product builds." >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-March/005074.html >> > > Are there bits of each changeset being left out? It's just it's easier > to track if there is a 1-to-1 correspondence. Large parts of 7032458 are left out that are unrelated to this Zero regression in hs20 (some Shark fixes and non hs20 fixes). The changeset from 7030207 are intact and can be backported by 1-to-1 correspondence if preferable. Personally I would prefer to see this Zero hs20 regression to be tracked as a unit in a Bug ID of its own. > >> Cheers >> Xerxes > From jon.masamitsu at oracle.com Thu Apr 21 14:18:19 2011 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Thu, 21 Apr 2011 21:18:19 +0000 Subject: hg: jdk7/hotspot/hotspot: 14 new changesets Message-ID: <20110421211846.D17BA47D79@hg.openjdk.java.net> Changeset: e6beb62de02d Author: never Date: 2011-04-05 19:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e6beb62de02d 7032963: StoreCM shouldn't participate in store elimination Reviewed-by: kvn ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/output.cpp Changeset: e1162778c1c8 Author: johnc Date: 2011-04-07 09:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e1162778c1c8 7009266: G1: assert(obj->is_oop_or_null(true )) failed: Error Summary: A referent object that is only weakly reachable at the start of concurrent marking but is re-attached to the strongly reachable object graph during marking may not be marked as live. This can cause the reference object to be processed prematurely and leave dangling pointers to the referent object. Implement a read barrier for the java.lang.ref.Reference::referent field by intrinsifying the Reference.get() method, and intercepting accesses though JNI, reflection, and Unsafe, so that when a non-null referent object is read it is also logged in an SATB buffer. Reviewed-by: kvn, iveresov, never, tonyp, dholmes ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/cppInterpreterGenerator_x86.hpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/interpreterGenerator_zero.hpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/cppInterpreter.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/unsafe.cpp Changeset: 9c4f56ff88e9 Author: jcoomes Date: 2011-04-07 16:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9c4f56ff88e9 7034133: cleanup obsolete option handling Reviewed-by: ysr, johnc, poonam ! src/share/vm/runtime/arguments.cpp Changeset: eda9eb483d29 Author: jcoomes Date: 2011-04-07 17:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/eda9eb483d29 6841742: par compact - remove unused/unsupported options Summary: ignore UseParallel{OldGCDensePrefix,OldGCCompacting,DensePrefixUpdate} Reviewed-by: jwilhelm, brutisso ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 92add02409c9 Author: jmasa Date: 2011-04-08 14:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/92add02409c9 Merge ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/prims/unsafe.cpp Changeset: f177ddd59c60 Author: jmasa Date: 2011-04-08 14:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f177ddd59c60 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 59766fd005ff Author: johnc Date: 2011-04-13 17:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/59766fd005ff 7035117: G1: nsk/stress/jni/jnistress002 fails with assertion failure Summary: Allow long type for offset in G1 code in compiler implementations of Unsafe.getObject Reviewed-by: never, iveresov ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/opto/library_call.cpp Changeset: 5d046bf49ce7 Author: johnc Date: 2011-04-14 13:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5d046bf49ce7 Merge ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: c69b1043dfb1 Author: ysr Date: 2011-04-14 12:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c69b1043dfb1 7036482: clear argument is redundant and unused in cardtable methods Summary: Removed the unused clear argument to various cardtbale methods and unused mod_oop_in_space_iterate method. Unrelated to synopsis, added a pair of clarifying parens in AllocationStats constructor. Reviewed-by: brutisso, jcoomes ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/modRefBarrierSet.hpp Changeset: 4080db1b5d0a Author: johnc Date: 2011-04-14 13:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4080db1b5d0a Merge Changeset: edd9b016deb6 Author: johnc Date: 2011-04-15 10:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/edd9b016deb6 7036021: G1: build failure on win64 and linux with hs21 in jdk6 build environment Summary: Missing parentheses around a casted expression and some missing casts were causing build failures with the jdk6 build tools. Reviewed-by: kvn, brutisso ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/opto/library_call.cpp Changeset: 1d0b856224f8 Author: jmasa Date: 2011-04-17 01:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1d0b856224f8 6946385: G1: jstat does not support G1 GC Summary: Added counters for jstat Reviewed-by: tonyp, jwilhelm, stefank, ysr, johnc Changeset: 527b586edf24 Author: johnc Date: 2011-04-18 16:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/527b586edf24 7036706: G1: Use LIR_OprDesc::as_pointer_register in code changes for 7035117 Summary: Use LIR_OprDesc::as_pointer_register() instead as_register/as_register_lo combination in the code changes for 7035117. Reviewed-by: iveresov ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp Changeset: 732454aaf5cb Author: jmasa Date: 2011-04-20 20:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/732454aaf5cb Merge ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/arguments.cpp From walter.rockett at sun.com Fri Apr 22 06:08:01 2011 From: walter.rockett at sun.com (walter.rockett at sun.com) Date: Fri, 22 Apr 2011 13:08:01 +0000 Subject: hg: hsx/hsx17/baseline: 11 new changesets Message-ID: <20110422130819.D312847E38@hg.openjdk.java.net> Changeset: 7cbd1e7b56ba Author: kevinw Date: 2011-04-18 13:34 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/7cbd1e7b56ba 6897143: Stress test crashes during HeapInspection using ParallelGC. Summary: http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=3247 Reviewed-by: chrisphi, ysr ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp Changeset: 47083018c460 Author: poonam Date: 2011-04-18 13:42 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/47083018c460 6837842: JNI_CreateJavaVM crashes under impersonation Summary: http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=3496 Reviewed-by: coleenp, dholmes, kevinw ! src/os/windows/vm/perfMemory_windows.cpp Changeset: e90d89dab490 Author: chrisphi Date: 2011-04-18 13:46 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/e90d89dab490 6919638: CMS: ExplicitGCInvokesConcurrent misinteracts with gc locker Summary: http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=3493 Reviewed-by: kevinw, poonam, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/runtime/globals.hpp Changeset: 4ec48c301281 Author: poonam Date: 2011-04-18 13:49 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/4ec48c301281 6745217: jmap throws sun.jvm.hotspot.utilities.AssertionFailure: BitMap index out of bounds (1.5.0_15-b04) Summary: http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=3526 Reviewed-by: chrisphi, swamyv ! agent/src/share/classes/sun/jvm/hotspot/memory/CMSBitMap.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/JavaThread.java Changeset: 92a4b6d11ab3 Author: kevinw Date: 2011-04-19 03:49 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/92a4b6d11ab3 6938026: C2 compiler fails in Node::rematerialize()const Summary: http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=3592 Reviewed-by: never, chrisphi, dsamersoff ! src/share/vm/opto/parse1.cpp Changeset: 47d6ab4dec3b Author: chrisphi Date: 2011-04-19 03:53 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/47d6ab4dec3b 6948537: CMS: BOT walkers observe out-of-thin-air zeros on sun4v sparc/CMT Summary: http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=3633 Reviewed-by: poonam, ysr ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/blockOffsetTable.hpp ! src/share/vm/runtime/globals.hpp Changeset: 01e81d81d4cb Author: chrisphi Date: 2011-04-19 03:54 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/01e81d81d4cb 6948539: CMS+UseCompressedOops: placement of cms_free bit interferes with promoted object link Summary: http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=3632 Reviewed-by: kevinw, poonam, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/oops/markOop.hpp Changeset: 963860620ae9 Author: wrockett Date: 2011-04-19 05:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/963860620ae9 7012829: Bump the HS17 build number to 18 Summary: See CR Reviewed-by: asaha ! make/hotspot_version Changeset: 1339e02bc576 Author: kevinw Date: 2011-04-19 06:00 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/1339e02bc576 6581734: CMS Old Gen's collection usage is zero after GC which is incorrect Summary: https://jetsvr.sfbay.sun.com:8443/BugApproval/ViewDetail.jsp?index=9939 Reviewed-by: ysr, mchung ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/services/management.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp + test/gc/6581734/Test6581734.java Changeset: 245267e5d015 Author: asaha Date: 2011-04-19 06:05 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/245267e5d015 6977952: Test: Sync missing tests from hs16.3 to hs17.x Summary: : Sync test cases from 6u20 Reviewed-by: wrockett + test/compiler/6894807/IsInstanceTest.java + test/compiler/6894807/Test6894807.sh + test/runtime/6626217/IFace.java + test/runtime/6626217/Loader2.java + test/runtime/6626217/Test6626217.sh + test/runtime/6626217/You_Have_Been_P0wned.java + test/runtime/6626217/bug_21227.java + test/runtime/6626217/from_loader2.java + test/runtime/6626217/many_loader1.java.foo Changeset: 0d4936f60577 Author: wrockett Date: 2011-04-19 06:06 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/0d4936f60577 6983515: Bump the HS17 build number to 19 Summary: See CR Reviewed-by: asaha ! make/hotspot_version From erik.trimble at oracle.com Sat Apr 23 02:35:38 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Sat, 23 Apr 2011 09:35:38 +0000 Subject: hg: jdk7/hotspot/hotspot: 8 new changesets Message-ID: <20110423093554.A780747EE0@hg.openjdk.java.net> Changeset: 2705303a05c4 Author: schien Date: 2011-04-14 15:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2705303a05c4 Added tag jdk7-b138 for changeset 0930dc920c18 ! .hgtags Changeset: d6d9b537f2c6 Author: trims Date: 2011-04-14 17:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d6d9b537f2c6 Added tag hs21-b08 for changeset 0930dc920c18 ! .hgtags Changeset: da7f1093a6b7 Author: trims Date: 2011-04-15 18:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/da7f1093a6b7 Merge Changeset: 611e19a16519 Author: trims Date: 2011-04-15 18:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/611e19a16519 7037174: Bump the HS21 build number to 09 Summary: Update the HS21 build number to 09 Reviewed-by: jcoomes ! make/hotspot_version Changeset: db3a870b62f6 Author: katleman Date: 2011-04-21 15:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/db3a870b62f6 Added tag jdk7-b139 for changeset 611e19a16519 ! .hgtags Changeset: 7b4fb6089361 Author: trims Date: 2011-04-21 19:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7b4fb6089361 Added tag hs21-b09 for changeset 611e19a16519 ! .hgtags Changeset: 83fccfbfe47b Author: trims Date: 2011-04-22 18:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/83fccfbfe47b Merge Changeset: d283b8296671 Author: trims Date: 2011-04-22 18:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d283b8296671 7039044: Bump the HS21 build number to 10 Summary: Update the HS21 build number to 10 Reviewed-by: jcoomes ! make/hotspot_version From coleen.phillimore at oracle.com Wed Apr 27 22:11:54 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 28 Apr 2011 05:11:54 +0000 Subject: hg: jdk7/hotspot/hotspot: 5 new changesets Message-ID: <20110428051206.3FF0747079@hg.openjdk.java.net> Changeset: 7ec4bb02d5f0 Author: vladidan Date: 2011-04-20 14:07 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7ec4bb02d5f0 7035861: linux-armsflt: assert(ni->data() == (int)(x + o)) failed: instructions must match Summary: The change avoids generating relocation info entry for the staging area patching stub on systems that don't support movw/movt instructions Reviewed-by: bdelsart ! src/share/vm/c1/c1_Runtime1.cpp Changeset: 49bd9c6f7bce Author: vladidan Date: 2011-04-21 10:12 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/49bd9c6f7bce Merge Changeset: cdd13dce903e Author: vladidan Date: 2011-04-23 00:33 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cdd13dce903e Merge Changeset: 01147d8aac1d Author: coleenp Date: 2011-04-26 14:04 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/01147d8aac1d 7009923: JSR 292: VM crash in JavaThread::last_frame Summary: Handle stack overflow before the first frame is called, by printing out the called method and not walking the stack. Reviewed-by: dholmes, phh, dsamersoff ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp Changeset: df22fe9c5a93 Author: coleenp Date: 2011-04-27 17:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/df22fe9c5a93 Merge From David.Holmes at oracle.com Thu Apr 28 23:01:59 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 29 Apr 2011 16:01:59 +1000 Subject: Request for review: 7036525 Disable alternative source mechanism for OPENJDK builds In-Reply-To: References: <4DB90020.7090708@oracle.com> Message-ID: <4DBA5457.1020405@oracle.com> Thanks Kelly. I just fixed the cc to hotspot-dev as it had an extra 'dev' in the domain. Maybe now someone from hotspot will see it! David Kelly O'Hair said the following on 04/29/11 12:06: > Looks fine. > > -kto > > On Apr 27, 2011, at 10:50 PM, David Holmes wrote: > >> http://cr.openjdk.java.net/~dholmes/7036525/webrev/ >> >> Simple but crude. If OPENJDK is defined then the Hotspot "alternative source" mechanism is effectively disabled by checking for a non-existent path. This allows people using the alt-src mechanism to select which type of build they want in a way that is consistent with how builds of OPENJDK are done in the rest of the JDK. >> >> Tested by checking the "errorReporter.cpp" location in builds with/without OPENJDK set, and with/without src/closed present. >> >> This will be pushed into hotspot-rt/hotspot for hs21-b11 >> >> Thanks, >> David > From omajid at redhat.com Fri Apr 29 11:02:38 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 29 Apr 2011 14:02:38 -0400 Subject: Request for review: [gcc] mark stack as non-executable Message-ID: <4DBAFD3E.7050103@redhat.com> Hi, The webrev marks libjvm.so's stack as non-executable: http://cr.openjdk.java.net/~omajid/webrevs/libjvm-exec-stack/ The reason the stack was being marked as executable was because we were missing a .note.GNU-stack in the assembly files [1]. The patch is based on Diego's patch back in 2007 [2]. I have made a few changes to it. I have updated the paths to the .s files so it works with the newer hotspot. I have changed %progbits to @progbits, which is what is used in several places [3][4]. Gentoo documentation [1] indicates that sparc also supports non-executable stacks, so I have made the changes to the sparc files. Any comments? Thanks, Omair [1] http://www.gentoo.org/proj/en/hardened/gnu-stack.xml#doc_chap7 [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2007-May/000002.html [3] http://sources.redhat.com/binutils/docs-2.12/as.info/Section.html#Section [4] http://www.redhat.com/archives/fedora-devel-list/2003-November/msg00838.html From Dmitry.Samersoff at oracle.com Fri Apr 29 11:17:38 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 29 Apr 2011 22:17:38 +0400 Subject: Request for review: [gcc] mark stack as non-executable In-Reply-To: <4DBAFD3E.7050103@redhat.com> References: <4DBAFD3E.7050103@redhat.com> Message-ID: <4DBB00C2.3000002@oracle.com> Omair, Thank you for digging into this problem. I just fixed the same bug. Please check 7019808 and http://cr.openjdk.java.net/~dsamersoff/7019808/webrev.04/ Your comments is much appreciated. -Dmitry On 2011-04-29 22:02, Omair Majid wrote: > Hi, > > The webrev marks libjvm.so's stack as non-executable: > http://cr.openjdk.java.net/~omajid/webrevs/libjvm-exec-stack/ > > The reason the stack was being marked as executable was because we were > missing a .note.GNU-stack in the assembly files [1]. > > The patch is based on Diego's patch back in 2007 [2]. I have made a few > changes to it. I have updated the paths to the .s files so it works with > the newer hotspot. I have changed %progbits to @progbits, which is what > is used in several places [3][4]. Gentoo documentation [1] indicates > that sparc also supports non-executable stacks, so I have made the > changes to the sparc files. > > Any comments? > > Thanks, > Omair > > [1] http://www.gentoo.org/proj/en/hardened/gnu-stack.xml#doc_chap7 > [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2007-May/000002.html > [3] > http://sources.redhat.com/binutils/docs-2.12/as.info/Section.html#Section > [4] > http://www.redhat.com/archives/fedora-devel-list/2003-November/msg00838.html > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From vladimir.kozlov at oracle.com Fri Apr 29 14:33:05 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 29 Apr 2011 21:33:05 +0000 Subject: hg: jdk7/hotspot/hotspot: 11 new changesets Message-ID: <20110429213324.9E15047112@hg.openjdk.java.net> Changeset: 2a23b1b5a0a8 Author: twisti Date: 2011-04-18 01:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2a23b1b5a0a8 7018355: JSR 292: VM crash in DefNewGeneration::copy_to_survivor_space Reviewed-by: kvn, jrose ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/memory/genOopClosures.hpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: bbe95b4337f1 Author: twisti Date: 2011-04-18 06:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bbe95b4337f1 7036960: TemplateTable::fast_aldc in templateTable_x86_64.cpp uses movptr instead of load_klass Reviewed-by: kvn, iveresov ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp Changeset: 2a34a4fbc52c Author: kvn Date: 2011-04-19 09:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2a34a4fbc52c 7037812: few more defaults changes for new AMD processors Summary: use PREFETCHW as default prefetch instruction, set UseXMMForArrayCopy and UseUnalignedLoadStores to true by default. Reviewed-by: kvn Contributed-by: tom.deneau at amd.com ! src/cpu/x86/vm/vm_version_x86.cpp Changeset: d934e4b931e9 Author: never Date: 2011-04-20 09:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d934e4b931e9 7009346: java/dyn/InvokeDynamicPrintArgs.java fails with NPE on solaris-sparc with -Xcomp Reviewed-by: kvn, jrose, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp Changeset: 66b0e2371912 Author: kvn Date: 2011-04-20 18:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/66b0e2371912 7026700: regression in 6u24-rev-b23: Crash in C2 compiler in PhaseIdealLoop::build_loop_late_post Summary: memory slices should be always created for non-static fields after allocation Reviewed-by: never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp Changeset: 08ccee2c4dbf Author: twisti Date: 2011-04-21 00:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/08ccee2c4dbf 6993078: JSR 292 too many pushes: Lesp points into register window Reviewed-by: kvn, never ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/oops/cpCacheOop.cpp Changeset: 548597e74aa4 Author: never Date: 2011-04-25 16:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/548597e74aa4 7030715: JSR 292 JRuby test/test_super_call_site_caching.rb asserts with +DoEscapeAnalysis Reviewed-by: twisti ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/opto/graphKit.cpp Changeset: 273b56978029 Author: kvn Date: 2011-04-26 12:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/273b56978029 7039586: test/java/util/Collections/Rotate.java failing with hs21-b09 Summary: A predicate should not be moved in partial peel optimization since it will invalidate jvm state of its uncommon trap. Reviewed-by: never ! src/share/vm/opto/loopopts.cpp Changeset: 149bb459be66 Author: never Date: 2011-04-27 15:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/149bb459be66 7029167: add support for conditional card marks Reviewed-by: iveresov, kvn ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/runtime/globals.hpp Changeset: 01fd6090fdd8 Author: never Date: 2011-04-28 14:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/01fd6090fdd8 7032162: assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr Reviewed-by: kvn ! src/share/vm/ci/ciObject.cpp ! src/share/vm/opto/stringopts.cpp Changeset: 286c498ae0d4 Author: kvn Date: 2011-04-29 11:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/286c498ae0d4 Merge ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/runtime/globals.hpp From omajid at redhat.com Fri Apr 29 15:15:15 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 29 Apr 2011 18:15:15 -0400 Subject: Request for review: [gcc] mark stack as non-executable In-Reply-To: <4DBB00C2.3000002@oracle.com> References: <4DBAFD3E.7050103@redhat.com> <4DBB00C2.3000002@oracle.com> Message-ID: <4DBB3873.5070700@redhat.com> On 04/29/2011 02:17 PM, Dmitry Samersoff wrote: > Omair, > > Thank you for digging into this problem. I just fixed the same > bug. Please check 7019808 and > > http://cr.openjdk.java.net/~dsamersoff/7019808/webrev.04/ > Ah, that's great! Was this posted somewhere that I missed? > Your comments is much appreciated. > It looks fine to me. I did an IcedTea7 build with this patch applied and the resulting libjvm.so has the right stack flags. Thanks, Omair From omajid at redhat.com Fri Apr 29 15:59:00 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 29 Apr 2011 18:59:00 -0400 Subject: Request for review: support building hotspot with gcc 4.6 Message-ID: <4DBB42B4.4090104@redhat.com> Hi, http://cr.openjdk.java.net/~omajid/webrevs/gcc-46-support/ The patch adds support for building hotspot with gcc 4.6. gcc 4.6 changed how arguments are handled. It now treats -export-dynamic as it treats any other -efoo option: it thinks xport-dynamic is the entry point and passes this information to the linker. Since -export-dynamic is not passed to the linker, not all symbols will be exported by the linker. The bfd-based linker, given the invalid entry point xport-dynamic, simply ignores it. The gold linker, however, crashes causing the build to fail. Since -export-dynamic is a linker option, the correct way to pass it is using -Wl,-export-dynamic (or -Xlinker -export-dynamic). We have had this patch in IcedTea6 for a while now, but it would be nice if this was in OpenJDK too. Thanks, Omair From jon.masamitsu at oracle.com Fri Apr 29 16:33:51 2011 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Fri, 29 Apr 2011 23:33:51 +0000 Subject: hg: jdk7/hotspot/hotspot: 12 new changesets Message-ID: <20110429233414.74CBD47119@hg.openjdk.java.net> Changeset: 49a67202bc67 Author: tonyp Date: 2011-04-19 15:46 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/49a67202bc67 7011855: G1: non-product flag to artificially grow the heap Summary: It introduces non-product cmd line parameter G1DummyRegionsPerGC which indicates how many "dummy" regions to allocate at the end of each GC. This allows the G1 heap to grow artificially and makes concurrent marking cycles more frequent irrespective of what the application that is running is doing. The dummy regions will be found totally empty during cleanup so this parameter can also be used to stress the concurrent cleanup operation. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 139667d9836a Author: iveresov Date: 2011-04-20 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/139667d9836a 7034464: Support transparent large pages on Linux Summary: Support transparent huge pages on Linux available since 2.6.38 Reviewed-by: iveresov, ysr Contributed-by: aph at redhat.com ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp Changeset: c48ad6ab8bdf Author: ysr Date: 2011-04-20 19:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c48ad6ab8bdf 7037276: Unnecessary double traversal of dirty card windows Summary: Short-circuited an unnecessary double traversal of dirty card windows when iterating younger refs. Also renamed some cardtable methods for more clarity. Reviewed-by: jmasa, stefank, poonam ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp Changeset: c0dcda80820f Author: ysr Date: 2011-04-21 01:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c0dcda80820f Merge Changeset: b52782ae3880 Author: jmasa Date: 2011-04-21 10:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b52782ae3880 6946417: G1: Java VisualVM does not support G1 properly. Summary: Added counters for jstat Reviewed-by: tonyp, jwilhelm, stefank, ysr, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp + src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp + src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp ! src/share/vm/gc_implementation/shared/generationCounters.cpp ! src/share/vm/gc_implementation/shared/generationCounters.hpp + src/share/vm/gc_implementation/shared/hSpaceCounters.cpp + src/share/vm/gc_implementation/shared/hSpaceCounters.hpp ! src/share/vm/services/g1MemoryPool.cpp ! src/share/vm/services/g1MemoryPool.hpp Changeset: 7f3faf7159fd Author: jmasa Date: 2011-04-22 09:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7f3faf7159fd Merge ! src/os/linux/vm/os_linux.cpp Changeset: d6cdc6c77582 Author: jcoomes Date: 2011-04-23 04:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d6cdc6c77582 7037250: cscope.make database generation is silently broken Reviewed-by: stefank + make/cscope.make ! make/linux/Makefile - make/linux/makefiles/cscope.make ! make/solaris/Makefile - make/solaris/makefiles/cscope.make Changeset: c303b3532d4a Author: iveresov Date: 2011-04-26 11:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c303b3532d4a 7037939: NUMA: Disable adaptive resizing if SHM large pages are used Summary: Make the NUMA allocator behave properly with SHM and ISM large pages. Reviewed-by: ysr ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp Changeset: 1f4413413144 Author: ysr Date: 2011-04-26 21:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1f4413413144 7039089: G1: changeset for 7037276 broke heap verification, and related cleanups Summary: In G1 heap verification, we no longer scan perm to G1-collected heap refs as part of process_strong_roots() but rather in a separate explicit oop iteration over the perm gen. This preserves the original perm card-marks. Added a new assertion in younger_refs_iterate() to catch a simple subcase where the user may have forgotten a prior save_marks() call, as happened in the case of G1's attempt to iterate perm to G1 refs when verifying the heap before exit. The assert was deliberately weakened for ParNew+CMS and will be fixed for that combination in a future CR. Also made some (non-G1) cleanups related to code and comments obsoleted by the migration of Symbols to the native heap. Reviewed-by: iveresov, jmasa, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/runtime/vmThread.cpp Changeset: 86ebb26bcdeb Author: johnc Date: 2011-04-27 14:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/86ebb26bcdeb 7037756: Deadlock in compiler thread similiar to 6789220 Summary: Avoid blocking in CompileBroker::compile_method_base() if the current thread holds the pending list lock. Reviewed-by: never, brutisso, ysr ! src/share/vm/compiler/compileBroker.cpp Changeset: c6033dad9fd3 Author: jmasa Date: 2011-04-29 12:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c6033dad9fd3 Merge - make/linux/makefiles/cscope.make - make/solaris/makefiles/cscope.make Changeset: df0a92a7e30b Author: jmasa Date: 2011-04-29 14:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/df0a92a7e30b Merge From omajid at redhat.com Fri Apr 29 16:34:57 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 29 Apr 2011 19:34:57 -0400 Subject: Request for review: support building hotspot with gcc 4.6 In-Reply-To: <4DBB460D.7050704@oracle.com> References: <4DBB42B4.4090104@redhat.com> <4DBB460D.7050704@oracle.com> Message-ID: <4DBB4B21.7090509@redhat.com> On 04/29/2011 07:13 PM, David Katleman wrote: > Hi Omair! > > On 4/29/2011 3:59 PM, Omair Majid wrote: >> Hi, >> >> http://cr.openjdk.java.net/~omajid/webrevs/gcc-46-support/ >> >> The patch adds support for building hotspot with gcc 4.6. gcc 4.6 >> changed how arguments are handled. It now treats -export-dynamic as it >> treats any other -efoo option: it thinks xport-dynamic is the entry >> point and passes this information to the linker. Since -export-dynamic >> is not passed to the linker, not all symbols will be exported by the >> linker. The bfd-based linker, given the invalid entry point >> xport-dynamic, simply ignores it. The gold linker, however, crashes >> causing the build to fail. >> >> Since -export-dynamic is a linker option, the correct way to pass it >> is using -Wl,-export-dynamic (or -Xlinker -export-dynamic). We have >> had this patch in IcedTea6 for a while now, but it would be nice if >> this was in OpenJDK too. > > Seems like your change should be surrounded by an ifneq that enables > your change for 4.6 and later > While I could certainly do that, I dont understand why it's needed. The patch keeps things backwards compatible. With the patch applied, I can still build hotspot with older versions of gcc/binutils. -export-dynamic is a linker option and has been for a (long) while now. I am actually not sure what the earliest version of ld that supports export-dynamic is, but -Wl,-export-dynamic is mentioned on http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html which was last updated 2003. Surely all versions of gcc/ld that we now use must support this? If you still think this needs to be conditional (although I strongly disagree that it needs to be), I can post another webrev. > Example elsewhere in the file > >> 129 # Except for a few acceptable ones >> 130 # Since GCC 4.3, -Wconversion has changed its meanings to warn >> these implicit >> 131 # conversions which might affect the values. To avoid that, we >> need to turn >> 132 # it off explicitly. >> 133 ifneq "$(shell expr \( $(CC_VER_MAJOR) \> 4 \) \| \( \( >> $(CC_VER_MAJOR) = 4 \) \& \( $(CC_VER_MINOR) \>= 3 \) \))" "0" >> 134 ACCEPTABLE_WARNINGS = -Wpointer-arith -Wsign-compare >> 135 else >> 136 ACCEPTABLE_WARNINGS = -Wpointer-arith -Wconversion -Wsign-compare >> 137 endif > Thanks for the example. I will keep this in mind whenever a gcc change needs to be conditional. Cheers, Omair From kelly.ohair at oracle.com Fri Apr 29 16:54:49 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 29 Apr 2011 16:54:49 -0700 Subject: Request for review: support building hotspot with gcc 4.6 In-Reply-To: <4DBB4B21.7090509@redhat.com> References: <4DBB42B4.4090104@redhat.com> <4DBB460D.7050704@oracle.com> <4DBB4B21.7090509@redhat.com> Message-ID: <97B7048E-A9D7-4D1B-A6D8-8CA531D68D52@oracle.com> The same hotspot sources and makefile deliver into our JDK6 releases, and formal builds of JDK6 are done on some very old Linux systems, RH2.1?, which I think is before 2000. -kto On Apr 29, 2011, at 4:34 PM, Omair Majid wrote: > On 04/29/2011 07:13 PM, David Katleman wrote: >> Hi Omair! >> >> On 4/29/2011 3:59 PM, Omair Majid wrote: >>> Hi, >>> >>> http://cr.openjdk.java.net/~omajid/webrevs/gcc-46-support/ >>> >>> The patch adds support for building hotspot with gcc 4.6. gcc 4.6 >>> changed how arguments are handled. It now treats -export-dynamic as it >>> treats any other -efoo option: it thinks xport-dynamic is the entry >>> point and passes this information to the linker. Since -export-dynamic >>> is not passed to the linker, not all symbols will be exported by the >>> linker. The bfd-based linker, given the invalid entry point >>> xport-dynamic, simply ignores it. The gold linker, however, crashes >>> causing the build to fail. >>> >>> Since -export-dynamic is a linker option, the correct way to pass it >>> is using -Wl,-export-dynamic (or -Xlinker -export-dynamic). We have >>> had this patch in IcedTea6 for a while now, but it would be nice if >>> this was in OpenJDK too. >> >> Seems like your change should be surrounded by an ifneq that enables >> your change for 4.6 and later >> > > While I could certainly do that, I dont understand why it's needed. The patch keeps things backwards compatible. With the patch applied, I can still build hotspot with older versions of gcc/binutils. > > -export-dynamic is a linker option and has been for a (long) while now. I am actually not sure what the earliest version of ld that supports export-dynamic is, but -Wl,-export-dynamic is mentioned on http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html which was last updated 2003. Surely all versions of gcc/ld that we now use must support this? > > If you still think this needs to be conditional (although I strongly disagree that it needs to be), I can post another webrev. > >> Example elsewhere in the file >> >>> 129 # Except for a few acceptable ones >>> 130 # Since GCC 4.3, -Wconversion has changed its meanings to warn >>> these implicit >>> 131 # conversions which might affect the values. To avoid that, we >>> need to turn >>> 132 # it off explicitly. >>> 133 ifneq "$(shell expr \( $(CC_VER_MAJOR) \> 4 \) \| \( \( >>> $(CC_VER_MAJOR) = 4 \) \& \( $(CC_VER_MINOR) \>= 3 \) \))" "0" >>> 134 ACCEPTABLE_WARNINGS = -Wpointer-arith -Wsign-compare >>> 135 else >>> 136 ACCEPTABLE_WARNINGS = -Wpointer-arith -Wconversion -Wsign-compare >>> 137 endif >> > > Thanks for the example. I will keep this in mind whenever a gcc change needs to be conditional. > > Cheers, > Omair From David.Holmes at oracle.com Fri Apr 29 17:17:50 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 30 Apr 2011 10:17:50 +1000 Subject: Request for review: support building hotspot with gcc 4.6 In-Reply-To: <4DBB460D.7050704@oracle.com> References: <4DBB42B4.4090104@redhat.com> <4DBB460D.7050704@oracle.com> Message-ID: <4DBB552E.5090400@oracle.com> Dave, David Katleman said the following on 04/30/11 09:13: > Hi Omair! > > On 4/29/2011 3:59 PM, Omair Majid wrote: >> Hi, >> >> http://cr.openjdk.java.net/~omajid/webrevs/gcc-46-support/ >> >> The patch adds support for building hotspot with gcc 4.6. gcc 4.6 >> changed how arguments are handled. It now treats -export-dynamic as it >> treats any other -efoo option: it thinks xport-dynamic is the entry >> point and passes this information to the linker. Since -export-dynamic >> is not passed to the linker, not all symbols will be exported by the >> linker. The bfd-based linker, given the invalid entry point >> xport-dynamic, simply ignores it. The gold linker, however, crashes >> causing the build to fail. >> >> Since -export-dynamic is a linker option, the correct way to pass it >> is using -Wl,-export-dynamic (or -Xlinker -export-dynamic). We have >> had this patch in IcedTea6 for a while now, but it would be nice if >> this was in OpenJDK too. > > Seems like your change should be surrounded by an ifneq that enables > your change for 4.6 and later Changing the use of a linker option: -foo to -Xlinker -foo (or -Wl,-foo) is fully compatible and preferable. We've been making a number of such changes ourselves (-Xlinker form) because they are needed when working with some of the cross-compilers we use for embedded. David Holmes ------------ > Example elsewhere in the file > >> 129 # Except for a few acceptable ones >> 130 # Since GCC 4.3, -Wconversion has changed its meanings to warn >> these implicit >> 131 # conversions which might affect the values. To avoid that, we >> need to turn >> 132 # it off explicitly. >> 133 ifneq "$(shell expr \( $(CC_VER_MAJOR) \> 4 \) \| \( \( >> $(CC_VER_MAJOR) = 4 \) \& \( $(CC_VER_MINOR) \>= 3 \) \))" "0" >> 134 ACCEPTABLE_WARNINGS = -Wpointer-arith -Wsign-compare >> 135 else >> 136 ACCEPTABLE_WARNINGS = -Wpointer-arith -Wconversion -Wsign-compare >> 137 endif > > Thanks > Dave > From erik.trimble at oracle.com Fri Apr 29 17:27:19 2011 From: erik.trimble at oracle.com (Erik Trimble) Date: Fri, 29 Apr 2011 17:27:19 -0700 Subject: Request for review: support building hotspot with gcc 4.6 In-Reply-To: <4DBB552E.5090400@oracle.com> References: <4DBB42B4.4090104@redhat.com> <4DBB460D.7050704@oracle.com> <4DBB552E.5090400@oracle.com> Message-ID: <4DBB5767.7000604@oracle.com> On 4/29/2011 5:17 PM, David Holmes wrote: > Dave, > > David Katleman said the following on 04/30/11 09:13: >> Hi Omair! >> >> On 4/29/2011 3:59 PM, Omair Majid wrote: >>> Hi, >>> >>> http://cr.openjdk.java.net/~omajid/webrevs/gcc-46-support/ >>> >>> The patch adds support for building hotspot with gcc 4.6. gcc 4.6 >>> changed how arguments are handled. It now treats -export-dynamic as >>> it treats any other -efoo option: it thinks xport-dynamic is the >>> entry point and passes this information to the linker. Since >>> -export-dynamic is not passed to the linker, not all symbols will be >>> exported by the linker. The bfd-based linker, given the invalid >>> entry point xport-dynamic, simply ignores it. The gold linker, >>> however, crashes causing the build to fail. >>> >>> Since -export-dynamic is a linker option, the correct way to pass it >>> is using -Wl,-export-dynamic (or -Xlinker -export-dynamic). We have >>> had this patch in IcedTea6 for a while now, but it would be nice if >>> this was in OpenJDK too. >> >> Seems like your change should be surrounded by an ifneq that enables >> your change for 4.6 and later > > Changing the use of a linker option: > > -foo > > to > > -Xlinker -foo (or -Wl,-foo) > > is fully compatible and preferable. We've been making a number of such > changes ourselves (-Xlinker form) because they are needed when working > with some of the cross-compilers we use for embedded. > > David Holmes > ------------ > >> Example elsewhere in the file >> >>> 129 # Except for a few acceptable ones >>> 130 # Since GCC 4.3, -Wconversion has changed its meanings to warn >>> these implicit >>> 131 # conversions which might affect the values. To avoid that, we >>> need to turn >>> 132 # it off explicitly. >>> 133 ifneq "$(shell expr \( $(CC_VER_MAJOR) \> 4 \) \| \( \( >>> $(CC_VER_MAJOR) = 4 \) \& \( $(CC_VER_MINOR) \>= 3 \) \))" "0" >>> 134 ACCEPTABLE_WARNINGS = -Wpointer-arith -Wsign-compare >>> 135 else >>> 136 ACCEPTABLE_WARNINGS = -Wpointer-arith -Wconversion -Wsign-compare >>> 137 endif >> >> Thanks >> Dave >> Presuming that the changes are still valid for a GCC and early libc in the 3.x range (i.e. older 2.4-based releases), then it's OK to not use ifneq Otherwise, we should use ifneq to cover the versions of GCC/libc where this is a valid option. We (Oracle) and others still support older Linux distros, so we do need to be careful not to break anything unless we specifically mean to (and, have a good reason to cause such breakage). -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA From David.Holmes at oracle.com Fri Apr 29 19:43:17 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 30 Apr 2011 12:43:17 +1000 Subject: Request for review: support building hotspot with gcc 4.6 In-Reply-To: <4DBB5767.7000604@oracle.com> References: <4DBB42B4.4090104@redhat.com> <4DBB460D.7050704@oracle.com> <4DBB552E.5090400@oracle.com> <4DBB5767.7000604@oracle.com> Message-ID: <4DBB7745.6050603@oracle.com> Erik Trimble said the following on 04/30/11 10:27: > On 4/29/2011 5:17 PM, David Holmes wrote: >> David Katleman said the following on 04/30/11 09:13: >>> On 4/29/2011 3:59 PM, Omair Majid wrote: >>>> >>>> http://cr.openjdk.java.net/~omajid/webrevs/gcc-46-support/ >>>> >>>> The patch adds support for building hotspot with gcc 4.6. gcc 4.6 >>>> changed how arguments are handled. It now treats -export-dynamic as >>>> it treats any other -efoo option: it thinks xport-dynamic is the >>>> entry point and passes this information to the linker. Since >>>> -export-dynamic is not passed to the linker, not all symbols will be >>>> exported by the linker. The bfd-based linker, given the invalid >>>> entry point xport-dynamic, simply ignores it. The gold linker, >>>> however, crashes causing the build to fail. >>>> >>>> Since -export-dynamic is a linker option, the correct way to pass it >>>> is using -Wl,-export-dynamic (or -Xlinker -export-dynamic). We have >>>> had this patch in IcedTea6 for a while now, but it would be nice if >>>> this was in OpenJDK too. >>> >>> Seems like your change should be surrounded by an ifneq that enables >>> your change for 4.6 and later >> >> Changing the use of a linker option: >> >> -foo >> >> to >> >> -Xlinker -foo (or -Wl,-foo) >> >> is fully compatible and preferable. We've been making a number of such >> changes ourselves (-Xlinker form) because they are needed when working >> with some of the cross-compilers we use for embedded. >> >> David Holmes >> ------------ >> >>> Example elsewhere in the file >>> >>>> 129 # Except for a few acceptable ones >>>> 130 # Since GCC 4.3, -Wconversion has changed its meanings to warn >>>> these implicit >>>> 131 # conversions which might affect the values. To avoid that, we >>>> need to turn >>>> 132 # it off explicitly. >>>> 133 ifneq "$(shell expr \( $(CC_VER_MAJOR) \> 4 \) \| \( \( >>>> $(CC_VER_MAJOR) = 4 \) \& \( $(CC_VER_MINOR) \>= 3 \) \))" "0" >>>> 134 ACCEPTABLE_WARNINGS = -Wpointer-arith -Wsign-compare >>>> 135 else >>>> 136 ACCEPTABLE_WARNINGS = -Wpointer-arith -Wconversion -Wsign-compare >>>> 137 endif >>> >>> Thanks >>> Dave >>> > > Presuming that the changes are still valid for a GCC and early libc in > the 3.x range (i.e. older 2.4-based releases), then it's OK to not use > ifneq > > Otherwise, we should use ifneq to cover the versions of GCC/libc where > this is a valid option. > > We (Oracle) and others still support older Linux distros, so we do need > to be careful not to break anything unless we specifically mean to (and, > have a good reason to cause such breakage). As long as the gcc version recognizes -Xlinker (and/or -Wl,) then as I said changing from direct use of -foo to "-Xlinker -foo" is 100% compatible. We already use -Xlinker and -Wl, all over the place! So this change should not have any compatibility issues whatsoever. David ----- From Dmitry.Samersoff at oracle.com Sat Apr 30 02:47:08 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 30 Apr 2011 13:47:08 +0400 Subject: Request for review: support building hotspot with gcc 4.6 In-Reply-To: <4DBB7745.6050603@oracle.com> References: <4DBB42B4.4090104@redhat.com> <4DBB460D.7050704@oracle.com> <4DBB552E.5090400@oracle.com> <4DBB5767.7000604@oracle.com> <4DBB7745.6050603@oracle.com> Message-ID: <4DBBDA9C.3000303@oracle.com> Omair, I'm second to David Holmes, -Xlinker forks fine since gcc 2.8.1 and I think we don't need any bracketing here. Personally I prefer -Xlinker over -Wl, because of better visibility. -Dmitry On 2011-04-30 06:43, David Holmes wrote: > Erik Trimble said the following on 04/30/11 10:27: >> On 4/29/2011 5:17 PM, David Holmes wrote: >>> David Katleman said the following on 04/30/11 09:13: >>>> On 4/29/2011 3:59 PM, Omair Majid wrote: >>>>> >>>>> http://cr.openjdk.java.net/~omajid/webrevs/gcc-46-support/ >>>>> >>>>> The patch adds support for building hotspot with gcc 4.6. gcc 4.6 >>>>> changed how arguments are handled. It now treats -export-dynamic as >>>>> it treats any other -efoo option: it thinks xport-dynamic is the >>>>> entry point and passes this information to the linker. Since >>>>> -export-dynamic is not passed to the linker, not all symbols will >>>>> be exported by the linker. The bfd-based linker, given the invalid >>>>> entry point xport-dynamic, simply ignores it. The gold linker, >>>>> however, crashes causing the build to fail. >>>>> >>>>> Since -export-dynamic is a linker option, the correct way to pass >>>>> it is using -Wl,-export-dynamic (or -Xlinker -export-dynamic). We >>>>> have had this patch in IcedTea6 for a while now, but it would be >>>>> nice if this was in OpenJDK too. >>>> >>>> Seems like your change should be surrounded by an ifneq that enables >>>> your change for 4.6 and later >>> >>> Changing the use of a linker option: >>> >>> -foo >>> >>> to >>> >>> -Xlinker -foo (or -Wl,-foo) >>> >>> is fully compatible and preferable. We've been making a number of >>> such changes ourselves (-Xlinker form) because they are needed when >>> working with some of the cross-compilers we use for embedded. >>> >>> David Holmes >>> ------------ >>> >>>> Example elsewhere in the file >>>> >>>>> 129 # Except for a few acceptable ones >>>>> 130 # Since GCC 4.3, -Wconversion has changed its meanings to warn >>>>> these implicit >>>>> 131 # conversions which might affect the values. To avoid that, we >>>>> need to turn >>>>> 132 # it off explicitly. >>>>> 133 ifneq "$(shell expr \( $(CC_VER_MAJOR) \> 4 \) \| \( \( >>>>> $(CC_VER_MAJOR) = 4 \) \& \( $(CC_VER_MINOR) \>= 3 \) \))" "0" >>>>> 134 ACCEPTABLE_WARNINGS = -Wpointer-arith -Wsign-compare >>>>> 135 else >>>>> 136 ACCEPTABLE_WARNINGS = -Wpointer-arith -Wconversion -Wsign-compare >>>>> 137 endif >>>> >>>> Thanks >>>> Dave >>>> >> >> Presuming that the changes are still valid for a GCC and early libc in >> the 3.x range (i.e. older 2.4-based releases), then it's OK to not use >> ifneq >> >> Otherwise, we should use ifneq to cover the versions of GCC/libc where >> this is a valid option. >> >> We (Oracle) and others still support older Linux distros, so we do >> need to be careful not to break anything unless we specifically mean >> to (and, have a good reason to cause such breakage). > > As long as the gcc version recognizes -Xlinker (and/or -Wl,) then as I > said changing from direct use of -foo to "-Xlinker -foo" is 100% > compatible. > > We already use -Xlinker and -Wl, all over the place! So this change > should not have any compatibility issues whatsoever. > > David > ----- > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From erik.trimble at oracle.com Sat Apr 30 05:01:17 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Sat, 30 Apr 2011 12:01:17 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20110430120128.8A45647145@hg.openjdk.java.net> Changeset: 4ca65400aa33 Author: ohair Date: 2011-04-26 16:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4ca65400aa33 6631003: Add hg tip changeset to build image Reviewed-by: mduigou ! .hgignore Changeset: d7cc76ea8d06 Author: cl Date: 2011-04-27 19:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d7cc76ea8d06 Merge Changeset: 6431be02f3ac Author: trims Date: 2011-04-29 16:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6431be02f3ac Merge - make/linux/makefiles/cscope.make - make/solaris/makefiles/cscope.make Changeset: 3aea9e9feb07 Author: trims Date: 2011-04-29 17:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3aea9e9feb07 7040777: Bump the HS21 build number to 11 Summary: Update the HS21 build number to 11 Reviewed-by: jcoomes ! make/hotspot_version From david.katleman at oracle.com Fri Apr 29 16:13:17 2011 From: david.katleman at oracle.com (David Katleman) Date: Fri, 29 Apr 2011 16:13:17 -0700 Subject: Request for review: support building hotspot with gcc 4.6 In-Reply-To: <4DBB42B4.4090104@redhat.com> References: <4DBB42B4.4090104@redhat.com> Message-ID: <4DBB460D.7050704@oracle.com> Hi Omair! On 4/29/2011 3:59 PM, Omair Majid wrote: > Hi, > > http://cr.openjdk.java.net/~omajid/webrevs/gcc-46-support/ > > The patch adds support for building hotspot with gcc 4.6. gcc 4.6 > changed how arguments are handled. It now treats -export-dynamic as it > treats any other -efoo option: it thinks xport-dynamic is the entry > point and passes this information to the linker. Since -export-dynamic > is not passed to the linker, not all symbols will be exported by the > linker. The bfd-based linker, given the invalid entry point > xport-dynamic, simply ignores it. The gold linker, however, crashes > causing the build to fail. > > Since -export-dynamic is a linker option, the correct way to pass it > is using -Wl,-export-dynamic (or -Xlinker -export-dynamic). We have > had this patch in IcedTea6 for a while now, but it would be nice if > this was in OpenJDK too. Seems like your change should be surrounded by an ifneq that enables your change for 4.6 and later Example elsewhere in the file > 129 # Except for a few acceptable ones > 130 # Since GCC 4.3, -Wconversion has changed its meanings to warn these implicit > 131 # conversions which might affect the values. To avoid that, we need to turn > 132 # it off explicitly. > 133 ifneq "$(shell expr \( $(CC_VER_MAJOR) \> 4 \) \| \( \( $(CC_VER_MAJOR) = 4 \) \& \( $(CC_VER_MINOR) \>= 3 \) \))" "0" > 134 ACCEPTABLE_WARNINGS = -Wpointer-arith -Wsign-compare > 135 else > 136 ACCEPTABLE_WARNINGS = -Wpointer-arith -Wconversion -Wsign-compare > 137 endif Thanks Dave