From Vladimir.Kozlov at Sun.COM Thu May 1 15:46:39 2008 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 01 May 2008 15:46:39 -0700 Subject: Can Phi->adr_type() be narrowoop ? Message-ID: <481A484F.6000604@sun.com> I am looking on failures where we missed an other checks for EncodeP, DecodeN in EA. When EA do split unique types it walks memory edges and can go over narrowoop memory (LoadN, for example). And since we have LoadN we can have memory Phi with narrowoop type. The question is can Phi->adr_type() be narrowoop also? We never checks adr_type() for narrowoop and it returns TypePrt not Type. Thanks, Vladimir From Thomas.Rodriguez at Sun.COM Thu May 1 16:10:33 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 01 May 2008 16:10:33 -0700 Subject: Can Phi->adr_type() be narrowoop ? In-Reply-To: <481A484F.6000604@sun.com> References: <481A484F.6000604@sun.com> Message-ID: <481A4DE9.3070805@sun.com> narrow oops aren't pointers so they shouldn't be able to be adr_types without being DecodeN'ed. tom Vladimir Kozlov wrote: > I am looking on failures where we missed an other checks for > EncodeP, DecodeN in EA. When EA do split unique types it walks > memory edges and can go over narrowoop memory (LoadN, for example). > And since we have LoadN we can have memory Phi with narrowoop type. > The question is can Phi->adr_type() be narrowoop also? > We never checks adr_type() for narrowoop and it returns TypePrt not Type. > > Thanks, > Vladimir From Vladimir.Kozlov at Sun.COM Thu May 1 16:28:46 2008 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 01 May 2008 16:28:46 -0700 Subject: Can Phi->adr_type() be narrowoop ? In-Reply-To: <481A4DE9.3070805@sun.com> References: <481A484F.6000604@sun.com> <481A4DE9.3070805@sun.com> Message-ID: <481A522E.2010600@sun.com> Thanks, Tom It is relief :) Vladimir Tom Rodriguez wrote: > narrow oops aren't pointers so they shouldn't be able to be adr_types > without being DecodeN'ed. > > tom > > Vladimir Kozlov wrote: >> I am looking on failures where we missed an other checks for >> EncodeP, DecodeN in EA. When EA do split unique types it walks >> memory edges and can go over narrowoop memory (LoadN, for example). >> And since we have LoadN we can have memory Phi with narrowoop type. >> The question is can Phi->adr_type() be narrowoop also? >> We never checks adr_type() for narrowoop and it returns TypePrt not Type. >> >> Thanks, >> Vladimir From chuck.rasbold at sun.com Wed May 7 10:53:32 2008 From: chuck.rasbold at sun.com (chuck.rasbold at sun.com) Date: Wed, 07 May 2008 17:53:32 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6603011: RFE: Optimize long division Message-ID: <20080507175336.2B93327DDC@hg.openjdk.java.net> Changeset: f3de1255b035 Author: rasbold Date: 2008-05-07 08:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f3de1255b035 6603011: RFE: Optimize long division Summary: Transform long division by constant into multiply Reviewed-by: never, kvn ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/divnode.cpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/mulnode.hpp ! src/share/vm/opto/type.hpp ! src/share/vm/utilities/globalDefinitions.hpp From chuck.rasbold at sun.com Fri May 9 08:11:28 2008 From: chuck.rasbold at sun.com (chuck.rasbold at sun.com) Date: Fri, 09 May 2008 15:11:28 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 11 new changesets Message-ID: <20080509151151.7966627E2C@hg.openjdk.java.net> Changeset: 435e64505015 Author: phh Date: 2008-04-24 15:07 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/435e64505015 6693457: Open-source hotspot linux-sparc support Summary: Move os_cpu/linux_sparc from closed to open Reviewed-by: kamg + make/linux/platform_sparcv9 + src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp + src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp + src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp + src/os_cpu/linux_sparc/vm/linux_sparc.ad + src/os_cpu/linux_sparc/vm/linux_sparc.s + src/os_cpu/linux_sparc/vm/orderAccess_linux_sparc.inline.hpp + src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp + src/os_cpu/linux_sparc/vm/os_linux_sparc.hpp + src/os_cpu/linux_sparc/vm/prefetch_linux_sparc.inline.hpp + src/os_cpu/linux_sparc/vm/threadLS_linux_sparc.cpp + src/os_cpu/linux_sparc/vm/threadLS_linux_sparc.hpp + src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp + src/os_cpu/linux_sparc/vm/thread_linux_sparc.hpp + src/os_cpu/linux_sparc/vm/vmStructs_linux_sparc.hpp + src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp ! src/share/vm/oops/oop.inline.hpp Changeset: 8a79f7ec8f5d Author: kamg Date: 2008-04-29 11:21 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8a79f7ec8f5d 6692246: Regression : JDK 6u4 b01 fails two JCK tests when fallback is switched off Summary: Added a clause to allow null to be an operand to the arraylength bytecode Reviewed-by: sbohne, coleenp ! src/share/vm/classfile/verifier.cpp Changeset: b7268662a986 Author: coleenp Date: 2008-04-29 19:31 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b7268662a986 6689523: max heap calculation for compressed oops is off by MaxPermSize Summary: Need to subtract MaxPermSize from the total heap size when determining whether compressed oops is turned on. Reviewed-by: jmasa, jcoomes, kvn ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 7f3a69574470 Author: kamg Date: 2008-04-30 10:58 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7f3a69574470 6695506: JVM should accept classfiles with classfile version 51 Summary: increase class file parser's acceptable max to 51 Reviewed-by: sbohne, ikrylov ! src/share/vm/classfile/classFileParser.cpp Changeset: 53735b80b9f1 Author: sbohne Date: 2008-05-01 09:38 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/53735b80b9f1 Merge Changeset: bcdc68eb7e1f Author: sbohne Date: 2008-05-02 08:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bcdc68eb7e1f Merge Changeset: c0492d52d55b Author: apetrusenko Date: 2008-04-01 15:13 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c0492d52d55b 6539517: CR 6186200 should be extended to perm gen allocation to prevent spurious OOM's from perm gen Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/includeDB_core ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/permGen.cpp ! src/share/vm/memory/permGen.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vm_operations.hpp Changeset: 3febac328d82 Author: apetrusenko Date: 2008-04-16 12:58 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3febac328d82 Merge - src/cpu/sparc/vm/disassembler_sparc.cpp - src/cpu/x86/vm/disassembler_x86.cpp - src/share/vm/compiler/disassemblerEnv.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/globals.hpp Changeset: fcbfc50865ab Author: iveresov Date: 2008-04-29 13:51 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fcbfc50865ab 6684395: Port NUMA-aware allocator to linux Summary: NUMA-aware allocator port to Linux Reviewed-by: jmasa, apetrusenko ! build/linux/makefiles/mapfile-vers-debug ! build/linux/makefiles/mapfile-vers-product ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/os.hpp Changeset: 8bd1e4487c18 Author: iveresov Date: 2008-05-04 03:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8bd1e4487c18 Merge ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/includeDB_core ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/runtime/globals.hpp Changeset: 7cce9e4e0f7c Author: rasbold Date: 2008-05-09 05:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7cce9e4e0f7c Merge From Thomas.Rodriguez at Sun.COM Fri May 9 14:53:40 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 09 May 2008 14:53:40 -0700 Subject: review (S) for 6697238 Message-ID: <4824C7E4.7000001@sun.com> http://webrev.invokedynamic.info/never/6697238/ From Thomas.Rodriguez at Sun.COM Fri May 9 14:53:42 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 09 May 2008 14:53:42 -0700 Subject: review (XS) for 6697236 Message-ID: <4824C7E6.3050808@sun.com> http://webrev.invokedynamic.info/never/6697236/ From gbenson at redhat.com Mon May 12 04:05:31 2008 From: gbenson at redhat.com (Gary Benson) Date: Mon, 12 May 2008 12:05:31 +0100 Subject: Safepoints at backward branches in c2 Message-ID: <20080512110531.GB3814@redhat.com> Hi all, I've been looking through the c2 code and I noticed that safepoint checks are inserted before backward branches but not forward branches. Why is this? Cheers, Gary -- http://gbenson.net/ From springer at reservoir.com Mon May 12 07:27:01 2008 From: springer at reservoir.com (Jonathan Springer) Date: Mon, 12 May 2008 09:27:01 -0500 Subject: Safepoints at backward branches in c2 In-Reply-To: <20080512110531.GB3814@redhat.com> References: <20080512110531.GB3814@redhat.com> Message-ID: <482853B5.3050404@reservoir.com> Gary Benson wrote: > Hi all, > > I've been looking through the c2 code and I noticed that safepoint > checks are inserted before backward branches but not forward branches. > Why is this? I believe that safepoints should be executed within a bounded amount of computation. Placing them at all backwards branches (and calls) guarantees that there are no loops without at least one safepoint. Regards, -Jonathan -- Jonathan Springer | Reservoir Labs, Inc. | http://www.reservoir.com/ From Thomas.Rodriguez at Sun.COM Mon May 12 11:29:39 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 12 May 2008 11:29:39 -0700 Subject: Safepoints at backward branches in c2 In-Reply-To: <482853B5.3050404@reservoir.com> References: <20080512110531.GB3814@redhat.com> <482853B5.3050404@reservoir.com> Message-ID: <48288C93.7010405@sun.com> That's correct. There are also various optimizations that later remove redundant ones to reduce the overhead. tom Jonathan Springer wrote: > Gary Benson wrote: >> Hi all, >> >> I've been looking through the c2 code and I noticed that safepoint >> checks are inserted before backward branches but not forward branches. >> Why is this? > > I believe that safepoints should be executed within a bounded amount > of computation. Placing them at all backwards branches (and calls) > guarantees that there are no loops without at least one safepoint. > > Regards, > -Jonathan > From gbenson at redhat.com Tue May 13 00:53:33 2008 From: gbenson at redhat.com (Gary Benson) Date: Tue, 13 May 2008 08:53:33 +0100 Subject: Safepoints at backward branches in c2 In-Reply-To: <482853B5.3050404@reservoir.com> References: <20080512110531.GB3814@redhat.com> <482853B5.3050404@reservoir.com> Message-ID: <20080513075332.GA3790@redhat.com> Jonathan Springer wrote: > Gary Benson wrote: > > I've been looking through the c2 code and I noticed that safepoint > > checks are inserted before backward branches but not forward > > branches. Why is this? > > I believe that safepoints should be executed within a bounded amount > of computation. Placing them at all backwards branches (and calls) > guarantees that there are no loops without at least one safepoint. Interesting. Where should the safepoints be in calls? I know the C++ interpreter puts one before every return, but is there somewhere else I should be putting one too? Cheers, Gary -- http://gbenson.net/ From Steve.Goldman at Sun.COM Tue May 13 07:33:54 2008 From: Steve.Goldman at Sun.COM (steve goldman) Date: Tue, 13 May 2008 10:33:54 -0400 Subject: Safepoints at backward branches in c2 In-Reply-To: <20080513075332.GA3790@redhat.com> References: <20080512110531.GB3814@redhat.com> <482853B5.3050404@reservoir.com> <20080513075332.GA3790@redhat.com> Message-ID: <4829A6D2.6080106@sun.com> Gary Benson wrote: > > Interesting. Where should the safepoints be in calls? I know the > C++ interpreter puts one before every return, but is there somewhere > else I should be putting one too? > Compiled code does them at returns just like the c++ interpreter. The c++ interpreter also has them at backbranches. It's in the DO_BACKEDGE_CHECKS macro. -- Steve From gbenson at redhat.com Tue May 13 08:50:10 2008 From: gbenson at redhat.com (Gary Benson) Date: Tue, 13 May 2008 16:50:10 +0100 Subject: Safepoints at backward branches in c2 In-Reply-To: <4829A6D2.6080106@sun.com> References: <20080512110531.GB3814@redhat.com> <482853B5.3050404@reservoir.com> <20080513075332.GA3790@redhat.com> <4829A6D2.6080106@sun.com> Message-ID: <20080513155010.GE3989@redhat.com> steve goldman wrote: > Gary Benson wrote: > > Interesting. Where should the safepoints be in calls? I know > > the C++ interpreter puts one before every return, but is there > > somewhere else I should be putting one too? > > Compiled code does them at returns just like the c++ interpreter. > The c++ interpreter also has them at backbranches. It's in the > DO_BACKEDGE_CHECKS macro. Cool, thanks. Cheers, Gary -- http://gbenson.net/ From john.rose at sun.com Wed May 14 02:47:16 2008 From: john.rose at sun.com (john.rose at sun.com) Date: Wed, 14 May 2008 09:47:16 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6701024: SAJDI functionality is broken Message-ID: <20080514094719.651DA28025@hg.openjdk.java.net> Changeset: 83c868b757c0 Author: jrose Date: 2008-05-14 00:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/83c868b757c0 6701024: SAJDI functionality is broken Summary: back out sa-related changes to 6652736, use concrete expressions for WKK names in the SA Reviewed-by: never, sundar ! agent/src/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/runtime/vmStructs.cpp From Vladimir.Kozlov at Sun.COM Wed May 14 16:36:41 2008 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 14 May 2008 16:36:41 -0700 Subject: Request for reviews (S): 6701887: JDK7 server VM in endless loop between Node::dominates Message-ID: <482B7789.5050304@sun.com> http://webrev.invokedynamic.info/kvn/6701887/index.html Fixed 6701887: JDK7 server VM in endless loop between Node::dominates Problem: The new method Node::dominates() added in 6686791 changes loops in the dead code which does not have a Region node. _ / \ | iF | | | ifTrue | | | SafePoint | | | iF | | | ifTrue | | \_/ Solution: Restore the iterations limit for a control path which doesn't have a Region node. Set it to 1000 since the method in jvm98 has a normal control path size 209 nodes: spec.benchmarks._205_raytrace.OctNode::CreateFaces() (643 bytes) Also fixed 2 problems in the original 6686791 changes. Reviewed by: Fix verified (y/n): y, failed tests in CTW: ZKM.jar and iab60.jar Other testing: JPRT, CTW From Vladimir.Kozlov at Sun.COM Wed May 14 20:53:07 2008 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 14 May 2008 20:53:07 -0700 Subject: Request for reviews (L): 6695810: null oop passed to encode_heap_oop_not_null Message-ID: <482BB3A3.4080102@sun.com> Note: diffs contains changes (in node.cpp and c2_globals.hpp) for 6701887 which I will push first. http://webrev.invokedynamic.info/kvn/6695810/index.html Fixed 6695810: null oop passed to encode_heap_oop_not_null These changes include fixes for problems found in Escape Analysis and Compressed Oops implementations. Also they include additional optimizations for Compressed Oops: - use the 32-bits gap after klass in a object for a narrow oop field, - use the 32-bits gap after klass in a object for boxing objects value (except Long and Double), - use heapOopSize for instanceKlass::_nonstatic_field_size value instead of wordSize, - add LoadNKlass and CMoveN nodes and use CmpN and ConN nodes and add correspondent platform specific assembler instructions to generate narrow oops (32-bits) compares for oop type and oop NULL checks. Reviewed by: Fix verified (y/n): y, failed tests and generated code Other testing: JPRT, CTW, nsk tests, refworkload From Vladimir.Kozlov at Sun.COM Thu May 15 14:26:01 2008 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 15 May 2008 14:26:01 -0700 Subject: Request for reviews (S): 6700102: c2 assertion "counter_changed,"failed dependencies, but counter didn't change")" with AggressiveOpts Message-ID: <482CAA69.7030507@sun.com> http://webrev.invokedynamic.info/kvn/6700102/index.html Fixed 6700102: c2 assertion "counter_changed,"failed dependencies, but counter didn't change")" with AggressiveOpts Problem: Bytecode Escape Analyzer does not have the check for the case described in 6389127 (for which the test case was created). Solution: Copy 6389127 fix from C1. Reviewed by: Fix verified (y/n): y, failed test Other testing: JPRT From vladimir.kozlov at sun.com Fri May 16 00:58:34 2008 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 16 May 2008 07:58:34 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6700102: c2 assertion "counter_changed, "failed dependencies, but counter didn't change")" with AggressiveOpts Message-ID: <20080516075839.1E165281C1@hg.openjdk.java.net> Changeset: 09c2ba680204 Author: kvn Date: 2008-05-15 22:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/09c2ba680204 6700102: c2 assertion "counter_changed,"failed dependencies, but counter didn't change")" with AggressiveOpts Summary: Bytecode Escape Analyzer does not have the check for the case described in 6389127. Reviewed-by: never ! src/share/vm/ci/bcEscapeAnalyzer.cpp From gbenson at redhat.com Fri May 16 01:42:37 2008 From: gbenson at redhat.com (Gary Benson) Date: Fri, 16 May 2008 09:42:37 +0100 Subject: Failing typeflow responsibility assertions Message-ID: <20080516084237.GA3704@redhat.com> Hi all, There's loads of bits in c2 that look like this: bool will_link; ciInstanceKlass* klass = iter().get_klass(will_link)->as_instance_klass(); assert(will_link, "_new: typeflow responsibility"); I'm doing the same in the JIT I'm writing, but I keep on failing these assertions. Do I have to do something to tell the CompileBroker not to feed me methods full of unloaded stuff? Oh, and I'm using -Xmixed. Cheers, Gary -- http://gbenson.net/ From vladimir.kozlov at sun.com Fri May 16 02:59:53 2008 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 16 May 2008 09:59:53 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6701887: JDK7 server VM in endless loop in Node::dominates Message-ID: <20080516095955.4A71B281CF@hg.openjdk.java.net> Changeset: 723be81c1212 Author: kvn Date: 2008-05-15 22:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/723be81c1212 6701887: JDK7 server VM in endless loop in Node::dominates Summary: The method Node::dominates loops in the dead code which does not have a Region node. Reviewed-by: jrose, never ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.cpp From John.Rose at Sun.COM Fri May 16 11:23:22 2008 From: John.Rose at Sun.COM (John Rose) Date: Fri, 16 May 2008 11:23:22 -0700 Subject: Failing typeflow responsibility assertions In-Reply-To: <20080516084237.GA3704@redhat.com> References: <20080516084237.GA3704@redhat.com> Message-ID: <200E1632-3850-445C-B32E-7A0F6A497BAC@sun.com> On May 16, 2008, at 1:42 AM, Gary Benson wrote: > Do I have to do something to tell the CompileBroker not > to feed me methods full of unloaded stuff? Oh, and I'm using -Xmixed. The typeflow pass builds the basic block model and typestates consumed by the parser. You can't build phis correctly without that stuff. (An earlier version tried to parse, find blocks, and compute phi types all on the fly, but it didn't work out, so ciTypeFlow was added as a first pass.) (The new typestate maps might change this a little, but we have to compile w/o the maps anyway.) The basic block model is pruned at unreached bytecodes which would provoke class loading. As a result, the parser can (mostly) ignore unloaded classes, which removes lots of buggy edge cases. Do you use ciTypeFlow in your JIT? -- John From MASLOWSC at cboe.com Sun May 18 09:53:53 2008 From: MASLOWSC at cboe.com (Maslowski, Chuck) Date: Sun, 18 May 2008 11:53:53 -0500 Subject: FW: Bug 6700047 Message-ID: <4BD174404CF4A34C98322DC926CF862B05559586@MSMAIL.cboent.cboe.com> forwarding to this group per Ramki's suggestion... FYI, we really don't want to run with -client nor use compiler exclusions. -----Original Message----- From: Y Srinivas Ramakrishna [mailto:Y.S.Ramakrishna at Sun.COM] Sent: Sunday, May 18, 2008 10:54 AM To: Maslowski, Chuck Subject: Re: Bug 6700047 of course that should be hotspot-compiler-dev at ... not hs-compiler-dev at ... -- r ----- Original Message ----- From: Y Srinivas Ramakrishna Date: Sunday, May 18, 2008 8:35 am Subject: Re: Bug 6700047 To: "Maslowski, Chuck" > Hi Chuck -- > > You might want to ask on hs-compiler-dev at openjdk.java.net > since it's known to be an issue on the current bits of OpenJDK 7 > as well (and of course is a server compiler issue; so a workaround > might be to run with -client rather than -server, but that would affect > the performance, as would excluding compile of the affected methods, > which you seem to have already discovered in 6703556). > > -- ramki > > ----- Original Message ----- > From: "Maslowski, Chuck" > Date: Saturday, May 17, 2008 1:53 pm > Subject: Bug 6700047 > To: hotspot-gc-dev at openjdk.java.net > > > > we ran into this HotSpot bug, do you guys have any information as to > a > > circumvention or fix ? > > -- thanks > > Chuck Maslowski > > CBOE From David.Cox at Sun.COM Mon May 19 10:00:26 2008 From: David.Cox at Sun.COM (David Cox) Date: Mon, 19 May 2008 10:00:26 -0700 Subject: Bug 6700047 In-Reply-To: <4BD174404CF4A34C98322DC926CF862B05559583@MSMAIL.cboent.cboe.com> References: <4BD174404CF4A34C98322DC926CF862B05559583@MSMAIL.cboent.cboe.com> Message-ID: <4831B22A.6030809@sun.com> Chuck, This is a bug in hotspot's server compiler. This kind of failure can be hard to diagnose so I suspect that the compiler team (Cc'd) would like to work with you to help them track it down. Dave Maslowski, Chuck wrote: > we ran into this HotSpot bug, do you guys have any information as to a circumvention or fix ? > -- thanks > Chuck Maslowski > CBOE From Vladimir.Kozlov at Sun.COM Mon May 19 21:31:21 2008 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 19 May 2008 21:31:21 -0700 Subject: Request for reviews (L): 6695810 and 6703890 Message-ID: <48325419.1050309@sun.com> As Chuck suggested, I divided the original 6695810 changes into 3 parts. 6703888 was reviewed by Tom and Coleen and is ready to go but I want to push it after 6695810 and 6703890. 6695810 and 6703890 were reviewed only by Tom and I need a second review for both. Thanks, Vladimir ----------------------------------------------- http://webrev.invokedynamic.info/kvn/6695810_only/index.html Problem: After CastPP is removed by PhaseCCP EncodeP was moved above the null check (EncodeP and DecodeN don't have control edge). As result the NotNULL type is not valid any more. Solution: Set control edge for EncodeP and DecodeN nodes using MemNode::Ideal_DU_PostCCP(). Also fix next problems: - replace Type::is_narrow() with more precise Type::is_ptr_to_narrowoop() defined during TypeOopPtr construction, - use subclass check instead of alias types check in CallNode::may_modify(), - call PhiNode::split_out_instance() also for Phi nodes with non-instance OopPtr type which matches the instance type, - stop compilation instead of VM exit when there is no space for scratch buffer in CodeCache, - don't flatten instance type in alias types, - skip the split through phi in LoadNode::Ideal() if the Region node dominates load's address, - an allocation is not scalar replaceable if the resuilt is stored into unknown array's element, - try 2 Region's input paths in Node::dominates(), - add missing checks for ConN node. Added the test case. Also added the test case for 6689060. Reviewed by: never Fix verified (y/n): y, failed test Other testing: JPRT, CTW, nsk tests ----------------------------------------------- http://webrev.invokedynamic.info/kvn/6703890/index.html Fixed 6703890: Compressed Oops: add LoadNKlass node to generate narrow oops (32-bits) compare instructions Problem: Currently C2 generates DecodeN and CmpP (64-bits) instructions for klass and oop NULL checks with Compressed Oops. Solution: Add LoadNKlass and CMoveN nodes, use CmpN and ConN nodes and add correspondent platform specific assembler instructions to generate narrow oops (32-bits) compare instructions to avoid decoding. Reviewed by: never Fix verified (y/n): y, check generated code Other testing: JPRT, CTW, nsk tests ----------------------------------------------- http://webrev.invokedynamic.info/kvn/6703888/index.html Fixed 6703888: Compressed Oops: use the 32-bits gap after klass in a object Problem: With Compressed Oops there is 32-bits gap after narrow 'klass' field in a object. Currently it is filled only with primitive type fields. Solution: Use the gap also for a narrow oop field and a boxing object value (except Long and Double). Use heapOopSize for instanceKlass::_nonstatic_field_size value instead of wordSize to define the size more precisely. Reviewed by: coleen, never Fix verified (y/n): y, check generated offsets Other testing: JPRT, CTW, nsk tests From gbenson at redhat.com Tue May 20 00:44:45 2008 From: gbenson at redhat.com (Gary Benson) Date: Tue, 20 May 2008 08:44:45 +0100 Subject: Failing typeflow responsibility assertions In-Reply-To: <200E1632-3850-445C-B32E-7A0F6A497BAC@sun.com> References: <20080516084237.GA3704@redhat.com> <200E1632-3850-445C-B32E-7A0F6A497BAC@sun.com> Message-ID: <20080520074445.GA3861@redhat.com> John Rose wrote: > On May 16, 2008, at 1:42 AM, Gary Benson wrote: > > Do I have to do something to tell the CompileBroker not to feed > > me methods full of unloaded stuff? Oh, and I'm using -Xmixed. > > The typeflow pass builds the basic block model and typestates > consumed by the parser. You can't build phis correctly without > that stuff. > > (An earlier version tried to parse, find blocks, and compute phi > types all on the fly, but it didn't work out, so ciTypeFlow was > added as a first pass.) > > (The new typestate maps might change this a little, but we have to > compile w/o the maps anyway.) > > The basic block model is pruned at unreached bytecodes which would > provoke class loading. > > As a result, the parser can (mostly) ignore unloaded classes, which > removes lots of buggy edge cases. > > Do you use ciTypeFlow in your JIT? That's awesome! I wasn't using it until yesterday but I am now :) So does the ciTypeFlow pass actually load the unloaded classes for you? Cheers, Gary -- http://gbenson.net/ From chuck.rasbold at sun.com Tue May 20 10:30:33 2008 From: chuck.rasbold at sun.com (chuck.rasbold at sun.com) Date: Tue, 20 May 2008 17:30:33 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 4 new changesets Message-ID: <20080520173041.E5AB8283AD@hg.openjdk.java.net> Changeset: b5489bb705c9 Author: ysr Date: 2008-05-06 15:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b5489bb705c9 6662086: 6u4+, 7b11+: CMS never clears referents when -XX:+ParallelRefProcEnabled Summary: Construct the relevant CMSIsAliveClosure used by CMS during parallel reference processing with the correct span. It had incorrectly been constructed with an empty span, a regression introduced in 6417901. Reviewed-by: jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp Changeset: e3729351c946 Author: iveresov Date: 2008-05-09 16:34 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e3729351c946 6697534: Premature GC and invalid lgrp selection with NUMA-aware allocator. Summary: Don't move tops of the chunks in ensure_parsibility(). Handle the situation with Solaris when a machine has a locality group with no memory. Reviewed-by: apetrusenko, jcoomes, ysr ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp Changeset: 7a0a921a1a8c Author: rasbold Date: 2008-05-14 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7a0a921a1a8c Merge Changeset: 8aa010f60e0f Author: rasbold Date: 2008-05-20 06:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8aa010f60e0f Merge From John.Rose at Sun.COM Tue May 20 10:59:04 2008 From: John.Rose at Sun.COM (John Rose) Date: Tue, 20 May 2008 10:59:04 -0700 Subject: Failing typeflow responsibility assertions In-Reply-To: <20080520074445.GA3861@redhat.com> References: <20080516084237.GA3704@redhat.com> <200E1632-3850-445C-B32E-7A0F6A497BAC@sun.com> <20080520074445.GA3861@redhat.com> Message-ID: On May 20, 2008, at 12:44 AM, Gary Benson wrote: > That's awesome! I wasn't using it until yesterday but I am now :) I'm glad it's helpful! > So does the ciTypeFlow pass actually load the unloaded classes for > you? No, the JIT tries pretty hard not to load classes. IIRC, the only exception to this rule is the call to load_signature_classes in compileBroker.cpp. JIT compilation should be transparent to Java execution, but loading classes causes class loader code to execute. If the JIT causes bytecode execution, then the JIT can cause application state changes, which explores new application states unnecessarily. This can expose JIT-entangled bugs in the application. You want this in stress testing, but not in the field. The JVM spec. allows class loading--not initialization--for any reason, but it's better (for system reproducibility) if the JIT has no detectable effect on app. state except speedups. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20080520/2023e9ab/attachment.html From John.Rose at Sun.COM Tue May 20 16:58:38 2008 From: John.Rose at Sun.COM (John Rose) Date: Tue, 20 May 2008 16:58:38 -0700 Subject: Request for reviews (L): 6695810 and 6703890 In-Reply-To: <48325419.1050309@sun.com> References: <48325419.1050309@sun.com> Message-ID: <8DE0790E-78C9-40F9-B30A-F1D393F089AD@sun.com> On May 19, 2008, at 9:31 PM, Vladimir Kozlov wrote: > ----------------------------------------------- > http://webrev.invokedynamic.info/kvn/6695810_only/index.html > > Problem: > After CastPP is removed by PhaseCCP EncodeP was moved above the > null check > (EncodeP and DecodeN don't have control edge). As result the > NotNULL type > is not valid any more. > > Solution: > Set control edge for EncodeP and DecodeN nodes using > MemNode::Ideal_DU_PostCCP(). > > Also fix next problems: > - replace Type::is_narrow() with more precise > Type::is_ptr_to_narrowoop() > defined during TypeOopPtr construction, > - use subclass check instead of alias types check in > CallNode::may_modify(), > - call PhiNode::split_out_instance() also for Phi nodes with > non-instance OopPtr type which matches the instance type, > - stop compilation instead of VM exit when there is no space > for scratch buffer in CodeCache, > - don't flatten instance type in alias types, > - skip the split through phi in LoadNode::Ideal() if the Region node > dominates load's address, > - an allocation is not scalar replaceable if the resuilt is stored > into unknown array's element, > - try 2 Region's input paths in Node::dominates(), > - add missing checks for ConN node. --- type.hpp The odd naming is distracting between TypePtr::points_to_narrowoop, TypePtr:: _is_ptr_to_narrowoop, Type::is_ptr_to_narrowoop. Suggest s/points_to_narrowoop/is_ptr_to_narrowoop_nv/ (where_nv is already in use to mean "I'm a hacked non-virtual version".) ---memnode.cpp Suggest a comment on MemNode::Ideal_DU_postCCP that n is not necessarily a memnode, and that nothing other than its control might be updated. Suggest replacing the goto with structured control flow. While you are at it, factor the "Split through Phi" stuff into a subroutine, since it is two screenfuls all by itself. --- callnode.cpp > - use subclass check instead of alias types check in > CallNode::may_modify(), The webrev patch differs from the diff. Which is more current? The patch looks more correct (and is a more conservative change). Side comment: This logic feels rickety to me. (And the names are confusing.) Why the pre-existing exemption of interfaces? They act here just like Object. The point is that an actual argument of type AT_K might be used to modify slice ADR_K+OFFSET, if AT_K and ADR_K overlap properly, and the type analysis determines that possibility. This can happen if: - AT_K and ADR_K are the same - AT_K is an interface which ADR_K implements (actually, since interface types cannot be trusted in opto, AT_K is any interface) - AT_K is a non-exact proper superclass of ADR_K (proposed fix disregards exactness of AT_K) The diff (not the patch) includes this case: - AT_K is a proper subclass of ADR_K That doesn't follow, since ADR_K the exact type of an allocation site (not a super type), and if AT_K is a proper subclass, it can never refer to the same object. Maybe a few more comments would help? --- rest of files The look good. Reviewed. -- John From vladimir.kozlov at sun.com Wed May 21 13:43:13 2008 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 21 May 2008 20:43:13 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6695810: null oop passed to encode_heap_oop_not_null Message-ID: <20080521204317.EEFA2284C8@hg.openjdk.java.net> Changeset: 885ed790ecf0 Author: kvn Date: 2008-05-21 10:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/885ed790ecf0 6695810: null oop passed to encode_heap_oop_not_null Summary: fix several problems in C2 related to Escape Analysis and Compressed Oops. Reviewed-by: never, jrose ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp + test/compiler/6689060/Test.java + test/compiler/6695810/Test.java From vladimir.kozlov at sun.com Wed May 21 15:50:27 2008 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 21 May 2008 22:50:27 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6703890: Compressed Oops: add LoadNKlass node to generate narrow oops (32-bits) compare instructions Message-ID: <20080521225031.AEF8B284DF@hg.openjdk.java.net> Changeset: c436414a719e Author: kvn Date: 2008-05-21 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c436414a719e 6703890: Compressed Oops: add LoadNKlass node to generate narrow oops (32-bits) compare instructions Summary: Add LoadNKlass and CMoveN nodes, use CmpN and ConN nodes to generate narrow oops compare instructions. Reviewed-by: never, rasbold ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/sparc/vm/relocInfo_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86_64.cpp ! src/cpu/x86/vm/assembler_x86_64.hpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/x86/vm/relocInfo_x86.hpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/includeDB_core ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/runtime/globals.hpp From vladimir.kozlov at sun.com Wed May 21 19:51:14 2008 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Thu, 22 May 2008 02:51:14 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6703888: Compressed Oops: use the 32-bits gap after klass in a object Message-ID: <20080522025118.B0B9428522@hg.openjdk.java.net> Changeset: 437d03ea40b1 Author: kvn Date: 2008-05-21 16:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/437d03ea40b1 6703888: Compressed Oops: use the 32-bits gap after klass in a object Summary: Use the gap also for a narrow oop field and a boxing object value. Reviewed-by: coleenp, never ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/gc_implementation/includeDB_gc_shared ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceOop.hpp From John.Rose at Sun.COM Thu May 22 01:42:48 2008 From: John.Rose at Sun.COM (John Rose) Date: Thu, 22 May 2008 01:42:48 -0700 Subject: Request for reviews (L): 6695810 and 6703890 In-Reply-To: <48325419.1050309@sun.com> References: <48325419.1050309@sun.com> Message-ID: <8FE6C27C-5F69-49CD-BF80-5202B5491B3B@sun.com> Reviewed. I have only a couple of comments. --- connode.cpp This line: if (t->isa_narrowoop()) return new (C, 1) ConNNode( t->is_narrowoop () ); should be moved into a "case T_NARROWOOP", parallel with the new line in CMoveNode::make. (Or else leave a comment behind.) --- compile.cpp It is unusual to place graph idealizations in final_graph_reshaping. Maybe you explained this verbally, but I have forgotten what the story is... Why is the CmpP(Decode, Decode) optimizations placed in final_graph_reshaping instead of in CmpP::Ideal? This deserves a comment. Otherwise, it looks great. Nice cleanups. -- John On May 19, 2008, at 9:31 PM, Vladimir Kozlov wrote: > http://webrev.invokedynamic.info/kvn/6703890/index.html > > Fixed 6703890: Compressed Oops: add LoadNKlass node to generate > narrow oops (32-bits) compare instructions > > Problem: > Currently C2 generates DecodeN and CmpP (64-bits) instructions for > klass and oop NULL checks with Compressed Oops. > > Solution: > Add LoadNKlass and CMoveN nodes, use CmpN and ConN nodes and > add correspondent platform specific assembler instructions > to generate narrow oops (32-bits) compare instructions > to avoid decoding. > > Reviewed by: never > Fix verified (y/n): y, check generated code > > Other testing: > JPRT, CTW, nsk tests > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20080522/209a227c/attachment.html From gbenson at redhat.com Thu May 22 02:17:25 2008 From: gbenson at redhat.com (Gary Benson) Date: Thu, 22 May 2008 10:17:25 +0100 Subject: Failing typeflow responsibility assertions In-Reply-To: References: <20080516084237.GA3704@redhat.com> <200E1632-3850-445C-B32E-7A0F6A497BAC@sun.com> <20080520074445.GA3861@redhat.com> Message-ID: <20080522091725.GB3794@redhat.com> John Rose wrote: > On May 20, 2008, at 12:44 AM, Gary Benson wrote: > > So does the ciTypeFlow pass actually load the unloaded classes for > > you? > > No, the JIT tries pretty hard not to load classes. IIRC, the only > exception to this rule is the call to load_signature_classes in > compileBroker.cpp. So the 'assert(will_link, "typeflow responsibility")' bits aren't being hit because the typeflow pass bails out? (ie env()->failing() returns true?) Will the compile broker retry the compilation later? > JIT compilation should be transparent to Java execution, but loading > classes causes class loader code to execute. If the JIT causes > bytecode execution, then the JIT can cause application state > changes, which explores new application states unnecessarily. This > can expose JIT-entangled bugs in the application. You want this in > stress testing, but not in the field. > > The JVM spec. allows class loading--not initialization--for any > reason, but it's better (for system reproducibility) if the JIT has > no detectable effect on app. state except speedups. That makes sense :) Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Thu May 22 02:29:45 2008 From: gbenson at redhat.com (Gary Benson) Date: Thu, 22 May 2008 10:29:45 +0100 Subject: Failing typeflow responsibility assertions In-Reply-To: <48347A34.7090504@sun.com> References: <20080516084237.GA3704@redhat.com> <48347A34.7090504@sun.com> Message-ID: <20080522092945.GC3794@redhat.com> Hi Tom, I'm using LLVM, a library which (amongst other things) contains compiler backends for several platforms. My original plan was to generate LLVM IR from one of the compilers' IRs but the problem with that is that LLVM IR is not assembly language -- assumptions embedded in C1 and C2 don't hold and working around each one is time consuming and hacky. It might take me a month to make the register allocator cope with not having registers -- and until I had a working JIT there's no guarantee I wouldn't run across a terminal problem. Cheers, Gary Tom Rodriguez wrote: > I'm curious why you are spending time writing a new java compiler > front end instead of replacing the back end of c1 or c2. Writing > and maintaining a new front end will be a bunch of work and it > doesn't seem necessary. You should be able to generate code > starting either from C1 or C2's high level IR without that much > difficulty. I know of licensees that do exactly that. > > tom > > Gary Benson wrote: > > Hi all, > > > > There's loads of bits in c2 that look like this: > > > > bool will_link; > > ciInstanceKlass* klass = > > iter().get_klass(will_link)->as_instance_klass(); > > assert(will_link, "_new: typeflow responsibility"); > > > > I'm doing the same in the JIT I'm writing, but I keep on failing > > these assertions. Do I have to do something to tell the > > CompileBroker not to feed me methods full of unloaded stuff? > > Oh, and I'm using -Xmixed. > > > > Cheers, > > Gary -- http://gbenson.net/ From Thomas.Rodriguez at Sun.COM Thu May 22 09:47:51 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 22 May 2008 09:47:51 -0700 Subject: Failing typeflow responsibility assertions In-Reply-To: <20080522092945.GC3794@redhat.com> References: <20080516084237.GA3704@redhat.com> <48347A34.7090504@sun.com> <20080522092945.GC3794@redhat.com> Message-ID: <4835A3B7.3070409@sun.com> > I'm using LLVM, a library which (amongst other things) contains > compiler backends for several platforms. My original plan was to > generate LLVM IR from one of the compilers' IRs but the problem > with that is that LLVM IR is not assembly language -- assumptions > embedded in C1 and C2 don't hold and working around each one is > time consuming and hacky. It might take me a month to make the > register allocator cope with not having registers -- and until I > had a working JIT there's no guarantee I wouldn't run across a > terminal problem. Why would you want to make the register allocator cope with not having registers? If you are replacing the backend then you aren't using the existing register allocators. You'd simply skip everything after then high level ir is generated and you'd be responsible for filling in a code buffer that could be turned into an nmethod by new_nmethod. There are no problems in there that you aren't facing with writing a new compiler from scratch. Writing and maintaining a good, correct Java front end is work that I would recommend you do everything you can to avoid, unless of course you think it sounds like fun. These are the problem I think you are really facing and maybe you already have answer for these: 1. How do you derive oopmaps from the generated code? 2. How do you get hotspot's relocation information into the code you generate? 3. If you are intending to support deoptimization, how do you get at the locations of the needed values. This is similar to 1 but may imply a little more complexity. 4. Some things we emit, like compiled inline caches and embedded references to oop, require instruction patterns that are patchable from the runtime. Does LLVM provide the control you need? 5. What's your plan for dealing with unloaded classes? C2 does it by terminating the control flow at the unloaded bytecode and emitting an uncommon trap that will fall back to the interpreter. The class will be loaded and a new compile of the code will be generated. C1 does it by emitting special patchable instructions and rewriting them when it encounters them. I don't know which one fits better with LLVM, C1 could probably be modified to use the uncommon trap strategy if patching were too difficult. There are probably other issues but those are the ones that jump out at me. tom > Cheers, > Gary > > Tom Rodriguez wrote: >> I'm curious why you are spending time writing a new java compiler >> front end instead of replacing the back end of c1 or c2. Writing >> and maintaining a new front end will be a bunch of work and it >> doesn't seem necessary. You should be able to generate code >> starting either from C1 or C2's high level IR without that much >> difficulty. I know of licensees that do exactly that. >> >> tom >> >> Gary Benson wrote: >>> Hi all, >>> >>> There's loads of bits in c2 that look like this: >>> >>> bool will_link; >>> ciInstanceKlass* klass = >>> iter().get_klass(will_link)->as_instance_klass(); >>> assert(will_link, "_new: typeflow responsibility"); >>> >>> I'm doing the same in the JIT I'm writing, but I keep on failing >>> these assertions. Do I have to do something to tell the >>> CompileBroker not to feed me methods full of unloaded stuff? >>> Oh, and I'm using -Xmixed. >>> >>> Cheers, >>> Gary > From John.Rose at Sun.COM Thu May 22 11:02:35 2008 From: John.Rose at Sun.COM (John Rose) Date: Thu, 22 May 2008 11:02:35 -0700 Subject: Failing typeflow responsibility assertions In-Reply-To: <20080522091725.GB3794@redhat.com> References: <20080516084237.GA3704@redhat.com> <200E1632-3850-445C-B32E-7A0F6A497BAC@sun.com> <20080520074445.GA3861@redhat.com> <20080522091725.GB3794@redhat.com> Message-ID: <3950F6EA-B65B-485F-B336-D64F048B681E@sun.com> On May 22, 2008, at 2:17 AM, Gary Benson wrote: > So the 'assert(will_link, "typeflow responsibility")' bits aren't > being hit because the typeflow pass bails out? (ie env()->failing() > returns true?) Will the compile broker retry the compilation later? No, typeflow ends such a block with a "trap". (If we bailed out on every unloaded class, we'd almost never compile anything.) A trap is like a branch to the interpreter (deopt). The parser is responsible for respecting those trap markings. A basic block that ends in a trap never gets (in compiled code) to the branch or return that ends the basic block in the bytecodes. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20080522/748d3bff/attachment.html From Vladimir.Kozlov at Sun.COM Thu May 22 14:07:24 2008 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Thu, 22 May 2008 14:07:24 -0700 Subject: Request for reviews (M): 6705887: Compressed Oops: generate x64 addressing and implicit null checks with narrow oops Message-ID: <4835E08C.5090303@sun.com> Thanks to already existing code it was easer than I thought. I will add another RFE to add debug info for narrow oops. Changes in connode.cpp and memnode.cpp are from comments on previous 6703890 changes. Thanks, Vladimir http://webrev.invokedynamic.info/kvn/6705887/index.html Fixed 6705887: Compressed Oops: generate x64 addressing and implicit null checks with narrow oops Problem: Currently C2 generates explicit narrow oops NULL checks (after 6703890 fix) and decode narrow oops to form an extended address for x64. Solution: Generate addresses and implicit null checks with narrow oops to avoid decoding. Reviewed by: Fix verified (y/n): y, generated code: 1c2 movl R10, [R10 + #16 + RDI << #2] # compressed ptr 1c7 decode_heap_oop RBP,R10 25b movl R11, [R12 + R10 << 3 + #8] (compressed oop addressing) # compressed klass ptr 260 NullCheck R10 Other testing: JPRT From gbenson at redhat.com Fri May 23 01:33:24 2008 From: gbenson at redhat.com (Gary Benson) Date: Fri, 23 May 2008 09:33:24 +0100 Subject: Failing typeflow responsibility assertions In-Reply-To: <4835A3B7.3070409@sun.com> References: <20080516084237.GA3704@redhat.com> <48347A34.7090504@sun.com> <20080522092945.GC3794@redhat.com> <4835A3B7.3070409@sun.com> Message-ID: <20080523083324.GB3780@redhat.com> Tom Rodriguez wrote: > Why would you want to make the register allocator cope with not > having registers? If you are replacing the backend then you aren't > using the existing register allocators. You'd simply skip > everything after then high level ir is generated and you'd be > responsible for filling in a code buffer that could be turned into > an nmethod by new_nmethod. There are no problems in there that you > aren't facing with writing a new compiler from scratch. Writing and > maintaining a good, correct Java front end is work that I would > recommend you do everything you can to avoid, unless of course you > think it sounds like fun. The register allocator was just a random example I remembered from six months ago when I looked at writing a direct ppc client port briefly. The answers to your questions are better examples I think. For example, I've no access to the compiled code, so I can't patch oops, I have to write everything without inlining them. Would it be possible to get C1 or C2 to never inline an oop? If so I may re-think my strategy! :) > These are the problem I think you are really facing and maybe you > already have answer for these: > > 1. How do you derive oopmaps from the generated code? I don't know that I can. One question I've been saving up for a while is how does the interpreter do this? Looking at frame.[hc]pp I see a lot of stuff that compiled frames are expected to provide that I probably can't -- it may be that I'll end up giving my compiled frames the same layout as the interpreter frames and doing whatever the interpreter does to tell the GC where the oops are. The problem being, I'm most familiar with the C++ interpreter, and I can't for the life of me see how it does this! > 2. How do you get hotspot's relocation information into the code > you generate? I can't, I can't rewrite the code once it's generated. I have to write the code without ever inlining oops. > 3. If you are intending to support deoptimization, how do you get > at the locations of the needed values. This is similar to 1 but may > imply a little more complexity. The way I'm currently heading is to allocate stack space for all locals and stack slots and to write them out from wherever LLVM has them (registers, etc) before method calls or safepoints. I may make the frame identical in layout to the interpreter frames so I can use the same decaching code so that deoptimization is simply a matter of starting the interpreter at bci X. > 4. Some things we emit, like compiled inline caches and embedded > references to oop, require instruction patterns that are patchable > from the runtime. Does LLVM provide the control you need? >From this question I think I misunderstood what you were asking for 2. > 5. What's your plan for dealing with unloaded classes? C2 does > it by terminating the control flow at the unloaded bytecode and > emitting an uncommon trap that will fall back to the interpreter. > The class will be loaded and a new compile of the code will be > generated. C1 does it by emitting special patchable instructions > and rewriting them when it encounters them. I don't know which one > fits better with LLVM, C1 could probably be modified to use the > uncommon trap strategy if patching were too difficult. I'm planning to do it like C2, I really like how it does it. > There are probably other issues but those are the ones that jump out > at me. Interfacing with the GC is the most troubling for me at the moment. If you can (or know anyone who can) point me in the right direction it would be much appreciated! Cheers, Gary -- http://gbenson.net/ From Vladimir.Kozlov at Sun.COM Tue May 27 23:19:17 2008 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 27 May 2008 23:19:17 -0700 Subject: Request for reviews (S): 6706829: Compressed Oops: add debug info for narrow oops Message-ID: <483CF965.4090602@sun.com> http://webrev.invokedynamic.info/kvn/6706829/index.html Fixed 6706829: Compressed Oops: add debug info for narrow oops Problem: Currently C2 generates decoding of narrow oops to provide inputs for debug info which does not support narrow oops. Solution: Add support for narrow oops in debug info to avoid decoding. Use 32 bits for the debug info Location value and use 4 bits for type. Generate narrow oops in debug info only for uncommon traps for now. For regular calls and safepoints additional checks should be added to make sure that DecodeN is not used after the call (safepoint) for which it was replaced with its input in debug info. Such change is more complex and will be done later. Reviewed by: Fix verified (y/n): y, generated code Other testing: JPRT From Steve.Goldman at Sun.COM Wed May 28 07:03:05 2008 From: Steve.Goldman at Sun.COM (steve goldman) Date: Wed, 28 May 2008 10:03:05 -0400 Subject: Please review (XXS) Message-ID: <483D6619.9080201@sun.com> Fixed 6707485: bytecodeInterpreterWithChecks.xsl is malformed The file src/share/vm/interpreter/bytecodeInterpreterWithChecks.xsl places the xsl:output tag within the xsl:template element. The xslt spec says that the output tag must be at the top level (i.e. a child of xsl:stylesheet). Reviewed by: Contributed by: gnu_andrew at member.fsf.org Fix verified (y/n): build c++ interpreter on sparc Other testing: webrev: http://webrev.invokedynamic.info/sgoldman/6707485/ -- Steve From steve.goldman at sun.com Wed May 28 18:36:25 2008 From: steve.goldman at sun.com (steve.goldman at sun.com) Date: Thu, 29 May 2008 01:36:25 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6707485: bytecodeInterpreterWithChecks.xsl is malformed Message-ID: <20080529013627.A05022898C@hg.openjdk.java.net> Changeset: aaa1137c5ef4 Author: sgoldman Date: 2008-05-28 12:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/aaa1137c5ef4 6707485: bytecodeInterpreterWithChecks.xsl is malformed Summary: xsl output tag not at top level Reviewed-by: never, kvn, rasbold Contributed-by: gnu_andrew at member.fsf.org ! src/share/vm/interpreter/bytecodeInterpreterWithChecks.xml ! src/share/vm/interpreter/bytecodeInterpreterWithChecks.xsl From coleen.phillimore at sun.com Wed May 28 23:48:42 2008 From: coleen.phillimore at sun.com (coleen.phillimore at sun.com) Date: Thu, 29 May 2008 06:48:42 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6696264: assert("narrow oop can never be zero") for GCBasher & ParNewGC Message-ID: <20080529064846.A862928C8C@hg.openjdk.java.net> Changeset: feeb96a45707 Author: coleenp Date: 2008-05-28 21:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/feeb96a45707 6696264: assert("narrow oop can never be zero") for GCBasher & ParNewGC Summary: decouple set_klass() with zeroing the gap when compressed. Reviewed-by: kvn, ysr, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86_64.cpp ! src/cpu/x86/vm/assembler_x86_64.hpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp From vladimir.kozlov at sun.com Thu May 29 15:15:04 2008 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Thu, 29 May 2008 22:15:04 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6705887: Compressed Oops: generate x64 addressing and implicit null checks with narrow oops Message-ID: <20080529221508.EB16728D40@hg.openjdk.java.net> Changeset: 7793bd37a336 Author: kvn Date: 2008-05-29 12:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7793bd37a336 6705887: Compressed Oops: generate x64 addressing and implicit null checks with narrow oops Summary: Generate addresses and implicit null checks with narrow oops to avoid decoding. Reviewed-by: jrose, never ! src/cpu/x86/vm/assembler_x86_32.hpp ! src/cpu/x86/vm/assembler_x86_64.hpp ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/linux_x86/vm/assembler_linux_x86_32.cpp ! src/os_cpu/linux_x86/vm/assembler_linux_x86_64.cpp ! src/os_cpu/solaris_x86/vm/assembler_solaris_x86_32.cpp ! src/os_cpu/solaris_x86/vm/assembler_solaris_x86_64.cpp ! src/os_cpu/windows_x86/vm/assembler_windows_x86_32.cpp ! src/os_cpu/windows_x86/vm/assembler_windows_x86_64.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.hpp From chuck.rasbold at sun.com Thu May 29 19:09:49 2008 From: chuck.rasbold at sun.com (chuck.rasbold at sun.com) Date: Fri, 30 May 2008 02:09:49 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6695049: (coll) Create an x86 intrinsic for Arrays.equals Message-ID: <20080530020953.797CC28D59@hg.openjdk.java.net> Changeset: 9148c65abefc Author: rasbold Date: 2008-05-29 16:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9148c65abefc 6695049: (coll) Create an x86 intrinsic for Arrays.equals Summary: Intrinsify java/util/Arrays.equals(char[], char[]) Reviewed-by: kvn, never ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp From volker.simonis at gmail.com Fri May 30 01:26:44 2008 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 30 May 2008 10:26:44 +0200 Subject: hg: jdk7/hotspot-comp/hotspot: 6695049: (coll) Create an x86 intrinsic for Arrays.equals In-Reply-To: <20080530020953.797CC28D59@hg.openjdk.java.net> References: <20080530020953.797CC28D59@hg.openjdk.java.net> Message-ID: Hi Chuck, could you observe any measurable performance improvements in any of the standard benchmarks (like JVM98, DaCapo, JBB...) with this change? Regards, Volker On 5/30/08, chuck.rasbold at sun.com wrote: > Changeset: 9148c65abefc > Author: rasbold > Date: 2008-05-29 16:22 -0700 > URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9148c65abefc > > 6695049: (coll) Create an x86 intrinsic for Arrays.equals > Summary: Intrinsify java/util/Arrays.equals(char[], char[]) > Reviewed-by: kvn, never > > ! src/cpu/x86/vm/x86_32.ad > ! src/cpu/x86/vm/x86_64.ad > ! src/share/vm/classfile/vmSymbols.hpp > ! src/share/vm/opto/classes.hpp > ! src/share/vm/opto/lcm.cpp > ! src/share/vm/opto/library_call.cpp > ! src/share/vm/opto/loopnode.cpp > ! src/share/vm/opto/matcher.cpp > ! src/share/vm/opto/memnode.cpp > ! src/share/vm/opto/memnode.hpp > ! src/share/vm/runtime/arguments.cpp > ! src/share/vm/runtime/globals.hpp > > From Chuck.Rasbold at Sun.COM Fri May 30 05:05:05 2008 From: Chuck.Rasbold at Sun.COM (Chuck Rasbold) Date: Fri, 30 May 2008 05:05:05 -0700 Subject: hg: jdk7/hotspot-comp/hotspot: 6695049: (coll) Create an x86 intrinsic for Arrays.equals In-Reply-To: References: <20080530020953.797CC28D59@hg.openjdk.java.net> Message-ID: <483FED71.8010908@sun.com> Volker - Honestly, no. However, this change paves the way for some companion changes, not yet in the JDK libraries, that should deliver a benchmark boost. -- Chuck Volker Simonis wrote: > Hi Chuck, > > could you observe any measurable performance improvements in any of > the standard benchmarks (like JVM98, DaCapo, JBB...) with this change? > > Regards, > Volker > > On 5/30/08, chuck.rasbold at sun.com wrote: >> Changeset: 9148c65abefc >> Author: rasbold >> Date: 2008-05-29 16:22 -0700 >> URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9148c65abefc >> >> 6695049: (coll) Create an x86 intrinsic for Arrays.equals >> Summary: Intrinsify java/util/Arrays.equals(char[], char[]) >> Reviewed-by: kvn, never >> >> ! src/cpu/x86/vm/x86_32.ad >> ! src/cpu/x86/vm/x86_64.ad >> ! src/share/vm/classfile/vmSymbols.hpp >> ! src/share/vm/opto/classes.hpp >> ! src/share/vm/opto/lcm.cpp >> ! src/share/vm/opto/library_call.cpp >> ! src/share/vm/opto/loopnode.cpp >> ! src/share/vm/opto/matcher.cpp >> ! src/share/vm/opto/memnode.cpp >> ! src/share/vm/opto/memnode.hpp >> ! src/share/vm/runtime/arguments.cpp >> ! src/share/vm/runtime/globals.hpp >> >>