From tom.rodriguez at oracle.com Mon Nov 1 11:25:31 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 1 Nov 2010 11:25:31 -0700 Subject: Request for reviews (M): 6987135: Performance regression on Intel platform with 32-bits edition between 6u13 and 6u14. In-Reply-To: <4CCB635B.7030708@oracle.com> References: <4CC2396D.5000701@oracle.com> <98B06EDE-B138-4389-AF13-DF9E684D0637@oracle.com> <4CCB1C08.40109@oracle.com> <4CCB635B.7030708@oracle.com> Message-ID: <2D128328-8AFF-499E-A5AE-1D62BD5AA93A@oracle.com> That looks good. tom On Oct 29, 2010, at 5:14 PM, Vladimir Kozlov wrote: > Tom suggested to use second TEMP register instead of push/pop. Here is new webrev: > > http://cr.openjdk.java.net/~kvn/6987135/webrev.02 > > Vladimir > > Vladimir Kozlov wrote: >> Thank you, Tom >> I updated webrev: >> http://cr.openjdk.java.net/~kvn/6987135/webrev.01 >> Tom Rodriguez wrote: >>> On Oct 22, 2010, at 6:25 PM, Vladimir Kozlov wrote: >>> >>>> http://cr.openjdk.java.net/~kvn/6987135/webrev.00 >>>> >>>> Fixed 6987135: Performance regression on Intel platform with 32-bits edition between 6u13 and 6u14. >>>> >>>> Changes for 6603011 added the conversion of long >>>> division by constant to the code with multiply. >>>> But some modern cpus improved DIV instruction >>>> performance. Use it for long division by constant >>>> when it is faster than code with multiply. >>> >>> The formats in x86_32.ad don't match the code. >> Fixed. >>> In modL_eReg_imm32, why can't the value be 0 or -1? >> There are Ideal transformations for such divisor values, >> DivL and ModL will never go to matcher with such divisor. >> Asserts verify it. >>> Why don't you use an immL definition that ensures that? If imm is MININT then the pcon calculation will go wrong. >> Matcher::use_asm_for_ldiv_by_con() has check for MININT. >> I added verification check into asserts. >>> >>> I believe you could do the register declarations like this: >> I updated both ModL and DivL code to use only dst. >> Thanks, >> Vladimir >>> >>> + instruct modL_eReg_imm32( eADXRegL dst, eRegL src, immL32 imm, eRegI tmp, eFlagsReg cr ) %{ >>> + match(Set dst (ModL src imm)); >>> + effect(TEMP dst, TEMP tmp, KILL cr ); >>> >>> to leave the src and tmp unbound which would give the RA a little more freedom. Actually wouldn't connecting src and dst directly result in fewer moves in the normal case? You might need a new temp but it seems like there are quite a few moves of src into dst for the idivl. >>> >>> + instruct modL_eReg_imm32( eADXRegL dst, immL32 imm, eSIRegI tmp, eFlagsReg cr ) %{ >>> + match(Set dst (ModL dst imm)); >>> + effect( KILL cr ); >>> >>> tom >>> >>>> Tested on US3, T1, T2, Sparc64, AMD and Intel latest cpus. >>>> >>> From vladimir.kozlov at oracle.com Mon Nov 1 11:40:07 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 01 Nov 2010 11:40:07 -0700 Subject: Request for reviews (M): 6987135: Performance regression on Intel platform with 32-bits edition between 6u13 and 6u14. In-Reply-To: <2D128328-8AFF-499E-A5AE-1D62BD5AA93A@oracle.com> References: <4CC2396D.5000701@oracle.com> <98B06EDE-B138-4389-AF13-DF9E684D0637@oracle.com> <4CCB1C08.40109@oracle.com> <4CCB635B.7030708@oracle.com> <2D128328-8AFF-499E-A5AE-1D62BD5AA93A@oracle.com> Message-ID: <4CCF0987.50809@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > That looks good. > > tom > > On Oct 29, 2010, at 5:14 PM, Vladimir Kozlov wrote: > >> Tom suggested to use second TEMP register instead of push/pop. Here is new webrev: >> >> http://cr.openjdk.java.net/~kvn/6987135/webrev.02 >> >> Vladimir >> >> Vladimir Kozlov wrote: >>> Thank you, Tom >>> I updated webrev: >>> http://cr.openjdk.java.net/~kvn/6987135/webrev.01 >>> Tom Rodriguez wrote: >>>> On Oct 22, 2010, at 6:25 PM, Vladimir Kozlov wrote: >>>> >>>>> http://cr.openjdk.java.net/~kvn/6987135/webrev.00 >>>>> >>>>> Fixed 6987135: Performance regression on Intel platform with 32-bits edition between 6u13 and 6u14. >>>>> >>>>> Changes for 6603011 added the conversion of long >>>>> division by constant to the code with multiply. >>>>> But some modern cpus improved DIV instruction >>>>> performance. Use it for long division by constant >>>>> when it is faster than code with multiply. >>>> The formats in x86_32.ad don't match the code. >>> Fixed. >>>> In modL_eReg_imm32, why can't the value be 0 or -1? >>> There are Ideal transformations for such divisor values, >>> DivL and ModL will never go to matcher with such divisor. >>> Asserts verify it. >>>> Why don't you use an immL definition that ensures that? If imm is MININT then the pcon calculation will go wrong. >>> Matcher::use_asm_for_ldiv_by_con() has check for MININT. >>> I added verification check into asserts. >>>> I believe you could do the register declarations like this: >>> I updated both ModL and DivL code to use only dst. >>> Thanks, >>> Vladimir >>>> + instruct modL_eReg_imm32( eADXRegL dst, eRegL src, immL32 imm, eRegI tmp, eFlagsReg cr ) %{ >>>> + match(Set dst (ModL src imm)); >>>> + effect(TEMP dst, TEMP tmp, KILL cr ); >>>> >>>> to leave the src and tmp unbound which would give the RA a little more freedom. Actually wouldn't connecting src and dst directly result in fewer moves in the normal case? You might need a new temp but it seems like there are quite a few moves of src into dst for the idivl. >>>> >>>> + instruct modL_eReg_imm32( eADXRegL dst, immL32 imm, eSIRegI tmp, eFlagsReg cr ) %{ >>>> + match(Set dst (ModL dst imm)); >>>> + effect( KILL cr ); >>>> >>>> tom >>>> >>>>> Tested on US3, T1, T2, Sparc64, AMD and Intel latest cpus. >>>>> > From christian.thalinger at oracle.com Tue Nov 2 02:38:41 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 2 Nov 2010 10:38:41 +0100 Subject: review request (L): 6984311 JSR 292 needs optional bootstrap method parameters In-Reply-To: <614316A7-EC07-4C52-A64C-BD97E6AF4E39@oracle.com> References: <6112D7F4-DD79-4430-A915-602F129E5F1E@oracle.com> <0EDC451E-6072-40EE-8A4C-DFA5C443BC4E@oracle.com> <614316A7-EC07-4C52-A64C-BD97E6AF4E39@oracle.com> Message-ID: <293F39DB-6C5D-490D-8C0B-B23D54ACC932@oracle.com> On Oct 30, 2010, at 9:08 PM, John Rose wrote: > On Oct 29, 2010, at 4:09 AM, Christian Thalinger wrote: > >> On Oct 28, 2010, at 8:40 PM, John Rose wrote: >>> 6984311: JSR 292 needs optional bootstrap method parameters >>> >>> http://cr.openjdk.java.net/~jrose/6984311/webrev.02/ >> >> src/share/vm/oops/constantPoolOop.cpp: >> 576 // Benign race condition: f1 may already be filled in >> while we were trying to lock. >> I guess we don't care here because the exception to be thrown is >> expected to be the same for different threads, right? > > Yes. I added more comments: > > + // Benign race condition: f1 may already be filled in while > we were trying to lock. > ++ // The important thing here is that all threads pick up the > same result. > ++ // It doesn't matter which racing thread wins, as long as only > one > ++ // result is used by all threads, and all future queries. > ++ // That result may be either a resolved constant or a failure > exception. > > This matches what is in the javadoc (for the java.dyn package-info): > * Every use of this constant pool entry must lead to the same > outcome. > * If the resolution of the names in the method handle constant > causes an exception to occur, > * this exception must be recorded by the JVM, and re-thrown on > every subsequent attempt > * to use this particular constant. > >> 1613 Bytes::put_Java_u2((address) (bytes+5), argc); >> 1614 for (int arg_i = 0; arg_i < argc; arg_i++) { >> 1615 int arg = invoke_dynamic_argument_index_at(idx, >> arg_i); >> 1616 Bytes::put_Java_u2((address) (bytes+5+2*arg_i), arg); >> 1617 } >> Isn't argc here overwritten with the first arg? > > Right! Changed 5 to 7 on line 1616. Thanks for spotting that. > >> src/share/vm/utilities/constantTag.cpp: >> >> Only the copyright year is changed. > > Fixed. > >> Otherwise looks good. > > Thanks. I am updating the webrev: > http://cr.openjdk.java.net/~jrose/6984311/webrev.03/ Looks good. -- Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20101102/9ea9a271/attachment.html From christian.thalinger at oracle.com Tue Nov 2 02:33:54 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 2 Nov 2010 10:33:54 +0100 Subject: review request (XL): 6981777: implement JSR 292 EG adjustments from summer 2010 In-Reply-To: <69F74C5D-88B1-42AC-AD6D-9882C6DCAF38@oracle.com> References: <0522FD4C-C456-4C60-83AF-5ABC494AF871@oracle.com> <69F74C5D-88B1-42AC-AD6D-9882C6DCAF38@oracle.com> Message-ID: <83368DC0-B656-42F5-B576-B179C0F54082@oracle.com> On Oct 30, 2010, at 9:20 PM, John Rose wrote: > Thanks for the review. I will answer it in detail shortly. Here's > a related (tiny) review request for JVM code. > > http://cr.openjdk.java.net/~jrose/6984311/webrev.03/src/share/vm/prims/methodHandles.cpp.udiff.html > > A tiny JVM bug was uncovered by unit-testing the big JDK changes for > 6981777. > > (It's in the *311 webrev because I thought of rolling it into the > fixes for 6984311, but then decided to split it.) The T_OBJECT check is just a shortcut so I guess the raw check is the bug fix. Anyway, the change looks good. -- Christian From christian.thalinger at oracle.com Tue Nov 2 10:56:15 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 2 Nov 2010 18:56:15 +0100 Subject: Request for reviews (XS): 6996240: The BitSet.length method sometimes returns an index+1 value less than that of the highest bit set. Message-ID: http://cr.openjdk.java.net/~twisti/6996240/webrev.01/ 6996240: The BitSet.length method sometimes returns an index+1 value less than that of the highest bit set. Reviewed-by: It's a problem with countLeadingZerosL. dst is a iRegI but is used as temporary for an iRegL OR value. The fix is to use a second temporary iRegL register for the OR value. Tested with the failing testcase attached to the CR. From tom.rodriguez at oracle.com Tue Nov 2 11:48:35 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 2 Nov 2010 11:48:35 -0700 Subject: Request for reviews (XS): 6996240: The BitSet.length method sometimes returns an index+1 value less than that of the highest bit set. In-Reply-To: References: Message-ID: You can also just declare dst to be iRegIsafe which is an integer held in a register that's also safe for longs. That might give a better register allocation. Either way is fine though. tom On Nov 2, 2010, at 10:56 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6996240/webrev.01/ > > 6996240: The BitSet.length method sometimes returns an index+1 value less than that of the highest bit set. > Reviewed-by: > > It's a problem with countLeadingZerosL. dst is a iRegI but is used as > temporary for an iRegL OR value. > > The fix is to use a second temporary iRegL register for the OR value. > > Tested with the failing testcase attached to the CR. From christian.thalinger at oracle.com Tue Nov 2 12:23:55 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 2 Nov 2010 20:23:55 +0100 Subject: Request for reviews (XS): 6996240: The BitSet.length method sometimes returns an index+1 value less than that of the highest bit set. In-Reply-To: References: Message-ID: On Nov 2, 2010, at 7:48 PM, Tom Rodriguez wrote: > You can also just declare dst to be iRegIsafe which is an integer > held in a register that's also safe for longs. That might give a > better register allocation. Either way is fine though. I didn't know there is such an operand type. Using iRegIsafe sounds better to me: http://cr.openjdk.java.net/~twisti/6996240/webrev.02/ -- Christian From tom.rodriguez at oracle.com Tue Nov 2 12:47:03 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 2 Nov 2010 12:47:03 -0700 Subject: Request for reviews (XS): 6996240: The BitSet.length method sometimes returns an index+1 value less than that of the highest bit set. In-Reply-To: References: Message-ID: <6F555321-6443-4476-A1D9-DC8421335ABE@oracle.com> Looks good. tom On Nov 2, 2010, at 12:23 PM, Christian Thalinger wrote: > On Nov 2, 2010, at 7:48 PM, Tom Rodriguez wrote: >> You can also just declare dst to be iRegIsafe which is an integer held in a register that's also safe for longs. That might give a better register allocation. Either way is fine though. > > > I didn't know there is such an operand type. Using iRegIsafe sounds better to me: > > http://cr.openjdk.java.net/~twisti/6996240/webrev.02/ > > -- Christian From vladimir.kozlov at oracle.com Tue Nov 2 12:48:55 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Nov 2010 12:48:55 -0700 Subject: Request for reviews (XS): 6996240: The BitSet.length method sometimes returns an index+1 value less than that of the highest bit set. In-Reply-To: References: Message-ID: <4CD06B27.4000807@oracle.com> Thank you, Christian All registers on sparc are 64 bit and all operations are 64 bit. Which instruction produce wrong value? Did you step per instruction in debugger? Thanks, Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6996240/webrev.01/ > > 6996240: The BitSet.length method sometimes returns an index+1 value > less than that of the highest bit set. > Reviewed-by: > > It's a problem with countLeadingZerosL. dst is a iRegI but is used as > temporary for an iRegL OR value. > > The fix is to use a second temporary iRegL register for the OR value. > > Tested with the failing testcase attached to the CR. From vladimir.kozlov at oracle.com Tue Nov 2 13:00:39 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Nov 2010 13:00:39 -0700 Subject: Request for reviews (XS): 6996240: The BitSet.length method sometimes returns an index+1 value less than that of the highest bit set. In-Reply-To: <4CD06B27.4000807@oracle.com> References: <4CD06B27.4000807@oracle.com> Message-ID: <4CD06DE7.4020902@oracle.com> Never mind, it is 32 bit execution mode. Your second webrev is good. thanks, Vladimir Vladimir Kozlov wrote: > Thank you, Christian > > All registers on sparc are 64 bit and all operations are 64 bit. > Which instruction produce wrong value? Did you step per instruction in > debugger? > > Thanks, > Vladimir > > Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/6996240/webrev.01/ >> >> 6996240: The BitSet.length method sometimes returns an index+1 value >> less than that of the highest bit set. >> Reviewed-by: >> >> It's a problem with countLeadingZerosL. dst is a iRegI but is used as >> temporary for an iRegL OR value. >> >> The fix is to use a second temporary iRegL register for the OR value. >> >> Tested with the failing testcase attached to the CR. From vladimir.kozlov at oracle.com Tue Nov 2 13:12:50 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 02 Nov 2010 20:12:50 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6987135: Performance regression on Intel platform with 32-bits edition between 6u13 and 6u14. Message-ID: <20101102201254.E0B0847673@hg.openjdk.java.net> Changeset: ae065c367d93 Author: kvn Date: 2010-11-02 09:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ae065c367d93 6987135: Performance regression on Intel platform with 32-bits edition between 6u13 and 6u14. Summary: Use hardware DIV instruction for long division by constant when it is faster than code with multiply. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/share/vm/opto/divnode.cpp ! src/share/vm/opto/matcher.hpp From tom.rodriguez at oracle.com Tue Nov 2 13:27:45 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 2 Nov 2010 13:27:45 -0700 Subject: Request for reviews (XS): 6996240: The BitSet.length method sometimes returns an index+1 value less than that of the highest bit set. In-Reply-To: <4CD06B27.4000807@oracle.com> References: <4CD06B27.4000807@oracle.com> Message-ID: <135D56FA-8499-4958-B2AF-FAA451DD103F@oracle.com> On Nov 2, 2010, at 12:48 PM, Vladimir Kozlov wrote: > Thank you, Christian > > All registers on sparc are 64 bit and all operations are 64 bit. > Which instruction produce wrong value? Did you step per instruction in debugger? In 32 bit only the g's and o's have their full 64 bit value preserved by the OS. The i's and l's are saved and restored in register window stack space that only has room for their 32 bit values. tom > > Thanks, > Vladimir > > Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/6996240/webrev.01/ >> 6996240: The BitSet.length method sometimes returns an index+1 value less than that of the highest bit set. >> Reviewed-by: >> It's a problem with countLeadingZerosL. dst is a iRegI but is used as >> temporary for an iRegL OR value. >> The fix is to use a second temporary iRegL register for the OR value. >> Tested with the failing testcase attached to the CR. From christian.thalinger at oracle.com Tue Nov 2 15:03:03 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 2 Nov 2010 23:03:03 +0100 Subject: Request for reviews (XS): 6996240: The BitSet.length method sometimes returns an index+1 value less than that of the highest bit set. In-Reply-To: <4CD06DE7.4020902@oracle.com> References: <4CD06B27.4000807@oracle.com> <4CD06DE7.4020902@oracle.com> Message-ID: <99FF66BC-08CD-40CC-9C22-DCB203B2CAC2@oracle.com> On Nov 2, 2010, at 9:00 PM, Vladimir Kozlov wrote: > Never mind, it is 32 bit execution mode. > > Your second webrev is good. Thank you, Tom and Vladimir. -- Christian From vladimir.kozlov at oracle.com Tue Nov 2 15:27:24 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Nov 2010 15:27:24 -0700 Subject: Request for reviews (S): 6991188: C2 Crashes while compiling method Message-ID: <4CD0904C.502@oracle.com> http://cr.openjdk.java.net/~kvn/6991188/webrev.00 Fixed 6991188: C2 Crashes while compiling method Construction of Connection Graph during EA relied on DU relation corresponds to nodes index so that def nodes processed before their uses. Move EA after IGVN (for 6966411 fix broke that. Because of that not all Graph edges will be created leading to incorrect EA results and incorrect Ideal graph. Walk over interesting nodes (AddP, LoadP, StoreP) several times until no new edges are created. Set limit on iterations. Tested with assert in iterations bailout code and calls to PhaseIdealLoop::verify() (removed from final changes). Passed JPRT, full CTW, nsk. From vladimir.kozlov at oracle.com Tue Nov 2 15:31:13 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Nov 2010 15:31:13 -0700 Subject: Request for reviews (XS): 6996240: The BitSet.length method sometimes returns an index+1 value less than that of the highest bit set. In-Reply-To: <135D56FA-8499-4958-B2AF-FAA451DD103F@oracle.com> References: <4CD06B27.4000807@oracle.com> <135D56FA-8499-4958-B2AF-FAA451DD103F@oracle.com> Message-ID: <4CD09131.2010801@oracle.com> Yes, I missed at first that it happens in 32 bit mode. Thanks, Vladimir Tom Rodriguez wrote: > On Nov 2, 2010, at 12:48 PM, Vladimir Kozlov wrote: > >> Thank you, Christian >> >> All registers on sparc are 64 bit and all operations are 64 bit. >> Which instruction produce wrong value? Did you step per instruction in debugger? > > In 32 bit only the g's and o's have their full 64 bit value preserved by the OS. The i's and l's are saved and restored in register window stack space that only has room for their 32 bit values. > > tom > >> Thanks, >> Vladimir >> >> Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/6996240/webrev.01/ >>> 6996240: The BitSet.length method sometimes returns an index+1 value less than that of the highest bit set. >>> Reviewed-by: >>> It's a problem with countLeadingZerosL. dst is a iRegI but is used as >>> temporary for an iRegL OR value. >>> The fix is to use a second temporary iRegL register for the OR value. >>> Tested with the failing testcase attached to the CR. > From vladimir.kozlov at oracle.com Tue Nov 2 16:42:29 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Nov 2010 16:42:29 -0700 Subject: Request for reviews (S): 6991188: C2 Crashes while compiling method In-Reply-To: <216CD9BB-CA01-49BB-87DE-802B818B4E00@oracle.com> References: <4CD0904C.502@oracle.com> <216CD9BB-CA01-49BB-87DE-802B818B4E00@oracle.com> Message-ID: <4CD0A1E5.9020204@oracle.com> Thanks, Tom Tom Rodriguez wrote: > Typo: > > + // Possible infinit build_connection_graph loop. Fixed. > > Why 10? How many passes does it normally take? Normally only 1-2 passes depending on graph complexity. In the bug test - 2, in JBB I saw 3 once. > Could this process only the nodes which changed or does it really need to reprocess every node? Only AddP, LoadP and StoreP (and narrow variants) are reprocessed. All other nodes are marked in vectSet _processed. There is check at the beginning of build_connection_graph(). I thought about using a separate worklist in new iterating code and populate it only with A/L/S nodes but I don't think it will help much. And we need to reprocess all A/L/S nodes since we don't know which nodes will be affected by one change (the chain through deferred edges could be long and split/merge through Phis). Thanks, Vladimir > > tom > > On Nov 2, 2010, at 3:27 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6991188/webrev.00 >> >> Fixed 6991188: C2 Crashes while compiling method >> >> Construction of Connection Graph during EA relied on >> DU relation corresponds to nodes index so that def >> nodes processed before their uses. Move EA after >> IGVN (for 6966411 fix broke that. Because of that >> not all Graph edges will be created leading to >> incorrect EA results and incorrect Ideal graph. >> >> Walk over interesting nodes (AddP, LoadP, StoreP) >> several times until no new edges are created. >> Set limit on iterations. >> >> Tested with assert in iterations bailout code and >> calls to PhaseIdealLoop::verify() (removed from >> final changes). Passed JPRT, full CTW, nsk. >> > From tom.rodriguez at oracle.com Tue Nov 2 16:59:12 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 2 Nov 2010 16:59:12 -0700 Subject: Request for reviews (S): 6991188: C2 Crashes while compiling method In-Reply-To: <4CD0A1E5.9020204@oracle.com> References: <4CD0904C.502@oracle.com> <216CD9BB-CA01-49BB-87DE-802B818B4E00@oracle.com> <4CD0A1E5.9020204@oracle.com> Message-ID: <048377C6-96CA-4EC9-8DB6-2A584D3D373C@oracle.com> On Nov 2, 2010, at 4:42 PM, Vladimir Kozlov wrote: > Thanks, Tom > > Tom Rodriguez wrote: >> Typo: >> + // Possible infinit build_connection_graph loop. > > Fixed. > >> Why 10? How many passes does it normally take? > > Normally only 1-2 passes depending on graph complexity. In the bug test - 2, in JBB I saw 3 once. > >> Could this process only the nodes which changed or does it really need to reprocess every node? > > Only AddP, LoadP and StoreP (and narrow variants) are reprocessed. All other nodes are marked in vectSet _processed. There is check at the beginning of build_connection_graph(). > I thought about using a separate worklist in new iterating code and populate it only with A/L/S nodes but I don't think it will help much. > And we need to reprocess all A/L/S nodes since we don't know which nodes will be affected by one change (the chain through deferred edges could be long and split/merge through Phis). Sounds and looks good. tom > > Thanks, > Vladimir > >> tom >> On Nov 2, 2010, at 3:27 PM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/6991188/webrev.00 >>> >>> Fixed 6991188: C2 Crashes while compiling method >>> >>> Construction of Connection Graph during EA relied on >>> DU relation corresponds to nodes index so that def >>> nodes processed before their uses. Move EA after >>> IGVN (for 6966411 fix broke that. Because of that >>> not all Graph edges will be created leading to >>> incorrect EA results and incorrect Ideal graph. >>> >>> Walk over interesting nodes (AddP, LoadP, StoreP) >>> several times until no new edges are created. >>> Set limit on iterations. >>> >>> Tested with assert in iterations bailout code and >>> calls to PhaseIdealLoop::verify() (removed from >>> final changes). Passed JPRT, full CTW, nsk. >>> From tom.rodriguez at oracle.com Tue Nov 2 16:12:38 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 2 Nov 2010 16:12:38 -0700 Subject: Request for reviews (S): 6991188: C2 Crashes while compiling method In-Reply-To: <4CD0904C.502@oracle.com> References: <4CD0904C.502@oracle.com> Message-ID: <216CD9BB-CA01-49BB-87DE-802B818B4E00@oracle.com> Typo: + // Possible infinit build_connection_graph loop. Why 10? How many passes does it normally take? Could this process only the nodes which changed or does it really need to reprocess every node? tom On Nov 2, 2010, at 3:27 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6991188/webrev.00 > > Fixed 6991188: C2 Crashes while compiling method > > Construction of Connection Graph during EA relied on > DU relation corresponds to nodes index so that def > nodes processed before their uses. Move EA after > IGVN (for 6966411 fix broke that. Because of that > not all Graph edges will be created leading to > incorrect EA results and incorrect Ideal graph. > > Walk over interesting nodes (AddP, LoadP, StoreP) > several times until no new edges are created. > Set limit on iterations. > > Tested with assert in iterations bailout code and > calls to PhaseIdealLoop::verify() (removed from > final changes). Passed JPRT, full CTW, nsk. > From john.r.rose at oracle.com Tue Nov 2 23:00:41 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 2 Nov 2010 23:00:41 -0700 Subject: review request (XS): 6996563: 6984311 changes forgot to update vmStructs.cpp for new field _operands Message-ID: <406CCF4B-6437-4399-85C5-4F7239BB452A@oracle.com> Bug summary says it all. http://cr.openjdk.java.net/~jrose/6996563/webrev/ I may update this webrev if I find other problems during testing. -- John From christian.thalinger at oracle.com Wed Nov 3 01:05:56 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 3 Nov 2010 09:05:56 +0100 Subject: review request (XS): 6996563: 6984311 changes forgot to update vmStructs.cpp for new field _operands In-Reply-To: <406CCF4B-6437-4399-85C5-4F7239BB452A@oracle.com> References: <406CCF4B-6437-4399-85C5-4F7239BB452A@oracle.com> Message-ID: On Nov 3, 2010, at 7:00 AM, John Rose wrote: > Bug summary says it all. > > http://cr.openjdk.java.net/~jrose/6996563/webrev/ > > I may update this webrev if I find other problems during testing. Looks good. -- Christian From christian.thalinger at oracle.com Wed Nov 3 01:13:04 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 3 Nov 2010 09:13:04 +0100 Subject: Request for reviews (S): 6991188: C2 Crashes while compiling method In-Reply-To: <4CD0904C.502@oracle.com> References: <4CD0904C.502@oracle.com> Message-ID: On Nov 2, 2010, at 11:27 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6991188/webrev.00 > > Fixed 6991188: C2 Crashes while compiling method > > Construction of Connection Graph during EA relied on > DU relation corresponds to nodes index so that def > nodes processed before their uses. Move EA after > IGVN (for 6966411 fix broke that. Because of that > not all Graph edges will be created leading to > incorrect EA results and incorrect Ideal graph. > > Walk over interesting nodes (AddP, LoadP, StoreP) > several times until no new edges are created. > Set limit on iterations. > > Tested with assert in iterations bailout code and > calls to PhaseIdealLoop::verify() (removed from > final changes). Passed JPRT, full CTW, nsk. > src/share/vm/opto/escape.hpp: + // Add a edge of the specified type pointing to the specified target. + // Set _progress if new esge is added. I think this should be "an edge" and esge -> edge. -- Christian From Christian.Thalinger at Sun.COM Wed Nov 3 02:45:25 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Wed, 03 Nov 2010 09:45:25 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6996240: The BitSet.length method sometimes returns an index+1 value less than that of the highest bit set. Message-ID: <20101103094531.5C8D14768F@hg.openjdk.java.net> Changeset: 885e464e1a40 Author: twisti Date: 2010-11-02 14:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/885e464e1a40 6996240: The BitSet.length method sometimes returns an index+1 value less than that of the highest bit set. Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad From vladimir.kozlov at oracle.com Wed Nov 3 09:24:18 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Nov 2010 09:24:18 -0700 Subject: Request for reviews (S): 6991188: C2 Crashes while compiling method In-Reply-To: References: <4CD0904C.502@oracle.com> Message-ID: <4CD18CB2.9070702@oracle.com> Thank you, Christian Vladimir On 11/3/10 1:13 AM, Christian Thalinger wrote: > On Nov 2, 2010, at 11:27 PM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/6991188/webrev.00 >> >> Fixed 6991188: C2 Crashes while compiling method >> >> Construction of Connection Graph during EA relied on >> DU relation corresponds to nodes index so that def >> nodes processed before their uses. Move EA after >> IGVN (for 6966411 fix broke that. Because of that >> not all Graph edges will be created leading to >> incorrect EA results and incorrect Ideal graph. >> >> Walk over interesting nodes (AddP, LoadP, StoreP) >> several times until no new edges are created. >> Set limit on iterations. >> >> Tested with assert in iterations bailout code and >> calls to PhaseIdealLoop::verify() (removed from >> final changes). Passed JPRT, full CTW, nsk. >> > > > src/share/vm/opto/escape.hpp: > + // Add a edge of the specified type pointing to the specified target. > + // Set _progress if new esge is added. > I think this should be "an edge" and esge -> edge. > > -- Christian From vladimir.kozlov at oracle.com Wed Nov 3 09:24:43 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Nov 2010 09:24:43 -0700 Subject: review request (XS): 6996563: 6984311 changes forgot to update vmStructs.cpp for new field _operands In-Reply-To: <406CCF4B-6437-4399-85C5-4F7239BB452A@oracle.com> References: <406CCF4B-6437-4399-85C5-4F7239BB452A@oracle.com> Message-ID: <4CD18CCB.90801@oracle.com> Looks good. Vladimir On 11/2/10 11:00 PM, John Rose wrote: > Bug summary says it all. > > http://cr.openjdk.java.net/~jrose/6996563/webrev/ > > I may update this webrev if I find other problems during testing. > > -- John From y.s.ramakrishna at oracle.com Wed Nov 3 09:59:53 2010 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Wed, 03 Nov 2010 09:59:53 -0700 Subject: Request for reviews (S): 6991188: C2 Crashes while compiling method In-Reply-To: <048377C6-96CA-4EC9-8DB6-2A584D3D373C@oracle.com> References: <4CD0904C.502@oracle.com> <216CD9BB-CA01-49BB-87DE-802B818B4E00@oracle.com> <4CD0A1E5.9020204@oracle.com> <048377C6-96CA-4EC9-8DB6-2A584D3D373C@oracle.com> Message-ID: <4CD19509.6070901@oracle.com> Hi Vladimir -- Just a general $0.02 comment, without my knowing anything about what is actually being done here. Can you give an upper bound on the number of iterations that would be needed in terms of a suitable metric on the starting graph? A little more commentary on the upper bound (if a non-trivial one exists), and the choice and suitability of the default, would be nice. Also, perhaps use a defined constant instead of the 10? (Would it be useful to have it be a diagnostic tunable?) -- ramki On 11/02/10 16:59, Tom Rodriguez wrote: > On Nov 2, 2010, at 4:42 PM, Vladimir Kozlov wrote: > >> Thanks, Tom >> >> Tom Rodriguez wrote: >>> Typo: >>> + // Possible infinit build_connection_graph loop. >> Fixed. >> >>> Why 10? How many passes does it normally take? >> Normally only 1-2 passes depending on graph complexity. In the bug test - 2, in JBB I saw 3 once. >> >>> Could this process only the nodes which changed or does it really need to reprocess every node? >> Only AddP, LoadP and StoreP (and narrow variants) are reprocessed. All other nodes are marked in vectSet _processed. There is check at the beginning of build_connection_graph(). >> I thought about using a separate worklist in new iterating code and populate it only with A/L/S nodes but I don't think it will help much. >> And we need to reprocess all A/L/S nodes since we don't know which nodes will be affected by one change (the chain through deferred edges could be long and split/merge through Phis). > > Sounds and looks good. > > tom > >> Thanks, >> Vladimir >> >>> tom >>> On Nov 2, 2010, at 3:27 PM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/6991188/webrev.00 >>>> >>>> Fixed 6991188: C2 Crashes while compiling method >>>> >>>> Construction of Connection Graph during EA relied on >>>> DU relation corresponds to nodes index so that def >>>> nodes processed before their uses. Move EA after >>>> IGVN (for 6966411 fix broke that. Because of that >>>> not all Graph edges will be created leading to >>>> incorrect EA results and incorrect Ideal graph. >>>> >>>> Walk over interesting nodes (AddP, LoadP, StoreP) >>>> several times until no new edges are created. >>>> Set limit on iterations. >>>> >>>> Tested with assert in iterations bailout code and >>>> calls to PhaseIdealLoop::verify() (removed from >>>> final changes). Passed JPRT, full CTW, nsk. >>>> > From vladimir.kozlov at oracle.com Wed Nov 3 10:16:32 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Nov 2010 10:16:32 -0700 Subject: Request for reviews (S): 6991188: C2 Crashes while compiling method In-Reply-To: <4CD19509.6070901@oracle.com> References: <4CD0904C.502@oracle.com> <216CD9BB-CA01-49BB-87DE-802B818B4E00@oracle.com> <4CD0A1E5.9020204@oracle.com> <048377C6-96CA-4EC9-8DB6-2A584D3D373C@oracle.com> <4CD19509.6070901@oracle.com> Message-ID: <4CD198F0.5080507@oracle.com> Thank you, Ramki How about this?: // Normally only 1-3 passes needed to build // Connection Graph depending on graph complexity. // Set limit to 10 to catch situation when something // did go wrong and recompile the method without EA. #define CG_BUILD_ITER_LIMIT 10 int iterations = 0; while(_progress && (iterations++ < CG_BUILD_ITER_LIMIT)) { Thanks, Vladimir Y. S. Ramakrishna wrote: > Hi Vladimir -- > > Just a general $0.02 comment, without my knowing anything about > what is actually being done here. > > Can you give an upper bound on the number of iterations > that would be needed in terms of a suitable metric on the > starting graph? A little more commentary on the upper bound > (if a non-trivial one exists), and the choice and suitability of > the default, would be nice. > > Also, perhaps use a defined constant instead of the 10? (Would it > be useful to have it be a diagnostic tunable?) > > -- ramki > > On 11/02/10 16:59, Tom Rodriguez wrote: >> On Nov 2, 2010, at 4:42 PM, Vladimir Kozlov wrote: >> >>> Thanks, Tom >>> >>> Tom Rodriguez wrote: >>>> Typo: >>>> + // Possible infinit build_connection_graph loop. >>> Fixed. >>> >>>> Why 10? How many passes does it normally take? >>> Normally only 1-2 passes depending on graph complexity. In the bug >>> test - 2, in JBB I saw 3 once. >>> >>>> Could this process only the nodes which changed or does it really >>>> need to reprocess every node? >>> Only AddP, LoadP and StoreP (and narrow variants) are reprocessed. >>> All other nodes are marked in vectSet _processed. There is check at >>> the beginning of build_connection_graph(). >>> I thought about using a separate worklist in new iterating code and >>> populate it only with A/L/S nodes but I don't think it will help much. >>> And we need to reprocess all A/L/S nodes since we don't know which >>> nodes will be affected by one change (the chain through deferred >>> edges could be long and split/merge through Phis). >> >> Sounds and looks good. >> >> tom >> >>> Thanks, >>> Vladimir >>> >>>> tom >>>> On Nov 2, 2010, at 3:27 PM, Vladimir Kozlov wrote: >>>>> http://cr.openjdk.java.net/~kvn/6991188/webrev.00 >>>>> >>>>> Fixed 6991188: C2 Crashes while compiling method >>>>> >>>>> Construction of Connection Graph during EA relied on >>>>> DU relation corresponds to nodes index so that def >>>>> nodes processed before their uses. Move EA after >>>>> IGVN (for 6966411 fix broke that. Because of that >>>>> not all Graph edges will be created leading to >>>>> incorrect EA results and incorrect Ideal graph. >>>>> >>>>> Walk over interesting nodes (AddP, LoadP, StoreP) >>>>> several times until no new edges are created. >>>>> Set limit on iterations. >>>>> >>>>> Tested with assert in iterations bailout code and >>>>> calls to PhaseIdealLoop::verify() (removed from >>>>> final changes). Passed JPRT, full CTW, nsk. >>>>> >> From y.s.ramakrishna at oracle.com Wed Nov 3 10:39:35 2010 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Wed, 03 Nov 2010 10:39:35 -0700 Subject: Request for reviews (S): 6991188: C2 Crashes while compiling method In-Reply-To: <4CD198F0.5080507@oracle.com> References: <4CD0904C.502@oracle.com> <216CD9BB-CA01-49BB-87DE-802B818B4E00@oracle.com> <4CD0A1E5.9020204@oracle.com> <048377C6-96CA-4EC9-8DB6-2A584D3D373C@oracle.com> <4CD19509.6070901@oracle.com> <4CD198F0.5080507@oracle.com> Message-ID: <4CD19E57.7020806@oracle.com> On 11/03/10 10:16, Vladimir Kozlov wrote: > Thank you, Ramki > > How about this?: > > // Normally only 1-3 passes needed to build > // Connection Graph depending on graph complexity. > // Set limit to 10 to catch situation when something > // did go wrong and recompile the method without EA. > #define CG_BUILD_ITER_LIMIT 10 > int iterations = 0; > while(_progress && (iterations++ < CG_BUILD_ITER_LIMIT)) { I suppose it is not possible to say "The maximum number of times we might need to iterate in the worst case is bounded above by k*n, where k is the foo-metric of the graph and n is its bar-metric", or ".. where foo is the number of deferred edges and bar is the number of nodes of type AddBaz in the starting graph", or some such structural complexity metric/property of the code or the graph being transformed? What you have above looks good otherwise. (You have another use of 10 after the wile loop, at line 1610, which i am guessing you would also change to use the defined constant.) Also, what does the #iterations bound? The cost of the Escape Analysis, or the size of the resulting code or both? (i.e. what kind of cost is the iteration limit bounding?) It might be nice to mention that (unless that is considered obvious to those familiar with the code). Ah, may be there is no trivial upper bound, for you do say "possible infinite build_connection_graph loop" at line 1611, which i missed on my previous reading. That does make some of my comments above about upper bound and cost-limiting somewhat moot. Sorry again for my naive and nit-picky-sounding comments, stemming from my lack of any bkgrd or knowledge of this code, so feel free to take all of this with the right dose of salt (i.e. with lots of it) :-) Thanks. -- ramki > > Thanks, > Vladimir > > Y. S. Ramakrishna wrote: >> Hi Vladimir -- >> >> Just a general $0.02 comment, without my knowing anything about >> what is actually being done here. >> >> Can you give an upper bound on the number of iterations >> that would be needed in terms of a suitable metric on the >> starting graph? A little more commentary on the upper bound >> (if a non-trivial one exists), and the choice and suitability of >> the default, would be nice. >> >> Also, perhaps use a defined constant instead of the 10? (Would it >> be useful to have it be a diagnostic tunable?) >> >> -- ramki >> >> On 11/02/10 16:59, Tom Rodriguez wrote: >>> On Nov 2, 2010, at 4:42 PM, Vladimir Kozlov wrote: >>> >>>> Thanks, Tom >>>> >>>> Tom Rodriguez wrote: >>>>> Typo: >>>>> + // Possible infinit build_connection_graph loop. >>>> Fixed. >>>> >>>>> Why 10? How many passes does it normally take? >>>> Normally only 1-2 passes depending on graph complexity. In the bug >>>> test - 2, in JBB I saw 3 once. >>>> >>>>> Could this process only the nodes which changed or does it really >>>>> need to reprocess every node? >>>> Only AddP, LoadP and StoreP (and narrow variants) are reprocessed. >>>> All other nodes are marked in vectSet _processed. There is check at >>>> the beginning of build_connection_graph(). >>>> I thought about using a separate worklist in new iterating code and >>>> populate it only with A/L/S nodes but I don't think it will help much. >>>> And we need to reprocess all A/L/S nodes since we don't know which >>>> nodes will be affected by one change (the chain through deferred >>>> edges could be long and split/merge through Phis). >>> >>> Sounds and looks good. >>> >>> tom >>> >>>> Thanks, >>>> Vladimir >>>> >>>>> tom >>>>> On Nov 2, 2010, at 3:27 PM, Vladimir Kozlov wrote: >>>>>> http://cr.openjdk.java.net/~kvn/6991188/webrev.00 >>>>>> >>>>>> Fixed 6991188: C2 Crashes while compiling method >>>>>> >>>>>> Construction of Connection Graph during EA relied on >>>>>> DU relation corresponds to nodes index so that def >>>>>> nodes processed before their uses. Move EA after >>>>>> IGVN (for 6966411 fix broke that. Because of that >>>>>> not all Graph edges will be created leading to >>>>>> incorrect EA results and incorrect Ideal graph. >>>>>> >>>>>> Walk over interesting nodes (AddP, LoadP, StoreP) >>>>>> several times until no new edges are created. >>>>>> Set limit on iterations. >>>>>> >>>>>> Tested with assert in iterations bailout code and >>>>>> calls to PhaseIdealLoop::verify() (removed from >>>>>> final changes). Passed JPRT, full CTW, nsk. >>>>>> >>> From vladimir.kozlov at oracle.com Wed Nov 3 11:33:06 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Nov 2010 11:33:06 -0700 Subject: Request for reviews (S): 6991188: C2 Crashes while compiling method In-Reply-To: <4CD19E57.7020806@oracle.com> References: <4CD0904C.502@oracle.com> <216CD9BB-CA01-49BB-87DE-802B818B4E00@oracle.com> <4CD0A1E5.9020204@oracle.com> <048377C6-96CA-4EC9-8DB6-2A584D3D373C@oracle.com> <4CD19509.6070901@oracle.com> <4CD198F0.5080507@oracle.com> <4CD19E57.7020806@oracle.com> Message-ID: <4CD1AAE2.6050101@oracle.com> Y. S. Ramakrishna wrote: > > > On 11/03/10 10:16, Vladimir Kozlov wrote: >> Thank you, Ramki >> >> How about this?: >> >> // Normally only 1-3 passes needed to build >> // Connection Graph depending on graph complexity. >> // Set limit to 10 to catch situation when something >> // did go wrong and recompile the method without EA. >> #define CG_BUILD_ITER_LIMIT 10 >> int iterations = 0; >> while(_progress && (iterations++ < CG_BUILD_ITER_LIMIT)) { > > I suppose it is not possible to say "The maximum number of > times we might need to iterate in the worst case is bounded > above by k*n, where k is the foo-metric of the graph and > n is its bar-metric", or ".. where foo is the number of > deferred edges and bar is the number of > nodes of type AddBaz in the starting graph", or some such > structural complexity metric/property of the code or the graph being > transformed? No. You can't calculate how many iterations you will need. > > What you have above looks good otherwise. (You have another use of > 10 after the wile loop, at line 1610, which i am guessing you would also > change to use the defined constant.) Correct, I also added #undef: if (iterations >= CG_BUILD_ITER_LIMIT) { // Possible infinite build_connection_graph loop. // Retry compilation without escape analysis. C->record_failure(C2Compiler::retry_no_escape_analysis()); _collecting = false; return false; } #undef CG_BUILD_ITER_LIMIT > > Also, what does the #iterations bound? The cost of the Escape Analysis, > or the size of the resulting code or both? (i.e. what kind of cost is > the iteration limit bounding?) It might be nice to mention that (unless > that is considered obvious to those familiar with the code). As new comment say iterations bound check tries to catch situations when after 10 iterations new graph edges are still added when we expect that graph construction should be finished after, say, no more than 4 (I never saw 4) iterations in 99.99% cases. Reaching 10 iterations could mean 2 things: 1. Something did go wrong, for example bug in the EA code, which cause infinite edges adding. We need to break out from such situation. 2. The java code is very complex and it really needs more than 10 iterations to construct Connection Graph. We want to bail out it also since it would, most likely, cause reaching Ideal nodes number limit and we bail out later anyway. Thanks, Vladimir > > Ah, may be there is no trivial upper bound, for you do say "possible > infinite > build_connection_graph loop" at line 1611, which i missed on my > previous reading. That does make some of my comments above about > upper bound and cost-limiting somewhat moot. > > Sorry again for my naive and nit-picky-sounding comments, stemming from my > lack of any bkgrd or knowledge of this code, so feel free to take all > of this with the right dose of salt (i.e. with lots of it) :-) > > Thanks. > -- ramki > >> >> Thanks, >> Vladimir >> >> Y. S. Ramakrishna wrote: >>> Hi Vladimir -- >>> >>> Just a general $0.02 comment, without my knowing anything about >>> what is actually being done here. >>> >>> Can you give an upper bound on the number of iterations >>> that would be needed in terms of a suitable metric on the >>> starting graph? A little more commentary on the upper bound >>> (if a non-trivial one exists), and the choice and suitability of >>> the default, would be nice. >>> >>> Also, perhaps use a defined constant instead of the 10? (Would it >>> be useful to have it be a diagnostic tunable?) >>> >>> -- ramki >>> >>> On 11/02/10 16:59, Tom Rodriguez wrote: >>>> On Nov 2, 2010, at 4:42 PM, Vladimir Kozlov wrote: >>>> >>>>> Thanks, Tom >>>>> >>>>> Tom Rodriguez wrote: >>>>>> Typo: >>>>>> + // Possible infinit build_connection_graph loop. >>>>> Fixed. >>>>> >>>>>> Why 10? How many passes does it normally take? >>>>> Normally only 1-2 passes depending on graph complexity. In the bug >>>>> test - 2, in JBB I saw 3 once. >>>>> >>>>>> Could this process only the nodes which changed or does it really >>>>>> need to reprocess every node? >>>>> Only AddP, LoadP and StoreP (and narrow variants) are reprocessed. >>>>> All other nodes are marked in vectSet _processed. There is check at >>>>> the beginning of build_connection_graph(). >>>>> I thought about using a separate worklist in new iterating code and >>>>> populate it only with A/L/S nodes but I don't think it will help much. >>>>> And we need to reprocess all A/L/S nodes since we don't know which >>>>> nodes will be affected by one change (the chain through deferred >>>>> edges could be long and split/merge through Phis). >>>> >>>> Sounds and looks good. >>>> >>>> tom >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> tom >>>>>> On Nov 2, 2010, at 3:27 PM, Vladimir Kozlov wrote: >>>>>>> http://cr.openjdk.java.net/~kvn/6991188/webrev.00 >>>>>>> >>>>>>> Fixed 6991188: C2 Crashes while compiling method >>>>>>> >>>>>>> Construction of Connection Graph during EA relied on >>>>>>> DU relation corresponds to nodes index so that def >>>>>>> nodes processed before their uses. Move EA after >>>>>>> IGVN (for 6966411 fix broke that. Because of that >>>>>>> not all Graph edges will be created leading to >>>>>>> incorrect EA results and incorrect Ideal graph. >>>>>>> >>>>>>> Walk over interesting nodes (AddP, LoadP, StoreP) >>>>>>> several times until no new edges are created. >>>>>>> Set limit on iterations. >>>>>>> >>>>>>> Tested with assert in iterations bailout code and >>>>>>> calls to PhaseIdealLoop::verify() (removed from >>>>>>> final changes). Passed JPRT, full CTW, nsk. >>>>>>> >>>> From y.s.ramakrishna at oracle.com Wed Nov 3 11:41:07 2010 From: y.s.ramakrishna at oracle.com (Y. S. Ramakrishna) Date: Wed, 03 Nov 2010 11:41:07 -0700 Subject: Request for reviews (S): 6991188: C2 Crashes while compiling method In-Reply-To: <4CD1AAE2.6050101@oracle.com> References: <4CD0904C.502@oracle.com> <216CD9BB-CA01-49BB-87DE-802B818B4E00@oracle.com> <4CD0A1E5.9020204@oracle.com> <048377C6-96CA-4EC9-8DB6-2A584D3D373C@oracle.com> <4CD19509.6070901@oracle.com> <4CD198F0.5080507@oracle.com> <4CD19E57.7020806@oracle.com> <4CD1AAE2.6050101@oracle.com> Message-ID: <4CD1ACC3.2000602@oracle.com> Sounds good; thanks for your patient explanation, Vladimir! :-) -- ramki On 11/03/10 11:33, Vladimir Kozlov wrote: > Y. S. Ramakrishna wrote: >> >> >> On 11/03/10 10:16, Vladimir Kozlov wrote: >>> Thank you, Ramki >>> >>> How about this?: >>> >>> // Normally only 1-3 passes needed to build >>> // Connection Graph depending on graph complexity. >>> // Set limit to 10 to catch situation when something >>> // did go wrong and recompile the method without EA. >>> #define CG_BUILD_ITER_LIMIT 10 >>> int iterations = 0; >>> while(_progress && (iterations++ < CG_BUILD_ITER_LIMIT)) { >> >> I suppose it is not possible to say "The maximum number of >> times we might need to iterate in the worst case is bounded >> above by k*n, where k is the foo-metric of the graph and >> n is its bar-metric", or ".. where foo is the number of >> deferred edges and bar is the number of >> nodes of type AddBaz in the starting graph", or some such >> structural complexity metric/property of the code or the graph being >> transformed? > > No. You can't calculate how many iterations you will need. > >> >> What you have above looks good otherwise. (You have another use of >> 10 after the wile loop, at line 1610, which i am guessing you would >> also change to use the defined constant.) > > Correct, I also added #undef: > > if (iterations >= CG_BUILD_ITER_LIMIT) { > // Possible infinite build_connection_graph loop. > // Retry compilation without escape analysis. > C->record_failure(C2Compiler::retry_no_escape_analysis()); > _collecting = false; > return false; > } > #undef CG_BUILD_ITER_LIMIT > >> >> Also, what does the #iterations bound? The cost of the Escape Analysis, >> or the size of the resulting code or both? (i.e. what kind of cost is >> the iteration limit bounding?) It might be nice to mention that (unless >> that is considered obvious to those familiar with the code). > > As new comment say iterations bound check tries to catch situations > when after 10 iterations new graph edges are still added when we > expect that graph construction should be finished after, say, no more > than 4 (I never saw 4) iterations in 99.99% cases. > Reaching 10 iterations could mean 2 things: > 1. Something did go wrong, for example bug in the EA code, which > cause infinite edges adding. We need to break out from such situation. > 2. The java code is very complex and it really needs more than 10 > iterations to construct Connection Graph. We want to bail out > it also since it would, most likely, cause reaching Ideal nodes number > limit and we bail out later anyway. > > Thanks, > Vladimir > >> >> Ah, may be there is no trivial upper bound, for you do say "possible >> infinite >> build_connection_graph loop" at line 1611, which i missed on my >> previous reading. That does make some of my comments above about >> upper bound and cost-limiting somewhat moot. >> >> Sorry again for my naive and nit-picky-sounding comments, stemming >> from my >> lack of any bkgrd or knowledge of this code, so feel free to take all >> of this with the right dose of salt (i.e. with lots of it) :-) >> >> Thanks. >> -- ramki >> >>> >>> Thanks, >>> Vladimir >>> >>> Y. S. Ramakrishna wrote: >>>> Hi Vladimir -- >>>> >>>> Just a general $0.02 comment, without my knowing anything about >>>> what is actually being done here. >>>> >>>> Can you give an upper bound on the number of iterations >>>> that would be needed in terms of a suitable metric on the >>>> starting graph? A little more commentary on the upper bound >>>> (if a non-trivial one exists), and the choice and suitability of >>>> the default, would be nice. >>>> >>>> Also, perhaps use a defined constant instead of the 10? (Would it >>>> be useful to have it be a diagnostic tunable?) >>>> >>>> -- ramki >>>> >>>> On 11/02/10 16:59, Tom Rodriguez wrote: >>>>> On Nov 2, 2010, at 4:42 PM, Vladimir Kozlov wrote: >>>>> >>>>>> Thanks, Tom >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> Typo: >>>>>>> + // Possible infinit build_connection_graph loop. >>>>>> Fixed. >>>>>> >>>>>>> Why 10? How many passes does it normally take? >>>>>> Normally only 1-2 passes depending on graph complexity. In the bug >>>>>> test - 2, in JBB I saw 3 once. >>>>>> >>>>>>> Could this process only the nodes which changed or does it really >>>>>>> need to reprocess every node? >>>>>> Only AddP, LoadP and StoreP (and narrow variants) are reprocessed. >>>>>> All other nodes are marked in vectSet _processed. There is check >>>>>> at the beginning of build_connection_graph(). >>>>>> I thought about using a separate worklist in new iterating code >>>>>> and populate it only with A/L/S nodes but I don't think it will >>>>>> help much. >>>>>> And we need to reprocess all A/L/S nodes since we don't know which >>>>>> nodes will be affected by one change (the chain through deferred >>>>>> edges could be long and split/merge through Phis). >>>>> >>>>> Sounds and looks good. >>>>> >>>>> tom >>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> tom >>>>>>> On Nov 2, 2010, at 3:27 PM, Vladimir Kozlov wrote: >>>>>>>> http://cr.openjdk.java.net/~kvn/6991188/webrev.00 >>>>>>>> >>>>>>>> Fixed 6991188: C2 Crashes while compiling method >>>>>>>> >>>>>>>> Construction of Connection Graph during EA relied on >>>>>>>> DU relation corresponds to nodes index so that def >>>>>>>> nodes processed before their uses. Move EA after >>>>>>>> IGVN (for 6966411 fix broke that. Because of that >>>>>>>> not all Graph edges will be created leading to >>>>>>>> incorrect EA results and incorrect Ideal graph. >>>>>>>> >>>>>>>> Walk over interesting nodes (AddP, LoadP, StoreP) >>>>>>>> several times until no new edges are created. >>>>>>>> Set limit on iterations. >>>>>>>> >>>>>>>> Tested with assert in iterations bailout code and >>>>>>>> calls to PhaseIdealLoop::verify() (removed from >>>>>>>> final changes). Passed JPRT, full CTW, nsk. >>>>>>>> >>>>> From christian.thalinger at oracle.com Thu Nov 4 03:55:06 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 4 Nov 2010 11:55:06 +0100 Subject: hg: jdk7/hotspot-comp/hotspot: 4 new changesets In-Reply-To: <20101030235048.A5A4647565@hg.openjdk.java.net> References: <20101030235048.A5A4647565@hg.openjdk.java.net> Message-ID: <4AA244FA-CEB3-4D96-85D6-D888F0DAE40D@oracle.com> On Oct 31, 2010, at 1:50 AM, john.r.rose at oracle.com wrote: > Changeset: fff777a71346 > Author: jrose > Date: 2010-10-30 11:45 -0700 > URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fff777a71346 > > 6994093: MethodHandle.invokeGeneric needs porting to SPARC > Summary: SPARC code missing from fix to 6939224 > Reviewed-by: twisti > > ! src/cpu/sparc/vm/assembler_sparc.hpp > ! src/cpu/sparc/vm/assembler_sparc.inline.hpp > ! src/cpu/sparc/vm/methodHandles_sparc.cpp That change has a regression. I filed: 6997459: JSR 292 after 6994093 getting: on return to interpreted call, restored SP is corrupted I send out a fix in a minute. -- Christian From christian.thalinger at oracle.com Thu Nov 4 04:55:47 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 4 Nov 2010 12:55:47 +0100 Subject: Request for reviews (S): 6997459: JSR 292 after 6994093 getting: on return to interpreted call, restored SP is corrupted Message-ID: <8EA7BCF0-2CF2-4BBC-92F7-5AB637944A6A@oracle.com> http://cr.openjdk.java.net/~twisti/6997459/webrev.01/ 6997459: JSR 292 after 6994093 getting: on return to interpreted call, restored SP is corrupted Reviewed-by: After 6994093 running a testcase on SPARC that should throw a WrongMethodTypeException results in an assert. The problem is that the change of 6994093 destroys O5 which is the saved sender SP and that leads to bogus FP values. The fix is to change temporary register usage in MethodHandles::generate_method_handle_interpreter_entry to preserve O5. Tested with failing testcase. From vladimir.kozlov at oracle.com Thu Nov 4 10:42:17 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 04 Nov 2010 10:42:17 -0700 Subject: Request for reviews (S): 6997311: SIGFPE in new long division asm code Message-ID: <4CD2F079.6050109@oracle.com> http://cr.openjdk.java.net/~kvn/6997311/webrev.00 Fixed 6997311: SIGFPE in new long division asm code Regression after changes added for 6987135. IDIV instruction throws SIGFPE if sign of result does not fit into 32 bit. I have to use unsigned DIV instruction and convert negative dividend to positive and result back. So more code. Added missing cast to long in 6603011/Test.java which prevented me to catch this situation during work on 6987135. Added additional verification output for failure (the same as for int testing). Tested with failed Nightly tests and fixed 6603011/Test. From vladimir.kozlov at oracle.com Thu Nov 4 11:00:18 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 04 Nov 2010 11:00:18 -0700 Subject: Request for reviews (S): 6997459: JSR 292 after 6994093 getting: on return to interpreted call, restored SP is corrupted In-Reply-To: <8EA7BCF0-2CF2-4BBC-92F7-5AB637944A6A@oracle.com> References: <8EA7BCF0-2CF2-4BBC-92F7-5AB637944A6A@oracle.com> Message-ID: <4CD2F4B2.3040804@oracle.com> Christian, What value O0 has on entry? The same as O5? You do not explain why you did next change. Before you store O5 and now O0 (at the beginning of method): __ delayed()->nop(); ! __ mov(O5_mtype, G5_method_type); // required by throw_WrongMethodType --- ! __ mov(O0_mtype, G5_method_type); // required by throw_WrongMethodType // mov(G3_method_handle, G3_method_handle); // already in this register Thanks, Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6997459/webrev.01/ > > 6997459: JSR 292 after 6994093 getting: on return to interpreted call, > restored SP is corrupted > Reviewed-by: > > After 6994093 running a testcase on SPARC that should throw a > WrongMethodTypeException results in an assert. The problem is that > the change of 6994093 destroys O5 which is the saved sender SP and > that leads to bogus FP values. > > The fix is to change temporary register usage in > MethodHandles::generate_method_handle_interpreter_entry to preserve > O5. > > Tested with failing testcase. From christian.thalinger at oracle.com Thu Nov 4 11:24:31 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 4 Nov 2010 19:24:31 +0100 Subject: Request for reviews (S): 6997459: JSR 292 after 6994093 getting: on return to interpreted call, restored SP is corrupted In-Reply-To: <4CD2F4B2.3040804@oracle.com> References: <8EA7BCF0-2CF2-4BBC-92F7-5AB637944A6A@oracle.com> <4CD2F4B2.3040804@oracle.com> Message-ID: On Nov 4, 2010, at 7:00 PM, Vladimir Kozlov wrote: > Christian, > > What value O0 has on entry? The same as O5? You do not explain why > you did > next change. Before you store O5 and now O0 (at the beginning of > method): > > __ delayed()->nop(); > ! __ mov(O5_mtype, G5_method_type); // required by > throw_WrongMethodType > --- > ! __ mov(O0_mtype, G5_method_type); // required by > throw_WrongMethodType > // mov(G3_method_handle, G3_method_handle); // already in this > register Yeah, that is a little confusing. The entry point is not at the beginning of the code but at line 101 here: http://cr.openjdk.java.net/~twisti/6997459/webrev.01/src/cpu/sparc/vm/methodHandles_sparc.cpp.sdiff.html The code before that line is exception handling and the branching code sets O0 to the right value. -- Christian From vladimir.kozlov at oracle.com Thu Nov 4 11:36:02 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 04 Nov 2010 11:36:02 -0700 Subject: Request for reviews (S): 6997459: JSR 292 after 6994093 getting: on return to interpreted call, restored SP is corrupted In-Reply-To: References: <8EA7BCF0-2CF2-4BBC-92F7-5AB637944A6A@oracle.com> <4CD2F4B2.3040804@oracle.com> Message-ID: <4CD2FD12.4020306@oracle.com> Got it. Looks good. Thanks, Vladimir Christian Thalinger wrote: > On Nov 4, 2010, at 7:00 PM, Vladimir Kozlov wrote: >> Christian, >> >> What value O0 has on entry? The same as O5? You do not explain why you >> did >> next change. Before you store O5 and now O0 (at the beginning of method): >> >> __ delayed()->nop(); >> ! __ mov(O5_mtype, G5_method_type); // required by >> throw_WrongMethodType >> --- >> ! __ mov(O0_mtype, G5_method_type); // required by >> throw_WrongMethodType >> // mov(G3_method_handle, G3_method_handle); // already in this >> register > > Yeah, that is a little confusing. The entry point is not at the > beginning of the code but at line 101 here: > > http://cr.openjdk.java.net/~twisti/6997459/webrev.01/src/cpu/sparc/vm/methodHandles_sparc.cpp.sdiff.html > > > The code before that line is exception handling and the branching code > sets O0 to the right value. > > -- Christian From john.r.rose at oracle.com Thu Nov 4 12:09:38 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 4 Nov 2010 12:09:38 -0700 Subject: Request for reviews (S): 6997459: JSR 292 after 6994093 getting: on return to interpreted call, restored SP is corrupted In-Reply-To: <8EA7BCF0-2CF2-4BBC-92F7-5AB637944A6A@oracle.com> References: <8EA7BCF0-2CF2-4BBC-92F7-5AB637944A6A@oracle.com> Message-ID: Reviewed; good fix. Thanks for jumping on it so quickly. -- John On Nov 4, 2010, at 4:55 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6997459/webrev.01/ > > 6997459: JSR 292 after 6994093 getting: on return to interpreted call, restored SP is corrupted > Reviewed-by: > > After 6994093 running a testcase on SPARC that should throw a > WrongMethodTypeException results in an assert. The problem is that > the change of 6994093 destroys O5 which is the saved sender SP and > that leads to bogus FP values. > > The fix is to change temporary register usage in > MethodHandles::generate_method_handle_interpreter_entry to preserve > O5. > > Tested with failing testcase. From tom.rodriguez at oracle.com Thu Nov 4 12:12:12 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 4 Nov 2010 12:12:12 -0700 Subject: Request for reviews (S): 6997459: JSR 292 after 6994093 getting: on return to interpreted call, restored SP is corrupted In-Reply-To: <8EA7BCF0-2CF2-4BBC-92F7-5AB637944A6A@oracle.com> References: <8EA7BCF0-2CF2-4BBC-92F7-5AB637944A6A@oracle.com> Message-ID: Looks good. tom On Nov 4, 2010, at 4:55 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6997459/webrev.01/ > > 6997459: JSR 292 after 6994093 getting: on return to interpreted call, restored SP is corrupted > Reviewed-by: > > After 6994093 running a testcase on SPARC that should throw a > WrongMethodTypeException results in an assert. The problem is that > the change of 6994093 destroys O5 which is the saved sender SP and > that leads to bogus FP values. > > The fix is to change temporary register usage in > MethodHandles::generate_method_handle_interpreter_entry to preserve > O5. > > Tested with failing testcase. From john.r.rose at oracle.com Thu Nov 4 13:10:02 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 4 Nov 2010 13:10:02 -0700 Subject: Request for reviews (S): 6997459: JSR 292 after 6994093 getting: on return to interpreted call, restored SP is corrupted In-Reply-To: <4CD2F4B2.3040804@oracle.com> References: <8EA7BCF0-2CF2-4BBC-92F7-5AB637944A6A@oracle.com> <4CD2F4B2.3040804@oracle.com> Message-ID: On Nov 4, 2010, at 11:00 AM, Vladimir Kozlov wrote: > What value O0 has on entry? The same as O5? You do not explain why you did > next change. Before you store O5 and now O0 (at the beginning of method): That block of code is not the beginning of the method. See the comment at the top of the hunk: // emit WrongMethodType path first, to enable back-branch from main path -- John From p.thio at xs4all.nl Thu Nov 4 13:38:35 2010 From: p.thio at xs4all.nl (Paul Thio) Date: Thu, 4 Nov 2010 21:38:35 +0100 Subject: tiered compilation and CompileThreshold Message-ID: When using tiered compilation, is it possible to set the compile threshold of the c1 compiler ? When -XX:+TieredCompilation is specified, it seems to ignore -XX:CompileThreshold. From Christian.Thalinger at Sun.COM Thu Nov 4 15:14:53 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 04 Nov 2010 22:14:53 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6997459: JSR 292 after 6994093 getting: on return to interpreted call, restored SP is corrupted Message-ID: <20101104221456.E3AAD476F4@hg.openjdk.java.net> Changeset: e62345fd6a46 Author: twisti Date: 2010-11-04 12:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e62345fd6a46 6997459: JSR 292 after 6994093 getting: on return to interpreted call, restored SP is corrupted Reviewed-by: kvn, jrose, never ! src/cpu/sparc/vm/methodHandles_sparc.cpp From vladimir.kozlov at oracle.com Thu Nov 4 15:24:09 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 04 Nov 2010 15:24:09 -0700 Subject: Request for reviews (S): 6991188: C2 Crashes while compiling method In-Reply-To: <4CD0904C.502@oracle.com> References: <4CD0904C.502@oracle.com> Message-ID: <4CD33289.6040106@oracle.com> http://cr.openjdk.java.net/~kvn/6991188/webrev.01 I updated changes based on comments and found issues. Use separate worklist in new loop code since cg_worklist does not have Store and Call nodes (they are UnknownType). Call node should not be marked processed since their arguments may need more then one pass to add all edges. Reuse GrowableArray worklist instead of creating few new. Thanks, Vladimir Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6991188/webrev.00 > > Fixed 6991188: C2 Crashes while compiling method > > Construction of Connection Graph during EA relied on > DU relation corresponds to nodes index so that def > nodes processed before their uses. Move EA after > IGVN (for 6966411 fix broke that. Because of that > not all Graph edges will be created leading to > incorrect EA results and incorrect Ideal graph. > > Walk over interesting nodes (AddP, LoadP, StoreP) > several times until no new edges are created. > Set limit on iterations. > > Tested with assert in iterations bailout code and > calls to PhaseIdealLoop::verify() (removed from > final changes). Passed JPRT, full CTW, nsk. > From igor.veresov at oracle.com Thu Nov 4 16:35:10 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 04 Nov 2010 16:35:10 -0700 Subject: tiered compilation and CompileThreshold In-Reply-To: References: Message-ID: <4CD3432E.2090904@oracle.com> On 11/4/10 1:38 PM, Paul Thio wrote: > When using tiered compilation, is it possible to set the compile threshold of the c1 compiler ? When -XX:+TieredCompilation is specified, it seems to ignore -XX:CompileThreshold. Yeah, it uses the following flags: Tier3InvocationThreshold = 200, Tier3MinInvocationThreshold = 100, Tier3CompileThreshold = 2000 The predicate that determines when to compile looks like that: p(i,b) = (i > Tier3InvocationThreshold) || (i > Tier3MinInvocationThreshold && i + b > Tier3CompileThreshold), where i - is the number of invocations of the method, b - number of backedges taken. igor From john.r.rose at oracle.com Fri Nov 5 00:12:29 2010 From: john.r.rose at oracle.com (John Rose) Date: Fri, 5 Nov 2010 00:12:29 -0700 Subject: review request (XS): 6996563: 6984311 changes forgot to update vmStructs.cpp for new field _operands In-Reply-To: References: <406CCF4B-6437-4399-85C5-4F7239BB452A@oracle.com> Message-ID: <5A12E0C9-6BDA-413B-985D-67D6966BBAB7@oracle.com> I did find one pre-existing bug which prevented me from validating this fix. See updated webrev. With this change, I can use the SA "dumpclass" command to create a dumped class file which has the same contents (except for stackmaps) and can be loaded by the JVM in place of the original file. http://cr.openjdk.java.net/~jrose/6996563/webrev.01 -- John On Nov 3, 2010, at 1:05 AM, Christian Thalinger wrote: > On Nov 3, 2010, at 7:00 AM, John Rose wrote: >> Bug summary says it all. >> >> http://cr.openjdk.java.net/~jrose/6996563/webrev/ >> >> I may update this webrev if I find other problems during testing. > > Looks good. -- Christian From christian.thalinger at oracle.com Fri Nov 5 02:54:29 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 5 Nov 2010 10:54:29 +0100 Subject: review request (XS): 6996563: 6984311 changes forgot to update vmStructs.cpp for new field _operands In-Reply-To: <5A12E0C9-6BDA-413B-985D-67D6966BBAB7@oracle.com> References: <406CCF4B-6437-4399-85C5-4F7239BB452A@oracle.com> <5A12E0C9-6BDA-413B-985D-67D6966BBAB7@oracle.com> Message-ID: <736AD073-DB3D-49F3-B55A-51E1584863B5@oracle.com> On Nov 5, 2010, at 8:12 AM, John Rose wrote: > I did find one pre-existing bug which prevented me from validating > this fix. See updated webrev. > > With this change, I can use the SA "dumpclass" command to create a > dumped class file which has the same contents (except for stackmaps) > and can be loaded by the JVM in place of the original file. > > http://cr.openjdk.java.net/~jrose/6996563/webrev.01 Looks good. -- Christian From forax at univ-mlv.fr Fri Nov 5 06:51:08 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 05 Nov 2010 14:51:08 +0100 Subject: review request (XS): 6996563: 6984311 changes forgot to update vmStructs.cpp for new field _operands In-Reply-To: <736AD073-DB3D-49F3-B55A-51E1584863B5@oracle.com> References: <406CCF4B-6437-4399-85C5-4F7239BB452A@oracle.com> <5A12E0C9-6BDA-413B-985D-67D6966BBAB7@oracle.com> <736AD073-DB3D-49F3-B55A-51E1584863B5@oracle.com> Message-ID: <4CD40BCC.50100@univ-mlv.fr> Le 05/11/2010 10:54, Christian Thalinger a ?crit : > On Nov 5, 2010, at 8:12 AM, John Rose wrote: >> I did find one pre-existing bug which prevented me from validating >> this fix. See updated webrev. >> >> With this change, I can use the SA "dumpclass" command to create a >> dumped class file which has the same contents (except for stackmaps) >> and can be loaded by the JVM in place of the original file. >> >> http://cr.openjdk.java.net/~jrose/6996563/webrev.01 > > Looks good. -- Christian refKind can be declared as a byte ? R?mi From vladimir.kozlov at oracle.com Fri Nov 5 09:19:38 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 05 Nov 2010 09:19:38 -0700 Subject: review request (XS): 6996563: 6984311 changes forgot to update vmStructs.cpp for new field _operands In-Reply-To: <5A12E0C9-6BDA-413B-985D-67D6966BBAB7@oracle.com> References: <406CCF4B-6437-4399-85C5-4F7239BB452A@oracle.com> <5A12E0C9-6BDA-413B-985D-67D6966BBAB7@oracle.com> Message-ID: <4CD42E9A.2030701@oracle.com> Looks good. Vladimir John Rose wrote: > I did find one pre-existing bug which prevented me from validating this fix. See updated webrev. > > With this change, I can use the SA "dumpclass" command to create a dumped class file which has the same contents (except for stackmaps) and can be loaded by the JVM in place of the original file. > > http://cr.openjdk.java.net/~jrose/6996563/webrev.01 > > -- John > > On Nov 3, 2010, at 1:05 AM, Christian Thalinger wrote: > >> On Nov 3, 2010, at 7:00 AM, John Rose wrote: >>> Bug summary says it all. >>> >>> http://cr.openjdk.java.net/~jrose/6996563/webrev/ >>> >>> I may update this webrev if I find other problems during testing. >> Looks good. -- Christian > From igor.veresov at oracle.com Fri Nov 5 12:04:10 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 05 Nov 2010 12:04:10 -0700 Subject: Request for review(XS): 6997456: Not possible to build just compiler2 Message-ID: <4CD4552A.9010208@oracle.com> This fixes the compile error. You can also now build a pure c2+int by specifying FORCE_TIERED=0 on the command line. Webrev: http://cr.openjdk.java.net/~iveresov/6997456/webrev.00/ Thanks, igor From tom.rodriguez at oracle.com Fri Nov 5 13:49:23 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 5 Nov 2010 13:49:23 -0700 Subject: Request for review(XS): 6997456: Not possible to build just compiler2 In-Reply-To: <4CD4552A.9010208@oracle.com> References: <4CD4552A.9010208@oracle.com> Message-ID: <5BABD6DF-E3E6-45D8-BB40-1C968755711A@oracle.com> Looks good. tom On Nov 5, 2010, at 12:04 PM, Igor Veresov wrote: > This fixes the compile error. You can also now build a pure c2+int by specifying FORCE_TIERED=0 on the command line. > > Webrev: http://cr.openjdk.java.net/~iveresov/6997456/webrev.00/ > > Thanks, > igor From tom.rodriguez at oracle.com Fri Nov 5 13:52:00 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 5 Nov 2010 13:52:00 -0700 Subject: Request for reviews (S): 6991188: C2 Crashes while compiling method In-Reply-To: <4CD33289.6040106@oracle.com> References: <4CD0904C.502@oracle.com> <4CD33289.6040106@oracle.com> Message-ID: <9F101F09-B241-4AB6-85FA-F76948BE9FF5@oracle.com> Should we do something more than retry without EA if it takes more iterations than we expect? Maybe an assert(false in debug mode? Otherwise it looks good. tom On Nov 4, 2010, at 3:24 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6991188/webrev.01 > > I updated changes based on comments and found issues. > Use separate worklist in new loop code since cg_worklist > does not have Store and Call nodes (they are UnknownType). > Call node should not be marked processed since their > arguments may need more then one pass to add all edges. > Reuse GrowableArray worklist instead of creating few new. > > Thanks, > Vladimir > > Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/6991188/webrev.00 >> Fixed 6991188: C2 Crashes while compiling method >> Construction of Connection Graph during EA relied on >> DU relation corresponds to nodes index so that def >> nodes processed before their uses. Move EA after >> IGVN (for 6966411 fix broke that. Because of that >> not all Graph edges will be created leading to >> incorrect EA results and incorrect Ideal graph. >> Walk over interesting nodes (AddP, LoadP, StoreP) >> several times until no new edges are created. >> Set limit on iterations. >> Tested with assert in iterations bailout code and >> calls to PhaseIdealLoop::verify() (removed from >> final changes). Passed JPRT, full CTW, nsk. From vladimir.kozlov at oracle.com Fri Nov 5 13:52:37 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 05 Nov 2010 13:52:37 -0700 Subject: Request for review(XS): 6997456: Not possible to build just compiler2 In-Reply-To: <4CD4552A.9010208@oracle.com> References: <4CD4552A.9010208@oracle.com> Message-ID: <4CD46E95.1030109@oracle.com> Looks good. Vladimir Igor Veresov wrote: > This fixes the compile error. You can also now build a pure c2+int by > specifying FORCE_TIERED=0 on the command line. > > Webrev: http://cr.openjdk.java.net/~iveresov/6997456/webrev.00/ > > Thanks, > igor From vladimir.kozlov at oracle.com Fri Nov 5 14:02:25 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 05 Nov 2010 14:02:25 -0700 Subject: Request for reviews (S): 6991188: C2 Crashes while compiling method In-Reply-To: <9F101F09-B241-4AB6-85FA-F76948BE9FF5@oracle.com> References: <4CD0904C.502@oracle.com> <4CD33289.6040106@oracle.com> <9F101F09-B241-4AB6-85FA-F76948BE9FF5@oracle.com> Message-ID: <4CD470E1.8040909@oracle.com> I had next assert when I tested these changes but I removed it from final version. I can put it back and also add number of Ideal nodes as reference. if (iterations >= CG_BUILD_ITER_LIMIT) { + assert(false, "infinit build_connection_graph loop"); // Retry compilation without escape analysis. C->record_failure(C2Compiler::retry_no_escape_analysis()); _collecting = false; return false; Thanks, Vladimir Tom Rodriguez wrote: > Should we do something more than retry without EA if it takes more iterations than we expect? Maybe an assert(false in debug mode? Otherwise it looks good. > > tom > > On Nov 4, 2010, at 3:24 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6991188/webrev.01 >> >> I updated changes based on comments and found issues. >> Use separate worklist in new loop code since cg_worklist >> does not have Store and Call nodes (they are UnknownType). >> Call node should not be marked processed since their >> arguments may need more then one pass to add all edges. >> Reuse GrowableArray worklist instead of creating few new. >> >> Thanks, >> Vladimir >> >> Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/6991188/webrev.00 >>> Fixed 6991188: C2 Crashes while compiling method >>> Construction of Connection Graph during EA relied on >>> DU relation corresponds to nodes index so that def >>> nodes processed before their uses. Move EA after >>> IGVN (for 6966411 fix broke that. Because of that >>> not all Graph edges will be created leading to >>> incorrect EA results and incorrect Ideal graph. >>> Walk over interesting nodes (AddP, LoadP, StoreP) >>> several times until no new edges are created. >>> Set limit on iterations. >>> Tested with assert in iterations bailout code and >>> calls to PhaseIdealLoop::verify() (removed from >>> final changes). Passed JPRT, full CTW, nsk. > From tom.rodriguez at oracle.com Fri Nov 5 14:29:50 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 5 Nov 2010 14:29:50 -0700 Subject: Request for reviews (S): 6997311: SIGFPE in new long division asm code In-Reply-To: <4CD2F079.6050109@oracle.com> References: <4CD2F079.6050109@oracle.com> Message-ID: I think I follow the new code and it looks ok. One typo: Fallthrow -> fallthrough. tom On Nov 4, 2010, at 10:42 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6997311/webrev.00 > > Fixed 6997311: SIGFPE in new long division asm code > > Regression after changes added for 6987135. > IDIV instruction throws SIGFPE if sign of result > does not fit into 32 bit. I have to use unsigned > DIV instruction and convert negative dividend > to positive and result back. So more code. > > Added missing cast to long in 6603011/Test.java > which prevented me to catch this situation during > work on 6987135. Added additional verification > output for failure (the same as for int testing). > > Tested with failed Nightly tests and fixed 6603011/Test. > From igor.veresov at oracle.com Fri Nov 5 14:37:22 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 05 Nov 2010 14:37:22 -0700 Subject: Request for review(XS): 6997456: Not possible to build just compiler2 In-Reply-To: <4CD46E95.1030109@oracle.com> References: <4CD4552A.9010208@oracle.com> <4CD46E95.1030109@oracle.com> Message-ID: <4CD47912.4020203@oracle.com> Thanks Tom and Vladimir! On 11/5/10 1:52 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > Igor Veresov wrote: >> This fixes the compile error. You can also now build a pure c2+int by >> specifying FORCE_TIERED=0 on the command line. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6997456/webrev.00/ >> >> Thanks, >> igor From john.r.rose at oracle.com Fri Nov 5 14:43:55 2010 From: john.r.rose at oracle.com (John Rose) Date: Fri, 5 Nov 2010 14:43:55 -0700 Subject: review request (XS): 6996563: 6984311 changes forgot to update vmStructs.cpp for new field _operands In-Reply-To: <4CD40BCC.50100@univ-mlv.fr> References: <406CCF4B-6437-4399-85C5-4F7239BB452A@oracle.com> <5A12E0C9-6BDA-413B-985D-67D6966BBAB7@oracle.com> <736AD073-DB3D-49F3-B55A-51E1584863B5@oracle.com> <4CD40BCC.50100@univ-mlv.fr> Message-ID: <76DAA2CF-3E3F-4576-BEC4-C6355C6C4DF6@oracle.com> Good idea. Done. -- John On Nov 5, 2010, at 6:51 AM, R?mi Forax wrote: > refKind can be declared as a byte ? From vladimir.kozlov at oracle.com Fri Nov 5 15:31:47 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 05 Nov 2010 15:31:47 -0700 Subject: Request for reviews (S): 6997311: SIGFPE in new long division asm code In-Reply-To: References: <4CD2F079.6050109@oracle.com> Message-ID: <4CD485D3.1040001@oracle.com> Thank you, Tom Vladimir Tom Rodriguez wrote: > I think I follow the new code and it looks ok. One typo: Fallthrow -> fallthrough. > > tom > > On Nov 4, 2010, at 10:42 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6997311/webrev.00 >> >> Fixed 6997311: SIGFPE in new long division asm code >> >> Regression after changes added for 6987135. >> IDIV instruction throws SIGFPE if sign of result >> does not fit into 32 bit. I have to use unsigned >> DIV instruction and convert negative dividend >> to positive and result back. So more code. >> >> Added missing cast to long in 6603011/Test.java >> which prevented me to catch this situation during >> work on 6987135. Added additional verification >> output for failure (the same as for int testing). >> >> Tested with failed Nightly tests and fixed 6603011/Test. >> > From john.r.rose at oracle.com Fri Nov 5 23:10:23 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 06 Nov 2010 06:10:23 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6996563: 6984311 changes forgot to update vmStructs.cpp for new field _operands Message-ID: <20101106061029.4B8F547761@hg.openjdk.java.net> Changeset: f42a2f0c16bb Author: jrose Date: 2010-11-05 12:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f42a2f0c16bb 6996563: 6984311 changes forgot to update vmStructs.cpp for new field _operands Summary: Add missing line to vmStructs. Also fix bug with class dumper. Reviewed-by: twisti, kvn ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! src/share/vm/runtime/vmStructs.cpp From igor.veresov at oracle.com Sat Nov 6 06:31:58 2010 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Sat, 06 Nov 2010 13:31:58 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20101106133206.3223847771@hg.openjdk.java.net> Changeset: 34bd82eba3bb Author: iveresov Date: 2010-11-05 14:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/34bd82eba3bb 6997456: Not possible to build just compiler2 Summary: Fix the compiler error. Allow to build just c2 specifying FORCE_TIERED=0 on the command line. Reviewed-by: never, kvn ! make/linux/Makefile ! make/solaris/Makefile ! make/windows/build.make ! src/share/vm/runtime/java.cpp Changeset: d0895dfaf7cc Author: iveresov Date: 2010-11-06 02:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d0895dfaf7cc Merge From vladimir.kozlov at oracle.com Sat Nov 6 21:27:21 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sun, 07 Nov 2010 04:27:21 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6997311: SIGFPE in new long division asm code Message-ID: <20101107042723.890D647791@hg.openjdk.java.net> Changeset: 2fe998383789 Author: kvn Date: 2010-11-06 18:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2fe998383789 6997311: SIGFPE in new long division asm code Summary: use unsigned DIV instruction Reviewed-by: never ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! test/compiler/6603011/Test.java From vladimir.kozlov at oracle.com Sat Nov 6 23:30:46 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sun, 07 Nov 2010 06:30:46 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6991188: C2 Crashes while compiling method Message-ID: <20101107063048.A364B4779D@hg.openjdk.java.net> Changeset: e4fcbeb5a698 Author: kvn Date: 2010-11-06 20:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e4fcbeb5a698 6991188: C2 Crashes while compiling method Summary: Do several iterations to build EA Connection Graph. Reviewed-by: never, twisti, ysr ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp From igor.veresov at oracle.com Mon Nov 8 17:15:39 2010 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Tue, 09 Nov 2010 01:15:39 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 27 new changesets Message-ID: <20101109011630.5742B47801@hg.openjdk.java.net> Changeset: 4e22405d98d6 Author: iveresov Date: 2010-10-19 11:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4e22405d98d6 6989669: Coops: -Xshare:dump causes crash Summary: Temporarily fix to disable compressed oops with CDS Reviewed-by: dholmes, twisti, kvn, never ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 68d6141ea19d Author: cl Date: 2010-10-07 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/68d6141ea19d Added tag jdk7-b113 for changeset beef35b96b81 ! .hgtags Changeset: 52f19c724d96 Author: trims Date: 2010-10-14 15:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/52f19c724d96 Merge ! .hgtags Changeset: 570870354f86 Author: trims Date: 2010-10-14 16:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/570870354f86 6992267: Bump the HS20 build number to 02 Summary: Update the HS20 build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 477faa484f91 Author: cl Date: 2010-10-14 19:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/477faa484f91 Added tag jdk7-b114 for changeset 68d6141ea19d ! .hgtags Changeset: bdbc48857210 Author: trims Date: 2010-10-20 16:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/bdbc48857210 Merge ! .hgtags Changeset: 9eaf8ba53f3d Author: trims Date: 2010-10-20 17:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9eaf8ba53f3d Merge Changeset: a4c7fe54bf3f Author: kamg Date: 2010-10-21 10:10 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a4c7fe54bf3f 6991315: RedefineClasses fails with java.lang.VerifyError Summary: Repair stackmap table attribute when relocating bytecode Reviewed-by: acorn, never + src/share/vm/classfile/stackMapTableFormat.hpp ! src/share/vm/includeDB_core ! src/share/vm/oops/methodOop.hpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/runtime/relocator.hpp Changeset: fa83ab460c54 Author: acorn Date: 2010-10-22 15:59 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fa83ab460c54 6988353: refactor contended sync subsystem Summary: reduce complexity by factoring synchronizer.cpp Reviewed-by: dholmes, never, coleenp - src/os/linux/vm/objectMonitor_linux.cpp - src/os/linux/vm/objectMonitor_linux.hpp - src/os/linux/vm/objectMonitor_linux.inline.hpp - src/os/solaris/vm/objectMonitor_solaris.cpp - src/os/solaris/vm/objectMonitor_solaris.hpp - src/os/solaris/vm/objectMonitor_solaris.inline.hpp - src/os/windows/vm/objectMonitor_windows.cpp - src/os/windows/vm/objectMonitor_windows.hpp - src/os/windows/vm/objectMonitor_windows.inline.hpp ! src/share/vm/includeDB_compiler1 ! src/share/vm/includeDB_core ! src/share/vm/includeDB_features ! src/share/vm/includeDB_jvmti ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp + src/share/vm/prims/jvmtiRawMonitor.cpp + src/share/vm/prims/jvmtiRawMonitor.hpp + src/share/vm/runtime/basicLock.cpp + src/share/vm/runtime/basicLock.hpp ! src/share/vm/runtime/mutex.hpp + src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/objectMonitor.inline.hpp + src/share/vm/runtime/park.cpp + src/share/vm/runtime/park.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/synchronizer.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: a312a67b32ef Author: acorn Date: 2010-10-25 13:31 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a312a67b32ef Merge ! src/share/vm/includeDB_core Changeset: 60ce9dade348 Author: acorn Date: 2010-10-26 14:43 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/60ce9dade348 Merge Changeset: 6412b3805cd6 Author: kamg Date: 2010-10-26 14:08 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6412b3805cd6 6891959: HotSpot should not throw ClassFormatError if a class has a field with '>' and/or '<' in its name Summary: Class file parser needs to look for and disallow '[' in names. Reviewed-by: coleenp, never ! src/share/vm/classfile/classFileParser.cpp Changeset: ee0d26abaad3 Author: kamg Date: 2010-10-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ee0d26abaad3 Merge Changeset: 35e4e086d5f5 Author: tonyp Date: 2010-10-14 10:38 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/35e4e086d5f5 6990359: G1: don't push a stolen entry on the taskqueue, deal with it directly Summary: When an entry is stolen, don't push it on the task queue but process it directly. Reviewed-by: iveresov, ysr, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 9f4848ebbabd Author: tonyp Date: 2010-10-15 17:26 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9f4848ebbabd 6992189: G1: inconsistent base used in sparse rem set iterator Summary: The remembered set iterator for sparse tables incorrectly assumes that index 0 corresponds to the bottom of the heap, not address 0 as it is the case. Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp Changeset: a5c514e74487 Author: johnc Date: 2010-10-18 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a5c514e74487 6988458: G1: assert(mr.end() <= _cm->finger()) failed: otherwise the region shouldn't be on the stack Summary: The changes from 6941395 did not clear the CMTask::_aborted_region fields when concurrent marking aborted because of overflow. As a result, the next time around we could see a memory region whose start address was above the global finger and the assertion tripped. Moved the clearing of the aborted regions to ConcurrentMark::clear_marking_state, which is executed on all of the exit paths. Reviewed-by: tonyp, ysr, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 72a161e62cc4 Author: tonyp Date: 2010-10-16 17:12 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/72a161e62cc4 6991377: G1: race between concurrent refinement and humongous object allocation Summary: There is a race between the concurrent refinement threads and the humongous object allocation that can cause the concurrent refinement threads to corrupt the part of the BOT that it is being initialized by the humongous object allocation operation. The solution is to do the humongous object allocation in careful steps to ensure that the concurrent refinement threads always have a consistent view over the BOT, region contents, and top. The fix includes some very minor tidying up in sparsePRT. Reviewed-by: jcoomes, johnc, ysr ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp Changeset: cd3ef3fd20dd Author: ysr Date: 2010-10-21 17:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/cd3ef3fd20dd 6992998: CMSWaitDuration=0 causes hangs with +ExplicitGCInvokesConcurrent Summary: Closed a timing hole during which concurrent full gc requests can be missed. The hole can increase the latency of the response to a full gc request by up to the value of CMSWaitDuration. If CMSWaitDuration=0 is, as currently, interpreted as an unbounded wait, suitable in certain tuning scenarios, the application can potentially hang. Made two obscure tunables, including CMSWaitDuration, manageable. Reviewed-by: jcoomes, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/runtime/globals.hpp Changeset: a7214d79fcf1 Author: ysr Date: 2010-10-23 23:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a7214d79fcf1 6896603: CMS/GCH: collection_attempt_is_safe() ergo should use more recent data Summary: Deprecated HandlePromotionFailure, removing the ability to turn off that feature, did away with one epoch look-ahead when deciding if a scavenge is likely to fail, relying on current data. Reviewed-by: jmasa, johnc, poonam ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/tenuredGeneration.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: c766bae6c14d Author: ysr Date: 2010-10-28 14:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c766bae6c14d 6995045: assert(!gch->incremental_collection_failed()) failed: Error, defNewGeneration.cpp:827 Summary: Sharpened an assert, introduced in 6896603, that intended to check that the incremental_collection_failed() predicate on the heap was being reset "soon enough". Reviewed-by: jmasa ! src/share/vm/memory/defNewGeneration.cpp Changeset: f5c8d6e5bfee Author: jcoomes Date: 2010-11-01 10:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f5c8d6e5bfee Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 9de67bf4244d Author: iveresov Date: 2010-11-02 16:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9de67bf4244d 6996136: VM crash in src/share/vm/runtime/virtualspace.cpp:424 Summary: Turn CDS off if compressed oops is on Reviewed-by: ysr, kvn, jcoomes, phh ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 96b3f2a7add0 Author: cl Date: 2010-10-21 17:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/96b3f2a7add0 Added tag jdk7-b115 for changeset bdbc48857210 ! .hgtags Changeset: 806d0c037e6b Author: cl Date: 2010-10-28 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/806d0c037e6b Added tag jdk7-b116 for changeset 96b3f2a7add0 ! .hgtags Changeset: 08f0f4a3ddd6 Author: trims Date: 2010-11-04 15:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/08f0f4a3ddd6 Added tag hs20-b02 for changeset 52f19c724d96 ! .hgtags Changeset: 4ac698856c43 Author: trims Date: 2010-11-04 16:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4ac698856c43 Merge - src/os/linux/vm/objectMonitor_linux.cpp - src/os/linux/vm/objectMonitor_linux.hpp - src/os/linux/vm/objectMonitor_linux.inline.hpp - src/os/solaris/vm/objectMonitor_solaris.cpp - src/os/solaris/vm/objectMonitor_solaris.hpp - src/os/solaris/vm/objectMonitor_solaris.inline.hpp - src/os/windows/vm/objectMonitor_windows.cpp - src/os/windows/vm/objectMonitor_windows.hpp - src/os/windows/vm/objectMonitor_windows.inline.hpp Changeset: 5caa30ea147b Author: iveresov Date: 2010-11-08 14:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5caa30ea147b Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/includeDB_core ! src/share/vm/includeDB_features ! src/share/vm/includeDB_jvmti ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/runtime/thread.cpp From igor.veresov at oracle.com Tue Nov 9 12:31:59 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 09 Nov 2010 12:31:59 -0800 Subject: Request for review(XS): JSR 292: Remove the plug guarding the use of compressed oops Message-ID: <4CD9AFBF.9010306@oracle.com> The plug that guards the use of compressed oops with invokedynamic needs to be removed. Webrev: http://cr.openjdk.java.net/~iveresov/6998737/webrev.00/ igor From christian.thalinger at oracle.com Tue Nov 9 12:53:17 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 9 Nov 2010 21:53:17 +0100 Subject: Request for review(XS): JSR 292: Remove the plug guarding the use of compressed oops In-Reply-To: <4CD9AFBF.9010306@oracle.com> References: <4CD9AFBF.9010306@oracle.com> Message-ID: On Nov 9, 2010, at 9:31 PM, Igor Veresov wrote: > The plug that guards the use of compressed oops with invokedynamic > needs to be removed. > > Webrev: http://cr.openjdk.java.net/~iveresov/6998737/webrev.00/ Looks good. Thanks for taking that. -- Christian From vladimir.kozlov at oracle.com Tue Nov 9 14:15:54 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 09 Nov 2010 14:15:54 -0800 Subject: Request for review(XS): JSR 292: Remove the plug guarding the use of compressed oops In-Reply-To: <4CD9AFBF.9010306@oracle.com> References: <4CD9AFBF.9010306@oracle.com> Message-ID: <4CD9C81A.9030900@oracle.com> Looks good. Vladimir Igor Veresov wrote: > The plug that guards the use of compressed oops with invokedynamic needs > to be removed. > > Webrev: http://cr.openjdk.java.net/~iveresov/6998737/webrev.00/ > > igor From igor.veresov at oracle.com Tue Nov 9 14:59:07 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 09 Nov 2010 14:59:07 -0800 Subject: Request for review(XS): JSR 292: Remove the plug guarding the use of compressed oops In-Reply-To: <4CD9C81A.9030900@oracle.com> References: <4CD9AFBF.9010306@oracle.com> <4CD9C81A.9030900@oracle.com> Message-ID: <4CD9D23B.5060107@oracle.com> Thanks, Christian and Vladimir! On 11/9/10 2:15 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > Igor Veresov wrote: >> The plug that guards the use of compressed oops with invokedynamic >> needs to be removed. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6998737/webrev.00/ >> >> igor From vladimir.kozlov at oracle.com Tue Nov 9 16:57:04 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 09 Nov 2010 16:57:04 -0800 Subject: Request for reviews (XS): 6839891: Array overrun in vm ci Message-ID: <4CD9EDE0.5040304@oracle.com> http://cr.openjdk.java.net/~kvn/6839891/webrev Fixed 6839891: Array overrun in vm ci From igor.veresov at oracle.com Tue Nov 9 17:07:19 2010 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Wed, 10 Nov 2010 01:07:19 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6998737: JSR 292: Remove the plug guarding the use of compressed oops Message-ID: <20101110010721.BD89047842@hg.openjdk.java.net> Changeset: 2db84614f61d Author: iveresov Date: 2010-11-09 15:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2db84614f61d 6998737: JSR 292: Remove the plug guarding the use of compressed oops Summary: The plug that guards the use of compressed oops with invokedynamic needs to be removed Reviewed-by: twisti, kvn ! src/share/vm/runtime/arguments.cpp From tom.rodriguez at oracle.com Tue Nov 9 17:23:04 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 9 Nov 2010 17:23:04 -0800 Subject: Request for reviews (XS): 6839891: Array overrun in vm ci In-Reply-To: <4CD9EDE0.5040304@oracle.com> References: <4CD9EDE0.5040304@oracle.com> Message-ID: <0D884B80-CCB9-427F-BE54-E4BEEFEE45BD@oracle.com> Looks good. tom On Nov 9, 2010, at 4:57 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6839891/webrev > > Fixed 6839891: Array overrun in vm ci > From vladimir.kozlov at oracle.com Tue Nov 9 19:44:40 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 10 Nov 2010 03:44:40 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6839891: Array overrun in vm ci Message-ID: <20101110034444.695AF47849@hg.openjdk.java.net> Changeset: b0e6879e48fa Author: kvn Date: 2010-11-09 17:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b0e6879e48fa 6839891: Array overrun in vm ci Summary: fix index check Reviewed-by: never ! src/share/vm/ci/ciInstanceKlass.cpp From vladimir.kozlov at oracle.com Thu Nov 11 19:03:35 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Nov 2010 19:03:35 -0800 Subject: Request for reviews (S): 6999491: non-zero COOPs are used when they should not Message-ID: <4CDCAE87.9070000@oracle.com> http://cr.openjdk.java.net/~kvn/6999491/webrev Fixed 6999491: non-zero COOPs are used when they should not Regression introduced by fix for 6984368 bug. The expression in max_heap_for_compressed_oops() produces incorrect result when HeapBaseMinAddress > OopEncodingHeapMax. HeapBaseMinAddress should be used only for a default heap size calculation. Added heap size to PrintCompressedOopsMode output. From igor.veresov at oracle.com Thu Nov 11 19:29:00 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 11 Nov 2010 19:29:00 -0800 Subject: Request for reviews (S): 6999491: non-zero COOPs are used when they should not In-Reply-To: <4CDCAE87.9070000@oracle.com> References: <4CDCAE87.9070000@oracle.com> Message-ID: <4CDCB47C.7000808@oracle.com> Looks good. igor On 11/11/10 7:03 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6999491/webrev > > Fixed 6999491: non-zero COOPs are used when they should not > > Regression introduced by fix for 6984368 bug. > The expression in max_heap_for_compressed_oops() produces > incorrect result when HeapBaseMinAddress > OopEncodingHeapMax. > > HeapBaseMinAddress should be used only for a default heap > size calculation. > Added heap size to PrintCompressedOopsMode output. > From John.Coomes at oracle.com Thu Nov 11 23:39:04 2010 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 11 Nov 2010 23:39:04 -0800 Subject: Request for reviews (S): 6999491: non-zero COOPs are used when they should not In-Reply-To: <4CDCAE87.9070000@oracle.com> References: <4CDCAE87.9070000@oracle.com> Message-ID: <19676.61208.440135.435180@oracle.com> Vladimir Kozlov (vladimir.kozlov at oracle.com) wrote: > http://cr.openjdk.java.net/~kvn/6999491/webrev > > Fixed 6999491: non-zero COOPs are used when they should not > > Regression introduced by fix for 6984368 bug. > The expression in max_heap_for_compressed_oops() produces > incorrect result when HeapBaseMinAddress > OopEncodingHeapMax. > > HeapBaseMinAddress should be used only for a default heap > size calculation. > Added heap size to PrintCompressedOopsMode output. Couple of nits: In universe.cpp, reserved_region()->byte_size() returns size_t, so use SIZE_FORMAT instead of INTX_FORMAT. arguments.cpp line 1332 should match the surrounding code: no spaces inside the parens and use { }, e.g. if (OopEncodingHeapMax < MaxPermSize + os::vm_page_size()) { return 0; } Otherwise, looks good. -John From christian.thalinger at oracle.com Fri Nov 12 06:04:13 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 12 Nov 2010 15:04:13 +0100 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC Message-ID: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> http://cr.openjdk.java.net/~twisti/6961690/webrev.01/ 6961690: load oops from constant table on SPARC Summary: oops should be loaded from the constant table of an nmethod instead of materializing them with a long code sequence. Reviewed-by: oops should be loaded from the constant table of an nmethod instead of materializing them with a long code sequence. This fix introduces two new ideal nodes MachConstantBaseNode and MachConstantNode. MachConstantBaseNode represents the base address of the constant table, MachConstantNode a constant that should be read from the constant table. ADLC was changed to support three new keywords: constantaddress, constanttablebase, and constantoffset. constantaddress represents the absolute address of a constant and is used on x86. constanttablebase represents the register that holds the constant table base address and constantoffset is the relative offset to constanttablebase. The latter two are used on SPARC. For SPARC a new command line option was added: UseRDPCForConstantTableBase. If that option is true the RDPC instruction is used to get the constant table base address instead of materializing the address. This option is currently off by default and may be switched on for future SPARC implementations. The patch also includes a change from Tom that fixes a bug that was uncovered by this work: http://cr.openjdk.java.net/~twisti/6961690/webrev.01/src/share/vm/opto/postaloc.cpp.udiff.html src/cpu/sparc/vm/assembler_sparc.cpp src/cpu/sparc/vm/assembler_sparc.hpp src/cpu/sparc/vm/assembler_sparc.inline.hpp src/cpu/sparc/vm/sparc.ad src/cpu/x86/vm/assembler_x86.cpp src/cpu/x86/vm/assembler_x86.hpp src/cpu/x86/vm/x86_32.ad src/cpu/x86/vm/x86_64.ad src/os/linux/vm/vmError_linux.cpp src/share/vm/adlc/adlparse.cpp src/share/vm/adlc/adlparse.hpp src/share/vm/adlc/archDesc.hpp src/share/vm/adlc/formssel.cpp src/share/vm/adlc/formssel.hpp src/share/vm/adlc/output_c.cpp src/share/vm/adlc/output_h.cpp src/share/vm/asm/assembler.hpp src/share/vm/asm/assembler.inline.hpp src/share/vm/compiler/disassembler.cpp src/share/vm/opto/c2_globals.hpp src/share/vm/opto/compile.cpp src/share/vm/opto/compile.hpp src/share/vm/opto/gcm.cpp src/share/vm/opto/machnode.cpp src/share/vm/opto/machnode.hpp src/share/vm/opto/node.hpp src/share/vm/opto/output.cpp src/share/vm/opto/postaloc.cpp src/share/vm/utilities/debug.cpp From vladimir.kozlov at oracle.com Fri Nov 12 07:45:26 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Nov 2010 07:45:26 -0800 Subject: Request for reviews (S): 6999491: non-zero COOPs are used when they should not In-Reply-To: <19676.61208.440135.435180@oracle.com> References: <4CDCAE87.9070000@oracle.com> <19676.61208.440135.435180@oracle.com> Message-ID: <4CDD6116.1030708@oracle.com> Thank you, John I will use your suggestions. Vladimir On 11/11/10 11:39 PM, John Coomes wrote: > Vladimir Kozlov (vladimir.kozlov at oracle.com) wrote: >> http://cr.openjdk.java.net/~kvn/6999491/webrev >> >> Fixed 6999491: non-zero COOPs are used when they should not >> >> Regression introduced by fix for 6984368 bug. >> The expression in max_heap_for_compressed_oops() produces >> incorrect result when HeapBaseMinAddress> OopEncodingHeapMax. >> >> HeapBaseMinAddress should be used only for a default heap >> size calculation. >> Added heap size to PrintCompressedOopsMode output. > > Couple of nits: > > In universe.cpp, reserved_region()->byte_size() returns size_t, so use > SIZE_FORMAT instead of INTX_FORMAT. > > arguments.cpp line 1332 should match the surrounding code: no spaces > inside the parens and use { }, e.g. > > if (OopEncodingHeapMax< MaxPermSize + os::vm_page_size()) { > return 0; > } > > Otherwise, looks good. > > -John > From vladimir.kozlov at oracle.com Fri Nov 12 12:19:42 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Nov 2010 12:19:42 -0800 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC In-Reply-To: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> References: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> Message-ID: <4CDDA15E.6030603@oracle.com> Do you need to connect MachConstantBaseNode to root? For RA? And where you emit it (call emit()) since you don't add it to any block: +MachConstantBaseNode* Compile::mach_constant_base_node() { + if (_mach_constant_base_node == NULL) { + _mach_constant_base_node = new (C) MachConstantBaseNode(); + _mach_constant_base_node->set_req(0, C->root()); Why commented?: ! //assert(!n->pinned() || n->is_SafePointScalarObject(), "only SafePointScalarObject pinned node is expected here"); You don't use is_MachConstantBase() so you don't need to add it to DEFINE_CLASS in node.hpp and call init_class_id(). May be one line?: +// Machine node that holds a constant which is stored in the constant +// table. You don't need to check for is_Mach(), check directly n->is_MachConstant(): + if (n->is_Mach()) { + MachNode *mach = n->as_Mach(); + + // If the MachNode is a MachConstantNode evaluate the + // constant value section. + if (mach->is_MachConstant()) { + MachConstantNode* machcon = mach->as_MachConstant(); + machcon->eval_constant(); + } + } Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6961690/webrev.01/ > > 6961690: load oops from constant table on SPARC > Summary: oops should be loaded from the constant table of an nmethod > instead of materializing them with a long code sequence. > Reviewed-by: > > oops should be loaded from the constant table of an nmethod instead of > materializing them with a long code sequence. > > This fix introduces two new ideal nodes MachConstantBaseNode and > MachConstantNode. MachConstantBaseNode represents the base address of > the constant table, MachConstantNode a constant that should be read > from the constant table. > > ADLC was changed to support three new keywords: constantaddress, > constanttablebase, and constantoffset. constantaddress represents the > absolute address of a constant and is used on x86. constanttablebase > represents the register that holds the constant table base address and > constantoffset is the relative offset to constanttablebase. The > latter two are used on SPARC. > > For SPARC a new command line option was added: > UseRDPCForConstantTableBase. If that option is true the RDPC > instruction is used to get the constant table base address instead of > materializing the address. This option is currently off by default > and may be switched on for future SPARC implementations. > > The patch also includes a change from Tom that fixes a bug that was > uncovered by this work: > > http://cr.openjdk.java.net/~twisti/6961690/webrev.01/src/share/vm/opto/postaloc.cpp.udiff.html > > > src/cpu/sparc/vm/assembler_sparc.cpp > src/cpu/sparc/vm/assembler_sparc.hpp > src/cpu/sparc/vm/assembler_sparc.inline.hpp > src/cpu/sparc/vm/sparc.ad > src/cpu/x86/vm/assembler_x86.cpp > src/cpu/x86/vm/assembler_x86.hpp > src/cpu/x86/vm/x86_32.ad > src/cpu/x86/vm/x86_64.ad > src/os/linux/vm/vmError_linux.cpp > src/share/vm/adlc/adlparse.cpp > src/share/vm/adlc/adlparse.hpp > src/share/vm/adlc/archDesc.hpp > src/share/vm/adlc/formssel.cpp > src/share/vm/adlc/formssel.hpp > src/share/vm/adlc/output_c.cpp > src/share/vm/adlc/output_h.cpp > src/share/vm/asm/assembler.hpp > src/share/vm/asm/assembler.inline.hpp > src/share/vm/compiler/disassembler.cpp > src/share/vm/opto/c2_globals.hpp > src/share/vm/opto/compile.cpp > src/share/vm/opto/compile.hpp > src/share/vm/opto/gcm.cpp > src/share/vm/opto/machnode.cpp > src/share/vm/opto/machnode.hpp > src/share/vm/opto/node.hpp > src/share/vm/opto/output.cpp > src/share/vm/opto/postaloc.cpp > src/share/vm/utilities/debug.cpp > From vladimir.kozlov at oracle.com Fri Nov 12 12:29:53 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 12 Nov 2010 20:29:53 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6999491: non-zero COOPs are used when they should not Message-ID: <20101112202958.A008147951@hg.openjdk.java.net> Changeset: 0ac62b4d6507 Author: kvn Date: 2010-11-12 09:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0ac62b4d6507 6999491: non-zero COOPs are used when they should not Summary: HeapBaseMinAddress should be used only for a default heap size calculation. Reviewed-by: iveresov, jcoomes, dholmes ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp From vladimir.kozlov at oracle.com Fri Nov 12 13:58:23 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Nov 2010 13:58:23 -0800 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC In-Reply-To: <4CDDA15E.6030603@oracle.com> References: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> <4CDDA15E.6030603@oracle.com> Message-ID: <4CDDB87F.1050103@oracle.com> Most important is why it is not under flag? Vladimir Vladimir Kozlov wrote: > Do you need to connect MachConstantBaseNode to root? For RA? And where > you emit it (call emit()) since you don't add it to any block: > > +MachConstantBaseNode* Compile::mach_constant_base_node() { > + if (_mach_constant_base_node == NULL) { > + _mach_constant_base_node = new (C) MachConstantBaseNode(); > + _mach_constant_base_node->set_req(0, C->root()); > > Why commented?: > ! //assert(!n->pinned() || n->is_SafePointScalarObject(), "only > SafePointScalarObject pinned node is expected here"); > > You don't use is_MachConstantBase() so you don't need to add it to > DEFINE_CLASS in node.hpp and call init_class_id(). > > May be one line?: > > +// Machine node that holds a constant which is stored in the constant > +// table. > > You don't need to check for is_Mach(), check directly n->is_MachConstant(): > > + if (n->is_Mach()) { > + MachNode *mach = n->as_Mach(); > + > + // If the MachNode is a MachConstantNode evaluate the > + // constant value section. > + if (mach->is_MachConstant()) { > + MachConstantNode* machcon = mach->as_MachConstant(); > + machcon->eval_constant(); > + } > + } > > Vladimir > > Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/6961690/webrev.01/ >> >> 6961690: load oops from constant table on SPARC >> Summary: oops should be loaded from the constant table of an nmethod >> instead of materializing them with a long code sequence. >> Reviewed-by: >> >> oops should be loaded from the constant table of an nmethod instead of >> materializing them with a long code sequence. >> >> This fix introduces two new ideal nodes MachConstantBaseNode and >> MachConstantNode. MachConstantBaseNode represents the base address of >> the constant table, MachConstantNode a constant that should be read >> from the constant table. >> >> ADLC was changed to support three new keywords: constantaddress, >> constanttablebase, and constantoffset. constantaddress represents the >> absolute address of a constant and is used on x86. constanttablebase >> represents the register that holds the constant table base address and >> constantoffset is the relative offset to constanttablebase. The >> latter two are used on SPARC. >> >> For SPARC a new command line option was added: >> UseRDPCForConstantTableBase. If that option is true the RDPC >> instruction is used to get the constant table base address instead of >> materializing the address. This option is currently off by default >> and may be switched on for future SPARC implementations. >> >> The patch also includes a change from Tom that fixes a bug that was >> uncovered by this work: >> >> http://cr.openjdk.java.net/~twisti/6961690/webrev.01/src/share/vm/opto/postaloc.cpp.udiff.html >> >> >> src/cpu/sparc/vm/assembler_sparc.cpp >> src/cpu/sparc/vm/assembler_sparc.hpp >> src/cpu/sparc/vm/assembler_sparc.inline.hpp >> src/cpu/sparc/vm/sparc.ad >> src/cpu/x86/vm/assembler_x86.cpp >> src/cpu/x86/vm/assembler_x86.hpp >> src/cpu/x86/vm/x86_32.ad >> src/cpu/x86/vm/x86_64.ad >> src/os/linux/vm/vmError_linux.cpp >> src/share/vm/adlc/adlparse.cpp >> src/share/vm/adlc/adlparse.hpp >> src/share/vm/adlc/archDesc.hpp >> src/share/vm/adlc/formssel.cpp >> src/share/vm/adlc/formssel.hpp >> src/share/vm/adlc/output_c.cpp >> src/share/vm/adlc/output_h.cpp >> src/share/vm/asm/assembler.hpp >> src/share/vm/asm/assembler.inline.hpp >> src/share/vm/compiler/disassembler.cpp >> src/share/vm/opto/c2_globals.hpp >> src/share/vm/opto/compile.cpp >> src/share/vm/opto/compile.hpp >> src/share/vm/opto/gcm.cpp >> src/share/vm/opto/machnode.cpp >> src/share/vm/opto/machnode.hpp >> src/share/vm/opto/node.hpp >> src/share/vm/opto/output.cpp >> src/share/vm/opto/postaloc.cpp >> src/share/vm/utilities/debug.cpp >> From christian.thalinger at oracle.com Mon Nov 15 05:29:56 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 15 Nov 2010 14:29:56 +0100 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC In-Reply-To: <4CDDA15E.6030603@oracle.com> References: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> <4CDDA15E.6030603@oracle.com> Message-ID: <025DDC98-A2FD-458C-B55A-3D31A531D298@oracle.com> On Nov 12, 2010, at 9:19 PM, Vladimir Kozlov wrote: > Do you need to connect MachConstantBaseNode to root? For RA? And > where you emit it (call emit()) since you don't add it to any block: > > +MachConstantBaseNode* Compile::mach_constant_base_node() { > + if (_mach_constant_base_node == NULL) { > + _mach_constant_base_node = new (C) MachConstantBaseNode(); > + _mach_constant_base_node->set_req(0, C->root()); The MachConstantBaseNode is added as an input to all MachConstantNodes in their Expand method (generated by ADLC) and is emitted when all other nodes are emitted in Compile::Fill_buffer. > > Why commented?: > ! //assert(!n->pinned() || n->is_SafePointScalarObject(), "only > SafePointScalarObject pinned node is expected here"); The reason why I pin MachConstantBaseNode is to get small offsets when RDPC instructions is used. When that assert is uncommented it triggers because the node is pinned but not a SafePointScalarObject. I think the right fix would be to also allow pinned MachConstantBaseNodes in that assert. A change we could do (but I haven't tested this yet) is to not pin MachConstantBaseNodes when UseRDPCForConstanTableBase is false since we materialize the constant table base address anyway so it doesn't matter where in the code that happens. Moving the materialization closer to the use would also decrease register pressure. > > You don't use is_MachConstantBase() so you don't need to add it to > DEFINE_CLASS in node.hpp and call init_class_id(). I can remove it if we don't need it for the assert above. > > May be one line?: > > +// Machine node that holds a constant which is stored in the constant > +// table. Yes. Emacs' M-q did that. > > You don't need to check for is_Mach(), check directly n- > >is_MachConstant(): > > + if (n->is_Mach()) { > + MachNode *mach = n->as_Mach(); > + > + // If the MachNode is a MachConstantNode evaluate the > + // constant value section. > + if (mach->is_MachConstant()) { > + MachConstantNode* machcon = mach->as_MachConstant(); > + machcon->eval_constant(); > + } > + } Good point. Changed that. -- Christian From christian.thalinger at oracle.com Mon Nov 15 05:45:03 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 15 Nov 2010 14:45:03 +0100 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC In-Reply-To: <4CDDB87F.1050103@oracle.com> References: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> <4CDDA15E.6030603@oracle.com> <4CDDB87F.1050103@oracle.com> Message-ID: <1877449A-9D27-47AC-BB18-E0E8CD8B2A36@oracle.com> On Nov 12, 2010, at 10:58 PM, Vladimir Kozlov wrote: > Most important is why it is not under flag? Hmm, I never thought about putting it under a flag since in theory materializing the constant table base address only once instead of every time it's required should always be a win. -- Christian From david.cox at oracle.com Mon Nov 15 06:23:42 2010 From: david.cox at oracle.com (David Cox) Date: Mon, 15 Nov 2010 15:23:42 +0100 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC In-Reply-To: <1877449A-9D27-47AC-BB18-E0E8CD8B2A36@oracle.com> References: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> <4CDDA15E.6030603@oracle.com> <4CDDB87F.1050103@oracle.com> <1877449A-9D27-47AC-BB18-E0E8CD8B2A36@oracle.com> Message-ID: <4CE1426E.5000804@oracle.com> On 11/15/10 2:45 PM, Christian Thalinger wrote: > On Nov 12, 2010, at 10:58 PM, Vladimir Kozlov wrote: >> Most important is why it is not under flag? > > > Hmm, I never thought about putting it under a flag since in theory > materializing the constant table base address only once instead of > every time it's required should always be a win. Paul also notes that the overall optimization may not be beneficial for all SPARC incarnations so having it switchable based upon chip version would be good. Dave From paul.hohensee at oracle.com Mon Nov 15 06:28:43 2010 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 15 Nov 2010 09:28:43 -0500 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC In-Reply-To: <4CE1426E.5000804@oracle.com> References: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> <4CDDA15E.6030603@oracle.com> <4CDDB87F.1050103@oracle.com> <1877449A-9D27-47AC-BB18-E0E8CD8B2A36@oracle.com> <4CE1426E.5000804@oracle.com> Message-ID: <4CE1439B.4030703@oracle.com> The idea I had is not to put it under a command line flag, but to put it under is_niagara() or some such via VM_Version. That way, you could use -XX:+UseNiagaraInstrs to test it if you need a command line switch. Paul On 11/15/10 9:23 AM, David Cox wrote: > On 11/15/10 2:45 PM, Christian Thalinger wrote: >> On Nov 12, 2010, at 10:58 PM, Vladimir Kozlov wrote: >>> Most important is why it is not under flag? >> >> >> Hmm, I never thought about putting it under a flag since in theory >> materializing the constant table base address only once instead of >> every time it's required should always be a win. > > Paul also notes that the overall optimization may not be beneficial > for all SPARC incarnations so having it switchable based upon chip > version would be good. > > Dave From christian.thalinger at oracle.com Mon Nov 15 06:56:58 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 15 Nov 2010 15:56:58 +0100 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC In-Reply-To: <4CE1426E.5000804@oracle.com> References: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> <4CDDA15E.6030603@oracle.com> <4CDDB87F.1050103@oracle.com> <1877449A-9D27-47AC-BB18-E0E8CD8B2A36@oracle.com> <4CE1426E.5000804@oracle.com> Message-ID: <3D0F25F3-2521-47AF-B8CA-3261BD33F169@oracle.com> On Nov 15, 2010, at 3:23 PM, David Cox wrote: > On 11/15/10 2:45 PM, Christian Thalinger wrote: >> On Nov 12, 2010, at 10:58 PM, Vladimir Kozlov wrote: >>> Most important is why it is not under flag? >> >> >> Hmm, I never thought about putting it under a flag since in theory >> materializing the constant table base address only once instead of >> every time it's required should always be a win. > > Paul also notes that the overall optimization may not be beneficial > for all SPARC incarnations so having it switchable based upon chip > version would be good. But I'm not talking about RDPC just address materialization. Maybe some SPARC implementations don't have 32 on-chip registers and it could get a RA problem, don't know about that. If you want me I can add a switch. -- Christian From paul.hohensee at oracle.com Mon Nov 15 08:41:29 2010 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 15 Nov 2010 11:41:29 -0500 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC In-Reply-To: <1877449A-9D27-47AC-BB18-E0E8CD8B2A36@oracle.com> References: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> <4CDDA15E.6030603@oracle.com> <4CDDB87F.1050103@oracle.com> <1877449A-9D27-47AC-BB18-E0E8CD8B2A36@oracle.com> Message-ID: <4CE162B9.4090404@oracle.com> Depends on the platform whether it's a win or not. When we did the original sparc64 port, it was faster to materialize 64-bit constants inline than to do a load. This was on U3s. Ditto U4s and U4+s when we tried them. Faster to do multi-issue (3 clocks max) than to tolerate a potential L1 miss. Paul On 11/15/10 8:45 AM, Christian Thalinger wrote: > On Nov 12, 2010, at 10:58 PM, Vladimir Kozlov wrote: >> Most important is why it is not under flag? > > > Hmm, I never thought about putting it under a flag since in theory > materializing the constant table base address only once instead of > every time it's required should always be a win. > > -- Christian From igor.veresov at oracle.com Mon Nov 15 12:14:55 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 15 Nov 2010 12:14:55 -0800 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC In-Reply-To: <4CE162B9.4090404@oracle.com> References: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> <4CDDA15E.6030603@oracle.com> <4CDDB87F.1050103@oracle.com> <1877449A-9D27-47AC-BB18-E0E8CD8B2A36@oracle.com> <4CE162B9.4090404@oracle.com> Message-ID: <4CE194BF.5000907@oracle.com> On 11/15/10 8:41 AM, Paul Hohensee wrote: > Depends on the platform whether it's a win or not. When we did the original > sparc64 port, it was faster to materialize 64-bit constants inline than > to do > a load. This was on U3s. Ditto U4s and U4+s when we tried them. Faster to > do multi-issue (3 clocks max) than to tolerate a potential L1 miss. > Also, consider the edge case: a method that does only one load of a constant. In this case it is a full-blown cache miss with a high probability (the first time for sure). Whereas if a constant is embedded in the instruction stream it never is. It would be interesting to compare cache-miss statistics (as well as the overall performance) for different styles of constant loading on T-series and M-series. igor > Paul > > On 11/15/10 8:45 AM, Christian Thalinger wrote: >> On Nov 12, 2010, at 10:58 PM, Vladimir Kozlov wrote: >>> Most important is why it is not under flag? >> >> >> Hmm, I never thought about putting it under a flag since in theory >> materializing the constant table base address only once instead of >> every time it's required should always be a win. >> >> -- Christian From vladimir.kozlov at oracle.com Mon Nov 15 14:46:45 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Nov 2010 14:46:45 -0800 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC In-Reply-To: <025DDC98-A2FD-458C-B55A-3D31A531D298@oracle.com> References: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> <4CDDA15E.6030603@oracle.com> <025DDC98-A2FD-458C-B55A-3D31A531D298@oracle.com> Message-ID: <4CE1B855.6020603@oracle.com> Christian Thalinger wrote: > On Nov 12, 2010, at 9:19 PM, Vladimir Kozlov wrote: >> Do you need to connect MachConstantBaseNode to root? For RA? And where >> you emit it (call emit()) since you don't add it to any block: >> >> +MachConstantBaseNode* Compile::mach_constant_base_node() { >> + if (_mach_constant_base_node == NULL) { >> + _mach_constant_base_node = new (C) MachConstantBaseNode(); >> + _mach_constant_base_node->set_req(0, C->root()); > > The MachConstantBaseNode is added as an input to all MachConstantNodes > in their Expand method (generated by ADLC) and is emitted when all other > nodes are emitted in Compile::Fill_buffer. I see it now. What confused me is you used this node for two different purposes. One is as Mach node to put into register the base of constant section and second is to collect constants information during code generation (in output.cpp). I think we should separate them. >> >> Why commented?: >> ! //assert(!n->pinned() || n->is_SafePointScalarObject(), "only >> SafePointScalarObject pinned node is expected here"); > > The reason why I pin MachConstantBaseNode is to get small offsets when > RDPC instructions is used. When that assert is uncommented it triggers > because the node is pinned but not a SafePointScalarObject. I think the > right fix would be to also allow pinned MachConstantBaseNodes in that > assert. Agree. > A change we could do (but I haven't tested this yet) is to not pin > MachConstantBaseNodes when UseRDPCForConstanTableBase is false since we > materialize the constant table base address anyway so it doesn't matter > where in the code that happens. Moving the materialization closer to > the use would also decrease register pressure. I agree so, please, fix it. > >> >> You don't use is_MachConstantBase() so you don't need to add it to >> DEFINE_CLASS in node.hpp and call init_class_id(). > > I can remove it if we don't need it for the assert above. Yes, we needed it for that assert and may be for other things in a future. Thanks, Vladimir From igor.veresov at oracle.com Mon Nov 15 20:12:36 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 15 Nov 2010 20:12:36 -0800 Subject: Request for review(S): 7000349: Tiered reacts incorrectly to C1 compilation failures Message-ID: <4CE204B4.8020701@oracle.com> Tiered has the following problems with C1 compile failures: 1. Compile broker marks method as non-compilable at all levels if C1 compilation fails because C1 doesn't fill the failure_reason in ciEnv. 2. If a method cannot be compiled at any of the C1 levels the tiered policy tries to immediately compile it with C2 instead of continuing profiling in the interpreter. 3. If C2 fails to compile the broker will make the method not compilable for C1 also, which is wrong. Also, C1 needs to report the failure reason. Webrev: http://cr.openjdk.java.net/~iveresov/7000349/webrev.00 Thanks, igor From vladimir.kozlov at oracle.com Mon Nov 15 21:35:28 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Nov 2010 21:35:28 -0800 Subject: Request for review(S): 7000349: Tiered reacts incorrectly to C1 compilation failures In-Reply-To: <4CE204B4.8020701@oracle.com> References: <4CE204B4.8020701@oracle.com> Message-ID: <4CE21820.2030603@oracle.com> Looks good. Vladimir On 11/15/10 8:12 PM, Igor Veresov wrote: > Tiered has the following problems with C1 compile failures: > > 1. Compile broker marks method as non-compilable at all levels if C1 compilation fails because C1 doesn't fill the > failure_reason in ciEnv. > 2. If a method cannot be compiled at any of the C1 levels the tiered policy tries to immediately compile it with C2 > instead of continuing profiling in the interpreter. > 3. If C2 fails to compile the broker will make the method not compilable for C1 also, which is wrong. > > Also, C1 needs to report the failure reason. > > Webrev: http://cr.openjdk.java.net/~iveresov/7000349/webrev.00 > > Thanks, > igor From christian.thalinger at oracle.com Tue Nov 16 02:35:28 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 16 Nov 2010 11:35:28 +0100 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC In-Reply-To: <4CE1B855.6020603@oracle.com> References: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> <4CDDA15E.6030603@oracle.com> <025DDC98-A2FD-458C-B55A-3D31A531D298@oracle.com> <4CE1B855.6020603@oracle.com> Message-ID: On Nov 15, 2010, at 11:46 PM, Vladimir Kozlov wrote: > Christian Thalinger wrote: >> On Nov 12, 2010, at 9:19 PM, Vladimir Kozlov wrote: >>> Do you need to connect MachConstantBaseNode to root? For RA? And >>> where you emit it (call emit()) since you don't add it to any block: >>> >>> +MachConstantBaseNode* Compile::mach_constant_base_node() { >>> + if (_mach_constant_base_node == NULL) { >>> + _mach_constant_base_node = new (C) MachConstantBaseNode(); >>> + _mach_constant_base_node->set_req(0, C->root()); >> The MachConstantBaseNode is added as an input to all >> MachConstantNodes in their Expand method (generated by ADLC) and is >> emitted when all other nodes are emitted in Compile::Fill_buffer. > > I see it now. What confused me is you used this node for two different > purposes. One is as Mach node to put into register the base of > constant > section and second is to collect constants information during code > generation (in output.cpp). I think we should separate them. Well, yes, we can separate it. You are right that the name of MachConstantBaseNode does not suggest that it also contains the whole constant table. Would you either want me to (a) link from the MachConstantBaseNode to the new constant table object or (b) have a singleton (like _mach_constant_base_node) and access it via Compile? Where should I put the constant table class? >> A change we could do (but I haven't tested this yet) is to not pin >> MachConstantBaseNodes when UseRDPCForConstanTableBase is false >> since we materialize the constant table base address anyway so it >> doesn't matter where in the code that happens. Moving the >> materialization closer to the use would also decrease register >> pressure. > > I agree so, please, fix it. I'm not sure that works. One problem I hit is that a MachConstantBaseNode is in a basic block that is scheduled later in the block layout than a block that has a MachConstantNode and uses MachConstantBaseNode. So when emitting the MachConstantNode we don't know the code offset of the MachConstantBaseNode yet and we can't emit the correct load offset. I don't see a way to fix this without changing the block layout which definitely is not a good idea. -- Christian From vladimir.kozlov at oracle.com Tue Nov 16 09:35:38 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 16 Nov 2010 09:35:38 -0800 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC In-Reply-To: References: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> <4CDDA15E.6030603@oracle.com> <025DDC98-A2FD-458C-B55A-3D31A531D298@oracle.com> <4CE1B855.6020603@oracle.com> Message-ID: <4CE2C0EA.7090208@oracle.com> On 11/16/10 2:35 AM, Christian Thalinger wrote: > On Nov 15, 2010, at 11:46 PM, Vladimir Kozlov wrote: >> Christian Thalinger wrote: >>> On Nov 12, 2010, at 9:19 PM, Vladimir Kozlov wrote: >>>> Do you need to connect MachConstantBaseNode to root? For RA? And where you emit it (call emit()) since you don't add >>>> it to any block: >>>> >>>> +MachConstantBaseNode* Compile::mach_constant_base_node() { >>>> + if (_mach_constant_base_node == NULL) { >>>> + _mach_constant_base_node = new (C) MachConstantBaseNode(); >>>> + _mach_constant_base_node->set_req(0, C->root()); >>> The MachConstantBaseNode is added as an input to all MachConstantNodes in their Expand method (generated by ADLC) and >>> is emitted when all other nodes are emitted in Compile::Fill_buffer. >> >> I see it now. What confused me is you used this node for two different >> purposes. One is as Mach node to put into register the base of constant >> section and second is to collect constants information during code >> generation (in output.cpp). I think we should separate them. > > Well, yes, we can separate it. You are right that the name of MachConstantBaseNode does not suggest that it also > contains the whole constant table. Would you either want me to (a) link from the MachConstantBaseNode to the new > constant table object or (b) have a singleton (like _mach_constant_base_node) and access it via Compile? Where should I > put the constant table class? I think you should move Constant class and table into Compile class. > >>> A change we could do (but I haven't tested this yet) is to not pin MachConstantBaseNodes when >>> UseRDPCForConstanTableBase is false since we materialize the constant table base address anyway so it doesn't matter >>> where in the code that happens. Moving the materialization closer to the use would also decrease register pressure. >> >> I agree so, please, fix it. > > I'm not sure that works. One problem I hit is that a MachConstantBaseNode is in a basic block that is scheduled later in > the block layout than a block that has a MachConstantNode and uses MachConstantBaseNode. So when emitting the > MachConstantNode we don't know the code offset of the MachConstantBaseNode yet and we can't emit the correct load > offset. I don't see a way to fix this without changing the block layout which definitely is not a good idea. Can you explain more why you need code offset of MCBN? I thought you need only base of constant table in register produced by this node. You collect all constants information (filling constant table) before emitting code so you should know all offsets in the table before emit. Thanks, Vladimir > > -- Christian From igor.veresov at oracle.com Tue Nov 16 15:43:56 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 16 Nov 2010 15:43:56 -0800 Subject: Request for review(S): 7000349: Tiered reacts incorrectly to C1 compilation failures In-Reply-To: <4CE21820.2030603@oracle.com> References: <4CE204B4.8020701@oracle.com> <4CE21820.2030603@oracle.com> Message-ID: <4CE3173C.8040709@oracle.com> Thanks, Vladimir! On 11/15/10 9:35 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > On 11/15/10 8:12 PM, Igor Veresov wrote: >> Tiered has the following problems with C1 compile failures: >> >> 1. Compile broker marks method as non-compilable at all levels if C1 >> compilation fails because C1 doesn't fill the >> failure_reason in ciEnv. >> 2. If a method cannot be compiled at any of the C1 levels the tiered >> policy tries to immediately compile it with C2 >> instead of continuing profiling in the interpreter. >> 3. If C2 fails to compile the broker will make the method not >> compilable for C1 also, which is wrong. >> >> Also, C1 needs to report the failure reason. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/7000349/webrev.00 >> >> Thanks, >> igor From igor.veresov at oracle.com Tue Nov 16 20:21:06 2010 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Wed, 17 Nov 2010 04:21:06 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7000349: Tiered reacts incorrectly to C1 compilation failures Message-ID: <20101117042112.4A00147A5B@hg.openjdk.java.net> Changeset: 22ef3370343b Author: iveresov Date: 2010-11-16 15:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/22ef3370343b 7000349: Tiered reacts incorrectly to C1 compilation failures Summary: Fix policy reaction to C1 comilation failures, make C1 properly report errors. Reviewed-by: kvn ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp From christian.thalinger at oracle.com Wed Nov 17 01:35:53 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 17 Nov 2010 10:35:53 +0100 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC In-Reply-To: <4CE2C0EA.7090208@oracle.com> References: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> <4CDDA15E.6030603@oracle.com> <025DDC98-A2FD-458C-B55A-3D31A531D298@oracle.com> <4CE1B855.6020603@oracle.com> <4CE2C0EA.7090208@oracle.com> Message-ID: On Nov 16, 2010, at 6:35 PM, Vladimir Kozlov wrote: > On 11/16/10 2:35 AM, Christian Thalinger wrote: >> On Nov 15, 2010, at 11:46 PM, Vladimir Kozlov wrote: >>> Christian Thalinger wrote: >>>> On Nov 12, 2010, at 9:19 PM, Vladimir Kozlov wrote: >>>>> Do you need to connect MachConstantBaseNode to root? For RA? And >>>>> where you emit it (call emit()) since you don't add >>>>> it to any block: >>>>> >>>>> +MachConstantBaseNode* Compile::mach_constant_base_node() { >>>>> + if (_mach_constant_base_node == NULL) { >>>>> + _mach_constant_base_node = new (C) MachConstantBaseNode(); >>>>> + _mach_constant_base_node->set_req(0, C->root()); >>>> The MachConstantBaseNode is added as an input to all >>>> MachConstantNodes in their Expand method (generated by ADLC) and >>>> is emitted when all other nodes are emitted in >>>> Compile::Fill_buffer. >>> >>> I see it now. What confused me is you used this node for two >>> different >>> purposes. One is as Mach node to put into register the base of >>> constant >>> section and second is to collect constants information during code >>> generation (in output.cpp). I think we should separate them. >> >> Well, yes, we can separate it. You are right that the name of >> MachConstantBaseNode does not suggest that it also >> contains the whole constant table. Would you either want me to (a) >> link from the MachConstantBaseNode to the new >> constant table object or (b) have a singleton (like >> _mach_constant_base_node) and access it via Compile? Where should I >> put the constant table class? > > I think you should move Constant class and table into Compile class. Will do. > >> >>>> A change we could do (but I haven't tested this yet) is to not >>>> pin MachConstantBaseNodes when >>>> UseRDPCForConstanTableBase is false since we materialize the >>>> constant table base address anyway so it doesn't matter >>>> where in the code that happens. Moving the materialization closer >>>> to the use would also decrease register pressure. >>> >>> I agree so, please, fix it. >> >> I'm not sure that works. One problem I hit is that a >> MachConstantBaseNode is in a basic block that is scheduled later in >> the block layout than a block that has a MachConstantNode and uses >> MachConstantBaseNode. So when emitting the >> MachConstantNode we don't know the code offset of the >> MachConstantBaseNode yet and we can't emit the correct load >> offset. I don't see a way to fix this without changing the block >> layout which definitely is not a good idea. > > Can you explain more why you need code offset of MCBN? I thought you > need only base of constant table in register produced by this node. > You collect all constants information (filling constant table) > before emitting code so you should know all offsets in the table > before emit. My fault. I was thinking that we're using RDPC when the node is not pinned, but that's not the case. Of course it works when not using RDPC. -- Christian From christian.thalinger at oracle.com Wed Nov 17 08:42:44 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 17 Nov 2010 17:42:44 +0100 Subject: Request for reviews (S): 6998985: faulty generic arraycopy on windows x86_64: 4th arg overwritten with oop Message-ID: <07675A9B-DD8F-4004-8F65-DB8946DF1D52@oracle.com> http://cr.openjdk.java.net/~twisti/6998985/webrev.01/ 6998985: faulty generic arraycopy on windows x86_64: 4th arg overwritten with oop Reviewed-by: There is a problem concerning generic arraycopy on windows x86_64. On windows, the stub gets its 4th argument in register r9. The register gets overwritten by an oop. In most cases, the subsequent range check will fail and the copy will be done over the slow path. However, depending on the oops address, the range check might succeed and the copy lead to wrong results. Tested with failing testcase. From vladimir.kozlov at oracle.com Wed Nov 17 09:36:39 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Nov 2010 09:36:39 -0800 Subject: Request for reviews (S): 6998985: faulty generic arraycopy on windows x86_64: 4th arg overwritten with oop In-Reply-To: <07675A9B-DD8F-4004-8F65-DB8946DF1D52@oracle.com> References: <07675A9B-DD8F-4004-8F65-DB8946DF1D52@oracle.com> Message-ID: <4CE412A7.1010802@oracle.com> Looks good. Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6998985/webrev.01/ > > 6998985: faulty generic arraycopy on windows x86_64: 4th arg overwritten > with oop > Reviewed-by: > > There is a problem concerning generic arraycopy on windows x86_64. On > windows, the stub gets its 4th argument in register r9. The register > gets overwritten by an oop. In most cases, the subsequent range check > will fail and the copy will be done over the slow path. However, > depending on the oops address, the range check might succeed and the > copy lead to wrong results. > > Tested with failing testcase. From tom.rodriguez at oracle.com Wed Nov 17 09:54:05 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 17 Nov 2010 09:54:05 -0800 Subject: Request for reviews (S): 6998985: faulty generic arraycopy on windows x86_64: 4th arg overwritten with oop In-Reply-To: <07675A9B-DD8F-4004-8F65-DB8946DF1D52@oracle.com> References: <07675A9B-DD8F-4004-8F65-DB8946DF1D52@oracle.com> Message-ID: Looks good. tom On Nov 17, 2010, at 8:42 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6998985/webrev.01/ > > 6998985: faulty generic arraycopy on windows x86_64: 4th arg overwritten with oop > Reviewed-by: > > There is a problem concerning generic arraycopy on windows x86_64. On > windows, the stub gets its 4th argument in register r9. The register > gets overwritten by an oop. In most cases, the subsequent range check > will fail and the copy will be done over the slow path. However, > depending on the oops address, the range check might succeed and the > copy lead to wrong results. > > Tested with failing testcase. From vladimir.kozlov at oracle.com Wed Nov 17 18:28:25 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Nov 2010 18:28:25 -0800 Subject: Request for reviews (S): 7000491: assert(false) failed: should be optimized out in SharedRuntime::g1_wb_pre Message-ID: <4CE48F49.6010703@oracle.com> http://cr.openjdk.java.net/~kvn/7000491/webrev Fixed 7000491: assert(false) failed: should be optimized out in SharedRuntime::g1_wb_pre Wrong value type is used for NULL store when clearing the detail message of the preallocated exception object for inlined throw. The passed value type was the exception object oop which is constant and as result the load of original value in g1 pre barrier code was replaced with this constant oop. As result the check of original value for NULL was incorrectly eliminated. Use String type as value type for the detail message zeroing. Verified with generated code for spec.jbb.validity.PepTest::testDiv From tom.rodriguez at oracle.com Wed Nov 17 21:52:21 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 17 Nov 2010 21:52:21 -0800 Subject: Request for reviews (S): 7000491: assert(false) failed: should be optimized out in SharedRuntime::g1_wb_pre In-Reply-To: <4CE48F49.6010703@oracle.com> References: <4CE48F49.6010703@oracle.com> Message-ID: <967A12CA-7F19-4398-950B-7F35C42CBDDE@oracle.com> Looks good. tom On Nov 17, 2010, at 6:28 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7000491/webrev > > Fixed 7000491: assert(false) failed: should be optimized out in SharedRuntime::g1_wb_pre > > Wrong value type is used for NULL store when clearing > the detail message of the preallocated exception object > for inlined throw. > The passed value type was the exception object oop which > is constant and as result the load of original value in > g1 pre barrier code was replaced with this constant oop. > As result the check of original value for NULL was > incorrectly eliminated. > > Use String type as value type for the detail message zeroing. > Verified with generated code for spec.jbb.validity.PepTest::testDiv From igor.veresov at oracle.com Wed Nov 17 22:56:37 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 17 Nov 2010 22:56:37 -0800 Subject: Request for reviews (S): 7000491: assert(false) failed: should be optimized out in SharedRuntime::g1_wb_pre In-Reply-To: <4CE48F49.6010703@oracle.com> References: <4CE48F49.6010703@oracle.com> Message-ID: <4CE4CE25.8070101@oracle.com> Looks good. igor On 11/17/10 6:28 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7000491/webrev > > Fixed 7000491: assert(false) failed: should be optimized out in > SharedRuntime::g1_wb_pre > > Wrong value type is used for NULL store when clearing > the detail message of the preallocated exception object > for inlined throw. > The passed value type was the exception object oop which > is constant and as result the load of original value in > g1 pre barrier code was replaced with this constant oop. > As result the check of original value for NULL was > incorrectly eliminated. > > Use String type as value type for the detail message zeroing. > Verified with generated code for spec.jbb.validity.PepTest::testDiv From christian.thalinger at oracle.com Thu Nov 18 08:12:20 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 18 Nov 2010 17:12:20 +0100 Subject: Request for reviews (S): 6998985: faulty generic arraycopy on windows x86_64: 4th arg overwritten with oop In-Reply-To: References: <07675A9B-DD8F-4004-8F65-DB8946DF1D52@oracle.com> Message-ID: <199124BD-E97A-4731-83E4-B0084442563E@oracle.com> JPRT found a bug. I have to look what goes wrong. -- Christian On Nov 17, 2010, at 6:54 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Nov 17, 2010, at 8:42 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/6998985/webrev.01/ >> >> 6998985: faulty generic arraycopy on windows x86_64: 4th arg >> overwritten with oop >> Reviewed-by: >> >> There is a problem concerning generic arraycopy on windows x86_64. >> On >> windows, the stub gets its 4th argument in register r9. The register >> gets overwritten by an oop. In most cases, the subsequent range >> check >> will fail and the copy will be done over the slow path. However, >> depending on the oops address, the range check might succeed and the >> copy lead to wrong results. >> >> Tested with failing testcase. > From christian.thalinger at oracle.com Thu Nov 18 08:25:30 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 18 Nov 2010 17:25:30 +0100 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC In-Reply-To: References: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> <4CDDA15E.6030603@oracle.com> <025DDC98-A2FD-458C-B55A-3D31A531D298@oracle.com> <4CE1B855.6020603@oracle.com> <4CE2C0EA.7090208@oracle.com> Message-ID: <5A90B778-D3D3-4494-BE64-6E29FF0D4F7A@oracle.com> On Nov 17, 2010, at 10:35 AM, Christian Thalinger wrote: > My fault. I was thinking that we're using RDPC when the node is not > pinned, but that's not the case. Of course it works when not using > RDPC. This became a bigger change that I thought it will be. I moved almost all logic into Compile, the constant table emission and the offset/ size calculation are now two different steps which are called explicitly in Compile::Fill_buffer, and the constant table base materialization is not pinned. http://cr.openjdk.java.net/~twisti/6961690/webrev.02/ -- Christian From vladimir.kozlov at oracle.com Thu Nov 18 09:14:37 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 18 Nov 2010 09:14:37 -0800 Subject: Request for reviews (S): 7000491: assert(false) failed: should be optimized out in SharedRuntime::g1_wb_pre In-Reply-To: <4CE4CE25.8070101@oracle.com> References: <4CE48F49.6010703@oracle.com> <4CE4CE25.8070101@oracle.com> Message-ID: <4CE55EFD.80901@oracle.com> Thank you, Tom and Igor Vladimir On 11/17/10 10:56 PM, Igor Veresov wrote: > Looks good. > > igor > > On 11/17/10 6:28 PM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/7000491/webrev >> >> Fixed 7000491: assert(false) failed: should be optimized out in >> SharedRuntime::g1_wb_pre >> >> Wrong value type is used for NULL store when clearing >> the detail message of the preallocated exception object >> for inlined throw. >> The passed value type was the exception object oop which >> is constant and as result the load of original value in >> g1 pre barrier code was replaced with this constant oop. >> As result the check of original value for NULL was >> incorrectly eliminated. >> >> Use String type as value type for the detail message zeroing. >> Verified with generated code for spec.jbb.validity.PepTest::testDiv > From vladimir.kozlov at oracle.com Thu Nov 18 11:30:09 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 18 Nov 2010 11:30:09 -0800 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC In-Reply-To: <5A90B778-D3D3-4494-BE64-6E29FF0D4F7A@oracle.com> References: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> <4CDDA15E.6030603@oracle.com> <025DDC98-A2FD-458C-B55A-3D31A531D298@oracle.com> <4CE1B855.6020603@oracle.com> <4CE2C0EA.7090208@oracle.com> <5A90B778-D3D3-4494-BE64-6E29FF0D4F7A@oracle.com> Message-ID: <4CE57EC1.30404@oracle.com> Christian, I like this code better but I still think that we should have a flag which controls how we load constant oops and longs. We may do it by just adding predicate(flag) into .ad file. Could you, please, check? And yes, we may need to keep some code you removed. Instead of using new flag ConstantTableAbsoluteAddressing (we have more flags than we need already) you should use Matcher's variable like next: const bool Matcher::clone_shift_expressions = true; I don't understand how MachConstantBaseNode::size() is not called on sparc where there is code generated for it? You need the size. It seems, you have to calculate it manually. I think you don't need to add_req() in constructor and then use set_req(root) since new MachConstantBase node is only created in Compile::mach_constant_base_node() so you can add_req(root) there Thanks, Vladimir Christian Thalinger wrote: > On Nov 17, 2010, at 10:35 AM, Christian Thalinger wrote: >> My fault. I was thinking that we're using RDPC when the node is not >> pinned, but that's not the case. Of course it works when not using RDPC. > > This became a bigger change that I thought it will be. I moved almost > all logic into Compile, the constant table emission and the offset/size > calculation are now two different steps which are called explicitly in > Compile::Fill_buffer, and the constant table base materialization is not > pinned. > > http://cr.openjdk.java.net/~twisti/6961690/webrev.02/ > > -- Christian From vladimir.kozlov at oracle.com Thu Nov 18 12:34:48 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 18 Nov 2010 20:34:48 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7000491: assert(false) failed: should be optimized out in SharedRuntime::g1_wb_pre Message-ID: <20101118203456.3A37C47ACA@hg.openjdk.java.net> Changeset: f264f4c42799 Author: kvn Date: 2010-11-18 09:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f264f4c42799 7000491: assert(false) failed: should be optimized out in SharedRuntime::g1_wb_pre Summary: Wrong value type is used for NULL store when clearing the detail message of the preallocated exception object. Reviewed-by: never, iveresov ! src/share/vm/opto/graphKit.cpp From paul.hohensee at oracle.com Thu Nov 18 14:29:50 2010 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 18 Nov 2010 17:29:50 -0500 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC In-Reply-To: <4CE57EC1.30404@oracle.com> References: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> <4CDDA15E.6030603@oracle.com> <025DDC98-A2FD-458C-B55A-3D31A531D298@oracle.com> <4CE1B855.6020603@oracle.com> <4CE2C0EA.7090208@oracle.com> <5A90B778-D3D3-4494-BE64-6E29FF0D4F7A@oracle.com> <4CE57EC1.30404@oracle.com> Message-ID: <4CE5A8DE.3000400@oracle.com> It should be a check on a VM_Version method such as is_niagara. I expect this to be a performance loss on non-T-series sparc. Paul On 11/18/10 2:30 PM, Vladimir Kozlov wrote: > Christian, > > I like this code better but I still think that we should have a flag > which controls how we load constant oops and longs. > We may do it by just adding predicate(flag) into .ad file. Could you, > please, check? And yes, we may need to keep some code you removed. > > Instead of using new flag ConstantTableAbsoluteAddressing (we have more > flags than we need already) you should use Matcher's variable like next: > > const bool Matcher::clone_shift_expressions = true; > > I don't understand how MachConstantBaseNode::size() is not called > on sparc where there is code generated for it? You need the size. > It seems, you have to calculate it manually. > > I think you don't need to add_req() in constructor and then use > set_req(root) since new MachConstantBase node is only created in > Compile::mach_constant_base_node() so you can add_req(root) there > > Thanks, > Vladimir > > Christian Thalinger wrote: >> On Nov 17, 2010, at 10:35 AM, Christian Thalinger wrote: >>> My fault. I was thinking that we're using RDPC when the node is not >>> pinned, but that's not the case. Of course it works when not using >>> RDPC. >> >> This became a bigger change that I thought it will be. I moved >> almost all logic into Compile, the constant table emission and the >> offset/size calculation are now two different steps which are called >> explicitly in Compile::Fill_buffer, and the constant table base >> materialization is not pinned. >> >> http://cr.openjdk.java.net/~twisti/6961690/webrev.02/ >> >> -- Christian From john.r.rose at oracle.com Thu Nov 18 15:29:49 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 18 Nov 2010 15:29:49 -0800 Subject: review request (M): 6979327: method handle invocation should use casts instead of type parameters to specify return type Message-ID: Javac changes have now propagated for changing this method handle syntax: mh.invokeExact() to be replaced by this: (T) mh.invokeExact() The present reviewe is the "other shoe" dropping for these javac changes, to make the corresponding changes in the JDK code. All the places which used the old syntax have been replaced by the new. http://cr.openjdk.java.net/~jrose/6979327/webrev.jdk.01/ Also in this change set, the class InvokeDynamic has been restored because of linkages to the JVM. (The previous change, for 6981777, removed it prematurely.) The restored class is not part of the 292 API, just the implementation. We'll want to remove the linkages from the JVM. -- John From igor.veresov at oracle.com Thu Nov 18 19:12:23 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 18 Nov 2010 19:12:23 -0800 Subject: Request for review(XL): 6985015: C1 needs to support compressed oops Message-ID: <4CE5EB17.3090503@oracle.com> This change implements compressed oops for C1 for x64 and sparc. The changes are mostly on the codegen level, with a few exceptions when we do access things outside of the heap that are uncompressed from the IR. Webrev: http://cr.openjdk.java.net/~iveresov/6985015/webrev.00/ Thanks, igor From christian.thalinger at oracle.com Fri Nov 19 01:47:07 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 19 Nov 2010 10:47:07 +0100 Subject: review request (M): 6979327: method handle invocation should use casts instead of type parameters to specify return type In-Reply-To: References: Message-ID: <0B777385-490A-4C3A-92EA-BA3A466B9B62@oracle.com> On Nov 19, 2010, at 12:29 AM, John Rose wrote: > Javac changes have now propagated for changing this method handle > syntax: > mh.invokeExact() > to be replaced by this: > (T) mh.invokeExact() > > The present reviewe is the "other shoe" dropping for these javac > changes, to make the corresponding changes in the JDK code. All the > places which used the old syntax have been replaced by the new. > > http://cr.openjdk.java.net/~jrose/6979327/webrev.jdk.01/ > > Also in this change set, the class InvokeDynamic has been restored > because of linkages to the JVM. (The previous change, for 6981777, > removed it prematurely.) The restored class is not part of the 292 > API, just the implementation. We'll want to remove the linkages > from the JVM. There's something wrong with the webrev. I get 404s for all files except the first. -- Christian From christian.thalinger at oracle.com Fri Nov 19 02:51:22 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 19 Nov 2010 11:51:22 +0100 Subject: Request for review(XL): 6985015: C1 needs to support compressed oops In-Reply-To: <4CE5EB17.3090503@oracle.com> References: <4CE5EB17.3090503@oracle.com> Message-ID: <063C8F18-F974-4A8C-8669-3D879749DCBE@oracle.com> On Nov 19, 2010, at 4:12 AM, Igor Veresov wrote: > This change implements compressed oops for C1 for x64 and sparc. > The changes are mostly on the codegen level, with a few exceptions > when we do access things outside of the heap that are uncompressed > from the IR. > > Webrev: http://cr.openjdk.java.net/~iveresov/6985015/webrev.00/ src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp: 764 #ifdef _LP64 765 if (UseCompressedOops) { 766 __ lduw(O0, oopDesc::klass_offset_in_bytes(), G3_scratch); 767 __ decode_heap_oop(G3_scratch); 768 } else 769 #endif 770 __ ld_ptr(O0, oopDesc::klass_offset_in_bytes(), G3_scratch); Why not using load_heap_oop here? I wonder why there is no load_klass_null that does all that (or actually the current load_klass should be called load_klass_not_null, but that's a too big change). 949 __ decode_heap_oop(to_reg->as_register(), to_reg- >as_register()); 993 __ decode_heap_oop(to_reg->as_register(), to_reg- >as_register()); Pass the register only once, it's a little shorter. Maybe you should add a local method doing: 946 #ifdef _LP64 947 if (UseCompressedOops && !wide) { 948 __ lduw(base, offset, to_reg->as_register()); 949 __ decode_heap_oop(to_reg->as_register(), to_reg- >as_register()); 950 } else 951 #endif 952 __ ld_ptr(base, offset, to_reg->as_register()); and reuse it. 1240 // load(O7, 0, to_reg, T_INT, false /*wide*/, false / *unaligned*/); Why is it commented? src/cpu/x86/vm/c1_LIRAssembler_x86.cpp: 550 __ load_heap_oop(rsi, Address(rax, java_lang_String::value_offset_in_bytes())); 551 __ movptr (rcx, Address(rax, java_lang_String::offset_offset_in_bytes())); 552 __ lea (rsi, Address(rsi, rcx, Address::times_2, arrayOopDesc::base_offset_in_bytes(T_CHAR))); 557 __ load_heap_oop(rdi, Address(rbx, java_lang_String::value_offset_in_bytes())); 558 __ movptr (rcx, Address(rbx, java_lang_String::offset_offset_in_bytes())); 559 __ lea (rdi, Address(rdi, rcx, Address::times_2, arrayOopDesc::base_offset_in_bytes(T_CHAR))); Please keep the indent. 779 case T_ADDRESS: 780 __ movptr(frame_map()->address_for_slot(dest- >single_stack_ix()), c->as_jint_bits()); 781 break; Indent. src/cpu/x86/vm/c1_LIRGenerator_x86.cpp: 1143 if (!x->klass()->is_loaded() || LP64_ONLY(UseCompressedOops) NOT_LP64(false)) { 1165 if (!x->klass()->is_loaded() || LP64_ONLY(UseCompressedOops) NOT_LP64(false)) { I think the common pattern is LP64_ONLY(|| UseCompressedOops). src/share/vm/c1/c1_LIRAssembler.hpp: void mem2reg (LIR_Opr src, LIR_Opr dest, BasicType type, - LIR_PatchCode patch_code = lir_patch_none, - CodeEmitInfo* info = NULL, bool unaligned = false); + LIR_PatchCode patch_code, + CodeEmitInfo* info, bool unaligned, bool wide); Why did you remove the default values? Because wide is always passed in? Otherwise looks good. -- Christian From christian.thalinger at oracle.com Fri Nov 19 05:11:03 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 19 Nov 2010 14:11:03 +0100 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC In-Reply-To: <4CE5A8DE.3000400@oracle.com> References: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> <4CDDA15E.6030603@oracle.com> <025DDC98-A2FD-458C-B55A-3D31A531D298@oracle.com> <4CE1B855.6020603@oracle.com> <4CE2C0EA.7090208@oracle.com> <5A90B778-D3D3-4494-BE64-6E29FF0D4F7A@oracle.com> <4CE57EC1.30404@oracle.com> <4CE5A8DE.3000400@oracle.com> Message-ID: <8D74DE3C-3473-4782-AD16-CDCE3C018C46@oracle.com> On Nov 18, 2010, at 11:29 PM, Paul Hohensee wrote: > It should be a check on a VM_Version method such as is_niagara. I > expect > this to be a performance loss on non-T-series sparc. Yes, I will do that. -- Christian From john.r.rose at oracle.com Fri Nov 19 10:20:43 2010 From: john.r.rose at oracle.com (John Rose) Date: Fri, 19 Nov 2010 10:20:43 -0800 Subject: review request (M): 6979327: method handle invocation should use casts instead of type parameters to specify return type In-Reply-To: <0B777385-490A-4C3A-92EA-BA3A466B9B62@oracle.com> References: <0B777385-490A-4C3A-92EA-BA3A466B9B62@oracle.com> Message-ID: <1C6C258E-82AD-40D8-A5EB-885D43386C8E@oracle.com> It's re-published. -- John On Nov 19, 2010, at 1:47 AM, Christian Thalinger wrote: > There's something wrong with the webrev. I get 404s for all files except the first. From vladimir.kozlov at oracle.com Fri Nov 19 12:19:27 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 19 Nov 2010 12:19:27 -0800 Subject: Request for review(XL): 6985015: C1 needs to support compressed oops In-Reply-To: <4CE5EB17.3090503@oracle.com> References: <4CE5EB17.3090503@oracle.com> Message-ID: <4CE6DBCF.2030607@oracle.com> Typo in assembler_sparc.cpp, should be srl(). I have the same comment as Christian's about using separate lduw/stw and decode/encode, they should be combined if you can't use existing functions. Looks good otherwise. Thanks, Vladimir Igor Veresov wrote: > This change implements compressed oops for C1 for x64 and sparc. > The changes are mostly on the codegen level, with a few exceptions when > we do access things outside of the heap that are uncompressed from the IR. > > Webrev: http://cr.openjdk.java.net/~iveresov/6985015/webrev.00/ > > Thanks, > igor From tom.rodriguez at oracle.com Fri Nov 19 13:18:44 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 19 Nov 2010 13:18:44 -0800 Subject: Request for review(XL): 6985015: C1 needs to support compressed oops In-Reply-To: <4CE5EB17.3090503@oracle.com> References: <4CE5EB17.3090503@oracle.com> Message-ID: <485C2B0E-2982-440E-B12F-3B45AA54A7E9@oracle.com> The cpu_reg_range_reduction stuff is pretty gross. Can we just make nof_caller_save_cpu_regs a method on FrameMap. The existing enum would become _max_nof_caller_save_cpu_regs so it could continue to be a constant for declarations. assembler_sparc.cpp: what is slr and why would you use it instead of sllx? c1_LIRAssembler_sparc.cpp: use load_klass instead. In general if you can use load_heap_oop and store_heap_oop instead that would be preferable. It's possible you'll need to add an alternate temp argument to them since they always assume it's ok to kill the oop value. in const2mem, init offset to -1 and assert that it's been set at before using it. sometimes the argument ordering is wide then unaligned and other times it's reversed which seems like asking for trouble. Why is it like this? I guess the arraycopy guards were fairly broken on 64 bit since they were still using br instead of brx in a few places. Oops. You're loading the klasses as 32 bit but comparing them using the 64 bit condition code which I know will work in this case but it's a bad practice. loads always produce safe values but it's not clear that our constant construction code does. Maybe we need a br variant that allows specifying the condition codes? bp lets you but that's v9 only. + #ifdef _LP64 + if (UseCompressedOops) { + __ encode_heap_oop(tmp, tmp); + __ lduw(dst, oopDesc::klass_offset_in_bytes(), tmp2); + } else + #endif __ ld_ptr(dst, oopDesc::klass_offset_in_bytes(), tmp2); Could you put some comments on this? I know this code is assert only but is there a need for a jobject2reg that produces the encoded oop directly? The relocs support it. Doing the type checks by producing wide oops will be much more expensive. c1_LIRAssembler_x86.cpp: what happening with the alignment? Why isn't it aligned from compressed oops? Other it looks fine. tom On Nov 18, 2010, at 7:12 PM, Igor Veresov wrote: > This change implements compressed oops for C1 for x64 and sparc. > The changes are mostly on the codegen level, with a few exceptions when we do access things outside of the heap that are uncompressed from the IR. > > Webrev: http://cr.openjdk.java.net/~iveresov/6985015/webrev.00/ > > Thanks, > igor From igor.veresov at oracle.com Fri Nov 19 14:26:02 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 19 Nov 2010 14:26:02 -0800 Subject: Request for review(XL): 6985015: C1 needs to support compressed oops In-Reply-To: <063C8F18-F974-4A8C-8669-3D879749DCBE@oracle.com> References: <4CE5EB17.3090503@oracle.com> <063C8F18-F974-4A8C-8669-3D879749DCBE@oracle.com> Message-ID: <4CE6F97A.4080500@oracle.com> Christian, thanks for the review! Please find the responses inline. On 11/19/10 2:51 AM, Christian Thalinger wrote: > On Nov 19, 2010, at 4:12 AM, Igor Veresov wrote: >> This change implements compressed oops for C1 for x64 and sparc. >> The changes are mostly on the codegen level, with a few exceptions >> when we do access things outside of the heap that are uncompressed >> from the IR. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6985015/webrev.00/ > > src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp: > > 764 #ifdef _LP64 > 765 if (UseCompressedOops) { > 766 __ lduw(O0, oopDesc::klass_offset_in_bytes(), G3_scratch); > 767 __ decode_heap_oop(G3_scratch); > 768 } else > 769 #endif > 770 __ ld_ptr(O0, oopDesc::klass_offset_in_bytes(), G3_scratch); > Why not using load_heap_oop here? I wonder why there is no > load_klass_null that does all that (or actually the current load_klass > should be called load_klass_not_null, but that's a too big change). Yeah, I know. SS12u1 had problems in this place and it was either I hand-inline load_klass() or lower the optimization level. I'll put a comment there. > > 949 __ decode_heap_oop(to_reg->as_register(), to_reg->as_register()); > 993 __ decode_heap_oop(to_reg->as_register(), to_reg->as_register()); > Pass the register only once, it's a little shorter. > Yes, thanks. > Maybe you should add a local method doing: > > 946 #ifdef _LP64 > 947 if (UseCompressedOops && !wide) { > 948 __ lduw(base, offset, to_reg->as_register()); > 949 __ decode_heap_oop(to_reg->as_register(), to_reg->as_register()); > 950 } else > 951 #endif > 952 __ ld_ptr(base, offset, to_reg->as_register()); > and reuse it. > I will be two different methods anyway, since one will have to accept the offset as a register, and the other as an int. If you think such a factoring will increase readability, then, sure I'll make these constructs as functions. > 1240 // load(O7, 0, to_reg, T_INT, false /*wide*/, false /*unaligned*/); > Why is it commented? > Forgot to remove it, thanks! > src/cpu/x86/vm/c1_LIRAssembler_x86.cpp: > > 550 __ load_heap_oop(rsi, Address(rax, > java_lang_String::value_offset_in_bytes())); > 551 __ movptr (rcx, Address(rax, > java_lang_String::offset_offset_in_bytes())); > 552 __ lea (rsi, Address(rsi, rcx, Address::times_2, > arrayOopDesc::base_offset_in_bytes(T_CHAR))); > 557 __ load_heap_oop(rdi, Address(rbx, > java_lang_String::value_offset_in_bytes())); > 558 __ movptr (rcx, Address(rbx, > java_lang_String::offset_offset_in_bytes())); > 559 __ lea (rdi, Address(rdi, rcx, Address::times_2, > arrayOopDesc::base_offset_in_bytes(T_CHAR))); > Please keep the indent. > Done. > 779 case T_ADDRESS: > 780 __ movptr(frame_map()->address_for_slot(dest->single_stack_ix()), > c->as_jint_bits()); > 781 break; > Indent. > Done. > src/cpu/x86/vm/c1_LIRGenerator_x86.cpp: > > 1143 if (!x->klass()->is_loaded() || LP64_ONLY(UseCompressedOops) > NOT_LP64(false)) { > 1165 if (!x->klass()->is_loaded() || LP64_ONLY(UseCompressedOops) > NOT_LP64(false)) { > I think the common pattern is LP64_ONLY(|| UseCompressedOops). It is, but do you think it would be more readable to factor this predicate to separate function. It just determines if we need an extra temporary. I'd rather leave it as is. > > src/share/vm/c1/c1_LIRAssembler.hpp: > > void mem2reg (LIR_Opr src, LIR_Opr dest, BasicType type, > - LIR_PatchCode patch_code = lir_patch_none, > - CodeEmitInfo* info = NULL, bool unaligned = false); > + LIR_PatchCode patch_code, > + CodeEmitInfo* info, bool unaligned, bool wide); > Why did you remove the default values? Because wide is always passed in? It is used only in a very few places, so I don't think saving on extra typing is that beneficial. The arguments where also specified every time, so their defaultness was never exploited. In general I prefer to avoid default arguments as much as possible. > > Otherwise looks good. > > -- Christian Thanks! igor From igor.veresov at oracle.com Fri Nov 19 14:32:18 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 19 Nov 2010 14:32:18 -0800 Subject: Request for review(XL): 6985015: C1 needs to support compressed oops In-Reply-To: <4CE6DBCF.2030607@oracle.com> References: <4CE5EB17.3090503@oracle.com> <4CE6DBCF.2030607@oracle.com> Message-ID: <4CE6FAF2.5030607@oracle.com> Vladimir, thanks for the review! On 11/19/10 12:19 PM, Vladimir Kozlov wrote: > Typo in assembler_sparc.cpp, should be srl(). Oh, right! Last minute change. :( Thanks! > > I have the same comment as Christian's about using separate lduw/stw and > decode/encode, they should be combined if you can't use existing functions. > Yes, like Tom noted in some places this can be avoided by introducing store_heap_oop() with an extra temporary so as not to kill the dst oop register. I'll think about how these think can be done in a better way and put out the updated webrev. Thanks! igor > Looks good otherwise. > > Thanks, > Vladimir > > Igor Veresov wrote: >> This change implements compressed oops for C1 for x64 and sparc. >> The changes are mostly on the codegen level, with a few exceptions >> when we do access things outside of the heap that are uncompressed >> from the IR. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6985015/webrev.00/ >> >> Thanks, >> igor From igor.veresov at oracle.com Fri Nov 19 16:22:37 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 19 Nov 2010 16:22:37 -0800 Subject: Request for review(XL): 6985015: C1 needs to support compressed oops In-Reply-To: <4CE6F97A.4080500@oracle.com> References: <4CE5EB17.3090503@oracle.com> <063C8F18-F974-4A8C-8669-3D879749DCBE@oracle.com> <4CE6F97A.4080500@oracle.com> Message-ID: <4CE714CD.3050806@oracle.com> On 11/19/10 2:26 PM, Igor Veresov wrote: > >> src/cpu/x86/vm/c1_LIRGenerator_x86.cpp: >> >> 1143 if (!x->klass()->is_loaded() || LP64_ONLY(UseCompressedOops) >> NOT_LP64(false)) { >> 1165 if (!x->klass()->is_loaded() || LP64_ONLY(UseCompressedOops) >> NOT_LP64(false)) { >> I think the common pattern is LP64_ONLY(|| UseCompressedOops). > > It is, but do you think it would be more readable to factor this > predicate to separate function. It just determines if we need an extra > temporary. I'd rather leave it as is. > Sorry, I didn't get what you meant at first. Ramki explained it to me. Thanks, I'll fix that. igor From John.Coomes at oracle.com Fri Nov 19 16:37:08 2010 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 19 Nov 2010 16:37:08 -0800 Subject: Request for review(XL): 6985015: C1 needs to support compressed oops In-Reply-To: <4CE714CD.3050806@oracle.com> References: <4CE5EB17.3090503@oracle.com> <063C8F18-F974-4A8C-8669-3D879749DCBE@oracle.com> <4CE6F97A.4080500@oracle.com> <4CE714CD.3050806@oracle.com> Message-ID: <19687.6196.168043.121843@oracle.com> Igor Veresov (igor.veresov at oracle.com) wrote: > On 11/19/10 2:26 PM, Igor Veresov wrote: > > > > >> src/cpu/x86/vm/c1_LIRGenerator_x86.cpp: > >> > >> 1143 if (!x->klass()->is_loaded() || LP64_ONLY(UseCompressedOops) > >> NOT_LP64(false)) { > >> 1165 if (!x->klass()->is_loaded() || LP64_ONLY(UseCompressedOops) > >> NOT_LP64(false)) { > >> I think the common pattern is LP64_ONLY(|| UseCompressedOops). > > > > It is, but do you think it would be more readable to factor this > > predicate to separate function. It just determines if we need an extra > > temporary. I'd rather leave it as is. > > > > Sorry, I didn't get what you meant at first. Ramki explained it to me. > Thanks, I'll fix that. BTW, why do you need/want to guard UseCompressedOops with LP64_ONLY()? UseCompressedOops is constant false in 32-bit. -John From igor.veresov at oracle.com Fri Nov 19 17:32:23 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 19 Nov 2010 17:32:23 -0800 Subject: Request for review(XL): 6985015: C1 needs to support compressed oops In-Reply-To: <19687.6196.168043.121843@oracle.com> References: <4CE5EB17.3090503@oracle.com> <063C8F18-F974-4A8C-8669-3D879749DCBE@oracle.com> <4CE6F97A.4080500@oracle.com> <4CE714CD.3050806@oracle.com> <19687.6196.168043.121843@oracle.com> Message-ID: <4CE72527.8090500@oracle.com> On 11/19/10 4:37 PM, John Coomes wrote: > Igor Veresov (igor.veresov at oracle.com) wrote: >> On 11/19/10 2:26 PM, Igor Veresov wrote: >> >>> >>>> src/cpu/x86/vm/c1_LIRGenerator_x86.cpp: >>>> >>>> 1143 if (!x->klass()->is_loaded() || LP64_ONLY(UseCompressedOops) >>>> NOT_LP64(false)) { >>>> 1165 if (!x->klass()->is_loaded() || LP64_ONLY(UseCompressedOops) >>>> NOT_LP64(false)) { >>>> I think the common pattern is LP64_ONLY(|| UseCompressedOops). >>> >>> It is, but do you think it would be more readable to factor this >>> predicate to separate function. It just determines if we need an extra >>> temporary. I'd rather leave it as is. >>> >> >> Sorry, I didn't get what you meant at first. Ramki explained it to me. >> Thanks, I'll fix that. > > BTW, why do you need/want to guard UseCompressedOops with LP64_ONLY()? > UseCompressedOops is constant false in 32-bit. > Hm, good question. It's actually a common pattern with compressed oops. The only reason I can see is to make the jvmg version a bit faster. But I would like not to do the global ifdef removal with this change, it's already big enough. igor From John.Coomes at oracle.com Fri Nov 19 18:12:58 2010 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 19 Nov 2010 18:12:58 -0800 Subject: Request for review(XL): 6985015: C1 needs to support compressed oops In-Reply-To: <4CE72527.8090500@oracle.com> References: <4CE5EB17.3090503@oracle.com> <063C8F18-F974-4A8C-8669-3D879749DCBE@oracle.com> <4CE6F97A.4080500@oracle.com> <4CE714CD.3050806@oracle.com> <19687.6196.168043.121843@oracle.com> <4CE72527.8090500@oracle.com> Message-ID: <19687.11946.275150.150715@oracle.com> Igor Veresov (igor.veresov at oracle.com) wrote: > On 11/19/10 4:37 PM, John Coomes wrote: > > Igor Veresov (igor.veresov at oracle.com) wrote: > >> On 11/19/10 2:26 PM, Igor Veresov wrote: > >> > >>> > >>>> src/cpu/x86/vm/c1_LIRGenerator_x86.cpp: > >>>> > >>>> 1143 if (!x->klass()->is_loaded() || LP64_ONLY(UseCompressedOops) > >>>> NOT_LP64(false)) { > >>>> 1165 if (!x->klass()->is_loaded() || LP64_ONLY(UseCompressedOops) > >>>> NOT_LP64(false)) { > >>>> I think the common pattern is LP64_ONLY(|| UseCompressedOops). > >>> > >>> It is, but do you think it would be more readable to factor this > >>> predicate to separate function. It just determines if we need an extra > >>> temporary. I'd rather leave it as is. > >>> > >> > >> Sorry, I didn't get what you meant at first. Ramki explained it to me. > >> Thanks, I'll fix that. > > > > BTW, why do you need/want to guard UseCompressedOops with LP64_ONLY()? > > UseCompressedOops is constant false in 32-bit. > > > > Hm, good question. It's actually a common pattern with compressed oops. > The only reason I can see is to make the jvmg version a bit faster. But > I would like not to do the global ifdef removal with this change, it's > already big enough. I wasn't suggesting you include it in your changes; it it's going to be done it should be done separately. I'm more interested in finding out why the pattern is used at all. -John From igor.veresov at oracle.com Fri Nov 19 21:52:30 2010 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Sat, 20 Nov 2010 05:52:30 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 23 new changesets Message-ID: <20101120055314.2F36647B32@hg.openjdk.java.net> Changeset: 62aa74bafa73 Author: cl Date: 2010-11-04 15:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/62aa74bafa73 Added tag jdk7-b117 for changeset 806d0c037e6b ! .hgtags Changeset: 698b7b727e12 Author: trims Date: 2010-11-10 20:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/698b7b727e12 Merge ! .hgtags - src/os/linux/vm/objectMonitor_linux.cpp - src/os/linux/vm/objectMonitor_linux.hpp - src/os/linux/vm/objectMonitor_linux.inline.hpp - src/os/solaris/vm/objectMonitor_solaris.cpp - src/os/solaris/vm/objectMonitor_solaris.hpp - src/os/solaris/vm/objectMonitor_solaris.inline.hpp - src/os/windows/vm/objectMonitor_windows.cpp - src/os/windows/vm/objectMonitor_windows.hpp - src/os/windows/vm/objectMonitor_windows.inline.hpp Changeset: 086898a88056 Author: ptisnovs Date: 2010-11-04 14:03 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/086898a88056 6997495: correction of regression test compiler/6857159/Test6857159 Summary: Testcase correction. Reviewed-by: never ! test/compiler/6857159/Test6857159.java Changeset: 26cd5261f8c6 Author: lana Date: 2010-11-04 15:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/26cd5261f8c6 Merge Changeset: 31aff7f873c6 Author: trims Date: 2010-11-10 21:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/31aff7f873c6 Merge Changeset: 84d114b9170e Author: iveresov Date: 2010-11-11 17:36 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/84d114b9170e Merge Changeset: 3ef7426b4dea Author: cl Date: 2010-11-11 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3ef7426b4dea Added tag jdk7-b118 for changeset 698b7b727e12 ! .hgtags Changeset: d4681dc64964 Author: trims Date: 2010-11-11 23:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d4681dc64964 Added tag hs20-b02 for changeset 3ef7426b4dea ! .hgtags Changeset: a1e319b5b13a Author: trims Date: 2010-11-11 23:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a1e319b5b13a Merge Changeset: 5484e7c53fa7 Author: trims Date: 2010-11-11 23:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5484e7c53fa7 6997698: Bump the HS20 build number to 03 Summary: Update the HS20 build number to 03 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 899bbbdcb6ea Author: ysr Date: 2010-11-05 13:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/899bbbdcb6ea 6997298: fatal error: must own lock CMS_markBitMap_lock during heap dump Summary: Since we are at a stop-world pause, the existing CMS-phase checks are sufficient for safety, and the locking check can be safely elided. Elaborated documentation comment to the case where class unloading and verification are disabled, and the query happens when we aren't in the sweeping phase, where the answer "false" would be (almost everywhere) too pessimistic. Reviewed-by: jmasa, johnc, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp Changeset: 4df7f8cba524 Author: ysr Date: 2010-11-09 10:47 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4df7f8cba524 6996613: CompactibleFreeListSpace::print should call CompactibleFreeListSpace::print_on, not Space::print_on Reviewed-by: tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp Changeset: 8d81b4a1d3e1 Author: ysr Date: 2010-11-11 10:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8d81b4a1d3e1 6998802: ScavengeALot: assert(!gch->incremental_collection_failed()) failed: Twice in a row Summary: Weaken assert by excluding scavenges resulting from -XX:+ScavengeALot stress-testing option. Reviewed-by: jmasa, tonyp ! src/share/vm/memory/defNewGeneration.cpp Changeset: e3e1fb85e50a Author: jmasa Date: 2010-11-15 16:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e3e1fb85e50a Merge Changeset: 1070423b51f3 Author: kamg Date: 2010-10-27 12:53 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1070423b51f3 6865028: Illegal instructions passing verification prior to 'invokespecial Object.' Summary: Update verifier to conform to spec re: reference vs. 'Object' types Reviewed-by: dholmes, coleenp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp Changeset: 35f885165c69 Author: kamg Date: 2010-11-05 09:32 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/35f885165c69 6981737: The java.vm.specification.version property is 1.0, seems like it should be 2.0 Summary: Change property value to 1. for major_version >= 7 Reviewed-by: dholmes, acorn ! src/share/vm/runtime/arguments.cpp + test/runtime/6981737/Test6981737.java Changeset: 9752a6549f2e Author: zgu Date: 2010-11-12 09:37 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9752a6549f2e Merge ! src/share/vm/classfile/verifier.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 13fee5052895 Author: zgu Date: 2010-11-17 09:21 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/13fee5052895 Merge Changeset: 9eecf81a02fb Author: ysr Date: 2010-11-16 13:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9eecf81a02fb 7000578: CMS: assert(SafepointSynchronize::is_at_safepoint()) failed: Else races are possible Summary: Weakened assert in onj_is_alive() to allow its use at initialization time when is_at_safepoint() normally reports false; added some related asserts to check order of is_init_completed() after Universe::is_fully_initialized(). Reviewed-by: jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/includeDB_core ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/init.cpp Changeset: 878b57474103 Author: johnc Date: 2010-11-16 14:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/878b57474103 6978187: G1: assert(ParallelGCThreads> 1 || n_yielded() == _hrrs->occupied()) strikes again Summary: An evacuation failure while copying the roots caused an object, A, to be forwarded to itself. During the subsequent RSet updating a reference to A was processed causing the reference to be added to the RSet of A's heap region. As a result of adding to the remembered set we ran into the issue described in 6930581 - the sparse table expanded and the RSet scanning code walked the cards in one instance of RHashTable (_cur) while the occupied() counts the cards in the expanded table (_next). Reviewed-by: tonyp, iveresov ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp Changeset: deef066c3622 Author: johnc Date: 2010-11-16 16:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/deef066c3622 Merge Changeset: 0be53e62c06c Author: jmasa Date: 2010-11-19 13:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0be53e62c06c Merge Changeset: 4110c3e0c50d Author: iveresov Date: 2010-11-19 17:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4110c3e0c50d Merge ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp From john.r.rose at oracle.com Sun Nov 21 00:40:12 2010 From: john.r.rose at oracle.com (John Rose) Date: Sun, 21 Nov 2010 00:40:12 -0800 Subject: for review (M): 7001423: JSR 292 bytecode enhancements need unit tests Message-ID: <4714171D-B690-4B3B-87EA-4018ED1E86FB@oracle.com> This webrev has a small jtreg test for the hotspot repository. http://cr.openjdk.java.net/~jrose/7001423/webrev.00/ It exercises the invokedynamic instruction, making the the bootstrap method parameters are made available to the BSM, and ensuring that the resulting call site can be invoked as expected. (Not included, to be done later: Multiple invocation of dynamic call sites, additional bootstrap method parameters, "ldc" of MethodHandle and MethodType constants.) In order to introduce an invokedynamic instruction (without help from the compiler), this unit test comes with a medium-sized script (single-file Java program) called "Indify" which generates the instruction in the test file. The Indify script is described here: http://blogs.sun.com/jrose/entry/a_modest_tool_for_writing In later pushes, Indify will be re-used for additional unit tests (such as those mentioned above to be done later). Thanks, -- John From puzzlesdj at gmail.com Sun Nov 21 06:07:53 2010 From: puzzlesdj at gmail.com (ddmetro) Date: Sun, 21 Nov 2010 06:07:53 -0800 (PST) Subject: help regarding 'thread allocation to cores' - in hotspot jvm Message-ID: <30271610.post@talk.nabble.com> Hi All, I am currently trying to figure out how hotspot jvm allocates thread to cores. I found code that creates compiler, vm and java threads as pthread and assigns priorities to them. I tried looking in the the 'os' and 'os_cpu' folders under 'src' folder of hotspot, however couldn't find anything related to - allocation of threads to cores. I expected to find this code in a folder by the name of 'i386' or 'i486'. I tried looking in the folder 'linux_x86', but couldn't find the required code. Question: Can someone direct me to the code (.cpp file) that handles thread allocation to cores? Platform: Linux - Ubuntu 10.04 Thanking You, Dhiraj P. -- View this message in context: http://old.nabble.com/help-regarding-%27thread-allocation-to-cores%27---in-hotspot-jvm-tp30271610p30271610.html Sent from the OpenJDK Hotspot Compiler Development List mailing list archive at Nabble.com. From y.s.ramakrishna at oracle.com Sun Nov 21 12:03:18 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Sun, 21 Nov 2010 12:03:18 -0800 Subject: help regarding 'thread allocation to cores' - in hotspot jvm In-Reply-To: <30271610.post@talk.nabble.com> References: <30271610.post@talk.nabble.com> Message-ID: <4CE97B06.4050806@oracle.com> Hello Dhiraj -- For all practical purposes, the JVM leaves that up to the OS, never explicitly binding threads to cores. In most cases, the OS scheduler has more relevant data and certainly more efficient policies to make a globally more optimal assignment than a single JVM would. There are interfaces in the planning stages that might allow specifying scheduling relationships to help the OS further optimize those decisions but as far as i know those are not completed yet. If however you want to play with explicit thread-to-core binding functionality, then you'll want to look at the code in os::bind_to_processor() (which by the way is only implemented in the case of Solaris at the moment), and never used by default in the JVM. The code is currently only used by GC thread code to bind specific threads to cores and, as far as i know, has not been used extensively at all (but rather more as a debug/special case mechanism so far; although of course i do not by any means know how specific Solaris customers may be using that functionality/capability). To start exploring that code (which may well have bit-rotted since it was first put in a number of years ago), search for BindCMSThreadToCPU and BindGCTaskThreadsToCPUs; and go from there. Anyway, FWIW ... -- ramki On 11/21/2010 6:07 AM, ddmetro wrote: > > Hi All, > > I am currently trying to figure out how hotspot jvm allocates thread to > cores. I found code that creates compiler, vm and java threads as pthread > and assigns priorities to them. I tried looking in the the 'os' and 'os_cpu' > folders under 'src' folder of hotspot, however couldn't find anything > related to - allocation of threads to cores. > > I expected to find this code in a folder by the name of 'i386' or 'i486'. I > tried looking in the folder 'linux_x86', but couldn't find the required > code. > > Question: Can someone direct me to the code (.cpp file) that handles thread > allocation to cores? > > Platform: Linux - Ubuntu 10.04 > > Thanking You, > Dhiraj P. > > From gbenson at redhat.com Mon Nov 22 05:12:16 2010 From: gbenson at redhat.com (Gary Benson) Date: Mon, 22 Nov 2010 13:12:16 +0000 Subject: Review Request: Zero and Shark fixes Message-ID: <20101122131216.GA3819@redhat.com> Hi all, This webrev contains a couple of fixes for Zero and Shark: http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-03/ Firstly, 6970683 introduced a new method, os::print_register_info, which this webrev provides for Zero. Secondly, 6953144 changed the way that compilers are initialized in the compile broker, and this webrev updates the Shark initialization for this change. I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ From dlila at redhat.com Mon Nov 22 11:23:13 2010 From: dlila at redhat.com (Denis Lila) Date: Mon, 22 Nov 2010 14:23:13 -0500 (EST) Subject: SIGSEGV in C2 compiler In-Reply-To: <1073012236.139391290453787509.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1924714775.139411290453793062.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hello. I was working on the pisces rendering engine using eclipse and I encountered a segfault. I was using the pisces/Test.java file to test various parts of the rendering engine without having to rebuild openjdk. In it, I create a Frame whose paint method creates a Path2D, a Stroker and a Dasher. Then the path is fed to the Dasher (but it is not drawn because this is unnecessary to make it crash), and eventually Stroker.somethingTo is called, which is where the crash occurred. However, it only happened when I accidentally left uncommented the rest of main, which creates other Stroker and Dasher objects and feeds lots of curves to them and measures how long this processing takes. Even then, it only happens if one grabs the window and moves it on and off screen, causing the paint method to be called. I tried putting a repaint() call at the end of paint() so that I wouldn't have to do any manual work, but that didn't work. It is reproducible using an awt.Robot, but not as frequently as manually. When I remove the Frame creation and leave just the performance measuring part of main(), it doesn't crash. It also doesn't crash when I remove the performance measuring part of main() and leave just the graphical part of the program. I tried reproducing it using a debug build of hotspot, but I couldn't. This all suggests that it's a concurrency issue, so I wrote a new main that simply created a few threads where each thread created Dasher and Stroker objects and fed curves to them, but this didn't crash. Another important thing is that I was only able to reproduce it when the files in pisces.tar.gz were compiled using ecj - not javac. I've seen over 30 hs_err_pis*.log files produced by this crash and every one of them says: C2: [2|3]% pisces.Stroker.somethingTo(I)V @ 710 (1190 bytes) where line 710 corresponds to line 830 in Stroker.java, which is a call to it.next() where "it" is an anonymous Iterator object. I did not submit a bug report at sun.bugs.com because I couldn't find a way to attach the 4 files. -------------- next part -------------- A non-text attachment was scrubbed... Name: pisces.tar.gz Type: application/x-compressed-tar Size: 22223 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20101122/5aa97226/attachment-0003.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: hotspot.log Type: text/x-log Size: 5433 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20101122/5aa97226/attachment-0004.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid12042.log Type: text/x-log Size: 21803 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20101122/5aa97226/attachment-0005.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gdbDump.txt Url: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20101122/5aa97226/attachment-0001.txt From dlila at redhat.com Mon Nov 22 11:27:40 2010 From: dlila at redhat.com (Denis Lila) Date: Mon, 22 Nov 2010 14:27:40 -0500 (EST) Subject: SIGSEGV in C2 compiler In-Reply-To: <245787815.139611290453922346.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <212257681.139941290454060257.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> I'm sorry, I accidentally sent this without finishing it. I meant to say that gdbdump.txt, hotspot.log, and the hs_err_*.log files were obtained using a fastdebug build of hotspot 19-b06. I can reproduce the crash with hotspot 17 too. Regards, Denis. ----- "Denis Lila" wrote: > Hello. > > I was working on the pisces rendering engine using eclipse and I > encountered a segfault. I was using the pisces/Test.java file > to test various parts of the rendering engine without having to > rebuild > openjdk. In it, I create a Frame whose paint method creates a Path2D, > a Stroker and a Dasher. Then the path is fed to the Dasher (but it is > not > drawn because this is unnecessary to make it crash), and eventually > Stroker.somethingTo is called, which is where the crash occurred. > However, > it only happened when I accidentally left uncommented the rest of > main, which creates other Stroker and Dasher objects and feeds lots of > curves to them and measures how long this processing takes. Even then, > it only happens if one grabs the window and moves it on and off > screen, > causing the paint method to be called. I tried putting a repaint() > call > at the end of paint() so that I wouldn't have to do any manual work, > but that didn't work. It is reproducible using an awt.Robot, but not > as frequently as manually. > > When I remove the Frame creation and leave just the performance > measuring > part of main(), it doesn't crash. It also doesn't crash when I remove > the performance measuring part of main() and leave just the graphical > part of the program. I tried reproducing it using a debug build of > hotspot, > but I couldn't. This all suggests that it's a concurrency issue, so I > wrote a new main that simply created a few threads where each thread > created Dasher and Stroker objects and fed curves to them, but this > didn't > crash. > > > Another important thing is that I was only able to reproduce it when > the > files in pisces.tar.gz were compiled using ecj - not javac. > > I've seen over 30 hs_err_pis*.log files produced by this crash and > every one > of them says: > C2: [2|3]% pisces.Stroker.somethingTo(I)V @ 710 (1190 bytes) > > where line 710 corresponds to line 830 in Stroker.java, which is a > call to > it.next() where "it" is an anonymous Iterator object. > > I did not submit a bug report at sun.bugs.com because I couldn't find > a way > to attach the 4 files. From tom.rodriguez at oracle.com Mon Nov 22 11:55:12 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 22 Nov 2010 11:55:12 -0800 Subject: SIGSEGV in C2 compiler In-Reply-To: <212257681.139941290454060257.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <212257681.139941290454060257.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: On Nov 22, 2010, at 11:27 AM, Denis Lila wrote: > I'm sorry, I accidentally sent this without finishing it. > > I meant to say that gdbdump.txt, hotspot.log, and the hs_err_*.log > files were obtained using a fastdebug build of hotspot 19-b06. > > I can reproduce the crash with hotspot 17 too. What about the latest hotspot which is hs20-b02? I think we recently fixed a bad graph bug related to EA. You can try -XX:-DoEscapeAnalysis. Actually if it reproduces with hs17 then it's probably not the same EA bug. Can you provide the ecj compiled class files too? >> >> I did not submit a bug report at sun.bugs.com because I couldn't find >> a way >> to attach the 4 files. Yes that's kind of lame. You can just include a note in the description that says to contact you directly for the files. Directly including the hs_err as text is a good idea though. tom From dlila at redhat.com Mon Nov 22 12:36:32 2010 From: dlila at redhat.com (Denis Lila) Date: Mon, 22 Nov 2010 15:36:32 -0500 (EST) Subject: SIGSEGV in C2 compiler In-Reply-To: <1510596729.146521290457597491.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <983990142.147551290458192485.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > What about the latest hotspot which is hs20-b02? That also crashes. > I think we recently fixed a bad graph bug related to EA. You can try > -XX:-DoEscapeAnalysis. Actually if it reproduces with hs17 then it's > probably not the same EA bug. Yes, it also crashes with -XX:-DoEscapeAnalysis. > Can you provide the ecj compiled class files too? Certainly. Regards, Denis. ----- "Tom Rodriguez" wrote: > On Nov 22, 2010, at 11:27 AM, Denis Lila wrote: > > > I'm sorry, I accidentally sent this without finishing it. > > > > I meant to say that gdbdump.txt, hotspot.log, and the hs_err_*.log > > files were obtained using a fastdebug build of hotspot 19-b06. > > > > I can reproduce the crash with hotspot 17 too. > > >> > >> I did not submit a bug report at sun.bugs.com because I couldn't > find > >> a way > >> to attach the 4 files. > > Yes that's kind of lame. You can just include a note in the > description that says to contact you directly for the files. Directly > including the hs_err as text is a good idea though. > > tom -------------- next part -------------- A non-text attachment was scrubbed... Name: piscesEcjClasses.tar.gz Type: application/x-compressed-tar Size: 20599 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20101122/03670836/attachment-0001.bin From john.r.rose at oracle.com Mon Nov 22 18:57:56 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 22 Nov 2010 18:57:56 -0800 Subject: review request (L): 6984311 JSR 292 needs optional bootstrap method parameters In-Reply-To: <293F39DB-6C5D-490D-8C0B-B23D54ACC932@oracle.com> References: <6112D7F4-DD79-4430-A915-602F129E5F1E@oracle.com> <0EDC451E-6072-40EE-8A4C-DFA5C443BC4E@oracle.com> <614316A7-EC07-4C52-A64C-BD97E6AF4E39@oracle.com> <293F39DB-6C5D-490D-8C0B-B23D54ACC932@oracle.com> Message-ID: <3BB24E8B-E579-4641-917C-F62B15C20C00@oracle.com> Because of a strong and reasonable request from the IBM JVM team, the JSR 292 class file format for CONSTANT_InvokeDynamic is changing one more time. The current format looks like this: struct { u1 tag = 18, u2 bsm: MethodHandle, u2 nt: NameAndType, u2 argc, u2 argv[argc] } The new format will look like this: struct { u1 tag = 18, u2 bsm_spec: MethodHandle, u2 nt: NameAndType } The bsm_spec will be an index into an explicit side-table in the class file, containing an array of the same information as before (MethodHandle, argc, argv[argc]). The side-table will be a new attribute named "BootstrapMethods". This format change will make the class file format a easier to parse by some JVMs (such as J9). I will be putting out a review request soon for this. -- John On Nov 2, 2010, at 2:38 AM, Christian Thalinger wrote: > On Oct 30, 2010, at 9:08 PM, John Rose wrote: >> ... >> Thanks. I am updating the webrev: >> http://cr.openjdk.java.net/~jrose/6984311/webrev.03/ > > Looks good. -- Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20101122/83233f84/attachment.html From john.r.rose at oracle.com Mon Nov 22 19:11:57 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 22 Nov 2010 19:11:57 -0800 Subject: review request (L): 6984311 JSR 292 needs optional bootstrap method parameters In-Reply-To: <3BB24E8B-E579-4641-917C-F62B15C20C00@oracle.com> References: <6112D7F4-DD79-4430-A915-602F129E5F1E@oracle.com> <0EDC451E-6072-40EE-8A4C-DFA5C443BC4E@oracle.com> <614316A7-EC07-4C52-A64C-BD97E6AF4E39@oracle.com> <293F39DB-6C5D-490D-8C0B-B23D54ACC932@oracle.com> <3BB24E8B-E579-4641-917C-F62B15C20C00@oracle.com> Message-ID: <47ACE85D-0185-435D-90AE-E497579E7C25@oracle.com> P.S. The updated spec is here, as always: http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/java/dyn/package-summary.html http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/ From igor.veresov at oracle.com Mon Nov 22 22:51:07 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 22 Nov 2010 22:51:07 -0800 Subject: Request for review(XL): 6985015: C1 needs to support compressed oops In-Reply-To: <485C2B0E-2982-440E-B12F-3B45AA54A7E9@oracle.com> References: <4CE5EB17.3090503@oracle.com> <485C2B0E-2982-440E-B12F-3B45AA54A7E9@oracle.com> Message-ID: <4CEB645B.5070405@oracle.com> Tom, thanks a lot for the review! Please find responses inlined. Updated webrev: http://cr.openjdk.java.net/~iveresov/6985015/webrev.01/ igor On 11/19/10 1:18 PM, Tom Rodriguez wrote: > The cpu_reg_range_reduction stuff is pretty gross. Can we just make nof_caller_save_cpu_regs a method on FrameMap. The existing enum would become _max_nof_caller_save_cpu_regs so it could continue to be a constant for declarations. > Sure, it seemed to be a good idea a the time, I thought it would look more uniform. Anyways, done, and added 2 more of these functions: for last_cpu_reg and last_byte_reg. > assembler_sparc.cpp: > > what is slr and why would you use it instead of sllx? Because sllx won't clear the upper bits. I thought I'd piggyback this little fix on this change. > > c1_LIRAssembler_sparc.cpp: > > use load_klass instead. It this about vtable_call() ? There was an issue with the SS12u1, I had to either hand-inline it, or lower the opt level. I'll put a comment. > > In general if you can use load_heap_oop and store_heap_oop instead that would be preferable. It's possible you'll need to add an alternate temp argument to them since they always assume it's ok to kill the oop value. > But to do that I would probably have to pass "wide" there and also to return the offset of the instruction that contains disp for patching. I thought I'd just contain this oddity in load/store or mem2reg/reg2mem. I can introduce these primitives if you like though... > in const2mem, init offset to -1 and assert that it's been set at before using it. > Done. > sometimes the argument ordering is wide then unaligned and other times it's reversed which seems like asking for trouble. Why is it like this? Fixed. > > I guess the arraycopy guards were fairly broken on 64 bit since they were still using br instead of brx in a few places. Oops. > > You're loading the klasses as 32 bit but comparing them using the 64 bit condition code which I know will work in this case but it's a bad practice. > loads always produce safe values but it's not clear that our constant construction code does. Maybe we need a br variant that allows specifying the > condition codes? bp lets you but that's v9 only. Done. > > + #ifdef _LP64 > + if (UseCompressedOops) { > + __ encode_heap_oop(tmp, tmp); > + __ lduw(dst, oopDesc::klass_offset_in_bytes(), tmp2); > + } else > + #endif > __ ld_ptr(dst, oopDesc::klass_offset_in_bytes(), tmp2); > > Could you put some comments on this? Sure. > I know this code is assert only but is there a need for a jobject2reg that produces the encoded oop directly? The relocs support it. > Doing the type checks by producing wide oops will be much more expensive. Yes, and there is definitely an opportunity to optimize checkcast and instanceof by doing that. I'd like address that in a separate CR, if that's ok? > > c1_LIRAssembler_x86.cpp: > > what happening with the alignment? Why isn't it aligned from compressed oops? On x86 all compressed oops operations (like *code_heap_oop() or load/store_klass()) contain heapbase verfication, so the size of the emitted code changes not only for 32 to 64 bits but also depending on whether the ASSERT is on. So, I decided I'd just stick with the post-padding. > > Other it looks fine. > > tom > > On Nov 18, 2010, at 7:12 PM, Igor Veresov wrote: > >> This change implements compressed oops for C1 for x64 and sparc. >> The changes are mostly on the codegen level, with a few exceptions when we do access things outside of the heap that are uncompressed from the IR. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6985015/webrev.00/ >> >> Thanks, >> igor > From christian.thalinger at oracle.com Tue Nov 23 01:50:43 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 23 Nov 2010 10:50:43 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: <20101122131216.GA3819@redhat.com> References: <20101122131216.GA3819@redhat.com> Message-ID: On Nov 22, 2010, at 2:12 PM, Gary Benson wrote: > Hi all, > > This webrev contains a couple of fixes for Zero and Shark: > > http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-03/ > > Firstly, 6970683 introduced a new method, os::print_register_info, > which this webrev provides for Zero. Secondly, 6953144 changed > the way that compilers are initialized in the compile broker, and > this webrev updates the Shark initialization for this change. > > I don't have a bug id for this. 7002129: Zero and Shark fixes, 3rd hotspot/src/share/vm/compiler/compileBroker.cpp: 541 #else // SHARK 542 int c1_count = 0; 543 int c2_count = 1; 544 545 _compilers[1] = new SharkCompiler(); 546 #endif // SHARK Does that mean you can compile now a client and server VM with Shark enabled? What happens in a client VM since compiler[0] seems not to be set? -- Christian From christian.thalinger at oracle.com Tue Nov 23 02:04:58 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 23 Nov 2010 11:04:58 +0100 Subject: review request (M): 6979327: method handle invocation should use casts instead of type parameters to specify return type In-Reply-To: <1C6C258E-82AD-40D8-A5EB-885D43386C8E@oracle.com> References: <0B777385-490A-4C3A-92EA-BA3A466B9B62@oracle.com> <1C6C258E-82AD-40D8-A5EB-885D43386C8E@oracle.com> Message-ID: <0C88707F-B19D-4E18-8F63-E2C7DCCCD5DD@oracle.com> On Nov 19, 2010, at 7:20 PM, John Rose wrote: > It's re-published. -- John Looks good. -- Christian From mark at klomp.org Tue Nov 23 02:12:47 2010 From: mark at klomp.org (Mark Wielaard) Date: Tue, 23 Nov 2010 11:12:47 +0100 Subject: SIGSEGV in C2 compiler In-Reply-To: <983990142.147551290458192485.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <983990142.147551290458192485.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1290507167.2239.3.camel@hermans.wildebeest.org> On Mon, 2010-11-22 at 15:36 -0500, Denis Lila wrote: > > What about the latest hotspot which is hs20-b02? > > That also crashes. > > > I think we recently fixed a bad graph bug related to EA. You can try > > -XX:-DoEscapeAnalysis. Actually if it reproduces with hs17 then it's > > probably not the same EA bug. > > Yes, it also crashes with -XX:-DoEscapeAnalysis. Have you tried with -XX:-UseCompressedOops? That is the biggest crasher on Fedora atm. https://bugzilla.redhat.com/show_bug.cgi?id=647737 From christian.thalinger at oracle.com Tue Nov 23 02:21:49 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 23 Nov 2010 11:21:49 +0100 Subject: for review (M): 7001423: JSR 292 bytecode enhancements need unit tests In-Reply-To: <4714171D-B690-4B3B-87EA-4018ED1E86FB@oracle.com> References: <4714171D-B690-4B3B-87EA-4018ED1E86FB@oracle.com> Message-ID: <64328FAD-8029-449F-BD45-B2A7AE4CE1E7@oracle.com> On Nov 21, 2010, at 9:40 AM, John Rose wrote: > This webrev has a small jtreg test for the hotspot repository. > > http://cr.openjdk.java.net/~jrose/7001423/webrev.00/ > > It exercises the invokedynamic instruction, making the the bootstrap > method parameters are made available to the BSM, and ensuring that > the resulting call site can be invoked as expected. > > (Not included, to be done later: Multiple invocation of dynamic > call sites, additional bootstrap method parameters, "ldc" of > MethodHandle and MethodType constants.) > > In order to introduce an invokedynamic instruction (without help > from the compiler), this unit test comes with a medium-sized script > (single-file Java program) called "Indify" which generates the > instruction in the test file. > > The Indify script is described here: http://blogs.sun.com/jrose/entry/a_modest_tool_for_writing > > In later pushes, Indify will be re-used for additional unit tests > (such as those mentioned above to be done later). I haven't looked closely at the changes (especially Indify) but it seems good. -- Christian From gbenson at redhat.com Tue Nov 23 03:51:34 2010 From: gbenson at redhat.com (Gary Benson) Date: Tue, 23 Nov 2010 11:51:34 +0000 Subject: Review Request: Zero and Shark fixes In-Reply-To: References: <20101122131216.GA3819@redhat.com> Message-ID: <20101123115133.GA4574@redhat.com> Christian Thalinger wrote: > hotspot/src/share/vm/compiler/compileBroker.cpp: > > 541 #else // SHARK > 542 int c1_count = 0; > 543 int c2_count = 1; > 544 > 545 _compilers[1] = new SharkCompiler(); > 546 #endif // SHARK > > Does that mean you can compile now a client and server VM with Shark > enabled? What happens in a client VM since compiler[0] seems not to > be set? No, you can't use Shark with the other compilers, the calling conventions are different (and, for non-x86 and non-sparc, not even there). This code is a little bit of a hack in that it slots Shark into the space normally used by the server compiler. The alternative would be to make a third "tier" for Shark, but that would be a lot of changes in a lot of places. I thought this way would be easier for you guys, but I'm happy to rewrite it if you prefer. _compilers is a static field, so it is zeroed when it is allocated. The code above the section in the patch relies on this too. Cheers, Gary -- http://gbenson.net/ From christian.thalinger at oracle.com Tue Nov 23 04:11:31 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 23 Nov 2010 13:11:31 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: <20101123115133.GA4574@redhat.com> References: <20101122131216.GA3819@redhat.com> <20101123115133.GA4574@redhat.com> Message-ID: On Nov 23, 2010, at 12:51 PM, Gary Benson wrote: > Christian Thalinger wrote: >> hotspot/src/share/vm/compiler/compileBroker.cpp: >> >> 541 #else // SHARK >> 542 int c1_count = 0; >> 543 int c2_count = 1; >> 544 >> 545 _compilers[1] = new SharkCompiler(); >> 546 #endif // SHARK >> >> Does that mean you can compile now a client and server VM with Shark >> enabled? What happens in a client VM since compiler[0] seems not to >> be set? > > No, you can't use Shark with the other compilers, the calling > conventions are different (and, for non-x86 and non-sparc, not even > there). This code is a little bit of a hack in that it slots Shark > into the space normally used by the server compiler. The alternative > would be to make a third "tier" for Shark, but that would be a lot of > changes in a lot of places. I thought this way would be easier for > you guys, but I'm happy to rewrite it if you prefer. > > _compilers is a static field, so it is zeroed when it is allocated. > The code above the section in the patch relies on this too. It does. I'm sure your code works, I just wanted to ask. Then I push your changes as is. -- Christian From gbenson at redhat.com Tue Nov 23 04:55:46 2010 From: gbenson at redhat.com (Gary Benson) Date: Tue, 23 Nov 2010 12:55:46 +0000 Subject: Review Request: Zero and Shark fixes In-Reply-To: References: <20101122131216.GA3819@redhat.com> <20101123115133.GA4574@redhat.com> Message-ID: <20101123125546.GB4574@redhat.com> Christian Thalinger wrote: > On Nov 23, 2010, at 12:51 PM, Gary Benson wrote: > > Christian Thalinger wrote: > > > hotspot/src/share/vm/compiler/compileBroker.cpp: > > > > > > 541 #else // SHARK > > > 542 int c1_count = 0; > > > 543 int c2_count = 1; > > > 544 > > > 545 _compilers[1] = new SharkCompiler(); > > > 546 #endif // SHARK > > > > > > Does that mean you can compile now a client and server VM with > > > Shark enabled? What happens in a client VM since compiler[0] > > > seems not to be set? > > > > No, you can't use Shark with the other compilers, the calling > > conventions are different (and, for non-x86 and non-sparc, not > > even there). This code is a little bit of a hack in that it slots > > Shark into the space normally used by the server compiler. The > > alternative would be to make a third "tier" for Shark, but that > > would be a lot of changes in a lot of places. I thought this way > > would be easier for you guys, but I'm happy to rewrite it if you > > prefer. > > > > _compilers is a static field, so it is zeroed when it is allocated. > > The code above the section in the patch relies on this too. > > It does. I'm sure your code works, I just wanted to ask. Then I push > your changes as is. Awesome, thanks :) Cheers, Gary -- http://gbenson.net/ From dlila at redhat.com Tue Nov 23 06:29:22 2010 From: dlila at redhat.com (Denis Lila) Date: Tue, 23 Nov 2010 09:29:22 -0500 (EST) Subject: SIGSEGV in C2 compiler In-Reply-To: <1029885353.207311290522395823.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <613570560.207811290522562188.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > Have you tried with -XX:-UseCompressedOops? > That is the biggest crasher on Fedora atm. > https://bugzilla.redhat.com/show_bug.cgi?id=647737 Actually, that's the first thing I tried :) Unfortunately, it still crashes with no compressed oops. This isn't surprising, since it crashed with HS17, where compressed oops are turned off by default, along with a couple of other optimizations. Regards, Denis. ----- "Mark Wielaard" wrote: > On Mon, 2010-11-22 at 15:36 -0500, Denis Lila wrote: > > > What about the latest hotspot which is hs20-b02? > > > > That also crashes. > > > > > I think we recently fixed a bad graph bug related to EA. You can > try > > > -XX:-DoEscapeAnalysis. Actually if it reproduces with hs17 then > it's > > > probably not the same EA bug. > > > > Yes, it also crashes with -XX:-DoEscapeAnalysis. > From Christian.Thalinger at Sun.COM Tue Nov 23 06:41:25 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 23 Nov 2010 14:41:25 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7002129: Zero and Shark fixes, 3rd Message-ID: <20101123144130.7A23A47BE4@hg.openjdk.java.net> Changeset: b675ff1ca7a3 Author: twisti Date: 2010-11-23 04:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b675ff1ca7a3 7002129: Zero and Shark fixes, 3rd Summary: 6970683 and 6953144 introduced changes that need to be implemented for Zero and Shark. Reviewed-by: twisti Contributed-by: Gary Benson ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/share/vm/compiler/compileBroker.cpp From vladimir.kozlov at oracle.com Tue Nov 23 17:12:19 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 24 Nov 2010 01:12:19 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 5 new changesets Message-ID: <20101124011230.C8DB647C1C@hg.openjdk.java.net> Changeset: 22260322f0be Author: zgu Date: 2010-11-18 14:37 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/22260322f0be 6751923: JNDI wake up when clock_settime() is called Summary: Ported Chris Phillips' patch from jdk5 to jdk7 Reviewed-by: chrisphi, coleenp ! src/os/solaris/vm/os_solaris.cpp Changeset: 0b33f0736406 Author: poonam Date: 2010-11-19 03:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0b33f0736406 6837842: JNI_CreateJavaVM crashes under impersonation Reviewed-by: acorn, dholmes ! src/os/windows/vm/perfMemory_windows.cpp Changeset: a6b067997c7e Author: coleenp Date: 2010-11-19 23:46 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a6b067997c7e Merge Changeset: e33f46fc48ed Author: coleenp Date: 2010-11-23 15:01 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e33f46fc48ed Merge Changeset: f95d63e2154a Author: stefank Date: 2010-11-23 13:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f95d63e2154a 6989984: Use standard include model for Hospot Summary: Replaced MakeDeps and the includeDB files with more standardized solutions. Reviewed-by: coleenp, kvn, kamg ! make/linux/makefiles/adlc.make ! make/linux/makefiles/amd64.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/core.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/i486.make ! make/linux/makefiles/jvmti.make ! make/linux/makefiles/launcher.make - make/linux/makefiles/makedeps.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/sparc.make ! make/linux/makefiles/sparcWorks.make ! make/linux/makefiles/sparcv9.make ! make/linux/makefiles/top.make ! make/linux/makefiles/vm.make ! make/linux/makefiles/zero.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/amd64.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/core.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/i486.make ! make/solaris/makefiles/jvmti.make ! make/solaris/makefiles/launcher.make - make/solaris/makefiles/makedeps.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/sparcv9.make ! make/solaris/makefiles/top.make ! make/solaris/makefiles/vm.make - make/windows/README ! make/windows/create.bat + make/windows/create_obj_files.sh ! make/windows/makefiles/adlc.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/generated.make - make/windows/makefiles/makedeps.make ! make/windows/makefiles/product.make + make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! make/windows/projectfiles/common/Makefile ! make/windows/projectfiles/compiler2/Makefile ! make/windows/projectfiles/kernel/Makefile ! make/windows/projectfiles/tiered/Makefile ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/bytecodeInterpreter_sparc.cpp ! src/cpu/sparc/vm/bytecodeInterpreter_sparc.hpp ! src/cpu/sparc/vm/bytecodeInterpreter_sparc.inline.hpp ! src/cpu/sparc/vm/bytecodes_sparc.cpp ! src/cpu/sparc/vm/bytecodes_sparc.hpp ! src/cpu/sparc/vm/bytes_sparc.hpp ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Defs_sparc.hpp ! src/cpu/sparc/vm/c1_FpuStackSim_sparc.cpp ! src/cpu/sparc/vm/c1_FpuStackSim_sparc.hpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/c1_LinearScan_sparc.cpp ! src/cpu/sparc/vm/c1_LinearScan_sparc.hpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.hpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/c1_globals_sparc.hpp ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/c2_init_sparc.cpp ! src/cpu/sparc/vm/codeBuffer_sparc.hpp ! src/cpu/sparc/vm/copy_sparc.hpp ! src/cpu/sparc/vm/cppInterpreterGenerator_sparc.hpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.hpp ! src/cpu/sparc/vm/debug_sparc.cpp ! src/cpu/sparc/vm/depChecker_sparc.cpp ! src/cpu/sparc/vm/depChecker_sparc.hpp ! src/cpu/sparc/vm/disassembler_sparc.hpp ! src/cpu/sparc/vm/dump_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/sparc/vm/globalDefinitions_sparc.hpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/sparc/vm/icBuffer_sparc.cpp ! src/cpu/sparc/vm/icache_sparc.cpp ! src/cpu/sparc/vm/icache_sparc.hpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp ! src/cpu/sparc/vm/interpreterRT_sparc.cpp ! src/cpu/sparc/vm/interpreterRT_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/interpreter_sparc.hpp ! src/cpu/sparc/vm/javaFrameAnchor_sparc.hpp ! src/cpu/sparc/vm/jniFastGetField_sparc.cpp ! src/cpu/sparc/vm/jniTypes_sparc.hpp ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/registerMap_sparc.hpp ! src/cpu/sparc/vm/register_definitions_sparc.cpp ! src/cpu/sparc/vm/register_sparc.cpp ! src/cpu/sparc/vm/register_sparc.hpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/sparc/vm/relocInfo_sparc.hpp ! src/cpu/sparc/vm/runtime_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/sparc/vm/templateInterpreterGenerator_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.hpp ! src/cpu/sparc/vm/vmStructs_sparc.hpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/sparc/vm/vmreg_sparc.cpp ! src/cpu/sparc/vm/vmreg_sparc.hpp ! src/cpu/sparc/vm/vmreg_sparc.inline.hpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/assembler_x86.inline.hpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.cpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.hpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.inline.hpp ! src/cpu/x86/vm/bytecodes_x86.cpp ! src/cpu/x86/vm/bytecodes_x86.hpp ! src/cpu/x86/vm/bytes_x86.hpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Defs_x86.hpp ! src/cpu/x86/vm/c1_FpuStackSim_x86.cpp ! src/cpu/x86/vm/c1_FpuStackSim_x86.hpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.hpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/cpu/x86/vm/c1_LinearScan_x86.hpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.hpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/c1_globals_x86.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/c2_init_x86.cpp ! src/cpu/x86/vm/codeBuffer_x86.hpp ! src/cpu/x86/vm/copy_x86.hpp ! src/cpu/x86/vm/cppInterpreterGenerator_x86.hpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.hpp ! src/cpu/x86/vm/debug_x86.cpp ! src/cpu/x86/vm/depChecker_x86.cpp ! src/cpu/x86/vm/depChecker_x86.hpp ! src/cpu/x86/vm/disassembler_x86.hpp ! src/cpu/x86/vm/dump_x86_32.cpp ! src/cpu/x86/vm/dump_x86_64.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/globalDefinitions_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/icBuffer_x86.cpp ! src/cpu/x86/vm/icache_x86.cpp ! src/cpu/x86/vm/icache_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/interpreterRT_x86.hpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/interpreterRT_x86_64.cpp ! src/cpu/x86/vm/interpreter_x86.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/javaFrameAnchor_x86.hpp ! src/cpu/x86/vm/jniFastGetField_x86_32.cpp ! src/cpu/x86/vm/jniFastGetField_x86_64.cpp ! src/cpu/x86/vm/jniTypes_x86.hpp ! src/cpu/x86/vm/jni_x86.h ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.hpp ! src/cpu/x86/vm/registerMap_x86.hpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/register_x86.cpp ! src/cpu/x86/vm/register_x86.hpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/x86/vm/relocInfo_x86.hpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/runtime_x86_64.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/templateInterpreterGenerator_x86.hpp ! src/cpu/x86/vm/templateInterpreter_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_32.hpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_64.hpp ! src/cpu/x86/vm/vmStructs_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/vmreg_x86.cpp ! src/cpu/x86/vm/vmreg_x86.hpp ! src/cpu/x86/vm/vmreg_x86.inline.hpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/assembler_zero.hpp ! src/cpu/zero/vm/assembler_zero.inline.hpp ! src/cpu/zero/vm/bytecodeInterpreter_zero.cpp ! src/cpu/zero/vm/bytecodeInterpreter_zero.hpp ! src/cpu/zero/vm/bytecodeInterpreter_zero.inline.hpp ! src/cpu/zero/vm/bytecodes_zero.cpp ! src/cpu/zero/vm/bytecodes_zero.hpp ! src/cpu/zero/vm/bytes_zero.hpp ! src/cpu/zero/vm/codeBuffer_zero.hpp ! src/cpu/zero/vm/copy_zero.hpp ! src/cpu/zero/vm/cppInterpreterGenerator_zero.hpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp ! src/cpu/zero/vm/debug_zero.cpp ! src/cpu/zero/vm/depChecker_zero.cpp ! src/cpu/zero/vm/depChecker_zero.hpp ! src/cpu/zero/vm/disassembler_zero.cpp ! src/cpu/zero/vm/disassembler_zero.hpp ! src/cpu/zero/vm/dump_zero.cpp ! src/cpu/zero/vm/entryFrame_zero.hpp ! src/cpu/zero/vm/entry_zero.hpp ! src/cpu/zero/vm/fakeStubFrame_zero.hpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.hpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/globalDefinitions_zero.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/cpu/zero/vm/icBuffer_zero.cpp ! src/cpu/zero/vm/icache_zero.cpp ! src/cpu/zero/vm/icache_zero.hpp ! src/cpu/zero/vm/interp_masm_zero.cpp ! src/cpu/zero/vm/interp_masm_zero.hpp ! src/cpu/zero/vm/interpreterFrame_zero.hpp ! src/cpu/zero/vm/interpreterGenerator_zero.hpp ! src/cpu/zero/vm/interpreterRT_zero.cpp ! src/cpu/zero/vm/interpreterRT_zero.hpp ! src/cpu/zero/vm/interpreter_zero.cpp ! src/cpu/zero/vm/interpreter_zero.hpp ! src/cpu/zero/vm/javaFrameAnchor_zero.hpp ! src/cpu/zero/vm/jniFastGetField_zero.cpp ! src/cpu/zero/vm/jniTypes_zero.hpp ! src/cpu/zero/vm/jni_zero.h ! src/cpu/zero/vm/methodHandles_zero.cpp ! src/cpu/zero/vm/nativeInst_zero.cpp ! src/cpu/zero/vm/nativeInst_zero.hpp ! src/cpu/zero/vm/registerMap_zero.hpp ! src/cpu/zero/vm/register_definitions_zero.cpp ! src/cpu/zero/vm/register_zero.cpp ! src/cpu/zero/vm/register_zero.hpp ! src/cpu/zero/vm/relocInfo_zero.cpp ! src/cpu/zero/vm/relocInfo_zero.hpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/cpu/zero/vm/sharkFrame_zero.hpp ! src/cpu/zero/vm/shark_globals_zero.hpp ! src/cpu/zero/vm/stack_zero.cpp ! src/cpu/zero/vm/stack_zero.hpp ! src/cpu/zero/vm/stack_zero.inline.hpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/cpu/zero/vm/stubRoutines_zero.cpp ! src/cpu/zero/vm/stubRoutines_zero.hpp ! src/cpu/zero/vm/templateInterpreterGenerator_zero.hpp ! src/cpu/zero/vm/templateInterpreter_zero.cpp ! src/cpu/zero/vm/templateInterpreter_zero.hpp ! src/cpu/zero/vm/templateTable_zero.cpp ! src/cpu/zero/vm/templateTable_zero.hpp ! src/cpu/zero/vm/vmStructs_zero.hpp ! src/cpu/zero/vm/vm_version_zero.cpp ! src/cpu/zero/vm/vm_version_zero.hpp ! src/cpu/zero/vm/vmreg_zero.cpp ! src/cpu/zero/vm/vmreg_zero.hpp ! src/cpu/zero/vm/vmreg_zero.inline.hpp ! src/cpu/zero/vm/vtableStubs_zero.cpp ! src/os/linux/launcher/java.c ! src/os/linux/launcher/java.h ! src/os/linux/launcher/java_md.c ! src/os/linux/launcher/java_md.h ! src/os/linux/vm/attachListener_linux.cpp ! src/os/linux/vm/c1_globals_linux.hpp ! src/os/linux/vm/c2_globals_linux.hpp ! src/os/linux/vm/chaitin_linux.cpp ! src/os/linux/vm/dtraceJSDT_linux.cpp ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/hpi_linux.cpp ! src/os/linux/vm/hpi_linux.hpp ! src/os/linux/vm/interfaceSupport_linux.hpp ! src/os/linux/vm/jsig.c ! src/os/linux/vm/jvm_linux.cpp ! src/os/linux/vm/jvm_linux.h ! src/os/linux/vm/mutex_linux.cpp ! src/os/linux/vm/mutex_linux.inline.hpp ! src/os/linux/vm/osThread_linux.cpp ! src/os/linux/vm/osThread_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/linux/vm/os_share_linux.hpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/linux/vm/stubRoutines_linux.cpp ! src/os/linux/vm/threadCritical_linux.cpp ! src/os/linux/vm/thread_linux.inline.hpp ! src/os/linux/vm/vmError_linux.cpp ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/generateJvmOffsets.h ! src/os/solaris/dtrace/generateJvmOffsetsMain.c ! src/os/solaris/dtrace/jvm_dtrace.c ! src/os/solaris/dtrace/jvm_dtrace.h ! src/os/solaris/dtrace/libjvm_db.h ! src/os/solaris/launcher/java.c ! src/os/solaris/launcher/java.h ! src/os/solaris/launcher/java_md.c ! src/os/solaris/launcher/java_md.h ! src/os/solaris/vm/attachListener_solaris.cpp ! src/os/solaris/vm/c1_globals_solaris.hpp ! src/os/solaris/vm/c2_globals_solaris.hpp ! src/os/solaris/vm/chaitin_solaris.cpp ! src/os/solaris/vm/dtraceJSDT_solaris.cpp ! src/os/solaris/vm/globals_solaris.hpp ! src/os/solaris/vm/hpi_solaris.cpp ! src/os/solaris/vm/hpi_solaris.hpp ! src/os/solaris/vm/interfaceSupport_solaris.hpp ! src/os/solaris/vm/jsig.c ! src/os/solaris/vm/jvm_solaris.cpp ! src/os/solaris/vm/jvm_solaris.h ! src/os/solaris/vm/mutex_solaris.cpp ! src/os/solaris/vm/mutex_solaris.inline.hpp ! src/os/solaris/vm/osThread_solaris.cpp ! src/os/solaris/vm/osThread_solaris.hpp ! src/os/solaris/vm/os_share_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/solaris/vm/stubRoutines_solaris.cpp ! src/os/solaris/vm/threadCritical_solaris.cpp ! src/os/solaris/vm/thread_solaris.inline.hpp ! src/os/solaris/vm/vmError_solaris.cpp ! src/os/windows/vm/attachListener_windows.cpp ! src/os/windows/vm/c1_globals_windows.hpp ! src/os/windows/vm/c2_globals_windows.hpp ! src/os/windows/vm/chaitin_windows.cpp ! src/os/windows/vm/dtraceJSDT_windows.cpp ! src/os/windows/vm/globals_windows.hpp ! src/os/windows/vm/hpi_windows.cpp ! src/os/windows/vm/hpi_windows.hpp ! src/os/windows/vm/interfaceSupport_windows.hpp ! src/os/windows/vm/jvm_windows.cpp ! src/os/windows/vm/jvm_windows.h ! src/os/windows/vm/mutex_windows.cpp ! src/os/windows/vm/mutex_windows.inline.hpp ! src/os/windows/vm/osThread_windows.cpp ! src/os/windows/vm/osThread_windows.hpp ! src/os/windows/vm/os_share_windows.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/os/windows/vm/os_windows.inline.hpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/os/windows/vm/stubRoutines_windows.cpp ! src/os/windows/vm/threadCritical_windows.cpp ! src/os/windows/vm/thread_windows.inline.hpp ! src/os/windows/vm/vmError_windows.cpp ! 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/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/os_cpu/linux_x86/vm/assembler_linux_x86.cpp ! src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/bytes_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/copy_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp ! src/os_cpu/linux_x86/vm/prefetch_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/threadLS_linux_x86.cpp ! src/os_cpu/linux_x86/vm/threadLS_linux_x86.hpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.hpp ! src/os_cpu/linux_x86/vm/vmStructs_linux_x86.hpp ! src/os_cpu/linux_x86/vm/vm_version_linux_x86.cpp ! src/os_cpu/linux_zero/vm/assembler_linux_zero.cpp ! src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp ! src/os_cpu/linux_zero/vm/bytes_linux_zero.inline.hpp ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp ! src/os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.hpp ! src/os_cpu/linux_zero/vm/prefetch_linux_zero.inline.hpp ! src/os_cpu/linux_zero/vm/threadLS_linux_zero.cpp ! src/os_cpu/linux_zero/vm/threadLS_linux_zero.hpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.cpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.hpp ! src/os_cpu/linux_zero/vm/vmStructs_linux_zero.hpp ! src/os_cpu/linux_zero/vm/vm_version_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp ! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.hpp ! src/os_cpu/solaris_sparc/vm/prefetch_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/threadLS_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/threadLS_solaris_sparc.hpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.hpp ! src/os_cpu/solaris_sparc/vm/vmStructs_solaris_sparc.hpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/bytes_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/copy_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp ! src/os_cpu/solaris_x86/vm/prefetch_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/threadLS_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/threadLS_solaris_x86.hpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.hpp ! src/os_cpu/solaris_x86/vm/vmStructs_solaris_x86.hpp ! src/os_cpu/solaris_x86/vm/vm_version_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp ! src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/bytes_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/copy_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp ! src/os_cpu/windows_x86/vm/prefetch_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/threadLS_windows_x86.cpp ! src/os_cpu/windows_x86/vm/threadLS_windows_x86.hpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.hpp ! src/os_cpu/windows_x86/vm/unwind_windows_x86.hpp ! src/os_cpu/windows_x86/vm/vmStructs_windows_x86.hpp ! src/os_cpu/windows_x86/vm/vm_version_windows_x86.cpp - src/share/tools/MakeDeps/ArgsParser.java - src/share/tools/MakeDeps/BuildConfig.java - src/share/tools/MakeDeps/Database.java - src/share/tools/MakeDeps/DirectoryTree.java - src/share/tools/MakeDeps/DirectoryTreeNode.java - src/share/tools/MakeDeps/FileFormatException.java - src/share/tools/MakeDeps/FileList.java - src/share/tools/MakeDeps/FileName.java - src/share/tools/MakeDeps/Macro.java - src/share/tools/MakeDeps/MacroDefinitions.java - src/share/tools/MakeDeps/MakeDeps.java - src/share/tools/MakeDeps/MetroWerksMacPlatform.java - src/share/tools/MakeDeps/Platform.java - src/share/tools/MakeDeps/UnixPlatform.java - src/share/tools/MakeDeps/Util.java - src/share/tools/MakeDeps/WinGammaPlatform.java - src/share/tools/MakeDeps/WinGammaPlatformVC6.java - src/share/tools/MakeDeps/WinGammaPlatformVC7.java - src/share/tools/MakeDeps/WinGammaPlatformVC8.java - src/share/tools/MakeDeps/WinGammaPlatformVC9.java + src/share/tools/ProjectCreator/ArgsParser.java + src/share/tools/ProjectCreator/BuildConfig.java + src/share/tools/ProjectCreator/DirectoryTree.java + src/share/tools/ProjectCreator/DirectoryTreeNode.java + src/share/tools/ProjectCreator/FileFormatException.java + src/share/tools/ProjectCreator/Macro.java + src/share/tools/ProjectCreator/MacroDefinitions.java + src/share/tools/ProjectCreator/ProjectCreator.java + src/share/tools/ProjectCreator/Util.java + src/share/tools/ProjectCreator/WinGammaPlatform.java + src/share/tools/ProjectCreator/WinGammaPlatformVC6.java + src/share/tools/ProjectCreator/WinGammaPlatformVC7.java + src/share/tools/ProjectCreator/WinGammaPlatformVC8.java + src/share/tools/ProjectCreator/WinGammaPlatformVC9.java ! src/share/tools/hsdis/hsdis-demo.c ! src/share/tools/hsdis/hsdis.c ! src/share/tools/hsdis/hsdis.h ! src/share/vm/adlc/adlc.hpp ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/archDesc.hpp ! src/share/vm/adlc/arena.cpp ! src/share/vm/adlc/arena.hpp ! src/share/vm/adlc/dfa.cpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/dict2.hpp ! src/share/vm/adlc/filebuff.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formsopt.cpp ! src/share/vm/adlc/formsopt.hpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/main.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/assembler.inline.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/asm/register.cpp ! src/share/vm/asm/register.hpp ! src/share/vm/c1/c1_CFGPrinter.cpp ! src/share/vm/c1/c1_CFGPrinter.hpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_Compiler.hpp ! src/share/vm/c1/c1_Defs.cpp ! 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_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/c1/c1_MacroAssembler.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_Optimizer.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/c1/c1_ValueMap.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/c1/c1_ValueSet.cpp ! src/share/vm/c1/c1_ValueSet.hpp ! src/share/vm/c1/c1_ValueStack.cpp ! src/share/vm/c1/c1_ValueStack.hpp ! src/share/vm/c1/c1_ValueType.cpp ! src/share/vm/c1/c1_ValueType.hpp ! src/share/vm/c1/c1_globals.cpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp ! src/share/vm/ci/ciArray.cpp ! src/share/vm/ci/ciArray.hpp ! src/share/vm/ci/ciArrayKlass.cpp ! src/share/vm/ci/ciArrayKlass.hpp ! src/share/vm/ci/ciArrayKlassKlass.hpp ! src/share/vm/ci/ciCPCache.cpp ! src/share/vm/ci/ciCPCache.hpp ! src/share/vm/ci/ciCallProfile.hpp ! src/share/vm/ci/ciCallSite.cpp ! src/share/vm/ci/ciCallSite.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciConstant.cpp ! src/share/vm/ci/ciConstant.hpp ! src/share/vm/ci/ciConstantPoolCache.cpp ! src/share/vm/ci/ciConstantPoolCache.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciExceptionHandler.cpp ! src/share/vm/ci/ciExceptionHandler.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/ci/ciFlags.cpp ! src/share/vm/ci/ciFlags.hpp ! src/share/vm/ci/ciInstance.cpp ! src/share/vm/ci/ciInstance.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciInstanceKlassKlass.cpp ! src/share/vm/ci/ciInstanceKlassKlass.hpp ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/ci/ciKlass.hpp ! src/share/vm/ci/ciKlassKlass.cpp ! src/share/vm/ci/ciKlassKlass.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodBlocks.cpp ! src/share/vm/ci/ciMethodBlocks.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/ci/ciMethodKlass.cpp ! src/share/vm/ci/ciMethodKlass.hpp ! src/share/vm/ci/ciNullObject.cpp ! src/share/vm/ci/ciNullObject.hpp ! src/share/vm/ci/ciObjArray.cpp ! src/share/vm/ci/ciObjArray.hpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObjArrayKlass.hpp ! src/share/vm/ci/ciObjArrayKlassKlass.cpp ! src/share/vm/ci/ciObjArrayKlassKlass.hpp ! src/share/vm/ci/ciObject.cpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/ci/ciSymbolKlass.cpp ! src/share/vm/ci/ciSymbolKlass.hpp ! src/share/vm/ci/ciType.cpp ! src/share/vm/ci/ciType.hpp ! src/share/vm/ci/ciTypeArray.cpp ! src/share/vm/ci/ciTypeArray.hpp ! src/share/vm/ci/ciTypeArrayKlass.cpp ! src/share/vm/ci/ciTypeArrayKlass.hpp ! src/share/vm/ci/ciTypeArrayKlassKlass.cpp ! src/share/vm/ci/ciTypeArrayKlassKlass.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/ci/ciUtilities.cpp ! src/share/vm/ci/ciUtilities.hpp ! src/share/vm/ci/compilerInterface.hpp ! src/share/vm/classfile/classFileError.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classFileStream.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/javaAssertions.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! 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/stackMapTableFormat.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verificationType.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/code/compressedStream.cpp ! src/share/vm/code/compressedStream.hpp ! src/share/vm/code/debugInfo.cpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/debugInfoRec.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/dependencies.hpp ! src/share/vm/code/exceptionHandlerTable.cpp ! src/share/vm/code/exceptionHandlerTable.hpp ! src/share/vm/code/icBuffer.cpp ! src/share/vm/code/icBuffer.hpp ! src/share/vm/code/location.cpp ! src/share/vm/code/location.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/oopRecorder.cpp ! src/share/vm/code/oopRecorder.hpp ! src/share/vm/code/pcDesc.cpp ! src/share/vm/code/pcDesc.hpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/code/scopeDesc.hpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/code/vmreg.cpp ! src/share/vm/code/vmreg.hpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/compiler/abstractCompiler.cpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/compiler/compileLog.cpp ! 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/compiler/methodLiveness.cpp ! src/share/vm/compiler/methodLiveness.hpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/compiler/oopMap.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsGCAdaptivePolicyCounters.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsGCAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsLockVerifier.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsLockVerifier.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.inline.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.inline.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/gc_implementation/g1/bufferingOopClosure.hpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.inline.hpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.cpp ! src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.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/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.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.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.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/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/g1/survRateGroup.cpp ! src/share/vm/gc_implementation/g1/survRateGroup.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp - src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep - src/share/vm/gc_implementation/includeDB_gc_g1 - src/share/vm/gc_implementation/includeDB_gc_parNew - src/share/vm/gc_implementation/includeDB_gc_parallelScavenge - src/share/vm/gc_implementation/includeDB_gc_serial - src/share/vm/gc_implementation/includeDB_gc_shared ! src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parNew/parOopClosures.hpp ! src/share/vm/gc_implementation/parNew/parOopClosures.inline.hpp ! src/share/vm/gc_implementation/parNew/vmStructs_parNew.hpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.hpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp ! src/share/vm/gc_implementation/parallelScavenge/adjoiningVirtualSpaces.hpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.hpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.hpp ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.cpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psGCAdaptivePolicyCounters.cpp ! src/share/vm/gc_implementation/parallelScavenge/psGCAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/parallelScavenge/psGenerationCounters.cpp ! src/share/vm/gc_implementation/parallelScavenge/psGenerationCounters.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.hpp ! 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/psPromotionLAB.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.hpp ! src/share/vm/gc_implementation/parallelScavenge/vmStructs_parallelgc.hpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/shared/ageTable.cpp ! src/share/vm/gc_implementation/shared/ageTable.hpp ! src/share/vm/gc_implementation/shared/allocationStats.cpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/gc_implementation/shared/cSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/cSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/collectorCounters.cpp ! src/share/vm/gc_implementation/shared/collectorCounters.hpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.hpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/gcAdaptivePolicyCounters.cpp ! src/share/vm/gc_implementation/shared/gcAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/shared/gcPolicyCounters.cpp ! src/share/vm/gc_implementation/shared/gcPolicyCounters.hpp ! src/share/vm/gc_implementation/shared/gcStats.cpp ! src/share/vm/gc_implementation/shared/gcStats.hpp ! src/share/vm/gc_implementation/shared/gcUtil.cpp ! src/share/vm/gc_implementation/shared/gcUtil.hpp ! src/share/vm/gc_implementation/shared/generationCounters.cpp ! src/share/vm/gc_implementation/shared/generationCounters.hpp ! src/share/vm/gc_implementation/shared/immutableSpace.cpp ! src/share/vm/gc_implementation/shared/immutableSpace.hpp ! src/share/vm/gc_implementation/shared/isGCActiveMark.hpp ! src/share/vm/gc_implementation/shared/liveRange.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.hpp ! src/share/vm/gc_implementation/shared/spaceCounters.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.hpp ! src/share/vm/gc_implementation/shared/spaceDecorator.cpp ! src/share/vm/gc_implementation/shared/spaceDecorator.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/gc_interface/gcCause.cpp ! src/share/vm/gc_interface/gcCause.hpp - src/share/vm/includeDB_compiler1 - src/share/vm/includeDB_compiler2 - src/share/vm/includeDB_core - src/share/vm/includeDB_features - src/share/vm/includeDB_gc - src/share/vm/includeDB_gc_parallel - src/share/vm/includeDB_jvmti - src/share/vm/includeDB_shark - src/share/vm/includeDB_zero ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeHistogram.cpp ! src/share/vm/interpreter/bytecodeHistogram.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp ! src/share/vm/interpreter/bytecodeInterpreterWithChecks.xsl ! src/share/vm/interpreter/bytecodeStream.cpp ! src/share/vm/interpreter/bytecodeStream.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/bytecodeTracer.hpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/cppInterpreter.cpp ! src/share/vm/interpreter/cppInterpreter.hpp ! src/share/vm/interpreter/cppInterpreterGenerator.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/interpreterGenerator.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/invocationCounter.cpp ! src/share/vm/interpreter/invocationCounter.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/oopMapCache.cpp ! src/share/vm/interpreter/oopMapCache.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/libadt/dict.cpp ! src/share/vm/libadt/dict.hpp ! src/share/vm/libadt/port.cpp ! src/share/vm/libadt/port.hpp ! src/share/vm/libadt/set.cpp ! src/share/vm/libadt/set.hpp ! src/share/vm/libadt/vectset.cpp ! src/share/vm/libadt/vectset.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/barrierSet.cpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/barrierSet.inline.hpp ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/blockOffsetTable.hpp ! src/share/vm/memory/blockOffsetTable.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/classify.cpp ! src/share/vm/memory/classify.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/memory/compactPermGen.hpp ! src/share/vm/memory/compactingPermGenGen.cpp ! src/share/vm/memory/compactingPermGenGen.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/defNewGeneration.inline.hpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/gcLocker.inline.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genMarkSweep.hpp ! src/share/vm/memory/genOopClosures.hpp ! src/share/vm/memory/genOopClosures.inline.hpp ! src/share/vm/memory/genRemSet.cpp ! src/share/vm/memory/genRemSet.hpp ! src/share/vm/memory/genRemSet.inline.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/generation.inline.hpp ! src/share/vm/memory/generationSpec.cpp ! src/share/vm/memory/generationSpec.hpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/memRegion.cpp ! src/share/vm/memory/memRegion.hpp ! src/share/vm/memory/modRefBarrierSet.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/permGen.cpp ! src/share/vm/memory/permGen.hpp ! src/share/vm/memory/referencePolicy.cpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/resourceArea.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/memory/restore.cpp ! src/share/vm/memory/serialize.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/space.inline.hpp ! src/share/vm/memory/specialized_oop_closures.cpp ! src/share/vm/memory/specialized_oop_closures.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/tenuredGeneration.hpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/memory/threadLocalAllocBuffer.inline.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/memory/universe.inline.hpp ! src/share/vm/memory/watermark.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/arrayKlassKlass.cpp ! src/share/vm/oops/arrayKlassKlass.hpp ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/oops/compiledICHolderKlass.cpp ! src/share/vm/oops/compiledICHolderKlass.hpp ! src/share/vm/oops/compiledICHolderOop.cpp ! src/share/vm/oops/compiledICHolderOop.hpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constMethodKlass.hpp ! src/share/vm/oops/constMethodOop.cpp ! src/share/vm/oops/constMethodOop.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolKlass.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/cpCacheKlass.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/generateOopMap.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceKlassKlass.hpp ! src/share/vm/oops/instanceOop.cpp ! src/share/vm/oops/instanceOop.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/instanceRefKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klass.inline.hpp ! src/share/vm/oops/klassKlass.cpp ! src/share/vm/oops/klassKlass.hpp ! src/share/vm/oops/klassOop.cpp ! src/share/vm/oops/klassOop.hpp ! src/share/vm/oops/klassPS.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/markOop.cpp ! src/share/vm/oops/markOop.hpp ! src/share/vm/oops/markOop.inline.hpp ! src/share/vm/oops/methodDataKlass.cpp ! src/share/vm/oops/methodDataKlass.hpp ! src/share/vm/oops/methodDataOop.cpp ! src/share/vm/oops/methodDataOop.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodKlass.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/objArrayKlass.inline.hpp ! src/share/vm/oops/objArrayKlassKlass.cpp ! src/share/vm/oops/objArrayKlassKlass.hpp ! src/share/vm/oops/objArrayOop.cpp ! src/share/vm/oops/objArrayOop.hpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oop.inline2.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp ! src/share/vm/oops/oop.psgc.inline.hpp ! src/share/vm/oops/oopsHierarchy.cpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/oops/symbolKlass.cpp ! src/share/vm/oops/symbolKlass.hpp ! src/share/vm/oops/symbolOop.cpp ! src/share/vm/oops/symbolOop.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.hpp ! src/share/vm/oops/typeArrayKlassKlass.cpp ! src/share/vm/oops/typeArrayKlassKlass.hpp ! src/share/vm/oops/typeArrayOop.cpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/addnode.hpp ! src/share/vm/opto/adlcVMDeps.hpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2_globals.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/c2compiler.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/classes.cpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/coalesce.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/divnode.cpp ! src/share/vm/opto/divnode.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/idealGraphPrinter.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/indexSet.cpp ! src/share/vm/opto/indexSet.hpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/live.hpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! 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/machnode.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/mulnode.hpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/multnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/opcodes.cpp ! src/share/vm/opto/opcodes.hpp ! src/share/vm/opto/optoreg.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/regalloc.cpp ! src/share/vm/opto/regalloc.hpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp ! src/share/vm/opto/rootnode.cpp ! src/share/vm/opto/rootnode.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/opto/split_if.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/opto/stringopts.hpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/subnode.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp + src/share/vm/precompiled.hpp ! src/share/vm/prims/evmCompat.cpp ! src/share/vm/prims/forte.cpp ! src/share/vm/prims/forte.hpp ! src/share/vm/prims/hpi_imported.h ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jni.h ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jniCheck.hpp ! src/share/vm/prims/jniFastGetField.cpp ! src/share/vm/prims/jniFastGetField.hpp ! src/share/vm/prims/jni_md.h ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/jvmtiAgentThread.hpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.hpp ! src/share/vm/prims/jvmtiEnter.hpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnv.xsl ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiEnvThreadState.cpp ! src/share/vm/prims/jvmtiEnvThreadState.hpp ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiEventController.hpp ! src/share/vm/prims/jvmtiEventController.inline.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiExtensions.cpp ! src/share/vm/prims/jvmtiExtensions.hpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp ! src/share/vm/prims/jvmtiGetLoadedClasses.hpp ! src/share/vm/prims/jvmtiHpp.xsl ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiManageCapabilities.cpp ! src/share/vm/prims/jvmtiManageCapabilities.hpp ! src/share/vm/prims/jvmtiRawMonitor.cpp ! src/share/vm/prims/jvmtiRawMonitor.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/prims/jvmtiRedefineClassesTrace.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/prims/jvmtiThreadState.cpp ! src/share/vm/prims/jvmtiThreadState.hpp ! src/share/vm/prims/jvmtiThreadState.inline.hpp ! src/share/vm/prims/jvmtiTrace.cpp ! src/share/vm/prims/jvmtiTrace.hpp ! src/share/vm/prims/jvmtiUtil.cpp ! src/share/vm/prims/jvmtiUtil.hpp ! src/share/vm/prims/methodComparator.cpp ! src/share/vm/prims/methodComparator.hpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/nativeLookup.hpp ! src/share/vm/prims/perf.cpp ! src/share/vm/prims/privilegedStack.cpp ! src/share/vm/prims/privilegedStack.hpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/aprofiler.cpp ! src/share/vm/runtime/aprofiler.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/basicLock.cpp ! src/share/vm/runtime/basicLock.hpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/biasedLocking.hpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/dtraceJSDT.cpp ! src/share/vm/runtime/dtraceJSDT.hpp ! src/share/vm/runtime/extendedPC.hpp ! src/share/vm/runtime/fieldDescriptor.cpp ! 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.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/frame.inline.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/hpi.cpp ! src/share/vm/runtime/hpi.hpp ! src/share/vm/runtime/icache.cpp ! src/share/vm/runtime/icache.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/init.hpp ! src/share/vm/runtime/interfaceSupport.cpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/javaFrameAnchor.hpp ! src/share/vm/runtime/jfieldIDWorkaround.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/jniHandles.hpp ! src/share/vm/runtime/jniPeriodicChecker.cpp ! src/share/vm/runtime/jniPeriodicChecker.hpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/memprofiler.hpp ! src/share/vm/runtime/monitorChunk.cpp ! src/share/vm/runtime/monitorChunk.hpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/mutex.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/objectMonitor.inline.hpp ! src/share/vm/runtime/orderAccess.cpp ! src/share/vm/runtime/orderAccess.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/osThread.cpp ! src/share/vm/runtime/osThread.hpp ! src/share/vm/runtime/park.cpp ! src/share/vm/runtime/park.hpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/perfData.hpp ! src/share/vm/runtime/perfMemory.cpp ! src/share/vm/runtime/perfMemory.hpp ! src/share/vm/runtime/prefetch.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp ! src/share/vm/runtime/reflectionCompat.hpp ! src/share/vm/runtime/reflectionUtils.cpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/registerMap.hpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/runtime/relocator.hpp ! src/share/vm/runtime/rframe.cpp ! src/share/vm/runtime/rframe.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/sharedRuntimeTrans.cpp ! src/share/vm/runtime/sharedRuntimeTrig.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp ! src/share/vm/runtime/simpleThresholdPolicy.inline.hpp ! src/share/vm/runtime/stackValue.cpp ! src/share/vm/runtime/stackValue.hpp ! src/share/vm/runtime/stackValueCollection.cpp ! src/share/vm/runtime/stackValueCollection.hpp ! src/share/vm/runtime/statSampler.cpp ! src/share/vm/runtime/statSampler.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/stubCodeGenerator.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/synchronizer.hpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/task.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/threadCritical.hpp ! src/share/vm/runtime/threadLocalStorage.cpp ! src/share/vm/runtime/threadLocalStorage.hpp ! src/share/vm/runtime/timer.cpp ! src/share/vm/runtime/timer.hpp ! src/share/vm/runtime/unhandledOops.cpp ! src/share/vm/runtime/unhandledOops.hpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframe.hpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vframeArray.hpp ! src/share/vm/runtime/vframe_hp.cpp ! src/share/vm/runtime/vframe_hp.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmStructs.hpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.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/classLoadingService.hpp ! src/share/vm/services/dtraceAttacher.cpp ! src/share/vm/services/dtraceAttacher.hpp ! src/share/vm/services/g1MemoryPool.cpp ! src/share/vm/services/g1MemoryPool.hpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/heapDumper.hpp ! src/share/vm/services/jmm.h ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/services/lowMemoryDetector.hpp ! src/share/vm/services/management.cpp ! src/share/vm/services/management.hpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp ! src/share/vm/services/memoryUsage.hpp ! src/share/vm/services/psMemoryPool.cpp ! src/share/vm/services/psMemoryPool.hpp ! src/share/vm/services/runtimeService.cpp ! src/share/vm/services/runtimeService.hpp ! src/share/vm/services/serviceUtil.hpp ! src/share/vm/services/threadService.cpp ! src/share/vm/services/threadService.hpp ! src/share/vm/shark/llvmHeaders.hpp ! src/share/vm/shark/llvmValue.hpp ! src/share/vm/shark/sharkBlock.cpp ! src/share/vm/shark/sharkBlock.hpp ! src/share/vm/shark/sharkBuilder.cpp ! src/share/vm/shark/sharkBuilder.hpp ! src/share/vm/shark/sharkCacheDecache.cpp ! src/share/vm/shark/sharkCacheDecache.hpp ! src/share/vm/shark/sharkCodeBuffer.hpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkCompiler.hpp ! src/share/vm/shark/sharkConstant.cpp ! src/share/vm/shark/sharkConstant.hpp ! src/share/vm/shark/sharkContext.cpp ! src/share/vm/shark/sharkContext.hpp ! src/share/vm/shark/sharkEntry.hpp ! src/share/vm/shark/sharkFunction.cpp ! src/share/vm/shark/sharkFunction.hpp ! src/share/vm/shark/sharkInliner.cpp ! src/share/vm/shark/sharkInliner.hpp ! src/share/vm/shark/sharkIntrinsics.cpp ! src/share/vm/shark/sharkIntrinsics.hpp ! src/share/vm/shark/sharkInvariants.cpp ! src/share/vm/shark/sharkInvariants.hpp ! src/share/vm/shark/sharkMemoryManager.cpp ! src/share/vm/shark/sharkMemoryManager.hpp ! src/share/vm/shark/sharkNativeWrapper.cpp ! src/share/vm/shark/sharkNativeWrapper.hpp ! src/share/vm/shark/sharkRuntime.cpp ! src/share/vm/shark/sharkRuntime.hpp ! src/share/vm/shark/sharkStack.cpp ! src/share/vm/shark/sharkStack.hpp ! src/share/vm/shark/sharkState.cpp ! src/share/vm/shark/sharkState.hpp ! src/share/vm/shark/sharkStateScanner.cpp ! src/share/vm/shark/sharkStateScanner.hpp ! src/share/vm/shark/sharkTopLevelBlock.cpp ! src/share/vm/shark/sharkTopLevelBlock.hpp ! src/share/vm/shark/sharkType.hpp ! src/share/vm/shark/sharkValue.cpp ! src/share/vm/shark/sharkValue.hpp ! src/share/vm/shark/shark_globals.cpp ! src/share/vm/shark/shark_globals.hpp ! src/share/vm/utilities/accessFlags.cpp ! src/share/vm/utilities/accessFlags.hpp ! src/share/vm/utilities/array.cpp ! src/share/vm/utilities/array.hpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/bitMap.hpp ! src/share/vm/utilities/bitMap.inline.hpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp ! src/share/vm/utilities/copy.cpp ! src/share/vm/utilities/copy.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/defaultStream.hpp ! src/share/vm/utilities/dtrace.hpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/globalDefinitions.cpp ! src/share/vm/utilities/globalDefinitions.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/growableArray.cpp ! src/share/vm/utilities/growableArray.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/hashtable.inline.hpp ! src/share/vm/utilities/histogram.cpp ! src/share/vm/utilities/histogram.hpp ! src/share/vm/utilities/intHisto.cpp ! src/share/vm/utilities/intHisto.hpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/numberSeq.cpp ! src/share/vm/utilities/numberSeq.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp ! src/share/vm/utilities/preserveException.cpp ! src/share/vm/utilities/preserveException.hpp ! src/share/vm/utilities/sizes.cpp ! src/share/vm/utilities/sizes.hpp ! src/share/vm/utilities/stack.hpp ! src/share/vm/utilities/stack.inline.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/top.hpp ! src/share/vm/utilities/utf8.cpp ! src/share/vm/utilities/utf8.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/xmlstream.cpp ! src/share/vm/utilities/xmlstream.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp From john.r.rose at oracle.com Wed Nov 24 23:42:50 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 24 Nov 2010 23:42:50 -0800 Subject: review request (L): 7001379: bootstrap method data needs to be moved from constant pool to a classfile attribute Message-ID: <080DC5F8-ADA6-47F2-845D-779C2019D175@oracle.com> On Nov 22, 2010, at 6:57 PM, John Rose wrote: > Because of a strong and reasonable request from the IBM JVM team, the JSR 292 class file format for CONSTANT_InvokeDynamic is changing one more time. > ... > I will be putting out a review request soon for this. Here is a JVM change which moves the variadic parts of CONSTANT_InvokeDynamic specifiers out of the constant pool and into a new attribute, BootstrapMethods. http://cr.openjdk.java.net/~jrose/7001379/webrev.hs.00 For review, here is the specification change, in the javadoc in the jdk repo: http://cr.openjdk.java.net/~jrose/7001379/webrev.jdk.00 The JDK webrev also includes an adjusted unit test. The base revision was reviewed by Christian yesterday: http://cr.openjdk.java.net/~jrose/7001423/webrev.00 The JVM code passes the unit test, of course. -- John From christian.thalinger at oracle.com Thu Nov 25 02:27:43 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 25 Nov 2010 11:27:43 +0100 Subject: review request (L): 7001379: bootstrap method data needs to be moved from constant pool to a classfile attribute In-Reply-To: <080DC5F8-ADA6-47F2-845D-779C2019D175@oracle.com> References: <080DC5F8-ADA6-47F2-845D-779C2019D175@oracle.com> Message-ID: On Nov 25, 2010, at 8:42 AM, John Rose wrote: > On Nov 22, 2010, at 6:57 PM, John Rose wrote: > >> Because of a strong and reasonable request from the IBM JVM team, the JSR 292 class file format for CONSTANT_InvokeDynamic is changing one more time. >> ... >> I will be putting out a review request soon for this. > > > Here is a JVM change which moves the variadic parts of CONSTANT_InvokeDynamic specifiers out of the constant pool and into a new attribute, BootstrapMethods. > http://cr.openjdk.java.net/~jrose/7001379/webrev.hs.00 src/share/vm/classfile/classFileParser.hpp: + //@@ static int start_operand_group(GrowableArray* &operands, int op_count, TRAPS); + //@@ static void store_operand_array(GrowableArray* operands, constantPoolHandle cp, TRAPS); Do we still need them? src/share/vm/oops/constantPoolOop.hpp: - void copy_entry_to(int from_i, constantPoolHandle to_cp, int to_i, TRAPS); + static void copy_entry_to(constantPoolHandle from_cp, int from_i, constantPoolHandle to_cp, int to_i, TRAPS); Maybe I'm missing the obvious here but why do need to pass a handle in? There is nothing fancy going on in that method. > > For review, here is the specification change, in the javadoc in the jdk repo: > http://cr.openjdk.java.net/~jrose/7001379/webrev.jdk.00 301 * Each {@code CONSTANT_InvokeDynamic} entry refers has a reference to a 302 * bootstrap method specifier defined in a separate array. I think there are some superfluous words. 317 * {@code BootstrapMethods} attribute. In particular, each cosntant Typo. > > The JDK webrev also includes an adjusted unit test. > > The base revision was reviewed by Christian yesterday: > http://cr.openjdk.java.net/~jrose/7001423/webrev.00 > > The JVM code passes the unit test, of course. -- Christian From igor.veresov at oracle.com Thu Nov 25 07:03:24 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 25 Nov 2010 07:03:24 -0800 Subject: Request for review(XL): 6985015: C1 needs to support compressed oops In-Reply-To: <4CE5EB17.3090503@oracle.com> References: <4CE5EB17.3090503@oracle.com> Message-ID: <4CEE7ABC.3040709@oracle.com> I've updated the webrev with includeDB changes and also removed unnecessary ifdefs. Webrev: http://cr.openjdk.java.net/~iveresov/6985015/webrev.02/ igor On 11/18/10 7:12 PM, Igor Veresov wrote: > This change implements compressed oops for C1 for x64 and sparc. > The changes are mostly on the codegen level, with a few exceptions when > we do access things outside of the heap that are uncompressed from the IR. > > Webrev: http://cr.openjdk.java.net/~iveresov/6985015/webrev.00/ > > Thanks, > igor From christian.thalinger at oracle.com Thu Nov 25 07:57:55 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 25 Nov 2010 16:57:55 +0100 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC In-Reply-To: <4CE57EC1.30404@oracle.com> References: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> <4CDDA15E.6030603@oracle.com> <025DDC98-A2FD-458C-B55A-3D31A531D298@oracle.com> <4CE1B855.6020603@oracle.com> <4CE2C0EA.7090208@oracle.com> <5A90B778-D3D3-4494-BE64-6E29FF0D4F7A@oracle.com> <4CE57EC1.30404@oracle.com> Message-ID: On Nov 18, 2010, at 8:30 PM, Vladimir Kozlov wrote: > Christian, > > I like this code better but I still think that we should have a flag > which controls how we load constant oops and longs. > We may do it by just adding predicate(flag) into .ad file. Could you, > please, check? And yes, we may need to keep some code you removed. Done. > > Instead of using new flag ConstantTableAbsoluteAddressing (we have more > flags than we need already) you should use Matcher's variable like next: > > const bool Matcher::clone_shift_expressions = true; Good idea. I didn't like the flag either. > > I don't understand how MachConstantBaseNode::size() is not called > on sparc where there is code generated for it? You need the size. > It seems, you have to calculate it manually. SPARC does not use Compile::Shorten_branches and that's the only place where I got calls to size. > > I think you don't need to add_req() in constructor and then use > set_req(root) since new MachConstantBase node is only created in > Compile::mach_constant_base_node() so you can add_req(root) there OK. I will send out a review later or tomorrow. -- Christian From vladimir.kozlov at oracle.com Thu Nov 25 11:38:54 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 25 Nov 2010 11:38:54 -0800 Subject: Request for review(XL): 6985015: C1 needs to support compressed oops In-Reply-To: <4CEE7ABC.3040709@oracle.com> References: <4CE5EB17.3090503@oracle.com> <4CEE7ABC.3040709@oracle.com> Message-ID: <4CEEBB4E.4020105@oracle.com> Igor, I don't like adding new br instructions which are used only 4 times. Could you simple totally separate code for COOP and use corresponding br (icc) instructions? Also there are no explanation/comments around new move_wide code. Why you need it (append()?) ? I am not C1 expert so it is not clear to me. Otherwise it is better then before. Thanks, Vladimir On 11/25/10 7:03 AM, Igor Veresov wrote: > I've updated the webrev with includeDB changes and also removed unnecessary ifdefs. > > Webrev: http://cr.openjdk.java.net/~iveresov/6985015/webrev.02/ > > igor > > On 11/18/10 7:12 PM, Igor Veresov wrote: >> This change implements compressed oops for C1 for x64 and sparc. >> The changes are mostly on the codegen level, with a few exceptions when >> we do access things outside of the heap that are uncompressed from the IR. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6985015/webrev.00/ >> >> Thanks, >> igor > From igor.veresov at oracle.com Fri Nov 26 21:14:54 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 26 Nov 2010 21:14:54 -0800 Subject: Request for review(XL): 6985015: C1 needs to support compressed oops In-Reply-To: <4CEEBB4E.4020105@oracle.com> References: <4CE5EB17.3090503@oracle.com> <4CEE7ABC.3040709@oracle.com> <4CEEBB4E.4020105@oracle.com> Message-ID: Vladimir, please find the answers inlined. Thanks, igor On Nov 25, 2010, at 11:38 AM, Vladimir Kozlov wrote: > Igor, > > I don't like adding new br instructions which are used only 4 times. > Could you simple totally separate code for COOP and use corresponding br (icc) instructions? > That was actually Tom's suggestion, or at least how I understood it. I was hoping it was elegant enough, but sure we can do just a separate version of this bunch of klass comparisons for coops and the regular version. > Also there are no explanation/comments around new move_wide code. Why you need it (append()?) ? I am not C1 expert so it is not clear to me. move_wide is needed to access references that is outside he heap (which are typically uncompressed) from LIR. Some fields in the Thread structure are a good example. append() is needed to add an operation to a LIR_List (which a list of instructions in a basic block). Any LIR operation will do that. > > Otherwise it is better then before. > > Thanks, > Vladimir > > On 11/25/10 7:03 AM, Igor Veresov wrote: >> I've updated the webrev with includeDB changes and also removed unnecessary ifdefs. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6985015/webrev.02/ >> >> igor >> >> On 11/18/10 7:12 PM, Igor Veresov wrote: >>> This change implements compressed oops for C1 for x64 and sparc. >>> The changes are mostly on the codegen level, with a few exceptions when >>> we do access things outside of the heap that are uncompressed from the IR. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/6985015/webrev.00/ >>> >>> Thanks, >>> igor >> From Paul.Thio at imc.nl Sat Nov 27 04:28:40 2010 From: Paul.Thio at imc.nl (P. Thio) Date: Sat, 27 Nov 2010 13:28:40 +0100 Subject: Escape Analysis and arrays Message-ID: <1290860920.23152.11.camel@perom> Here's is a case for Escape Analysis. When a array of a primitive type is indexed by a variable, the allocation of the array is no longer optimized. A small test case is attached. There are two similar programs. The main difference is: < s += b[i]; --- > switch (i) { > case 0: s += b[0]; break; > case 1: s += b[1]; break; > case 2: s += b[2]; break; > case 3: s += b[3]; break; > case 4: s += b[4]; break; > case 5: s += b[5]; break; > } For the second program the array allocation is eliminated. A log with more information and the Assembly output are included. Can for the first program the array allocation be optimized as well ? Paul ________________________________ The information in this e-mail is intended only for the person or entity to which it is addressed. It may contain confidential and /or privileged material. If someone other than the intended recipient should receive this e-mail, he / she shall not be entitled to read, disseminate, disclose or duplicate it. If you receive this e-mail unintentionally, please inform us immediately by "reply" and then delete it from your system. Although this information has been compiled with great care, neither IMC Financial Markets & Asset Management nor any of its related entities shall accept any responsibility for any errors, omissions or other inaccuracies in this information or for the consequences thereof, nor shall it be bound in any way by the contents of this e-mail or its attachments. In the event of incomplete or incorrect transmission, please return the e-mail to the sender and permanently delete this message and any attachments. Messages and attachments are scanned for all known viruses. Always scan attachments before opening them. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20101127/fce00cb6/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: files.tar Type: application/x-tar Size: 71680 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20101127/fce00cb6/attachment-0001.tar From puzzlesdj at gmail.com Sat Nov 27 05:14:01 2010 From: puzzlesdj at gmail.com (ddmetro) Date: Sat, 27 Nov 2010 05:14:01 -0800 (PST) Subject: help regarding 'thread allocation to cores' - in hotspot jvm In-Reply-To: <4CE97B06.4050806@oracle.com> References: <30271610.post@talk.nabble.com> <4CE97B06.4050806@oracle.com> Message-ID: <30318328.post@talk.nabble.com> Thanks Ramakrishna. I have modified the hotspot code, to alternately schedule threads on one of the two cores on my dual-core machine using the linux system call - pthread_setaffinity_np(). I also have a java program - that creates two threads - each of which print infinitely. With this as the input program to the hotspot code, I am expecting the 'System Monitor' to show equal loads(CPU Utilization) on both the cores. However, both the cores are being utilized equally - (i) without the code changes as well as (ii) with the code changes. 1. I am trying to come up with a test case (input java program), that performs well with my code (both cores being utilized) and performs less efficiently (under utilization of cores) when run without my changes. 2. I am trying to switch off OS level scheduling to show that my code changes improve the utilization of cores. Question: Kindly direct me, as to which of the above mentioned two approaches should I proceed with? Also, I tried switching off OS level scheduling in linux (ubuntu), but I am still struggling to figure it out. Kindly provide pointers as to how to proceed with it. OS: Linux Ubuntu 10.04 Thanking You for your time and patience, Dhiraj P. -- View this message in context: http://old.nabble.com/help-regarding-%27thread-allocation-to-cores%27---in-hotspot-jvm-tp30271610p30318328.html Sent from the OpenJDK Hotspot Compiler Development List mailing list archive at Nabble.com. From p.thio at xs4all.nl Sat Nov 27 06:34:19 2010 From: p.thio at xs4all.nl (Paul Thio) Date: Sat, 27 Nov 2010 15:34:19 +0100 Subject: Escape Analysis and arrays Message-ID: <06F33F36-21AC-4C6A-A64C-54A5B46D719B@xs4all.nl> Please ignore my previous mail about Escape Analysis. I found the answer in the jdk 7 notes: "After escape analysis, the server compiler eliminates scalar replaceable object allocations and associated locks from heap. The server compiler also eliminates locks for all non-globally escaping objects. It does not replace a heap allocation with a stack allocation for non-globally escaping objects." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20101127/06215e08/attachment.html From p.thio at xs4all.nl Mon Nov 29 11:58:59 2010 From: p.thio at xs4all.nl (Paul Thio) Date: Mon, 29 Nov 2010 20:58:59 +0100 Subject: Escape analysis Message-ID: <3726F160-2B0E-4E55-AFB4-852CDD367E21@xs4all.nl> Hello, I am wondering why in the following test program, the allocation at line 15 is not eliminated/replaced. Thanks, Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: Test.java Type: application/octet-stream Size: 1058 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20101129/6f75d615/attachment.obj From vladimir.kozlov at oracle.com Mon Nov 29 14:25:05 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 29 Nov 2010 14:25:05 -0800 Subject: Escape analysis In-Reply-To: <3726F160-2B0E-4E55-AFB4-852CDD367E21@xs4all.nl> References: <3726F160-2B0E-4E55-AFB4-852CDD367E21@xs4all.nl> Message-ID: <4CF42841.2040400@oracle.com> Paul, It is known problem and it is on our list of EA improvements. Object key (pointer to it) is used in Cmp instruction in HashMap.get(): if (e.hash == hash && ((k = e.key) == key || key.equals(k))) Thanks, Vladimir Paul Thio wrote: > Hello, > > I am wondering why in the following test program, the allocation at line 15 is not eliminated/replaced. > > Thanks, > > Paul > From igor.veresov at oracle.com Mon Nov 29 17:09:21 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 29 Nov 2010 17:09:21 -0800 Subject: Request for review(XL): 6985015: C1 needs to support compressed oops In-Reply-To: References: <4CE5EB17.3090503@oracle.com> <4CEE7ABC.3040709@oracle.com> <4CEEBB4E.4020105@oracle.com> Message-ID: <4CF44EC1.2050101@oracle.com> Vladimir, I've removed the new br instructions and separated the type verfication code for coops in arraycopy. Webrev: http://cr.openjdk.java.net/~iveresov/6985015/webrev.03/ Thanks, igor On 11/26/10 9:14 PM, Igor Veresov wrote: > Vladimir, please find the answers inlined. > > Thanks, > igor > > On Nov 25, 2010, at 11:38 AM, Vladimir Kozlov wrote: > >> Igor, >> >> I don't like adding new br instructions which are used only 4 times. >> Could you simple totally separate code for COOP and use corresponding br (icc) instructions? >> > > That was actually Tom's suggestion, or at least how I understood it. I was hoping it was elegant enough, but sure we can do just a separate version of this bunch of klass comparisons for coops and the regular version. > >> Also there are no explanation/comments around new move_wide code. Why you need it (append()?) ? I am not C1 expert so it is not clear to me. > > move_wide is needed to access references that is outside he heap (which are typically uncompressed) from LIR. Some fields in the Thread structure are a good example. > > append() is needed to add an operation to a LIR_List (which a list of instructions in a basic block). Any LIR operation will do that. >> >> Otherwise it is better then before. >> >> Thanks, >> Vladimir >> >> On 11/25/10 7:03 AM, Igor Veresov wrote: >>> I've updated the webrev with includeDB changes and also removed unnecessary ifdefs. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/6985015/webrev.02/ >>> >>> igor >>> >>> On 11/18/10 7:12 PM, Igor Veresov wrote: >>>> This change implements compressed oops for C1 for x64 and sparc. >>>> The changes are mostly on the codegen level, with a few exceptions when >>>> we do access things outside of the heap that are uncompressed from the IR. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/6985015/webrev.00/ >>>> >>>> Thanks, >>>> igor >>> From john.r.rose at oracle.com Mon Nov 29 19:35:30 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 29 Nov 2010 19:35:30 -0800 Subject: review request (L): 7001379: bootstrap method data needs to be moved from constant pool to a classfile attribute In-Reply-To: References: <080DC5F8-ADA6-47F2-845D-779C2019D175@oracle.com> Message-ID: On Nov 25, 2010, at 2:27 AM, Christian Thalinger wrote: > On Nov 25, 2010, at 8:42 AM, John Rose wrote: >> On Nov 22, 2010, at 6:57 PM, John Rose wrote: >> >>> Because of a strong and reasonable request from the IBM JVM team, the JSR 292 class file format for CONSTANT_InvokeDynamic is changing one more time. >>> ... >>> I will be putting out a review request soon for this. >> >> >> Here is a JVM change which moves the variadic parts of CONSTANT_InvokeDynamic specifiers out of the constant pool and into a new attribute, BootstrapMethods. >> http://cr.openjdk.java.net/~jrose/7001379/webrev.hs.00 > > src/share/vm/classfile/classFileParser.hpp: > > + //@@ static int start_operand_group(GrowableArray* &operands, int op_count, TRAPS); > + //@@ static void store_operand_array(GrowableArray* operands, constantPoolHandle cp, TRAPS); > > Do we still need them? Oops, nope. > src/share/vm/oops/constantPoolOop.hpp: > > - void copy_entry_to(int from_i, constantPoolHandle to_cp, int to_i, TRAPS); > + static void copy_entry_to(constantPoolHandle from_cp, int from_i, constantPoolHandle to_cp, int to_i, TRAPS); > > Maybe I'm missing the obvious here but why do need to pass a handle in? There is nothing fancy going on in that method. In principle, the call to 'klass_at' could trigger a GC. We know it won't, because of the tag of the CP entry. But that requires a private, invisible contract with the present implementation of 'klass_at'. It is safer to use the handle. Since I had to introduce a handle in copy_cp_to_impl, it was natural to move it down into the per-entry routine. >> For review, here is the specification change, in the javadoc in the jdk repo: >> http://cr.openjdk.java.net/~jrose/7001379/webrev.jdk.00 > > 301 * Each {@code CONSTANT_InvokeDynamic} entry refers has a reference to a > 302 * bootstrap method specifier defined in a separate array. > > I think there are some superfluous words. Thanks. Fixed and clarified: * Each {@code CONSTANT_InvokeDynamic} entry contains an index which references * a bootstrap method specifier; all such specifiers are contained in a separate array. * This array is defined by a class attribute named {@code BootstrapMethods}. > 317 * {@code BootstrapMethods} attribute. In particular, each cosntant > > Typo. Fixed. >> The JDK webrev also includes an adjusted unit test. >> >> The base revision was reviewed by Christian yesterday: >> http://cr.openjdk.java.net/~jrose/7001423/webrev.00 >> >> The JVM code passes the unit test, of course. > > > -- Christian Thanks. Can I cite you as a reviewer on both change sets? -- John From john.r.rose at oracle.com Mon Nov 29 19:52:35 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 29 Nov 2010 19:52:35 -0800 Subject: for review (M): 7001423: JSR 292 bytecode enhancements need unit tests In-Reply-To: <64328FAD-8029-449F-BD45-B2A7AE4CE1E7@oracle.com> References: <4714171D-B690-4B3B-87EA-4018ED1E86FB@oracle.com> <64328FAD-8029-449F-BD45-B2A7AE4CE1E7@oracle.com> Message-ID: Christian, I updated the unit test to exercise the new change set for 7001379. The test now exercises a second BSM ("bsm2") which gets passed extra arguments from the BootstrapMethods classfile attribute. Would you mind doing a quick re-review? http://cr.openjdk.java.net/~jrose/7001423/webrev.01/ -- John On Nov 23, 2010, at 2:21 AM, Christian Thalinger wrote: > On Nov 21, 2010, at 9:40 AM, John Rose wrote: >> This webrev has a small jtreg test for the hotspot repository. >> >> http://cr.openjdk.java.net/~jrose/7001423/webrev.00/ >> >> It exercises the invokedynamic instruction, making the the bootstrap method parameters are made available to the BSM, and ensuring that the resulting call site can be invoked as expected. >> >> (Not included, to be done later: Multiple invocation of dynamic call sites, additional bootstrap method parameters, "ldc" of MethodHandle and MethodType constants.) >> >> In order to introduce an invokedynamic instruction (without help from the compiler), this unit test comes with a medium-sized script (single-file Java program) called "Indify" which generates the instruction in the test file. >> >> The Indify script is described here: http://blogs.sun.com/jrose/entry/a_modest_tool_for_writing >> >> In later pushes, Indify will be re-used for additional unit tests (such as those mentioned above to be done later). > > I haven't looked closely at the changes (especially Indify) but it seems good. > > -- Christian From christian.thalinger at oracle.com Tue Nov 30 00:08:24 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 30 Nov 2010 09:08:24 +0100 Subject: review request (L): 7001379: bootstrap method data needs to be moved from constant pool to a classfile attribute In-Reply-To: References: <080DC5F8-ADA6-47F2-845D-779C2019D175@oracle.com> Message-ID: On Nov 30, 2010, at 4:35 AM, John Rose wrote: >> src/share/vm/oops/constantPoolOop.hpp: >> >> - void copy_entry_to(int from_i, constantPoolHandle to_cp, int to_i, TRAPS); >> + static void copy_entry_to(constantPoolHandle from_cp, int from_i, constantPoolHandle to_cp, int to_i, TRAPS); >> >> Maybe I'm missing the obvious here but why do need to pass a handle in? There is nothing fancy going on in that method. > > In principle, the call to 'klass_at' could trigger a GC. We know it won't, because of the tag of the CP entry. But that requires a private, invisible contract with the present implementation of 'klass_at'. It is safer to use the handle. Since I had to introduce a handle in copy_cp_to_impl, it was natural to move it down into the per-entry routine. I see. That makes sense. > Thanks. Can I cite you as a reviewer on both change sets? Sure. -- Christian From christian.thalinger at oracle.com Tue Nov 30 00:22:01 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 30 Nov 2010 09:22:01 +0100 Subject: for review (M): 7001423: JSR 292 bytecode enhancements need unit tests In-Reply-To: References: <4714171D-B690-4B3B-87EA-4018ED1E86FB@oracle.com> <64328FAD-8029-449F-BD45-B2A7AE4CE1E7@oracle.com> Message-ID: <8D07F490-E91D-4F69-9737-C306AE34DE30@oracle.com> On Nov 30, 2010, at 4:52 AM, John Rose wrote: > Christian, I updated the unit test to exercise the new change set for 7001379. The test now exercises a second BSM ("bsm2") which gets passed extra arguments from the BootstrapMethods classfile attribute. > > Would you mind doing a quick re-review? > > http://cr.openjdk.java.net/~jrose/7001423/webrev.01/ Looks good. -- Christian From christian.thalinger at oracle.com Tue Nov 30 01:04:28 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 30 Nov 2010 10:04:28 +0100 Subject: Request for reviews (S): 7001363: java/dyn/InvokeDynamic should not be a well-known class in the JVM References: <5535007A-A40B-4356-90A8-B15E63BC492F@oracle.com> Message-ID: <398B8ADD-B10E-495D-AC73-D405E917B2D4@oracle.com> http://cr.openjdk.java.net/~twisti/7001363/webrev.01/ 7001363: java/dyn/InvokeDynamic should not be a well-known class in the JVM Summary: Because of the removal of language support, the JDK 7 API for JSR 292 no longer includes a public class named java/dyn/InvokeDynamic. Reviewed-by: Because of the removal of language support, the JDK 7 API for JSR 292 no longer includes a public class named java/dyn/InvokeDynamic. However, the JVM uses java/dyn/InvokeDynamic (arbitrarily) as a marker class for invokedynamic instructions. This practice needs to change, and the class may then be removed from the JDK. John already reviewed the changes, I'm just sending an official webrev for completeness. Please feel free to review it too! Begin forwarded message: > > From: John Rose > Date: November 30, 2010 12:52:41 AM GMT+01:00 > To: Christian Thalinger > Subject: Re: 7001363: java/dyn/InvokeDynamic should not be a well-known class in the JVM > > On Nov 29, 2010, at 7:08 AM, Christian Thalinger wrote: > >> On Nov 19, 2010, at 8:44 AM, John Rose wrote: >>> Can I hand you this one? >> >> >> It's not completely clear to me what we have to remove. As far as I understand it invokedynamic instructions should still work but all references to java/dyn/InvokeDynamic should disappear. This is preliminary webrev: >> >> http://cr.openjdk.java.net/~twisti/7001363/webrev.00/ >> >> These changes do exactly that. I can still run invokedynamic programs but the InvokeDynamic class is not referenced and loaded anymore. > > Reviewed. Looks good. (You can CC this to hotspot-compiler-dev if you want.) -- John From christian.thalinger at oracle.com Tue Nov 30 07:55:42 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 30 Nov 2010 16:55:42 +0100 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC In-Reply-To: References: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> <4CDDA15E.6030603@oracle.com> <025DDC98-A2FD-458C-B55A-3D31A531D298@oracle.com> <4CE1B855.6020603@oracle.com> <4CE2C0EA.7090208@oracle.com> <5A90B778-D3D3-4494-BE64-6E29FF0D4F7A@oracle.com> <4CE57EC1.30404@oracle.com> Message-ID: On Nov 25, 2010, at 4:57 PM, Christian Thalinger wrote: >> I don't understand how MachConstantBaseNode::size() is not called >> on sparc where there is code generated for it? You need the size. >> It seems, you have to calculate it manually. > > SPARC does not use Compile::Shorten_branches and that's the only place where I got calls to size. I implemented MachConstantBaseNode::size on SPARC too. >> I think you don't need to add_req() in constructor and then use >> set_req(root) since new MachConstantBase node is only created in >> Compile::mach_constant_base_node() so you can add_req(root) there > > > OK. > > I will send out a review later or tomorrow. ...or today: http://cr.openjdk.java.net/~twisti/6961690/webrev.04/ I removed the additional pipe_class'es on SPARC again. That should be the final version. -- Christian From vladimir.kozlov at oracle.com Tue Nov 30 08:47:50 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 30 Nov 2010 08:47:50 -0800 Subject: Request for reviews (S): 7001363: java/dyn/InvokeDynamic should not be a well-known class in the JVM In-Reply-To: <398B8ADD-B10E-495D-AC73-D405E917B2D4@oracle.com> References: <5535007A-A40B-4356-90A8-B15E63BC492F@oracle.com> <398B8ADD-B10E-495D-AC73-D405E917B2D4@oracle.com> Message-ID: <4CF52AB6.4000208@oracle.com> Looks good. Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7001363/webrev.01/ > > 7001363: java/dyn/InvokeDynamic should not be a well-known class in the JVM > Summary: Because of the removal of language support, the JDK 7 API for JSR 292 no longer includes a public class named java/dyn/InvokeDynamic. > Reviewed-by: > > Because of the removal of language support, the JDK 7 API for JSR 292 > no longer includes a public class named java/dyn/InvokeDynamic. > > However, the JVM uses java/dyn/InvokeDynamic (arbitrarily) as a marker > class for invokedynamic instructions. This practice needs to change, > and the class may then be removed from the JDK. > > John already reviewed the changes, I'm just sending an official webrev for completeness. Please feel free to review it too! > > > Begin forwarded message: >> From: John Rose >> Date: November 30, 2010 12:52:41 AM GMT+01:00 >> To: Christian Thalinger >> Subject: Re: 7001363: java/dyn/InvokeDynamic should not be a well-known class in the JVM >> >> On Nov 29, 2010, at 7:08 AM, Christian Thalinger wrote: >> >>> On Nov 19, 2010, at 8:44 AM, John Rose wrote: >>>> Can I hand you this one? >>> >>> It's not completely clear to me what we have to remove. As far as I understand it invokedynamic instructions should still work but all references to java/dyn/InvokeDynamic should disappear. This is preliminary webrev: >>> >>> http://cr.openjdk.java.net/~twisti/7001363/webrev.00/ >>> >>> These changes do exactly that. I can still run invokedynamic programs but the InvokeDynamic class is not referenced and loaded anymore. >> Reviewed. Looks good. (You can CC this to hotspot-compiler-dev if you want.) -- John > > From vladimir.kozlov at oracle.com Tue Nov 30 10:02:56 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 30 Nov 2010 10:02:56 -0800 Subject: Request for reviews (XXL): 6961690: load oops from constant table on SPARC In-Reply-To: References: <0EAEA35E-3027-4558-BA2A-C0A60B180C78@oracle.com> <4CDDA15E.6030603@oracle.com> <025DDC98-A2FD-458C-B55A-3D31A531D298@oracle.com> <4CE1B855.6020603@oracle.com> <4CE2C0EA.7090208@oracle.com> <5A90B778-D3D3-4494-BE64-6E29FF0D4F7A@oracle.com> <4CE57EC1.30404@oracle.com> Message-ID: <4CF53C50.40206@oracle.com> Looks good. Add the assert into MachConstantBaseNode::emit sparc code. Thanks, Vladimir Christian Thalinger wrote: > On Nov 25, 2010, at 4:57 PM, Christian Thalinger wrote: >>> I don't understand how MachConstantBaseNode::size() is not called >>> on sparc where there is code generated for it? You need the size. >>> It seems, you have to calculate it manually. >> SPARC does not use Compile::Shorten_branches and that's the only place where I got calls to size. > > I implemented MachConstantBaseNode::size on SPARC too. > >>> I think you don't need to add_req() in constructor and then use >>> set_req(root) since new MachConstantBase node is only created in >>> Compile::mach_constant_base_node() so you can add_req(root) there >> >> OK. >> >> I will send out a review later or tomorrow. > > ...or today: > > http://cr.openjdk.java.net/~twisti/6961690/webrev.04/ > > I removed the additional pipe_class'es on SPARC again. That should be the final version. > > -- Christian From tom.rodriguez at oracle.com Tue Nov 30 11:48:46 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 30 Nov 2010 11:48:46 -0800 Subject: review (XS) for 7002666: eclipse CDT projects crash with compressed oops Message-ID: <648D2EC9-0AA8-4D98-AC3F-01AC2AF7EE1D@oracle.com> http://cr.openjdk.java.net/~never/7002666/ 7002666: eclipse CDT projects crash with compressed oops Reviewed-by: When emitting the code to zero a newly allocated object C2 attempts to identify space that's already been initialized or extra space that isn't actually part of an instance. The logic for this should only be executed for instances and never for arrays but the logic doesn't explicitly test for arrays. It's normally protected in the array case because the klass is precise and the value of layout_helper will never match zeroes_done since it's always negative for arrays. In this case the newArray is producing something that's typed as Object so the klass input of the allocation says Object and it mistakenly assumes the rest of the array doesn't need zeroing. The fix is to only execute this logic for AllocateNodes. Tested with eclipse and with new test case. src/share/vm/opto/memnode.cpp test/compiler/7002666/Test7002666.java From tom.rodriguez at oracle.com Tue Nov 30 13:13:39 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 30 Nov 2010 13:13:39 -0800 Subject: review (XS) for 6875026: CTW failure jdk6_18/hotspot/src/share/vm/c1/c1_LinearScan.cpp:5486 Message-ID: http://cr.openjdk.java.net/~never/6875026 6875026: CTW failure jdk6_18/hotspot/src/share/vm/c1/c1_LinearScan.cpp:5486 Reviewed-by: Constructing the CodeEmitInfo for an instruciton may result in evaluation of instructions which are only used in the ValueStack. This should always been done before any argument setup with fixed registers. arraycopy uses all the registers and this can cause us to fail our allocation. The fix is to make the code look like the sparc code and create the CodeEmitInfo early. Tested with test from report. src/cpu/x86/vm/c1_LIRGenerator_x86.cpp From vladimir.kozlov at oracle.com Tue Nov 30 15:06:56 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 30 Nov 2010 15:06:56 -0800 Subject: review (XS) for 6875026: CTW failure jdk6_18/hotspot/src/share/vm/c1/c1_LinearScan.cpp:5486 In-Reply-To: References: Message-ID: <4CF58390.7060801@oracle.com> Good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6875026 > > 6875026: CTW failure jdk6_18/hotspot/src/share/vm/c1/c1_LinearScan.cpp:5486 > Reviewed-by: > > Constructing the CodeEmitInfo for an instruciton may result in > evaluation of instructions which are only used in the ValueStack. > This should always been done before any argument setup with fixed > registers. arraycopy uses all the registers and this can cause us to > fail our allocation. The fix is to make the code look like the sparc > code and create the CodeEmitInfo early. Tested with test from report. > > src/cpu/x86/vm/c1_LIRGenerator_x86.cpp From igor.veresov at oracle.com Tue Nov 30 15:28:57 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 30 Nov 2010 15:28:57 -0800 Subject: review (XS) for 6875026: CTW failure jdk6_18/hotspot/src/share/vm/c1/c1_LinearScan.cpp:5486 In-Reply-To: References: Message-ID: <4CF588B9.6010309@oracle.com> Looks good! igor On 11/30/10 1:13 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6875026 > > 6875026: CTW failure jdk6_18/hotspot/src/share/vm/c1/c1_LinearScan.cpp:5486 > Reviewed-by: > > Constructing the CodeEmitInfo for an instruciton may result in > evaluation of instructions which are only used in the ValueStack. > This should always been done before any argument setup with fixed > registers. arraycopy uses all the registers and this can cause us to > fail our allocation. The fix is to make the code look like the sparc > code and create the CodeEmitInfo early. Tested with test from report. > > src/cpu/x86/vm/c1_LIRGenerator_x86.cpp From vladimir.kozlov at oracle.com Tue Nov 30 15:05:35 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 30 Nov 2010 15:05:35 -0800 Subject: review (XS) for 7002666: eclipse CDT projects crash with compressed oops In-Reply-To: <648D2EC9-0AA8-4D98-AC3F-01AC2AF7EE1D@oracle.com> References: <648D2EC9-0AA8-4D98-AC3F-01AC2AF7EE1D@oracle.com> Message-ID: <4CF5833F.6060807@oracle.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7002666/ > > 7002666: eclipse CDT projects crash with compressed oops > Reviewed-by: > > When emitting the code to zero a newly allocated object C2 attempts to > identify space that's already been initialized or extra space that > isn't actually part of an instance. The logic for this should only be > executed for instances and never for arrays but the logic doesn't > explicitly test for arrays. It's normally protected in the array case > because the klass is precise and the value of layout_helper will never > match zeroes_done since it's always negative for arrays. In this case > the newArray is producing something that's typed as Object so the > klass input of the allocation says Object and it mistakenly assumes > the rest of the array doesn't need zeroing. The fix is to only > execute this logic for AllocateNodes. Tested with eclipse and with > new test case. > > src/share/vm/opto/memnode.cpp > test/compiler/7002666/Test7002666.java From Christian.Thalinger at Sun.COM Tue Nov 30 23:02:50 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Wed, 01 Dec 2010 07:02:50 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7001363: java/dyn/InvokeDynamic should not be a well-known class in the JVM Message-ID: <20101201070252.9F5BB47FC3@hg.openjdk.java.net> Changeset: f2da85a9b08e Author: twisti Date: 2010-11-30 09:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f2da85a9b08e 7001363: java/dyn/InvokeDynamic should not be a well-known class in the JVM Summary: Because of the removal of language support, the JDK 7 API for JSR 292 no longer includes a public class named java/dyn/InvokeDynamic. Reviewed-by: jrose, kvn ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/thread.cpp