From igor.ignatyev at oracle.com Mon Apr 1 07:15:13 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 01 Apr 2013 18:15:13 +0400 Subject: RFR(M): 8007288: Additional WB API for compiler's testing In-Reply-To: <0549160A-DBFE-42A8-9AAE-AC98CB066D09@oracle.com> References: <5154B8F1.2030108@oracle.com> <0549160A-DBFE-42A8-9AAE-AC98CB066D09@oracle.com> Message-ID: <51599671.4090501@oracle.com> test 'compiler/whitebox/EnqueueMethodForCompilationTest' has failed during testing, because 'CompilationPolicy::can_be_compiled()' returns 'true' for invalid comp_level (less that -1 or great that 4). i added method 'is_compile' to check whether a value is valid level of compilation and rerun jprt. in new results: - compiler/whitebox/IsMethodCompilableTest failed on on *-i586-*-c1 due to JDK-8007270 - timeouts in other compiler's tests: * compiler/6663848/Tester * compiler/6711100/Test * compiler/6792161/Test6792161 * compiler/6863420/Test * compiler/6863420/Test * compiler/6901572/Test * compiler/7100757/Test7100757 * compiler/7119644/TestFloatVect * compiler/7196199/Test7196199 * compiler/7199742/Test7199742 updated webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.01/ Best regards, Igor Ignatyev On 03/29/2013 01:52 AM, David Chase wrote: > (Not a reviewer) > > Could you run these tests on the "east" JPRT queue and see if they have any problems there? > We seem to have some surprisingly slow machines there, and that has caused problems with other tests. > > David > > > On 2013-03-28, at 5:41 PM, Igor Ignatyev wrote: > >> Hi all, >> >> Please review the patch. >> >> 1. added new functions to WhiteBox: >> public native boolean setForceInlineMethod(Method method, boolean value); >> public native boolean enqueueMethodForCompilation(Method method, int compLevel); >> public native void clearMethodState(Method method); >> 2. related changes in not whitebox code: >> - added 'Method::clear_not_*_compilable()' and corresponded 'AccessFlags::clear_not_*_compilable()' >> - added 'MethodData::init()' - reset method data into original state. reset all counters, flags >> 3. removed useless code: >> - 'if (!TieredCompilation) { comp_level = CompLevel_highest_tier; }' in CompileBroker::compile_method() -- there is no method calls w/ comp_level != CompLevel_highest_tier in non-tiered >> - 'MethodData::initialize(methodHandle method)' -- declaration w/o definition >> 4. added tests for new WB functions >> >> webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.00/ >> jbs: https://jbs.oracle.com/bugs/browse/JDK-8007288 >> -- >> Best regards, >> Igor Ignatyev > From vladimir.kozlov at oracle.com Mon Apr 1 10:30:22 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 01 Apr 2013 10:30:22 -0700 Subject: RFR(M): 8007288: Additional WB API for compiler's testing In-Reply-To: <51599671.4090501@oracle.com> References: <5154B8F1.2030108@oracle.com> <0549160A-DBFE-42A8-9AAE-AC98CB066D09@oracle.com> <51599671.4090501@oracle.com> Message-ID: <5159C42E.7000208@oracle.com> compileBroker.cpp - add assert() to check that. compilationPolicy.cpp - I don't think the change is correct since is_compile(CompLevel_any) returns false. Could you rename setForceInlineMethod() to testSetForceInlineMethod() to be more clear what it does? Thanks, Vladimir On 4/1/13 7:15 AM, Igor Ignatyev wrote: > test 'compiler/whitebox/EnqueueMethodForCompilationTest' has failed > during testing, because 'CompilationPolicy::can_be_compiled()' returns > 'true' for invalid comp_level (less that -1 or great that 4). > > i added method 'is_compile' to check whether a value is valid level of > compilation and rerun jprt. > > in new results: > - compiler/whitebox/IsMethodCompilableTest failed on on *-i586-*-c1 > due to JDK-8007270 > - timeouts in other compiler's tests: > * compiler/6663848/Tester > * compiler/6711100/Test > * compiler/6792161/Test6792161 > * compiler/6863420/Test > * compiler/6863420/Test > * compiler/6901572/Test > * compiler/7100757/Test7100757 > * compiler/7119644/TestFloatVect > * compiler/7196199/Test7196199 > * compiler/7199742/Test7199742 > > updated webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.01/ > > Best regards, > Igor Ignatyev > > On 03/29/2013 01:52 AM, David Chase wrote: >> (Not a reviewer) >> >> Could you run these tests on the "east" JPRT queue and see if they >> have any problems there? >> We seem to have some surprisingly slow machines there, and that has >> caused problems with other tests. >> >> David >> >> >> On 2013-03-28, at 5:41 PM, Igor Ignatyev >> wrote: >> >>> Hi all, >>> >>> Please review the patch. >>> >>> 1. added new functions to WhiteBox: >>> public native boolean setForceInlineMethod(Method method, boolean >>> value); >>> public native boolean enqueueMethodForCompilation(Method method, >>> int compLevel); >>> public native void clearMethodState(Method method); >>> 2. related changes in not whitebox code: >>> - added 'Method::clear_not_*_compilable()' and corresponded >>> 'AccessFlags::clear_not_*_compilable()' >>> - added 'MethodData::init()' - reset method data into original >>> state. reset all counters, flags >>> 3. removed useless code: >>> - 'if (!TieredCompilation) { comp_level = CompLevel_highest_tier; >>> }' in CompileBroker::compile_method() -- there is no method calls w/ >>> comp_level != CompLevel_highest_tier in non-tiered >>> - 'MethodData::initialize(methodHandle method)' -- declaration w/o >>> definition >>> 4. added tests for new WB functions >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.00/ >>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8007288 >>> -- >>> Best regards, >>> Igor Ignatyev >> From christian.thalinger at oracle.com Mon Apr 1 11:01:08 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 1 Apr 2013 11:01:08 -0700 Subject: RFR (M): 6443505: Ideal() function for CmpLTMask In-Reply-To: <5154D446.5050708@oracle.com> References: <32C62903-0EB1-4668-B66F-B94ED433AC30@oracle.com> <5154D446.5050708@oracle.com> Message-ID: <4E5D18DB-C9A6-4DAB-ADB4-E6890E4B4DD1@oracle.com> On Mar 28, 2013, at 4:37 PM, Vladimir Kozlov wrote: > "pipeline" info is not used in code generation, it is outdated anyway. So use what other similar instructions use. > > I think we should use only branch variant on all x86 (32 and 64bit). We save register (tmp) and it is MUCH MUCH more important for performance (less spills on stack). And you need only 3 instructions for cadd_cmpLTMask. I agree on this one. -- Chris > > And, please, remove unneeded spaces near parenthesis, at least in new code. > > Thanks, > Vladimir > > On 3/27/13 6:09 PM, David Chase wrote: >> Problem: >> (as stated) >> C2 needs a special case like CmpLTMask (turn result of a comparison into a -1/0 mask) for the comparison of a difference with zero. >> >> (as actually observed) >> 1) The improvement in that case is minimal and (very) difficult to get to trigger, because CSE interferes and extracts the p-q from the pattern. >> 2) The original code generation for caddCmpLTMask on some platforms was actually wrong (used carry bit for a signed comparison) >> 3) The original Ideal pattern matching, because of a typo/thinko, accidentally failed to apply in the symmetric case >> 4) Code generation for CmpLTMask on all platforms omitted the somewhat relevant case of and-CmpLTMask; if the very specific pattern failed to apply, then it would fall back to the laborious calculation of an actual mask, when much more compact code could apply. >> >> Fix: >> Repair wrong code generation. >> Write additional pattern for (and (cmpltmask p q) y) >> Fixed the typo so the pattern fires more often. >> >> Webrev: >> http://cr.openjdk.java.net/~drchase/6443505/webrev.00/ >> >> Testing: >> Wrote a new test to definitely exercise the two patterns in question. >> Verified that "new test" would fail running with unfixed compiler. >> >> Verified (observing assembly output) that the new patterns matched on x86_32-cmov, x86_32+cmov, x86_64, and Sparc >> (except that I could not get the and-cmpltmask pattern to fire on Sparc. >> Bit of a shame we lack a cumulative coverage tool wired into jtreg so we could easily know if it ever fired at all). >> >> Benchmarked change on x86_64 (saw little or no performance difference on the whole benchmark) >> >> JPRT on compiler tests (clean runs thwarted by irrelevant failures, but it was always the same 2 or 3 borked tests.) >> >> JPRT on just the new test (clean run) >> >> Questions: >> not 100% sure on the pattern costs. >> not 100% sure on the choice of "pipeline". >> From christian.thalinger at oracle.com Mon Apr 1 11:09:38 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 1 Apr 2013 11:09:38 -0700 Subject: RFR (S): 8010913 : compiler/6863420 often exceeds timeout In-Reply-To: <4FF7D604-759B-497A-B75D-DACE0755F43D@oracle.com> References: <4FF7D604-759B-497A-B75D-DACE0755F43D@oracle.com> Message-ID: On Mar 28, 2013, at 10:45 AM, David Chase wrote: > Problem: > The test runs over-long on some test machines, causing timeouts and spurious failures > if JPRT is used to check compiler tests across a range of machines. > A four-minute run was observed in one case. > > Fix: > Add an increased timeout and a timeout thread for shutting down the test early. > > Testing: > JPRT of that test across all available platforms with an artificially short timeout > to ensure that the timeout thread worked as expected, manual check of successful > runs to be sure that the timeout thread did its job (i.e., saw runs for a hair more than > the time limit, as well as short runs). > > webrev: > http://cr.openjdk.java.net/~drchase/8010913/webrev.00/ Looks good. Two minor comments: + /* NOTICE THE INTERNAL TIMEOUT IN CLASS TOT */ Maybe this comment should be above the timeout: ! * @run main/othervm/timeout=300 Test + Thread.sleep(240*1000); and make this timeout a final static? -- Chris From vladimir.kozlov at oracle.com Mon Apr 1 12:01:36 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 01 Apr 2013 12:01:36 -0700 Subject: RFR (S): 8010913 : compiler/6863420 often exceeds timeout In-Reply-To: <4FF7D604-759B-497A-B75D-DACE0755F43D@oracle.com> References: <4FF7D604-759B-497A-B75D-DACE0755F43D@oracle.com> Message-ID: <5159D990.9000306@oracle.com> Main loop should also check 'done': for (int numThreads = 1; numThreads <= 32; numThreads++) { Thanks, Vladimir On 3/28/13 10:45 AM, David Chase wrote: > Problem: > The test runs over-long on some test machines, causing timeouts and spurious failures > if JPRT is used to check compiler tests across a range of machines. > A four-minute run was observed in one case. > > Fix: > Add an increased timeout and a timeout thread for shutting down the test early. > > Testing: > JPRT of that test across all available platforms with an artificially short timeout > to ensure that the timeout thread worked as expected, manual check of successful > runs to be sure that the timeout thread did its job (i.e., saw runs for a hair more than > the time limit, as well as short runs). > > webrev: > http://cr.openjdk.java.net/~drchase/8010913/webrev.00/ > From igor.ignatyev at oracle.com Tue Apr 2 01:49:14 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 02 Apr 2013 12:49:14 +0400 Subject: RFR(M): 8007288: Additional WB API for compiler's testing In-Reply-To: <5159C42E.7000208@oracle.com> References: <5154B8F1.2030108@oracle.com> <0549160A-DBFE-42A8-9AAE-AC98CB066D09@oracle.com> <51599671.4090501@oracle.com> <5159C42E.7000208@oracle.com> Message-ID: <515A9B8A.6040503@oracle.com> > compileBroker.cpp - add assert() to check that. If I add it, WB.enqueueMethodForCompilation() will trigger this assert, e.g. in test 'compiler/whitebox/EnqueueMethodForCompilationTest'. > compilationPolicy.cpp - I don't think the change is correct since > is_compile(CompLevel_any) returns false. 'comp_level == CompLevel_any' is the same that 'comp_level == CompLevel_all' and this situation is processed in compilationPolicy.cpp:124, so I think that it's correct, isn't it? I can add explicit checking for equality to 'CompLevel_any'. > Could you rename setForceInlineMethod() to testSetForceInlineMethod() to > be more clear what it does? I will rename setForceInlineMethod() and setDontInlineMethod(). Best regards, Igor Ignatyev On 04/01/2013 09:30 PM, Vladimir Kozlov wrote: > compileBroker.cpp - add assert() to check that. > > compilationPolicy.cpp - I don't think the change is correct since > is_compile(CompLevel_any) returns false. > > Could you rename setForceInlineMethod() to testSetForceInlineMethod() to > be more clear what it does? > > Thanks, > Vladimir > > On 4/1/13 7:15 AM, Igor Ignatyev wrote: >> test 'compiler/whitebox/EnqueueMethodForCompilationTest' has failed >> during testing, because 'CompilationPolicy::can_be_compiled()' returns >> 'true' for invalid comp_level (less that -1 or great that 4). >> >> i added method 'is_compile' to check whether a value is valid level of >> compilation and rerun jprt. >> >> in new results: >> - compiler/whitebox/IsMethodCompilableTest failed on on *-i586-*-c1 >> due to JDK-8007270 >> - timeouts in other compiler's tests: >> * compiler/6663848/Tester >> * compiler/6711100/Test >> * compiler/6792161/Test6792161 >> * compiler/6863420/Test >> * compiler/6863420/Test >> * compiler/6901572/Test >> * compiler/7100757/Test7100757 >> * compiler/7119644/TestFloatVect >> * compiler/7196199/Test7196199 >> * compiler/7199742/Test7199742 >> >> updated webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.01/ >> >> Best regards, >> Igor Ignatyev >> >> On 03/29/2013 01:52 AM, David Chase wrote: >>> (Not a reviewer) >>> >>> Could you run these tests on the "east" JPRT queue and see if they >>> have any problems there? >>> We seem to have some surprisingly slow machines there, and that has >>> caused problems with other tests. >>> >>> David >>> >>> >>> On 2013-03-28, at 5:41 PM, Igor Ignatyev >>> wrote: >>> >>>> Hi all, >>>> >>>> Please review the patch. >>>> >>>> 1. added new functions to WhiteBox: >>>> public native boolean setForceInlineMethod(Method method, boolean >>>> value); >>>> public native boolean enqueueMethodForCompilation(Method method, >>>> int compLevel); >>>> public native void clearMethodState(Method method); >>>> 2. related changes in not whitebox code: >>>> - added 'Method::clear_not_*_compilable()' and corresponded >>>> 'AccessFlags::clear_not_*_compilable()' >>>> - added 'MethodData::init()' - reset method data into original >>>> state. reset all counters, flags >>>> 3. removed useless code: >>>> - 'if (!TieredCompilation) { comp_level = CompLevel_highest_tier; >>>> }' in CompileBroker::compile_method() -- there is no method calls w/ >>>> comp_level != CompLevel_highest_tier in non-tiered >>>> - 'MethodData::initialize(methodHandle method)' -- declaration w/o >>>> definition >>>> 4. added tests for new WB functions >>>> >>>> webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.00/ >>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8007288 >>>> -- >>>> Best regards, >>>> Igor Ignatyev >>> From david.r.chase at oracle.com Tue Apr 2 07:21:50 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 2 Apr 2013 10:21:50 -0400 Subject: RFR (S): 8010913 : compiler/6863420 often exceeds timeout In-Reply-To: <5159D990.9000306@oracle.com> References: <4FF7D604-759B-497A-B75D-DACE0755F43D@oracle.com> <5159D990.9000306@oracle.com> Message-ID: <8EF78437-8AC7-4475-B4C3-3ECD0896B8D4@oracle.com> http://cr.openjdk.java.net/~drchase/8010913/webrev.01/ On 2013-04-01, at 3:01 PM, Vladimir Kozlov wrote: > Main loop should also check 'done': > > for (int numThreads = 1; numThreads <= 32; numThreads++) { > > Thanks, > Vladimir > > On 3/28/13 10:45 AM, David Chase wrote: >> Problem: >> The test runs over-long on some test machines, causing timeouts and spurious failures >> if JPRT is used to check compiler tests across a range of machines. >> A four-minute run was observed in one case. >> >> Fix: >> Add an increased timeout and a timeout thread for shutting down the test early. >> >> Testing: >> JPRT of that test across all available platforms with an artificially short timeout >> to ensure that the timeout thread worked as expected, manual check of successful >> runs to be sure that the timeout thread did its job (i.e., saw runs for a hair more than >> the time limit, as well as short runs). >> >> webrev: >> http://cr.openjdk.java.net/~drchase/8010913/webrev.00/ >> From vladimir.kozlov at oracle.com Tue Apr 2 08:20:05 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Apr 2013 08:20:05 -0700 Subject: RFR (S): 8010913 : compiler/6863420 often exceeds timeout In-Reply-To: <8EF78437-8AC7-4475-B4C3-3ECD0896B8D4@oracle.com> References: <4FF7D604-759B-497A-B75D-DACE0755F43D@oracle.com> <5159D990.9000306@oracle.com> <8EF78437-8AC7-4475-B4C3-3ECD0896B8D4@oracle.com> Message-ID: <515AF725.3040000@oracle.com> Good. Thanks, Vladimir On 4/2/13 7:21 AM, David Chase wrote: > http://cr.openjdk.java.net/~drchase/8010913/webrev.01/ > > On 2013-04-01, at 3:01 PM, Vladimir Kozlov wrote: > >> Main loop should also check 'done': >> >> for (int numThreads = 1; numThreads <= 32; numThreads++) { >> >> Thanks, >> Vladimir >> >> On 3/28/13 10:45 AM, David Chase wrote: >>> Problem: >>> The test runs over-long on some test machines, causing timeouts and spurious failures >>> if JPRT is used to check compiler tests across a range of machines. >>> A four-minute run was observed in one case. >>> >>> Fix: >>> Add an increased timeout and a timeout thread for shutting down the test early. >>> >>> Testing: >>> JPRT of that test across all available platforms with an artificially short timeout >>> to ensure that the timeout thread worked as expected, manual check of successful >>> runs to be sure that the timeout thread did its job (i.e., saw runs for a hair more than >>> the time limit, as well as short runs). >>> >>> webrev: >>> http://cr.openjdk.java.net/~drchase/8010913/webrev.00/ >>> > From nils.eliasson at oracle.com Tue Apr 2 09:59:33 2013 From: nils.eliasson at oracle.com (nils.eliasson at oracle.com) Date: Tue, 02 Apr 2013 16:59:33 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7034299: Faulty winsock initialization code Message-ID: <20130402165938.8A97B48536@hg.openjdk.java.net> Changeset: 53028d751155 Author: neliasso Date: 2013-04-02 09:30 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/53028d751155 7034299: Faulty winsock initialization code Reviewed-by: dholmes, sla, ctornqvi ! src/os/windows/vm/os_windows.cpp From vladimir.kozlov at oracle.com Tue Apr 2 11:51:10 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Apr 2013 11:51:10 -0700 Subject: RFR (M): 8011102: Clear AVX registers after return from JNI call In-Reply-To: <5150EADD.2050707@oracle.com> References: <5150EADD.2050707@oracle.com> Message-ID: <515B289E.7050203@oracle.com> http://cr.openjdk.java.net/~kvn/8011102/webrev/ A native library may use wide 256bit YMM registers and does not clean them after that causing SSE <-> AVX transition penalty. Note: penalty exist only in mixing 256bit data avx instructions with SSE instructions. There is no penalty with mixed 128 bit avx instructions because they zero upper bits. Add vzeroupper instruction after return from JNI call to avoid the penalty. Add vzeroupper in compiled code which use 256bit vectors, before calls and return. Also add it in intrinsics which use 256bit vectors: arraycopy, fillarray, strings and encode_iso. Note, vzeroupper is fast, one cycle instruction. Moved Java_To_Runtime() encoding to x86_64.ad from _x86_64.ad because they are the same. Tested with compiler jtreg, ctw, jprt. Thanks, Vladimir From vladimir.kozlov at oracle.com Tue Apr 2 12:19:37 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Apr 2013 12:19:37 -0700 Subject: RFR(M): 8007288: Additional WB API for compiler's testing In-Reply-To: <515A9B8A.6040503@oracle.com> References: <5154B8F1.2030108@oracle.com> <0549160A-DBFE-42A8-9AAE-AC98CB066D09@oracle.com> <51599671.4090501@oracle.com> <5159C42E.7000208@oracle.com> <515A9B8A.6040503@oracle.com> Message-ID: <515B2F49.7050305@oracle.com> On 4/2/13 1:49 AM, Igor Ignatyev wrote: > > compileBroker.cpp - add assert() to check that. > If I add it, WB.enqueueMethodForCompilation() will trigger this assert, > e.g. in test 'compiler/whitebox/EnqueueMethodForCompilationTest'. Which means the test introduces the case which never happens in normal execution. I am not sure it is good or bad. You can relax assert with WhiteBoxAPI check. I really want this assert for normal execution. > > > compilationPolicy.cpp - I don't think the change is correct since > > is_compile(CompLevel_any) returns false. > 'comp_level == CompLevel_any' is the same that 'comp_level == > CompLevel_all' and this situation is processed in > compilationPolicy.cpp:124, so I think that it's correct, isn't it? > I can add explicit checking for equality to 'CompLevel_any'. You are right about CompLevel_any. What about next check in m->is_not_compilable(): if (is_method_handle_intrinsic()) return !is_synthetic(); // the generated adapters must be compiled Thanks, Vladimir > >> Could you rename setForceInlineMethod() to testSetForceInlineMethod() to >> be more clear what it does? > I will rename setForceInlineMethod() and setDontInlineMethod(). > > Best regards, > Igor Ignatyev > > On 04/01/2013 09:30 PM, Vladimir Kozlov wrote: >> compileBroker.cpp - add assert() to check that. >> >> compilationPolicy.cpp - I don't think the change is correct since >> is_compile(CompLevel_any) returns false. >> >> Could you rename setForceInlineMethod() to testSetForceInlineMethod() to >> be more clear what it does? >> >> Thanks, >> Vladimir >> >> On 4/1/13 7:15 AM, Igor Ignatyev wrote: >>> test 'compiler/whitebox/EnqueueMethodForCompilationTest' has failed >>> during testing, because 'CompilationPolicy::can_be_compiled()' returns >>> 'true' for invalid comp_level (less that -1 or great that 4). >>> >>> i added method 'is_compile' to check whether a value is valid level of >>> compilation and rerun jprt. >>> >>> in new results: >>> - compiler/whitebox/IsMethodCompilableTest failed on on *-i586-*-c1 >>> due to JDK-8007270 >>> - timeouts in other compiler's tests: >>> * compiler/6663848/Tester >>> * compiler/6711100/Test >>> * compiler/6792161/Test6792161 >>> * compiler/6863420/Test >>> * compiler/6863420/Test >>> * compiler/6901572/Test >>> * compiler/7100757/Test7100757 >>> * compiler/7119644/TestFloatVect >>> * compiler/7196199/Test7196199 >>> * compiler/7199742/Test7199742 >>> >>> updated webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.01/ >>> >>> Best regards, >>> Igor Ignatyev >>> >>> On 03/29/2013 01:52 AM, David Chase wrote: >>>> (Not a reviewer) >>>> >>>> Could you run these tests on the "east" JPRT queue and see if they >>>> have any problems there? >>>> We seem to have some surprisingly slow machines there, and that has >>>> caused problems with other tests. >>>> >>>> David >>>> >>>> >>>> On 2013-03-28, at 5:41 PM, Igor Ignatyev >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> Please review the patch. >>>>> >>>>> 1. added new functions to WhiteBox: >>>>> public native boolean setForceInlineMethod(Method method, boolean >>>>> value); >>>>> public native boolean enqueueMethodForCompilation(Method method, >>>>> int compLevel); >>>>> public native void clearMethodState(Method method); >>>>> 2. related changes in not whitebox code: >>>>> - added 'Method::clear_not_*_compilable()' and corresponded >>>>> 'AccessFlags::clear_not_*_compilable()' >>>>> - added 'MethodData::init()' - reset method data into original >>>>> state. reset all counters, flags >>>>> 3. removed useless code: >>>>> - 'if (!TieredCompilation) { comp_level = CompLevel_highest_tier; >>>>> }' in CompileBroker::compile_method() -- there is no method calls w/ >>>>> comp_level != CompLevel_highest_tier in non-tiered >>>>> - 'MethodData::initialize(methodHandle method)' -- declaration w/o >>>>> definition >>>>> 4. added tests for new WB functions >>>>> >>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.00/ >>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8007288 >>>>> -- >>>>> Best regards, >>>>> Igor Ignatyev >>>> From niclas.adlertz at oracle.com Wed Apr 3 04:58:26 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Wed, 3 Apr 2013 13:58:26 +0200 Subject: RFR(XS) 8006008: [parfait] Memory leak at hotspot/src/share/vm/adlc/archDesc.cpp Message-ID: Hi all. A very small parfait fix. A review would be much appreciated. Thank you. Regards, Niclas Adlertz ----------------------------------------------------------------- webrev: http://cr.openjdk.java.net/~adlertz/JDK-8006008/webrev00/ jbs: https://jbs.oracle.com/bugs/browse/JDK-8006008 bugs: http://bugs.sun.com/view_bug.do?bug_id=8006008 From volker.simonis at gmail.com Wed Apr 3 05:06:38 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 3 Apr 2013 14:06:38 +0200 Subject: RFR (XS): 8010460: Interpreter on some platforms loads ConstMethod::_max_stack and misses extra stack slots for JSR 292 In-Reply-To: References: <6B922316-9630-4955-9A42-8FA52D5571F6@oracle.com> <4CA94106-1D2A-4DF2-814E-DF2F7A190B60@oracle.com> <8A8F768B-D0E2-46C1-AEC2-ED2FAA88EA09@oracle.com> Message-ID: Hi Roland, this issue is almost the same as: 8002087 : JSR 292: max_stack issues in interpreter code after JSR-292 merge (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8002087) I think besides the oop map problem (in OopMapForCacheEntry::compute_map) your change fixes all other issues described there. On Fri, Mar 29, 2013 at 7:22 PM, Roland Westrelin < roland.westrelin at oracle.com> wrote: > Thanks for reviewing this. > > > Good. It's time to get rid of the //6815692// stuff. The extra_stack > variables (always zero now) can go away too. > > I'm not sure what to do with this: > guarantee(!EnableInvokeDynamic, "no support yet for > java.lang.invoke.MethodHandle"); //6815692 > //6815692//if (EnableInvokeDynamic) > //6815692// __ inc(O3, Method::extra_stack_entries()); > > in cppInterpreter_sparc.cpp > > Well, it wouldn't work anyway if running with 'EnableInvokeDynamic' enabled. But you have: 1217 __ lduh(O3, in_bytes(ConstMethod::max_stack_offset()), O3); 1218 guarantee(!EnableInvokeDynamic, "no support yet for java.lang.invoke.MethodHandle"); //6815692 1219 //6815692//if (EnableInvokeDynamic) 1220 //6815692// __ inc(O3, Method::extra_stack_entries()); and now, after your change, max_stack automatically accounts for the extra stack entries, so I'd delete the lines: 1219 //6815692//if (EnableInvokeDynamic) 1220 //6815692// __ inc(O3, Method::extra_stack_entries()); Just for the case that somebody ever wants to implement 'EnableInvokeDynamic' for the CPP-interpreter on SPARC. Maybe you could also remove the guarantee and hope for the best.. For our ppc-port ( http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/file/tip/src/cpu/ppc/vm/cppInterpreter_ppc.cpp) I've fixed this by inserting: __ ppc_lhz(max_stack, method_(max_stack)); if (EnableInvokeDynamic) { // Take into account 'extra_stack_entries' needed by method handles (see method.hpp) __ ppc_addi(max_stack, max_stack, methodOopDesc::extra_stack_entries()); } but that's not necessary anymore, after your change. > > I think extra_stack_words can be deleted, and extra_stack_entries can be > made private to Method. > > > > This line of code is redundant in > src/cpu/x86/vm/templateInterpreter_x86_{32,64}.cpp: > > const int extra_stack = Method::extra_stack_entries(); > > I applied Christian's suggestions and yours and found a reference to > Method::extra_stack_entries() in c2 that I assume can be removed. Here is a > new webrev: > > http://cr.openjdk.java.net/~roland/8010460/webrev.01/ > > Roland. You may also consider to fix another problem which only occurs if you use a hsx24 or later with pre-hsx24 class library (i.e. if building hsx24/hsx25 with a pre-hsx24 bootstrap JDK). It is an assertion in bytecodeInterpreter.cpp: // We have a problem here if we are running with a pre-hsx24 JDK (for example during bootstrap) // because in that case, EnableInvokeDynamic is true by default but will be later switched off // if java_lang_invoke_MethodHandle::compute_offsets() detects that the JDK only has the classes // for the old JSR292 implementation. // This leads to a situation where 'istate->_stack_limit' always accounts for // methodOopDesc::extra_stack_entries() because it is computed in // CppInterpreterGenerator::generate_compute_interpreter_state() which was generated while // EnableInvokeDynamic was still true. On the other hand, istate->_method->max_stack() doesn't // account for extra_stack_entries() anymore because at the time when it is called // EnableInvokeDynamic was already set to false. // So we have a second version of the assertion which handles the case where EnableInvokeDynamic was // switched off because of the wrong classes. if (EnableInvokeDynamic || FLAG_IS_CMDLINE(EnableInvokeDynamic)) { assert(labs(istate->_stack_base - istate->_stack_limit) == (istate->_method->max_stack() + 1), "bad stack limit"); } else { const int extra_stack_entries = 2; // MUST match the value in methodOopDesc::extra_stack_entries() assert(labs(istate->_stack_base - istate->_stack_limit) == (istate->_method->max_stack() + extra_stack_entries + 1), "bad stack limit"); } You can see the actual patch we did at: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/diff/61615792f0fe/src/share/vm/interpreter/bytecodeInterpreter.cpp Regards, Volker -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130403/940bba24/attachment.html From roland.westrelin at oracle.com Wed Apr 3 05:42:31 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 3 Apr 2013 14:42:31 +0200 Subject: RFR(XS) 8006008: [parfait] Memory leak at hotspot/src/share/vm/adlc/archDesc.cpp In-Reply-To: References: Message-ID: <51043661-778D-4DA2-8317-422D3CC6F54F@oracle.com> It looks good. Roland. From roland.westrelin at oracle.com Wed Apr 3 06:36:00 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 3 Apr 2013 15:36:00 +0200 Subject: RFR (M): 8011102: Clear AVX registers after return from JNI call In-Reply-To: <515B289E.7050203@oracle.com> References: <5150EADD.2050707@oracle.com> <515B289E.7050203@oracle.com> Message-ID: > http://cr.openjdk.java.net/~kvn/8011102/webrev/ It looks good. pre_call_FPU and pre_call_FPU_size should maybe be renamed. Roland. From roland.westrelin at oracle.com Wed Apr 3 07:03:59 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 3 Apr 2013 16:03:59 +0200 Subject: RFR (XS): 8010460: Interpreter on some platforms loads ConstMethod::_max_stack and misses extra stack slots for JSR 292 In-Reply-To: References: <6B922316-9630-4955-9A42-8FA52D5571F6@oracle.com> <4CA94106-1D2A-4DF2-814E-DF2F7A190B60@oracle.com> <8A8F768B-D0E2-46C1-AEC2-ED2FAA88EA09@oracle.com> Message-ID: <78E3C02A-9A65-4658-9024-D7E33F84FDA5@oracle.com> Hi Volker, > this issue is almost the same as: > > 8002087 : JSR 292: max_stack issues in interpreter code after JSR-292 merge > (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8002087) > > I think besides the oop map problem (in OopMapForCacheEntry::compute_map) your change fixes all other issues described there. Thanks. I wasn't aware of this one. I've linked the 2 bugs in the database. > On Fri, Mar 29, 2013 at 7:22 PM, Roland Westrelin wrote: > Thanks for reviewing this. > > > Good. It's time to get rid of the //6815692// stuff. The extra_stack variables (always zero now) can go away too. > > I'm not sure what to do with this: > guarantee(!EnableInvokeDynamic, "no support yet for java.lang.invoke.MethodHandle"); //6815692 > //6815692//if (EnableInvokeDynamic) > //6815692// __ inc(O3, Method::extra_stack_entries()); > > in cppInterpreter_sparc.cpp > > > Well, it wouldn't work anyway if running with 'EnableInvokeDynamic' enabled. > But you have: > 1217 __ lduh(O3, in_bytes(ConstMethod::max_stack_offset()), O3); > 1218 guarantee(!EnableInvokeDynamic, "no support yet for java.lang.invoke.MethodHandle"); //6815692 > 1219 //6815692//if (EnableInvokeDynamic) > 1220 //6815692// __ inc(O3, Method::extra_stack_entries()); > > and now, after your change, max_stack automatically accounts for the extra stack entries, so I'd delete the lines: > 1219 //6815692//if (EnableInvokeDynamic) > 1220 //6815692// __ inc(O3, Method::extra_stack_entries()); > > Just for the case that somebody ever wants to implement 'EnableInvokeDynamic' for the CPP-interpreter on SPARC. Maybe you could also remove the guarantee and hope for the best.. I'll go with your suggestion. I'll let Christian or John comment on the change below. Roland. > You may also consider to fix another problem which only occurs if you use a hsx24 or later with pre-hsx24 class library (i.e. if building hsx24/hsx25 with a pre-hsx24 bootstrap JDK). It is an assertion in bytecodeInterpreter.cpp: > > // We have a problem here if we are running with a pre-hsx24 JDK (for example during bootstrap) > // because in that case, EnableInvokeDynamic is true by default but will be later switched off > // if java_lang_invoke_MethodHandle::compute_offsets() detects that the JDK only has the classes > > // for the old JSR292 implementation. > > // This leads to a situation where 'istate->_stack_limit' always accounts for > // methodOopDesc::extra_stack_entries() because it is computed in > // CppInterpreterGenerator::generate_compute_interpreter_state() which was generated while > > // EnableInvokeDynamic was still true. On the other hand, istate->_method->max_stack() doesn't > > // account for extra_stack_entries() anymore because at the time when it is called > // EnableInvokeDynamic was already set to false. > > // So we have a second version of the assertion which handles the case where EnableInvokeDynamic was > > // switched off because of the wrong classes. > if (EnableInvokeDynamic || FLAG_IS_CMDLINE(EnableInvokeDynamic)) { > > assert(labs(istate->_stack_base - istate->_stack_limit) == (istate->_method->max_stack() + 1), "bad stack limit"); > > } > else { > const int extra_stack_entries = 2; // MUST match the value in methodOopDesc::extra_stack_entries() > > assert(labs(istate->_stack_base - istate->_stack_limit) == (istate->_method->max_stack() + extra_stack_entries > > + 1), "bad stack limit"); > > } > > You can see the actual patch we did at: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/diff/61615792f0fe/src/share/vm/interpreter/bytecodeInterpreter.cpp From vladimir.kozlov at oracle.com Wed Apr 3 07:34:50 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Apr 2013 07:34:50 -0700 Subject: RFR(XS) 8006008: [parfait] Memory leak at hotspot/src/share/vm/adlc/archDesc.cpp In-Reply-To: References: Message-ID: <515C3E0A.9080908@oracle.com> Good. Thanks, Vladimir On 4/3/13 4:58 AM, Niclas Adlertz wrote: > Hi all. > > A very small parfait fix. A review would be much appreciated. > Thank you. > > Regards, > Niclas Adlertz > > ----------------------------------------------------------------- > webrev: http://cr.openjdk.java.net/~adlertz/JDK-8006008/webrev00/ > jbs: https://jbs.oracle.com/bugs/browse/JDK-8006008 > bugs: http://bugs.sun.com/view_bug.do?bug_id=8006008 > > From vladimir.kozlov at oracle.com Wed Apr 3 07:41:54 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Apr 2013 07:41:54 -0700 Subject: RFR (M): 8011102: Clear AVX registers after return from JNI call In-Reply-To: References: <5150EADD.2050707@oracle.com> <515B289E.7050203@oracle.com> Message-ID: <515C3FB2.70607@oracle.com> Thank you, Roland How about pre_call_resets? Thanks, Vladimir On 4/3/13 6:36 AM, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~kvn/8011102/webrev/ > > It looks good. > pre_call_FPU and pre_call_FPU_size should maybe be renamed. > > Roland. > From roland.westrelin at oracle.com Wed Apr 3 07:42:32 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 3 Apr 2013 16:42:32 +0200 Subject: RFR (M): 8011102: Clear AVX registers after return from JNI call In-Reply-To: <515C3FB2.70607@oracle.com> References: <5150EADD.2050707@oracle.com> <515B289E.7050203@oracle.com> <515C3FB2.70607@oracle.com> Message-ID: <03C0ADA4-7FCB-4F43-B9EF-CB491090324A@oracle.com> > How about pre_call_resets? It's ok with me. Thanks, Roland. From niclas.adlertz at oracle.com Wed Apr 3 08:24:55 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Wed, 3 Apr 2013 17:24:55 +0200 Subject: RFR(XS) 8006008: [parfait] Memory leak at hotspot/src/share/vm/adlc/archDesc.cpp In-Reply-To: <515C3E0A.9080908@oracle.com> References: <515C3E0A.9080908@oracle.com> Message-ID: Thank you Vladimir and Roland. Regards, Niclas Adlertz On 3 apr 2013, at 16:34, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 4/3/13 4:58 AM, Niclas Adlertz wrote: >> Hi all. >> >> A very small parfait fix. A review would be much appreciated. >> Thank you. >> >> Regards, >> Niclas Adlertz >> >> ----------------------------------------------------------------- >> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8006008/webrev00/ >> jbs: https://jbs.oracle.com/bugs/browse/JDK-8006008 >> bugs: http://bugs.sun.com/view_bug.do?bug_id=8006008 >> >> From niclas.adlertz at oracle.com Wed Apr 3 08:38:33 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Wed, 3 Apr 2013 17:38:33 +0200 Subject: RFR(XXS) 8006014: [parfait] Memory leak at hotspot/src/share/vm/adlc/dfa.cpp Message-ID: Hi all. A very small parfait fix. A review would be much appreciated. Thank you. Regards, Niclas Adlertz ----------------------------------------------------------------- webrev: http://cr.openjdk.java.net/~adlertz/JDK-8006014/webrev00/ jbs: https://jbs.oracle.com/bugs/browse/JDK-8006014 bugs: http://bugs.sun.com/view_bug.do?bug_id=8006014 From niclas.adlertz at oracle.com Wed Apr 3 08:55:31 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Wed, 3 Apr 2013 17:55:31 +0200 Subject: RFR(XXS) 8006016: [parfait] Memory leak at hotspot/src/share/vm/adlc/output_c.cpp & output_h.cpp Message-ID: <2F77284B-7D68-4EE6-AE80-D6F88E6F3203@oracle.com> Hi all. A small parfait fix. A review would be much appreciated. Thank you. Regards, Niclas Adlertz ----------------------------------------------------------------- webrev: http://cr.openjdk.java.net/~adlertz/JDK-8006016/webrev00/ jbs: https://jbs.oracle.com/bugs/browse/JDK-8006016 bugs: http://bugs.sun.com/view_bug.do?bug_id=8006016 From roland.westrelin at oracle.com Wed Apr 3 08:56:52 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 3 Apr 2013 17:56:52 +0200 Subject: RFR(XXS) 8006014: [parfait] Memory leak at hotspot/src/share/vm/adlc/dfa.cpp In-Reply-To: References: Message-ID: <377F5103-C0EE-48BB-8134-FEAB918C660D@oracle.com> It looks good. Roland. From roland.westrelin at oracle.com Wed Apr 3 09:18:01 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 3 Apr 2013 18:18:01 +0200 Subject: RFR(XXS) 8006016: [parfait] Memory leak at hotspot/src/share/vm/adlc/output_c.cpp & output_h.cpp In-Reply-To: <2F77284B-7D68-4EE6-AE80-D6F88E6F3203@oracle.com> References: <2F77284B-7D68-4EE6-AE80-D6F88E6F3203@oracle.com> Message-ID: It looks good. Roland. From vladimir.kozlov at oracle.com Wed Apr 3 10:25:57 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Apr 2013 10:25:57 -0700 Subject: RFR(XXS) 8006014: [parfait] Memory leak at hotspot/src/share/vm/adlc/dfa.cpp In-Reply-To: References: Message-ID: <515C6625.4020605@oracle.com> Niclas, We have agreement that we fix code style in touched code (and may be a little surrounding also): < if( mList._lchild ) { --- > if (mList._lchild) { Also one of comments was moved to next line with strange indention. Please, fix it. And we don't need so many spaces between "} //". The code fix is good. Thanks, Vladimir On 4/3/13 8:38 AM, Niclas Adlertz wrote: > Hi all. > > A very small parfait fix. A review would be much appreciated. > Thank you. > > Regards, > Niclas Adlertz > > ----------------------------------------------------------------- > webrev: http://cr.openjdk.java.net/~adlertz/JDK-8006014/webrev00/ > jbs: https://jbs.oracle.com/bugs/browse/JDK-8006014 > bugs: http://bugs.sun.com/view_bug.do?bug_id=8006014 > > From vladimir.kozlov at oracle.com Wed Apr 3 10:33:55 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Apr 2013 10:33:55 -0700 Subject: RFR(XXS) 8006016: [parfait] Memory leak at hotspot/src/share/vm/adlc/output_c.cpp & output_h.cpp In-Reply-To: <2F77284B-7D68-4EE6-AE80-D6F88E6F3203@oracle.com> References: <2F77284B-7D68-4EE6-AE80-D6F88E6F3203@oracle.com> Message-ID: <515C6803.5050301@oracle.com> Niclas, Fix code style in output_c.cpp, otherwise it is good. Changes in output_h.cpp are good. Thanks, Vladimir On 4/3/13 8:55 AM, Niclas Adlertz wrote: > Hi all. > > A small parfait fix. A review would be much appreciated. > Thank you. > > Regards, > Niclas Adlertz > > ----------------------------------------------------------------- > webrev: http://cr.openjdk.java.net/~adlertz/JDK-8006016/webrev00/ > jbs: https://jbs.oracle.com/bugs/browse/JDK-8006016 > bugs: http://bugs.sun.com/view_bug.do?bug_id=8006016 > > From niclas.adlertz at oracle.com Wed Apr 3 11:48:46 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Wed, 3 Apr 2013 20:48:46 +0200 Subject: RFR(XXS) 8006014: [parfait] Memory leak at hotspot/src/share/vm/adlc/dfa.cpp In-Reply-To: <515C6625.4020605@oracle.com> References: <515C6625.4020605@oracle.com> Message-ID: <0D1E1C6A-1E3B-41D8-AADD-AB46C0EE302B@oracle.com> Thank you Roland. Thank you Vladimir. I've fixed the coding style. http://cr.openjdk.java.net/~adlertz/JDK-8006014/webrev02/ Regards, Niclas Adlertz On 3 apr 2013, at 19:25, Vladimir Kozlov wrote: > Niclas, > > We have agreement that we fix code style in touched code (and may be a little surrounding also): > < if( mList._lchild ) { > --- > > if (mList._lchild) { > > Also one of comments was moved to next line with strange indention. Please, fix it. And we don't need so many spaces between "} //". > > The code fix is good. > > Thanks, > Vladimir > > On 4/3/13 8:38 AM, Niclas Adlertz wrote: >> Hi all. >> >> A very small parfait fix. A review would be much appreciated. >> Thank you. >> >> Regards, >> Niclas Adlertz >> >> ----------------------------------------------------------------- >> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8006014/webrev00/ >> jbs: https://jbs.oracle.com/bugs/browse/JDK-8006014 >> bugs: http://bugs.sun.com/view_bug.do?bug_id=8006014 >> >> From vladimir.kozlov at oracle.com Wed Apr 3 12:02:17 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Apr 2013 12:02:17 -0700 Subject: RFR(XXS) 8006014: [parfait] Memory leak at hotspot/src/share/vm/adlc/dfa.cpp In-Reply-To: <0D1E1C6A-1E3B-41D8-AADD-AB46C0EE302B@oracle.com> References: <515C6625.4020605@oracle.com> <0D1E1C6A-1E3B-41D8-AADD-AB46C0EE302B@oracle.com> Message-ID: <515C7CB9.9090809@oracle.com> Good. Thanks, Vladimir On 4/3/13 11:48 AM, Niclas Adlertz wrote: > Thank you Roland. > Thank you Vladimir. > > I've fixed the coding style. > > http://cr.openjdk.java.net/~adlertz/JDK-8006014/webrev02/ > > Regards, > Niclas Adlertz > > On 3 apr 2013, at 19:25, Vladimir Kozlov wrote: > >> Niclas, >> >> We have agreement that we fix code style in touched code (and may be a little surrounding also): >> < if( mList._lchild ) { >> --- >>> if (mList._lchild) { >> >> Also one of comments was moved to next line with strange indention. Please, fix it. And we don't need so many spaces between "} //". >> >> The code fix is good. >> >> Thanks, >> Vladimir >> >> On 4/3/13 8:38 AM, Niclas Adlertz wrote: >>> Hi all. >>> >>> A very small parfait fix. A review would be much appreciated. >>> Thank you. >>> >>> Regards, >>> Niclas Adlertz >>> >>> ----------------------------------------------------------------- >>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8006014/webrev00/ >>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8006014 >>> bugs: http://bugs.sun.com/view_bug.do?bug_id=8006014 >>> >>> > From christian.thalinger at oracle.com Wed Apr 3 12:22:41 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 3 Apr 2013 12:22:41 -0700 Subject: RFR (S): 8010913 : compiler/6863420 often exceeds timeout In-Reply-To: <8EF78437-8AC7-4475-B4C3-3ECD0896B8D4@oracle.com> References: <4FF7D604-759B-497A-B75D-DACE0755F43D@oracle.com> <5159D990.9000306@oracle.com> <8EF78437-8AC7-4475-B4C3-3ECD0896B8D4@oracle.com> Message-ID: <289773D9-A850-4B9F-B083-FD47C0CB1398@oracle.com> Thanks. Looks good. -- Chris On Apr 2, 2013, at 7:21 AM, David Chase wrote: > http://cr.openjdk.java.net/~drchase/8010913/webrev.01/ > > On 2013-04-01, at 3:01 PM, Vladimir Kozlov wrote: > >> Main loop should also check 'done': >> >> for (int numThreads = 1; numThreads <= 32; numThreads++) { >> >> Thanks, >> Vladimir >> >> On 3/28/13 10:45 AM, David Chase wrote: >>> Problem: >>> The test runs over-long on some test machines, causing timeouts and spurious failures >>> if JPRT is used to check compiler tests across a range of machines. >>> A four-minute run was observed in one case. >>> >>> Fix: >>> Add an increased timeout and a timeout thread for shutting down the test early. >>> >>> Testing: >>> JPRT of that test across all available platforms with an artificially short timeout >>> to ensure that the timeout thread worked as expected, manual check of successful >>> runs to be sure that the timeout thread did its job (i.e., saw runs for a hair more than >>> the time limit, as well as short runs). >>> >>> webrev: >>> http://cr.openjdk.java.net/~drchase/8010913/webrev.00/ >>> > From christian.thalinger at oracle.com Wed Apr 3 12:33:36 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 3 Apr 2013 12:33:36 -0700 Subject: RFR (XS): 8010460: Interpreter on some platforms loads ConstMethod::_max_stack and misses extra stack slots for JSR 292 In-Reply-To: References: <6B922316-9630-4955-9A42-8FA52D5571F6@oracle.com> <4CA94106-1D2A-4DF2-814E-DF2F7A190B60@oracle.com> <8A8F768B-D0E2-46C1-AEC2-ED2FAA88EA09@oracle.com> Message-ID: On Apr 3, 2013, at 5:06 AM, Volker Simonis wrote: > Hi Roland, > > this issue is almost the same as: > > 8002087 : JSR 292: max_stack issues in interpreter code after JSR-292 merge > (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8002087) > > I think besides the oop map problem (in OopMapForCacheEntry::compute_map) your change fixes all other issues described there. > > On Fri, Mar 29, 2013 at 7:22 PM, Roland Westrelin wrote: > Thanks for reviewing this. > > > Good. It's time to get rid of the //6815692// stuff. The extra_stack variables (always zero now) can go away too. > > I'm not sure what to do with this: > guarantee(!EnableInvokeDynamic, "no support yet for java.lang.invoke.MethodHandle"); //6815692 > //6815692//if (EnableInvokeDynamic) > //6815692// __ inc(O3, Method::extra_stack_entries()); > > in cppInterpreter_sparc.cpp > > > Well, it wouldn't work anyway if running with 'EnableInvokeDynamic' enabled. > But you have: > 1217 __ lduh(O3, in_bytes(ConstMethod::max_stack_offset()), O3); > 1218 guarantee(!EnableInvokeDynamic, "no support yet for java.lang.invoke.MethodHandle"); //6815692 > 1219 //6815692//if (EnableInvokeDynamic) > 1220 //6815692// __ inc(O3, Method::extra_stack_entries()); > and now, after your change, max_stack automatically accounts for the extra stack entries, so I'd delete the lines: > 1219 //6815692//if (EnableInvokeDynamic) > 1220 //6815692// __ inc(O3, Method::extra_stack_entries()); > Just for the case that somebody ever wants to implement 'EnableInvokeDynamic' for the CPP-interpreter on SPARC. Maybe you could also remove the guarantee and hope for the best.. > > For our ppc-port (http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/file/tip/src/cpu/ppc/vm/cppInterpreter_ppc.cpp) I've fixed this by inserting: > __ ppc_lhz(max_stack, method_(max_stack)); > > if (EnableInvokeDynamic) { > // Take into account 'extra_stack_entries' needed by method handles (see method.hpp) > __ ppc_addi(max_stack, max_stack, methodOopDesc::extra_stack_entries()); > > } > but that's not necessary anymore, after your change. > > > I think extra_stack_words can be deleted, and extra_stack_entries can be made private to Method. > > > > This line of code is redundant in src/cpu/x86/vm/templateInterpreter_x86_{32,64}.cpp: > > const int extra_stack = Method::extra_stack_entries(); > > I applied Christian's suggestions and yours and found a reference to Method::extra_stack_entries() in c2 that I assume can be removed. Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8010460/webrev.01/ > > Roland. > > You may also consider to fix another problem which only occurs if you use a hsx24 or later with pre-hsx24 class library (i.e. if building hsx24/hsx25 with a pre-hsx24 bootstrap JDK). It is an assertion in bytecodeInterpreter.cpp: > > // We have a problem here if we are running with a pre-hsx24 JDK (for example during bootstrap) > // because in that case, EnableInvokeDynamic is true by default but will be later switched off > // if java_lang_invoke_MethodHandle::compute_offsets() detects that the JDK only has the classes > > // for the old JSR292 implementation. > // This leads to a situation where 'istate->_stack_limit' always accounts for > // methodOopDesc::extra_stack_entries() because it is computed in > // CppInterpreterGenerator::generate_compute_interpreter_state() which was generated while > > // EnableInvokeDynamic was still true. On the other hand, istate->_method->max_stack() doesn't > // account for extra_stack_entries() anymore because at the time when it is called > // EnableInvokeDynamic was already set to false. > > // So we have a second version of the assertion which handles the case where EnableInvokeDynamic was > // switched off because of the wrong classes. > if (EnableInvokeDynamic || FLAG_IS_CMDLINE(EnableInvokeDynamic)) { > > assert(labs(istate->_stack_base - istate->_stack_limit) == (istate->_method->max_stack() + 1), "bad stack limit"); > } > else { > const int extra_stack_entries = 2; // MUST match the value in methodOopDesc::extra_stack_entries() > > assert(labs(istate->_stack_base - istate->_stack_limit) == (istate->_method->max_stack() + extra_stack_entries > + 1), "bad stack limit"); > > } Oh boy. I'm not sure if that bootstrap problem still exists. Could someone verify that? -- Chris > You can see the actual patch we did at: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/diff/61615792f0fe/src/share/vm/interpreter/bytecodeInterpreter.cpp > > Regards, > Volker > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130403/cb768a39/attachment.html From igor.ignatyev at oracle.com Wed Apr 3 12:35:05 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 03 Apr 2013 23:35:05 +0400 Subject: RFR(M): 8007288: Additional WB API for compiler's testing In-Reply-To: <515B2F49.7050305@oracle.com> References: <5154B8F1.2030108@oracle.com> <0549160A-DBFE-42A8-9AAE-AC98CB066D09@oracle.com> <51599671.4090501@oracle.com> <5159C42E.7000208@oracle.com> <515A9B8A.6040503@oracle.com> <515B2F49.7050305@oracle.com> Message-ID: <515C8469.40901@oracle.com> >>> compileBroker.cpp - add assert() to check that. >> If I add it, WB.enqueueMethodForCompilation() will trigger this assert, >> e.g. in test 'compiler/whitebox/EnqueueMethodForCompilationTest'. > > Which means the test introduces the case which never happens in normal > execution. I am not sure it is good or bad. > You can relax assert with WhiteBoxAPI check. I really want this assert > for normal execution. i added assert and changed 'NonTieredCompPolicy::initial_compile_level' since it return 'CompLevel_full_profile' instead of 'CompLevel_full_optimization' for non-tiered C2 with Xcomp. sorry, i missed this it due to poor preprocessor in my brain. >>> compilationPolicy.cpp - I don't think the change is correct since >>> is_compile(CompLevel_any) returns false. >> 'comp_level == CompLevel_any' is the same that 'comp_level == >> CompLevel_all' and this situation is processed in >> compilationPolicy.cpp:124, so I think that it's correct, isn't it? >> I can add explicit checking for equality to 'CompLevel_any'. should i add this check? > You are right about CompLevel_any. What about next check in > m->is_not_compilable(): > > if (is_method_handle_intrinsic()) > return !is_synthetic(); // the generated adapters must be compiled > even if CompilationPolicy::can_be_compiled() return 'true' for invalid comp_level, method won't be compiled since CompileBroker::compiler(comp_level) will be 'NULL' in CompileBroker::compile_method(): AbstractCompiler *comp = CompileBroker::compiler(comp_level); if (comp == NULL || !comp->can_compile_method(method) || compilation_is_prohibited(method, osr_bci, comp_level)) { return NULL; } updated webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.02/ Best regards, Igor Ignatyev On 04/02/2013 11:19 PM, Vladimir Kozlov wrote: > On 4/2/13 1:49 AM, Igor Ignatyev wrote: >> > compileBroker.cpp - add assert() to check that. >> If I add it, WB.enqueueMethodForCompilation() will trigger this assert, >> e.g. in test 'compiler/whitebox/EnqueueMethodForCompilationTest'. > > Which means the test introduces the case which never happens in normal > execution. I am not sure it is good or bad. > You can relax assert with WhiteBoxAPI check. I really want this assert > for normal execution. > >> >> > compilationPolicy.cpp - I don't think the change is correct since >> > is_compile(CompLevel_any) returns false. >> 'comp_level == CompLevel_any' is the same that 'comp_level == >> CompLevel_all' and this situation is processed in >> compilationPolicy.cpp:124, so I think that it's correct, isn't it? >> I can add explicit checking for equality to 'CompLevel_any'. > > You are right about CompLevel_any. What about next check in > m->is_not_compilable(): > > if (is_method_handle_intrinsic()) > return !is_synthetic(); // the generated adapters must be compiled > > Thanks, > Vladimir > >> >>> Could you rename setForceInlineMethod() to testSetForceInlineMethod() to >>> be more clear what it does? >> I will rename setForceInlineMethod() and setDontInlineMethod(). >> >> Best regards, >> Igor Ignatyev >> >> On 04/01/2013 09:30 PM, Vladimir Kozlov wrote: >>> compileBroker.cpp - add assert() to check that. >>> >>> compilationPolicy.cpp - I don't think the change is correct since >>> is_compile(CompLevel_any) returns false. >>> >>> Could you rename setForceInlineMethod() to testSetForceInlineMethod() to >>> be more clear what it does? >>> >>> Thanks, >>> Vladimir >>> >>> On 4/1/13 7:15 AM, Igor Ignatyev wrote: >>>> test 'compiler/whitebox/EnqueueMethodForCompilationTest' has failed >>>> during testing, because 'CompilationPolicy::can_be_compiled()' returns >>>> 'true' for invalid comp_level (less that -1 or great that 4). >>>> >>>> i added method 'is_compile' to check whether a value is valid level of >>>> compilation and rerun jprt. >>>> >>>> in new results: >>>> - compiler/whitebox/IsMethodCompilableTest failed on on *-i586-*-c1 >>>> due to JDK-8007270 >>>> - timeouts in other compiler's tests: >>>> * compiler/6663848/Tester >>>> * compiler/6711100/Test >>>> * compiler/6792161/Test6792161 >>>> * compiler/6863420/Test >>>> * compiler/6863420/Test >>>> * compiler/6901572/Test >>>> * compiler/7100757/Test7100757 >>>> * compiler/7119644/TestFloatVect >>>> * compiler/7196199/Test7196199 >>>> * compiler/7199742/Test7199742 >>>> >>>> updated webrev: >>>> http://cr.openjdk.java.net/~iignatyev/8007288/webrev.01/ >>>> >>>> Best regards, >>>> Igor Ignatyev >>>> >>>> On 03/29/2013 01:52 AM, David Chase wrote: >>>>> (Not a reviewer) >>>>> >>>>> Could you run these tests on the "east" JPRT queue and see if they >>>>> have any problems there? >>>>> We seem to have some surprisingly slow machines there, and that has >>>>> caused problems with other tests. >>>>> >>>>> David >>>>> >>>>> >>>>> On 2013-03-28, at 5:41 PM, Igor Ignatyev >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Please review the patch. >>>>>> >>>>>> 1. added new functions to WhiteBox: >>>>>> public native boolean setForceInlineMethod(Method method, boolean >>>>>> value); >>>>>> public native boolean enqueueMethodForCompilation(Method method, >>>>>> int compLevel); >>>>>> public native void clearMethodState(Method method); >>>>>> 2. related changes in not whitebox code: >>>>>> - added 'Method::clear_not_*_compilable()' and corresponded >>>>>> 'AccessFlags::clear_not_*_compilable()' >>>>>> - added 'MethodData::init()' - reset method data into original >>>>>> state. reset all counters, flags >>>>>> 3. removed useless code: >>>>>> - 'if (!TieredCompilation) { comp_level = CompLevel_highest_tier; >>>>>> }' in CompileBroker::compile_method() -- there is no method calls w/ >>>>>> comp_level != CompLevel_highest_tier in non-tiered >>>>>> - 'MethodData::initialize(methodHandle method)' -- declaration w/o >>>>>> definition >>>>>> 4. added tests for new WB functions >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.00/ >>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8007288 >>>>>> -- >>>>>> Best regards, >>>>>> Igor Ignatyev >>>>> From vladimir.kozlov at oracle.com Wed Apr 3 13:23:30 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Apr 2013 13:23:30 -0700 Subject: RFR(M): 8007288: Additional WB API for compiler's testing In-Reply-To: <515C8469.40901@oracle.com> References: <5154B8F1.2030108@oracle.com> <0549160A-DBFE-42A8-9AAE-AC98CB066D09@oracle.com> <51599671.4090501@oracle.com> <5159C42E.7000208@oracle.com> <515A9B8A.6040503@oracle.com> <515B2F49.7050305@oracle.com> <515C8469.40901@oracle.com> Message-ID: <515C8FC2.2010900@oracle.com> >>> I can add explicit checking for equality to 'CompLevel_any'. > should i add this check? I don't think it is needed. May be comment. You convinced me about changes in CompilationPolicy::can_be_compiled(). Now, why you need new changes in compilationPolicy.hpp? It was not in previous webrev. Yes, it may be correct but why? Vladimir On 4/3/13 12:35 PM, Igor Ignatyev wrote: > >>> compileBroker.cpp - add assert() to check that. > >> If I add it, WB.enqueueMethodForCompilation() will trigger this assert, > >> e.g. in test 'compiler/whitebox/EnqueueMethodForCompilationTest'. > > > > Which means the test introduces the case which never happens in normal > > execution. I am not sure it is good or bad. > > You can relax assert with WhiteBoxAPI check. I really want this assert > > for normal execution. > i added assert and changed 'NonTieredCompPolicy::initial_compile_level' > since it return 'CompLevel_full_profile' instead of > 'CompLevel_full_optimization' for non-tiered C2 with Xcomp. sorry, i > missed this it due to poor preprocessor in my brain. > >>>> compilationPolicy.cpp - I don't think the change is correct since >>>> is_compile(CompLevel_any) returns false. >>> 'comp_level == CompLevel_any' is the same that 'comp_level == >>> CompLevel_all' and this situation is processed in >>> compilationPolicy.cpp:124, so I think that it's correct, isn't it? >>> I can add explicit checking for equality to 'CompLevel_any'. > should i add this check? > >> You are right about CompLevel_any. What about next check in >> m->is_not_compilable(): >> >> if (is_method_handle_intrinsic()) >> return !is_synthetic(); // the generated adapters must be compiled >> > even if CompilationPolicy::can_be_compiled() return 'true' for invalid > comp_level, method won't be compiled since > CompileBroker::compiler(comp_level) will be 'NULL' in > CompileBroker::compile_method(): > > AbstractCompiler *comp = CompileBroker::compiler(comp_level); > if (comp == NULL || !comp->can_compile_method(method) || > compilation_is_prohibited(method, osr_bci, comp_level)) { > return NULL; > } > > updated webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.02/ > > Best regards, > Igor Ignatyev > > On 04/02/2013 11:19 PM, Vladimir Kozlov wrote: >> On 4/2/13 1:49 AM, Igor Ignatyev wrote: >>> > compileBroker.cpp - add assert() to check that. >>> If I add it, WB.enqueueMethodForCompilation() will trigger this assert, >>> e.g. in test 'compiler/whitebox/EnqueueMethodForCompilationTest'. >> >> Which means the test introduces the case which never happens in normal >> execution. I am not sure it is good or bad. >> You can relax assert with WhiteBoxAPI check. I really want this assert >> for normal execution. >> >>> >>> > compilationPolicy.cpp - I don't think the change is correct since >>> > is_compile(CompLevel_any) returns false. >>> 'comp_level == CompLevel_any' is the same that 'comp_level == >>> CompLevel_all' and this situation is processed in >>> compilationPolicy.cpp:124, so I think that it's correct, isn't it? >>> I can add explicit checking for equality to 'CompLevel_any'. >> >> You are right about CompLevel_any. What about next check in >> m->is_not_compilable(): >> >> if (is_method_handle_intrinsic()) >> return !is_synthetic(); // the generated adapters must be compiled >> >> Thanks, >> Vladimir >> >>> >>>> Could you rename setForceInlineMethod() to >>>> testSetForceInlineMethod() to >>>> be more clear what it does? >>> I will rename setForceInlineMethod() and setDontInlineMethod(). >>> >>> Best regards, >>> Igor Ignatyev >>> >>> On 04/01/2013 09:30 PM, Vladimir Kozlov wrote: >>>> compileBroker.cpp - add assert() to check that. >>>> >>>> compilationPolicy.cpp - I don't think the change is correct since >>>> is_compile(CompLevel_any) returns false. >>>> >>>> Could you rename setForceInlineMethod() to >>>> testSetForceInlineMethod() to >>>> be more clear what it does? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/1/13 7:15 AM, Igor Ignatyev wrote: >>>>> test 'compiler/whitebox/EnqueueMethodForCompilationTest' has failed >>>>> during testing, because 'CompilationPolicy::can_be_compiled()' returns >>>>> 'true' for invalid comp_level (less that -1 or great that 4). >>>>> >>>>> i added method 'is_compile' to check whether a value is valid level of >>>>> compilation and rerun jprt. >>>>> >>>>> in new results: >>>>> - compiler/whitebox/IsMethodCompilableTest failed on on *-i586-*-c1 >>>>> due to JDK-8007270 >>>>> - timeouts in other compiler's tests: >>>>> * compiler/6663848/Tester >>>>> * compiler/6711100/Test >>>>> * compiler/6792161/Test6792161 >>>>> * compiler/6863420/Test >>>>> * compiler/6863420/Test >>>>> * compiler/6901572/Test >>>>> * compiler/7100757/Test7100757 >>>>> * compiler/7119644/TestFloatVect >>>>> * compiler/7196199/Test7196199 >>>>> * compiler/7199742/Test7199742 >>>>> >>>>> updated webrev: >>>>> http://cr.openjdk.java.net/~iignatyev/8007288/webrev.01/ >>>>> >>>>> Best regards, >>>>> Igor Ignatyev >>>>> >>>>> On 03/29/2013 01:52 AM, David Chase wrote: >>>>>> (Not a reviewer) >>>>>> >>>>>> Could you run these tests on the "east" JPRT queue and see if they >>>>>> have any problems there? >>>>>> We seem to have some surprisingly slow machines there, and that has >>>>>> caused problems with other tests. >>>>>> >>>>>> David >>>>>> >>>>>> >>>>>> On 2013-03-28, at 5:41 PM, Igor Ignatyev >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Please review the patch. >>>>>>> >>>>>>> 1. added new functions to WhiteBox: >>>>>>> public native boolean setForceInlineMethod(Method method, boolean >>>>>>> value); >>>>>>> public native boolean enqueueMethodForCompilation(Method method, >>>>>>> int compLevel); >>>>>>> public native void clearMethodState(Method method); >>>>>>> 2. related changes in not whitebox code: >>>>>>> - added 'Method::clear_not_*_compilable()' and corresponded >>>>>>> 'AccessFlags::clear_not_*_compilable()' >>>>>>> - added 'MethodData::init()' - reset method data into original >>>>>>> state. reset all counters, flags >>>>>>> 3. removed useless code: >>>>>>> - 'if (!TieredCompilation) { comp_level = CompLevel_highest_tier; >>>>>>> }' in CompileBroker::compile_method() -- there is no method calls w/ >>>>>>> comp_level != CompLevel_highest_tier in non-tiered >>>>>>> - 'MethodData::initialize(methodHandle method)' -- declaration w/o >>>>>>> definition >>>>>>> 4. added tests for new WB functions >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.00/ >>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8007288 >>>>>>> -- >>>>>>> Best regards, >>>>>>> Igor Ignatyev >>>>>> From vladimir.kozlov at oracle.com Wed Apr 3 14:49:56 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 03 Apr 2013 21:49:56 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8011102: Clear AVX registers after return from JNI call Message-ID: <20130403215000.D9371485A0@hg.openjdk.java.net> Changeset: e961c11b85fe Author: kvn Date: 2013-04-03 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e961c11b85fe 8011102: Clear AVX registers after return from JNI call Summary: Execute vzeroupper instruction after JNI call and on exits in jit compiled code which use 256bit vectors. Reviewed-by: roland ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/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/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/bsd_x86/vm/bsd_x86_64.ad ! src/os_cpu/linux_x86/vm/linux_x86_64.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_64.ad ! src/os_cpu/windows_x86/vm/windows_x86_64.ad From vladimir.kozlov at oracle.com Wed Apr 3 15:49:42 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Apr 2013 15:49:42 -0700 Subject: RFR (M): guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset In-Reply-To: References: <514A61EE.4030600@oracle.com> Message-ID: <515CB206.7090608@oracle.com> Hi Chuck I finally have time to spend on this. The fix is good and changes did cleanup a mess we had. I verified the failure and the fix with CTW rt.jar and new guarantee() as you suggested. I will push the fix shortly after finish testing. Thanks, Vladimir On 3/22/13 9:52 AM, Chuck Rasbold wrote: > Thanks, Vladimir. > > I've updated the webrev so that it reflects bug number 8010437. > > http://cr.openjdk.java.net/~rasbold/8010437/webrev.00/ > > > On Wed, Mar 20, 2013 at 6:27 PM, Vladimir Kozlov > > wrote: > > Thank you, Chuck > > I created bug 8010437 and will work on the patch. > > Thanks, > Vladimir > > On 3/20/13 10:02 AM, Chuck Rasbold wrote: > > http://cr.openjdk.java.net/~__rasbold/XXXXXXX/webrev.00/ > > > > > > We occasionally get this guarantee failure from an older JVM > (HotSpot > 22): > > # Internal Error (assembler_x86.inline.hpp:46) > # guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds > # 8-bit offset > > I'm encountering a case in C2 where a branch is incorrectly > converted to a short branch under very specific conditions. The root > cause occurs when a call and safepoint are adjacent in > consecutive blocks. In shorten_branches(), an off-by-one > error exists in calculating the size of the trailing (safepoint) > block > when it > potentially requires loop padding. > > This bug still exists in the current HotSpot 25, although I > don't have > a testcase that reproduces there. > > However, with the improved guarantee from my webrev, but without the > actual fix, a hs25 CTW run on rt.jar fails. > > Can a bug be opened? Can I get an Oracle engineer to sponsor and > review my change? > > > From vladimir.kozlov at oracle.com Wed Apr 3 18:29:55 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 04 Apr 2013 01:29:55 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8010437: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset Message-ID: <20130404012959.4A62A485AD@hg.openjdk.java.net> Changeset: 0a8c2ea3902d Author: rasbold Date: 2013-04-03 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0a8c2ea3902d 8010437: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset Summary: Fix shorten_branches() to accurately count an initial nop that may be inserted in a block that starts with a safepoint. Reviewed-by: kvn ! src/share/vm/opto/output.cpp From david.r.chase at oracle.com Wed Apr 3 20:00:38 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 3 Apr 2013 23:00:38 -0400 Subject: RFR(M) : 7104565 : trim jprt build targets Message-ID: <7C7CBBE7-2651-4F94-820A-C68378C46AA9@oracle.com> webrev: http://cr.openjdk.java.net/~drchase/7104565/webrev.02/ Problem: Debug builds are inconsistently named, and are not needed for usual JPRT testing, and consume lots of space and time. #ifdef conventions are a little dubious (I'm just paraphrasing from the bug here). Fix: Pick up Tom Rodriguez's work towards a fix (95+% complete), translate forward in time to current build, check for omissions and changes. Fix includes: replace #ifdef DEBUG and #ifdef FASTDEBUG with #ifdef ASSERT consistently name the debug build "debug" instead of "jvmg" remove "debug" targets from JPRT properties files. Testing: Jtreg locally JPRT of usual compiler tests Cross-checked old diffs with new diffs JPRT of compiler regression tests Manually check that appropriate -DASSERT flag is passed to compilations. Noticeable changes: "make debug", not "make jvmg" JPRT of compiler regression tests is much faster and times out much less often. From igor.ignatyev at oracle.com Wed Apr 3 23:40:47 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 04 Apr 2013 10:40:47 +0400 Subject: RFR(M): 8007288: Additional WB API for compiler's testing In-Reply-To: <515C8FC2.2010900@oracle.com> References: <5154B8F1.2030108@oracle.com> <0549160A-DBFE-42A8-9AAE-AC98CB066D09@oracle.com> <51599671.4090501@oracle.com> <5159C42E.7000208@oracle.com> <515A9B8A.6040503@oracle.com> <515B2F49.7050305@oracle.com> <515C8469.40901@oracle.com> <515C8FC2.2010900@oracle.com> Message-ID: <515D206F.7060307@oracle.com> >> Now, why you need new changes in compilationPolicy.hpp? It was not in >> previous webrev. Yes, it may be correct but why? After I had look-see 'globalDefinitions' I mistakenly decided that 'CompLevel_initial_compile' always is 'CompLevel_full_optimization' for C2. So I said that 'comp_level' always equals 'CompLevel_highest_tier' in 'CompileBroker::compile_method' for non-tiered, but it isn't true, because 'NonTieredCompPolicy::initial_compile_level' returns 'CompLevel_full_profile' when 'TIERED' is defined. On the one hand I want to be able to use any 'comp_level' in 'CompileBroker::compile_method' from WhiteBoxAPI, so I need to remove 'if (!TieredCompilation) { comp_level = CompLevel_highest_tier; }'. On the other hand, we must use only 'CompLevel_highest_tier' for non-tiered in normal execution. The only place where used inaccurate 'comp_level' is 'NonTieredCompPolicy::initial_compile_level', and I think it would be better if it returns correct level. Best regards, Igor Ignatyev On 04/04/2013 12:23 AM, Vladimir Kozlov wrote: > >>> I can add explicit checking for equality to 'CompLevel_any'. > > should i add this check? > > I don't think it is needed. May be comment. > > You convinced me about changes in CompilationPolicy::can_be_compiled(). > > Now, why you need new changes in compilationPolicy.hpp? It was not in > previous webrev. Yes, it may be correct but why? > > Vladimir > > On 4/3/13 12:35 PM, Igor Ignatyev wrote: >> >>> compileBroker.cpp - add assert() to check that. >> >> If I add it, WB.enqueueMethodForCompilation() will trigger this >> assert, >> >> e.g. in test 'compiler/whitebox/EnqueueMethodForCompilationTest'. >> > >> > Which means the test introduces the case which never happens in normal >> > execution. I am not sure it is good or bad. >> > You can relax assert with WhiteBoxAPI check. I really want this assert >> > for normal execution. >> i added assert and changed 'NonTieredCompPolicy::initial_compile_level' >> since it return 'CompLevel_full_profile' instead of >> 'CompLevel_full_optimization' for non-tiered C2 with Xcomp. sorry, i >> missed this it due to poor preprocessor in my brain. >> >>>>> compilationPolicy.cpp - I don't think the change is correct since >>>>> is_compile(CompLevel_any) returns false. >>>> 'comp_level == CompLevel_any' is the same that 'comp_level == >>>> CompLevel_all' and this situation is processed in >>>> compilationPolicy.cpp:124, so I think that it's correct, isn't it? >>>> I can add explicit checking for equality to 'CompLevel_any'. >> should i add this check? >> >>> You are right about CompLevel_any. What about next check in >>> m->is_not_compilable(): >>> >>> if (is_method_handle_intrinsic()) >>> return !is_synthetic(); // the generated adapters must be compiled >>> >> even if CompilationPolicy::can_be_compiled() return 'true' for invalid >> comp_level, method won't be compiled since >> CompileBroker::compiler(comp_level) will be 'NULL' in >> CompileBroker::compile_method(): >> >> AbstractCompiler *comp = CompileBroker::compiler(comp_level); >> if (comp == NULL || !comp->can_compile_method(method) || >> compilation_is_prohibited(method, osr_bci, comp_level)) { >> return NULL; >> } >> >> updated webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.02/ >> >> Best regards, >> Igor Ignatyev >> >> On 04/02/2013 11:19 PM, Vladimir Kozlov wrote: >>> On 4/2/13 1:49 AM, Igor Ignatyev wrote: >>>> > compileBroker.cpp - add assert() to check that. >>>> If I add it, WB.enqueueMethodForCompilation() will trigger this assert, >>>> e.g. in test 'compiler/whitebox/EnqueueMethodForCompilationTest'. >>> >>> Which means the test introduces the case which never happens in normal >>> execution. I am not sure it is good or bad. >>> You can relax assert with WhiteBoxAPI check. I really want this assert >>> for normal execution. >>> >>>> >>>> > compilationPolicy.cpp - I don't think the change is correct since >>>> > is_compile(CompLevel_any) returns false. >>>> 'comp_level == CompLevel_any' is the same that 'comp_level == >>>> CompLevel_all' and this situation is processed in >>>> compilationPolicy.cpp:124, so I think that it's correct, isn't it? >>>> I can add explicit checking for equality to 'CompLevel_any'. >>> >>> You are right about CompLevel_any. What about next check in >>> m->is_not_compilable(): >>> >>> if (is_method_handle_intrinsic()) >>> return !is_synthetic(); // the generated adapters must be compiled >>> >>> Thanks, >>> Vladimir >>> >>>> >>>>> Could you rename setForceInlineMethod() to >>>>> testSetForceInlineMethod() to >>>>> be more clear what it does? >>>> I will rename setForceInlineMethod() and setDontInlineMethod(). >>>> >>>> Best regards, >>>> Igor Ignatyev >>>> >>>> On 04/01/2013 09:30 PM, Vladimir Kozlov wrote: >>>>> compileBroker.cpp - add assert() to check that. >>>>> >>>>> compilationPolicy.cpp - I don't think the change is correct since >>>>> is_compile(CompLevel_any) returns false. >>>>> >>>>> Could you rename setForceInlineMethod() to >>>>> testSetForceInlineMethod() to >>>>> be more clear what it does? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 4/1/13 7:15 AM, Igor Ignatyev wrote: >>>>>> test 'compiler/whitebox/EnqueueMethodForCompilationTest' has failed >>>>>> during testing, because 'CompilationPolicy::can_be_compiled()' >>>>>> returns >>>>>> 'true' for invalid comp_level (less that -1 or great that 4). >>>>>> >>>>>> i added method 'is_compile' to check whether a value is valid >>>>>> level of >>>>>> compilation and rerun jprt. >>>>>> >>>>>> in new results: >>>>>> - compiler/whitebox/IsMethodCompilableTest failed on on >>>>>> *-i586-*-c1 >>>>>> due to JDK-8007270 >>>>>> - timeouts in other compiler's tests: >>>>>> * compiler/6663848/Tester >>>>>> * compiler/6711100/Test >>>>>> * compiler/6792161/Test6792161 >>>>>> * compiler/6863420/Test >>>>>> * compiler/6863420/Test >>>>>> * compiler/6901572/Test >>>>>> * compiler/7100757/Test7100757 >>>>>> * compiler/7119644/TestFloatVect >>>>>> * compiler/7196199/Test7196199 >>>>>> * compiler/7199742/Test7199742 >>>>>> >>>>>> updated webrev: >>>>>> http://cr.openjdk.java.net/~iignatyev/8007288/webrev.01/ >>>>>> >>>>>> Best regards, >>>>>> Igor Ignatyev >>>>>> >>>>>> On 03/29/2013 01:52 AM, David Chase wrote: >>>>>>> (Not a reviewer) >>>>>>> >>>>>>> Could you run these tests on the "east" JPRT queue and see if they >>>>>>> have any problems there? >>>>>>> We seem to have some surprisingly slow machines there, and that has >>>>>>> caused problems with other tests. >>>>>>> >>>>>>> David >>>>>>> >>>>>>> >>>>>>> On 2013-03-28, at 5:41 PM, Igor Ignatyev >>>>>>> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review the patch. >>>>>>>> >>>>>>>> 1. added new functions to WhiteBox: >>>>>>>> public native boolean setForceInlineMethod(Method method, boolean >>>>>>>> value); >>>>>>>> public native boolean enqueueMethodForCompilation(Method method, >>>>>>>> int compLevel); >>>>>>>> public native void clearMethodState(Method method); >>>>>>>> 2. related changes in not whitebox code: >>>>>>>> - added 'Method::clear_not_*_compilable()' and corresponded >>>>>>>> 'AccessFlags::clear_not_*_compilable()' >>>>>>>> - added 'MethodData::init()' - reset method data into original >>>>>>>> state. reset all counters, flags >>>>>>>> 3. removed useless code: >>>>>>>> - 'if (!TieredCompilation) { comp_level = CompLevel_highest_tier; >>>>>>>> }' in CompileBroker::compile_method() -- there is no method >>>>>>>> calls w/ >>>>>>>> comp_level != CompLevel_highest_tier in non-tiered >>>>>>>> - 'MethodData::initialize(methodHandle method)' -- declaration >>>>>>>> w/o >>>>>>>> definition >>>>>>>> 4. added tests for new WB functions >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.00/ >>>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8007288 >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> Igor Ignatyev >>>>>>> From stefan.karlsson at oracle.com Thu Apr 4 00:11:57 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 04 Apr 2013 09:11:57 +0200 Subject: RFR(M) : 7104565 : trim jprt build targets In-Reply-To: <7C7CBBE7-2651-4F94-820A-C68378C46AA9@oracle.com> References: <7C7CBBE7-2651-4F94-820A-C68378C46AA9@oracle.com> Message-ID: <515D27BD.7010006@oracle.com> David, You change a lot of make files and this will affect all HotSpot developers, so this review should probably go to hotspot-dev and not hotspot-compiler-dev. Have you tried these changes with a full JDK8 forest and the new build infrastructure? thanks, StefanK On 04/04/2013 05:00 AM, David Chase wrote: > webrev: http://cr.openjdk.java.net/~drchase/7104565/webrev.02/ > > Problem: > Debug builds are inconsistently named, and are not needed for usual JPRT testing, and consume lots of space and time. > #ifdef conventions are a little dubious (I'm just paraphrasing from the bug here). > > Fix: > Pick up Tom Rodriguez's work towards a fix (95+% complete), > translate forward in time to current build, check for omissions and changes. > > Fix includes: > replace #ifdef DEBUG and #ifdef FASTDEBUG with #ifdef ASSERT > consistently name the debug build "debug" instead of "jvmg" > remove "debug" targets from JPRT properties files. > > Testing: > Jtreg locally > JPRT of usual compiler tests > Cross-checked old diffs with new diffs > JPRT of compiler regression tests > Manually check that appropriate -DASSERT flag is passed to compilations. > > Noticeable changes: > "make debug", not "make jvmg" > JPRT of compiler regression tests is much faster and times out much less often. > From niclas.adlertz at oracle.com Thu Apr 4 00:16:12 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Thu, 4 Apr 2013 09:16:12 +0200 Subject: RFR(XXS) 8006016: [parfait] Memory leak at hotspot/src/share/vm/adlc/output_c.cpp & output_h.cpp In-Reply-To: <515C6803.5050301@oracle.com> References: <2F77284B-7D68-4EE6-AE80-D6F88E6F3203@oracle.com> <515C6803.5050301@oracle.com> Message-ID: Thank you Roland. Thank you Vladimir. Here are the additional code style fixes. http://cr.openjdk.java.net/~adlertz/JDK-8006016/webrev02/ Regards, Niclas Adlertz On 3 apr 2013, at 19:33, Vladimir Kozlov wrote: > Niclas, > > Fix code style in output_c.cpp, otherwise it is good. > Changes in output_h.cpp are good. > > Thanks, > Vladimir > > On 4/3/13 8:55 AM, Niclas Adlertz wrote: >> Hi all. >> >> A small parfait fix. A review would be much appreciated. >> Thank you. >> >> Regards, >> Niclas Adlertz >> >> ----------------------------------------------------------------- >> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8006016/webrev00/ >> jbs: https://jbs.oracle.com/bugs/browse/JDK-8006016 >> bugs: http://bugs.sun.com/view_bug.do?bug_id=8006016 >> >> From volker.simonis at gmail.com Thu Apr 4 00:44:35 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 4 Apr 2013 09:44:35 +0200 Subject: RFR (XS): 8010460: Interpreter on some platforms loads ConstMethod::_max_stack and misses extra stack slots for JSR 292 In-Reply-To: References: <6B922316-9630-4955-9A42-8FA52D5571F6@oracle.com> <4CA94106-1D2A-4DF2-814E-DF2F7A190B60@oracle.com> <8A8F768B-D0E2-46C1-AEC2-ED2FAA88EA09@oracle.com> Message-ID: On Wed, Apr 3, 2013 at 9:33 PM, Christian Thalinger < christian.thalinger at oracle.com> wrote: > > On Apr 3, 2013, at 5:06 AM, Volker Simonis > wrote: > > Hi Roland, > > this issue is almost the same as: > > 8002087 : JSR 292: max_stack issues in interpreter code after JSR-292 merge > (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8002087) > > I think besides the oop map problem (in OopMapForCacheEntry::compute_map) > your change fixes all other issues described there. > > On Fri, Mar 29, 2013 at 7:22 PM, Roland Westrelin < > roland.westrelin at oracle.com> wrote: > >> Thanks for reviewing this. >> >> > Good. It's time to get rid of the //6815692// stuff. The extra_stack >> variables (always zero now) can go away too. >> >> I'm not sure what to do with this: >> guarantee(!EnableInvokeDynamic, "no support yet for >> java.lang.invoke.MethodHandle"); //6815692 >> //6815692//if (EnableInvokeDynamic) >> //6815692// __ inc(O3, Method::extra_stack_entries()); >> >> in cppInterpreter_sparc.cpp >> >> > Well, it wouldn't work anyway if running with 'EnableInvokeDynamic' > enabled. > But you have: > > 1217 __ lduh(O3, in_bytes(ConstMethod::max_stack_offset()), O3); > 1218 guarantee(!EnableInvokeDynamic, "no support yet for java.lang.invoke.MethodHandle"); //6815692 > 1219 //6815692//if (EnableInvokeDynamic) > 1220 //6815692// __ inc(O3, Method::extra_stack_entries()); > > and now, after your change, max_stack automatically accounts for the extra > stack entries, so I'd delete the lines: > > 1219 //6815692//if (EnableInvokeDynamic) > 1220 //6815692// __ inc(O3, Method::extra_stack_entries()); > > Just for the case that somebody ever wants to implement > 'EnableInvokeDynamic' for the CPP-interpreter on SPARC. Maybe you could > also remove the guarantee and hope for the best.. > > For our ppc-port ( > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/file/tip/src/cpu/ppc/vm/cppInterpreter_ppc.cpp) > I've fixed this by inserting: > > __ ppc_lhz(max_stack, method_(max_stack)); > > if (EnableInvokeDynamic) { > // Take into account 'extra_stack_entries' needed by method handles (see method.hpp) > __ ppc_addi(max_stack, max_stack, methodOopDesc::extra_stack_entries()); > > } > > but that's not necessary anymore, after your change. > > >> > I think extra_stack_words can be deleted, and extra_stack_entries can >> be made private to Method. >> > >> > This line of code is redundant in >> src/cpu/x86/vm/templateInterpreter_x86_{32,64}.cpp: >> > const int extra_stack = Method::extra_stack_entries(); >> >> I applied Christian's suggestions and yours and found a reference to >> Method::extra_stack_entries() in c2 that I assume can be removed. Here is a >> new webrev: >> >> http://cr.openjdk.java.net/~roland/8010460/webrev.01/ >> >> Roland. > > > You may also consider to fix another problem which only occurs if you use > a hsx24 or later with pre-hsx24 class library (i.e. if building hsx24/hsx25 > with a pre-hsx24 bootstrap JDK). It is an assertion in > bytecodeInterpreter.cpp: > > // We have a problem here if we are running with a pre-hsx24 JDK (for example during bootstrap) > // because in that case, EnableInvokeDynamic is true by default but will be later switched off > // if java_lang_invoke_MethodHandle::compute_offsets() detects that the JDK only has the classes > > // for the old JSR292 implementation. > // This leads to a situation where 'istate->_stack_limit' always accounts for > // methodOopDesc::extra_stack_entries() because it is computed in > // CppInterpreterGenerator::generate_compute_interpreter_state() which was generated while > > // EnableInvokeDynamic was still true. On the other hand, istate->_method->max_stack() doesn't > // account for extra_stack_entries() anymore because at the time when it is called > // EnableInvokeDynamic was already set to false. > > // So we have a second version of the assertion which handles the case where EnableInvokeDynamic was > // switched off because of the wrong classes. > if (EnableInvokeDynamic || FLAG_IS_CMDLINE(EnableInvokeDynamic)) { > > assert(labs(istate->_stack_base - istate->_stack_limit) == (istate->_method->max_stack() + 1), "bad stack limit"); > } > else { > const int extra_stack_entries = 2; // MUST match the value in methodOopDesc::extra_stack_entries() > > assert(labs(istate->_stack_base - istate->_stack_limit) == (istate->_method->max_stack() + extra_stack_entries > + 1), "bad stack limit"); > > } > > > Oh boy. I'm not sure if that bootstrap problem still exists. Could > someone verify that? > > -- Chris > > Of course it does exist, otherwise I wouldn't had to fix it:) Please read the above comment for the details why it occurs. @Roland: the above fix still uses 'extra_stack_entries = 2' which would have to be changed to '1' with your change. An even better solution would be to define it as a public constant or enum in the 'Method' class and use that in 'extra_stack_entries()' and in the above assertion. I wanted to do that in our port but then left it as is to avoid changes in shared code. You can see the actual patch we did at: > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/diff/61615792f0fe/src/share/vm/interpreter/bytecodeInterpreter.cpp > > Regards, > Volker > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130404/4928db84/attachment.html From mikael.gerdin at oracle.com Thu Apr 4 00:56:24 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 04 Apr 2013 09:56:24 +0200 Subject: RFR(M) : 7104565 : trim jprt build targets In-Reply-To: <7C7CBBE7-2651-4F94-820A-C68378C46AA9@oracle.com> References: <7C7CBBE7-2651-4F94-820A-C68378C46AA9@oracle.com> Message-ID: <515D3228.5090401@oracle.com> David, On 2013-04-04 05:00, David Chase wrote: > webrev: http://cr.openjdk.java.net/~drchase/7104565/webrev.02/ I noticed that the "udiff" for llvmHeaders.hpp in your webrev is broken: http://cr.openjdk.java.net/~drchase/7104565/webrev.02/src/share/vm/shark/llvmHeaders.hpp.udiff.html It doesn't show the removed lines at all. Could you try to generate a webrev with the "standard" webrev script in the top-level repo to rule out any bug in the "enhanced" webrev (the one with next/prev file links). /Mikael > > Problem: > Debug builds are inconsistently named, and are not needed for usual JPRT testing, and consume lots of space and time. > #ifdef conventions are a little dubious (I'm just paraphrasing from the bug here). > > Fix: > Pick up Tom Rodriguez's work towards a fix (95+% complete), > translate forward in time to current build, check for omissions and changes. > > Fix includes: > replace #ifdef DEBUG and #ifdef FASTDEBUG with #ifdef ASSERT > consistently name the debug build "debug" instead of "jvmg" > remove "debug" targets from JPRT properties files. > > Testing: > Jtreg locally > JPRT of usual compiler tests > Cross-checked old diffs with new diffs > JPRT of compiler regression tests > Manually check that appropriate -DASSERT flag is passed to compilations. > > Noticeable changes: > "make debug", not "make jvmg" > JPRT of compiler regression tests is much faster and times out much less often. > From nils.eliasson at oracle.com Thu Apr 4 02:44:09 2013 From: nils.eliasson at oracle.com (nils.eliasson at oracle.com) Date: Thu, 04 Apr 2013 09:44:09 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8006008: Memory leak in hotspot/src/share/vm/adlc/archDesc.cpp Message-ID: <20130404094413.06A6D485C1@hg.openjdk.java.net> Changeset: 70c52efb2cbd Author: neliasso Date: 2013-04-04 09:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/70c52efb2cbd 8006008: Memory leak in hotspot/src/share/vm/adlc/archDesc.cpp Reviewed-by: roland, kvn Contributed-by: niclas.adlertz at oracle.com ! src/share/vm/adlc/archDesc.cpp From david.r.chase at oracle.com Thu Apr 4 04:08:21 2013 From: david.r.chase at oracle.com (David Chase) Date: Thu, 4 Apr 2013 07:08:21 -0400 Subject: RFR(M) : 7104565 : trim jprt build targets In-Reply-To: <515D27BD.7010006@oracle.com> References: <7C7CBBE7-2651-4F94-820A-C68378C46AA9@oracle.com> <515D27BD.7010006@oracle.com> Message-ID: <333A9E51-2823-4036-839E-EEEB063AA251@oracle.com> On 2013-04-04, at 3:11 AM, Stefan Karlsson wrote: > David, > > You change a lot of make files and this will affect all HotSpot developers, so this review should probably go to hotspot-dev and not hotspot-compiler-dev. > > Have you tried these changes with a full JDK8 forest and the new build infrastructure? I can do that. Does JPRT use new or old build? (if it does, then in some sense I have already tested that way, and if it does not, then it is pointless to re-run JPRT on the full tree.) Two questions -- I noticed that I missed two versions of profiled.make (i.e., those files could be deleted). But I am also unsure about the wisdom of getting rid of profiled make -- what is our method of profiling hotspot, if we do not have that build option? David From stefan.karlsson at oracle.com Thu Apr 4 04:41:57 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 04 Apr 2013 13:41:57 +0200 Subject: RFR(M) : 7104565 : trim jprt build targets In-Reply-To: <333A9E51-2823-4036-839E-EEEB063AA251@oracle.com> References: <7C7CBBE7-2651-4F94-820A-C68378C46AA9@oracle.com> <515D27BD.7010006@oracle.com> <333A9E51-2823-4036-839E-EEEB063AA251@oracle.com> Message-ID: <515D6705.2040208@oracle.com> On 04/04/2013 01:08 PM, David Chase wrote: > On 2013-04-04, at 3:11 AM, Stefan Karlsson wrote: > >> David, >> >> You change a lot of make files and this will affect all HotSpot developers, so this review should probably go to hotspot-dev and not hotspot-compiler-dev. >> >> Have you tried these changes with a full JDK8 forest and the new build infrastructure? > I can do that. Does JPRT use new or old build? (if it does, then in some sense I have already tested that way, and if it does not, then it is pointless to re-run JPRT on the full tree.) Neither, if you only sync the HotSpot forest. You have to fetch the entire JDK8 forest, and then I _think_ JPRT will use the new build system. Though, I don't think it will build jvmg/debug per default. You need to build with the slowdebug target. You better ask build-infra-dev at openjdk.java.net . > > Two questions -- I noticed that I missed two versions of profiled.make (i.e., those files could be deleted). But I am also unsure about the wisdom of getting rid of profiled make -- what is our method of profiling hotspot, if we do not have that build option? I have no knowledge about profiled.make. thanks, StefanK > > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130404/8ca438b1/attachment.html From mikael.gerdin at oracle.com Thu Apr 4 04:57:17 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 04 Apr 2013 13:57:17 +0200 Subject: RFR(M) : 7104565 : trim jprt build targets In-Reply-To: <515D6705.2040208@oracle.com> References: <7C7CBBE7-2651-4F94-820A-C68378C46AA9@oracle.com> <515D27BD.7010006@oracle.com> <333A9E51-2823-4036-839E-EEEB063AA251@oracle.com> <515D6705.2040208@oracle.com> Message-ID: <515D6A9D.3020704@oracle.com> David, On 2013-04-04 13:41, Stefan Karlsson wrote: > On 04/04/2013 01:08 PM, David Chase wrote: >> On 2013-04-04, at 3:11 AM, Stefan Karlsson wrote: >> >>> David, >>> >>> You change a lot of make files and this will affect all HotSpot developers, so this review should probably go to hotspot-dev and not hotspot-compiler-dev. >>> >>> Have you tried these changes with a full JDK8 forest and the new build infrastructure? >> I can do that. Does JPRT use new or old build? (if it does, then in some sense I have already tested that way, and if it does not, then it is pointless to re-run JPRT on the full tree.) > > Neither, if you only sync the HotSpot forest. > > You have to fetch the entire JDK8 forest, and then I _think_ JPRT will > use the new build system. Though, I don't think it will build jvmg/debug > per default. You need to build with the slowdebug target. You better ask > build-infra-dev at openjdk.java.net . > >> >> Two questions -- I noticed that I missed two versions of profiled.make (i.e., those files could be deleted). But I am also unsure about the wisdom of getting rid of profiled make -- what is our method of profiling hotspot, if we do not have that build option? > > I have no knowledge about profiled.make. I believe that profiled.make will compile hotspot with support for gprof & friends. The problem with gprof is that it only works on binaries, not shared libraries. So with Christian T's change to remove the gamma launcher and thereby the LINK_INTO=AOUT make flag profiled.make will probably be completely useless. Also, I think most people who want to profile the VM use sampling based profiling tools such as "perf", "collect/analyze" or VTune. /Mikael > > thanks, > StefanK > >> >> David >> > From roland.westrelin at oracle.com Thu Apr 4 05:47:35 2013 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Thu, 04 Apr 2013 12:47:35 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20130404124739.D7DFB485C6@hg.openjdk.java.net> Changeset: 6c4abd4a9595 Author: roland Date: 2013-04-04 09:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6c4abd4a9595 8010399: Test8009761.java "Failed: init recursive calls: 5498. After deopt 5494". Summary: test from 8009761 shouldn't be run with -Xcomp Reviewed-by: kvn ! test/compiler/8009761/Test8009761.java Changeset: 9125a548c1eb Author: roland Date: 2013-04-04 02:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9125a548c1eb Merge From vladimir.kozlov at oracle.com Thu Apr 4 07:34:51 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 04 Apr 2013 07:34:51 -0700 Subject: RFR(XXS) 8006016: [parfait] Memory leak at hotspot/src/share/vm/adlc/output_c.cpp & output_h.cpp In-Reply-To: References: <2F77284B-7D68-4EE6-AE80-D6F88E6F3203@oracle.com> <515C6803.5050301@oracle.com> Message-ID: <515D8F8B.7050908@oracle.com> Good. Thanks, Vladimir On 4/4/13 12:16 AM, Niclas Adlertz wrote: > Thank you Roland. > Thank you Vladimir. > > Here are the additional code style fixes. > > http://cr.openjdk.java.net/~adlertz/JDK-8006016/webrev02/ > > Regards, > Niclas Adlertz > > On 3 apr 2013, at 19:33, Vladimir Kozlov wrote: > >> Niclas, >> >> Fix code style in output_c.cpp, otherwise it is good. >> Changes in output_h.cpp are good. >> >> Thanks, >> Vladimir >> >> On 4/3/13 8:55 AM, Niclas Adlertz wrote: >>> Hi all. >>> >>> A small parfait fix. A review would be much appreciated. >>> Thank you. >>> >>> Regards, >>> Niclas Adlertz >>> >>> ----------------------------------------------------------------- >>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8006016/webrev00/ >>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8006016 >>> bugs: http://bugs.sun.com/view_bug.do?bug_id=8006016 >>> >>> > From vladimir.kozlov at oracle.com Thu Apr 4 07:41:47 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 04 Apr 2013 07:41:47 -0700 Subject: RFR(M) : 7104565 : trim jprt build targets In-Reply-To: <333A9E51-2823-4036-839E-EEEB063AA251@oracle.com> References: <7C7CBBE7-2651-4F94-820A-C68378C46AA9@oracle.com> <515D27BD.7010006@oracle.com> <333A9E51-2823-4036-839E-EEEB063AA251@oracle.com> Message-ID: <515D912B.5020203@oracle.com> It was very long broken (before 1.5) and never was repaired. It was used before we had decent profiling tools. Just delete all 'profiled' related files. Thanks, Vladimir On 4/4/13 4:08 AM, David Chase wrote: > > On 2013-04-04, at 3:11 AM, Stefan Karlsson wrote: > >> David, >> >> You change a lot of make files and this will affect all HotSpot developers, so this review should probably go to hotspot-dev and not hotspot-compiler-dev. >> >> Have you tried these changes with a full JDK8 forest and the new build infrastructure? > > I can do that. Does JPRT use new or old build? (if it does, then in some sense I have already tested that way, and if it does not, then it is pointless to re-run JPRT on the full tree.) > > Two questions -- I noticed that I missed two versions of profiled.make (i.e., those files could be deleted). But I am also unsure about the wisdom of getting rid of profiled make -- what is our method of profiling hotspot, if we do not have that build option? > > David > From igor.ignatyev at oracle.com Thu Apr 4 10:13:31 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 04 Apr 2013 21:13:31 +0400 Subject: RFR(M): 8007288: Additional WB API for compiler's testing In-Reply-To: <515D206F.7060307@oracle.com> References: <5154B8F1.2030108@oracle.com> <0549160A-DBFE-42A8-9AAE-AC98CB066D09@oracle.com> <51599671.4090501@oracle.com> <5159C42E.7000208@oracle.com> <515A9B8A.6040503@oracle.com> <515B2F49.7050305@oracle.com> <515C8469.40901@oracle.com> <515C8FC2.2010900@oracle.com> <515D206F.7060307@oracle.com> Message-ID: <515DB4BB.8040209@oracle.com> I also found another place with inaccurate comp_level in 'ciReplay.cpp::process_compile()', there always uses 'CompLevel_full_optimization'. webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.03/ Best regards, Igor Ignatyev On 04/04/2013 10:40 AM, Igor Ignatyev wrote: >>> Now, why you need new changes in compilationPolicy.hpp? It was not in >>> previous webrev. Yes, it may be correct but why? > > After I had look-see 'globalDefinitions' I mistakenly decided that > 'CompLevel_initial_compile' always is 'CompLevel_full_optimization' for > C2. So I said that 'comp_level' always equals 'CompLevel_highest_tier' > in 'CompileBroker::compile_method' for non-tiered, but it isn't true, > because 'NonTieredCompPolicy::initial_compile_level' returns > 'CompLevel_full_profile' when 'TIERED' is defined. > > On the one hand I want to be able to use any 'comp_level' in > 'CompileBroker::compile_method' from WhiteBoxAPI, so I need to remove > 'if (!TieredCompilation) { comp_level = CompLevel_highest_tier; }'. On > the other hand, we must use only 'CompLevel_highest_tier' for > non-tiered in normal execution. > > The only place where used inaccurate 'comp_level' is > 'NonTieredCompPolicy::initial_compile_level', and I think it would be > better if it returns correct level. > > Best regards, > Igor Ignatyev > > On 04/04/2013 12:23 AM, Vladimir Kozlov wrote: >> >>> I can add explicit checking for equality to 'CompLevel_any'. >> > should i add this check? >> >> I don't think it is needed. May be comment. >> >> You convinced me about changes in CompilationPolicy::can_be_compiled(). >> >> Now, why you need new changes in compilationPolicy.hpp? It was not in >> previous webrev. Yes, it may be correct but why? >> >> Vladimir >> >> On 4/3/13 12:35 PM, Igor Ignatyev wrote: >>> >>> compileBroker.cpp - add assert() to check that. >>> >> If I add it, WB.enqueueMethodForCompilation() will trigger this >>> assert, >>> >> e.g. in test 'compiler/whitebox/EnqueueMethodForCompilationTest'. >>> > >>> > Which means the test introduces the case which never happens in >>> normal >>> > execution. I am not sure it is good or bad. >>> > You can relax assert with WhiteBoxAPI check. I really want this >>> assert >>> > for normal execution. >>> i added assert and changed 'NonTieredCompPolicy::initial_compile_level' >>> since it return 'CompLevel_full_profile' instead of >>> 'CompLevel_full_optimization' for non-tiered C2 with Xcomp. sorry, i >>> missed this it due to poor preprocessor in my brain. >>> >>>>>> compilationPolicy.cpp - I don't think the change is correct since >>>>>> is_compile(CompLevel_any) returns false. >>>>> 'comp_level == CompLevel_any' is the same that 'comp_level == >>>>> CompLevel_all' and this situation is processed in >>>>> compilationPolicy.cpp:124, so I think that it's correct, isn't it? >>>>> I can add explicit checking for equality to 'CompLevel_any'. >>> should i add this check? >>> >>>> You are right about CompLevel_any. What about next check in >>>> m->is_not_compilable(): >>>> >>>> if (is_method_handle_intrinsic()) >>>> return !is_synthetic(); // the generated adapters must be >>>> compiled >>>> >>> even if CompilationPolicy::can_be_compiled() return 'true' for invalid >>> comp_level, method won't be compiled since >>> CompileBroker::compiler(comp_level) will be 'NULL' in >>> CompileBroker::compile_method(): >>> >>> AbstractCompiler *comp = CompileBroker::compiler(comp_level); >>> if (comp == NULL || !comp->can_compile_method(method) || >>> compilation_is_prohibited(method, osr_bci, comp_level)) { >>> return NULL; >>> } >>> >>> updated webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.02/ >>> >>> Best regards, >>> Igor Ignatyev >>> >>> On 04/02/2013 11:19 PM, Vladimir Kozlov wrote: >>>> On 4/2/13 1:49 AM, Igor Ignatyev wrote: >>>>> > compileBroker.cpp - add assert() to check that. >>>>> If I add it, WB.enqueueMethodForCompilation() will trigger this >>>>> assert, >>>>> e.g. in test 'compiler/whitebox/EnqueueMethodForCompilationTest'. >>>> >>>> Which means the test introduces the case which never happens in normal >>>> execution. I am not sure it is good or bad. >>>> You can relax assert with WhiteBoxAPI check. I really want this assert >>>> for normal execution. >>>> >>>>> >>>>> > compilationPolicy.cpp - I don't think the change is correct since >>>>> > is_compile(CompLevel_any) returns false. >>>>> 'comp_level == CompLevel_any' is the same that 'comp_level == >>>>> CompLevel_all' and this situation is processed in >>>>> compilationPolicy.cpp:124, so I think that it's correct, isn't it? >>>>> I can add explicit checking for equality to 'CompLevel_any'. >>>> >>>> You are right about CompLevel_any. What about next check in >>>> m->is_not_compilable(): >>>> >>>> if (is_method_handle_intrinsic()) >>>> return !is_synthetic(); // the generated adapters must be >>>> compiled >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>>> Could you rename setForceInlineMethod() to >>>>>> testSetForceInlineMethod() to >>>>>> be more clear what it does? >>>>> I will rename setForceInlineMethod() and setDontInlineMethod(). >>>>> >>>>> Best regards, >>>>> Igor Ignatyev >>>>> >>>>> On 04/01/2013 09:30 PM, Vladimir Kozlov wrote: >>>>>> compileBroker.cpp - add assert() to check that. >>>>>> >>>>>> compilationPolicy.cpp - I don't think the change is correct since >>>>>> is_compile(CompLevel_any) returns false. >>>>>> >>>>>> Could you rename setForceInlineMethod() to >>>>>> testSetForceInlineMethod() to >>>>>> be more clear what it does? >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 4/1/13 7:15 AM, Igor Ignatyev wrote: >>>>>>> test 'compiler/whitebox/EnqueueMethodForCompilationTest' has failed >>>>>>> during testing, because 'CompilationPolicy::can_be_compiled()' >>>>>>> returns >>>>>>> 'true' for invalid comp_level (less that -1 or great that 4). >>>>>>> >>>>>>> i added method 'is_compile' to check whether a value is valid >>>>>>> level of >>>>>>> compilation and rerun jprt. >>>>>>> >>>>>>> in new results: >>>>>>> - compiler/whitebox/IsMethodCompilableTest failed on on >>>>>>> *-i586-*-c1 >>>>>>> due to JDK-8007270 >>>>>>> - timeouts in other compiler's tests: >>>>>>> * compiler/6663848/Tester >>>>>>> * compiler/6711100/Test >>>>>>> * compiler/6792161/Test6792161 >>>>>>> * compiler/6863420/Test >>>>>>> * compiler/6863420/Test >>>>>>> * compiler/6901572/Test >>>>>>> * compiler/7100757/Test7100757 >>>>>>> * compiler/7119644/TestFloatVect >>>>>>> * compiler/7196199/Test7196199 >>>>>>> * compiler/7199742/Test7199742 >>>>>>> >>>>>>> updated webrev: >>>>>>> http://cr.openjdk.java.net/~iignatyev/8007288/webrev.01/ >>>>>>> >>>>>>> Best regards, >>>>>>> Igor Ignatyev >>>>>>> >>>>>>> On 03/29/2013 01:52 AM, David Chase wrote: >>>>>>>> (Not a reviewer) >>>>>>>> >>>>>>>> Could you run these tests on the "east" JPRT queue and see if they >>>>>>>> have any problems there? >>>>>>>> We seem to have some surprisingly slow machines there, and that has >>>>>>>> caused problems with other tests. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>> On 2013-03-28, at 5:41 PM, Igor Ignatyev >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review the patch. >>>>>>>>> >>>>>>>>> 1. added new functions to WhiteBox: >>>>>>>>> public native boolean setForceInlineMethod(Method method, >>>>>>>>> boolean >>>>>>>>> value); >>>>>>>>> public native boolean enqueueMethodForCompilation(Method method, >>>>>>>>> int compLevel); >>>>>>>>> public native void clearMethodState(Method method); >>>>>>>>> 2. related changes in not whitebox code: >>>>>>>>> - added 'Method::clear_not_*_compilable()' and corresponded >>>>>>>>> 'AccessFlags::clear_not_*_compilable()' >>>>>>>>> - added 'MethodData::init()' - reset method data into original >>>>>>>>> state. reset all counters, flags >>>>>>>>> 3. removed useless code: >>>>>>>>> - 'if (!TieredCompilation) { comp_level = >>>>>>>>> CompLevel_highest_tier; >>>>>>>>> }' in CompileBroker::compile_method() -- there is no method >>>>>>>>> calls w/ >>>>>>>>> comp_level != CompLevel_highest_tier in non-tiered >>>>>>>>> - 'MethodData::initialize(methodHandle method)' -- declaration >>>>>>>>> w/o >>>>>>>>> definition >>>>>>>>> 4. added tests for new WB functions >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.00/ >>>>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8007288 >>>>>>>>> -- >>>>>>>>> Best regards, >>>>>>>>> Igor Ignatyev >>>>>>>> From nils.eliasson at oracle.com Thu Apr 4 10:10:56 2013 From: nils.eliasson at oracle.com (nils.eliasson at oracle.com) Date: Thu, 04 Apr 2013 17:10:56 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8006014: Memory leak in hotspot/src/share/vm/adlc/dfa.cpp Message-ID: <20130404171100.7556F485D5@hg.openjdk.java.net> Changeset: 573cf206e381 Author: neliasso Date: 2013-04-04 09:30 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/573cf206e381 8006014: Memory leak in hotspot/src/share/vm/adlc/dfa.cpp Reviewed-by: kvn, roland Contributed-by: niclas.adlertz at oracle.com ! src/share/vm/adlc/dfa.cpp From vladimir.kozlov at oracle.com Thu Apr 4 11:24:36 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 04 Apr 2013 11:24:36 -0700 Subject: RFR (S): 8011198: LP64 setting is not preserved on Solaris after 8006965 In-Reply-To: <515B289E.7050203@oracle.com> References: <515B289E.7050203@oracle.com> Message-ID: <515DC564.9000807@oracle.com> http://cr.openjdk.java.net/~kvn/8011198/webrev/ Fixed incremental build makefiles generated by buildtree.make. Consolidated unix build.sh. Fixed launcher.script (hotspot) to use .dbxrc from HOME dir since 8006965 removed it from build dir. Tested with jprt. Thanks, Vladimir From christian.thalinger at oracle.com Thu Apr 4 11:50:29 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 4 Apr 2013 11:50:29 -0700 Subject: RFR (S): 8011198: LP64 setting is not preserved on Solaris after 8006965 In-Reply-To: <515DC564.9000807@oracle.com> References: <515B289E.7050203@oracle.com> <515DC564.9000807@oracle.com> Message-ID: On Apr 4, 2013, at 11:24 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8011198/webrev/ > > Fixed incremental build makefiles generated by buildtree.make. Sorry I removed the lines in 8006965. Thanks for fixing it. > Consolidated unix build.sh. Since you're probably the only one using I think it's fine :-) > Fixed launcher.script (hotspot) to use .dbxrc from HOME dir since 8006965 removed it from build dir. Ahh, thanks. Looks good. -- Chris > > Tested with jprt. > > Thanks, > Vladimir > From vladimir.kozlov at oracle.com Thu Apr 4 12:11:29 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 04 Apr 2013 12:11:29 -0700 Subject: RFR (S): 8011198: LP64 setting is not preserved on Solaris after 8006965 In-Reply-To: References: <515B289E.7050203@oracle.com> <515DC564.9000807@oracle.com> Message-ID: <515DD061.4080409@oracle.com> Thanks, Christian Vladimir On 4/4/13 11:50 AM, Christian Thalinger wrote: > > On Apr 4, 2013, at 11:24 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/8011198/webrev/ >> >> Fixed incremental build makefiles generated by buildtree.make. > > Sorry I removed the lines in 8006965. Thanks for fixing it. > >> Consolidated unix build.sh. > > Since you're probably the only one using I think it's fine :-) > >> Fixed launcher.script (hotspot) to use .dbxrc from HOME dir since 8006965 removed it from build dir. > > Ahh, thanks. > > Looks good. > > -- Chris > >> >> Tested with jprt. >> >> Thanks, >> Vladimir >> > From christian.thalinger at oracle.com Thu Apr 4 12:13:53 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 4 Apr 2013 12:13:53 -0700 Subject: RFR (S): 8011198: LP64 setting is not preserved on Solaris after 8006965 In-Reply-To: <515DD061.4080409@oracle.com> References: <515B289E.7050203@oracle.com> <515DC564.9000807@oracle.com> <515DD061.4080409@oracle.com> Message-ID: On Apr 4, 2013, at 12:11 PM, Vladimir Kozlov wrote: > Thanks, Christian Unrelated to this review I just found a typo in launcher.script: $ ack JPAR ./src/os/posix/launcher/launcher.script JPARMS="$@ $JAVA_ARGS"; set args $JPARMS $DBX -s $MYDIR/.dbxrc $LAUNCHER $JPARAMS $VALGRIND --tool=memcheck --leak-check=yes --num-callers=50 $LAUNCHER -Xmx16m $JPARMS LD_PRELOAD=$PRELOADING exec $LAUNCHER $JPARMS The DBX line uses JPARAMS instead of JPARMS. -- Chris > > Vladimir > > On 4/4/13 11:50 AM, Christian Thalinger wrote: >> >> On Apr 4, 2013, at 11:24 AM, Vladimir Kozlov wrote: >> >>> http://cr.openjdk.java.net/~kvn/8011198/webrev/ >>> >>> Fixed incremental build makefiles generated by buildtree.make. >> >> Sorry I removed the lines in 8006965. Thanks for fixing it. >> >>> Consolidated unix build.sh. >> >> Since you're probably the only one using I think it's fine :-) >> >>> Fixed launcher.script (hotspot) to use .dbxrc from HOME dir since 8006965 removed it from build dir. >> >> Ahh, thanks. >> >> Looks good. >> >> -- Chris >> >>> >>> Tested with jprt. >>> >>> Thanks, >>> Vladimir >>> >> From vladimir.kozlov at oracle.com Thu Apr 4 15:44:10 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 04 Apr 2013 22:44:10 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8011198: LP64 setting is not preserved on Solaris after 8006965 Message-ID: <20130404224414.CB92448074@hg.openjdk.java.net> Changeset: bab5cbf74b5f Author: kvn Date: 2013-04-04 12:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bab5cbf74b5f 8011198: LP64 setting is not preserved on Solaris after 8006965 Summary: Fixed incremental build makefiles generated by buildtree.make. Consolidated unix build.sh. Reviewed-by: twisti - make/bsd/build.sh ! make/bsd/makefiles/buildtree.make + make/build.sh - make/linux/build.sh ! make/linux/makefiles/buildtree.make - make/solaris/build.sh ! make/solaris/makefiles/buildtree.make ! src/os/posix/launcher/launcher.script From vladimir.kozlov at oracle.com Thu Apr 4 18:03:57 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 04 Apr 2013 18:03:57 -0700 Subject: RFR(M): 8007288: Additional WB API for compiler's testing In-Reply-To: <515DB4BB.8040209@oracle.com> References: <5154B8F1.2030108@oracle.com> <0549160A-DBFE-42A8-9AAE-AC98CB066D09@oracle.com> <51599671.4090501@oracle.com> <5159C42E.7000208@oracle.com> <515A9B8A.6040503@oracle.com> <515B2F49.7050305@oracle.com> <515C8469.40901@oracle.com> <515C8FC2.2010900@oracle.com> <515D206F.7060307@oracle.com> <515DB4BB.8040209@oracle.com> Message-ID: <515E22FD.7020302@oracle.com> Don't change ciReplay.cpp now. File a new bug on hotspot/compiler because compilation level should be recorded by ciEnv::dump_replay_data() and used during replay. It does not affect WB testing because it is only used during replay compilation. > The only place where used inaccurate 'comp_level' is > 'NonTieredCompPolicy::initial_compile_level', and I think it would be > better if it returns correct level. So the problem is next #if which is always true for Server VM now: #if defined(TIERED) CompLevel_initial_compile = CompLevel_full_profile but NonTieredCompPolicy is selected (CompilationPolicyChoice==0) based on TieredCompilation flag. Okay, you fix for NonTieredCompPolicy::initial_compile_level is correct. Thanks, Vladimir On 4/4/13 10:13 AM, Igor Ignatyev wrote: > I also found another place with inaccurate comp_level in > 'ciReplay.cpp::process_compile()', there always uses > 'CompLevel_full_optimization'. > > webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.03/ > > Best regards, > Igor Ignatyev > > On 04/04/2013 10:40 AM, Igor Ignatyev wrote: >>>> Now, why you need new changes in compilationPolicy.hpp? It was not in >>>> previous webrev. Yes, it may be correct but why? >> >> After I had look-see 'globalDefinitions' I mistakenly decided that >> 'CompLevel_initial_compile' always is 'CompLevel_full_optimization' for >> C2. So I said that 'comp_level' always equals 'CompLevel_highest_tier' >> in 'CompileBroker::compile_method' for non-tiered, but it isn't true, >> because 'NonTieredCompPolicy::initial_compile_level' returns >> 'CompLevel_full_profile' when 'TIERED' is defined. >> >> On the one hand I want to be able to use any 'comp_level' in >> 'CompileBroker::compile_method' from WhiteBoxAPI, so I need to remove >> 'if (!TieredCompilation) { comp_level = CompLevel_highest_tier; }'. On >> the other hand, we must use only 'CompLevel_highest_tier' for >> non-tiered in normal execution. >> >> The only place where used inaccurate 'comp_level' is >> 'NonTieredCompPolicy::initial_compile_level', and I think it would be >> better if it returns correct level. >> >> Best regards, >> Igor Ignatyev >> >> On 04/04/2013 12:23 AM, Vladimir Kozlov wrote: >>> >>> I can add explicit checking for equality to 'CompLevel_any'. >>> > should i add this check? >>> >>> I don't think it is needed. May be comment. >>> >>> You convinced me about changes in CompilationPolicy::can_be_compiled(). >>> >>> Now, why you need new changes in compilationPolicy.hpp? It was not in >>> previous webrev. Yes, it may be correct but why? >>> >>> Vladimir >>> >>> On 4/3/13 12:35 PM, Igor Ignatyev wrote: >>>> >>> compileBroker.cpp - add assert() to check that. >>>> >> If I add it, WB.enqueueMethodForCompilation() will trigger this >>>> assert, >>>> >> e.g. in test 'compiler/whitebox/EnqueueMethodForCompilationTest'. >>>> > >>>> > Which means the test introduces the case which never happens in >>>> normal >>>> > execution. I am not sure it is good or bad. >>>> > You can relax assert with WhiteBoxAPI check. I really want this >>>> assert >>>> > for normal execution. >>>> i added assert and changed 'NonTieredCompPolicy::initial_compile_level' >>>> since it return 'CompLevel_full_profile' instead of >>>> 'CompLevel_full_optimization' for non-tiered C2 with Xcomp. sorry, i >>>> missed this it due to poor preprocessor in my brain. >>>> >>>>>>> compilationPolicy.cpp - I don't think the change is correct since >>>>>>> is_compile(CompLevel_any) returns false. >>>>>> 'comp_level == CompLevel_any' is the same that 'comp_level == >>>>>> CompLevel_all' and this situation is processed in >>>>>> compilationPolicy.cpp:124, so I think that it's correct, isn't it? >>>>>> I can add explicit checking for equality to 'CompLevel_any'. >>>> should i add this check? >>>> >>>>> You are right about CompLevel_any. What about next check in >>>>> m->is_not_compilable(): >>>>> >>>>> if (is_method_handle_intrinsic()) >>>>> return !is_synthetic(); // the generated adapters must be >>>>> compiled >>>>> >>>> even if CompilationPolicy::can_be_compiled() return 'true' for invalid >>>> comp_level, method won't be compiled since >>>> CompileBroker::compiler(comp_level) will be 'NULL' in >>>> CompileBroker::compile_method(): >>>> >>>> AbstractCompiler *comp = CompileBroker::compiler(comp_level); >>>> if (comp == NULL || !comp->can_compile_method(method) || >>>> compilation_is_prohibited(method, osr_bci, comp_level)) { >>>> return NULL; >>>> } >>>> >>>> updated webrev: >>>> http://cr.openjdk.java.net/~iignatyev/8007288/webrev.02/ >>>> >>>> Best regards, >>>> Igor Ignatyev >>>> >>>> On 04/02/2013 11:19 PM, Vladimir Kozlov wrote: >>>>> On 4/2/13 1:49 AM, Igor Ignatyev wrote: >>>>>> > compileBroker.cpp - add assert() to check that. >>>>>> If I add it, WB.enqueueMethodForCompilation() will trigger this >>>>>> assert, >>>>>> e.g. in test 'compiler/whitebox/EnqueueMethodForCompilationTest'. >>>>> >>>>> Which means the test introduces the case which never happens in normal >>>>> execution. I am not sure it is good or bad. >>>>> You can relax assert with WhiteBoxAPI check. I really want this assert >>>>> for normal execution. >>>>> >>>>>> >>>>>> > compilationPolicy.cpp - I don't think the change is correct since >>>>>> > is_compile(CompLevel_any) returns false. >>>>>> 'comp_level == CompLevel_any' is the same that 'comp_level == >>>>>> CompLevel_all' and this situation is processed in >>>>>> compilationPolicy.cpp:124, so I think that it's correct, isn't it? >>>>>> I can add explicit checking for equality to 'CompLevel_any'. >>>>> >>>>> You are right about CompLevel_any. What about next check in >>>>> m->is_not_compilable(): >>>>> >>>>> if (is_method_handle_intrinsic()) >>>>> return !is_synthetic(); // the generated adapters must be >>>>> compiled >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>>> Could you rename setForceInlineMethod() to >>>>>>> testSetForceInlineMethod() to >>>>>>> be more clear what it does? >>>>>> I will rename setForceInlineMethod() and setDontInlineMethod(). >>>>>> >>>>>> Best regards, >>>>>> Igor Ignatyev >>>>>> >>>>>> On 04/01/2013 09:30 PM, Vladimir Kozlov wrote: >>>>>>> compileBroker.cpp - add assert() to check that. >>>>>>> >>>>>>> compilationPolicy.cpp - I don't think the change is correct since >>>>>>> is_compile(CompLevel_any) returns false. >>>>>>> >>>>>>> Could you rename setForceInlineMethod() to >>>>>>> testSetForceInlineMethod() to >>>>>>> be more clear what it does? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 4/1/13 7:15 AM, Igor Ignatyev wrote: >>>>>>>> test 'compiler/whitebox/EnqueueMethodForCompilationTest' has failed >>>>>>>> during testing, because 'CompilationPolicy::can_be_compiled()' >>>>>>>> returns >>>>>>>> 'true' for invalid comp_level (less that -1 or great that 4). >>>>>>>> >>>>>>>> i added method 'is_compile' to check whether a value is valid >>>>>>>> level of >>>>>>>> compilation and rerun jprt. >>>>>>>> >>>>>>>> in new results: >>>>>>>> - compiler/whitebox/IsMethodCompilableTest failed on on >>>>>>>> *-i586-*-c1 >>>>>>>> due to JDK-8007270 >>>>>>>> - timeouts in other compiler's tests: >>>>>>>> * compiler/6663848/Tester >>>>>>>> * compiler/6711100/Test >>>>>>>> * compiler/6792161/Test6792161 >>>>>>>> * compiler/6863420/Test >>>>>>>> * compiler/6863420/Test >>>>>>>> * compiler/6901572/Test >>>>>>>> * compiler/7100757/Test7100757 >>>>>>>> * compiler/7119644/TestFloatVect >>>>>>>> * compiler/7196199/Test7196199 >>>>>>>> * compiler/7199742/Test7199742 >>>>>>>> >>>>>>>> updated webrev: >>>>>>>> http://cr.openjdk.java.net/~iignatyev/8007288/webrev.01/ >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Igor Ignatyev >>>>>>>> >>>>>>>> On 03/29/2013 01:52 AM, David Chase wrote: >>>>>>>>> (Not a reviewer) >>>>>>>>> >>>>>>>>> Could you run these tests on the "east" JPRT queue and see if they >>>>>>>>> have any problems there? >>>>>>>>> We seem to have some surprisingly slow machines there, and that >>>>>>>>> has >>>>>>>>> caused problems with other tests. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2013-03-28, at 5:41 PM, Igor Ignatyev >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Please review the patch. >>>>>>>>>> >>>>>>>>>> 1. added new functions to WhiteBox: >>>>>>>>>> public native boolean setForceInlineMethod(Method method, >>>>>>>>>> boolean >>>>>>>>>> value); >>>>>>>>>> public native boolean enqueueMethodForCompilation(Method >>>>>>>>>> method, >>>>>>>>>> int compLevel); >>>>>>>>>> public native void clearMethodState(Method method); >>>>>>>>>> 2. related changes in not whitebox code: >>>>>>>>>> - added 'Method::clear_not_*_compilable()' and corresponded >>>>>>>>>> 'AccessFlags::clear_not_*_compilable()' >>>>>>>>>> - added 'MethodData::init()' - reset method data into original >>>>>>>>>> state. reset all counters, flags >>>>>>>>>> 3. removed useless code: >>>>>>>>>> - 'if (!TieredCompilation) { comp_level = >>>>>>>>>> CompLevel_highest_tier; >>>>>>>>>> }' in CompileBroker::compile_method() -- there is no method >>>>>>>>>> calls w/ >>>>>>>>>> comp_level != CompLevel_highest_tier in non-tiered >>>>>>>>>> - 'MethodData::initialize(methodHandle method)' -- declaration >>>>>>>>>> w/o >>>>>>>>>> definition >>>>>>>>>> 4. added tests for new WB functions >>>>>>>>>> >>>>>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.00/ >>>>>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8007288 >>>>>>>>>> -- >>>>>>>>>> Best regards, >>>>>>>>>> Igor Ignatyev >>>>>>>>> From john.coomes at oracle.com Thu Apr 4 20:55:17 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Apr 2013 03:55:17 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b84 for changeset f5f40094ffcc Message-ID: <20130405035526.75805480A5@hg.openjdk.java.net> Changeset: 41b50e2c5ea3 Author: katleman Date: 2013-04-04 19:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/41b50e2c5ea3 Added tag jdk8-b84 for changeset f5f40094ffcc ! .hgtags From john.coomes at oracle.com Thu Apr 4 20:55:32 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Apr 2013 03:55:32 +0000 Subject: hg: hsx/hotspot-comp/jaxws: 4 new changesets Message-ID: <20130405035543.51AD6480A6@hg.openjdk.java.net> Changeset: 0ab59cba6167 Author: jjg Date: 2013-03-18 18:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/0ab59cba6167 8007803: Implement javax.lang.model API for Type Annotations Reviewed-by: darcy ! src/share/jaxws_classes/com/sun/tools/internal/jxc/model/nav/ApNavigator.java Changeset: 2476e1f2afa5 Author: lana Date: 2013-03-26 12:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/2476e1f2afa5 Merge Changeset: 5773e3fc8380 Author: lana Date: 2013-04-01 21:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/5773e3fc8380 Merge Changeset: 8c0b6bccfe47 Author: katleman Date: 2013-04-04 19:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/8c0b6bccfe47 Added tag jdk8-b84 for changeset 5773e3fc8380 ! .hgtags From john.coomes at oracle.com Thu Apr 4 20:55:08 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Apr 2013 03:55:08 +0000 Subject: hg: hsx/hotspot-comp/corba: 5 new changesets Message-ID: <20130405035513.24315480A4@hg.openjdk.java.net> Changeset: c3ec80715805 Author: mfang Date: 2013-03-25 16:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/c3ec80715805 8010521: jdk8 l10n resource file translation update 2 Reviewed-by: naoto, yhuang ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_de.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_es.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_fr.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_it.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ja.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_sv.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_CN.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_TW.properties ! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_zh_CN.prp Changeset: 910af9c3f338 Author: mfang Date: 2013-03-25 18:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/910af9c3f338 Merge Changeset: 7d7a009d5fbd Author: lana Date: 2013-03-26 12:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/7d7a009d5fbd Merge Changeset: 928f8b888deb Author: lana Date: 2013-04-01 21:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/928f8b888deb Merge Changeset: 9583a6431596 Author: katleman Date: 2013-04-04 19:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/9583a6431596 Added tag jdk8-b84 for changeset 928f8b888deb ! .hgtags From john.coomes at oracle.com Thu Apr 4 20:55:03 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Apr 2013 03:55:03 +0000 Subject: hg: hsx/hotspot-comp: 8 new changesets Message-ID: <20130405035504.22806480A3@hg.openjdk.java.net> Changeset: 19a59a13b3ef Author: dholmes Date: 2013-03-14 01:41 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/19a59a13b3ef 8009428: Revert changes to $ substitution performed as part of nashorn integration Reviewed-by: alanb, erikj ! common/makefiles/MakeBase.gmk Changeset: 4984ac509993 Author: lana Date: 2013-03-15 23:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/4984ac509993 Merge Changeset: 477d18509ecb Author: lana Date: 2013-03-26 12:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/477d18509ecb Merge Changeset: a1bb1a0df1fa Author: lana Date: 2013-04-01 21:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/a1bb1a0df1fa Merge Changeset: 15c1642967c9 Author: andrew Date: 2013-04-02 13:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/15c1642967c9 8009988: build-infra: Fix configure output for zip debuginfo check Summary: No output from zip debuginfo option when default is used. Reviewed-by: tbell ! common/autoconf/autogen.sh ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: f3cdfb3d360d Author: omajid Date: 2013-04-02 14:13 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/f3cdfb3d360d 8011278: Allow using a system-installed giflib Reviewed-by: andrew, prr ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: 01f631f89fa3 Author: katleman Date: 2013-04-02 15:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/01f631f89fa3 Merge Changeset: a0fa9e93efee Author: katleman Date: 2013-04-04 19:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/a0fa9e93efee Added tag jdk8-b84 for changeset 01f631f89fa3 ! .hgtags From john.coomes at oracle.com Thu Apr 4 20:58:10 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Apr 2013 03:58:10 +0000 Subject: hg: hsx/hotspot-comp/jdk: 52 new changesets Message-ID: <20130405040906.16B96480A7@hg.openjdk.java.net> Changeset: 07acfb90700b Author: malenkov Date: 2013-03-14 12:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/07acfb90700b 8000183: 7163696: JCK Swing interactive test JScrollBarTest0013 fails with Nimbus and GTK L&Fs Reviewed-by: alexsch, serb ! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java + test/javax/swing/JScrollBar/7163696/Test7163696.java Changeset: d4e1c5803a59 Author: alexsch Date: 2013-03-15 17:02 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d4e1c5803a59 8009221: [macosx] Two closed/javax/swing regression tests fail on MacOSX. Reviewed-by: serb, alexp + test/javax/swing/JMenu/4515762/bug4515762.java + test/javax/swing/JRootPane/4670486/bug4670486.java ! test/javax/swing/regtesthelpers/Util.java Changeset: 2725b8a783e7 Author: lana Date: 2013-03-15 16:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2725b8a783e7 Merge - make/tools/javazic/Makefile - make/tools/src/build/tools/javazic/BackEnd.java - make/tools/src/build/tools/javazic/Checksum.java - make/tools/src/build/tools/javazic/DayOfWeek.java - make/tools/src/build/tools/javazic/Gen.java - make/tools/src/build/tools/javazic/GenDoc.java - make/tools/src/build/tools/javazic/Main.java - make/tools/src/build/tools/javazic/Mappings.java - make/tools/src/build/tools/javazic/Month.java - make/tools/src/build/tools/javazic/Rule.java - make/tools/src/build/tools/javazic/RuleDay.java - make/tools/src/build/tools/javazic/RuleRec.java - make/tools/src/build/tools/javazic/Simple.java - make/tools/src/build/tools/javazic/Time.java - make/tools/src/build/tools/javazic/Timezone.java - make/tools/src/build/tools/javazic/Zone.java - make/tools/src/build/tools/javazic/ZoneRec.java - make/tools/src/build/tools/javazic/Zoneinfo.java - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java - src/share/classes/java/util/function/Block.java - src/share/classes/java/util/function/DoubleBlock.java - src/share/classes/java/util/function/IntBlock.java - src/share/classes/java/util/function/LongBlock.java - src/share/classes/sun/security/util/KeyLength.java - test/javax/script/RhinoExceptionTest.java Changeset: 4bf5a5a72664 Author: serb Date: 2013-03-18 22:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4bf5a5a72664 8000435: [macosx] Button painting error under Java 7 on Mac Reviewed-by: denis, alexsch ! src/macosx/classes/com/apple/laf/AquaButtonBorder.java ! src/macosx/classes/com/apple/laf/AquaButtonExtendedTypes.java Changeset: af6049edac00 Author: kshefov Date: 2013-03-19 17:51 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/af6049edac00 8009881: TEST_BUG: javax/swing/JTree/8004298/bug8004298.java should be modified Reviewed-by: serb, alexsch ! test/javax/swing/JTree/8004298/bug8004298.java Changeset: 4e15c3e56315 Author: kshefov Date: 2013-03-20 14:02 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4e15c3e56315 8009880: TEST_BUG: Test java/beans/Introspector/TestTypeResolver.java should be modified again Reviewed-by: malenkov, alexsch ! test/java/beans/Introspector/TestTypeResolver.java Changeset: 87001c7bb678 Author: alitvinov Date: 2013-03-20 20:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/87001c7bb678 6550588: java.awt.Desktop cannot open file with Windows UNC filename Reviewed-by: art, uta ! src/windows/classes/sun/awt/windows/WDesktopPeer.java ! src/windows/native/sun/windows/awt_Desktop.cpp + test/java/awt/Desktop/OpenByUNCPathNameTest/OpenByUNCPathNameTest.java Changeset: ef948ef2b58f Author: alexsch Date: 2013-03-21 16:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ef948ef2b58f 8007146: [macosx] Setting a display mode crashes JDK under VNC Reviewed-by: serb ! src/macosx/native/sun/awt/CGraphicsDevice.m + test/java/awt/GraphicsDevice/CheckDisplayModes.java Changeset: a275acd8bcae Author: denis Date: 2013-03-22 19:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a275acd8bcae 7123476: DesktopOpenTests:When enter the file path and click the open button,it crash Reviewed-by: art, anthony ! make/sun/xawt/FILES_c_unix.gmk ! makefiles/CompileNativeLibraries.gmk ! src/solaris/native/sun/awt/gtk2_interface.c ! src/solaris/native/sun/awt/gtk2_interface.h ! src/solaris/native/sun/xawt/awt_Desktop.c + src/solaris/native/sun/xawt/gnome_interface.c + src/solaris/native/sun/xawt/gnome_interface.h Changeset: 15a2599f470f Author: lana Date: 2013-03-26 11:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/15a2599f470f Merge ! makefiles/CompileNativeLibraries.gmk Changeset: e497a050e059 Author: uta Date: 2013-03-13 13:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e497a050e059 7190897: (fs) Files.isWritable method returns false when the path is writable (win) Summary: The [GetEffectiveRightsFromAcl] based implementation was changed to the [AccessCheck] based. Reviewed-by: alanb ! src/windows/classes/sun/nio/fs/WindowsConstants.java ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java ! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java ! src/windows/classes/sun/nio/fs/WindowsSecurity.java ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c Changeset: e33cbbe21419 Author: alanb Date: 2013-03-13 17:58 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e33cbbe21419 8009751: (se) Selector spin when select, close and interestOps(0) invoked at same time (lnx) Reviewed-by: zhouyx, chegar, robm ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java Changeset: 94335b6ffb32 Author: jgish Date: 2013-03-13 11:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/94335b6ffb32 8002070: Remove the stack search for a resource bundle for Logger to use Summary: The fragile, vulnerable, stack crawling has been eliminated from findResourceBundle(String) Reviewed-by: mchung, alanb ! src/share/classes/java/util/logging/Logger.java ! test/java/util/logging/LoggerResourceBundleRace.java Changeset: ef0c60b93a17 Author: dxu Date: 2013-03-13 14:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ef0c60b93a17 8001334: Remove use of JVM_* functions from java.io code Summary: Replace JVM_* functions with direct system calls in java io area Reviewed-by: alanb, uta, martin ! make/java/nio/Makefile ! makefiles/CompileNativeLibraries.gmk ! src/share/native/java/io/ObjectOutputStream.c ! src/share/native/java/io/io_util.c ! src/share/native/java/io/io_util.h ! src/solaris/native/common/jdk_util_md.h ! src/solaris/native/java/io/FileDescriptor_md.c ! src/solaris/native/java/io/UnixFileSystem_md.c ! src/solaris/native/java/io/io_util_md.c ! src/solaris/native/java/io/io_util_md.h ! src/windows/native/common/jdk_util_md.h ! src/windows/native/java/io/io_util_md.c ! src/windows/native/java/io/io_util_md.h Changeset: f5c85c0a9af0 Author: robm Date: 2013-03-14 00:21 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f5c85c0a9af0 8009650: HttpClient available() check throws SocketException when connection has been closed Reviewed-by: chegar, khazra, dsamersoff Contributed-by: sdouglas at redhat.com ! src/share/classes/sun/net/www/http/HttpClient.java + test/sun/net/www/http/HttpClient/IsAvailable.java Changeset: 41289b4a1819 Author: dholmes Date: 2013-03-14 01:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/41289b4a1819 8009429: Miscellaneous profiles cleanup 8009428: Revert changes to $ substitution performed as part of nashorn integration Reviewed-by: alanb, erikj ! makefiles/CreateJars.gmk ! makefiles/ProfileNames.gmk ! makefiles/Profiles.gmk ! makefiles/profile-includes.txt ! makefiles/profile-rtjar-includes.txt Changeset: f010eb1e696f Author: alanb Date: 2013-03-14 16:03 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f010eb1e696f 8005716: Enhance JNI specification to allow support of static JNI libraries in Embedded JREs Reviewed-by: dlong, alanb, mduigou Contributed-by: bill.pittore at oracle.com, bob.vandette at oracle.com ! make/java/java/mapfile-vers ! makefiles/mapfiles/libjava/mapfile-vers ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Runtime.java ! src/share/classes/java/lang/System.java ! src/share/javavm/export/jni.h ! src/share/native/common/jni_util.h ! src/share/native/java/lang/ClassLoader.c ! src/solaris/native/common/jni_util_md.c ! src/windows/native/common/jni_util_md.c Changeset: ca9469a15792 Author: alanb Date: 2013-03-14 16:59 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ca9469a15792 7183800: TEST_BUG: Update tests to run on Ubuntu 12.04 (localhost is 127.0.1.1) Reviewed-by: alanb, chegar Contributed-by: yiming.wang at oracle.com ! test/java/nio/channels/DatagramChannel/Connect.java ! test/java/nio/channels/DatagramChannel/ConnectedSend.java ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/Launcher.java ! test/javax/management/remote/mandatory/connection/RMIConnectionIdTest.java Changeset: d79503c4c56f Author: naoto Date: 2013-03-14 11:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d79503c4c56f 8008576: Calendar mismatch using Host LocaleProviderAdapter Reviewed-by: okutsu ! make/java/java/FILES_java.gmk ! src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/sun/util/locale/LanguageTag.java ! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/CalendarProviderImpl.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java + src/share/classes/sun/util/spi/CalendarProvider.java ! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! src/windows/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c Changeset: 46ad8dfabd5f Author: sundar Date: 2013-03-15 19:30 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/46ad8dfabd5f 8010136: Make jrunscript's init.js to work on nashorn Reviewed-by: lagergren, hannesw ! src/share/classes/com/sun/tools/script/shell/init.js Changeset: c1a142965db0 Author: lana Date: 2013-03-15 23:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c1a142965db0 Merge ! makefiles/CompileNativeLibraries.gmk ! src/share/classes/java/util/logging/Logger.java - src/share/classes/sun/security/util/KeyLength.java Changeset: c1165d566a23 Author: vlivanov Date: 2013-03-06 16:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c1165d566a23 8009222: java.lang.IllegalArgumentException: not invocable, no method type when attempting to get getter method handle for a static field Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/DirectMethodHandle.java + test/java/lang/invoke/8009222/Test8009222.java Changeset: ec8229b26dbc Author: chegar Date: 2013-03-17 09:55 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ec8229b26dbc 8010142: ProblemList.txt updates (3/2013) Reviewed-by: alanb ! test/ProblemList.txt Changeset: a0275a47fa78 Author: sla Date: 2013-03-19 09:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a0275a47fa78 8006637: Failure to filter out native frame events on Solaris Summary: Test is confused by other threads calling String.intern(). Add a thread filter to avoid this. Reviewed-by: sspitsyn, alanb ! test/com/sun/jdi/NativeInstanceFilter.java Changeset: e766da5575fa Author: dholmes Date: 2013-03-19 06:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e766da5575fa 8009426: "profiles" target fails due to nashorn if "images" is not built first Reviewed-by: alanb ! makefiles/CreateJars.gmk ! makefiles/Profiles.gmk ! makefiles/profile-includes.txt Changeset: 4103eb6b2137 Author: jzavgren Date: 2013-03-18 14:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4103eb6b2137 8007607: security native code doesn't always use malloc, realloc, and calloc correctly Reviewed-by: chegar, dsamersoff, valeriep ! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c ! src/share/native/sun/security/jgss/wrapper/NativeUtil.c ! src/solaris/native/com/sun/security/auth/module/Solaris.c ! src/solaris/native/com/sun/security/auth/module/Unix.c ! src/solaris/native/sun/security/smartcardio/pcsc_md.c Changeset: 2241a2d34085 Author: mduigou Date: 2013-03-19 16:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2241a2d34085 8001642: Add Optional, OptionalDouble, OptionalInt, OptionalLong Reviewed-by: mduigou, darcy, alanb, jjb Contributed-by: Brian Goetz + src/share/classes/java/util/Optional.java + src/share/classes/java/util/OptionalDouble.java + src/share/classes/java/util/OptionalInt.java + src/share/classes/java/util/OptionalLong.java + test/java/util/Optional/Basic.java + test/java/util/Optional/BasicDouble.java + test/java/util/Optional/BasicInt.java + test/java/util/Optional/BasicLong.java Changeset: fb23896a01f5 Author: uta Date: 2013-03-20 13:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fb23896a01f5 8006193: (process) Clean-up java.lang.ProcessImpl.finalize, does not need to be public Reviewed-by: alanb ! src/windows/classes/java/lang/ProcessImpl.java Changeset: 3070b7363853 Author: chegar Date: 2013-03-20 14:39 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3070b7363853 8010282: sun.net.www.protocol.jar.JarFileFactory.close(JarFile) should be thread-safe Reviewed-by: khazra, alanb ! src/share/classes/sun/net/www/protocol/jar/JarURLConnection.java ! src/solaris/classes/sun/net/www/protocol/jar/JarFileFactory.java ! src/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java Changeset: 38116bfe5323 Author: mullan Date: 2013-03-20 10:58 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/38116bfe5323 8010112: NullPointerException in sun.security.provider.certpath.CertId() Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/CertId.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/share/classes/sun/security/x509/X509CertImpl.java Changeset: 9859856920ed Author: mullan Date: 2013-03-20 11:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9859856920ed Merge - src/share/classes/sun/security/util/KeyLength.java Changeset: 38c1d0c2d6a6 Author: mullan Date: 2013-03-20 12:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/38c1d0c2d6a6 Merge Changeset: ccd9f53377c4 Author: mchung Date: 2013-03-20 09:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ccd9f53377c4 8006104: Improve tests to test ".useParentHandlers" property set in the logging configuration Reviewed-by: alanb ! test/java/util/logging/CustomLogManager.java ! test/java/util/logging/CustomLogManagerTest.java Changeset: cf0049037deb Author: darcy Date: 2013-03-20 15:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cf0049037deb 8010427: Refine Method.isDefault implementation Reviewed-by: acorn, dlsmith ! src/share/classes/java/lang/reflect/Method.java Changeset: 3c1a4966d901 Author: dholmes Date: 2013-03-20 22:39 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3c1a4966d901 8006818: SunEC and SunPKCS11 providers should be in all profiles Reviewed-by: dholmes, alanb, valeriep Contributed-by: Jen Dority ! makefiles/profile-includes.txt Changeset: 9ee1aff76498 Author: sundar Date: 2013-03-21 19:19 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9ee1aff76498 8009869: Need to modify java.security property package.access to include nashorn packages Reviewed-by: ahgross, jlaskey, lagergren ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 3f8fbb0ab155 Author: robm Date: 2013-03-21 17:33 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3f8fbb0ab155 8009251: Add proxy handling and keep-alive fixes to jsse Reviewed-by: chegar ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/https/AbstractDelegateHttpsURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java Changeset: 93cd7052d306 Author: weijun Date: 2013-03-22 19:59 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/93cd7052d306 8010531: Add BadKdc* tests to problem list for solaris-sparcv9 Reviewed-by: alanb ! test/ProblemList.txt Changeset: 470232a8e89d Author: stefank Date: 2013-03-22 15:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/470232a8e89d 8005116: NPG: Rename -permstat option for jmap in jdk8 to -clstats Reviewed-by: jmasa, sla Contributed-by: Erik Helin ! src/share/classes/sun/tools/jmap/JMap.java Changeset: 518d6087e01f Author: stefank Date: 2013-03-22 15:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/518d6087e01f 8004172: Update jstat counter names to reflect metaspace changes Reviewed-by: mchung Contributed-by: Erik Helin ! src/share/classes/sun/tools/jstat/resources/jstat_options ! test/sun/tools/jstat/gcCapacityOutput1.awk ! test/sun/tools/jstat/gcCauseOutput1.awk + test/sun/tools/jstat/gcMetaCapacityOutput1.awk ! test/sun/tools/jstat/gcOldOutput1.awk ! test/sun/tools/jstat/gcOutput1.awk - test/sun/tools/jstat/gcPermCapacityOutput1.awk + test/sun/tools/jstat/jstatGcMetaCapacityOutput1.sh - test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh ! test/sun/tools/jstat/lineCounts1.awk ! test/sun/tools/jstat/lineCounts2.awk ! test/sun/tools/jstat/lineCounts3.awk ! test/sun/tools/jstat/lineCounts4.awk ! test/sun/tools/jstat/options1.out ! test/sun/tools/jstat/options2.out ! test/sun/tools/jstat/timeStamp1.awk ! test/sun/tools/jstatd/jstatGcutilOutput1.awk Changeset: 3470101fae58 Author: weijun Date: 2013-03-23 11:49 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3470101fae58 8009970: Several LoginModule classes need extra permission to load AuthResources Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java Changeset: ed63cace1d30 Author: weijun Date: 2013-03-23 11:49 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ed63cace1d30 8009875: Provide a default udp_preference_limit for krb5.conf Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/internal/Krb5.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/config/DefUdpLimit.java Changeset: d92a96dcbfe1 Author: sundar Date: 2013-03-25 19:25 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d92a96dcbfe1 8010704: The test closed/java/lang/SecurityManager/CheckPackageDefinition.java failed after fix for 8009869 Reviewed-by: lagergren, hannesw ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-solaris Changeset: 5d0c891264bf Author: chegar Date: 2013-03-25 14:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5d0c891264bf 8010668: builtin JNI libraries should not be unloaded Reviewed-by: chegar, alanb Contributed-by: Bill Pittore ! src/share/native/java/lang/ClassLoader.c Changeset: 5e383a73386a Author: mchung Date: 2013-03-25 17:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5e383a73386a 8007703: Remove com.sun.servicetag API Reviewed-by: dholmes, alanb, erikj ! make/com/sun/Makefile ! make/common/Release.gmk ! makefiles/CopyFiles.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcProperties.gmk ! makefiles/profile-includes.txt ! makefiles/profile-rtjar-includes.txt ! test/Makefile Changeset: 335d2156222e Author: mchung Date: 2013-03-25 18:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/335d2156222e 8010787: changeset for 8007703 is missing the deleted files Reviewed-by: dholmes, alanb, erikj - make/com/sun/servicetag/Makefile - src/share/classes/com/sun/servicetag/BrowserSupport.java - src/share/classes/com/sun/servicetag/Installer.java - src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java - src/share/classes/com/sun/servicetag/RegistrationData.java - src/share/classes/com/sun/servicetag/RegistrationDocument.java - src/share/classes/com/sun/servicetag/Registry.java - src/share/classes/com/sun/servicetag/ServiceTag.java - src/share/classes/com/sun/servicetag/SolarisServiceTag.java - src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java - src/share/classes/com/sun/servicetag/SunConnection.java - src/share/classes/com/sun/servicetag/SystemEnvironment.java - src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java - src/share/classes/com/sun/servicetag/Util.java - src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java - src/share/classes/com/sun/servicetag/package.html - src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt - src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties - src/share/classes/com/sun/servicetag/resources/jdk_header.png - src/share/classes/com/sun/servicetag/resources/product_registration.xsd - src/share/classes/com/sun/servicetag/resources/register.html - src/share/classes/com/sun/servicetag/resources/register_ja.html - src/share/classes/com/sun/servicetag/resources/register_zh_CN.html - test/com/sun/servicetag/DeleteServiceTag.java - test/com/sun/servicetag/DuplicateNotFound.java - test/com/sun/servicetag/FindServiceTags.java - test/com/sun/servicetag/InstanceUrnCheck.java - test/com/sun/servicetag/InvalidRegistrationData.java - test/com/sun/servicetag/InvalidServiceTag.java - test/com/sun/servicetag/JavaServiceTagTest.java - test/com/sun/servicetag/JavaServiceTagTest1.java - test/com/sun/servicetag/NewRegistrationData.java - test/com/sun/servicetag/SvcTagClient.java - test/com/sun/servicetag/SystemRegistryTest.java - test/com/sun/servicetag/TestLoadFromXML.java - test/com/sun/servicetag/UpdateServiceTagTest.java - test/com/sun/servicetag/Util.java - test/com/sun/servicetag/ValidRegistrationData.java - test/com/sun/servicetag/environ.properties - test/com/sun/servicetag/missing-environ-field.xml - test/com/sun/servicetag/newer-registry-version.xml - test/com/sun/servicetag/registration.xml - test/com/sun/servicetag/servicetag1.properties - test/com/sun/servicetag/servicetag2.properties - test/com/sun/servicetag/servicetag3.properties - test/com/sun/servicetag/servicetag4.properties - test/com/sun/servicetag/servicetag5.properties Changeset: 543d0fbc962e Author: lana Date: 2013-03-26 12:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/543d0fbc962e Merge - make/com/sun/servicetag/Makefile ! makefiles/CompileNativeLibraries.gmk - src/share/classes/com/sun/servicetag/BrowserSupport.java - src/share/classes/com/sun/servicetag/Installer.java - src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java - src/share/classes/com/sun/servicetag/RegistrationData.java - src/share/classes/com/sun/servicetag/RegistrationDocument.java - src/share/classes/com/sun/servicetag/Registry.java - src/share/classes/com/sun/servicetag/ServiceTag.java - src/share/classes/com/sun/servicetag/SolarisServiceTag.java - src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java - src/share/classes/com/sun/servicetag/SunConnection.java - src/share/classes/com/sun/servicetag/SystemEnvironment.java - src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java - src/share/classes/com/sun/servicetag/Util.java - src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java - src/share/classes/com/sun/servicetag/package.html - src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt - src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties - src/share/classes/com/sun/servicetag/resources/jdk_header.png - src/share/classes/com/sun/servicetag/resources/product_registration.xsd - src/share/classes/com/sun/servicetag/resources/register.html - src/share/classes/com/sun/servicetag/resources/register_ja.html - src/share/classes/com/sun/servicetag/resources/register_zh_CN.html - test/com/sun/servicetag/DeleteServiceTag.java - test/com/sun/servicetag/DuplicateNotFound.java - test/com/sun/servicetag/FindServiceTags.java - test/com/sun/servicetag/InstanceUrnCheck.java - test/com/sun/servicetag/InvalidRegistrationData.java - test/com/sun/servicetag/InvalidServiceTag.java - test/com/sun/servicetag/JavaServiceTagTest.java - test/com/sun/servicetag/JavaServiceTagTest1.java - test/com/sun/servicetag/NewRegistrationData.java - test/com/sun/servicetag/SvcTagClient.java - test/com/sun/servicetag/SystemRegistryTest.java - test/com/sun/servicetag/TestLoadFromXML.java - test/com/sun/servicetag/UpdateServiceTagTest.java - test/com/sun/servicetag/Util.java - test/com/sun/servicetag/ValidRegistrationData.java - test/com/sun/servicetag/environ.properties - test/com/sun/servicetag/missing-environ-field.xml - test/com/sun/servicetag/newer-registry-version.xml - test/com/sun/servicetag/registration.xml - test/com/sun/servicetag/servicetag1.properties - test/com/sun/servicetag/servicetag2.properties - test/com/sun/servicetag/servicetag3.properties - test/com/sun/servicetag/servicetag4.properties - test/com/sun/servicetag/servicetag5.properties - test/sun/tools/jstat/gcPermCapacityOutput1.awk - test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh Changeset: ea7d0f49e5dd Author: lana Date: 2013-04-01 21:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ea7d0f49e5dd Merge - make/com/sun/servicetag/Makefile - src/share/classes/com/sun/servicetag/BrowserSupport.java - src/share/classes/com/sun/servicetag/Installer.java - src/share/classes/com/sun/servicetag/LinuxSystemEnvironment.java - src/share/classes/com/sun/servicetag/RegistrationData.java - src/share/classes/com/sun/servicetag/RegistrationDocument.java - src/share/classes/com/sun/servicetag/Registry.java - src/share/classes/com/sun/servicetag/ServiceTag.java - src/share/classes/com/sun/servicetag/SolarisServiceTag.java - src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java - src/share/classes/com/sun/servicetag/SunConnection.java - src/share/classes/com/sun/servicetag/SystemEnvironment.java - src/share/classes/com/sun/servicetag/UnauthorizedAccessException.java - src/share/classes/com/sun/servicetag/Util.java - src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java - src/share/classes/com/sun/servicetag/package.html - src/share/classes/com/sun/servicetag/resources/Putback-Notes.txt - src/share/classes/com/sun/servicetag/resources/javase_5_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_6_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_7_swordfish.properties - src/share/classes/com/sun/servicetag/resources/javase_servicetag.properties - src/share/classes/com/sun/servicetag/resources/jdk_header.png - src/share/classes/com/sun/servicetag/resources/product_registration.xsd - src/share/classes/com/sun/servicetag/resources/register.html - src/share/classes/com/sun/servicetag/resources/register_ja.html - src/share/classes/com/sun/servicetag/resources/register_zh_CN.html - test/com/sun/servicetag/DeleteServiceTag.java - test/com/sun/servicetag/DuplicateNotFound.java - test/com/sun/servicetag/FindServiceTags.java - test/com/sun/servicetag/InstanceUrnCheck.java - test/com/sun/servicetag/InvalidRegistrationData.java - test/com/sun/servicetag/InvalidServiceTag.java - test/com/sun/servicetag/JavaServiceTagTest.java - test/com/sun/servicetag/JavaServiceTagTest1.java - test/com/sun/servicetag/NewRegistrationData.java - test/com/sun/servicetag/SvcTagClient.java - test/com/sun/servicetag/SystemRegistryTest.java - test/com/sun/servicetag/TestLoadFromXML.java - test/com/sun/servicetag/UpdateServiceTagTest.java - test/com/sun/servicetag/Util.java - test/com/sun/servicetag/ValidRegistrationData.java - test/com/sun/servicetag/environ.properties - test/com/sun/servicetag/missing-environ-field.xml - test/com/sun/servicetag/newer-registry-version.xml - test/com/sun/servicetag/registration.xml - test/com/sun/servicetag/servicetag1.properties - test/com/sun/servicetag/servicetag2.properties - test/com/sun/servicetag/servicetag3.properties - test/com/sun/servicetag/servicetag4.properties - test/com/sun/servicetag/servicetag5.properties - test/sun/tools/jstat/gcPermCapacityOutput1.awk - test/sun/tools/jstat/jstatGcPermCapacityOutput1.sh Changeset: b68094f8263f Author: erikj Date: 2013-03-28 09:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b68094f8263f 8010908: Images target failes when configured with --disable-zip-debug-info Reviewed-by: tbell ! makefiles/Images.gmk Changeset: 9c76ea43d491 Author: omajid Date: 2013-04-02 14:13 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9c76ea43d491 8011278: Allow using a system-installed giflib Reviewed-by: andrew, prr ! makefiles/CompileNativeLibraries.gmk ! src/share/native/sun/awt/splashscreen/splashscreen_gif.c Changeset: 7b4721e4edb4 Author: katleman Date: 2013-04-02 15:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7b4721e4edb4 Merge ! makefiles/CompileNativeLibraries.gmk Changeset: 43da85020921 Author: katleman Date: 2013-04-04 19:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/43da85020921 Added tag jdk8-b84 for changeset 7b4721e4edb4 ! .hgtags From john.coomes at oracle.com Thu Apr 4 21:12:43 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 05 Apr 2013 04:12:43 +0000 Subject: hg: hsx/hotspot-comp/langtools: 29 new changesets Message-ID: <20130405041410.BE6B6480A8@hg.openjdk.java.net> Changeset: eb0198033c5c Author: jfranck Date: 2013-03-13 22:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/eb0198033c5c 8006547: Repeating annotations: No Target on container annotation with all targets on base annotation gives compiler error Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/annotations/repeatingAnnotations/DefaultTarget.java + test/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeParameter.java + test/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeParameter.out + test/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeUse.java + test/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeUse.out + test/tools/javac/annotations/repeatingAnnotations/NoTargetOnContainer.java + test/tools/javac/annotations/repeatingAnnotations/NoTargetOnContainer2.java Changeset: e0ef84e33167 Author: bpatel Date: 2013-03-13 14:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/e0ef84e33167 8009684: Default top left frame should be "All Packages" in the generated javadoc documentation Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java ! test/com/sun/javadoc/testProfiles/TestProfiles.java Changeset: 82dc1e827c2a Author: dholmes Date: 2013-03-14 01:45 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/82dc1e827c2a 8009429: Miscellaneous profiles cleanup Reviewed-by: jjg, alanb ! src/share/classes/com/sun/tools/javac/sym/Profiles.java Changeset: 2e21ecd7a5ad Author: vromero Date: 2013-03-14 08:30 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/2e21ecd7a5ad 8008582: jtreg failures after conversion of shell tests to Java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/ArrayUtils.java ! test/tools/javac/4846262/CheckEBCDICLocaleTest.java ! test/tools/javac/ClassPathTest/ClassPathTest.java ! test/tools/javac/ProtectedInnerClass/ProtectedInnerClassesTest.java ! test/tools/javac/lib/ToolBox.java ! test/tools/javac/links/LinksTest.java ! test/tools/javac/newlines/NewLineTest.java ! test/tools/javah/6257087/T6257087.java ! test/tools/javah/constMacroTest/ConstMacroTest.java ! test/tools/javap/stackmap/StackmapTest.java Changeset: fd3fdaff0257 Author: mchung Date: 2013-03-14 10:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/fd3fdaff0257 8005428: Update jdeps to read the same profile information as by javac Reviewed-by: alanb ! make/netbeans/langtools/nbproject/project.xml ! src/share/classes/com/sun/tools/jdeps/Analyzer.java ! src/share/classes/com/sun/tools/jdeps/ClassFileReader.java ! src/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/share/classes/com/sun/tools/jdeps/PlatformClassPath.java + src/share/classes/com/sun/tools/jdeps/Profiles.java ! src/share/classes/com/sun/tools/jdeps/resources/jdeps.properties - src/share/classes/com/sun/tools/jdeps/resources/jdk.properties ! test/tools/jdeps/Basic.java ! test/tools/jdeps/p/Foo.java + test/tools/jdeps/profiles.properties Changeset: fbbf5376e7e4 Author: rfield Date: 2013-03-14 22:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/fbbf5376e7e4 8010010: NPE generating serializedLambdaName for nested lambda Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/LambdaLambdaSerialized.java Changeset: fa24eba012bd Author: vromero Date: 2013-03-15 09:02 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/fa24eba012bd 5053846: javac: MethodRef entries are duplicated in the constant pool Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/T5053846/MethodRefDupInConstantPoolTest.java Changeset: 195b71850b56 Author: mnunez Date: 2013-03-15 13:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/195b71850b56 8007767: TargetAnnoCombo.java need to be updated to add a new test mode Reviewed-by: jjg, strarup ! test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java ! test/tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java - test/tools/javac/annotations/repeatingAnnotations/combo/TestCaseGenerator.java Changeset: a3049f4a7987 Author: lana Date: 2013-03-15 23:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a3049f4a7987 Merge Changeset: 1f8c28134ffc Author: jjg Date: 2013-03-18 08:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/1f8c28134ffc 8005220: RFE to write javap tests for repeating annotations. Reviewed-by: jjg Contributed-by: peter.jensen at oracle.com + test/tools/javap/output/RepeatingTypeAnnotations.java + test/tools/javap/output/Tester.java Changeset: 40adaf938847 Author: jjg Date: 2013-03-18 14:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/40adaf938847 8008425: Remove interim new javax.lang.model API for type-annotations Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java - src/share/classes/javax/lang/model/type/AnnotatedType.java ! src/share/classes/javax/lang/model/type/ExecutableType.java ! src/share/classes/javax/lang/model/type/TypeKind.java ! src/share/classes/javax/lang/model/type/TypeVisitor.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/Types.java Changeset: 97f6839673d6 Author: jjg Date: 2013-03-18 18:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/97f6839673d6 8007803: Implement javax.lang.model API for Type Annotations Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java + src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java + src/share/classes/javax/lang/model/AnnotatedConstruct.java ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/ExecutableElement.java ! src/share/classes/javax/lang/model/type/ExecutableType.java ! src/share/classes/javax/lang/model/type/TypeMirror.java ! src/share/classes/javax/lang/model/util/Types.java Changeset: a4913ea9bb62 Author: darcy Date: 2013-03-19 13:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a4913ea9bb62 8010179: Remove transitional target values from javac Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! test/tools/javac/ClassFileModifiers/MemberModifiers.java ! test/tools/javac/profiles/ProfileOptionTest.java Changeset: 578eb3dd111d Author: jjg Date: 2013-03-19 15:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/578eb3dd111d 8010315: doclint errors in javac public API Reviewed-by: darcy ! make/build.xml ! src/share/classes/com/sun/source/util/DocTreeScanner.java ! src/share/classes/com/sun/source/util/JavacTask.java ! src/share/classes/com/sun/source/util/Plugin.java ! src/share/classes/javax/lang/model/AnnotatedConstruct.java ! src/share/classes/javax/lang/model/type/ExecutableType.java Changeset: a03c4a86ea2b Author: jjg Date: 2013-03-19 17:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a03c4a86ea2b 8010361: fix some langtools findbugs issues Reviewed-by: darcy ! src/share/classes/com/sun/tools/classfile/Code_attribute.java ! src/share/classes/com/sun/tools/classfile/Descriptor.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/javah/Util.java ! src/share/classes/com/sun/tools/javap/StackMapWriter.java ! src/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/share/classes/com/sun/tools/jdeps/PlatformClassPath.java ! src/share/classes/com/sun/tools/sjavac/Main.java ! src/share/classes/com/sun/tools/sjavac/comp/Dependencies.java Changeset: 9cf17b7a5fe7 Author: jjg Date: 2013-03-19 17:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/9cf17b7a5fe7 8010333: Remove com.sun.tools.javac.Server Reviewed-by: darcy - src/share/classes/com/sun/tools/javac/Server.java Changeset: 74d7f9bcac93 Author: jjg Date: 2013-03-19 19:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/74d7f9bcac93 8010317: DocLint incorrectly reports some
 tags as empty
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclint/Checker.java
+ test/tools/doclint/EmptyPreTest.java

Changeset: 972474640b7d
Author:    darcy
Date:      2013-03-20 17:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/972474640b7d

8010364: Clarify javax.lang.model API for Type Annotations
Reviewed-by: jjg, abuckley

! src/share/classes/javax/lang/model/AnnotatedConstruct.java
! src/share/classes/javax/lang/model/type/ExecutableType.java

Changeset: cc38a6723663
Author:    mcimadamore
Date:      2013-03-22 12:38 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/cc38a6723663

8009649: Lambda back-end should generate invokespecial for method handles referring to private instance methods
Summary: Private lambda methods should be accessed through invokespecial
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/tools/javac/lambda/bytecode/TestLambdaBytecode.java

Changeset: f3814edefb33
Author:    mcimadamore
Date:      2013-03-22 12:39 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f3814edefb33

8010101: Intersection type cast issues redundant unchecked warning
Summary: Code for checking intersection type cast is incorrectly swapping operands, leading to spurious warnings
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/lambda/Intersection02.java
+ test/tools/javac/lambda/Intersection02.out

Changeset: b6cf07c54c29
Author:    mcimadamore
Date:      2013-03-22 12:41 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/b6cf07c54c29

8009820: AssertionError when compiling java code with two identical static imports
Summary: Speculative attribution is carried out twice with same method symbol in case of static imports
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
+ test/tools/javac/lambda/DoubleStaticImport.java

Changeset: c6728c9addff
Author:    mcimadamore
Date:      2013-03-22 12:43 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/c6728c9addff

8010303: Graph inference: missing incorporation step causes spurious inference error
Summary: Multiple equality constraints on inference vars are not used to generate new inference constraints
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! test/tools/javac/lambda/TargetType28.out
+ test/tools/javac/lambda/TargetType67.java
+ test/tools/javac/lambda/TargetType68.java
+ test/tools/javac/lambda/TargetType69.java

Changeset: 5da12e8a59ba
Author:    mcimadamore
Date:      2013-03-22 12:44 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/5da12e8a59ba

8010387: Javac crashes when diagnostic mentions anonymous inner class' type variables
Summary: Rich formatter doesn't preprocess supertypes of an anonymous inner class
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
+ test/tools/javac/Diagnostics/8010387/T8010387.java
+ test/tools/javac/Diagnostics/8010387/T8010387.out

Changeset: f4500abff1fd
Author:    darcy
Date:      2013-03-22 10:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f4500abff1fd

7080464: langtools regression test failures when assertions are enabled
Reviewed-by: jjg

! test/tools/javac/api/TestJavacTaskScanner.java
! test/tools/javac/diags/MessageFile.java
! test/tools/javac/diags/MessageInfo.java

Changeset: fdf30b225e1c
Author:    mfang
Date:      2013-03-25 16:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/fdf30b225e1c

8010521: jdk8 l10n resource file translation update 2
Reviewed-by: naoto, yhuang

! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties
! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties
! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties
! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties
! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties
! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties
! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties
! src/share/classes/com/sun/tools/javah/resources/l10n_zh_CN.properties

Changeset: 65e1ca8dcdc7
Author:    mfang
Date:      2013-03-25 18:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/65e1ca8dcdc7

Merge


Changeset: 28e466e9cd34
Author:    lana
Date:      2013-03-26 12:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/28e466e9cd34

Merge

- src/share/classes/com/sun/tools/javac/Server.java
- src/share/classes/com/sun/tools/jdeps/resources/jdk.properties
- src/share/classes/javax/lang/model/type/AnnotatedType.java
- test/tools/javac/annotations/repeatingAnnotations/combo/TestCaseGenerator.java

Changeset: cfb65ca92082
Author:    lana
Date:      2013-04-01 21:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/cfb65ca92082

Merge

- src/share/classes/com/sun/tools/javac/Server.java
- src/share/classes/com/sun/tools/jdeps/resources/jdk.properties
- src/share/classes/javax/lang/model/type/AnnotatedType.java
- test/tools/javac/annotations/repeatingAnnotations/combo/TestCaseGenerator.java

Changeset: 4a48f3173534
Author:    katleman
Date:      2013-04-04 19:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/4a48f3173534

Added tag jdk8-b84 for changeset cfb65ca92082

! .hgtags


From john.coomes at oracle.com  Thu Apr  4 21:14:20 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 05 Apr 2013 04:14:20 +0000
Subject: hg: hsx/hotspot-comp/nashorn: 16 new changesets
Message-ID: <20130405041435.BF074480A9@hg.openjdk.java.net>

Changeset: c54e218333be
Author:    sundar
Date:      2013-03-12 18:12 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/c54e218333be

8009757: Package access clean up and refactoring
Reviewed-by: jlaskey, lagergren, attila

! docs/JavaScriptingProgrammersGuide.html
! docs/source/javaarray.js
! make/build.xml
! make/java.security.override
! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java
+ src/jdk/nashorn/api/scripting/ScriptUtils.java
! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/objects/NativeDebug.java
! src/jdk/nashorn/internal/objects/NativeJava.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/NashornLoader.java
! src/jdk/nashorn/internal/runtime/ScriptLoader.java
! src/jdk/nashorn/internal/runtime/StructureLoader.java
! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
+ src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java
! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js
! src/jdk/nashorn/internal/runtime/resources/parser.js
! test/script/basic/JDK-8008448.js
! test/script/basic/NASHORN-401.js
! test/script/basic/consstring.js
! test/script/basic/fileline.js
! test/script/basic/javainnerclasses.js
! test/script/basic/list.js
! test/script/basic/map.js
! test/script/basic/stdin.js
! test/script/sandbox/javaextend.js
! test/script/sandbox/javaextend.js.EXPECTED
! test/script/sandbox/reflection.js
- test/script/sandbox/reflection.js.EXPECTED
! test/script/sandbox/unsafe.js
- test/script/sandbox/unsafe.js.EXPECTED
! test/script/trusted/urlreader.js
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java
- test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java
! test/src/jdk/nashorn/internal/runtime/TrustedScriptEngineTest.java
- test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java
- test/src/jdk/nashorn/internal/test/models/DessertTopping.java
- test/src/jdk/nashorn/internal/test/models/DessertToppingFloorWaxDriver.java
- test/src/jdk/nashorn/internal/test/models/FinalClass.java
- test/src/jdk/nashorn/internal/test/models/FloorWax.java
- test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java
- test/src/jdk/nashorn/internal/test/models/NonPublicClass.java
- test/src/jdk/nashorn/internal/test/models/OuterClass.java
- test/src/jdk/nashorn/internal/test/models/OverloadedSam.java
- test/src/jdk/nashorn/internal/test/models/OverrideObject.java
- test/src/jdk/nashorn/internal/test/models/StringArgs.java
- test/src/jdk/nashorn/internal/test/models/Toothpaste.java
+ test/src/jdk/nashorn/test/models/ConstructorWithArgument.java
+ test/src/jdk/nashorn/test/models/DessertTopping.java
+ test/src/jdk/nashorn/test/models/DessertToppingFloorWaxDriver.java
+ test/src/jdk/nashorn/test/models/FinalClass.java
+ test/src/jdk/nashorn/test/models/FloorWax.java
+ test/src/jdk/nashorn/test/models/Nashorn401TestSubject.java
+ test/src/jdk/nashorn/test/models/NoAccessibleConstructorClass.java
+ test/src/jdk/nashorn/test/models/NonPublicClass.java
+ test/src/jdk/nashorn/test/models/OuterClass.java
+ test/src/jdk/nashorn/test/models/OverloadedSam.java
+ test/src/jdk/nashorn/test/models/OverrideObject.java
+ test/src/jdk/nashorn/test/models/SourceHelper.java
+ test/src/jdk/nashorn/test/models/StringArgs.java
+ test/src/jdk/nashorn/test/models/Toothpaste.java

Changeset: e15806b9d716
Author:    lagergren
Date:      2013-03-12 15:30 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/e15806b9d716

8009718: Lazy execution architecture continued - ScriptFunctionData is either final or recompilable. Moved ScriptFunctionData creation logic away from runtime to compile time. Prepared for method generation/specialization. Got rid of ScriptFunctionImplTrampoline whose semantics could be done as part of the relinking anyway. Merge with the lookup package change.
Reviewed-by: attila, jlaskey

! src/jdk/nashorn/internal/codegen/Attr.java
! src/jdk/nashorn/internal/codegen/BranchOptimizer.java
! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/CompilationPhase.java
! src/jdk/nashorn/internal/codegen/CompileUnit.java
! src/jdk/nashorn/internal/codegen/Compiler.java
! src/jdk/nashorn/internal/codegen/FinalizeTypes.java
! src/jdk/nashorn/internal/codegen/FoldConstants.java
! src/jdk/nashorn/internal/codegen/FunctionSignature.java
! src/jdk/nashorn/internal/codegen/Lower.java
! src/jdk/nashorn/internal/codegen/Splitter.java
! src/jdk/nashorn/internal/codegen/types/Type.java
! src/jdk/nashorn/internal/ir/Block.java
! src/jdk/nashorn/internal/ir/FunctionNode.java
! src/jdk/nashorn/internal/ir/ObjectNode.java
! src/jdk/nashorn/internal/ir/UnaryNode.java
- src/jdk/nashorn/internal/ir/annotations/ChildNode.java
- src/jdk/nashorn/internal/ir/annotations/ParentNode.java
! src/jdk/nashorn/internal/ir/annotations/Reference.java
! src/jdk/nashorn/internal/ir/debug/ASTWriter.java
! src/jdk/nashorn/internal/objects/NativeArray.java
! src/jdk/nashorn/internal/objects/NativeDebug.java
! src/jdk/nashorn/internal/objects/NativeError.java
! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java
- src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java
! src/jdk/nashorn/internal/parser/JSONParser.java
! src/jdk/nashorn/internal/parser/Parser.java
! src/jdk/nashorn/internal/runtime/AccessorProperty.java
! src/jdk/nashorn/internal/runtime/CodeInstaller.java
+ src/jdk/nashorn/internal/runtime/CompiledFunction.java
+ src/jdk/nashorn/internal/runtime/CompiledFunctions.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/ECMAException.java
+ src/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java
+ src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java
! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java
! src/jdk/nashorn/internal/runtime/ScriptFunction.java
! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java
- src/jdk/nashorn/internal/runtime/SpecializedMethodChooser.java
! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java
! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java
! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java
! src/jdk/nashorn/internal/runtime/resources/Options.properties
! test/script/currently-failing/JDK-8006529.js
+ test/script/currently-failing/clone_ir.js

Changeset: 60684aeba89c
Author:    sundar
Date:      2013-03-12 21:17 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/60684aeba89c

8009868: For loop with "true" as condition results in AssertionError in codegen
Reviewed-by: jlaskey, hannesw, lagergren

! src/jdk/nashorn/internal/codegen/Lower.java
+ test/script/basic/JDK-8009868.js

Changeset: 390d44ba90cf
Author:    lagergren
Date:      2013-03-14 14:49 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/390d44ba90cf

8009982: Lazy execution bugfix. Added lazy sunspider unit test. Added mandreel to compile-octane test. Fixed warnings
Reviewed-by: sundar, jlaskey

! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java
! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/Compiler.java
! src/jdk/nashorn/internal/ir/FunctionNode.java
! src/jdk/nashorn/internal/objects/Global.java
! src/jdk/nashorn/internal/parser/Parser.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/ScriptLoader.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
! src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java
! src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java
! src/jdk/nashorn/internal/runtime/regexp/RegExp.java
! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java
! src/jdk/nashorn/internal/runtime/regexp/RegExpResult.java
! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
! test/script/basic/compile-octane.js.EXPECTED
! test/script/basic/run-octane.js
+ test/script/basic/runsunspider-eager.js
+ test/script/basic/runsunspider-lazy.js
! test/script/basic/runsunspider.js

Changeset: d5d80b52cf1c
Author:    lagergren
Date:      2013-03-15 16:07 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/d5d80b52cf1c

8010147: Forgot to add EXPECTED files for lazy and eager sunspider test
Reviewed-by: sundar, jlaskey

+ test/script/basic/runsunspider-eager.js.EXPECTED
+ test/script/basic/runsunspider-lazy.js.EXPECTED
- test/script/basic/runsunspider.js.EXPECTED

Changeset: 4daacf8a25ef
Author:    sundar
Date:      2013-03-15 21:52 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/4daacf8a25ef

8010145: removed workaround "init.js" in nashorn repo
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/api/scripting/Formatter.java
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
! src/jdk/nashorn/api/scripting/ScriptUtils.java
! src/jdk/nashorn/api/scripting/resources/engine.js
- src/jdk/nashorn/api/scripting/resources/init.js

Changeset: 3b0a0d9d51f0
Author:    sundar
Date:      2013-03-18 21:03 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/3b0a0d9d51f0

8010199: javax.script.Invocable implementation for nashorn does not return null when matching functions are missing
Reviewed-by: lagergren, jlaskey

! bin/jjs
! bin/jjssecure
! bin/nashorn
! bin/nashornsecure
! src/jdk/nashorn/api/scripting/NashornScriptEngine.java
+ test/script/basic/JDK-8010199.js
! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java

Changeset: 606a1946e3e2
Author:    jlaskey
Date:      2013-03-19 11:03 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/606a1946e3e2

8009969: CodeCoverage should use template
Reviewed-by: jlaskey, sundar
Contributed-by: pavel.stepanov at oracle.com

! make/build.xml
! make/code_coverage.xml
! make/project.properties

Changeset: 4be452026847
Author:    attila
Date:      2013-03-23 00:58 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/4be452026847

8010652: Eliminate non-child references in Block/FunctionNode, and make few node types immutable
Reviewed-by: jlaskey, lagergren

! make/project.properties
! src/jdk/nashorn/internal/codegen/Attr.java
! src/jdk/nashorn/internal/codegen/ClassEmitter.java
! src/jdk/nashorn/internal/codegen/CodeGenerator.java
! src/jdk/nashorn/internal/codegen/CompilationPhase.java
! src/jdk/nashorn/internal/codegen/Compiler.java
! src/jdk/nashorn/internal/codegen/FinalizeTypes.java
! src/jdk/nashorn/internal/codegen/FoldConstants.java
! src/jdk/nashorn/internal/codegen/FunctionSignature.java
! src/jdk/nashorn/internal/codegen/Lower.java
! src/jdk/nashorn/internal/codegen/MethodEmitter.java
! src/jdk/nashorn/internal/codegen/Splitter.java
! src/jdk/nashorn/internal/codegen/WeighNodes.java
! src/jdk/nashorn/internal/ir/AccessNode.java
! src/jdk/nashorn/internal/ir/Assignment.java
! src/jdk/nashorn/internal/ir/BaseNode.java
! src/jdk/nashorn/internal/ir/BinaryNode.java
! src/jdk/nashorn/internal/ir/Block.java
! src/jdk/nashorn/internal/ir/BreakNode.java
! src/jdk/nashorn/internal/ir/CallNode.java
! src/jdk/nashorn/internal/ir/CaseNode.java
! src/jdk/nashorn/internal/ir/CatchNode.java
! src/jdk/nashorn/internal/ir/ContinueNode.java
! src/jdk/nashorn/internal/ir/DoWhileNode.java
! src/jdk/nashorn/internal/ir/EmptyNode.java
! src/jdk/nashorn/internal/ir/ExecuteNode.java
! src/jdk/nashorn/internal/ir/ForNode.java
! src/jdk/nashorn/internal/ir/FunctionNode.java
! src/jdk/nashorn/internal/ir/IdentNode.java
! src/jdk/nashorn/internal/ir/IfNode.java
! src/jdk/nashorn/internal/ir/IndexNode.java
! src/jdk/nashorn/internal/ir/LabelNode.java
+ src/jdk/nashorn/internal/ir/LexicalContext.java
! src/jdk/nashorn/internal/ir/LineNumberNode.java
! src/jdk/nashorn/internal/ir/LiteralNode.java
! src/jdk/nashorn/internal/ir/Location.java
! src/jdk/nashorn/internal/ir/Node.java
! src/jdk/nashorn/internal/ir/ObjectNode.java
! src/jdk/nashorn/internal/ir/PropertyNode.java
- src/jdk/nashorn/internal/ir/ReferenceNode.java
! src/jdk/nashorn/internal/ir/ReturnNode.java
! src/jdk/nashorn/internal/ir/RuntimeNode.java
! src/jdk/nashorn/internal/ir/SplitNode.java
! src/jdk/nashorn/internal/ir/SwitchNode.java
! src/jdk/nashorn/internal/ir/Symbol.java
! src/jdk/nashorn/internal/ir/TernaryNode.java
! src/jdk/nashorn/internal/ir/ThrowNode.java
! src/jdk/nashorn/internal/ir/TryNode.java
! src/jdk/nashorn/internal/ir/TypeOverride.java
! src/jdk/nashorn/internal/ir/UnaryNode.java
! src/jdk/nashorn/internal/ir/VarNode.java
! src/jdk/nashorn/internal/ir/WhileNode.java
! src/jdk/nashorn/internal/ir/WithNode.java
! src/jdk/nashorn/internal/ir/debug/JSONWriter.java
! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java
! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java
! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java
! src/jdk/nashorn/internal/parser/Parser.java
! src/jdk/nashorn/internal/runtime/Context.java
! src/jdk/nashorn/internal/runtime/resources/Messages.properties
! test/script/basic/JDK-8006755.js
! test/script/basic/NASHORN-837.js
! test/src/jdk/nashorn/internal/codegen/CompilerTest.java

Changeset: ae4ef3102d9c
Author:    lagergren
Date:      2013-03-25 12:01 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/ae4ef3102d9c

8017010: index evaluation to a temporary location for index operator much change temporaries to slots, but never scoped vars
Reviewed-by: hannesw, sundar

! src/jdk/nashorn/internal/codegen/Attr.java
! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java
! src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java
+ test/script/basic/JDK-8017010.js
+ test/script/basic/JDK-8017010.js.EXPECTED
! test/script/basic/NASHORN-258.js
! test/script/basic/NASHORN-258.js.EXPECTED

Changeset: 15dac7439921
Author:    sundar
Date:      2013-03-25 18:20 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/15dac7439921

8010709: org on the top level doesn't resolve
Reviewed-by: lagergren, hannesw

! src/jdk/nashorn/internal/objects/Global.java
+ test/script/basic/JDK-8010709.js

Changeset: 43e40c08e7f8
Author:    lagergren
Date:      2013-03-26 08:42 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/43e40c08e7f8

8010706: -Dnashorn.args system property to create command lines to wrapped nashorn.jar:s
Reviewed-by: hannesw, sundar

! docs/DEVELOPER_README
! src/jdk/nashorn/internal/runtime/options/Options.java

Changeset: ed60078f0a80
Author:    sundar
Date:      2013-03-26 18:26 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/ed60078f0a80

8010720: Linkage problem with java.lang.String.length()
Reviewed-by: hannesw, lagergren

! src/jdk/nashorn/internal/objects/NativeString.java
! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java
+ test/script/basic/JDK-8010720.js

Changeset: db8a33cb22b8
Author:    lana
Date:      2013-03-26 12:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/db8a33cb22b8

Merge

- src/jdk/nashorn/api/scripting/resources/init.js
- src/jdk/nashorn/internal/ir/ReferenceNode.java
- src/jdk/nashorn/internal/ir/annotations/ChildNode.java
- src/jdk/nashorn/internal/ir/annotations/ParentNode.java
- src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java
- src/jdk/nashorn/internal/runtime/SpecializedMethodChooser.java
- test/script/basic/runsunspider.js.EXPECTED
- test/script/sandbox/reflection.js.EXPECTED
- test/script/sandbox/unsafe.js.EXPECTED
- test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java
- test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java
- test/src/jdk/nashorn/internal/test/models/DessertTopping.java
- test/src/jdk/nashorn/internal/test/models/DessertToppingFloorWaxDriver.java
- test/src/jdk/nashorn/internal/test/models/FinalClass.java
- test/src/jdk/nashorn/internal/test/models/FloorWax.java
- test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java
- test/src/jdk/nashorn/internal/test/models/NonPublicClass.java
- test/src/jdk/nashorn/internal/test/models/OuterClass.java
- test/src/jdk/nashorn/internal/test/models/OverloadedSam.java
- test/src/jdk/nashorn/internal/test/models/OverrideObject.java
- test/src/jdk/nashorn/internal/test/models/StringArgs.java
- test/src/jdk/nashorn/internal/test/models/Toothpaste.java

Changeset: 999cc1bf5520
Author:    lana
Date:      2013-04-01 21:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/999cc1bf5520

Merge

- src/jdk/nashorn/api/scripting/resources/init.js
- src/jdk/nashorn/internal/ir/ReferenceNode.java
- src/jdk/nashorn/internal/ir/annotations/ChildNode.java
- src/jdk/nashorn/internal/ir/annotations/ParentNode.java
- src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java
- src/jdk/nashorn/internal/runtime/SpecializedMethodChooser.java
- test/script/basic/runsunspider.js.EXPECTED
- test/script/sandbox/reflection.js.EXPECTED
- test/script/sandbox/unsafe.js.EXPECTED
- test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java
- test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java
- test/src/jdk/nashorn/internal/test/models/DessertTopping.java
- test/src/jdk/nashorn/internal/test/models/DessertToppingFloorWaxDriver.java
- test/src/jdk/nashorn/internal/test/models/FinalClass.java
- test/src/jdk/nashorn/internal/test/models/FloorWax.java
- test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java
- test/src/jdk/nashorn/internal/test/models/NonPublicClass.java
- test/src/jdk/nashorn/internal/test/models/OuterClass.java
- test/src/jdk/nashorn/internal/test/models/OverloadedSam.java
- test/src/jdk/nashorn/internal/test/models/OverrideObject.java
- test/src/jdk/nashorn/internal/test/models/StringArgs.java
- test/src/jdk/nashorn/internal/test/models/Toothpaste.java

Changeset: e0378f0a50da
Author:    katleman
Date:      2013-04-04 19:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/e0378f0a50da

Added tag jdk8-b84 for changeset 999cc1bf5520

! .hgtags


From igor.ignatyev at oracle.com  Fri Apr  5 00:31:43 2013
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 05 Apr 2013 11:31:43 +0400
Subject: RFR(M): 8007288: Additional WB API for compiler's testing
In-Reply-To: <515E22FD.7020302@oracle.com>
References: <5154B8F1.2030108@oracle.com>
	<0549160A-DBFE-42A8-9AAE-AC98CB066D09@oracle.com>
	<51599671.4090501@oracle.com> <5159C42E.7000208@oracle.com>
	<515A9B8A.6040503@oracle.com> <515B2F49.7050305@oracle.com>
	<515C8469.40901@oracle.com> <515C8FC2.2010900@oracle.com>
	<515D206F.7060307@oracle.com> <515DB4BB.8040209@oracle.com>
	<515E22FD.7020302@oracle.com>
Message-ID: <515E7DDF.4010102@oracle.com>

Vladimir,

Thanks for the review.

Best regards,
Igor Ignatyev

On 04/05/2013 05:03 AM, Vladimir Kozlov wrote:
> Don't change ciReplay.cpp now. File a new bug on hotspot/compiler
> because compilation level should be recorded by
> ciEnv::dump_replay_data() and used during replay.
>
> It does not affect WB testing because it is only used during replay
> compilation.
>
>  > The only place where used inaccurate 'comp_level' is
>  > 'NonTieredCompPolicy::initial_compile_level', and I think it would be
>  > better if it returns correct level.
>
> So the problem is next #if which is always true for Server VM now:
>
> #if defined(TIERED)
> CompLevel_initial_compile   = CompLevel_full_profile
>
> but NonTieredCompPolicy is selected (CompilationPolicyChoice==0) based
> on TieredCompilation flag.
>
> Okay, you fix for NonTieredCompPolicy::initial_compile_level is correct.
>
> Thanks,
> Vladimir
>
> On 4/4/13 10:13 AM, Igor Ignatyev wrote:
>> I also found another place with inaccurate comp_level in
>> 'ciReplay.cpp::process_compile()', there always uses
>> 'CompLevel_full_optimization'.
>>
>> webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.03/
>>
>> Best regards,
>> Igor Ignatyev
>>
>> On 04/04/2013 10:40 AM, Igor Ignatyev wrote:
>>>>> Now, why you need new changes in compilationPolicy.hpp? It was not in
>>>>> previous webrev. Yes, it may be correct but why?
>>>
>>> After I had look-see 'globalDefinitions' I mistakenly decided that
>>> 'CompLevel_initial_compile' always is 'CompLevel_full_optimization' for
>>> C2. So I said that 'comp_level' always equals 'CompLevel_highest_tier'
>>> in 'CompileBroker::compile_method' for non-tiered, but it isn't true,
>>> because 'NonTieredCompPolicy::initial_compile_level' returns
>>> 'CompLevel_full_profile' when 'TIERED' is defined.
>>>
>>> On the one hand I want to be able to use any 'comp_level' in
>>> 'CompileBroker::compile_method' from WhiteBoxAPI, so I need to remove
>>> 'if (!TieredCompilation) { comp_level = CompLevel_highest_tier; }'. On
>>> the other hand,  we must use only 'CompLevel_highest_tier' for
>>> non-tiered in normal execution.
>>>
>>> The only place where used inaccurate 'comp_level' is
>>> 'NonTieredCompPolicy::initial_compile_level', and I think it would be
>>> better if it returns correct level.
>>>
>>> Best regards,
>>> Igor Ignatyev
>>>
>>> On 04/04/2013 12:23 AM, Vladimir Kozlov wrote:
>>>>  >>> I can add explicit checking for equality to 'CompLevel_any'.
>>>>  > should i add this check?
>>>>
>>>> I don't think it is needed. May be comment.
>>>>
>>>> You convinced me about changes in CompilationPolicy::can_be_compiled().
>>>>
>>>> Now, why you need new changes in compilationPolicy.hpp? It was not in
>>>> previous webrev. Yes, it may be correct but why?
>>>>
>>>> Vladimir
>>>>
>>>> On 4/3/13 12:35 PM, Igor Ignatyev wrote:
>>>>>  >>> compileBroker.cpp - add assert() to check that.
>>>>>  >> If I add it, WB.enqueueMethodForCompilation() will trigger this
>>>>> assert,
>>>>>  >> e.g. in test 'compiler/whitebox/EnqueueMethodForCompilationTest'.
>>>>>  >
>>>>>  > Which means the test introduces the case which never happens in
>>>>> normal
>>>>>  > execution. I am not sure it is good or bad.
>>>>>  > You can relax assert with WhiteBoxAPI check. I really want this
>>>>> assert
>>>>>  > for normal execution.
>>>>> i added assert and changed
>>>>> 'NonTieredCompPolicy::initial_compile_level'
>>>>> since it return 'CompLevel_full_profile' instead of
>>>>> 'CompLevel_full_optimization' for non-tiered C2 with Xcomp. sorry, i
>>>>> missed this it due to poor preprocessor in my brain.
>>>>>
>>>>>>>> compilationPolicy.cpp - I don't think the change is correct since
>>>>>>>> is_compile(CompLevel_any) returns false.
>>>>>>> 'comp_level == CompLevel_any' is the same that 'comp_level ==
>>>>>>> CompLevel_all' and this situation is processed in
>>>>>>> compilationPolicy.cpp:124, so I think that it's correct, isn't it?
>>>>>>> I can add explicit checking for equality to 'CompLevel_any'.
>>>>> should i add this check?
>>>>>
>>>>>> You are right about CompLevel_any. What about next check in
>>>>>> m->is_not_compilable():
>>>>>>
>>>>>>    if (is_method_handle_intrinsic())
>>>>>>      return !is_synthetic();  // the generated adapters must be
>>>>>> compiled
>>>>>>
>>>>> even if CompilationPolicy::can_be_compiled() return 'true' for invalid
>>>>> comp_level, method won't be compiled since
>>>>> CompileBroker::compiler(comp_level) will be 'NULL' in
>>>>> CompileBroker::compile_method():
>>>>>
>>>>> AbstractCompiler *comp = CompileBroker::compiler(comp_level);
>>>>> if (comp == NULL || !comp->can_compile_method(method) ||
>>>>>      compilation_is_prohibited(method, osr_bci, comp_level)) {
>>>>>    return NULL;
>>>>> }
>>>>>
>>>>> updated webrev:
>>>>> http://cr.openjdk.java.net/~iignatyev/8007288/webrev.02/
>>>>>
>>>>> Best regards,
>>>>> Igor Ignatyev
>>>>>
>>>>> On 04/02/2013 11:19 PM, Vladimir Kozlov wrote:
>>>>>> On 4/2/13 1:49 AM, Igor Ignatyev wrote:
>>>>>>>  > compileBroker.cpp - add assert() to check that.
>>>>>>> If I add it, WB.enqueueMethodForCompilation() will trigger this
>>>>>>> assert,
>>>>>>> e.g. in test 'compiler/whitebox/EnqueueMethodForCompilationTest'.
>>>>>>
>>>>>> Which means the test introduces the case which never happens in
>>>>>> normal
>>>>>> execution. I am not sure it is good or bad.
>>>>>> You can relax assert with WhiteBoxAPI check. I really want this
>>>>>> assert
>>>>>> for normal execution.
>>>>>>
>>>>>>>
>>>>>>>  > compilationPolicy.cpp - I don't think the change is correct since
>>>>>>>  > is_compile(CompLevel_any) returns false.
>>>>>>> 'comp_level == CompLevel_any' is the same that 'comp_level ==
>>>>>>> CompLevel_all' and this situation is processed in
>>>>>>> compilationPolicy.cpp:124, so I think that it's correct, isn't it?
>>>>>>> I can add explicit checking for equality to 'CompLevel_any'.
>>>>>>
>>>>>> You are right about CompLevel_any. What about next check in
>>>>>> m->is_not_compilable():
>>>>>>
>>>>>>    if (is_method_handle_intrinsic())
>>>>>>      return !is_synthetic();  // the generated adapters must be
>>>>>> compiled
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>>>
>>>>>>>> Could you rename setForceInlineMethod() to
>>>>>>>> testSetForceInlineMethod() to
>>>>>>>> be more clear what it does?
>>>>>>> I will rename setForceInlineMethod() and setDontInlineMethod().
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Igor Ignatyev
>>>>>>>
>>>>>>> On 04/01/2013 09:30 PM, Vladimir Kozlov wrote:
>>>>>>>> compileBroker.cpp - add assert() to check that.
>>>>>>>>
>>>>>>>> compilationPolicy.cpp - I don't think the change is correct since
>>>>>>>> is_compile(CompLevel_any) returns false.
>>>>>>>>
>>>>>>>> Could you rename setForceInlineMethod() to
>>>>>>>> testSetForceInlineMethod() to
>>>>>>>> be more clear what it does?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Vladimir
>>>>>>>>
>>>>>>>> On 4/1/13 7:15 AM, Igor Ignatyev wrote:
>>>>>>>>> test 'compiler/whitebox/EnqueueMethodForCompilationTest' has
>>>>>>>>> failed
>>>>>>>>> during testing, because 'CompilationPolicy::can_be_compiled()'
>>>>>>>>> returns
>>>>>>>>> 'true' for invalid comp_level (less that -1 or great that 4).
>>>>>>>>>
>>>>>>>>> i added method 'is_compile' to check whether a value is valid
>>>>>>>>> level of
>>>>>>>>> compilation and rerun jprt.
>>>>>>>>>
>>>>>>>>> in new results:
>>>>>>>>>    - compiler/whitebox/IsMethodCompilableTest failed on on
>>>>>>>>> *-i586-*-c1
>>>>>>>>> due to JDK-8007270
>>>>>>>>>    - timeouts in other compiler's tests:
>>>>>>>>>      * compiler/6663848/Tester
>>>>>>>>>      * compiler/6711100/Test
>>>>>>>>>      * compiler/6792161/Test6792161
>>>>>>>>>      * compiler/6863420/Test
>>>>>>>>>      * compiler/6863420/Test
>>>>>>>>>      * compiler/6901572/Test
>>>>>>>>>      * compiler/7100757/Test7100757
>>>>>>>>>      * compiler/7119644/TestFloatVect
>>>>>>>>>      * compiler/7196199/Test7196199
>>>>>>>>>      * compiler/7199742/Test7199742
>>>>>>>>>
>>>>>>>>> updated webrev:
>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/8007288/webrev.01/
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Igor Ignatyev
>>>>>>>>>
>>>>>>>>> On 03/29/2013 01:52 AM, David Chase wrote:
>>>>>>>>>> (Not a reviewer)
>>>>>>>>>>
>>>>>>>>>> Could you run these tests on the "east" JPRT queue and see if
>>>>>>>>>> they
>>>>>>>>>> have any problems there?
>>>>>>>>>> We seem to have some surprisingly slow machines there, and that
>>>>>>>>>> has
>>>>>>>>>> caused problems with other tests.
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2013-03-28, at 5:41 PM, Igor Ignatyev
>>>>>>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> Please review the patch.
>>>>>>>>>>>
>>>>>>>>>>> 1. added new functions to WhiteBox:
>>>>>>>>>>>   public native boolean setForceInlineMethod(Method method,
>>>>>>>>>>> boolean
>>>>>>>>>>> value);
>>>>>>>>>>>   public native boolean enqueueMethodForCompilation(Method
>>>>>>>>>>> method,
>>>>>>>>>>> int compLevel);
>>>>>>>>>>>   public native void    clearMethodState(Method method);
>>>>>>>>>>> 2. related changes in not whitebox code:
>>>>>>>>>>>   - added 'Method::clear_not_*_compilable()' and corresponded
>>>>>>>>>>> 'AccessFlags::clear_not_*_compilable()'
>>>>>>>>>>>   - added 'MethodData::init()' - reset method data into original
>>>>>>>>>>> state. reset all counters, flags
>>>>>>>>>>> 3. removed useless code:
>>>>>>>>>>>   - 'if (!TieredCompilation) { comp_level =
>>>>>>>>>>> CompLevel_highest_tier;
>>>>>>>>>>> }' in CompileBroker::compile_method() -- there is no method
>>>>>>>>>>> calls w/
>>>>>>>>>>> comp_level != CompLevel_highest_tier in non-tiered
>>>>>>>>>>>   - 'MethodData::initialize(methodHandle method)' -- declaration
>>>>>>>>>>> w/o
>>>>>>>>>>> definition
>>>>>>>>>>> 4. added tests for new WB functions
>>>>>>>>>>>
>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.00/
>>>>>>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8007288
>>>>>>>>>>> --
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Igor Ignatyev
>>>>>>>>>>

From alejandro.murillo at oracle.com  Fri Apr  5 03:25:08 2013
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 05 Apr 2013 10:25:08 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 28 new changesets
Message-ID: <20130405102605.1156E480C9@hg.openjdk.java.net>

Changeset: ac242ddfa319
Author:    katleman
Date:      2013-04-04 19:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ac242ddfa319

Added tag jdk8-b84 for changeset af788b85010e

! .hgtags

Changeset: 0c3ee6f1fa23
Author:    coleenp
Date:      2013-03-27 08:19 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0c3ee6f1fa23

8009531: Crash when redefining class with annotated method
Summary: Neglected to copy the annotations in clone_with_new_data when they were moved to ConstMethod.
Reviewed-by: acorn, sspitsyn, dcubed

! src/share/vm/oops/constMethod.cpp
! src/share/vm/oops/constMethod.hpp
! src/share/vm/oops/method.cpp

Changeset: aa758f0c5b1c
Author:    hseigel
Date:      2013-03-27 11:41 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/aa758f0c5b1c

8010833: Test7116786.java is failing on most configs after fix for 8010667
Summary: Update test to recognize that non-zero pad bytes for lookupswitch/tablewsitch opcodes are now valid.
Reviewed-by: dcubed, twisti, kvn, coleenp, dholmes

! test/runtime/7116786/Test7116786.java

Changeset: b601102d00c8
Author:    hseigel
Date:      2013-03-27 13:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b601102d00c8

Merge


Changeset: cd3089a56438
Author:    acorn
Date:      2013-03-27 14:10 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cd3089a56438

8009731: Confusing error message for loader constraint violation
Summary: Fix text, overwritten type and holder for resolved method
Reviewed-by: coleenp, dcubed, minqi, dholmes

! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/oops/klassVtable.cpp

Changeset: 53f4040e809c
Author:    acorn
Date:      2013-03-27 16:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/53f4040e809c

Merge


Changeset: b5bae74160b7
Author:    zgu
Date:      2013-03-27 15:41 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b5bae74160b7

8010474: [parfait] Undefined return value of the functions in hotspot/src/share/vm/services/memTracker.hpp
Summary: Fixed functions that miss return values
Reviewed-by: coleenp, acorn, kvn

! src/share/vm/services/memTracker.hpp

Changeset: 26e0c03da92c
Author:    zgu
Date:      2013-03-27 13:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/26e0c03da92c

Merge

- make/windows/projectfiles/kernel/Makefile
- make/windows/projectfiles/kernel/vm.def
- make/windows/projectfiles/kernel/vm.dsw

Changeset: f044c45bee68
Author:    zgu
Date:      2013-03-27 22:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f044c45bee68

Merge


Changeset: 1b90c7607451
Author:    minqi
Date:      2013-03-27 17:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1b90c7607451

2178143: JVM crashes if the number of bound CPUs changed during runtime
Summary: Supply a new flag -XX:+AssumeMP to workaround the problem. With the flag is turned on, assume VM run on MP platform so is_MP() will return true that sync calls will not skip away.
Reviewed-by: dholmes, acorn, dcubed, jmasa
Contributed-by: yumin.qi at oracle.com

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/os.hpp

Changeset: d7adf726b18a
Author:    minqi
Date:      2013-03-28 00:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d7adf726b18a

Merge


Changeset: c0f9217203b2
Author:    dcubed
Date:      2013-03-29 08:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c0f9217203b2

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: d886ac1dfd36
Author:    coleenp
Date:      2013-03-31 21:43 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d886ac1dfd36

8010723: fatal error: acquiring lock Metaspace allocation lock/5 out of order
Summary: Avoid holding SystemDictionary_lock while calling Klass::remove_unshareable_info
Reviewed-by: coleenp, acorn
Contributed-by: ioi.lam at oracle.com

! src/share/vm/classfile/systemDictionary.cpp

Changeset: e458120c6e1a
Author:    sla
Date:      2013-03-28 15:39 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e458120c6e1a

8002118: WindbgDebuggerLocal should not try to load 64-bit debug libraries for 32-bit JVM
Reviewed-by: sspitsyn, zgu
Contributed-by: peter.allwin at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java

Changeset: ede380e13960
Author:    mgerdin
Date:      2013-04-02 11:28 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ede380e13960

8009763: Add WB test for String.intern()
Summary: Add convenience method in StringTable, add WhiteBox method and simple sanity test
Reviewed-by: mgerdin, zgu
Contributed-by: leonid.mesnik at oracle.com

! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/prims/whitebox.cpp
+ test/runtime/interned/SanityTest.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 8c03fc47511d
Author:    iklam
Date:      2013-04-01 14:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8c03fc47511d

8011048: Possible reading from unmapped memory in UTF8::as_quoted_ascii()
Summary: Pass utf_length parameter to UTF8::as_quoted_ascii()
Reviewed-by: dcubed, minqi

! src/share/vm/oops/symbol.cpp
! src/share/vm/utilities/utf8.cpp
! src/share/vm/utilities/utf8.hpp

Changeset: a4e8dac9db8c
Author:    zgu
Date:      2013-04-02 07:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a4e8dac9db8c

Merge


Changeset: 2e093b564241
Author:    mgerdin
Date:      2013-03-28 10:27 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2e093b564241

7014552: gc/lock/jni/jnilockXXX works too slow on 1-processor machine
Summary: Keep a counter of how many times we were stalled by the GC locker, add a diagnostic flag which sets the limit.
Reviewed-by: brutisso, ehelin, johnc

! 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/parallelScavenge/parallelScavengeHeap.cpp
! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 754c24457b20
Author:    tschatzl
Date:      2013-03-27 19:21 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/754c24457b20

7112912: Message "Error occurred during initialization of VM" on boxes with lots of RAM
Summary: Ergonomics now also takes available virtual memory into account when deciding for a heap size. The helper method to determine the maximum allocatable memory block now uses the appropriate OS specific calls to retrieve available virtual memory for the java process. In 32 bit environments this method now also searches for the maximum actually reservable amount of memory. Merge previously separate implementations for Linux/BSD/Solaris into a single method.
Reviewed-by: jmasa, tamao

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/posix/vm/os_posix.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/os.hpp

Changeset: 24ef5fb05e0f
Author:    johnc
Date:      2013-03-29 13:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/24ef5fb05e0f

8010463: G1: Crashes with -UseTLAB and heap verification
Summary: Some parts of the G1 heap can only be walked during a safepoint. Skip verifying these parts of the heap when verifying during JVM startup.
Reviewed-by: brutisso, tschatzl

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/runtime/init.cpp
! src/share/vm/runtime/thread.cpp
+ test/gc/TestVerifyBeforeGCDuringStartup.java

Changeset: 8bf6338972ce
Author:    ehelin
Date:      2013-03-23 09:16 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8bf6338972ce

8009408: gc/metaspace/ClassMetaspaceSizeInJmapHeap.java fails with "exit code 1"
Reviewed-by: brutisso, sla, ctornqvi

! test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java
+ test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java

Changeset: cc5b5976d72c
Author:    tschatzl
Date:      2013-04-02 10:03 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cc5b5976d72c

8005857: assert in GC_locker from PSOldGen::expand with -XX:+PrintGCDetails and Verbose
Summary: Use GC_locker::is_active_and_needs_gc() instead of GC_locker::is_active() for providing information about the reason of heap expansion.
Reviewed-by: jmasa, johnc

! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp

Changeset: 15c04fe93c18
Author:    mgerdin
Date:      2013-04-03 09:19 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/15c04fe93c18

Merge

- make/windows/projectfiles/kernel/Makefile
- make/windows/projectfiles/kernel/vm.def
- make/windows/projectfiles/kernel/vm.dsw
! src/os/linux/vm/os_linux.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
- test/runtime/8007736/TestStaticIF.java

Changeset: 0c039865ef2b
Author:    mgerdin
Date:      2013-04-04 19:07 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0c039865ef2b

Merge

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/os.hpp

Changeset: 0ca3dd0ffaba
Author:    bharadwaj
Date:      2013-04-04 17:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0ca3dd0ffaba

Merge

- make/bsd/build.sh
- make/linux/build.sh
- make/solaris/build.sh
! src/os/windows/vm/os_windows.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/runtime/globals.hpp

Changeset: a947f40fb536
Author:    amurillo
Date:      2013-04-04 21:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a947f40fb536

Merge

- make/bsd/build.sh
- make/linux/build.sh
- make/solaris/build.sh

Changeset: 42fe530cd478
Author:    amurillo
Date:      2013-04-04 21:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/42fe530cd478

Added tag hs25-b26 for changeset a947f40fb536

! .hgtags

Changeset: dcdeb150988c
Author:    amurillo
Date:      2013-04-04 21:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dcdeb150988c

8011584: new hotspot build - hs25-b27
Reviewed-by: jcoomes

! make/hotspot_version


From david.r.chase at oracle.com  Fri Apr  5 11:08:41 2013
From: david.r.chase at oracle.com (David Chase)
Date: Fri, 5 Apr 2013 14:08:41 -0400
Subject: RFR (M): 6443505: Ideal() function for CmpLTMask
In-Reply-To: <4E5D18DB-C9A6-4DAB-ADB4-E6890E4B4DD1@oracle.com>
References: <32C62903-0EB1-4668-B66F-B94ED433AC30@oracle.com>
	<5154D446.5050708@oracle.com>
	<4E5D18DB-C9A6-4DAB-ADB4-E6890E4B4DD1@oracle.com>
Message-ID: <2DE0B851-3A39-4027-9DFC-A19BF3C075C0@oracle.com>

http://cr.openjdk.java.net/~drchase/6443505/webrev.01/

Suggestions incorporated, revised and whacked on the sparc and-cmpltmask pattern until it was (1) observed to fire and (2) did not interfere with add-and-cmpltmask.

I kept the branch-free variants in comments of x86, since these were also tested and seen to work.

Revised code seen to work correctly on Sparc and x86, and also passed JPRT targeted to the new unit test.


On 2013-04-01, at 2:01 PM, Christian Thalinger  wrote:

> 
> On Mar 28, 2013, at 4:37 PM, Vladimir Kozlov  wrote:
> 
>> "pipeline" info is not used in code generation, it is outdated anyway. So use what other similar instructions use.
>> 
>> I think we should use only branch variant on all x86 (32 and 64bit). We save register (tmp) and it is MUCH MUCH more important for performance (less spills on stack). And you need only 3 instructions for cadd_cmpLTMask.
> 
> I agree on this one.  -- Chris
> 
>> 
>> And, please, remove unneeded spaces near parenthesis, at least in new code.
>> 
>> Thanks,
>> Vladimir
>> 
>> On 3/27/13 6:09 PM, David Chase wrote:
>>> Problem:
>>> (as stated)
>>> C2 needs a special case like CmpLTMask (turn result of a comparison into a -1/0 mask) for the comparison of a difference with zero.
>>> 
>>> (as actually observed)
>>> 1) The improvement in that case is minimal and (very) difficult to get to trigger, because CSE interferes and extracts the p-q from the pattern.
>>> 2) The original code generation for caddCmpLTMask on some platforms was actually wrong (used carry bit for a signed comparison)
>>> 3) The original Ideal pattern matching, because of a typo/thinko, accidentally failed to apply in the symmetric case
>>> 4) Code generation for CmpLTMask on all platforms omitted the somewhat relevant case of and-CmpLTMask; if the very specific pattern failed to apply, then it would fall back to the laborious calculation of an actual mask, when much more compact code could apply.
>>> 
>>> Fix:
>>> Repair wrong code generation.
>>> Write additional pattern for (and (cmpltmask p q) y)
>>> Fixed the typo so the pattern fires more often.
>>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~drchase/6443505/webrev.00/
>>> 
>>> Testing:
>>> Wrote a new test to definitely exercise the two patterns in question.
>>> Verified that "new test" would fail running with unfixed compiler.
>>> 
>>> Verified (observing assembly output) that the new patterns matched on x86_32-cmov, x86_32+cmov, x86_64, and Sparc
>>> (except that I could not get the and-cmpltmask pattern to fire on Sparc.
>>> Bit of a shame we lack a cumulative coverage tool wired into jtreg so we could easily know if it ever fired at all).
>>> 
>>> Benchmarked change on x86_64 (saw little or no performance difference on the whole benchmark)
>>> 
>>> JPRT on compiler tests (clean runs thwarted by irrelevant failures, but it was always the same 2 or 3 borked tests.)
>>> 
>>> JPRT on just the new test (clean run)
>>> 
>>> Questions:
>>> not 100% sure on the pattern costs.
>>> not 100% sure on the choice of "pipeline".
>>> 
> 


From igor.ignatyev at oracle.com  Fri Apr  5 12:50:22 2013
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 05 Apr 2013 23:50:22 +0400
Subject: RFR(M): 8007288: Additional WB API for compiler's testing
In-Reply-To: <515E22FD.7020302@oracle.com>
References: <5154B8F1.2030108@oracle.com>
	<0549160A-DBFE-42A8-9AAE-AC98CB066D09@oracle.com>
	<51599671.4090501@oracle.com> <5159C42E.7000208@oracle.com>
	<515A9B8A.6040503@oracle.com> <515B2F49.7050305@oracle.com>
	<515C8469.40901@oracle.com> <515C8FC2.2010900@oracle.com>
	<515D206F.7060307@oracle.com> <515DB4BB.8040209@oracle.com>
	<515E22FD.7020302@oracle.com>
Message-ID: <515F2AFE.9040402@oracle.com>

Vladimir,

Just want to check that I understand correctly: you're ok with pushing 
webrev.02[*], aren't you?

[*] http://cr.openjdk.java.net/~iignatyev/8007288/webrev.02/

Best regards,
Igor Ignatyev

On 04/05/2013 05:03 AM, Vladimir Kozlov wrote:
> Don't change ciReplay.cpp now. File a new bug on hotspot/compiler
> because compilation level should be recorded by
> ciEnv::dump_replay_data() and used during replay.
>
> It does not affect WB testing because it is only used during replay
> compilation.
>
>  > The only place where used inaccurate 'comp_level' is
>  > 'NonTieredCompPolicy::initial_compile_level', and I think it would be
>  > better if it returns correct level.
>
> So the problem is next #if which is always true for Server VM now:
>
> #if defined(TIERED)
> CompLevel_initial_compile   = CompLevel_full_profile
>
> but NonTieredCompPolicy is selected (CompilationPolicyChoice==0) based
> on TieredCompilation flag.
>
> Okay, you fix for NonTieredCompPolicy::initial_compile_level is correct.
>
> Thanks,
> Vladimir
>
> On 4/4/13 10:13 AM, Igor Ignatyev wrote:
>> I also found another place with inaccurate comp_level in
>> 'ciReplay.cpp::process_compile()', there always uses
>> 'CompLevel_full_optimization'.
>>
>> webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.03/
>>
>> Best regards,
>> Igor Ignatyev
>>
>> On 04/04/2013 10:40 AM, Igor Ignatyev wrote:
>>>>> Now, why you need new changes in compilationPolicy.hpp? It was not in
>>>>> previous webrev. Yes, it may be correct but why?
>>>
>>> After I had look-see 'globalDefinitions' I mistakenly decided that
>>> 'CompLevel_initial_compile' always is 'CompLevel_full_optimization' for
>>> C2. So I said that 'comp_level' always equals 'CompLevel_highest_tier'
>>> in 'CompileBroker::compile_method' for non-tiered, but it isn't true,
>>> because 'NonTieredCompPolicy::initial_compile_level' returns
>>> 'CompLevel_full_profile' when 'TIERED' is defined.
>>>
>>> On the one hand I want to be able to use any 'comp_level' in
>>> 'CompileBroker::compile_method' from WhiteBoxAPI, so I need to remove
>>> 'if (!TieredCompilation) { comp_level = CompLevel_highest_tier; }'. On
>>> the other hand,  we must use only 'CompLevel_highest_tier' for
>>> non-tiered in normal execution.
>>>
>>> The only place where used inaccurate 'comp_level' is
>>> 'NonTieredCompPolicy::initial_compile_level', and I think it would be
>>> better if it returns correct level.
>>>
>>> Best regards,
>>> Igor Ignatyev
>>>
>>> On 04/04/2013 12:23 AM, Vladimir Kozlov wrote:
>>>>  >>> I can add explicit checking for equality to 'CompLevel_any'.
>>>>  > should i add this check?
>>>>
>>>> I don't think it is needed. May be comment.
>>>>
>>>> You convinced me about changes in CompilationPolicy::can_be_compiled().
>>>>
>>>> Now, why you need new changes in compilationPolicy.hpp? It was not in
>>>> previous webrev. Yes, it may be correct but why?
>>>>
>>>> Vladimir
>>>>
>>>> On 4/3/13 12:35 PM, Igor Ignatyev wrote:
>>>>>  >>> compileBroker.cpp - add assert() to check that.
>>>>>  >> If I add it, WB.enqueueMethodForCompilation() will trigger this
>>>>> assert,
>>>>>  >> e.g. in test 'compiler/whitebox/EnqueueMethodForCompilationTest'.
>>>>>  >
>>>>>  > Which means the test introduces the case which never happens in
>>>>> normal
>>>>>  > execution. I am not sure it is good or bad.
>>>>>  > You can relax assert with WhiteBoxAPI check. I really want this
>>>>> assert
>>>>>  > for normal execution.
>>>>> i added assert and changed
>>>>> 'NonTieredCompPolicy::initial_compile_level'
>>>>> since it return 'CompLevel_full_profile' instead of
>>>>> 'CompLevel_full_optimization' for non-tiered C2 with Xcomp. sorry, i
>>>>> missed this it due to poor preprocessor in my brain.
>>>>>
>>>>>>>> compilationPolicy.cpp - I don't think the change is correct since
>>>>>>>> is_compile(CompLevel_any) returns false.
>>>>>>> 'comp_level == CompLevel_any' is the same that 'comp_level ==
>>>>>>> CompLevel_all' and this situation is processed in
>>>>>>> compilationPolicy.cpp:124, so I think that it's correct, isn't it?
>>>>>>> I can add explicit checking for equality to 'CompLevel_any'.
>>>>> should i add this check?
>>>>>
>>>>>> You are right about CompLevel_any. What about next check in
>>>>>> m->is_not_compilable():
>>>>>>
>>>>>>    if (is_method_handle_intrinsic())
>>>>>>      return !is_synthetic();  // the generated adapters must be
>>>>>> compiled
>>>>>>
>>>>> even if CompilationPolicy::can_be_compiled() return 'true' for invalid
>>>>> comp_level, method won't be compiled since
>>>>> CompileBroker::compiler(comp_level) will be 'NULL' in
>>>>> CompileBroker::compile_method():
>>>>>
>>>>> AbstractCompiler *comp = CompileBroker::compiler(comp_level);
>>>>> if (comp == NULL || !comp->can_compile_method(method) ||
>>>>>      compilation_is_prohibited(method, osr_bci, comp_level)) {
>>>>>    return NULL;
>>>>> }
>>>>>
>>>>> updated webrev:
>>>>> http://cr.openjdk.java.net/~iignatyev/8007288/webrev.02/
>>>>>
>>>>> Best regards,
>>>>> Igor Ignatyev
>>>>>
>>>>> On 04/02/2013 11:19 PM, Vladimir Kozlov wrote:
>>>>>> On 4/2/13 1:49 AM, Igor Ignatyev wrote:
>>>>>>>  > compileBroker.cpp - add assert() to check that.
>>>>>>> If I add it, WB.enqueueMethodForCompilation() will trigger this
>>>>>>> assert,
>>>>>>> e.g. in test 'compiler/whitebox/EnqueueMethodForCompilationTest'.
>>>>>>
>>>>>> Which means the test introduces the case which never happens in
>>>>>> normal
>>>>>> execution. I am not sure it is good or bad.
>>>>>> You can relax assert with WhiteBoxAPI check. I really want this
>>>>>> assert
>>>>>> for normal execution.
>>>>>>
>>>>>>>
>>>>>>>  > compilationPolicy.cpp - I don't think the change is correct since
>>>>>>>  > is_compile(CompLevel_any) returns false.
>>>>>>> 'comp_level == CompLevel_any' is the same that 'comp_level ==
>>>>>>> CompLevel_all' and this situation is processed in
>>>>>>> compilationPolicy.cpp:124, so I think that it's correct, isn't it?
>>>>>>> I can add explicit checking for equality to 'CompLevel_any'.
>>>>>>
>>>>>> You are right about CompLevel_any. What about next check in
>>>>>> m->is_not_compilable():
>>>>>>
>>>>>>    if (is_method_handle_intrinsic())
>>>>>>      return !is_synthetic();  // the generated adapters must be
>>>>>> compiled
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>>>
>>>>>>>> Could you rename setForceInlineMethod() to
>>>>>>>> testSetForceInlineMethod() to
>>>>>>>> be more clear what it does?
>>>>>>> I will rename setForceInlineMethod() and setDontInlineMethod().
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Igor Ignatyev
>>>>>>>
>>>>>>> On 04/01/2013 09:30 PM, Vladimir Kozlov wrote:
>>>>>>>> compileBroker.cpp - add assert() to check that.
>>>>>>>>
>>>>>>>> compilationPolicy.cpp - I don't think the change is correct since
>>>>>>>> is_compile(CompLevel_any) returns false.
>>>>>>>>
>>>>>>>> Could you rename setForceInlineMethod() to
>>>>>>>> testSetForceInlineMethod() to
>>>>>>>> be more clear what it does?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Vladimir
>>>>>>>>
>>>>>>>> On 4/1/13 7:15 AM, Igor Ignatyev wrote:
>>>>>>>>> test 'compiler/whitebox/EnqueueMethodForCompilationTest' has
>>>>>>>>> failed
>>>>>>>>> during testing, because 'CompilationPolicy::can_be_compiled()'
>>>>>>>>> returns
>>>>>>>>> 'true' for invalid comp_level (less that -1 or great that 4).
>>>>>>>>>
>>>>>>>>> i added method 'is_compile' to check whether a value is valid
>>>>>>>>> level of
>>>>>>>>> compilation and rerun jprt.
>>>>>>>>>
>>>>>>>>> in new results:
>>>>>>>>>    - compiler/whitebox/IsMethodCompilableTest failed on on
>>>>>>>>> *-i586-*-c1
>>>>>>>>> due to JDK-8007270
>>>>>>>>>    - timeouts in other compiler's tests:
>>>>>>>>>      * compiler/6663848/Tester
>>>>>>>>>      * compiler/6711100/Test
>>>>>>>>>      * compiler/6792161/Test6792161
>>>>>>>>>      * compiler/6863420/Test
>>>>>>>>>      * compiler/6863420/Test
>>>>>>>>>      * compiler/6901572/Test
>>>>>>>>>      * compiler/7100757/Test7100757
>>>>>>>>>      * compiler/7119644/TestFloatVect
>>>>>>>>>      * compiler/7196199/Test7196199
>>>>>>>>>      * compiler/7199742/Test7199742
>>>>>>>>>
>>>>>>>>> updated webrev:
>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/8007288/webrev.01/
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Igor Ignatyev
>>>>>>>>>
>>>>>>>>> On 03/29/2013 01:52 AM, David Chase wrote:
>>>>>>>>>> (Not a reviewer)
>>>>>>>>>>
>>>>>>>>>> Could you run these tests on the "east" JPRT queue and see if
>>>>>>>>>> they
>>>>>>>>>> have any problems there?
>>>>>>>>>> We seem to have some surprisingly slow machines there, and that
>>>>>>>>>> has
>>>>>>>>>> caused problems with other tests.
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2013-03-28, at 5:41 PM, Igor Ignatyev
>>>>>>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> Please review the patch.
>>>>>>>>>>>
>>>>>>>>>>> 1. added new functions to WhiteBox:
>>>>>>>>>>>   public native boolean setForceInlineMethod(Method method,
>>>>>>>>>>> boolean
>>>>>>>>>>> value);
>>>>>>>>>>>   public native boolean enqueueMethodForCompilation(Method
>>>>>>>>>>> method,
>>>>>>>>>>> int compLevel);
>>>>>>>>>>>   public native void    clearMethodState(Method method);
>>>>>>>>>>> 2. related changes in not whitebox code:
>>>>>>>>>>>   - added 'Method::clear_not_*_compilable()' and corresponded
>>>>>>>>>>> 'AccessFlags::clear_not_*_compilable()'
>>>>>>>>>>>   - added 'MethodData::init()' - reset method data into original
>>>>>>>>>>> state. reset all counters, flags
>>>>>>>>>>> 3. removed useless code:
>>>>>>>>>>>   - 'if (!TieredCompilation) { comp_level =
>>>>>>>>>>> CompLevel_highest_tier;
>>>>>>>>>>> }' in CompileBroker::compile_method() -- there is no method
>>>>>>>>>>> calls w/
>>>>>>>>>>> comp_level != CompLevel_highest_tier in non-tiered
>>>>>>>>>>>   - 'MethodData::initialize(methodHandle method)' -- declaration
>>>>>>>>>>> w/o
>>>>>>>>>>> definition
>>>>>>>>>>> 4. added tests for new WB functions
>>>>>>>>>>>
>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.00/
>>>>>>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8007288
>>>>>>>>>>> --
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Igor Ignatyev
>>>>>>>>>>

From vladimir.kozlov at oracle.com  Fri Apr  5 13:30:23 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 05 Apr 2013 13:30:23 -0700
Subject: RFR(M): 8007288: Additional WB API for compiler's testing
In-Reply-To: <515F2AFE.9040402@oracle.com>
References: <5154B8F1.2030108@oracle.com>
	<0549160A-DBFE-42A8-9AAE-AC98CB066D09@oracle.com>
	<51599671.4090501@oracle.com> <5159C42E.7000208@oracle.com>
	<515A9B8A.6040503@oracle.com> <515B2F49.7050305@oracle.com>
	<515C8469.40901@oracle.com> <515C8FC2.2010900@oracle.com>
	<515D206F.7060307@oracle.com> <515DB4BB.8040209@oracle.com>
	<515E22FD.7020302@oracle.com> <515F2AFE.9040402@oracle.com>
Message-ID: <515F345F.4060509@oracle.com>

Yes, I am okay with it.

Vladimir

On 4/5/13 12:50 PM, Igor Ignatyev wrote:
> Vladimir,
>
> Just want to check that I understand correctly: you're ok with pushing
> webrev.02[*], aren't you?
>
> [*] http://cr.openjdk.java.net/~iignatyev/8007288/webrev.02/
>
> Best regards,
> Igor Ignatyev
>
> On 04/05/2013 05:03 AM, Vladimir Kozlov wrote:
>> Don't change ciReplay.cpp now. File a new bug on hotspot/compiler
>> because compilation level should be recorded by
>> ciEnv::dump_replay_data() and used during replay.
>>
>> It does not affect WB testing because it is only used during replay
>> compilation.
>>
>>  > The only place where used inaccurate 'comp_level' is
>>  > 'NonTieredCompPolicy::initial_compile_level', and I think it would be
>>  > better if it returns correct level.
>>
>> So the problem is next #if which is always true for Server VM now:
>>
>> #if defined(TIERED)
>> CompLevel_initial_compile   = CompLevel_full_profile
>>
>> but NonTieredCompPolicy is selected (CompilationPolicyChoice==0) based
>> on TieredCompilation flag.
>>
>> Okay, you fix for NonTieredCompPolicy::initial_compile_level is correct.
>>
>> Thanks,
>> Vladimir
>>
>> On 4/4/13 10:13 AM, Igor Ignatyev wrote:
>>> I also found another place with inaccurate comp_level in
>>> 'ciReplay.cpp::process_compile()', there always uses
>>> 'CompLevel_full_optimization'.
>>>
>>> webrev: http://cr.openjdk.java.net/~iignatyev/8007288/webrev.03/
>>>
>>> Best regards,
>>> Igor Ignatyev
>>>
>>> On 04/04/2013 10:40 AM, Igor Ignatyev wrote:
>>>>>> Now, why you need new changes in compilationPolicy.hpp? It was not in
>>>>>> previous webrev. Yes, it may be correct but why?
>>>>
>>>> After I had look-see 'globalDefinitions' I mistakenly decided that
>>>> 'CompLevel_initial_compile' always is 'CompLevel_full_optimization' for
>>>> C2. So I said that 'comp_level' always equals 'CompLevel_highest_tier'
>>>> in 'CompileBroker::compile_method' for non-tiered, but it isn't true,
>>>> because 'NonTieredCompPolicy::initial_compile_level' returns
>>>> 'CompLevel_full_profile' when 'TIERED' is defined.
>>>>
>>>> On the one hand I want to be able to use any 'comp_level' in
>>>> 'CompileBroker::compile_method' from WhiteBoxAPI, so I need to remove
>>>> 'if (!TieredCompilation) { comp_level = CompLevel_highest_tier; }'. On
>>>> the other hand,  we must use only 'CompLevel_highest_tier' for
>>>> non-tiered in normal execution.
>>>>
>>>> The only place where used inaccurate 'comp_level' is
>>>> 'NonTieredCompPolicy::initial_compile_level', and I think it would be
>>>> better if it returns correct level.
>>>>
>>>> Best regards,
>>>> Igor Ignatyev
>>>>
>>>> On 04/04/2013 12:23 AM, Vladimir Kozlov wrote:
>>>>>  >>> I can add explicit checking for equality to 'CompLevel_any'.
>>>>>  > should i add this check?
>>>>>
>>>>> I don't think it is needed. May be comment.
>>>>>
>>>>> You convinced me about changes in
>>>>> CompilationPolicy::can_be_compiled().
>>>>>
>>>>> Now, why you need new changes in compilationPolicy.hpp? It was not in
>>>>> previous webrev. Yes, it may be correct but why?
>>>>>
>>>>> Vladimir
>>>>>
>>>>> On 4/3/13 12:35 PM, Igor Ignatyev wrote:
>>>>>>  >>> compileBroker.cpp - add assert() to check that.
>>>>>>  >> If I add it, WB.enqueueMethodForCompilation() will trigger this
>>>>>> assert,
>>>>>>  >> e.g. in test 'compiler/whitebox/EnqueueMethodForCompilationTest'.
>>>>>>  >
>>>>>>  > Which means the test introduces the case which never happens in
>>>>>> normal
>>>>>>  > execution. I am not sure it is good or bad.
>>>>>>  > You can relax assert with WhiteBoxAPI check. I really want this
>>>>>> assert
>>>>>>  > for normal execution.
>>>>>> i added assert and changed
>>>>>> 'NonTieredCompPolicy::initial_compile_level'
>>>>>> since it return 'CompLevel_full_profile' instead of
>>>>>> 'CompLevel_full_optimization' for non-tiered C2 with Xcomp. sorry, i
>>>>>> missed this it due to poor preprocessor in my brain.
>>>>>>
>>>>>>>>> compilationPolicy.cpp - I don't think the change is correct since
>>>>>>>>> is_compile(CompLevel_any) returns false.
>>>>>>>> 'comp_level == CompLevel_any' is the same that 'comp_level ==
>>>>>>>> CompLevel_all' and this situation is processed in
>>>>>>>> compilationPolicy.cpp:124, so I think that it's correct, isn't it?
>>>>>>>> I can add explicit checking for equality to 'CompLevel_any'.
>>>>>> should i add this check?
>>>>>>
>>>>>>> You are right about CompLevel_any. What about next check in
>>>>>>> m->is_not_compilable():
>>>>>>>
>>>>>>>    if (is_method_handle_intrinsic())
>>>>>>>      return !is_synthetic();  // the generated adapters must be
>>>>>>> compiled
>>>>>>>
>>>>>> even if CompilationPolicy::can_be_compiled() return 'true' for
>>>>>> invalid
>>>>>> comp_level, method won't be compiled since
>>>>>> CompileBroker::compiler(comp_level) will be 'NULL' in
>>>>>> CompileBroker::compile_method():
>>>>>>
>>>>>> AbstractCompiler *comp = CompileBroker::compiler(comp_level);
>>>>>> if (comp == NULL || !comp->can_compile_method(method) ||
>>>>>>      compilation_is_prohibited(method, osr_bci, comp_level)) {
>>>>>>    return NULL;
>>>>>> }
>>>>>>
>>>>>> updated webrev:
>>>>>> http://cr.openjdk.java.net/~iignatyev/8007288/webrev.02/
>>>>>>
>>>>>> Best regards,
>>>>>> Igor Ignatyev
>>>>>>
>>>>>> On 04/02/2013 11:19 PM, Vladimir Kozlov wrote:
>>>>>>> On 4/2/13 1:49 AM, Igor Ignatyev wrote:
>>>>>>>>  > compileBroker.cpp - add assert() to check that.
>>>>>>>> If I add it, WB.enqueueMethodForCompilation() will trigger this
>>>>>>>> assert,
>>>>>>>> e.g. in test 'compiler/whitebox/EnqueueMethodForCompilationTest'.
>>>>>>>
>>>>>>> Which means the test introduces the case which never happens in
>>>>>>> normal
>>>>>>> execution. I am not sure it is good or bad.
>>>>>>> You can relax assert with WhiteBoxAPI check. I really want this
>>>>>>> assert
>>>>>>> for normal execution.
>>>>>>>
>>>>>>>>
>>>>>>>>  > compilationPolicy.cpp - I don't think the change is correct
>>>>>>>> since
>>>>>>>>  > is_compile(CompLevel_any) returns false.
>>>>>>>> 'comp_level == CompLevel_any' is the same that 'comp_level ==
>>>>>>>> CompLevel_all' and this situation is processed in
>>>>>>>> compilationPolicy.cpp:124, so I think that it's correct, isn't it?
>>>>>>>> I can add explicit checking for equality to 'CompLevel_any'.
>>>>>>>
>>>>>>> You are right about CompLevel_any. What about next check in
>>>>>>> m->is_not_compilable():
>>>>>>>
>>>>>>>    if (is_method_handle_intrinsic())
>>>>>>>      return !is_synthetic();  // the generated adapters must be
>>>>>>> compiled
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>>>
>>>>>>>>> Could you rename setForceInlineMethod() to
>>>>>>>>> testSetForceInlineMethod() to
>>>>>>>>> be more clear what it does?
>>>>>>>> I will rename setForceInlineMethod() and setDontInlineMethod().
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Igor Ignatyev
>>>>>>>>
>>>>>>>> On 04/01/2013 09:30 PM, Vladimir Kozlov wrote:
>>>>>>>>> compileBroker.cpp - add assert() to check that.
>>>>>>>>>
>>>>>>>>> compilationPolicy.cpp - I don't think the change is correct since
>>>>>>>>> is_compile(CompLevel_any) returns false.
>>>>>>>>>
>>>>>>>>> Could you rename setForceInlineMethod() to
>>>>>>>>> testSetForceInlineMethod() to
>>>>>>>>> be more clear what it does?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Vladimir
>>>>>>>>>
>>>>>>>>> On 4/1/13 7:15 AM, Igor Ignatyev wrote:
>>>>>>>>>> test 'compiler/whitebox/EnqueueMethodForCompilationTest' has
>>>>>>>>>> failed
>>>>>>>>>> during testing, because 'CompilationPolicy::can_be_compiled()'
>>>>>>>>>> returns
>>>>>>>>>> 'true' for invalid comp_level (less that -1 or great that 4).
>>>>>>>>>>
>>>>>>>>>> i added method 'is_compile' to check whether a value is valid
>>>>>>>>>> level of
>>>>>>>>>> compilation and rerun jprt.
>>>>>>>>>>
>>>>>>>>>> in new results:
>>>>>>>>>>    - compiler/whitebox/IsMethodCompilableTest failed on on
>>>>>>>>>> *-i586-*-c1
>>>>>>>>>> due to JDK-8007270
>>>>>>>>>>    - timeouts in other compiler's tests:
>>>>>>>>>>      * compiler/6663848/Tester
>>>>>>>>>>      * compiler/6711100/Test
>>>>>>>>>>      * compiler/6792161/Test6792161
>>>>>>>>>>      * compiler/6863420/Test
>>>>>>>>>>      * compiler/6863420/Test
>>>>>>>>>>      * compiler/6901572/Test
>>>>>>>>>>      * compiler/7100757/Test7100757
>>>>>>>>>>      * compiler/7119644/TestFloatVect
>>>>>>>>>>      * compiler/7196199/Test7196199
>>>>>>>>>>      * compiler/7199742/Test7199742
>>>>>>>>>>
>>>>>>>>>> updated webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/8007288/webrev.01/
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Igor Ignatyev
>>>>>>>>>>
>>>>>>>>>> On 03/29/2013 01:52 AM, David Chase wrote:
>>>>>>>>>>> (Not a reviewer)
>>>>>>>>>>>
>>>>>>>>>>> Could you run these tests on the "east" JPRT queue and see if
>>>>>>>>>>> they
>>>>>>>>>>> have any problems there?
>>>>>>>>>>> We seem to have some surprisingly slow machines there, and that
>>>>>>>>>>> has
>>>>>>>>>>> caused problems with other tests.
>>>>>>>>>>>
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 2013-03-28, at 5:41 PM, Igor Ignatyev
>>>>>>>>>>> 
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> Please review the patch.
>>>>>>>>>>>>
>>>>>>>>>>>> 1. added new functions to WhiteBox:
>>>>>>>>>>>>   public native boolean setForceInlineMethod(Method method,
>>>>>>>>>>>> boolean
>>>>>>>>>>>> value);
>>>>>>>>>>>>   public native boolean enqueueMethodForCompilation(Method
>>>>>>>>>>>> method,
>>>>>>>>>>>> int compLevel);
>>>>>>>>>>>>   public native void    clearMethodState(Method method);
>>>>>>>>>>>> 2. related changes in not whitebox code:
>>>>>>>>>>>>   - added 'Method::clear_not_*_compilable()' and corresponded
>>>>>>>>>>>> 'AccessFlags::clear_not_*_compilable()'
>>>>>>>>>>>>   - added 'MethodData::init()' - reset method data into
>>>>>>>>>>>> original
>>>>>>>>>>>> state. reset all counters, flags
>>>>>>>>>>>> 3. removed useless code:
>>>>>>>>>>>>   - 'if (!TieredCompilation) { comp_level =
>>>>>>>>>>>> CompLevel_highest_tier;
>>>>>>>>>>>> }' in CompileBroker::compile_method() -- there is no method
>>>>>>>>>>>> calls w/
>>>>>>>>>>>> comp_level != CompLevel_highest_tier in non-tiered
>>>>>>>>>>>>   - 'MethodData::initialize(methodHandle method)' --
>>>>>>>>>>>> declaration
>>>>>>>>>>>> w/o
>>>>>>>>>>>> definition
>>>>>>>>>>>> 4. added tests for new WB functions
>>>>>>>>>>>>
>>>>>>>>>>>> webrev:
>>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/8007288/webrev.00/
>>>>>>>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8007288
>>>>>>>>>>>> --
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Igor Ignatyev
>>>>>>>>>>>

From iggy.veresov at gmail.com  Fri Apr  5 21:31:24 2013
From: iggy.veresov at gmail.com (Igor Veresov)
Date: Fri, 5 Apr 2013 21:31:24 -0700
Subject: RFR (XS) 8006851: When TieredCompilation is set,
	max code cache should be bumped to 256mb
In-Reply-To: <5113DC95.3020704@oracle.com>
References: <5112B256.8030803@oracle.com> <5113DC95.3020704@oracle.com>
Message-ID: 

Btw, are you guys still seeing "performance anomalies" with increased code cache?

igor 

On Feb 7, 2013, at 8:55 AM, Morris Meyer  wrote:

> Folks, 
> 
> I have changed this patch to include Azeem Jiva's and Vladimir Kozlov's concerns.  Per the workflow this has gone through JPRT. 
> 
> Thanks in advance, 
> 
>         --morris 
> 
> JBS - https://jbs.oracle.com/bugs/browse/JDK-8006851 
> WEBREV - http://cr.openjdk.java.net/~morris/8006851 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130405/35ee03d4/attachment-0001.html 

From john.r.rose at oracle.com  Sat Apr  6 14:52:05 2013
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 6 Apr 2013 14:52:05 -0700
Subject: RFR(M) : 7104565 : trim jprt build targets
In-Reply-To: <515D912B.5020203@oracle.com>
References: <7C7CBBE7-2651-4F94-820A-C68378C46AA9@oracle.com>
	<515D27BD.7010006@oracle.com>
	<333A9E51-2823-4036-839E-EEEB063AA251@oracle.com>
	<515D912B.5020203@oracle.com>
Message-ID: <1CFFD0FC-C382-4ED9-B4D0-A2CE7038174C@oracle.com>

On Apr 4, 2013, at 7:41 AM, Vladimir Kozlov  wrote:

> It was very long broken (before 1.5) and never was repaired. It was used before we had decent profiling tools. Just delete all 'profiled' related files.

I agree.  Profiled has been dead for about 9 years.  Time for it to go away!

? John

P.S.  FTR, here are some messages from the last time we tried to kill it:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-March/001446.html

The file reorder.sh was a remaining mention of the profiled build in 2009 but it is gone now.

Begin forwarded message:

From: John Rose 
Subject: Re: Pls review 6813274 (M)
Date: March 16, 2009 4:24:37 PM PDT
To: Paul Hohensee 

The Sun analyzer generates mapfiles from collector experiment records obtained from the real JVM, without special compilation.

The last non-incremental change, I think, was Fred Oliver regenerating them in 2004 for bug 5075485.  See:
 /net/jano2.sfbay/export2/hotspot/ws/main/c2_baseline/build/solaris/makefiles/SCCS/s.reorder_COMPILER1_i486

Nobody updating that work will care about prepackaged "profiled" builds if they can use the analyzer.

OTOH, I had forgotten about reorder.sh.  (5 years is a long time.)  The script is very manual and is bit-rotten.  The libmcount sources it refers to no longer exist (apparently) in either the open or closed repos.

So I still say get rid of the build directories from buildatree, but leave make/*/makefiles/profiled.make in place for reference.  The next time somebody refreshes the map files, they'll have all the information the WS can supply, and they'll need to figure out how to use today's tools to build today's mapfile.

-- John

On Mar 16, 2009, at 3:35 PM, Paul Hohensee wrote:

> I rummaged around and discovered that solaris/reorder.sh uses the profiled
> vms to generate the linker mapfiles used to reorder libjvm.so.  Can you think
> of another way to do this?  Or does it even matter anymore?
> 
> Paul
> 
> John Rose wrote:
>> On Mar 16, 2009, at 5:51 AM, Paul Hohensee wrote:
>> 
>>> Thanks for the review.  I'll remove the profiled targets.
>> 
>> I owe you one for taking that off my conscience!  -- John



Begin forwarded message:

From: Paul Hohensee 
Subject: Re: Pls review 6813274 (M)
Date: March 16, 2009 4:27:51 PM PDT
To: John Rose 

ok.  I'll leave reorder.sh in place too, with a note at the top to use the collector instead.

paul

John Rose wrote:
> 
> The Sun analyzer generates mapfiles from collector experiment records obtained from the real JVM, without special compilation. 
> 
> The last non-incremental change, I think, was Fred Oliver regenerating them in 2004 for bug 5075485.  See: 
>   /net/jano2.sfbay/export2/hotspot/ws/main/c2_baseline/build/solaris/makefiles/SCCS/s.reorder_COMPILER1_i486 
> 
> Nobody updating that work will care about prepackaged "profiled" builds if they can use the analyzer. 
> 
> OTOH, I had forgotten about reorder.sh.  (5 years is a long time.)  The script is very manual and is bit-rotten.  The libmcount sources it refers to no longer exist (apparently) in either the open or closed repos. 
> 
> So I still say get rid of the build directories from buildatree, but leave make/*/makefiles/profiled.make in place for reference.  The next time somebody refreshes the map files, they'll have all the information the WS can supply, and they'll need to figure out how to use today's tools to build today's mapfile. 
> 
> -- John 
> 
> On Mar 16, 2009, at 3:35 PM, Paul Hohensee wrote: 
> 
>> I rummaged around and discovered that solaris/reorder.sh uses the profiled 
>> vms to generate the linker mapfiles used to reorder libjvm.so.  Can you think 
>> of another way to do this?  Or does it even matter anymore? 
>> 
>> Paul 
>> 
>> John Rose wrote: 
>>> On Mar 16, 2009, at 5:51 AM, Paul Hohensee wrote: 
>>> 
>>>> Thanks for the review.  I'll remove the profiled targets. 
>>> 
>>> I owe you one for taking that off my conscience!  -- John 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130406/1578b41b/attachment.html 

From nils.eliasson at oracle.com  Mon Apr  8 02:59:22 2013
From: nils.eliasson at oracle.com (nils.eliasson at oracle.com)
Date: Mon, 08 Apr 2013 09:59:22 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 8006016: Memory leak at
	hotspot/src/share/vm/adlc/output_c.cpp
Message-ID: <20130408095934.7044148138@hg.openjdk.java.net>

Changeset: 705ef39fcaa9
Author:    neliasso
Date:      2013-04-05 11:09 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/705ef39fcaa9

8006016: Memory leak at hotspot/src/share/vm/adlc/output_c.cpp
Reviewed-by: kvn, roland
Contributed-by: niclas.adlertz at oracle.com

! src/share/vm/adlc/output_c.cpp
! src/share/vm/adlc/output_h.cpp


From niclas.adlertz at oracle.com  Mon Apr  8 03:05:00 2013
From: niclas.adlertz at oracle.com (Niclas Adlertz)
Date: Mon, 8 Apr 2013 12:05:00 +0200
Subject: RFR(M) 8011621: Keep the "live range id - node" mapping in a separate
	class
Message-ID: <941B0F67-1B66-45EF-8150-BB9F435EB9CD@oracle.com>

Hi all.

Problem:
In order to clean up the Split code (in opto/reg_split.cpp) making it easier to maintain and (hopefully) making it easier to improve (https://jbs.oracle.com/bugs/browse/JDK-7022320), it would be good to have the Split code more isolated with as few dependencies to other parts of the code as possible. 
The Split code could reside in an own module (class), just having references to classes and data it really needs. Right now it would need to have a reference to PhaseChaitin, only to access the "live range id - node" mapping. However, it does not need to know about everything in the PhaseChaitin class. This may also introduce cross reference problems since PhaseChaitin would use the Split module and the Split module would need a reference to PhaseChaitin.

Solution:
Move the "live range id - node" mapping to a separate class, instantiated by PhaseChaitin, which can then be passed to the Split module as a reference. 

Regards,
Niclas Adlertz

(Note that the webrev title is named JDK-7022320. That's just the local folder name that the code resides in. The bug is indeed 8011621)

-----------------------------------------------------------------
webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011621/webrev00/
   jbs: https://jbs.oracle.com/bugs/browse/JDK-8011621
  bugs: http://bugs.sun.com/view_bug.do?bug_id=8011621



From roland.westrelin at oracle.com  Mon Apr  8 08:32:30 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 8 Apr 2013 17:32:30 +0200
Subject: RFR(M) 8011621: Keep the "live range id - node" mapping in a
	separate class
In-Reply-To: <941B0F67-1B66-45EF-8150-BB9F435EB9CD@oracle.com>
References: <941B0F67-1B66-45EF-8150-BB9F435EB9CD@oracle.com>
Message-ID: <2518FDBA-C4D7-4C53-862A-9E626E658524@oracle.com>

Niclas,

In vmStructs.cpp, you need to add a declaration for PhaseChaitin::_lrg_map otherwise:
c2_nonstatic_field(LRGMap,             _max_lrg_id,              uint)
is useless.

Why not declare: LRGMap _lrg_map; rather than stack allocate it and set a pointer.

Can you add comments describing what LRGMap is before its declaration?

Shouldn't that:
 242   if (C->unique() > _lrg_map->_names.Size()) {
 243     _lrg_map->_names.extend(C->unique() - 1, 0);
 244   }

be moved to the LRGMap constructor?

Shouldn't you make _max_lrg_id, _uf_map and _names private and have accessors?

Otherwise it looks good.

Roland.



From christian.thalinger at oracle.com  Mon Apr  8 10:52:06 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 8 Apr 2013 10:52:06 -0700
Subject: RFR (M): 6443505: Ideal() function for CmpLTMask
In-Reply-To: <2DE0B851-3A39-4027-9DFC-A19BF3C075C0@oracle.com>
References: <32C62903-0EB1-4668-B66F-B94ED433AC30@oracle.com>
	<5154D446.5050708@oracle.com>
	<4E5D18DB-C9A6-4DAB-ADB4-E6890E4B4DD1@oracle.com>
	<2DE0B851-3A39-4027-9DFC-A19BF3C075C0@oracle.com>
Message-ID: <90169857-8AA6-4748-9201-6DB080C95E18@oracle.com>


On Apr 5, 2013, at 11:08 AM, David Chase  wrote:

> http://cr.openjdk.java.net/~drchase/6443505/webrev.01/
> 
> Suggestions incorporated, revised and whacked on the sparc and-cmpltmask pattern until it was (1) observed to fire and (2) did not interfere with add-and-cmpltmask.
> 
> I kept the branch-free variants in comments of x86, since these were also tested and seen to work.
> 
> Revised code seen to work correctly on Sparc and x86, and also passed JPRT targeted to the new unit test.

src/cpu/x86/vm/x86_32.ad:

!   format %{ "XOR    ECX,ECX\t# cadd_LTMaskA\n\t"
+   format %{ "XORL     $tmp, $tmp\t# and_cmpLTMaskA\n\t"

Sometimes you have cmpLT and sometimes not.  Always use the instruct name.

+ instruct and_cmpLTMaskB(rRegI p, rRegI q, rRegI y, eFlagsReg cr)
+ %{

Could you move the %{ to the same line to be like the existing ones (I know that 32 and 64 are different; it's annoying):

+ instruct cadd_cmpLTMaskB(rRegI p, rRegI q, rRegI y, eFlagsReg cr) %{

src/cpu/x86/vm/x86_64.ad:

+ /* Better to save a register than avoid a branch

Do we really want to keep the unused code?

-- Chris

> 
> 
> On 2013-04-01, at 2:01 PM, Christian Thalinger  wrote:
> 
>> 
>> On Mar 28, 2013, at 4:37 PM, Vladimir Kozlov  wrote:
>> 
>>> "pipeline" info is not used in code generation, it is outdated anyway. So use what other similar instructions use.
>>> 
>>> I think we should use only branch variant on all x86 (32 and 64bit). We save register (tmp) and it is MUCH MUCH more important for performance (less spills on stack). And you need only 3 instructions for cadd_cmpLTMask.
>> 
>> I agree on this one.  -- Chris
>> 
>>> 
>>> And, please, remove unneeded spaces near parenthesis, at least in new code.
>>> 
>>> Thanks,
>>> Vladimir
>>> 
>>> On 3/27/13 6:09 PM, David Chase wrote:
>>>> Problem:
>>>> (as stated)
>>>> C2 needs a special case like CmpLTMask (turn result of a comparison into a -1/0 mask) for the comparison of a difference with zero.
>>>> 
>>>> (as actually observed)
>>>> 1) The improvement in that case is minimal and (very) difficult to get to trigger, because CSE interferes and extracts the p-q from the pattern.
>>>> 2) The original code generation for caddCmpLTMask on some platforms was actually wrong (used carry bit for a signed comparison)
>>>> 3) The original Ideal pattern matching, because of a typo/thinko, accidentally failed to apply in the symmetric case
>>>> 4) Code generation for CmpLTMask on all platforms omitted the somewhat relevant case of and-CmpLTMask; if the very specific pattern failed to apply, then it would fall back to the laborious calculation of an actual mask, when much more compact code could apply.
>>>> 
>>>> Fix:
>>>> Repair wrong code generation.
>>>> Write additional pattern for (and (cmpltmask p q) y)
>>>> Fixed the typo so the pattern fires more often.
>>>> 
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~drchase/6443505/webrev.00/
>>>> 
>>>> Testing:
>>>> Wrote a new test to definitely exercise the two patterns in question.
>>>> Verified that "new test" would fail running with unfixed compiler.
>>>> 
>>>> Verified (observing assembly output) that the new patterns matched on x86_32-cmov, x86_32+cmov, x86_64, and Sparc
>>>> (except that I could not get the and-cmpltmask pattern to fire on Sparc.
>>>> Bit of a shame we lack a cumulative coverage tool wired into jtreg so we could easily know if it ever fired at all).
>>>> 
>>>> Benchmarked change on x86_64 (saw little or no performance difference on the whole benchmark)
>>>> 
>>>> JPRT on compiler tests (clean runs thwarted by irrelevant failures, but it was always the same 2 or 3 borked tests.)
>>>> 
>>>> JPRT on just the new test (clean run)
>>>> 
>>>> Questions:
>>>> not 100% sure on the pattern costs.
>>>> not 100% sure on the choice of "pipeline".
>>>> 
>> 
> 


From david.r.chase at oracle.com  Mon Apr  8 11:23:33 2013
From: david.r.chase at oracle.com (David Chase)
Date: Mon, 8 Apr 2013 14:23:33 -0400
Subject: RFR (M): 6443505: Ideal() function for CmpLTMask
In-Reply-To: <90169857-8AA6-4748-9201-6DB080C95E18@oracle.com>
References: <32C62903-0EB1-4668-B66F-B94ED433AC30@oracle.com>
	<5154D446.5050708@oracle.com>
	<4E5D18DB-C9A6-4DAB-ADB4-E6890E4B4DD1@oracle.com>
	<2DE0B851-3A39-4027-9DFC-A19BF3C075C0@oracle.com>
	<90169857-8AA6-4748-9201-6DB080C95E18@oracle.com>
Message-ID: 


On 2013-04-08, at 1:52 PM, Christian Thalinger  wrote:
> src/cpu/x86/vm/x86_32.ad:
> 
> !   format %{ "XOR    ECX,ECX\t# cadd_LTMaskA\n\t"
> +   format %{ "XORL     $tmp, $tmp\t# and_cmpLTMaskA\n\t"
> 
> Sometimes you have cmpLT and sometimes not.  Always use the instruct name.

So cmpLTMask everywhere?  And use a name that IDs the pattern, right?

> + instruct and_cmpLTMaskB(rRegI p, rRegI q, rRegI y, eFlagsReg cr)
> + %{
> 
> Could you move the %{ to the same line to be like the existing ones (I know that 32 and 64 are different; it's annoying):
> 
> + instruct cadd_cmpLTMaskB(rRegI p, rRegI q, rRegI y, eFlagsReg cr) %{


> src/cpu/x86/vm/x86_64.ad:
> 
> + /* Better to save a register than avoid a branch
> 
> Do we really want to keep the unused code?

We could lose it.  I think we need to keep a comment to document why we did it with a branch.

David


From vladimir.kozlov at oracle.com  Mon Apr  8 11:34:18 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 08 Apr 2013 11:34:18 -0700
Subject: RFR(M) 8011621: Keep the "live range id - node" mapping in a
	separate class
In-Reply-To: <941B0F67-1B66-45EF-8150-BB9F435EB9CD@oracle.com>
References: <941B0F67-1B66-45EF-8150-BB9F435EB9CD@oracle.com>
Message-ID: <51630DAA.8060906@oracle.com>

Niclas,

Thank you for doing this cleanup.

Please, test affection on RA performance. You can use CTW for this and 
fastdebug VM:

${JAVA_HOME}/bin/java -server -Xss4m -verify -XX:+CompileTheWorld 
-XX:+TimeCompiler -Xbootclasspath/p:${JAVA_HOME}/jre/lib/rt.jar

Or build optimized VM and run jvm08, for example, with -XX:+TimeCompiler.

Can you use full name LiveRangeMap instead of LRGMap?
Don't put big methods with loops into header file, we don't want to 
increase code size without need.

Explicitly declare private: and public: parts in class. Add comment what 
is class for.

I like Roland's suggestion (LRGMap _lrg_map;) because it avoids a 
reference through _lrg_map pointer (in compiled code C++ needs only one 
PhaseChaitin* pointer).

Thanks,
Vladimir

On 4/8/13 3:05 AM, Niclas Adlertz wrote:
> Hi all.
>
> Problem:
> In order to clean up the Split code (in opto/reg_split.cpp) making it easier to maintain and (hopefully) making it easier to improve (https://jbs.oracle.com/bugs/browse/JDK-7022320), it would be good to have the Split code more isolated with as few dependencies to other parts of the code as possible.
> The Split code could reside in an own module (class), just having references to classes and data it really needs. Right now it would need to have a reference to PhaseChaitin, only to access the "live range id - node" mapping. However, it does not need to know about everything in the PhaseChaitin class. This may also introduce cross reference problems since PhaseChaitin would use the Split module and the Split module would need a reference to PhaseChaitin.
>
> Solution:
> Move the "live range id - node" mapping to a separate class, instantiated by PhaseChaitin, which can then be passed to the Split module as a reference.
>
> Regards,
> Niclas Adlertz
>
> (Note that the webrev title is named JDK-7022320. That's just the local folder name that the code resides in. The bug is indeed 8011621)
>
> -----------------------------------------------------------------
> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011621/webrev00/
>     jbs: https://jbs.oracle.com/bugs/browse/JDK-8011621
>    bugs: http://bugs.sun.com/view_bug.do?bug_id=8011621
>
>

From vladimir.kozlov at oracle.com  Mon Apr  8 12:04:57 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 08 Apr 2013 12:04:57 -0700
Subject: RFR (M): 6443505: Ideal() function for CmpLTMask
In-Reply-To: <2DE0B851-3A39-4027-9DFC-A19BF3C075C0@oracle.com>
References: <32C62903-0EB1-4668-B66F-B94ED433AC30@oracle.com>
	<5154D446.5050708@oracle.com>
	<4E5D18DB-C9A6-4DAB-ADB4-E6890E4B4DD1@oracle.com>
	<2DE0B851-3A39-4027-9DFC-A19BF3C075C0@oracle.com>
Message-ID: <516314D9.1080002@oracle.com>

David,

We already have several thousands lines in .ad files so I would prefer 
to remove unused code. You can leave the comment explaining why we use 
branches instead of cmoves.

Please, remove next lines since we will have comment about that:
// always // predicate(!VM_Version::supports_cmov());

I would like to ask you to convert old LTMask instructions to use 
macroassembler as you did with new one. It is direction in which we move 
.ad files.

sparc.ad:
Why do you need to specify default cost in cmpLTMask0()?
+   ins_cost(DEFAULT_COST);

You don't need -XX:+UnlockDiagnosticVMOptions in the test command since 
you are not using diagnostic flags. CompileOnly is product flag:

src/share/vm/runtime/globals.hpp:  product(ccstrlist, CompileOnly, "",


How different LTMask code in x86_32.ad and x86_64.ad? We have third 
x86.ad file which contains instructions which are the same for 32- and 
64-bit. Note both files are use rRegI now.
As separate changes (rfe) you can look if you can move LTMask (and 
other) instructions into x86.ad. One thing I notice is flag type name 
rFlagsReg vs eFlagsReg. You need to rename it to use rFlagsReg and move 
operand rFlagsReg() into x86.ad.


Thanks,
Vladimir

On 4/5/13 11:08 AM, David Chase wrote:
> http://cr.openjdk.java.net/~drchase/6443505/webrev.01/
>
> Suggestions incorporated, revised and whacked on the sparc and-cmpltmask pattern until it was (1) observed to fire and (2) did not interfere with add-and-cmpltmask.
>
> I kept the branch-free variants in comments of x86, since these were also tested and seen to work.
>
> Revised code seen to work correctly on Sparc and x86, and also passed JPRT targeted to the new unit test.
>
>
> On 2013-04-01, at 2:01 PM, Christian Thalinger  wrote:
>
>>
>> On Mar 28, 2013, at 4:37 PM, Vladimir Kozlov  wrote:
>>
>>> "pipeline" info is not used in code generation, it is outdated anyway. So use what other similar instructions use.
>>>
>>> I think we should use only branch variant on all x86 (32 and 64bit). We save register (tmp) and it is MUCH MUCH more important for performance (less spills on stack). And you need only 3 instructions for cadd_cmpLTMask.
>>
>> I agree on this one.  -- Chris
>>
>>>
>>> And, please, remove unneeded spaces near parenthesis, at least in new code.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 3/27/13 6:09 PM, David Chase wrote:
>>>> Problem:
>>>> (as stated)
>>>> C2 needs a special case like CmpLTMask (turn result of a comparison into a -1/0 mask) for the comparison of a difference with zero.
>>>>
>>>> (as actually observed)
>>>> 1) The improvement in that case is minimal and (very) difficult to get to trigger, because CSE interferes and extracts the p-q from the pattern.
>>>> 2) The original code generation for caddCmpLTMask on some platforms was actually wrong (used carry bit for a signed comparison)
>>>> 3) The original Ideal pattern matching, because of a typo/thinko, accidentally failed to apply in the symmetric case
>>>> 4) Code generation for CmpLTMask on all platforms omitted the somewhat relevant case of and-CmpLTMask; if the very specific pattern failed to apply, then it would fall back to the laborious calculation of an actual mask, when much more compact code could apply.
>>>>
>>>> Fix:
>>>> Repair wrong code generation.
>>>> Write additional pattern for (and (cmpltmask p q) y)
>>>> Fixed the typo so the pattern fires more often.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~drchase/6443505/webrev.00/
>>>>
>>>> Testing:
>>>> Wrote a new test to definitely exercise the two patterns in question.
>>>> Verified that "new test" would fail running with unfixed compiler.
>>>>
>>>> Verified (observing assembly output) that the new patterns matched on x86_32-cmov, x86_32+cmov, x86_64, and Sparc
>>>> (except that I could not get the and-cmpltmask pattern to fire on Sparc.
>>>> Bit of a shame we lack a cumulative coverage tool wired into jtreg so we could easily know if it ever fired at all).
>>>>
>>>> Benchmarked change on x86_64 (saw little or no performance difference on the whole benchmark)
>>>>
>>>> JPRT on compiler tests (clean runs thwarted by irrelevant failures, but it was always the same 2 or 3 borked tests.)
>>>>
>>>> JPRT on just the new test (clean run)
>>>>
>>>> Questions:
>>>> not 100% sure on the pattern costs.
>>>> not 100% sure on the choice of "pipeline".
>>>>
>>
>

From igor.ignatyev at oracle.com  Mon Apr  8 12:30:50 2013
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 08 Apr 2013 23:30:50 +0400
Subject: RFR(S) : 8011675: adding compilation level to replay data
Message-ID: <51631AEA.9080702@oracle.com>

Hi all,

Please review patch.

Problem:
Replay of compilations supports c1 and tiered as well as c2, the only 
thing missing is comp_level.

Fix:
1. added comp_level into dump and usage during replay
2. minor changes in agent/doc:
   - escaped '<', '>'
   - renamed 'C2 Replay'/'C2 compiler replay' to 'Replay'/'Compiler replay'

Testing:
manually launched the replay from JDK-8010934 (assert specifically to 
c1) on jvm w/o corresponded fix. assert was triggered w/ patch and 
wasn't triggered w/o.


webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.00/
jbs: https://jbs.oracle.com/bugs/browse/JDK-8011675
-- 
Best regards,
Igor Ignatyev

From bharadwaj.yadavalli at oracle.com  Mon Apr  8 16:16:56 2013
From: bharadwaj.yadavalli at oracle.com (bharadwaj.yadavalli at oracle.com)
Date: Mon, 08 Apr 2013 23:16:56 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 8010913: compiler/6863420 often exceeds
	timeout
Message-ID: <20130408231705.232DB48157@hg.openjdk.java.net>

Changeset: f67065f02409
Author:    bharadwaj
Date:      2013-04-08 07:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f67065f02409

8010913: compiler/6863420 often exceeds timeout
Summary: add longer timeout for jtreg, add internal timeout thread to prevent spurious timeouts
Reviewed-by: twisti, kvn
Contributed-by: drchase 

! test/compiler/6863420/Test.java


From vladimir.kozlov at oracle.com  Mon Apr  8 17:19:21 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 08 Apr 2013 17:19:21 -0700
Subject: RFR(S) : 8011675: adding compilation level to replay data
In-Reply-To: <51631AEA.9080702@oracle.com>
References: <51631AEA.9080702@oracle.com>
Message-ID: <51635E89.30808@oracle.com>

Igor,

Thank you for fixing and cleaning this.

In vmStructs.cpp move _comp_level after _compile_id as in nmethod class.

Typo in ciReplay.cpp:
+      comp_level != CompLevel_highest_tier;

Actually it is useless to replay compilation at different level, it 
should exit with error. Could happened because incorrectly run without 
Tiered when the crush happened with Tiered.

In ciReplay.cpp use parenthesis around equality checks: if (. && (. == .)).

Thanks,
Vladimir

On 4/8/13 12:30 PM, Igor Ignatyev wrote:
> Hi all,
>
> Please review patch.
>
> Problem:
> Replay of compilations supports c1 and tiered as well as c2, the only
> thing missing is comp_level.
>
> Fix:
> 1. added comp_level into dump and usage during replay
> 2. minor changes in agent/doc:
>    - escaped '<', '>'
>    - renamed 'C2 Replay'/'C2 compiler replay' to 'Replay'/'Compiler replay'
>
> Testing:
> manually launched the replay from JDK-8010934 (assert specifically to
> c1) on jvm w/o corresponded fix. assert was triggered w/ patch and
> wasn't triggered w/o.
>
>
> webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.00/
> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011675

From igor.ignatyev at oracle.com  Tue Apr  9 00:04:58 2013
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 09 Apr 2013 11:04:58 +0400
Subject: RFR(S) : 8011675: adding compilation level to replay data
In-Reply-To: <51635E89.30808@oracle.com>
References: <51631AEA.9080702@oracle.com> <51635E89.30808@oracle.com>
Message-ID: <5163BD9A.5080308@oracle.com>

Vladimir,

Thank you for review.

updated webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.01/

Best regards,
Igor Ignatyev

On 04/09/2013 04:19 AM, Vladimir Kozlov wrote:
> Igor,
>
> Thank you for fixing and cleaning this.
>
> In vmStructs.cpp move _comp_level after _compile_id as in nmethod class.
>
> Typo in ciReplay.cpp:
> +      comp_level != CompLevel_highest_tier;
>
> Actually it is useless to replay compilation at different level, it
> should exit with error. Could happened because incorrectly run without
> Tiered when the crush happened with Tiered.
>
> In ciReplay.cpp use parenthesis around equality checks: if (. && (. == .)).
>
> Thanks,
> Vladimir
>
> On 4/8/13 12:30 PM, Igor Ignatyev wrote:
>> Hi all,
>>
>> Please review patch.
>>
>> Problem:
>> Replay of compilations supports c1 and tiered as well as c2, the only
>> thing missing is comp_level.
>>
>> Fix:
>> 1. added comp_level into dump and usage during replay
>> 2. minor changes in agent/doc:
>>    - escaped '<', '>'
>>    - renamed 'C2 Replay'/'C2 compiler replay' to 'Replay'/'Compiler
>> replay'
>>
>> Testing:
>> manually launched the replay from JDK-8010934 (assert specifically to
>> c1) on jvm w/o corresponded fix. assert was triggered w/ patch and
>> wasn't triggered w/o.
>>
>>
>> webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.00/
>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011675

From vladimir.kozlov at oracle.com  Tue Apr  9 00:40:36 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 09 Apr 2013 00:40:36 -0700
Subject: RFR(S) : 8011675: adding compilation level to replay data
In-Reply-To: <5163BD9A.5080308@oracle.com>
References: <51631AEA.9080702@oracle.com> <51635E89.30808@oracle.com>
	<5163BD9A.5080308@oracle.com>
Message-ID: <5163C5F4.7020605@oracle.com>

Igor,

Sorry, I may said it not clear. What I meant is to set error (call 
report_error()) in such case and return from process_compile() without 
compilation. But let ciReplay::replay() finish and exit. replay_impl() 
should print the problem so you don't need to do it in 
process_compile(). And, please, test it.
The message should be more informative, something like:
"compilation level %d requires TieredCompilation"
An other bad cases is when failure happened in Client (C1) or Server 
(C2) but the replay is run with opposite VM.

thanks,
Vladimir

On 4/9/13 12:04 AM, Igor Ignatyev wrote:
> Vladimir,
>
> Thank you for review.
>
> updated webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.01/
>
> Best regards,
> Igor Ignatyev
>
> On 04/09/2013 04:19 AM, Vladimir Kozlov wrote:
>> Igor,
>>
>> Thank you for fixing and cleaning this.
>>
>> In vmStructs.cpp move _comp_level after _compile_id as in nmethod class.
>>
>> Typo in ciReplay.cpp:
>> +      comp_level != CompLevel_highest_tier;
>>
>> Actually it is useless to replay compilation at different level, it
>> should exit with error. Could happened because incorrectly run without
>> Tiered when the crush happened with Tiered.
>>
>> In ciReplay.cpp use parenthesis around equality checks: if (. && (. ==
>> .)).
>>
>> Thanks,
>> Vladimir
>>
>> On 4/8/13 12:30 PM, Igor Ignatyev wrote:
>>> Hi all,
>>>
>>> Please review patch.
>>>
>>> Problem:
>>> Replay of compilations supports c1 and tiered as well as c2, the only
>>> thing missing is comp_level.
>>>
>>> Fix:
>>> 1. added comp_level into dump and usage during replay
>>> 2. minor changes in agent/doc:
>>>    - escaped '<', '>'
>>>    - renamed 'C2 Replay'/'C2 compiler replay' to 'Replay'/'Compiler
>>> replay'
>>>
>>> Testing:
>>> manually launched the replay from JDK-8010934 (assert specifically to
>>> c1) on jvm w/o corresponded fix. assert was triggered w/ patch and
>>> wasn't triggered w/o.
>>>
>>>
>>> webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.00/
>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011675

From roland.westrelin at oracle.com  Tue Apr  9 02:57:40 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 9 Apr 2013 11:57:40 +0200
Subject: RFR(S): 8011706: specjvm2008 test xml.transform gets array bound
	exception with c1
Message-ID: <2BC866EE-271F-4CF1-8DCC-8C11759321BB@oracle.com>

http://cr.openjdk.java.net/~roland/8011706/webrev.00/

Loop invariant code motion moves loop invariant loads (from a field or an array) to the dominator of the loop header. If the dominator is not a direct predecessor of the loop header then some stores to the same field/array may happen between the dominator and the loop header and a load may be moved before a store to the same field/array. 

Roland.

From roland.westrelin at oracle.com  Tue Apr  9 04:11:48 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 9 Apr 2013 13:11:48 +0200
Subject: RFRS(XS): 8011582 assert(nbits == 32 || (-(1 << nbits-1) <= x && x <
	( 1 << nbits-1))) failed: value out of range
Message-ID: <2EE91CDF-A3E9-4E1E-89DB-50A6C23CFF83@oracle.com>

http://cr.openjdk.java.net/~roland/8011582/webrev.00/

New predicate_failed_trap c1 stub for array bound check elimination uses:
        __ br(Assembler::always, false, Assembler::pt, deopt_blob->unpack_with_reexecution(), relocInfo::runtime_call_type);

but it should use jump_to() instead which works if the deopt stub is far from the c1 stubs.

Roland.

From roland.westrelin at oracle.com  Tue Apr  9 04:19:45 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 9 Apr 2013 13:19:45 +0200
Subject: RFR(XS): 8011648: C1: optimized build is broken after 7153771
Message-ID: <48F03646-093E-42DC-9D7D-99403532C5FD@oracle.com>

Some missing #ifdef ASSERT

http://cr.openjdk.java.net/~roland/8011648/webrev.00/

Roland.

From david.r.chase at oracle.com  Tue Apr  9 05:10:41 2013
From: david.r.chase at oracle.com (David Chase)
Date: Tue, 9 Apr 2013 08:10:41 -0400
Subject: RFR (M): 6443505: Ideal() function for CmpLTMask
In-Reply-To: <516314D9.1080002@oracle.com>
References: <32C62903-0EB1-4668-B66F-B94ED433AC30@oracle.com>
	<5154D446.5050708@oracle.com>
	<4E5D18DB-C9A6-4DAB-ADB4-E6890E4B4DD1@oracle.com>
	<2DE0B851-3A39-4027-9DFC-A19BF3C075C0@oracle.com>
	<516314D9.1080002@oracle.com>
Message-ID: 

Any reason I should not delete:

  enc_class enc_cmpLTP_mem(rRegI p, rRegI q, memory mem, eCXRegI tmp) %{    // cadd_cmpLT

It's only called from a comment:

/* If I enable this, I encourage spilling in the inner loop of compress.
instruct cadd_cmpLTMask_mem(ncxRegI p, ncxRegI q, memory y, eCXRegI tmp, eFlagsReg cr) %{

And the code that it generates is wrong.
And it uses the pre-macro-assembler.

David


On 2013-04-08, at 3:04 PM, Vladimir Kozlov  wrote:

> David,
> 
> We already have several thousands lines in .ad files so I would prefer to remove unused code. You can leave the comment explaining why we use branches instead of cmoves.
> 
> Please, remove next lines since we will have comment about that:
> // always // predicate(!VM_Version::supports_cmov());
> 
> I would like to ask you to convert old LTMask instructions to use macroassembler as you did with new one. It is direction in which we move .ad files.
> 
> sparc.ad:
> Why do you need to specify default cost in cmpLTMask0()?
> +   ins_cost(DEFAULT_COST);
> 
> You don't need -XX:+UnlockDiagnosticVMOptions in the test command since you are not using diagnostic flags. CompileOnly is product flag:
> 
> src/share/vm/runtime/globals.hpp:  product(ccstrlist, CompileOnly, "",
> 
> 
> How different LTMask code in x86_32.ad and x86_64.ad? We have third x86.ad file which contains instructions which are the same for 32- and 64-bit. Note both files are use rRegI now.
> As separate changes (rfe) you can look if you can move LTMask (and other) instructions into x86.ad. One thing I notice is flag type name rFlagsReg vs eFlagsReg. You need to rename it to use rFlagsReg and move operand rFlagsReg() into x86.ad.
> 
> 
> Thanks,
> Vladimir
> 
> On 4/5/13 11:08 AM, David Chase wrote:
>> http://cr.openjdk.java.net/~drchase/6443505/webrev.01/
>> 
>> Suggestions incorporated, revised and whacked on the sparc and-cmpltmask pattern until it was (1) observed to fire and (2) did not interfere with add-and-cmpltmask.
>> 
>> I kept the branch-free variants in comments of x86, since these were also tested and seen to work.
>> 
>> Revised code seen to work correctly on Sparc and x86, and also passed JPRT targeted to the new unit test.
>> 
>> 
>> On 2013-04-01, at 2:01 PM, Christian Thalinger  wrote:
>> 
>>> 
>>> On Mar 28, 2013, at 4:37 PM, Vladimir Kozlov  wrote:
>>> 
>>>> "pipeline" info is not used in code generation, it is outdated anyway. So use what other similar instructions use.
>>>> 
>>>> I think we should use only branch variant on all x86 (32 and 64bit). We save register (tmp) and it is MUCH MUCH more important for performance (less spills on stack). And you need only 3 instructions for cadd_cmpLTMask.
>>> 
>>> I agree on this one.  -- Chris
>>> 
>>>> 
>>>> And, please, remove unneeded spaces near parenthesis, at least in new code.
>>>> 
>>>> Thanks,
>>>> Vladimir
>>>> 
>>>> On 3/27/13 6:09 PM, David Chase wrote:
>>>>> Problem:
>>>>> (as stated)
>>>>> C2 needs a special case like CmpLTMask (turn result of a comparison into a -1/0 mask) for the comparison of a difference with zero.
>>>>> 
>>>>> (as actually observed)
>>>>> 1) The improvement in that case is minimal and (very) difficult to get to trigger, because CSE interferes and extracts the p-q from the pattern.
>>>>> 2) The original code generation for caddCmpLTMask on some platforms was actually wrong (used carry bit for a signed comparison)
>>>>> 3) The original Ideal pattern matching, because of a typo/thinko, accidentally failed to apply in the symmetric case
>>>>> 4) Code generation for CmpLTMask on all platforms omitted the somewhat relevant case of and-CmpLTMask; if the very specific pattern failed to apply, then it would fall back to the laborious calculation of an actual mask, when much more compact code could apply.
>>>>> 
>>>>> Fix:
>>>>> Repair wrong code generation.
>>>>> Write additional pattern for (and (cmpltmask p q) y)
>>>>> Fixed the typo so the pattern fires more often.
>>>>> 
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~drchase/6443505/webrev.00/
>>>>> 
>>>>> Testing:
>>>>> Wrote a new test to definitely exercise the two patterns in question.
>>>>> Verified that "new test" would fail running with unfixed compiler.
>>>>> 
>>>>> Verified (observing assembly output) that the new patterns matched on x86_32-cmov, x86_32+cmov, x86_64, and Sparc
>>>>> (except that I could not get the and-cmpltmask pattern to fire on Sparc.
>>>>> Bit of a shame we lack a cumulative coverage tool wired into jtreg so we could easily know if it ever fired at all).
>>>>> 
>>>>> Benchmarked change on x86_64 (saw little or no performance difference on the whole benchmark)
>>>>> 
>>>>> JPRT on compiler tests (clean runs thwarted by irrelevant failures, but it was always the same 2 or 3 borked tests.)
>>>>> 
>>>>> JPRT on just the new test (clean run)
>>>>> 
>>>>> Questions:
>>>>> not 100% sure on the pattern costs.
>>>>> not 100% sure on the choice of "pipeline".
>>>>> 
>>> 
>> 


From goetz.lindenmaier at sap.com  Tue Apr  9 07:35:29 2013
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 9 Apr 2013 14:35:29 +0000
Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp
	stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp
	stub.]
In-Reply-To: <03C4DFDE-CD52-446E-92AA-A6F12903FE29@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC0CFA7D32@DEWDFEMB12A.global.corp.sap>
	<03C4DFDE-CD52-446E-92AA-A6F12903FE29@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC0CFB116E@DEWDFEMB12A.global.corp.sap>

Hi Chris, 

I'm now working on this issue.  Sorry for the delay...

What do you think about moving 
    void emit_java_to_interp(CodeBuffer& cbuf);
and
   void size_java_to_interp();
to compiledIC.hpp and the new platform file, too?

This would also allow to overcome the ugly 
   extern uint size_java_to_interp();
in output.cpp, as it could be replaced by CompiledStaticCall::size_java_to_interp().

I also would like to name this
  CompiledStaticCall::emit_to_interp_stub()
  CompiledStaticCall::to_interp_stub_size()

I could also extract code from enc_class Java_Static_Call 
to form a routine
  CompiledStaticCall::emit_call(CodeBuffer *cbuf, intptr_t entry_point, relocInfo::relocType rtype) {
    emit_call_reloc(cbuf, entry_point, rtype)
    if (rtype != relocInfo::runtime_call_type) {
        emit_java_to_interp(cbuf);
      }
  }
With this, also 
  extern uint reloc_java_to_interp();
from output.cpp could be moved into this class.

Then handling of CompiledStaticCalls would be completely implemented in this
one class.

(I would have to move emit_call_reloc to MacroAssembler.)

Best regards,
  Goetz.



-----Original Message-----
From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
Sent: Montag, 25. M?rz 2013 23:29
To: Lindenmaier, Goetz
Cc: 'hotspot-compiler-dev at openjdk.java.net'
Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]


On Mar 4, 2013, at 8:34 AM, "Lindenmaier, Goetz"  wrote:

> Hi Chris, 
> 
> I would like to take up this issue again. 
> I'm about to put our changes on the jdk8 branch, and it would be convenient
> to have a final solution for this.
> 
> Should I prepare a webrev with a different solution adding a new file
> for this?  What should go into that file? 

Sorry for answering that late.

Yes, to see a patch for that would be good.  We need to put all platform dependent Compiled* methods in that new file.  Platform dependent means every method that uses a native* method from nativeInst_:

CompiledIC::cleanup_call_site
CompiledIC::is_icholder_call_site
CompiledIC::CompiledIC

CompiledStaticCall::set_to_interpreted
CompiledStaticCall::set_stub_to_clean
CompiledStaticCall::verify

-- Chris

> 
> Best regards,
>  Goetz.
> 
> 
> 
> -----Original Message-----
> From: goetz.lindenmaier at sap.com 
> Sent: Dienstag, 18. Dezember 2012 10:42
> To: 'Christian Thalinger'
> Subject: RE: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
> 
> Hi Chris, 
> 
> What would you put into that file?  The offset, or the class CompiledStaticCall?
> You could also put it into nativeInst_  to avoid adding another file.
> 
> But basically I think the offset is the best solution, because it's very small
> and straight forward, and the offset is set where the code is generated 
> that defines the offset.
> 
> Only the #ifndef COMPILER2 is ugly, but here I think the solution is to 
> guard the whole class CompiledStaticCall with #ifdef COMPILER2.
> 
> But I'm happy with any placement of the code.
> 
> Best regards,
>  Goetz.
> 
> 
> 
> -----Original Message-----
> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
> Sent: Montag, 17. Dezember 2012 21:34
> To: Lindenmaier, Goetz
> Cc: 'hotspot-compiler-dev at openjdk.java.net'
> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
> 
> 
> On Nov 29, 2012, at 2:10 PM, "Lindenmaier, Goetz"  wrote:
> 
>> Hi Chris, 
>> 
>> Loading the constant takes 5 instructions, the other way only three,
>> in the code only one, if the constant pool base is in a register.
>> The 5 instructions are hard to patch atomically.  The constant pool 
>> is just a 64 bit store.  
>> 
>>> Sorry for being so persistent on this :-)  
>> That's ok, I already found several places in our VM where it was easy to 
>> change our code to get along without the shared changes we did in 
>> first place.  But I can't redesign everything, and I can not risk to break
>> anything in our product.
>> 
>> If you feel like doing so, you can have a look at 
>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/600ce596eea9
>> which contains our bytecode interpreter profiling implementation.
>> If you think this is currently of use in the main branch, I would lift it to HS25 
>> (the permgen changes might cause trouble) and contribute it to hsx.
> 
> Sorry for the long delay.
> 
> Thinking about this problem again it seems that the correct solution would be to have a compiledIC_.cpp file.
> 
> The CompiledIC instruction layout is platform dependent; it just happens to be the same for all architectures we have right now (well, except PPC) because we made it to be the same.  Actually on SPARC we could also use a load from the constant table which would be simpler.
> 
> Having a platform dependent file for this code feels right.  What do you think?
> 
> -- Chris
> 
>> 
>> Best regards,
>> Goetz.
>> 
>> -----Original Message-----
>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>> Sent: Thursday, November 29, 2012 7:53 PM
>> To: Lindenmaier, Goetz
>> Cc: hotspot-compiler-dev at openjdk.java.net
>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>> 
>> 
>> On Nov 29, 2012, at 12:27 AM, "Lindenmaier, Goetz"  wrote:
>> 
>>> Hi Chris, 
>>> 
>>>> Why can't you point the relocation to the method load instruction?  It doesn't seem right to do that in shared code.
>>> Because the relocation is used 
>>> 1.) to find the beginning of the stub to patch the call to go there 
>>> 2.) to find the load to patch the IC.
>> 
>> Got it.
>> 
>>> 
>>> Just have a look at CompiledStaticCall::set_to_interpreted(),
>>> the variable 'stub' is used twice.  
>> 
>> Sorry for being so persistent on this :-)  What is the reason you have to load the constant from the constant table?  On other architectures we materialize the constant.
>> 
>> -- Chris
>> 
>>> 
>>> Best regards, 
>>> Goetz.
>>> 
>>> -----Original Message-----
>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>> Sent: Donnerstag, 29. November 2012 01:35
>>> To: Lindenmaier, Goetz
>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>> 
>>> 
>>> On Nov 27, 2012, at 4:24 AM, "Lindenmaier, Goetz"  wrote:
>>> 
>>>> Hi Chris,
>>>> 
>>>>> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub?
>>>> Shared code (class CompiledStaticCall) wants to patch the inline cache 
>>>> in the stub which is emitted in platform code.
>>>> So the platform code should specify how the shared code can find the inline cache 
>>>> in the stub, which it does through the constant I introduced.
>>>> 
>>>>> Do you need two relocations?  I'm confused.
>>>> No, three ;)
>>>> The relocation you mention is used to find the stub given the call.
>>>> The other relocations are needed to find the inline cache / call target
>>>> once the stub is found (see CompiledStaticCall::set_to_interpreted()).
>>>> It's just the same on x86_64:
>>>> 
>>>> // static stub relocation stores the instruction address of the call
>>>> __ relocate(static_stub_Relocation::spec(mark), RELOC_IMM64); 
>>>> // static stub relocation also tags the methodOop in the code-stream.
>>>> __ movoop(rbx, (jobject) NULL);  // method is zapped till fixup time
>>>> // This is recognized as unresolved by relocs/nativeinst/ic code
>>>> __ jump(RuntimeAddress(__ pc()));
>>>> 
>>>> On PPC, we have to load the base of the constant table after generating the 
>>>> static_stub_relocation and before emitting the ppc equivalent for moveoop(). This offset is 
>>>> exactly what we store in the  CompiledStaticCall::comp_to_int_load_offset constant.
>>> 
>>> Why can't you point the relocation to the method load instruction?  It doesn't seem right to do that in shared code.
>>> 
>>> -- Chris
>>> 
>>>> 
>>>> Best regards,
>>>> Goetz.
>>>> 
>>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>> Sent: Dienstag, 27. November 2012 01:53
>>>> To: Lindenmaier, Goetz
>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>> 
>>>> 
>>>> On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz"  wrote:
>>>> 
>>>>> Hi Chris,
>>>>> 
>>>>> We put it into the ad file because it describes an offset into the stub that is
>>>>> generated from the ad file by emit_java_to_interp(CodeBuffer& cbuf), 
>>>>> used by ir  node CallStaticJavaDirect.  Maybe I should not call it stub, but it's 
>>>>> generated into the stubs section of the code buffer.
>>>>> If that stub generator is moved out of the ad file to shared compiler code, one should
>>>>> move the field with it, but for the current implementation I think that's fine.
>>>>> 
>>>>> Does C1 generate the same stub? Or is the CompiledStaticCall a C2 feature?
>>>>> If so, one could protect the whole thing by #ifdef COMPILER2.
>>>> 
>>>> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub?
>>>> 
>>>> // Create a static stub relocation which relates this stub
>>>> // with the call instruction at insts_call_instruction_offset in the
>>>> // instructions code-section.
>>>> __ relocate(static_stub_Relocation::spec(__ code()->insts()->start() + insts_relocation_offset));
>>>> 
>>>> Do you need two relocations?  I'm confused.
>>>> 
>>>> -- Chris
>>>> 
>>>>> 
>>>>> Thanks for all the bugids!
>>>>> 
>>>>> Best regards,
>>>>> Goetz.
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>> Sent: Mittwoch, 21. November 2012 19:53
>>>>> To: Lindenmaier, Goetz
>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>> Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>> 
>>>>> 
>>>>> On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz"  wrote:
>>>>> 
>>>>>> Hi Chris, 
>>>>>> 
>>>>>> yes, there is no C1 on ppc.  
>>>>>> We do tiered compilation with a stripped C2.
>>>>> 
>>>>> Right.  But some other architecture (or in the future) might need this for C1 as well.  We should find a better place for the value than the ad file.  The obvious place would be compiledIC_.hpp but we don't have that file, yet.
>>>>> 
>>>>> I filed:
>>>>> 
>>>>> 8003853: specify offset of IC load in java_to_interp stub
>>>>> 
>>>>> -- Chris
>>>>> 
>>>>>> 
>>>>>> Best regards,
>>>>>> Goetz
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>>> Sent: Dienstag, 20. November 2012 22:19
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>> Subject: Re: RFR (S): Specify offset of IC load in java_to_interp stub.
>>>>>> 
>>>>>> 
>>>>>> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz"  wrote:
>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub
>>>>>>> to update the IC  with NativeMovConstReg.  The current implementation assumes that
>>>>>>> the load is always the first instruction in the stub.  This is an artificial restriction. E.g.,
>>>>>>> it might be useful to load the constant pool address (MachConstantBase) before the
>>>>>>> IC load (as we do on PPC).
>>>>>>> 
>>>>>>> This change adds a constant specifying an offset from the beginning of the stub to
>>>>>>> the  IC load. The offset is platform specific and 0 on sparc and x86.
>>>>>>> 
>>>>>>> You can find the change here:
>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/
>>>>>> 
>>>>>> That should be fixed indeed.  
>>>>>> 
>>>>>> +#ifndef COMPILER2
>>>>>> +const int CompiledStaticCall::comp_to_int_load_offset = 0;
>>>>>> 
>>>>>> There is no C1 for PPC (sorry, I didn't check)?
>>>>>> 
>>>>>> -- Chris
>>>>>> 
>>>>>>> 
>>>>>>> or in our ppc port:
>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33
>>>>>>> 
>>>>>>> Thank you and best regards,
>>>>>>> Goetz
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


From roland.westrelin at oracle.com  Tue Apr  9 07:50:24 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 9 Apr 2013 16:50:24 +0200
Subject: RFR (XS): 8010460: Interpreter on some platforms loads
	ConstMethod::_max_stack and misses extra stack slots for JSR 292
In-Reply-To: 
References: <6B922316-9630-4955-9A42-8FA52D5571F6@oracle.com>
	
	<4CA94106-1D2A-4DF2-814E-DF2F7A190B60@oracle.com>
	<8A8F768B-D0E2-46C1-AEC2-ED2FAA88EA09@oracle.com>
	
	
	
	
Message-ID: <5463992A-B3A0-4647-9176-90704DBE6262@oracle.com>

Here is a new webrev:

http://cr.openjdk.java.net/~roland/8010460/webrev.02/

It includes Volker's suggestions.
The cpp interpreter is broken so I couldn't even test that it compiles.

Roland.

From vladimir.kozlov at oracle.com  Tue Apr  9 08:42:10 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 09 Apr 2013 08:42:10 -0700
Subject: RFR(S): 8011706: specjvm2008 test xml.transform gets array bound
	exception with c1
In-Reply-To: <2BC866EE-271F-4CF1-8DCC-8C11759321BB@oracle.com>
References: <2BC866EE-271F-4CF1-8DCC-8C11759321BB@oracle.com>
Message-ID: <516436D2.7010101@oracle.com>

Roland,

Changes are good but could you explain how you got "dominator is not a 
direct predecessor"? In C2 only irreducible loops have several entry 
points and could have such situation. Is it the same for this case in 
C1? Just curious.

Thanks,
Vladimir

On 4/9/13 2:57 AM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8011706/webrev.00/
>
> Loop invariant code motion moves loop invariant loads (from a field or an array) to the dominator of the loop header. If the dominator is not a direct predecessor of the loop header then some stores to the same field/array may happen between the dominator and the loop header and a load may be moved before a store to the same field/array.
>
> Roland.
>

From vladimir.kozlov at oracle.com  Tue Apr  9 08:43:41 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 09 Apr 2013 08:43:41 -0700
Subject: RFRS(XS): 8011582 assert(nbits == 32 || (-(1 << nbits-1) <= x
	&& x < ( 1 << nbits-1))) failed: value out of range
In-Reply-To: <2EE91CDF-A3E9-4E1E-89DB-50A6C23CFF83@oracle.com>
References: <2EE91CDF-A3E9-4E1E-89DB-50A6C23CFF83@oracle.com>
Message-ID: <5164372D.5040400@oracle.com>

Thanks, Roland

It is good.

Vladimir

On 4/9/13 4:11 AM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8011582/webrev.00/
>
> New predicate_failed_trap c1 stub for array bound check elimination uses:
>          __ br(Assembler::always, false, Assembler::pt, deopt_blob->unpack_with_reexecution(), relocInfo::runtime_call_type);
>
> but it should use jump_to() instead which works if the deopt stub is far from the c1 stubs.
>
> Roland.
>

From vladimir.kozlov at oracle.com  Tue Apr  9 08:45:42 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 09 Apr 2013 08:45:42 -0700
Subject: RFR(XS): 8011648: C1: optimized build is broken after 7153771
In-Reply-To: <48F03646-093E-42DC-9D7D-99403532C5FD@oracle.com>
References: <48F03646-093E-42DC-9D7D-99403532C5FD@oracle.com>
Message-ID: <516437A6.2040208@oracle.com>

Good.

Thanks,
Vladimir

On 4/9/13 4:19 AM, Roland Westrelin wrote:
> Some missing #ifdef ASSERT
>
> http://cr.openjdk.java.net/~roland/8011648/webrev.00/
>
> Roland.
>

From vladimir.kozlov at oracle.com  Tue Apr  9 08:50:22 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 09 Apr 2013 08:50:22 -0700
Subject: RFR (M): 6443505: Ideal() function for CmpLTMask
In-Reply-To: 
References: <32C62903-0EB1-4668-B66F-B94ED433AC30@oracle.com>
	<5154D446.5050708@oracle.com>
	<4E5D18DB-C9A6-4DAB-ADB4-E6890E4B4DD1@oracle.com>
	<2DE0B851-3A39-4027-9DFC-A19BF3C075C0@oracle.com>
	<516314D9.1080002@oracle.com>
	
Message-ID: <516438BE.1080507@oracle.com>

Leave only first lines commented to see matching and remove the rest:

   /* If I enable this, I encourage spilling in the inner loop of compress.
   instruct cadd_cmpLTMask_mem( ncxRegI p, ncxRegI q, memory y, eCXRegI 
tmp, eFlagsReg cr ) %{
   match(Set p (AddI (AndI (CmpLTMask p q) (LoadI y)) (SubI p q)));
   */

Vladimir

On 4/9/13 5:10 AM, David Chase wrote:
> Any reason I should not delete:
>
>    enc_class enc_cmpLTP_mem(rRegI p, rRegI q, memory mem, eCXRegI tmp) %{    // cadd_cmpLT
>
> It's only called from a comment:
>
> /* If I enable this, I encourage spilling in the inner loop of compress.
> instruct cadd_cmpLTMask_mem(ncxRegI p, ncxRegI q, memory y, eCXRegI tmp, eFlagsReg cr) %{
>
> And the code that it generates is wrong.
> And it uses the pre-macro-assembler.
>
> David
>
>
> On 2013-04-08, at 3:04 PM, Vladimir Kozlov  wrote:
>
>> David,
>>
>> We already have several thousands lines in .ad files so I would prefer to remove unused code. You can leave the comment explaining why we use branches instead of cmoves.
>>
>> Please, remove next lines since we will have comment about that:
>> // always // predicate(!VM_Version::supports_cmov());
>>
>> I would like to ask you to convert old LTMask instructions to use macroassembler as you did with new one. It is direction in which we move .ad files.
>>
>> sparc.ad:
>> Why do you need to specify default cost in cmpLTMask0()?
>> +   ins_cost(DEFAULT_COST);
>>
>> You don't need -XX:+UnlockDiagnosticVMOptions in the test command since you are not using diagnostic flags. CompileOnly is product flag:
>>
>> src/share/vm/runtime/globals.hpp:  product(ccstrlist, CompileOnly, "",
>>
>>
>> How different LTMask code in x86_32.ad and x86_64.ad? We have third x86.ad file which contains instructions which are the same for 32- and 64-bit. Note both files are use rRegI now.
>> As separate changes (rfe) you can look if you can move LTMask (and other) instructions into x86.ad. One thing I notice is flag type name rFlagsReg vs eFlagsReg. You need to rename it to use rFlagsReg and move operand rFlagsReg() into x86.ad.
>>
>>
>> Thanks,
>> Vladimir
>>
>> On 4/5/13 11:08 AM, David Chase wrote:
>>> http://cr.openjdk.java.net/~drchase/6443505/webrev.01/
>>>
>>> Suggestions incorporated, revised and whacked on the sparc and-cmpltmask pattern until it was (1) observed to fire and (2) did not interfere with add-and-cmpltmask.
>>>
>>> I kept the branch-free variants in comments of x86, since these were also tested and seen to work.
>>>
>>> Revised code seen to work correctly on Sparc and x86, and also passed JPRT targeted to the new unit test.
>>>
>>>
>>> On 2013-04-01, at 2:01 PM, Christian Thalinger  wrote:
>>>
>>>>
>>>> On Mar 28, 2013, at 4:37 PM, Vladimir Kozlov  wrote:
>>>>
>>>>> "pipeline" info is not used in code generation, it is outdated anyway. So use what other similar instructions use.
>>>>>
>>>>> I think we should use only branch variant on all x86 (32 and 64bit). We save register (tmp) and it is MUCH MUCH more important for performance (less spills on stack). And you need only 3 instructions for cadd_cmpLTMask.
>>>>
>>>> I agree on this one.  -- Chris
>>>>
>>>>>
>>>>> And, please, remove unneeded spaces near parenthesis, at least in new code.
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 3/27/13 6:09 PM, David Chase wrote:
>>>>>> Problem:
>>>>>> (as stated)
>>>>>> C2 needs a special case like CmpLTMask (turn result of a comparison into a -1/0 mask) for the comparison of a difference with zero.
>>>>>>
>>>>>> (as actually observed)
>>>>>> 1) The improvement in that case is minimal and (very) difficult to get to trigger, because CSE interferes and extracts the p-q from the pattern.
>>>>>> 2) The original code generation for caddCmpLTMask on some platforms was actually wrong (used carry bit for a signed comparison)
>>>>>> 3) The original Ideal pattern matching, because of a typo/thinko, accidentally failed to apply in the symmetric case
>>>>>> 4) Code generation for CmpLTMask on all platforms omitted the somewhat relevant case of and-CmpLTMask; if the very specific pattern failed to apply, then it would fall back to the laborious calculation of an actual mask, when much more compact code could apply.
>>>>>>
>>>>>> Fix:
>>>>>> Repair wrong code generation.
>>>>>> Write additional pattern for (and (cmpltmask p q) y)
>>>>>> Fixed the typo so the pattern fires more often.
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~drchase/6443505/webrev.00/
>>>>>>
>>>>>> Testing:
>>>>>> Wrote a new test to definitely exercise the two patterns in question.
>>>>>> Verified that "new test" would fail running with unfixed compiler.
>>>>>>
>>>>>> Verified (observing assembly output) that the new patterns matched on x86_32-cmov, x86_32+cmov, x86_64, and Sparc
>>>>>> (except that I could not get the and-cmpltmask pattern to fire on Sparc.
>>>>>> Bit of a shame we lack a cumulative coverage tool wired into jtreg so we could easily know if it ever fired at all).
>>>>>>
>>>>>> Benchmarked change on x86_64 (saw little or no performance difference on the whole benchmark)
>>>>>>
>>>>>> JPRT on compiler tests (clean runs thwarted by irrelevant failures, but it was always the same 2 or 3 borked tests.)
>>>>>>
>>>>>> JPRT on just the new test (clean run)
>>>>>>
>>>>>> Questions:
>>>>>> not 100% sure on the pattern costs.
>>>>>> not 100% sure on the choice of "pipeline".
>>>>>>
>>>>
>>>
>

From roland.westrelin at oracle.com  Tue Apr  9 09:02:45 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 9 Apr 2013 18:02:45 +0200
Subject: RFR(S): 8011706: specjvm2008 test xml.transform gets array bound
	exception with c1
In-Reply-To: <516436D2.7010101@oracle.com>
References: <2BC866EE-271F-4CF1-8DCC-8C11759321BB@oracle.com>
	<516436D2.7010101@oracle.com>
Message-ID: 

> Changes are good but could you explain how you got "dominator is not a direct predecessor"? In C2 only irreducible loops have several entry points and could have such situation. Is it the same for this case in C1? Just curious.


Thanks for the review.
The test case in the webrev is an example. The loop header has 3 predecessors (both branches of the if + the backbranch). The dominator of the loop header is the block that ends with the if. So loop invariant code motion moves the load of the array field before the if.

Roland.

From roland.westrelin at oracle.com  Tue Apr  9 09:03:16 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 9 Apr 2013 18:03:16 +0200
Subject: RFR(XS): 8011648: C1: optimized build is broken after 7153771
In-Reply-To: <516437A6.2040208@oracle.com>
References: <48F03646-093E-42DC-9D7D-99403532C5FD@oracle.com>
	<516437A6.2040208@oracle.com>
Message-ID: 

Thanks for the review.

Roland.

From roland.westrelin at oracle.com  Tue Apr  9 09:03:33 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 9 Apr 2013 18:03:33 +0200
Subject: RFRS(XS): 8011582 assert(nbits == 32 || (-(1 << nbits-1) <= x &&
	x < ( 1 << nbits-1))) failed: value out of range
In-Reply-To: <5164372D.5040400@oracle.com>
References: <2EE91CDF-A3E9-4E1E-89DB-50A6C23CFF83@oracle.com>
	<5164372D.5040400@oracle.com>
Message-ID: <0BAD141F-DBD8-4646-8EA7-57F6FBDCBA0F@oracle.com>

Thanks for the review.

Roland.

From vladimir.x.ivanov at oracle.com  Tue Apr  9 09:22:41 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 09 Apr 2013 20:22:41 +0400
Subject: RFR(S): 8011706: specjvm2008 test xml.transform gets array bound
	exception with c1
In-Reply-To: <2BC866EE-271F-4CF1-8DCC-8C11759321BB@oracle.com>
References: <2BC866EE-271F-4CF1-8DCC-8C11759321BB@oracle.com>
Message-ID: <51644051.10309@oracle.com>

Roland,

I have a comment regarding regression test: can you replace 
System.exit(97) with throwing an exception? Calling System.exit() 
"considered harmful" :-)

Best regards,
Vladimir Ivanov

On 4/9/13 1:57 PM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8011706/webrev.00/
>
> Loop invariant code motion moves loop invariant loads (from a field or an array) to the dominator of the loop header. If the dominator is not a direct predecessor of the loop header then some stores to the same field/array may happen between the dominator and the loop header and a load may be moved before a store to the same field/array.
>
> Roland.
>

From vladimir.kozlov at oracle.com  Tue Apr  9 09:24:37 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 09 Apr 2013 09:24:37 -0700
Subject: RFR(S): 8011706: specjvm2008 test xml.transform gets array bound
	exception with c1
In-Reply-To: 
References: <2BC866EE-271F-4CF1-8DCC-8C11759321BB@oracle.com>
	<516436D2.7010101@oracle.com>
	
Message-ID: <516440C5.50208@oracle.com>

On 4/9/13 9:02 AM, Roland Westrelin wrote:
>> Changes are good but could you explain how you got "dominator is not a direct predecessor"? In C2 only irreducible loops have several entry points and could have such situation. Is it the same for this case in C1? Just curious.
>
>
> Thanks for the review.
> The test case in the webrev is an example. The loop header has 3 predecessors (both branches of the if + the backbranch). The dominator of the loop header is the block that ends with the if. So loop invariant code motion moves the load of the array field before the if.

I see. In C2 we insert additional block with Region before loop to merge 
all incoming branches so the loop block has only one entry and may be 
few back branches (which we split later during loop transofrmation).

Thanks,
Vladimir

>
> Roland.
>

From roland.westrelin at oracle.com  Tue Apr  9 09:25:26 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 9 Apr 2013 18:25:26 +0200
Subject: RFR(S): 8011706: specjvm2008 test xml.transform gets array bound
	exception with c1
In-Reply-To: <51644051.10309@oracle.com>
References: <2BC866EE-271F-4CF1-8DCC-8C11759321BB@oracle.com>
	<51644051.10309@oracle.com>
Message-ID: 

> I have a comment regarding regression test: can you replace System.exit(97) with throwing an exception? Calling System.exit() "considered harmful" :-)

Thanks for the correction. So should I not catch the NPE that's thrown in case of failure of the test or throw new Exception()?

Roland.

From vladimir.x.ivanov at oracle.com  Tue Apr  9 09:38:44 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 09 Apr 2013 20:38:44 +0400
Subject: RFR(S): 8011706: specjvm2008 test xml.transform gets array bound
	exception with c1
In-Reply-To: 
References: <2BC866EE-271F-4CF1-8DCC-8C11759321BB@oracle.com>
	<51644051.10309@oracle.com>
	
Message-ID: <51644414.30300@oracle.com>

Roland,

I would rewrite it as follows:
   ...
   } catch (NullPointerException ex) {
       throw new RuntimeException("TEST FAILED", e);
   }
   System.out.println("TEST PASSED");

Best regards,
Vladimir Ivanov

On 4/9/13 8:25 PM, Roland Westrelin wrote:
>> I have a comment regarding regression test: can you replace System.exit(97) with throwing an exception? Calling System.exit() "considered harmful" :-)
>
> Thanks for the correction. So should I not catch the NPE that's thrown in case of failure of the test or throw new Exception()?
>
> Roland.
>

From roland.westrelin at oracle.com  Tue Apr  9 09:39:30 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 9 Apr 2013 18:39:30 +0200
Subject: RFR(S): 8011706: specjvm2008 test xml.transform gets array bound
	exception with c1
In-Reply-To: <51644414.30300@oracle.com>
References: <2BC866EE-271F-4CF1-8DCC-8C11759321BB@oracle.com>
	<51644051.10309@oracle.com>
	
	<51644414.30300@oracle.com>
Message-ID: <0A6EDD24-4F95-4D38-8298-FA0673627FE4@oracle.com>

> I would rewrite it as follows:
>  ...
>  } catch (NullPointerException ex) {
>      throw new RuntimeException("TEST FAILED", e);
>  }
>  System.out.println("TEST PASSED");

Thanks for the suggestion. I'll do that.

Roland.

From vladimir.x.ivanov at oracle.com  Tue Apr  9 18:15:18 2013
From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com)
Date: Wed, 10 Apr 2013 01:15:18 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 8007288: Additional WB API for
	compiler's testing
Message-ID: <20130410011522.178474819A@hg.openjdk.java.net>

Changeset: b84fd7d73702
Author:    iignatyev
Date:      2013-04-09 09:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b84fd7d73702

8007288: Additional WB API for compiler's testing
Reviewed-by: kvn, vlivanov

! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/oops/methodData.hpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/compilationPolicy.hpp
! src/share/vm/utilities/accessFlags.hpp
! src/share/vm/utilities/globalDefinitions.hpp
+ test/compiler/whitebox/ClearMethodStateTest.java
! test/compiler/whitebox/CompilerWhiteBoxTest.java
! test/compiler/whitebox/DeoptimizeAllTest.java
! test/compiler/whitebox/DeoptimizeMethodTest.java
+ test/compiler/whitebox/EnqueueMethodForCompilationTest.java
! test/compiler/whitebox/IsMethodCompilableTest.java
! test/compiler/whitebox/MakeMethodNotCompilableTest.java
! test/compiler/whitebox/SetDontInlineMethodTest.java
+ test/compiler/whitebox/SetForceInlineMethodTest.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java


From nils.eliasson at oracle.com  Wed Apr 10 04:45:20 2013
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Wed, 10 Apr 2013 13:45:20 +0200
Subject: RFR(XS) 8009026: [parfait] Null pointer deference in
	hotspot/src/share/vm/code/nmethod.cpp
In-Reply-To: <514B0805.1050002@oracle.com>
References: <514B0805.1050002@oracle.com>
Message-ID: <516550D0.6080804@oracle.com>

Hi,

I know I am a bit late to the game, but I think I should raise the issue 
with false positives in Parfait. By fixing non-bugs we risk introducing 
new bugs into otherwise perfectly fine code by introducing unnecessary 
complexity.

In this bug (8009026) Parfait complains about 'this' being null in the 
constructor of nmethod. For non-throwing new that isn't a problem. If 
the allocation fails the constructor isn't run (Section 5.3.4 (13) of 
the C++03 standard). The fix unfortunately introduces a dependence 
between heap::allocate and codecache::has_space. If the allocate code is 
changed (as I was just about to do) without also fixing the 
codecache::has_space(), it may succeed while heap::allocate still 
returns null - and then we will fail the guarantee(), aborting the VM, 
instead of just skipping the compile as we used to. Also in the current 
implementation has_space() is more conservative than allocate() - so we 
will fail some compiles that would have worked before the fix.

If something should have been fixed, it should possibly been to have 
added an empty throw() to the new overloading, making it explicit that 
we want the empty exception-specification variant of new().

//Nils




From vladimir.kozlov at oracle.com  Wed Apr 10 10:55:23 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 10 Apr 2013 10:55:23 -0700
Subject: RFR(XS) 8009026: [parfait] Null pointer deference in
	hotspot/src/share/vm/code/nmethod.cpp
In-Reply-To: <516550D0.6080804@oracle.com>
References: <514B0805.1050002@oracle.com> <516550D0.6080804@oracle.com>
Message-ID: <5165A78B.2060407@oracle.com>

On 4/10/13 4:45 AM, Nils Eliasson wrote:
> Hi,
>
> I know I am a bit late to the game, but I think I should raise the issue
> with false positives in Parfait. By fixing non-bugs we risk introducing
> new bugs into otherwise perfectly fine code by introducing unnecessary
> complexity.

That is why we have review process. I always asked everyone to do reviews.

>
> In this bug (8009026) Parfait complains about 'this' being null in the
> constructor of nmethod. For non-throwing new that isn't a problem. If
> the allocation fails the constructor isn't run (Section 5.3.4 (13) of
> the C++03 standard). The fix unfortunately introduces a dependence
> between heap::allocate and codecache::has_space. If the allocate code is

Yes, it is unfortunate.

> changed (as I was just about to do) without also fixing the
> codecache::has_space(), it may succeed while heap::allocate still
> returns null - and then we will fail the guarantee(), aborting the VM,
> instead of just skipping the compile as we used to. Also in the current

We can add assert into CodeCache::allocate to check if has_space() 
returns the same result.

> implementation has_space() is more conservative than allocate() - so we
> will fail some compiles that would have worked before the fix.

To be conservative is not bad and you see the difference only in edge 
case. The remaining space is not lost it will be used for adapters.

>
> If something should have been fixed, it should possibly been to have
> added an empty throw() to the new overloading, making it explicit that
> we want the empty exception-specification variant of new().

We don't use C++ exceptions.

Thanks,
Vladimir

>
> //Nils
>
>
>

From christian.thalinger at oracle.com  Wed Apr 10 14:07:42 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 10 Apr 2013 14:07:42 -0700
Subject: RFR (S): 8011933: add number of classes,
	methods and time spent to CompileTheWorld
Message-ID: <47080B19-6B18-4CD8-A1DD-61088B72A1D8@oracle.com>

http://cr.openjdk.java.net/~twisti/8011933

8011933: add number of classes, methods and time spent to CompileTheWorld
Reviewed-by:

Add some code to print some statistics with the done message: 

CompileTheWorld : Done (2 classes, 16 methods, 972 ms)

src/share/vm/classfile/classLoader.cpp
src/share/vm/classfile/classLoader.hpp


From john.r.rose at oracle.com  Wed Apr 10 14:30:34 2013
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 10 Apr 2013 14:30:34 -0700
Subject: RFR (S): 8011933: add number of classes,
	methods and time spent to CompileTheWorld
In-Reply-To: <47080B19-6B18-4CD8-A1DD-61088B72A1D8@oracle.com>
References: <47080B19-6B18-4CD8-A1DD-61088B72A1D8@oracle.com>
Message-ID: <6B8292E1-5DF2-4C4F-A6AE-02B43CB88ECD@oracle.com>

Reviewed.  ? John

On Apr 10, 2013, at 2:07 PM, Christian Thalinger  wrote:

> http://cr.openjdk.java.net/~twisti/8011933
> 
> 8011933: add number of classes, methods and time spent to CompileTheWorld
> Reviewed-by:
> 
> Add some code to print some statistics with the done message: 
> 
> CompileTheWorld : Done (2 classes, 16 methods, 972 ms)
> 
> src/share/vm/classfile/classLoader.cpp
> src/share/vm/classfile/classLoader.hpp
> 


From vladimir.kozlov at oracle.com  Wed Apr 10 15:53:16 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 10 Apr 2013 15:53:16 -0700
Subject: RFR (S): 8011933: add number of classes, methods and time spent
	to CompileTheWorld
In-Reply-To: <47080B19-6B18-4CD8-A1DD-61088B72A1D8@oracle.com>
References: <47080B19-6B18-4CD8-A1DD-61088B72A1D8@oracle.com>
Message-ID: <5165ED5C.6060603@oracle.com>

Looks good.

Vladimir

On 4/10/13 2:07 PM, Christian Thalinger wrote:
> http://cr.openjdk.java.net/~twisti/8011933
>
> 8011933: add number of classes, methods and time spent to CompileTheWorld
> Reviewed-by:
>
> Add some code to print some statistics with the done message:
>
> CompileTheWorld : Done (2 classes, 16 methods, 972 ms)
>
> src/share/vm/classfile/classLoader.cpp
> src/share/vm/classfile/classLoader.hpp
>

From vitalyd at gmail.com  Wed Apr 10 16:42:39 2013
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 10 Apr 2013 19:42:39 -0400
Subject: RFR (S): 8011933: add number of classes, methods and time spent
	to CompileTheWorld
In-Reply-To: <47080B19-6B18-4CD8-A1DD-61088B72A1D8@oracle.com>
References: <47080B19-6B18-4CD8-A1DD-61088B72A1D8@oracle.com>
Message-ID: 

Chris,

This is pedantic but os::javaTimeNanos() may be better since it'll use
higher resolution clock source and it's monotonic (if OS supports monotonic
clock).

Vitaly
On Apr 10, 2013 5:08 PM, "Christian Thalinger" <
christian.thalinger at oracle.com> wrote:

> http://cr.openjdk.java.net/~twisti/8011933
>
> 8011933: add number of classes, methods and time spent to CompileTheWorld
> Reviewed-by:
>
> Add some code to print some statistics with the done message:
>
> CompileTheWorld : Done (2 classes, 16 methods, 972 ms)
>
> src/share/vm/classfile/classLoader.cpp
> src/share/vm/classfile/classLoader.hpp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130410/703d5613/attachment.html 

From christian.thalinger at oracle.com  Wed Apr 10 19:49:31 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 10 Apr 2013 19:49:31 -0700
Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp
	stub [Was: Re: RFR (S): Specify offset of IC load in
	java_to_interp stub.]
In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFB116E@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC0CFA7D32@DEWDFEMB12A.global.corp.sap>
	<03C4DFDE-CD52-446E-92AA-A6F12903FE29@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB116E@DEWDFEMB12A.global.corp.sap>
Message-ID: <7D07437F-CFF7-4298-B9A1-DE9F2E32D77D@oracle.com>


On Apr 9, 2013, at 7:35 AM, "Lindenmaier, Goetz"  wrote:

> Hi Chris, 
> 
> I'm now working on this issue.  Sorry for the delay...
> 
> What do you think about moving 
>    void emit_java_to_interp(CodeBuffer& cbuf);
> and
>   void size_java_to_interp();
> to compiledIC.hpp and the new platform file, too?

I like that.

> 
> This would also allow to overcome the ugly 
>   extern uint size_java_to_interp();
> in output.cpp, as it could be replaced by CompiledStaticCall::size_java_to_interp().

Great.

> 
> I also would like to name this
>  CompiledStaticCall::emit_to_interp_stub()
>  CompiledStaticCall::to_interp_stub_size()

I'm okay with that.  Not sure if others have objections.

> 
> I could also extract code from enc_class Java_Static_Call 
> to form a routine
>  CompiledStaticCall::emit_call(CodeBuffer *cbuf, intptr_t entry_point, relocInfo::relocType rtype) {
>    emit_call_reloc(cbuf, entry_point, rtype)
>    if (rtype != relocInfo::runtime_call_type) {
>        emit_java_to_interp(cbuf);
>      }
>  }
> With this, also 
>  extern uint reloc_java_to_interp();
> from output.cpp could be moved into this class.

On SPARC only or the other architectures as well?

> 
> Then handling of CompiledStaticCalls would be completely implemented in this
> one class.

That's tempting.

> 
> (I would have to move emit_call_reloc to MacroAssembler.)

Could you send a webrev with these changes?

-- Chris

> 
> Best regards,
>  Goetz.
> 
> 
> 
> -----Original Message-----
> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
> Sent: Montag, 25. M?rz 2013 23:29
> To: Lindenmaier, Goetz
> Cc: 'hotspot-compiler-dev at openjdk.java.net'
> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
> 
> 
> On Mar 4, 2013, at 8:34 AM, "Lindenmaier, Goetz"  wrote:
> 
>> Hi Chris, 
>> 
>> I would like to take up this issue again. 
>> I'm about to put our changes on the jdk8 branch, and it would be convenient
>> to have a final solution for this.
>> 
>> Should I prepare a webrev with a different solution adding a new file
>> for this?  What should go into that file? 
> 
> Sorry for answering that late.
> 
> Yes, to see a patch for that would be good.  We need to put all platform dependent Compiled* methods in that new file.  Platform dependent means every method that uses a native* method from nativeInst_:
> 
> CompiledIC::cleanup_call_site
> CompiledIC::is_icholder_call_site
> CompiledIC::CompiledIC
> 
> CompiledStaticCall::set_to_interpreted
> CompiledStaticCall::set_stub_to_clean
> CompiledStaticCall::verify
> 
> -- Chris
> 
>> 
>> Best regards,
>> Goetz.
>> 
>> 
>> 
>> -----Original Message-----
>> From: goetz.lindenmaier at sap.com 
>> Sent: Dienstag, 18. Dezember 2012 10:42
>> To: 'Christian Thalinger'
>> Subject: RE: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>> 
>> Hi Chris, 
>> 
>> What would you put into that file?  The offset, or the class CompiledStaticCall?
>> You could also put it into nativeInst_  to avoid adding another file.
>> 
>> But basically I think the offset is the best solution, because it's very small
>> and straight forward, and the offset is set where the code is generated 
>> that defines the offset.
>> 
>> Only the #ifndef COMPILER2 is ugly, but here I think the solution is to 
>> guard the whole class CompiledStaticCall with #ifdef COMPILER2.
>> 
>> But I'm happy with any placement of the code.
>> 
>> Best regards,
>> Goetz.
>> 
>> 
>> 
>> -----Original Message-----
>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>> Sent: Montag, 17. Dezember 2012 21:34
>> To: Lindenmaier, Goetz
>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>> 
>> 
>> On Nov 29, 2012, at 2:10 PM, "Lindenmaier, Goetz"  wrote:
>> 
>>> Hi Chris, 
>>> 
>>> Loading the constant takes 5 instructions, the other way only three,
>>> in the code only one, if the constant pool base is in a register.
>>> The 5 instructions are hard to patch atomically.  The constant pool 
>>> is just a 64 bit store.  
>>> 
>>>> Sorry for being so persistent on this :-)  
>>> That's ok, I already found several places in our VM where it was easy to 
>>> change our code to get along without the shared changes we did in 
>>> first place.  But I can't redesign everything, and I can not risk to break
>>> anything in our product.
>>> 
>>> If you feel like doing so, you can have a look at 
>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/600ce596eea9
>>> which contains our bytecode interpreter profiling implementation.
>>> If you think this is currently of use in the main branch, I would lift it to HS25 
>>> (the permgen changes might cause trouble) and contribute it to hsx.
>> 
>> Sorry for the long delay.
>> 
>> Thinking about this problem again it seems that the correct solution would be to have a compiledIC_.cpp file.
>> 
>> The CompiledIC instruction layout is platform dependent; it just happens to be the same for all architectures we have right now (well, except PPC) because we made it to be the same.  Actually on SPARC we could also use a load from the constant table which would be simpler.
>> 
>> Having a platform dependent file for this code feels right.  What do you think?
>> 
>> -- Chris
>> 
>>> 
>>> Best regards,
>>> Goetz.
>>> 
>>> -----Original Message-----
>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>> Sent: Thursday, November 29, 2012 7:53 PM
>>> To: Lindenmaier, Goetz
>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>> 
>>> 
>>> On Nov 29, 2012, at 12:27 AM, "Lindenmaier, Goetz"  wrote:
>>> 
>>>> Hi Chris, 
>>>> 
>>>>> Why can't you point the relocation to the method load instruction?  It doesn't seem right to do that in shared code.
>>>> Because the relocation is used 
>>>> 1.) to find the beginning of the stub to patch the call to go there 
>>>> 2.) to find the load to patch the IC.
>>> 
>>> Got it.
>>> 
>>>> 
>>>> Just have a look at CompiledStaticCall::set_to_interpreted(),
>>>> the variable 'stub' is used twice.  
>>> 
>>> Sorry for being so persistent on this :-)  What is the reason you have to load the constant from the constant table?  On other architectures we materialize the constant.
>>> 
>>> -- Chris
>>> 
>>>> 
>>>> Best regards, 
>>>> Goetz.
>>>> 
>>>> -----Original Message-----
>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>> Sent: Donnerstag, 29. November 2012 01:35
>>>> To: Lindenmaier, Goetz
>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>> 
>>>> 
>>>> On Nov 27, 2012, at 4:24 AM, "Lindenmaier, Goetz"  wrote:
>>>> 
>>>>> Hi Chris,
>>>>> 
>>>>>> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub?
>>>>> Shared code (class CompiledStaticCall) wants to patch the inline cache 
>>>>> in the stub which is emitted in platform code.
>>>>> So the platform code should specify how the shared code can find the inline cache 
>>>>> in the stub, which it does through the constant I introduced.
>>>>> 
>>>>>> Do you need two relocations?  I'm confused.
>>>>> No, three ;)
>>>>> The relocation you mention is used to find the stub given the call.
>>>>> The other relocations are needed to find the inline cache / call target
>>>>> once the stub is found (see CompiledStaticCall::set_to_interpreted()).
>>>>> It's just the same on x86_64:
>>>>> 
>>>>> // static stub relocation stores the instruction address of the call
>>>>> __ relocate(static_stub_Relocation::spec(mark), RELOC_IMM64); 
>>>>> // static stub relocation also tags the methodOop in the code-stream.
>>>>> __ movoop(rbx, (jobject) NULL);  // method is zapped till fixup time
>>>>> // This is recognized as unresolved by relocs/nativeinst/ic code
>>>>> __ jump(RuntimeAddress(__ pc()));
>>>>> 
>>>>> On PPC, we have to load the base of the constant table after generating the 
>>>>> static_stub_relocation and before emitting the ppc equivalent for moveoop(). This offset is 
>>>>> exactly what we store in the  CompiledStaticCall::comp_to_int_load_offset constant.
>>>> 
>>>> Why can't you point the relocation to the method load instruction?  It doesn't seem right to do that in shared code.
>>>> 
>>>> -- Chris
>>>> 
>>>>> 
>>>>> Best regards,
>>>>> Goetz.
>>>>> 
>>>>> 
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>> Sent: Dienstag, 27. November 2012 01:53
>>>>> To: Lindenmaier, Goetz
>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>> 
>>>>> 
>>>>> On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz"  wrote:
>>>>> 
>>>>>> Hi Chris,
>>>>>> 
>>>>>> We put it into the ad file because it describes an offset into the stub that is
>>>>>> generated from the ad file by emit_java_to_interp(CodeBuffer& cbuf), 
>>>>>> used by ir  node CallStaticJavaDirect.  Maybe I should not call it stub, but it's 
>>>>>> generated into the stubs section of the code buffer.
>>>>>> If that stub generator is moved out of the ad file to shared compiler code, one should
>>>>>> move the field with it, but for the current implementation I think that's fine.
>>>>>> 
>>>>>> Does C1 generate the same stub? Or is the CompiledStaticCall a C2 feature?
>>>>>> If so, one could protect the whole thing by #ifdef COMPILER2.
>>>>> 
>>>>> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub?
>>>>> 
>>>>> // Create a static stub relocation which relates this stub
>>>>> // with the call instruction at insts_call_instruction_offset in the
>>>>> // instructions code-section.
>>>>> __ relocate(static_stub_Relocation::spec(__ code()->insts()->start() + insts_relocation_offset));
>>>>> 
>>>>> Do you need two relocations?  I'm confused.
>>>>> 
>>>>> -- Chris
>>>>> 
>>>>>> 
>>>>>> Thanks for all the bugids!
>>>>>> 
>>>>>> Best regards,
>>>>>> Goetz.
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>>> Sent: Mittwoch, 21. November 2012 19:53
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>> Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>>> 
>>>>>> 
>>>>>> On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz"  wrote:
>>>>>> 
>>>>>>> Hi Chris, 
>>>>>>> 
>>>>>>> yes, there is no C1 on ppc.  
>>>>>>> We do tiered compilation with a stripped C2.
>>>>>> 
>>>>>> Right.  But some other architecture (or in the future) might need this for C1 as well.  We should find a better place for the value than the ad file.  The obvious place would be compiledIC_.hpp but we don't have that file, yet.
>>>>>> 
>>>>>> I filed:
>>>>>> 
>>>>>> 8003853: specify offset of IC load in java_to_interp stub
>>>>>> 
>>>>>> -- Chris
>>>>>> 
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> Goetz
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>>>> Sent: Dienstag, 20. November 2012 22:19
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>> Subject: Re: RFR (S): Specify offset of IC load in java_to_interp stub.
>>>>>>> 
>>>>>>> 
>>>>>>> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz"  wrote:
>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub
>>>>>>>> to update the IC  with NativeMovConstReg.  The current implementation assumes that
>>>>>>>> the load is always the first instruction in the stub.  This is an artificial restriction. E.g.,
>>>>>>>> it might be useful to load the constant pool address (MachConstantBase) before the
>>>>>>>> IC load (as we do on PPC).
>>>>>>>> 
>>>>>>>> This change adds a constant specifying an offset from the beginning of the stub to
>>>>>>>> the  IC load. The offset is platform specific and 0 on sparc and x86.
>>>>>>>> 
>>>>>>>> You can find the change here:
>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/
>>>>>>> 
>>>>>>> That should be fixed indeed.  
>>>>>>> 
>>>>>>> +#ifndef COMPILER2
>>>>>>> +const int CompiledStaticCall::comp_to_int_load_offset = 0;
>>>>>>> 
>>>>>>> There is no C1 for PPC (sorry, I didn't check)?
>>>>>>> 
>>>>>>> -- Chris
>>>>>>> 
>>>>>>>> 
>>>>>>>> or in our ppc port:
>>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33
>>>>>>>> 
>>>>>>>> Thank you and best regards,
>>>>>>>> Goetz
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


From krystal.mo at oracle.com  Wed Apr 10 20:38:20 2013
From: krystal.mo at oracle.com (Krystal Mo)
Date: Wed, 10 Apr 2013 20:38:20 -0700
Subject: Request for review (XS): JDK-8011952: Missing ResourceMarks in
	TraceMethodHandles
Message-ID: <5166302C.9060904@oracle.com>

Hi everybody,

Could I have a review for this small change, please?

Webrev: http://cr.openjdk.java.net/~kmo/8011952/webrev.00/
CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011952

Description: (copied from CR)

There are some TraceMethodHandles logic that uses Symbol::as_C_string(), 
but miss putting a ResourceMark in the appropriate scope, triggering 
assertions in debug builds when using -XX:+TraceMethodHandles.

Testing:

Testing with JPRT.
Hand tested some programs using MethodHandles with VM flags: 
-XX:+TraceMethodHandles -XX:+Verbose, all of them hit assertion before 
change and pass after the change.

Thanks,
Kris


From christian.thalinger at oracle.com  Wed Apr 10 20:49:03 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 10 Apr 2013 20:49:03 -0700
Subject: RFR (S): 8011933: add number of classes,
	methods and time spent to CompileTheWorld
In-Reply-To: 
References: <47080B19-6B18-4CD8-A1DD-61088B72A1D8@oracle.com>
	
Message-ID: 


On Apr 10, 2013, at 4:42 PM, Vitaly Davidovich  wrote:

> Chris,
> 
> This is pedantic but os::javaTimeNanos() may be better since it'll use higher resolution clock source and it's monotonic (if OS supports monotonic clock).
> 
The time spent is really only a rough estimate since it includes other things like the pre-loading of the classes in the constant pool.  If someone wants better numbers in the future we should time the compiles only.  For now this is good enough.

Thanks for the review.

-- Chris
> Vitaly
> 
> On Apr 10, 2013 5:08 PM, "Christian Thalinger"  wrote:
> http://cr.openjdk.java.net/~twisti/8011933
> 
> 8011933: add number of classes, methods and time spent to CompileTheWorld
> Reviewed-by:
> 
> Add some code to print some statistics with the done message:
> 
> CompileTheWorld : Done (2 classes, 16 methods, 972 ms)
> 
> src/share/vm/classfile/classLoader.cpp
> src/share/vm/classfile/classLoader.hpp
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130410/6e2554b2/attachment.html 

From david.holmes at oracle.com  Wed Apr 10 21:14:13 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 11 Apr 2013 14:14:13 +1000
Subject: Request for review (XS): JDK-8011952: Missing ResourceMarks in
	TraceMethodHandles
In-Reply-To: <5166302C.9060904@oracle.com>
References: <5166302C.9060904@oracle.com>
Message-ID: <51663895.2070505@oracle.com>

Looks good to me!

Thanks,
David

On 11/04/2013 1:38 PM, Krystal Mo wrote:
> Hi everybody,
>
> Could I have a review for this small change, please?
>
> Webrev: http://cr.openjdk.java.net/~kmo/8011952/webrev.00/
> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011952
>
> Description: (copied from CR)
>
> There are some TraceMethodHandles logic that uses Symbol::as_C_string(),
> but miss putting a ResourceMark in the appropriate scope, triggering
> assertions in debug builds when using -XX:+TraceMethodHandles.
>
> Testing:
>
> Testing with JPRT.
> Hand tested some programs using MethodHandles with VM flags:
> -XX:+TraceMethodHandles -XX:+Verbose, all of them hit assertion before
> change and pass after the change.
>
> Thanks,
> Kris
>

From krystal.mo at oracle.com  Wed Apr 10 21:16:46 2013
From: krystal.mo at oracle.com (Krystal Mo)
Date: Wed, 10 Apr 2013 21:16:46 -0700
Subject: Request for review (XS): JDK-8011952: Missing ResourceMarks in
	TraceMethodHandles
In-Reply-To: <51663895.2070505@oracle.com>
References: <5166302C.9060904@oracle.com> <51663895.2070505@oracle.com>
Message-ID: <5166392E.20104@oracle.com>

Thank you, David!

- Kris

On 04/10/2013 09:14 PM, David Holmes wrote:
> Looks good to me!
>
> Thanks,
> David
>
> On 11/04/2013 1:38 PM, Krystal Mo wrote:
>> Hi everybody,
>>
>> Could I have a review for this small change, please?
>>
>> Webrev: http://cr.openjdk.java.net/~kmo/8011952/webrev.00/
>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011952
>>
>> Description: (copied from CR)
>>
>> There are some TraceMethodHandles logic that uses Symbol::as_C_string(),
>> but miss putting a ResourceMark in the appropriate scope, triggering
>> assertions in debug builds when using -XX:+TraceMethodHandles.
>>
>> Testing:
>>
>> Testing with JPRT.
>> Hand tested some programs using MethodHandles with VM flags:
>> -XX:+TraceMethodHandles -XX:+Verbose, all of them hit assertion before
>> change and pass after the change.
>>
>> Thanks,
>> Kris
>>


From roland.westrelin at oracle.com  Thu Apr 11 01:08:17 2013
From: roland.westrelin at oracle.com (roland.westrelin at oracle.com)
Date: Thu, 11 Apr 2013 08:08:17 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 8011706: specjvm2008 test xml.transform
	gets array bound exception with c1
Message-ID: <20130411080819.4A3ED481F8@hg.openjdk.java.net>

Changeset: 84ab5667f290
Author:    roland
Date:      2013-04-10 09:52 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/84ab5667f290

8011706: specjvm2008 test xml.transform gets array bound exception with c1
Summary: loop invariant code motion may move load before store to the same field
Reviewed-by: kvn

! src/share/vm/c1/c1_ValueMap.cpp
+ test/compiler/8011706/Test8011706.java


From staffan.larsen at oracle.com  Thu Apr 11 02:24:03 2013
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 11 Apr 2013 11:24:03 +0200
Subject: Request for review (XS): JDK-8011952: Missing ResourceMarks in
	TraceMethodHandles
In-Reply-To: <5166302C.9060904@oracle.com>
References: <5166302C.9060904@oracle.com>
Message-ID: <47B8C164-2EEB-4C1A-90DC-6715607DEFF3@oracle.com>

Looks good.

/Staffan

On 11 apr 2013, at 05:38, Krystal Mo  wrote:

> Hi everybody,
> 
> Could I have a review for this small change, please?
> 
> Webrev: http://cr.openjdk.java.net/~kmo/8011952/webrev.00/
> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011952
> 
> Description: (copied from CR)
> 
> There are some TraceMethodHandles logic that uses Symbol::as_C_string(), but miss putting a ResourceMark in the appropriate scope, triggering assertions in debug builds when using -XX:+TraceMethodHandles.
> 
> Testing:
> 
> Testing with JPRT.
> Hand tested some programs using MethodHandles with VM flags: -XX:+TraceMethodHandles -XX:+Verbose, all of them hit assertion before change and pass after the change.
> 
> Thanks,
> Kris
> 


From krystal.mo at oracle.com  Thu Apr 11 02:26:49 2013
From: krystal.mo at oracle.com (Krystal Mo)
Date: Thu, 11 Apr 2013 02:26:49 -0700
Subject: Request for review (XS): JDK-8011952: Missing ResourceMarks in
	TraceMethodHandles
In-Reply-To: <47B8C164-2EEB-4C1A-90DC-6715607DEFF3@oracle.com>
References: <5166302C.9060904@oracle.com>
	<47B8C164-2EEB-4C1A-90DC-6715607DEFF3@oracle.com>
Message-ID: <516681D9.9070803@oracle.com>

Thank you, Staffan!

- Kris

On 04/11/2013 02:24 AM, Staffan Larsen wrote:
> Looks good.
>
> /Staffan
>
> On 11 apr 2013, at 05:38, Krystal Mo  wrote:
>
>> Hi everybody,
>>
>> Could I have a review for this small change, please?
>>
>> Webrev: http://cr.openjdk.java.net/~kmo/8011952/webrev.00/
>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011952
>>
>> Description: (copied from CR)
>>
>> There are some TraceMethodHandles logic that uses Symbol::as_C_string(), but miss putting a ResourceMark in the appropriate scope, triggering assertions in debug builds when using -XX:+TraceMethodHandles.
>>
>> Testing:
>>
>> Testing with JPRT.
>> Hand tested some programs using MethodHandles with VM flags: -XX:+TraceMethodHandles -XX:+Verbose, all of them hit assertion before change and pass after the change.
>>
>> Thanks,
>> Kris
>>


From vladimir.x.ivanov at oracle.com  Thu Apr 11 02:52:25 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 11 Apr 2013 13:52:25 +0400
Subject: RFR (XS): 8011972: Field can be erroneously marked as contended when
	@Contended annotation isn't present
Message-ID: <516687D9.2070700@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8011972/webrev.00
4 lines changed: 0 ins; 3 del; 1 mod

If a field is marked with some annotation recognized by VM (but not 
@Contended), the field will be marked as contended anyway. It's because 
AnnotationCollector::set_contended(bool contended) ignores the parameter 
and always marks a field as contended.

Moreover, calls to AnnotationCollector::set_contended in 
ClassFileParser::parse_annotations are redundant, because there's 
already a call right before:
src/share/vm/classfile/classFileParser.cpp:
1714     coll->set_annotation(id);

The problem hasn't manifested itself before, because @Contended is the 
only annotation on fields [1] VM recognizes. I hit it when working on a 
new annotation on fields for VM.

Testing: manual (w/ additional annotation on fields), 
runtime/8003985/Test8003985.java

Best regards,
Vladimir Ivanov

[1] 
http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/file/tip/src/share/vm/classfile/classFileParser.cpp 

ClassFileParser::AnnotationCollector::annotation_index

From krystal.mo at oracle.com  Thu Apr 11 02:59:59 2013
From: krystal.mo at oracle.com (Krystal Mo)
Date: Thu, 11 Apr 2013 02:59:59 -0700
Subject: RFR (XS): 8011972: Field can be erroneously marked as contended
	when @Contended annotation isn't present
In-Reply-To: <516687D9.2070700@oracle.com>
References: <516687D9.2070700@oracle.com>
Message-ID: <5166899F.8010400@oracle.com>

Looks good to me.

- Kris

On 04/11/2013 02:52 AM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8011972/webrev.00
> 4 lines changed: 0 ins; 3 del; 1 mod
>
> If a field is marked with some annotation recognized by VM (but not 
> @Contended), the field will be marked as contended anyway. It's 
> because AnnotationCollector::set_contended(bool contended) ignores the 
> parameter and always marks a field as contended.
>
> Moreover, calls to AnnotationCollector::set_contended in 
> ClassFileParser::parse_annotations are redundant, because there's 
> already a call right before:
> src/share/vm/classfile/classFileParser.cpp:
> 1714     coll->set_annotation(id);
>
> The problem hasn't manifested itself before, because @Contended is the 
> only annotation on fields [1] VM recognizes. I hit it when working on 
> a new annotation on fields for VM.
>
> Testing: manual (w/ additional annotation on fields), 
> runtime/8003985/Test8003985.java
>
> Best regards,
> Vladimir Ivanov
>
> [1] 
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/file/tip/src/share/vm/classfile/classFileParser.cpp 
>
> ClassFileParser::AnnotationCollector::annotation_index


From aleksey.shipilev at oracle.com  Thu Apr 11 03:34:30 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 11 Apr 2013 14:34:30 +0400
Subject: RFR (XS): 8011972: Field can be erroneously marked as contended
	when @Contended annotation isn't present
In-Reply-To: <516687D9.2070700@oracle.com>
References: <516687D9.2070700@oracle.com>
Message-ID: <516691B6.1030504@oracle.com>

Thanks!
Looks good.

-Aleksey.

On 04/11/2013 01:52 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8011972/webrev.00
> 4 lines changed: 0 ins; 3 del; 1 mod
> 
> If a field is marked with some annotation recognized by VM (but not
> @Contended), the field will be marked as contended anyway. It's because
> AnnotationCollector::set_contended(bool contended) ignores the parameter
> and always marks a field as contended.
> 
> Moreover, calls to AnnotationCollector::set_contended in
> ClassFileParser::parse_annotations are redundant, because there's
> already a call right before:
> src/share/vm/classfile/classFileParser.cpp:
> 1714     coll->set_annotation(id);
> 
> The problem hasn't manifested itself before, because @Contended is the
> only annotation on fields [1] VM recognizes. I hit it when working on a
> new annotation on fields for VM.
> 
> Testing: manual (w/ additional annotation on fields),
> runtime/8003985/Test8003985.java
> 
> Best regards,
> Vladimir Ivanov
> 
> [1]
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/file/tip/src/share/vm/classfile/classFileParser.cpp
> 
> ClassFileParser::AnnotationCollector::annotation_index


From aleksey.shipilev at oracle.com  Thu Apr 11 03:37:33 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 11 Apr 2013 14:37:33 +0400
Subject: RFR (XS): 8011972: Field can be erroneously marked as contended
	when @Contended annotation isn't present
In-Reply-To: <516691B6.1030504@oracle.com>
References: <516687D9.2070700@oracle.com> <516691B6.1030504@oracle.com>
Message-ID: <5166926D.1010607@oracle.com>

BTW, is there any reason to retain AnnotationCollector::set_contended?
There is a symmetrical AnnotationCollector::is_contended which can be
folded to "has_annotation(_sun_misc_Contended)"?

-Aleksey.

On 04/11/2013 02:34 PM, Aleksey Shipilev wrote:
> Thanks!
> Looks good.
> 
> -Aleksey.
> 
> On 04/11/2013 01:52 PM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8011972/webrev.00
>> 4 lines changed: 0 ins; 3 del; 1 mod
>>
>> If a field is marked with some annotation recognized by VM (but not
>> @Contended), the field will be marked as contended anyway. It's because
>> AnnotationCollector::set_contended(bool contended) ignores the parameter
>> and always marks a field as contended.
>>
>> Moreover, calls to AnnotationCollector::set_contended in
>> ClassFileParser::parse_annotations are redundant, because there's
>> already a call right before:
>> src/share/vm/classfile/classFileParser.cpp:
>> 1714     coll->set_annotation(id);
>>
>> The problem hasn't manifested itself before, because @Contended is the
>> only annotation on fields [1] VM recognizes. I hit it when working on a
>> new annotation on fields for VM.
>>
>> Testing: manual (w/ additional annotation on fields),
>> runtime/8003985/Test8003985.java
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> [1]
>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/file/tip/src/share/vm/classfile/classFileParser.cpp
>>
>> ClassFileParser::AnnotationCollector::annotation_index
> 


From vladimir.x.ivanov at oracle.com  Thu Apr 11 04:20:07 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 11 Apr 2013 15:20:07 +0400
Subject: RFR (XS): 8011972: Field can be erroneously marked as contended
	when @Contended annotation isn't present
In-Reply-To: <5166926D.1010607@oracle.com>
References: <516687D9.2070700@oracle.com> <516691B6.1030504@oracle.com>
	<5166926D.1010607@oracle.com>
Message-ID: <51669C67.5040807@oracle.com>

Kris, Aleksey, thanks for review.

AnnotationCollector::set_contended isn't used anymore and I don't see 
any reason to keep it. Will remove it completely.

Regarding is_contended(), I'm reluctant to replace it with 
has_annotation(_sun_misc_Contended), because it's more verbose.

Best regards,
Vladimir Ivanov

On 4/11/13 2:37 PM, Aleksey Shipilev wrote:
> BTW, is there any reason to retain AnnotationCollector::set_contended?
> There is a symmetrical AnnotationCollector::is_contended which can be
> folded to "has_annotation(_sun_misc_Contended)"?
>
> -Aleksey.
>
> On 04/11/2013 02:34 PM, Aleksey Shipilev wrote:
>> Thanks!
>> Looks good.
>>
>> -Aleksey.
>>
>> On 04/11/2013 01:52 PM, Vladimir Ivanov wrote:
>>> http://cr.openjdk.java.net/~vlivanov/8011972/webrev.00
>>> 4 lines changed: 0 ins; 3 del; 1 mod
>>>
>>> If a field is marked with some annotation recognized by VM (but not
>>> @Contended), the field will be marked as contended anyway. It's because
>>> AnnotationCollector::set_contended(bool contended) ignores the parameter
>>> and always marks a field as contended.
>>>
>>> Moreover, calls to AnnotationCollector::set_contended in
>>> ClassFileParser::parse_annotations are redundant, because there's
>>> already a call right before:
>>> src/share/vm/classfile/classFileParser.cpp:
>>> 1714     coll->set_annotation(id);
>>>
>>> The problem hasn't manifested itself before, because @Contended is the
>>> only annotation on fields [1] VM recognizes. I hit it when working on a
>>> new annotation on fields for VM.
>>>
>>> Testing: manual (w/ additional annotation on fields),
>>> runtime/8003985/Test8003985.java
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> [1]
>>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/file/tip/src/share/vm/classfile/classFileParser.cpp
>>>
>>> ClassFileParser::AnnotationCollector::annotation_index
>>
>

From david.r.chase at oracle.com  Thu Apr 11 05:48:45 2013
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 11 Apr 2013 08:48:45 -0400
Subject: RFR (M): 6443505: Ideal() function for CmpLTMask
In-Reply-To: <516438BE.1080507@oracle.com>
References: <32C62903-0EB1-4668-B66F-B94ED433AC30@oracle.com>
	<5154D446.5050708@oracle.com>
	<4E5D18DB-C9A6-4DAB-ADB4-E6890E4B4DD1@oracle.com>
	<2DE0B851-3A39-4027-9DFC-A19BF3C075C0@oracle.com>
	<516314D9.1080002@oracle.com>
	
	<516438BE.1080507@oracle.com>
Message-ID: <8E700E1C-ED14-42C2-8077-7BF7984C629E@oracle.com>

http://cr.openjdk.java.net/~drchase/6443505/webrev.02/

On 2013-04-09, at 11:50 AM, Vladimir Kozlov  wrote:

> Leave only first lines commented to see matching and remove the rest:
> 
>  /* If I enable this, I encourage spilling in the inner loop of compress.
>  instruct cadd_cmpLTMask_mem( ncxRegI p, ncxRegI q, memory y, eCXRegI tmp, eFlagsReg cr ) %{
>  match(Set p (AddI (AndI (CmpLTMask p q) (LoadI y)) (SubI p q)));
>  */
> 
> Vladimir
> 
> On 4/9/13 5:10 AM, David Chase wrote:
>> Any reason I should not delete:
>> 
>>   enc_class enc_cmpLTP_mem(rRegI p, rRegI q, memory mem, eCXRegI tmp) %{    // cadd_cmpLT
>> 
>> It's only called from a comment:
>> 
>> /* If I enable this, I encourage spilling in the inner loop of compress.
>> instruct cadd_cmpLTMask_mem(ncxRegI p, ncxRegI q, memory y, eCXRegI tmp, eFlagsReg cr) %{
>> 
>> And the code that it generates is wrong.
>> And it uses the pre-macro-assembler.
>> 
>> David
>> 
>> 
>> On 2013-04-08, at 3:04 PM, Vladimir Kozlov  wrote:
>> 
>>> David,
>>> 
>>> We already have several thousands lines in .ad files so I would prefer to remove unused code. You can leave the comment explaining why we use branches instead of cmoves.
>>> 
>>> Please, remove next lines since we will have comment about that:
>>> // always // predicate(!VM_Version::supports_cmov());
>>> 
>>> I would like to ask you to convert old LTMask instructions to use macroassembler as you did with new one. It is direction in which we move .ad files.
>>> 
>>> sparc.ad:
>>> Why do you need to specify default cost in cmpLTMask0()?
>>> +   ins_cost(DEFAULT_COST);
>>> 
>>> You don't need -XX:+UnlockDiagnosticVMOptions in the test command since you are not using diagnostic flags. CompileOnly is product flag:
>>> 
>>> src/share/vm/runtime/globals.hpp:  product(ccstrlist, CompileOnly, "",
>>> 
>>> 
>>> How different LTMask code in x86_32.ad and x86_64.ad? We have third x86.ad file which contains instructions which are the same for 32- and 64-bit. Note both files are use rRegI now.
>>> As separate changes (rfe) you can look if you can move LTMask (and other) instructions into x86.ad. One thing I notice is flag type name rFlagsReg vs eFlagsReg. You need to rename it to use rFlagsReg and move operand rFlagsReg() into x86.ad.
>>> 
>>> 
>>> Thanks,
>>> Vladimir
>>> 
>>> On 4/5/13 11:08 AM, David Chase wrote:
>>>> http://cr.openjdk.java.net/~drchase/6443505/webrev.01/
>>>> 
>>>> Suggestions incorporated, revised and whacked on the sparc and-cmpltmask pattern until it was (1) observed to fire and (2) did not interfere with add-and-cmpltmask.
>>>> 
>>>> I kept the branch-free variants in comments of x86, since these were also tested and seen to work.
>>>> 
>>>> Revised code seen to work correctly on Sparc and x86, and also passed JPRT targeted to the new unit test.
>>>> 
>>>> 
>>>> On 2013-04-01, at 2:01 PM, Christian Thalinger  wrote:
>>>> 
>>>>> 
>>>>> On Mar 28, 2013, at 4:37 PM, Vladimir Kozlov  wrote:
>>>>> 
>>>>>> "pipeline" info is not used in code generation, it is outdated anyway. So use what other similar instructions use.
>>>>>> 
>>>>>> I think we should use only branch variant on all x86 (32 and 64bit). We save register (tmp) and it is MUCH MUCH more important for performance (less spills on stack). And you need only 3 instructions for cadd_cmpLTMask.
>>>>> 
>>>>> I agree on this one.  -- Chris
>>>>> 
>>>>>> 
>>>>>> And, please, remove unneeded spaces near parenthesis, at least in new code.
>>>>>> 
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>> 
>>>>>> On 3/27/13 6:09 PM, David Chase wrote:
>>>>>>> Problem:
>>>>>>> (as stated)
>>>>>>> C2 needs a special case like CmpLTMask (turn result of a comparison into a -1/0 mask) for the comparison of a difference with zero.
>>>>>>> 
>>>>>>> (as actually observed)
>>>>>>> 1) The improvement in that case is minimal and (very) difficult to get to trigger, because CSE interferes and extracts the p-q from the pattern.
>>>>>>> 2) The original code generation for caddCmpLTMask on some platforms was actually wrong (used carry bit for a signed comparison)
>>>>>>> 3) The original Ideal pattern matching, because of a typo/thinko, accidentally failed to apply in the symmetric case
>>>>>>> 4) Code generation for CmpLTMask on all platforms omitted the somewhat relevant case of and-CmpLTMask; if the very specific pattern failed to apply, then it would fall back to the laborious calculation of an actual mask, when much more compact code could apply.
>>>>>>> 
>>>>>>> Fix:
>>>>>>> Repair wrong code generation.
>>>>>>> Write additional pattern for (and (cmpltmask p q) y)
>>>>>>> Fixed the typo so the pattern fires more often.
>>>>>>> 
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~drchase/6443505/webrev.00/
>>>>>>> 
>>>>>>> Testing:
>>>>>>> Wrote a new test to definitely exercise the two patterns in question.
>>>>>>> Verified that "new test" would fail running with unfixed compiler.
>>>>>>> 
>>>>>>> Verified (observing assembly output) that the new patterns matched on x86_32-cmov, x86_32+cmov, x86_64, and Sparc
>>>>>>> (except that I could not get the and-cmpltmask pattern to fire on Sparc.
>>>>>>> Bit of a shame we lack a cumulative coverage tool wired into jtreg so we could easily know if it ever fired at all).
>>>>>>> 
>>>>>>> Benchmarked change on x86_64 (saw little or no performance difference on the whole benchmark)
>>>>>>> 
>>>>>>> JPRT on compiler tests (clean runs thwarted by irrelevant failures, but it was always the same 2 or 3 borked tests.)
>>>>>>> 
>>>>>>> JPRT on just the new test (clean run)
>>>>>>> 
>>>>>>> Questions:
>>>>>>> not 100% sure on the pattern costs.
>>>>>>> not 100% sure on the choice of "pipeline".
>>>>>>> 
>>>>> 
>>>> 
>> 


From vladimir.kozlov at oracle.com  Thu Apr 11 08:29:15 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 11 Apr 2013 08:29:15 -0700
Subject: RFR (XS): 8011972: Field can be erroneously marked as contended
	when @Contended annotation isn't present
In-Reply-To: <516687D9.2070700@oracle.com>
References: <516687D9.2070700@oracle.com>
Message-ID: <5166D6CB.4000204@oracle.com>

VladimirI,

May be you should remove set_contended() method since I don't see other 
usage after you removed those lines.

Thanks,
VladimirK

On 4/11/13 2:52 AM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8011972/webrev.00
> 4 lines changed: 0 ins; 3 del; 1 mod
>
> If a field is marked with some annotation recognized by VM (but not
> @Contended), the field will be marked as contended anyway. It's because
> AnnotationCollector::set_contended(bool contended) ignores the parameter
> and always marks a field as contended.
>
> Moreover, calls to AnnotationCollector::set_contended in
> ClassFileParser::parse_annotations are redundant, because there's
> already a call right before:
> src/share/vm/classfile/classFileParser.cpp:
> 1714     coll->set_annotation(id);
>
> The problem hasn't manifested itself before, because @Contended is the
> only annotation on fields [1] VM recognizes. I hit it when working on a
> new annotation on fields for VM.
>
> Testing: manual (w/ additional annotation on fields),
> runtime/8003985/Test8003985.java
>
> Best regards,
> Vladimir Ivanov
>
> [1]
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/file/tip/src/share/vm/classfile/classFileParser.cpp
>
> ClassFileParser::AnnotationCollector::annotation_index

From vladimir.kozlov at oracle.com  Thu Apr 11 08:40:41 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 11 Apr 2013 08:40:41 -0700
Subject: RFR (M): 6443505: Ideal() function for CmpLTMask
In-Reply-To: <8E700E1C-ED14-42C2-8077-7BF7984C629E@oracle.com>
References: <32C62903-0EB1-4668-B66F-B94ED433AC30@oracle.com>
	<5154D446.5050708@oracle.com>
	<4E5D18DB-C9A6-4DAB-ADB4-E6890E4B4DD1@oracle.com>
	<2DE0B851-3A39-4027-9DFC-A19BF3C075C0@oracle.com>
	<516314D9.1080002@oracle.com>
	
	<516438BE.1080507@oracle.com>
	<8E700E1C-ED14-42C2-8077-7BF7984C629E@oracle.com>
Message-ID: <5166D979.40709@oracle.com>

Very good.

Thanks,
Vladimir

On 4/11/13 5:48 AM, David Chase wrote:
> http://cr.openjdk.java.net/~drchase/6443505/webrev.02/
>
> On 2013-04-09, at 11:50 AM, Vladimir Kozlov  wrote:
>
>> Leave only first lines commented to see matching and remove the rest:
>>
>>   /* If I enable this, I encourage spilling in the inner loop of compress.
>>   instruct cadd_cmpLTMask_mem( ncxRegI p, ncxRegI q, memory y, eCXRegI tmp, eFlagsReg cr ) %{
>>   match(Set p (AddI (AndI (CmpLTMask p q) (LoadI y)) (SubI p q)));
>>   */
>>
>> Vladimir
>>
>> On 4/9/13 5:10 AM, David Chase wrote:
>>> Any reason I should not delete:
>>>
>>>    enc_class enc_cmpLTP_mem(rRegI p, rRegI q, memory mem, eCXRegI tmp) %{    // cadd_cmpLT
>>>
>>> It's only called from a comment:
>>>
>>> /* If I enable this, I encourage spilling in the inner loop of compress.
>>> instruct cadd_cmpLTMask_mem(ncxRegI p, ncxRegI q, memory y, eCXRegI tmp, eFlagsReg cr) %{
>>>
>>> And the code that it generates is wrong.
>>> And it uses the pre-macro-assembler.
>>>
>>> David
>>>
>>>
>>> On 2013-04-08, at 3:04 PM, Vladimir Kozlov  wrote:
>>>
>>>> David,
>>>>
>>>> We already have several thousands lines in .ad files so I would prefer to remove unused code. You can leave the comment explaining why we use branches instead of cmoves.
>>>>
>>>> Please, remove next lines since we will have comment about that:
>>>> // always // predicate(!VM_Version::supports_cmov());
>>>>
>>>> I would like to ask you to convert old LTMask instructions to use macroassembler as you did with new one. It is direction in which we move .ad files.
>>>>
>>>> sparc.ad:
>>>> Why do you need to specify default cost in cmpLTMask0()?
>>>> +   ins_cost(DEFAULT_COST);
>>>>
>>>> You don't need -XX:+UnlockDiagnosticVMOptions in the test command since you are not using diagnostic flags. CompileOnly is product flag:
>>>>
>>>> src/share/vm/runtime/globals.hpp:  product(ccstrlist, CompileOnly, "",
>>>>
>>>>
>>>> How different LTMask code in x86_32.ad and x86_64.ad? We have third x86.ad file which contains instructions which are the same for 32- and 64-bit. Note both files are use rRegI now.
>>>> As separate changes (rfe) you can look if you can move LTMask (and other) instructions into x86.ad. One thing I notice is flag type name rFlagsReg vs eFlagsReg. You need to rename it to use rFlagsReg and move operand rFlagsReg() into x86.ad.
>>>>
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 4/5/13 11:08 AM, David Chase wrote:
>>>>> http://cr.openjdk.java.net/~drchase/6443505/webrev.01/
>>>>>
>>>>> Suggestions incorporated, revised and whacked on the sparc and-cmpltmask pattern until it was (1) observed to fire and (2) did not interfere with add-and-cmpltmask.
>>>>>
>>>>> I kept the branch-free variants in comments of x86, since these were also tested and seen to work.
>>>>>
>>>>> Revised code seen to work correctly on Sparc and x86, and also passed JPRT targeted to the new unit test.
>>>>>
>>>>>
>>>>> On 2013-04-01, at 2:01 PM, Christian Thalinger  wrote:
>>>>>
>>>>>>
>>>>>> On Mar 28, 2013, at 4:37 PM, Vladimir Kozlov  wrote:
>>>>>>
>>>>>>> "pipeline" info is not used in code generation, it is outdated anyway. So use what other similar instructions use.
>>>>>>>
>>>>>>> I think we should use only branch variant on all x86 (32 and 64bit). We save register (tmp) and it is MUCH MUCH more important for performance (less spills on stack). And you need only 3 instructions for cadd_cmpLTMask.
>>>>>>
>>>>>> I agree on this one.  -- Chris
>>>>>>
>>>>>>>
>>>>>>> And, please, remove unneeded spaces near parenthesis, at least in new code.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 3/27/13 6:09 PM, David Chase wrote:
>>>>>>>> Problem:
>>>>>>>> (as stated)
>>>>>>>> C2 needs a special case like CmpLTMask (turn result of a comparison into a -1/0 mask) for the comparison of a difference with zero.
>>>>>>>>
>>>>>>>> (as actually observed)
>>>>>>>> 1) The improvement in that case is minimal and (very) difficult to get to trigger, because CSE interferes and extracts the p-q from the pattern.
>>>>>>>> 2) The original code generation for caddCmpLTMask on some platforms was actually wrong (used carry bit for a signed comparison)
>>>>>>>> 3) The original Ideal pattern matching, because of a typo/thinko, accidentally failed to apply in the symmetric case
>>>>>>>> 4) Code generation for CmpLTMask on all platforms omitted the somewhat relevant case of and-CmpLTMask; if the very specific pattern failed to apply, then it would fall back to the laborious calculation of an actual mask, when much more compact code could apply.
>>>>>>>>
>>>>>>>> Fix:
>>>>>>>> Repair wrong code generation.
>>>>>>>> Write additional pattern for (and (cmpltmask p q) y)
>>>>>>>> Fixed the typo so the pattern fires more often.
>>>>>>>>
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~drchase/6443505/webrev.00/
>>>>>>>>
>>>>>>>> Testing:
>>>>>>>> Wrote a new test to definitely exercise the two patterns in question.
>>>>>>>> Verified that "new test" would fail running with unfixed compiler.
>>>>>>>>
>>>>>>>> Verified (observing assembly output) that the new patterns matched on x86_32-cmov, x86_32+cmov, x86_64, and Sparc
>>>>>>>> (except that I could not get the and-cmpltmask pattern to fire on Sparc.
>>>>>>>> Bit of a shame we lack a cumulative coverage tool wired into jtreg so we could easily know if it ever fired at all).
>>>>>>>>
>>>>>>>> Benchmarked change on x86_64 (saw little or no performance difference on the whole benchmark)
>>>>>>>>
>>>>>>>> JPRT on compiler tests (clean runs thwarted by irrelevant failures, but it was always the same 2 or 3 borked tests.)
>>>>>>>>
>>>>>>>> JPRT on just the new test (clean run)
>>>>>>>>
>>>>>>>> Questions:
>>>>>>>> not 100% sure on the pattern costs.
>>>>>>>> not 100% sure on the choice of "pipeline".
>>>>>>>>
>>>>>>
>>>>>
>>>
>

From vladimir.x.ivanov at oracle.com  Thu Apr 11 08:57:54 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 11 Apr 2013 19:57:54 +0400
Subject: RFR (XS): 8011972: Field can be erroneously marked as contended
	when @Contended annotation isn't present
In-Reply-To: <5166D6CB.4000204@oracle.com>
References: <516687D9.2070700@oracle.com> <5166D6CB.4000204@oracle.com>
Message-ID: <5166DD82.8010706@oracle.com>

Thanks for review, VladimirK.

I agree.

http://cr.openjdk.java.net/~vlivanov/8011972/webrev.01/

Best regards,
Vladimir Ivanov

On 4/11/13 7:29 PM, Vladimir Kozlov wrote:
> VladimirI,
>
> May be you should remove set_contended() method since I don't see other
> usage after you removed those lines.
>
> Thanks,
> VladimirK
>
> On 4/11/13 2:52 AM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8011972/webrev.00
>> 4 lines changed: 0 ins; 3 del; 1 mod
>>
>> If a field is marked with some annotation recognized by VM (but not
>> @Contended), the field will be marked as contended anyway. It's because
>> AnnotationCollector::set_contended(bool contended) ignores the parameter
>> and always marks a field as contended.
>>
>> Moreover, calls to AnnotationCollector::set_contended in
>> ClassFileParser::parse_annotations are redundant, because there's
>> already a call right before:
>> src/share/vm/classfile/classFileParser.cpp:
>> 1714     coll->set_annotation(id);
>>
>> The problem hasn't manifested itself before, because @Contended is the
>> only annotation on fields [1] VM recognizes. I hit it when working on a
>> new annotation on fields for VM.
>>
>> Testing: manual (w/ additional annotation on fields),
>> runtime/8003985/Test8003985.java
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> [1]
>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/file/tip/src/share/vm/classfile/classFileParser.cpp
>>
>>
>> ClassFileParser::AnnotationCollector::annotation_index

From vladimir.kozlov at oracle.com  Thu Apr 11 09:00:26 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 11 Apr 2013 09:00:26 -0700
Subject: RFR (XS): 8011972: Field can be erroneously marked as contended
	when @Contended annotation isn't present
In-Reply-To: <5166DD82.8010706@oracle.com>
References: <516687D9.2070700@oracle.com> <5166D6CB.4000204@oracle.com>
	<5166DD82.8010706@oracle.com>
Message-ID: <5166DE1A.8060103@oracle.com>

Good.

Thanks,
Vladimir

On 4/11/13 8:57 AM, Vladimir Ivanov wrote:
> Thanks for review, VladimirK.
>
> I agree.
>
> http://cr.openjdk.java.net/~vlivanov/8011972/webrev.01/
>
> Best regards,
> Vladimir Ivanov
>
> On 4/11/13 7:29 PM, Vladimir Kozlov wrote:
>> VladimirI,
>>
>> May be you should remove set_contended() method since I don't see other
>> usage after you removed those lines.
>>
>> Thanks,
>> VladimirK
>>
>> On 4/11/13 2:52 AM, Vladimir Ivanov wrote:
>>> http://cr.openjdk.java.net/~vlivanov/8011972/webrev.00
>>> 4 lines changed: 0 ins; 3 del; 1 mod
>>>
>>> If a field is marked with some annotation recognized by VM (but not
>>> @Contended), the field will be marked as contended anyway. It's because
>>> AnnotationCollector::set_contended(bool contended) ignores the parameter
>>> and always marks a field as contended.
>>>
>>> Moreover, calls to AnnotationCollector::set_contended in
>>> ClassFileParser::parse_annotations are redundant, because there's
>>> already a call right before:
>>> src/share/vm/classfile/classFileParser.cpp:
>>> 1714     coll->set_annotation(id);
>>>
>>> The problem hasn't manifested itself before, because @Contended is the
>>> only annotation on fields [1] VM recognizes. I hit it when working on a
>>> new annotation on fields for VM.
>>>
>>> Testing: manual (w/ additional annotation on fields),
>>> runtime/8003985/Test8003985.java
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> [1]
>>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/file/tip/src/share/vm/classfile/classFileParser.cpp
>>>
>>>
>>>
>>> ClassFileParser::AnnotationCollector::annotation_index

From krystal.mo at oracle.com  Thu Apr 11 09:04:03 2013
From: krystal.mo at oracle.com (Krystal Mo)
Date: Thu, 11 Apr 2013 09:04:03 -0700
Subject: RFR (XS): 8011972: Field can be erroneously marked as contended
	when @Contended annotation isn't present
In-Reply-To: <5166DD82.8010706@oracle.com>
References: <516687D9.2070700@oracle.com> <5166D6CB.4000204@oracle.com>
	<5166DD82.8010706@oracle.com>
Message-ID: <5166DEF3.5040302@oracle.com>

Still looks good.

Thanks,
Kris

On 04/11/2013 08:57 AM, Vladimir Ivanov wrote:
> Thanks for review, VladimirK.
>
> I agree.
>
> http://cr.openjdk.java.net/~vlivanov/8011972/webrev.01/
>
> Best regards,
> Vladimir Ivanov
>
> On 4/11/13 7:29 PM, Vladimir Kozlov wrote:
>> VladimirI,
>>
>> May be you should remove set_contended() method since I don't see other
>> usage after you removed those lines.
>>
>> Thanks,
>> VladimirK
>>
>> On 4/11/13 2:52 AM, Vladimir Ivanov wrote:
>>> http://cr.openjdk.java.net/~vlivanov/8011972/webrev.00
>>> 4 lines changed: 0 ins; 3 del; 1 mod
>>>
>>> If a field is marked with some annotation recognized by VM (but not
>>> @Contended), the field will be marked as contended anyway. It's because
>>> AnnotationCollector::set_contended(bool contended) ignores the 
>>> parameter
>>> and always marks a field as contended.
>>>
>>> Moreover, calls to AnnotationCollector::set_contended in
>>> ClassFileParser::parse_annotations are redundant, because there's
>>> already a call right before:
>>> src/share/vm/classfile/classFileParser.cpp:
>>> 1714     coll->set_annotation(id);
>>>
>>> The problem hasn't manifested itself before, because @Contended is the
>>> only annotation on fields [1] VM recognizes. I hit it when working on a
>>> new annotation on fields for VM.
>>>
>>> Testing: manual (w/ additional annotation on fields),
>>> runtime/8003985/Test8003985.java
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> [1]
>>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/file/tip/src/share/vm/classfile/classFileParser.cpp 
>>>
>>>
>>>
>>> ClassFileParser::AnnotationCollector::annotation_index


From krystal.mo at oracle.com  Thu Apr 11 11:34:19 2013
From: krystal.mo at oracle.com (krystal.mo at oracle.com)
Date: Thu, 11 Apr 2013 18:34:19 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 8011952: Missing ResourceMarks in
	TraceMethodHandles
Message-ID: <20130411183423.ECA5F48212@hg.openjdk.java.net>

Changeset: d79859ff6535
Author:    kmo
Date:      2013-04-11 07:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d79859ff6535

8011952: Missing ResourceMarks in TraceMethodHandles
Summary: add missing ResourceMark under TraceMethodHandles in LinkResolver
Reviewed-by: dholmes

! src/share/vm/interpreter/linkResolver.cpp


From ionionascu at gmail.com  Thu Apr 11 13:39:00 2013
From: ionionascu at gmail.com (Ion Ionascu)
Date: Thu, 11 Apr 2013 21:39:00 +0100
Subject: Does the JVM ever re-compiles compiled code?
Message-ID: 

Hi,


I hope this is the right mailing list to ask this question.

Could you please tell me if the JVM ever re-compiles already compiled
bytecode? And, is the compiled code ever brought back to a state where it
is just interpreted?

I am curious about re-compilation because the server compiler is set by
default to compile code after 10000 accesses in order to statistically
guarantee that enough information has been gathered to do the best
optimisations. But, does the JVM continue to track code usage after it is
compiled?


Thank you,
Ion Ionascu

www.ionionascu.eu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130411/e366f14e/attachment.html 

From goetz.lindenmaier at sap.com  Thu Apr 11 14:46:32 2013
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 11 Apr 2013 21:46:32 +0000
Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp
	stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp
	stub.]
In-Reply-To: <7D07437F-CFF7-4298-B9A1-DE9F2E32D77D@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC0CFA7D32@DEWDFEMB12A.global.corp.sap>
	<03C4DFDE-CD52-446E-92AA-A6F12903FE29@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB116E@DEWDFEMB12A.global.corp.sap>
	<7D07437F-CFF7-4298-B9A1-DE9F2E32D77D@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC0CFB1EDE@DEWDFEMB12A.global.corp.sap>

Hi all,

I prepared the webrev for the changes discussed below:
http://cr.openjdk.java.net/~goetz/webrevs/8003853/

To fix the issues we have with the PPC port with finding ICs, this change 
cleans up the code handling compiled static Java calls:
 - Methods using native instructions are moved from compiledIC.cpp
   to compiledIC_.cpp.
 - Methods emitting the call patched by CompiledStaticCall are
   moved from the ad file to this class.
   As a side effect this reduces redundancies in x86_64.ad and x86_32.ad.
 - We get rid of extern declarations in output.cpp.

Now all code concerning CompiledStaticCalls is collected in one class.
The PPC port needs not change shared code any more to implement them.
I also got around to move code to MacroAssembler, as only a simple call 
was needed on x86 and sparc.

Probably this is (M) now, no more (S).

Please review and send comments.  I'll be happy to adapt to them!

Best regards,
  Goetz Lindenmaier

-----Original Message-----
From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
Sent: Thursday, April 11, 2013 4:50 AM
To: Lindenmaier, Goetz
Cc: 'hotspot-compiler-dev at openjdk.java.net'
Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]


On Apr 9, 2013, at 7:35 AM, "Lindenmaier, Goetz"  wrote:

> Hi Chris, 
> 
> I'm now working on this issue.  Sorry for the delay...
> 
> What do you think about moving 
>    void emit_java_to_interp(CodeBuffer& cbuf);
> and
>   void size_java_to_interp();
> to compiledIC.hpp and the new platform file, too?

I like that.

> 
> This would also allow to overcome the ugly 
>   extern uint size_java_to_interp();
> in output.cpp, as it could be replaced by CompiledStaticCall::size_java_to_interp().

Great.

> 
> I also would like to name this
>  CompiledStaticCall::emit_to_interp_stub()
>  CompiledStaticCall::to_interp_stub_size()

I'm okay with that.  Not sure if others have objections.

> 
> I could also extract code from enc_class Java_Static_Call 
> to form a routine
>  CompiledStaticCall::emit_call(CodeBuffer *cbuf, intptr_t entry_point, relocInfo::relocType rtype) {
>    emit_call_reloc(cbuf, entry_point, rtype)
>    if (rtype != relocInfo::runtime_call_type) {
>        emit_java_to_interp(cbuf);
>      }
>  }
> With this, also 
>  extern uint reloc_java_to_interp();
> from output.cpp could be moved into this class.

On SPARC only or the other architectures as well?

> 
> Then handling of CompiledStaticCalls would be completely implemented in this
> one class.

That's tempting.

> 
> (I would have to move emit_call_reloc to MacroAssembler.)

Could you send a webrev with these changes?

-- Chris

> 
> Best regards,
>  Goetz.
> 
> 
> 
> -----Original Message-----
> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
> Sent: Montag, 25. M?rz 2013 23:29
> To: Lindenmaier, Goetz
> Cc: 'hotspot-compiler-dev at openjdk.java.net'
> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
> 
> 
> On Mar 4, 2013, at 8:34 AM, "Lindenmaier, Goetz"  wrote:
> 
>> Hi Chris, 
>> 
>> I would like to take up this issue again. 
>> I'm about to put our changes on the jdk8 branch, and it would be convenient
>> to have a final solution for this.
>> 
>> Should I prepare a webrev with a different solution adding a new file
>> for this?  What should go into that file? 
> 
> Sorry for answering that late.
> 
> Yes, to see a patch for that would be good.  We need to put all platform dependent Compiled* methods in that new file.  Platform dependent means every method that uses a native* method from nativeInst_:
> 
> CompiledIC::cleanup_call_site
> CompiledIC::is_icholder_call_site
> CompiledIC::CompiledIC
> 
> CompiledStaticCall::set_to_interpreted
> CompiledStaticCall::set_stub_to_clean
> CompiledStaticCall::verify
> 
> -- Chris
> 
>> 
>> Best regards,
>> Goetz.
>> 
>> 
>> 
>> -----Original Message-----
>> From: goetz.lindenmaier at sap.com 
>> Sent: Dienstag, 18. Dezember 2012 10:42
>> To: 'Christian Thalinger'
>> Subject: RE: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>> 
>> Hi Chris, 
>> 
>> What would you put into that file?  The offset, or the class CompiledStaticCall?
>> You could also put it into nativeInst_  to avoid adding another file.
>> 
>> But basically I think the offset is the best solution, because it's very small
>> and straight forward, and the offset is set where the code is generated 
>> that defines the offset.
>> 
>> Only the #ifndef COMPILER2 is ugly, but here I think the solution is to 
>> guard the whole class CompiledStaticCall with #ifdef COMPILER2.
>> 
>> But I'm happy with any placement of the code.
>> 
>> Best regards,
>> Goetz.
>> 
>> 
>> 
>> -----Original Message-----
>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>> Sent: Montag, 17. Dezember 2012 21:34
>> To: Lindenmaier, Goetz
>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>> 
>> 
>> On Nov 29, 2012, at 2:10 PM, "Lindenmaier, Goetz"  wrote:
>> 
>>> Hi Chris, 
>>> 
>>> Loading the constant takes 5 instructions, the other way only three,
>>> in the code only one, if the constant pool base is in a register.
>>> The 5 instructions are hard to patch atomically.  The constant pool 
>>> is just a 64 bit store.  
>>> 
>>>> Sorry for being so persistent on this :-)  
>>> That's ok, I already found several places in our VM where it was easy to 
>>> change our code to get along without the shared changes we did in 
>>> first place.  But I can't redesign everything, and I can not risk to break
>>> anything in our product.
>>> 
>>> If you feel like doing so, you can have a look at 
>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/600ce596eea9
>>> which contains our bytecode interpreter profiling implementation.
>>> If you think this is currently of use in the main branch, I would lift it to HS25 
>>> (the permgen changes might cause trouble) and contribute it to hsx.
>> 
>> Sorry for the long delay.
>> 
>> Thinking about this problem again it seems that the correct solution would be to have a compiledIC_.cpp file.
>> 
>> The CompiledIC instruction layout is platform dependent; it just happens to be the same for all architectures we have right now (well, except PPC) because we made it to be the same.  Actually on SPARC we could also use a load from the constant table which would be simpler.
>> 
>> Having a platform dependent file for this code feels right.  What do you think?
>> 
>> -- Chris
>> 
>>> 
>>> Best regards,
>>> Goetz.
>>> 
>>> -----Original Message-----
>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>> Sent: Thursday, November 29, 2012 7:53 PM
>>> To: Lindenmaier, Goetz
>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>> 
>>> 
>>> On Nov 29, 2012, at 12:27 AM, "Lindenmaier, Goetz"  wrote:
>>> 
>>>> Hi Chris, 
>>>> 
>>>>> Why can't you point the relocation to the method load instruction?  It doesn't seem right to do that in shared code.
>>>> Because the relocation is used 
>>>> 1.) to find the beginning of the stub to patch the call to go there 
>>>> 2.) to find the load to patch the IC.
>>> 
>>> Got it.
>>> 
>>>> 
>>>> Just have a look at CompiledStaticCall::set_to_interpreted(),
>>>> the variable 'stub' is used twice.  
>>> 
>>> Sorry for being so persistent on this :-)  What is the reason you have to load the constant from the constant table?  On other architectures we materialize the constant.
>>> 
>>> -- Chris
>>> 
>>>> 
>>>> Best regards, 
>>>> Goetz.
>>>> 
>>>> -----Original Message-----
>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>> Sent: Donnerstag, 29. November 2012 01:35
>>>> To: Lindenmaier, Goetz
>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>> 
>>>> 
>>>> On Nov 27, 2012, at 4:24 AM, "Lindenmaier, Goetz"  wrote:
>>>> 
>>>>> Hi Chris,
>>>>> 
>>>>>> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub?
>>>>> Shared code (class CompiledStaticCall) wants to patch the inline cache 
>>>>> in the stub which is emitted in platform code.
>>>>> So the platform code should specify how the shared code can find the inline cache 
>>>>> in the stub, which it does through the constant I introduced.
>>>>> 
>>>>>> Do you need two relocations?  I'm confused.
>>>>> No, three ;)
>>>>> The relocation you mention is used to find the stub given the call.
>>>>> The other relocations are needed to find the inline cache / call target
>>>>> once the stub is found (see CompiledStaticCall::set_to_interpreted()).
>>>>> It's just the same on x86_64:
>>>>> 
>>>>> // static stub relocation stores the instruction address of the call
>>>>> __ relocate(static_stub_Relocation::spec(mark), RELOC_IMM64); 
>>>>> // static stub relocation also tags the methodOop in the code-stream.
>>>>> __ movoop(rbx, (jobject) NULL);  // method is zapped till fixup time
>>>>> // This is recognized as unresolved by relocs/nativeinst/ic code
>>>>> __ jump(RuntimeAddress(__ pc()));
>>>>> 
>>>>> On PPC, we have to load the base of the constant table after generating the 
>>>>> static_stub_relocation and before emitting the ppc equivalent for moveoop(). This offset is 
>>>>> exactly what we store in the  CompiledStaticCall::comp_to_int_load_offset constant.
>>>> 
>>>> Why can't you point the relocation to the method load instruction?  It doesn't seem right to do that in shared code.
>>>> 
>>>> -- Chris
>>>> 
>>>>> 
>>>>> Best regards,
>>>>> Goetz.
>>>>> 
>>>>> 
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>> Sent: Dienstag, 27. November 2012 01:53
>>>>> To: Lindenmaier, Goetz
>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>> 
>>>>> 
>>>>> On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz"  wrote:
>>>>> 
>>>>>> Hi Chris,
>>>>>> 
>>>>>> We put it into the ad file because it describes an offset into the stub that is
>>>>>> generated from the ad file by emit_java_to_interp(CodeBuffer& cbuf), 
>>>>>> used by ir  node CallStaticJavaDirect.  Maybe I should not call it stub, but it's 
>>>>>> generated into the stubs section of the code buffer.
>>>>>> If that stub generator is moved out of the ad file to shared compiler code, one should
>>>>>> move the field with it, but for the current implementation I think that's fine.
>>>>>> 
>>>>>> Does C1 generate the same stub? Or is the CompiledStaticCall a C2 feature?
>>>>>> If so, one could protect the whole thing by #ifdef COMPILER2.
>>>>> 
>>>>> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub?
>>>>> 
>>>>> // Create a static stub relocation which relates this stub
>>>>> // with the call instruction at insts_call_instruction_offset in the
>>>>> // instructions code-section.
>>>>> __ relocate(static_stub_Relocation::spec(__ code()->insts()->start() + insts_relocation_offset));
>>>>> 
>>>>> Do you need two relocations?  I'm confused.
>>>>> 
>>>>> -- Chris
>>>>> 
>>>>>> 
>>>>>> Thanks for all the bugids!
>>>>>> 
>>>>>> Best regards,
>>>>>> Goetz.
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>>> Sent: Mittwoch, 21. November 2012 19:53
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>> Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>>> 
>>>>>> 
>>>>>> On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz"  wrote:
>>>>>> 
>>>>>>> Hi Chris, 
>>>>>>> 
>>>>>>> yes, there is no C1 on ppc.  
>>>>>>> We do tiered compilation with a stripped C2.
>>>>>> 
>>>>>> Right.  But some other architecture (or in the future) might need this for C1 as well.  We should find a better place for the value than the ad file.  The obvious place would be compiledIC_.hpp but we don't have that file, yet.
>>>>>> 
>>>>>> I filed:
>>>>>> 
>>>>>> 8003853: specify offset of IC load in java_to_interp stub
>>>>>> 
>>>>>> -- Chris
>>>>>> 
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> Goetz
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>>>> Sent: Dienstag, 20. November 2012 22:19
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>> Subject: Re: RFR (S): Specify offset of IC load in java_to_interp stub.
>>>>>>> 
>>>>>>> 
>>>>>>> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz"  wrote:
>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub
>>>>>>>> to update the IC  with NativeMovConstReg.  The current implementation assumes that
>>>>>>>> the load is always the first instruction in the stub.  This is an artificial restriction. E.g.,
>>>>>>>> it might be useful to load the constant pool address (MachConstantBase) before the
>>>>>>>> IC load (as we do on PPC).
>>>>>>>> 
>>>>>>>> This change adds a constant specifying an offset from the beginning of the stub to
>>>>>>>> the  IC load. The offset is platform specific and 0 on sparc and x86.
>>>>>>>> 
>>>>>>>> You can find the change here:
>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/
>>>>>>> 
>>>>>>> That should be fixed indeed.  
>>>>>>> 
>>>>>>> +#ifndef COMPILER2
>>>>>>> +const int CompiledStaticCall::comp_to_int_load_offset = 0;
>>>>>>> 
>>>>>>> There is no C1 for PPC (sorry, I didn't check)?
>>>>>>> 
>>>>>>> -- Chris
>>>>>>> 
>>>>>>>> 
>>>>>>>> or in our ppc port:
>>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33
>>>>>>>> 
>>>>>>>> Thank you and best regards,
>>>>>>>> Goetz
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


From forax at univ-mlv.fr  Thu Apr 11 15:00:25 2013
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 12 Apr 2013 00:00:25 +0200
Subject: Does the JVM ever re-compiles compiled code?
In-Reply-To: 
References: 
Message-ID: <51673279.50003@univ-mlv.fr>

On 04/11/2013 10:39 PM, Ion Ionascu wrote:
> Hi,
>
>
> I hope this is the right mailing list to ask this question.
>
> Could you please tell me if the JVM ever re-compiles already compiled 
> bytecode?

yes, in two cases, if an optimistic assumption (like a branch of a if 
was never taken,
a value is never null, etc) is broken or if the JVM is configured in 
tiered mode,
in that case the JVM JIT the code once with the client compiler (c1) and
also add probes in the compiled code to still profile the application.

> And, is the compiled code ever brought back to a state where it is 
> just interpreted?

yes, it's the normal mode, not in tiered compilation, in that case,
if an assumption is broken, the VM deoptimize the code i.e.
mark the JITed code as should not be used anymore and jum
from the compiled code to the interpreter, that will re-profile the 
application
and if hot re-JIT the code.

>
> I am curious about re-compilation because the server compiler is set 
> by default to compile code after 10000 accesses in order to 
> statistically guarantee that enough information has been gathered to 
> do the best optimisations. But, does the JVM continue to track code 
> usage after it is compiled?

no, not by default.

>
>
> Thank you,
> Ion Ionascu
>
> www.ionionascu.eu 

cheers,
R?mi


From vladimir.x.ivanov at oracle.com  Thu Apr 11 17:08:12 2013
From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com)
Date: Fri, 12 Apr 2013 00:08:12 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets
Message-ID: <20130412000816.D6D514822C@hg.openjdk.java.net>

Changeset: 9befe2fce567
Author:    vlivanov
Date:      2013-04-11 09:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9befe2fce567

8011972: Field can be erroneously marked as contended when @Contended annotation isn't present
Reviewed-by: kvn, kmo, shade

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp

Changeset: b5db9d29062f
Author:    vlivanov
Date:      2013-04-11 11:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b5db9d29062f

Merge



From john.coomes at oracle.com  Thu Apr 11 20:44:31 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 12 Apr 2013 03:44:31 +0000
Subject: hg: hsx/hotspot-comp: 9 new changesets
Message-ID: <20130412034431.9712648242@hg.openjdk.java.net>

Changeset: 52d1b385a4ed
Author:    erikj
Date:      2013-04-04 09:24 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/52d1b385a4ed

8006828: "SKIP_BOOT_CYCLE=false" must work in new building infrastructure
Reviewed-by: tbell, alanb

! common/autoconf/bootcycle-spec.gmk.in
! common/autoconf/spec.gmk.in
! common/makefiles/Jprt.gmk
! common/makefiles/Main.gmk

Changeset: 2d4156e077fa
Author:    erikj
Date:      2013-04-04 09:25 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/2d4156e077fa

8011372: Remove -p from cp in IdleCompilation.gmk
Reviewed-by: pliden, tbell

! common/makefiles/IdlCompilation.gmk

Changeset: 3b8ffb80db0f
Author:    erikj
Date:      2013-04-05 09:38 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/3b8ffb80db0f

8008373: JFR JTReg tests fail with CompilationError on MacOSX; missing '._sunec.jar'
Reviewed-by: tbell

! common/autoconf/basics.m4
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/makefiles/MakeBase.gmk

Changeset: 653ff6bcf0b1
Author:    omajid
Date:      2013-04-08 14:07 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/653ff6bcf0b1

8011388: Support building zero and zeroshark with the new build
Reviewed-by: andrew, dholmes, erikj
Contributed-by: Omair Majid , Roman Kennke 

! common/autoconf/generated-configure.sh
! common/autoconf/hotspot-spec.gmk.in
! common/autoconf/jdk-options.m4
! common/autoconf/libraries.m4
! common/autoconf/platform.m4
! common/autoconf/spec.gmk.in

Changeset: 2f43964043c2
Author:    erikj
Date:      2013-04-09 09:42 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/2f43964043c2

8006288: build-infra: Use solaris nm and not gnm on solaris
Reviewed-by: tbell

! common/autoconf/compare.sh.in
! common/autoconf/generated-configure.sh
! common/autoconf/spec.gmk.in
! common/autoconf/toolchain.m4

Changeset: 2ef28c12d649
Author:    erikj
Date:      2013-04-09 09:45 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/2ef28c12d649

8010465: Can't enable sjavac when building in jprt.
Reviewed-by: ohair, tbell

! common/makefiles/JavaCompilation.gmk
! common/makefiles/Jprt.gmk
! common/makefiles/MakeBase.gmk
! common/makefiles/MakeHelpers.gmk

Changeset: a09e9c9ca963
Author:    tbell
Date:      2013-04-09 13:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/a09e9c9ca963

8011348: use of which in common/autoconf/autogen.sh is not portable
Reviewed-by: erikj, katleman, mduigou

! common/autoconf/autogen.sh

Changeset: 7fc358f59436
Author:    katleman
Date:      2013-04-09 15:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/7fc358f59436

Merge


Changeset: 44bc9bc4da4d
Author:    katleman
Date:      2013-04-11 09:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/44bc9bc4da4d

Added tag jdk8-b85 for changeset 7fc358f59436

! .hgtags


From john.coomes at oracle.com  Thu Apr 11 20:44:35 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 12 Apr 2013 03:44:35 +0000
Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b85 for changeset
	9583a6431596
Message-ID: <20130412034438.59AB348243@hg.openjdk.java.net>

Changeset: 44a8ce4a759f
Author:    katleman
Date:      2013-04-11 09:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/44a8ce4a759f

Added tag jdk8-b85 for changeset 9583a6431596

! .hgtags


From john.coomes at oracle.com  Thu Apr 11 20:44:43 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 12 Apr 2013 03:44:43 +0000
Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b85 for changeset
	41b50e2c5ea3
Message-ID: <20130412034452.781B548244@hg.openjdk.java.net>

Changeset: ca71ec37b2ef
Author:    katleman
Date:      2013-04-11 09:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/ca71ec37b2ef

Added tag jdk8-b85 for changeset 41b50e2c5ea3

! .hgtags


From john.coomes at oracle.com  Thu Apr 11 20:44:58 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 12 Apr 2013 03:44:58 +0000
Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b85 for changeset
	8c0b6bccfe47
Message-ID: <20130412034503.CC68C48245@hg.openjdk.java.net>

Changeset: 26c840af7720
Author:    katleman
Date:      2013-04-11 09:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/26c840af7720

Added tag jdk8-b85 for changeset 8c0b6bccfe47

! .hgtags


From john.coomes at oracle.com  Thu Apr 11 20:45:14 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 12 Apr 2013 03:45:14 +0000
Subject: hg: hsx/hotspot-comp/jdk: 4 new changesets
Message-ID: <20130412034659.38B3948246@hg.openjdk.java.net>

Changeset: e22961ea91bd
Author:    erikj
Date:      2013-04-05 09:39 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e22961ea91bd

8008373: JFR JTReg tests fail with CompilationError on MacOSX; missing '._sunec.jar'
Reviewed-by: tbell

! makefiles/CompileDemos.gmk
! makefiles/CompileJavaClasses.gmk
! makefiles/CompileLaunchers.gmk
! makefiles/CompileNativeLibraries.gmk
! makefiles/CopyFiles.gmk
! makefiles/CopyIntoClasses.gmk
! makefiles/CopySamples.gmk
! makefiles/GendataFontConfig.gmk
! makefiles/GensrcCharacterData.gmk
! makefiles/GensrcMisc.gmk
! makefiles/GensrcSwing.gmk
! makefiles/SignJars.gmk
! makefiles/Tools.gmk

Changeset: fddd158b872a
Author:    omajid
Date:      2013-04-08 14:09 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fddd158b872a

8011388: Support building zero and zeroshark with the new build
Reviewed-by: andrew, dholmes, erikj
Contributed-by: Omair Majid , Roman Kennke 

! makefiles/Profiles.gmk

Changeset: 296676d534c5
Author:    katleman
Date:      2013-04-09 15:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/296676d534c5

Merge


Changeset: 081327aac5be
Author:    katleman
Date:      2013-04-11 09:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/081327aac5be

Added tag jdk8-b85 for changeset 296676d534c5

! .hgtags


From john.coomes at oracle.com  Thu Apr 11 20:49:32 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 12 Apr 2013 03:49:32 +0000
Subject: hg: hsx/hotspot-comp/langtools: Added tag jdk8-b85 for changeset
	4a48f3173534
Message-ID: <20130412034945.F0E2F48247@hg.openjdk.java.net>

Changeset: 2c9acb17f41a
Author:    katleman
Date:      2013-04-11 09:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/2c9acb17f41a

Added tag jdk8-b85 for changeset 4a48f3173534

! .hgtags


From john.coomes at oracle.com  Thu Apr 11 20:49:51 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 12 Apr 2013 03:49:51 +0000
Subject: hg: hsx/hotspot-comp/nashorn: Added tag jdk8-b85 for changeset
	e0378f0a50da
Message-ID: <20130412034953.D316948248@hg.openjdk.java.net>

Changeset: aed0529f5f5d
Author:    katleman
Date:      2013-04-11 09:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/aed0529f5f5d

Added tag jdk8-b85 for changeset e0378f0a50da

! .hgtags


From krystal.mo at oracle.com  Thu Apr 11 22:40:32 2013
From: krystal.mo at oracle.com (Krystal Mo)
Date: Thu, 11 Apr 2013 22:40:32 -0700
Subject: Does the JVM ever re-compiles compiled code?
In-Reply-To: 
References: 
Message-ID: <51679E50.8070803@oracle.com>

Hi Ion,

Remi has explained it quite nicely. I'll just add a few points.

On 04/11/2013 01:39 PM, Ion Ionascu wrote:
> Hi,
>
>
> I hope this is the right mailing list to ask this question.
>
Yes, it is if you're looking for HotSpot VM specific information. 
HotSpot VM is just one implementation of the JVM spec, and there are 
other vendors that may take a different approach than we do.

> Could you please tell me if the JVM ever re-compiles already compiled 
> bytecode?

Yes, just as Remi said in his reply. HotSpot's JIT compilers can make 
aggressive assumptions of the program and optimize accordingly, e.g. 
Class Hierarchy Analysis, implicit null-pointer checking, etc. When 
those assumptions are broken after a method has been JIT compiled, then 
the compiled code will be thrown away, and execution in the compiled 
code will be "deoptimized" to run in (1) the interpreter in non-tiered 
mode; (2) maybe in lower tier code in tiered mode.

You can confirm that by specifying the -XX:+PrintCompilation VM flag, 
and watch for messages like "made not entrant". That's the sign of 
deoptimization happening.

> And, is the compiled code ever brought back to a state where it is 
> just interpreted?
>
Yes. An interesting example you might not have guessed is that even in 
-Xcomp mode, HotSpot may run a lot of code in the interpreter. That's 
because C2 (HotSpot server compiler) doesn't (and can't) load Java 
classes, and doesn't generate code to load Java classes; so if it sees a 
Java class that is not yet loaded in a method when that method is being 
compiled, then C2 generates an uncommon trap there. When the uncommon 
trap is hit, it'll deoptimize and go back into the interpreter to load 
the class. And then this method may be compiled again later.

> I am curious about re-compilation because the server compiler is set 
> by default to compile code after 10000 accesses in order to 
> statistically guarantee that enough information has been gathered to 
> do the best optimisations. But, does the JVM continue to track code 
> usage after it is compiled?
>
Right now in HotSpot, no. HotSpot instruments the interpreter (and lower 
tier compiled code in tiered mode) with counters to trigger compilation. 
C2 compiled code don't have such counters. And HotSpot doesn't do 
sampling-based profiling that feeds into the JITs now.

Other JVM vendors may take tradeoffs differently, though.

- Kris

>
> Thank you,
> Ion Ionascu
>
> www.ionionascu.eu 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130411/4c08e11f/attachment.html 

From yumin.qi at oracle.com  Thu Apr 11 23:12:04 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Thu, 11 Apr 2013 23:12:04 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
Message-ID: <5167A5B4.4060100@oracle.com>

Hi,

   Can I have your inputs for the fix?
   webrev:

  http://cr.openjdk.java.net/~minqi/8010992/webrev/  

   Bug:  8010992: Remove calls to global ::operator new[] and new
https://jbs.oracle.com/bugs/browse/JDK-8010992

Problem description:  Remove the usage of global operator ::new[] and 
::new. In hotspot debug build, disable the usage of global new[] and 
new.  Hotspot does not throw c++ exceptions, but it cannot prevent third 
party code to catch such exceptions.  By disabling use of global 
operator new[] and new, we constrain the exception disposal within 
hotspot. C++ classes (as same for structs) in hotspot have to either 
extends from CHeapObj or ResourceObj unless they are stack objects or 
values which have to be from StackObj or _ValueObj respectively.  Or 
they have to implement their own operator new[] or new.

Thanks
Yumin



From david.holmes at oracle.com  Fri Apr 12 01:46:52 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 Apr 2013 18:46:52 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <5167A5B4.4060100@oracle.com>
References: <5167A5B4.4060100@oracle.com>
Message-ID: <5167C9FC.5000902@oracle.com>

Hi Yumin,

This looks pretty good.

On 12/04/2013 4:12 PM, Yumin Qi wrote:
>    Can I have your inputs for the fix?
>    webrev:
>
>   http://cr.openjdk.java.net/~minqi/8010992/webrev/
> 

src/share/vm/classfile/altHashing.cpp

Can these be directly stack-allocated arrays instead of C-Heap ?

---

allocation.cpp

672 // %% note this is causing a problem on solaris debug build. the global
673 // new is being called from jdk source and causing data corruption.
674 // 
src/share/native/sun/awt/font/fontmanager/textcache/hsMemory.cpp::hsSoftNew

Is this still an issue?

As a general comment do we need all the operator new[] additions?

---

allocation.inline.hpp

Can we reduce code duplication by changing, eg:

#ifdef ASSERT
     void* p = (void*)AllocateHeap(size, F, (caller_pc != 0 ? caller_pc 
: CALLER_PC));
     if (PrintMallocFree) trace_heap_malloc(size, "CHeapObj-new", p);
     return p;
#else
     return (void *) AllocateHeap(size, F, (caller_pc != 0 ? caller_pc : 
CALLER_PC));
#endif

to

     void* p = (void*)AllocateHeap(size, F, (caller_pc != 0 ? caller_pc 
: CALLER_PC));
#ifdef ASSERT
     if (PrintMallocFree) trace_heap_malloc(size, "CHeapObj-new", p);
#endif
     return p;

---

src/share/vm/memory/cardTableModRefBS.cpp

86   for (i = 0; i < max_covered_regions; i++) {
87     _covered[i].set_start(NULL)  ; _covered[i].set_word_size(0)  ;
88     _committed[i].set_start(NULL); _committed[i].set_word_size(0);
89   }

this appears to be a semantic change, which leads me to ask:

Given "new MemRegion[1]" vs NEW_C_HEAP_ARRAY(...,1,...) what are the 
array contents initialized to in each case?

---

src/share/vm/memory/cardTableRS.cpp

   68 CardTableRS::~CardTableRS() {
   69   if (_last_cur_val_in_gen) {
   70     // FREE_C_HEAP_ARRAY(jbyte, _last_cur_val_in_gen, mtInternal);
   71   }
   72 }

Was this an existing memory leak? I'm noticing that most uses of "new 
X[n]" don't have a corresponding delete!

But why is this commented out?

---

src/share/vm/runtime/handles.hpp

initialize_thread shouldn't need to be public. What is calling it?

---

src/share/vm/runtime/thread.cpp

These changes don't look right - why doesn't HandleMark extend one of 
the allocation base classes ?


Thanks,
David
-----

>    Bug:  8010992: Remove calls to global ::operator new[] and new
> https://jbs.oracle.com/bugs/browse/JDK-8010992
>
> Problem description:  Remove the usage of global operator ::new[] and
> ::new. In hotspot debug build, disable the usage of global new[] and
> new.  Hotspot does not throw c++ exceptions, but it cannot prevent third
> party code to catch such exceptions.  By disabling use of global
> operator new[] and new, we constrain the exception disposal within
> hotspot. C++ classes (as same for structs) in hotspot have to either
> extends from CHeapObj or ResourceObj unless they are stack objects or
> values which have to be from StackObj or _ValueObj respectively.  Or
> they have to implement their own operator new[] or new.
>
> Thanks
> Yumin
>
>

From pavel.punegov at oracle.com  Fri Apr 12 03:14:44 2013
From: pavel.punegov at oracle.com (Pavel Punegov)
Date: Fri, 12 Apr 2013 14:14:44 +0400
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <5167A5B4.4060100@oracle.com>
References: <5167A5B4.4060100@oracle.com>
Message-ID: <2008251.VQ1tnDndxf@trisuli>

Yumin,

Should the bug [*] be closed as a duplicate of this as you changed the failing 
part?

Also, do you have a JPRT build with your changes? Was there any testing done?

[*] JDK-7045180 unexpected C++ exception in ObjectSynchronizer::inflate
( https://jbs.oracle.com/bugs/browse/JDK-7045180 )


On Thursday 11 April 2013 23:12:04 Yumin Qi wrote:
> Hi,
> 
>    Can I have your inputs for the fix?
>    webrev:
> 
>   http://cr.openjdk.java.net/~minqi/8010992/webrev/ 
> 
> 
>    Bug:  8010992: Remove calls to global ::operator new[] and new
> https://jbs.oracle.com/bugs/browse/JDK-8010992
> 
> Problem description:  Remove the usage of global operator ::new[] and
> 
> ::new. In hotspot debug build, disable the usage of global new[] and
> 
> new.  Hotspot does not throw c++ exceptions, but it cannot prevent third
> party code to catch such exceptions.  By disabling use of global
> operator new[] and new, we constrain the exception disposal within
> hotspot. C++ classes (as same for structs) in hotspot have to either
> extends from CHeapObj or ResourceObj unless they are stack objects or
> values which have to be from StackObj or _ValueObj respectively.  Or
> they have to implement their own operator new[] or new.
> 
> Thanks
> Yumin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130412/12b5b59e/attachment.html 

From nils.eliasson at oracle.com  Fri Apr 12 03:19:46 2013
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Fri, 12 Apr 2013 12:19:46 +0200
Subject: RFR (M): 8006952: Slow VM due to excessive code cache freelist
	iteration
In-Reply-To: <511511A5.8050101@oracle.com>
References: <5107AADF.6010501@oracle.com> <51082499.3000905@oracle.com>
	<51093FAC.6090803@oracle.com> <51097FA6.3050709@oracle.com>
	<510ABAB9.8020909@oracle.com>
	<15E6C57378C5FE43AD074594DD824E501C8AB7E7@DEWDFEMB15A.global.corp.sap>
	<511511A5.8050101@oracle.com>
Message-ID: <5167DFC2.6020007@oracle.com>

I have now incorporated both Vladimirs and Andreas suggestion:

Changes to previous revision includes:
1) Updated the checks in both heap::allocate and heap::search_freelist 
so that non critical allocation never stride into the 
CodeCacheMinimumFreeSpace.
2) Inverted the critical condition - now all allocations default to not 
critical. Only the places where we would go fatal if the allocation 
returns null are critical.
3) Refactored some names and removed duplicate methods in heap.cpp.

http://cr.openjdk.java.net/~neliasso/8006952/webrev.08/ 


This changes also opens up for decreasing the CodeCacheMinimumFreeSpace 
since we now guarantee that only critical allocation will end up there. 
And they will not grow to 500K when compilation have stopped anyways.

Kind regards,
//Nils


On 2013-02-08 15:54, Nils Eliasson wrote:
> Vladimir and Andreas, thanks for your feedback! I am considering your 
> suggestions.
>
> My fix is a step in the right direction but I realize it is not enough.
>
> Initially, it works good reserving the last part of the heap block. 
> But if the application has a bigger active code footprint that what 
> can fit in the code cache, there will be new flushes that will 
> increase fragmentation and slowly reduce the usable part of the code 
> cache. So I will add functionality for backing off.
>
> //Nils
>
> Schoesser, Andreas skrev 2013-02-01 10:58:
>> Hi Nils,
>>
>> this is IMO a good idea since we experienced the same problem with 
>> one of our ports. I think in our case it was not the nmethod sweeper 
>> continuously running (there's MinCodeCacheFlushingInterval to only 
>> speculatively disconnect nmethods every 30 seconds) but from the 
>> compiler loop constantly polling the freelist without the nmethod 
>> sweeper making any progress.
>>
>> You also might consider to propagate the "critical" flag down to 
>> search_freelist(). Then, a simple address compare would do to keep 
>> the end of the code cache free from nmethods:
>> - For non-critical blobs, search_freelist() may only fit free blocks 
>> < CodeCache::end() - CodeCacheMinimumFreeSpace
>> - For critical blocks, search_freelist() may fit all free blocks
>>
>> Best regards,
>> Andreas
>>
>> -----Original Message-----
>> From: hotspot-compiler-dev-bounces at openjdk.java.net 
>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of 
>> Nils Eliasson
>> Sent: Donnerstag, 31. Januar 2013 19:41
>> To: hotspot-compiler-dev at openjdk.java.net
>> Subject: Re: RFR (M): 8006952: Slow VM due to excessive code cache 
>> freelist iteration
>>
>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.04/
>>
>> //N
>>
>> Vladimir Kozlov skrev 2013-01-30 21:16:
>>> Nils, you sent webrev for other bug fix.
>>>
>>> Vladimir
>>>
>>> On 1/30/13 7:43 AM, Nils Eliasson wrote:
>>>> Thanks for the link, interesting background.
>>>>
>>>> Even if finding the largest block on the freelist is free, we would
>>>> still have a misbehavior when the free heap block is less than 1,5M 
>>>> and
>>>> the flushing begins to create a 1,5M freelist block.
>>>>
>>>> Unallocated memory is a good measurement if have some continuous 
>>>> memory
>>>> in reserve for critical blobs. I am thinking of using the thresholds
>>>> against unallocated memory, but forbidding nmethods from using the 
>>>> last
>>>> 0,5M (MinimumFreeSpace) from the heap block. That would prevent the VM
>>>> from fragmenting the last continuous memory space, and allow the VM to
>>>> use all of the freelist.
>>>>
>>>> Like this:
>>>> http://cr.openjdk.java.net/~neliasso/8002364/webrev.03
>>>>
>>>> //Nils
>>>>
>>>> Vladimir Kozlov skrev 2013-01-29 20:35:
>>>>> Nils,
>>>>>
>>>>> You are reversing 7025742 fix. I would prefer to keep track of a
>>>>> largest free block during allocation in CodeCache (by using ordered
>>>>> list or other technique) to avoid scanning the list.
>>>>>
>>>>> Vladimir
>>>>>
>>>>> On 1/29/13 2:56 AM, Nils Eliasson wrote:
>>>>>> Remove continuous free block requirement for code cache flushing and
>>>>>> minimum free space.
>>>>>>
>>>>>> This causes a degenerate behavior when the VM are repeatedly 
>>>>>> flushing
>>>>>> the code cache trying to free up a continuous 1,5M block. Since the
>>>>>> freelist is fragmented a significant part of the code cache is kept
>>>>>> unallocated. A significant amount of time is spent traversing the
>>>>>> freelist holding the code cache lock or waiting for other threads
>>>>>> doing
>>>>>> the same.
>>>>>>
>>>>>> I don't see any reason for why a continuous block is required. Code
>>>>>> cache flushing threshold (CodeCacheFlushingMinimumFreeSpace) is
>>>>>> default
>>>>>> 1,5M and code cache minimum threshold (CodeCacheMinimumFreeSpace) is
>>>>>> 0,5M. Finding such a block on the freelist is often unrealistic,
>>>>>> and has
>>>>>> not any purpose. The largest nmethods are in the order of 250k, and
>>>>>> they
>>>>>> are not allocated when code cache is starting to run out. All 
>>>>>> critical
>>>>>> adapters are small and will fit easily in the freelist or in the
>>>>>> remaining heap space.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.02/
>>>>>>
>>>>>> Thanks,
>>>>>> Nils Eliasson
>


From niclas.adlertz at oracle.com  Fri Apr 12 05:01:45 2013
From: niclas.adlertz at oracle.com (Niclas Adlertz)
Date: Fri, 12 Apr 2013 14:01:45 +0200
Subject: RFR(M) 8011621: Keep the "live range id - node" mapping in a
	separate class
In-Reply-To: <51630DAA.8060906@oracle.com>
References: <941B0F67-1B66-45EF-8150-BB9F435EB9CD@oracle.com>
	<51630DAA.8060906@oracle.com>
Message-ID: <2650A2B9-507B-4031-BF2F-CA636160197E@oracle.com>

Hi again,

Thank you for your comments.

Vladimir:
---------

> ${JAVA_HOME}/bin/java -server -Xss4m -verify -XX:+CompileTheWorld -XX:+TimeCompiler -Xbootclasspath/p:${JAVA_HOME}/jre/lib/rt.jar

Base: Total compilation: 2235.880 sec.
Fix: Total compilation: 2226.020 sec.

So the fix should be ok in terms of compilation time. 

> Can you use full name LiveRangeMap instead of LRGMap?
Sure, fixed.

> Don't put big methods with loops into header file, we don't want to increase code size without need.
Ok, fixed.

> Explicitly declare private: and public: parts in class. Add comment what is class for.
Done.

> I like Roland's suggestion (LRGMap _lrg_map;) because it avoids a reference through _lrg_map pointer (in compiled code C++ needs only one PhaseChaitin* pointer).
Done.

Roland:
-------

> In vmStructs.cpp, you need to add a declaration for PhaseChaitin::_lrg_map otherwise:
> c2_nonstatic_field(LRGMap,             _max_lrg_id,              uint)
> is useless.
I removed it from vmStructs.cpp completely instead, since it's not used by the agent.

> Why not declare: LRGMap _lrg_map; rather than stack allocate it and set a pointer.
I just followed the old pattern, but that's a good remark, thank you.
Fixed.

> Can you add comments describing what LRGMap is before its declaration?
> 
> Shouldn't that:
> 242   if (C->unique() > _lrg_map->_names.Size()) {
> 243     _lrg_map->_names.extend(C->unique() - 1, 0);
> 244   }
> 
> be moved to the LRGMap constructor?

This code is not necessary anymore, because I also took the liberty of removing 
pd_preallocate_hook(); 
and 
pd_postallocate_verify_hook();

which are not needed anymore because they only added nodes for Win95 and Win 98.

> Shouldn't you make _max_lrg_id, _uf_map and _names private and have accessors?
I have now made public methods for performing operations on _max_lrg_id, _uf_map and _names.

---------

The new webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011621/webrev02/

Thank you.

Regards,
Niclas Adlertz

On 8 apr 2013, at 20:34, Vladimir Kozlov wrote:

> Niclas,
> 
> Thank you for doing this cleanup.
> 
> Please, test affection on RA performance. You can use CTW for this and fastdebug VM:
> 
> ${JAVA_HOME}/bin/java -server -Xss4m -verify -XX:+CompileTheWorld -XX:+TimeCompiler -Xbootclasspath/p:${JAVA_HOME}/jre/lib/rt.jar
> 
> Or build optimized VM and run jvm08, for example, with -XX:+TimeCompiler.
> 
> Can you use full name LiveRangeMap instead of LRGMap?
> Don't put big methods with loops into header file, we don't want to increase code size without need.
> 
> Explicitly declare private: and public: parts in class. Add comment what is class for.
> 
> I like Roland's suggestion (LRGMap _lrg_map;) because it avoids a reference through _lrg_map pointer (in compiled code C++ needs only one PhaseChaitin* pointer).
> 
> Thanks,
> Vladimir
> 
> On 4/8/13 3:05 AM, Niclas Adlertz wrote:
>> Hi all.
>> 
>> Problem:
>> In order to clean up the Split code (in opto/reg_split.cpp) making it easier to maintain and (hopefully) making it easier to improve (https://jbs.oracle.com/bugs/browse/JDK-7022320), it would be good to have the Split code more isolated with as few dependencies to other parts of the code as possible.
>> The Split code could reside in an own module (class), just having references to classes and data it really needs. Right now it would need to have a reference to PhaseChaitin, only to access the "live range id - node" mapping. However, it does not need to know about everything in the PhaseChaitin class. This may also introduce cross reference problems since PhaseChaitin would use the Split module and the Split module would need a reference to PhaseChaitin.
>> 
>> Solution:
>> Move the "live range id - node" mapping to a separate class, instantiated by PhaseChaitin, which can then be passed to the Split module as a reference.
>> 
>> Regards,
>> Niclas Adlertz
>> 
>> (Note that the webrev title is named JDK-7022320. That's just the local folder name that the code resides in. The bug is indeed 8011621)
>> 
>> -----------------------------------------------------------------
>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011621/webrev00/
>>    jbs: https://jbs.oracle.com/bugs/browse/JDK-8011621
>>   bugs: http://bugs.sun.com/view_bug.do?bug_id=8011621
>> 
>> 


From roland.westrelin at oracle.com  Fri Apr 12 06:02:16 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Fri, 12 Apr 2013 15:02:16 +0200
Subject: RFR(M) 8011621: Keep the "live range id - node" mapping in a
	separate class
In-Reply-To: <2650A2B9-507B-4031-BF2F-CA636160197E@oracle.com>
References: <941B0F67-1B66-45EF-8150-BB9F435EB9CD@oracle.com>
	<51630DAA.8060906@oracle.com>
	<2650A2B9-507B-4031-BF2F-CA636160197E@oracle.com>
Message-ID: <43019A3A-0385-4B62-9089-6F29FF0CC8A5@oracle.com>

Hi Niclas,

> This code is not necessary anymore, because I also took the liberty of removing 
> pd_preallocate_hook(); 
> and 
> pd_postallocate_verify_hook();
> 
> which are not needed anymore because they only added nodes for Win95 and Win 98.

Did you use hg remove for the files that are not needed anymore?

> The new webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011621/webrev02/

Shouldn't LiveRangeMap be VALUE_OBJ_CLASS_SPEC?

live.hpp: comment not aligned anymore. 

It looks good to me.

Roland.

From roland.westrelin at oracle.com  Fri Apr 12 07:17:48 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Fri, 12 Apr 2013 16:17:48 +0200
Subject: RFR(XS): 8012037: Test8009761.java "Failed: init recursive calls:
	7224. After deopt 58824"
Message-ID: <35515493-8A97-44C5-B1E4-F5CD05C98A3D@oracle.com>

http://cr.openjdk.java.net/~roland/8012037/webrev.00/

Test shouldn't be run with a different CompileThreshold.

Roland.

From igor.ignatyev at oracle.com  Fri Apr 12 08:27:38 2013
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 12 Apr 2013 19:27:38 +0400
Subject: RFR(S) : 8011675: adding compilation level to replay data
In-Reply-To: <5163C5F4.7020605@oracle.com>
References: <51631AEA.9080702@oracle.com> <51635E89.30808@oracle.com>
	<5163BD9A.5080308@oracle.com> <5163C5F4.7020605@oracle.com>
Message-ID: <516827EA.3040001@oracle.com>

updated webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.02/
added:
   1. more informative message on unsupported comp_level
   2. not-product flag 'CrashAfterCompileId' and assert in 
compileBroker.cpp for assured generation of replay.txt
   2. tests for ciReplay

Best regards,
Igor Ignatyev

On 04/09/2013 11:40 AM, Vladimir Kozlov wrote:
> Igor,
>
> Sorry, I may said it not clear. What I meant is to set error (call
> report_error()) in such case and return from process_compile() without
> compilation. But let ciReplay::replay() finish and exit. replay_impl()
> should print the problem so you don't need to do it in
> process_compile(). And, please, test it.
> The message should be more informative, something like:
> "compilation level %d requires TieredCompilation"
> An other bad cases is when failure happened in Client (C1) or Server
> (C2) but the replay is run with opposite VM.
>
> thanks,
> Vladimir
>
> On 4/9/13 12:04 AM, Igor Ignatyev wrote:
>> Vladimir,
>>
>> Thank you for review.
>>
>> updated webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.01/
>>
>> Best regards,
>> Igor Ignatyev
>>
>> On 04/09/2013 04:19 AM, Vladimir Kozlov wrote:
>>> Igor,
>>>
>>> Thank you for fixing and cleaning this.
>>>
>>> In vmStructs.cpp move _comp_level after _compile_id as in nmethod class.
>>>
>>> Typo in ciReplay.cpp:
>>> +      comp_level != CompLevel_highest_tier;
>>>
>>> Actually it is useless to replay compilation at different level, it
>>> should exit with error. Could happened because incorrectly run without
>>> Tiered when the crush happened with Tiered.
>>>
>>> In ciReplay.cpp use parenthesis around equality checks: if (. && (. ==
>>> .)).
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 4/8/13 12:30 PM, Igor Ignatyev wrote:
>>>> Hi all,
>>>>
>>>> Please review patch.
>>>>
>>>> Problem:
>>>> Replay of compilations supports c1 and tiered as well as c2, the only
>>>> thing missing is comp_level.
>>>>
>>>> Fix:
>>>> 1. added comp_level into dump and usage during replay
>>>> 2. minor changes in agent/doc:
>>>>    - escaped '<', '>'
>>>>    - renamed 'C2 Replay'/'C2 compiler replay' to 'Replay'/'Compiler
>>>> replay'
>>>>
>>>> Testing:
>>>> manually launched the replay from JDK-8010934 (assert specifically to
>>>> c1) on jvm w/o corresponded fix. assert was triggered w/ patch and
>>>> wasn't triggered w/o.
>>>>
>>>>
>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.00/
>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011675

From igor.ignatyev at oracle.com  Fri Apr 12 08:29:39 2013
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 12 Apr 2013 19:29:39 +0400
Subject: RFR(S) : 8011971 : WB API doesn't accept j.l.reflect.Constructor
Message-ID: <51682863.3020800@oracle.com>

Hi all,

Please review patch.

1. changed signature of all methods where j.l.reflect.Method is used
2. added tests which use j.l.reflect.Constructor

webrev: http://cr.openjdk.java.net/~iignatyev/8011971/webrev.00/
jbs: https://jbs.oracle.com/bugs/browse/JDK-8011971
-- 
Best regards,
Igor Ignatyev

From roland.westrelin at oracle.com  Fri Apr 12 09:09:20 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Fri, 12 Apr 2013 18:09:20 +0200
Subject: RFR(XS): 8011901:  Unsafe.getAndAddLong(obj, off,
	delta) does not work properly with long deltas
Message-ID: <2234A456-8619-4B27-AF7F-4D9F9181E08D@oracle.com>

http://cr.openjdk.java.net/~roland/8011901/webrev.00/

64 bit on x86 xaddL_no_res shouldn't allow a 64 bit constant: it's not supported by the architecture.

Roland.

From aleksey.shipilev at oracle.com  Fri Apr 12 09:33:04 2013
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 12 Apr 2013 20:33:04 +0400
Subject: RFR(XS): 8011901:  Unsafe.getAndAddLong(obj, off, delta) does
	not work properly with long deltas
In-Reply-To: <2234A456-8619-4B27-AF7F-4D9F9181E08D@oracle.com>
References: <2234A456-8619-4B27-AF7F-4D9F9181E08D@oracle.com>
Message-ID: <51683740.7090107@oracle.com>

On 04/12/2013 08:09 PM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8011901/webrev.00/

Looks good. Fixes the test on Linux/x86_64, as well as the original
problem this testcase was derived from.

> 64 bit on x86 xaddL_no_res shouldn't allow a 64 bit constant: it's
> not supported by the architecture.

Indeed! I couldn't believe the fix is that simple. I was staring at the
addq encoding in the Intel SDM few days ago, but missed this completely.
Thanks for figuring this out!

-Aleksey.

From vladimir.kozlov at oracle.com  Fri Apr 12 10:21:07 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 12 Apr 2013 10:21:07 -0700
Subject: RFR (M): 8006952: Slow VM due to excessive code cache freelist
	iteration
In-Reply-To: <5167DFC2.6020007@oracle.com>
References: <5107AADF.6010501@oracle.com> <51082499.3000905@oracle.com>
	<51093FAC.6090803@oracle.com> <51097FA6.3050709@oracle.com>
	<510ABAB9.8020909@oracle.com>
	<15E6C57378C5FE43AD074594DD824E501C8AB7E7@DEWDFEMB15A.global.corp.sap>
	<511511A5.8050101@oracle.com> <5167DFC2.6020007@oracle.com>
Message-ID: <51684283.7010304@oracle.com>

Nils,

It is sad that you have to reverse parfait fix but I agree that your 
changes are more clean.

After these changes largest_free_block() is used only in statistics 
output which is useless since it is not participating in codecache 
allocations.  May be we should remove it and use 
heap_unallocated_capacity() instead (do we need lock then?):

size_t CodeCache::largest_free_block() {
   return _heap->heap_unallocated_capacity();
}

Also red_zone_start() is confusing because it does not show how it is 
related to heap_unallocated_capacity(). In one place you use one:

  211     if (size(length) > (heap_unallocated_capacity() - 
CodeCacheMinimumFreeSpace)) {

and in an other use second:

  437     if (((size_t)cur + length) >= (size_t)red_zone_start()) {

Can we just use only heap_unallocated_capacity()?

Thanks,
Vladimir

On 4/12/13 3:19 AM, Nils Eliasson wrote:
> I have now incorporated both Vladimirs and Andreas suggestion:
>
> Changes to previous revision includes:
> 1) Updated the checks in both heap::allocate and heap::search_freelist
> so that non critical allocation never stride into the
> CodeCacheMinimumFreeSpace.
> 2) Inverted the critical condition - now all allocations default to not
> critical. Only the places where we would go fatal if the allocation
> returns null are critical.
> 3) Refactored some names and removed duplicate methods in heap.cpp.
>
> http://cr.openjdk.java.net/~neliasso/8006952/webrev.08/
> 
>
> This changes also opens up for decreasing the CodeCacheMinimumFreeSpace
> since we now guarantee that only critical allocation will end up there.
> And they will not grow to 500K when compilation have stopped anyways.
>
> Kind regards,
> //Nils
>
>
> On 2013-02-08 15:54, Nils Eliasson wrote:
>> Vladimir and Andreas, thanks for your feedback! I am considering your
>> suggestions.
>>
>> My fix is a step in the right direction but I realize it is not enough.
>>
>> Initially, it works good reserving the last part of the heap block.
>> But if the application has a bigger active code footprint that what
>> can fit in the code cache, there will be new flushes that will
>> increase fragmentation and slowly reduce the usable part of the code
>> cache. So I will add functionality for backing off.
>>
>> //Nils
>>
>> Schoesser, Andreas skrev 2013-02-01 10:58:
>>> Hi Nils,
>>>
>>> this is IMO a good idea since we experienced the same problem with
>>> one of our ports. I think in our case it was not the nmethod sweeper
>>> continuously running (there's MinCodeCacheFlushingInterval to only
>>> speculatively disconnect nmethods every 30 seconds) but from the
>>> compiler loop constantly polling the freelist without the nmethod
>>> sweeper making any progress.
>>>
>>> You also might consider to propagate the "critical" flag down to
>>> search_freelist(). Then, a simple address compare would do to keep
>>> the end of the code cache free from nmethods:
>>> - For non-critical blobs, search_freelist() may only fit free blocks
>>> < CodeCache::end() - CodeCacheMinimumFreeSpace
>>> - For critical blocks, search_freelist() may fit all free blocks
>>>
>>> Best regards,
>>> Andreas
>>>
>>> -----Original Message-----
>>> From: hotspot-compiler-dev-bounces at openjdk.java.net
>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of
>>> Nils Eliasson
>>> Sent: Donnerstag, 31. Januar 2013 19:41
>>> To: hotspot-compiler-dev at openjdk.java.net
>>> Subject: Re: RFR (M): 8006952: Slow VM due to excessive code cache
>>> freelist iteration
>>>
>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.04/
>>>
>>> //N
>>>
>>> Vladimir Kozlov skrev 2013-01-30 21:16:
>>>> Nils, you sent webrev for other bug fix.
>>>>
>>>> Vladimir
>>>>
>>>> On 1/30/13 7:43 AM, Nils Eliasson wrote:
>>>>> Thanks for the link, interesting background.
>>>>>
>>>>> Even if finding the largest block on the freelist is free, we would
>>>>> still have a misbehavior when the free heap block is less than 1,5M
>>>>> and
>>>>> the flushing begins to create a 1,5M freelist block.
>>>>>
>>>>> Unallocated memory is a good measurement if have some continuous
>>>>> memory
>>>>> in reserve for critical blobs. I am thinking of using the thresholds
>>>>> against unallocated memory, but forbidding nmethods from using the
>>>>> last
>>>>> 0,5M (MinimumFreeSpace) from the heap block. That would prevent the VM
>>>>> from fragmenting the last continuous memory space, and allow the VM to
>>>>> use all of the freelist.
>>>>>
>>>>> Like this:
>>>>> http://cr.openjdk.java.net/~neliasso/8002364/webrev.03
>>>>>
>>>>> //Nils
>>>>>
>>>>> Vladimir Kozlov skrev 2013-01-29 20:35:
>>>>>> Nils,
>>>>>>
>>>>>> You are reversing 7025742 fix. I would prefer to keep track of a
>>>>>> largest free block during allocation in CodeCache (by using ordered
>>>>>> list or other technique) to avoid scanning the list.
>>>>>>
>>>>>> Vladimir
>>>>>>
>>>>>> On 1/29/13 2:56 AM, Nils Eliasson wrote:
>>>>>>> Remove continuous free block requirement for code cache flushing and
>>>>>>> minimum free space.
>>>>>>>
>>>>>>> This causes a degenerate behavior when the VM are repeatedly
>>>>>>> flushing
>>>>>>> the code cache trying to free up a continuous 1,5M block. Since the
>>>>>>> freelist is fragmented a significant part of the code cache is kept
>>>>>>> unallocated. A significant amount of time is spent traversing the
>>>>>>> freelist holding the code cache lock or waiting for other threads
>>>>>>> doing
>>>>>>> the same.
>>>>>>>
>>>>>>> I don't see any reason for why a continuous block is required. Code
>>>>>>> cache flushing threshold (CodeCacheFlushingMinimumFreeSpace) is
>>>>>>> default
>>>>>>> 1,5M and code cache minimum threshold (CodeCacheMinimumFreeSpace) is
>>>>>>> 0,5M. Finding such a block on the freelist is often unrealistic,
>>>>>>> and has
>>>>>>> not any purpose. The largest nmethods are in the order of 250k, and
>>>>>>> they
>>>>>>> are not allocated when code cache is starting to run out. All
>>>>>>> critical
>>>>>>> adapters are small and will fit easily in the freelist or in the
>>>>>>> remaining heap space.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.02/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Nils Eliasson
>>
>

From yumin.qi at oracle.com  Fri Apr 12 10:30:32 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Fri, 12 Apr 2013 10:30:32 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <5167C9FC.5000902@oracle.com>
References: <5167A5B4.4060100@oracle.com> <5167C9FC.5000902@oracle.com>
Message-ID: <516844B8.1030805@oracle.com>

Thanks, David

On 4/12/2013 1:46 AM, David Holmes wrote:
> Hi Yumin,
>
> This looks pretty good.
>
> On 12/04/2013 4:12 PM, Yumin Qi wrote:
>>    Can I have your inputs for the fix?
>>    webrev:
>>
>>   http://cr.openjdk.java.net/~minqi/8010992/webrev/
>> 
>
> src/share/vm/classfile/altHashing.cpp
>
> Can these be directly stack-allocated arrays instead of C-Heap ?
>
Yes
> ---
>
> allocation.cpp
>
> 672 // %% note this is causing a problem on solaris debug build. the 
> global
> 673 // new is being called from jdk source and causing data corruption.
> 674 // 
> src/share/native/sun/awt/font/fontmanager/textcache/hsMemory.cpp::hsSoftNew
>
> Is this still an issue?
>
> As a general comment do we need all the operator new[] additions?
>
No longer an issue, the code mentioned in jdk has been removed.
> ---
>
> allocation.inline.hpp
>
> Can we reduce code duplication by changing, eg:
>
> #ifdef ASSERT
>     void* p = (void*)AllocateHeap(size, F, (caller_pc != 0 ? caller_pc 
> : CALLER_PC));
>     if (PrintMallocFree) trace_heap_malloc(size, "CHeapObj-new", p);
>     return p;
> #else
>     return (void *) AllocateHeap(size, F, (caller_pc != 0 ? caller_pc 
> : CALLER_PC));
> #endif
>
> to
>
>     void* p = (void*)AllocateHeap(size, F, (caller_pc != 0 ? caller_pc 
> : CALLER_PC));
> #ifdef ASSERT
>     if (PrintMallocFree) trace_heap_malloc(size, "CHeapObj-new", p);
> #endif
>     return p;
>
Yes, that is better.
> ---
>
> src/share/vm/memory/cardTableModRefBS.cpp
>
> 86   for (i = 0; i < max_covered_regions; i++) {
> 87     _covered[i].set_start(NULL)  ; _covered[i].set_word_size(0)  ;
> 88     _committed[i].set_start(NULL); _committed[i].set_word_size(0);
> 89   }
>
> this appears to be a semantic change, which leads me to ask:
>
> Given "new MemRegion[1]" vs NEW_C_HEAP_ARRAY(...,1,...) what are the 
> array contents initialized to in each case?
>
Ii should be changed to use NEW_C_HEAP_OBJECT, but MemRegion is a 
_ValueObj which should not be new'ed.   The loop here is just doing that 
what the default ctor do.
> ---
>
> src/share/vm/memory/cardTableRS.cpp
>
>   68 CardTableRS::~CardTableRS() {
>   69   if (_last_cur_val_in_gen) {
>   70     // FREE_C_HEAP_ARRAY(jbyte, _last_cur_val_in_gen, mtInternal);
>   71   }
>   72 }
>
> Was this an existing memory leak? I'm noticing that most uses of "new 
> X[n]" don't have a corresponding delete!
>
> But why is this commented out?
That is a mistake, I will uncomment it back.
>
> ---
>
> src/share/vm/runtime/handles.hpp
>
> initialize_thread shouldn't need to be public. What is calling it?
>
> ---
>
> src/share/vm/runtime/thread.cpp
>
> These changes don't look right - why doesn't HandleMark extend one of 
> the allocation base classes ?
>
The HandleMark should be an StackObj, but we need to create it in heap 
in thread creation. This part is confusing me too.  This is the only 
place to create it in heap, all the usage is a StackObj.

Thanks
Yumin
>
> Thanks,
> David
> -----
>
>>    Bug:  8010992: Remove calls to global ::operator new[] and new
>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>
>> Problem description:  Remove the usage of global operator ::new[] and
>> ::new. In hotspot debug build, disable the usage of global new[] and
>> new.  Hotspot does not throw c++ exceptions, but it cannot prevent third
>> party code to catch such exceptions.  By disabling use of global
>> operator new[] and new, we constrain the exception disposal within
>> hotspot. C++ classes (as same for structs) in hotspot have to either
>> extends from CHeapObj or ResourceObj unless they are stack objects or
>> values which have to be from StackObj or _ValueObj respectively.  Or
>> they have to implement their own operator new[] or new.
>>
>> Thanks
>> Yumin
>>
>>


From vladimir.kozlov at oracle.com  Fri Apr 12 10:43:23 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 12 Apr 2013 10:43:23 -0700
Subject: RFR(XS): 8011901:  Unsafe.getAndAddLong(obj, off, delta) does
	not work properly with long deltas
In-Reply-To: <2234A456-8619-4B27-AF7F-4D9F9181E08D@oracle.com>
References: <2234A456-8619-4B27-AF7F-4D9F9181E08D@oracle.com>
Message-ID: <516847BB.8010007@oracle.com>

Roland,

The fix is correct, only movq instruction can load 64bit immediate 
value. I looked on other instructions (in x86_64.ad and x86.ad) with 
immL parameter and all of them use movq only. Could you double check?

Also remove unused "enc_class Con64" to avoid its usage by accident.

Thanks,
Vladimir

On 4/12/13 9:09 AM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8011901/webrev.00/
>
> 64 bit on x86 xaddL_no_res shouldn't allow a 64 bit constant: it's not supported by the architecture.
>
> Roland.
>

From alejandro.murillo at oracle.com  Fri Apr 12 11:05:20 2013
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 12 Apr 2013 18:05:20 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 26 new changesets
Message-ID: <20130412180612.F09ED4828C@hg.openjdk.java.net>

Changeset: 5dcfeb396fed
Author:    katleman
Date:      2013-04-11 09:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5dcfeb396fed

Added tag jdk8-b85 for changeset 42fe530cd478

! .hgtags

Changeset: 3b890cd4da64
Author:    ctornqvi
Date:      2013-04-03 21:41 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3b890cd4da64

8009125: Add NMT tests for Virtual Memory operations
Summary: Tests added for Reserve/Commit/Uncommit/Unreserve operations
Reviewed-by: zgu, mgerdin

! src/share/vm/prims/whitebox.cpp
- test/runtime/NMT/AllocTestType.java
+ test/runtime/NMT/MallocTestType.java
+ test/runtime/NMT/ThreadedMallocTestType.java
+ test/runtime/NMT/ThreadedVirtualAllocTestType.java
+ test/runtime/NMT/VirtualAllocTestType.java
! test/testlibrary/OutputAnalyzerTest.java
! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 8554c55669b0
Author:    hseigel
Date:      2013-04-04 08:47 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8554c55669b0

8010943: guarantee(length == 0) failed: invalid method ordering length
Summary: Add DumpSharedSpaces to IF condition to handle verify during -Xshare:dump.
Reviewed-by: coleenp, zgu

! src/share/vm/oops/instanceKlass.cpp

Changeset: bad3bed4b323
Author:    ccheung
Date:      2013-03-29 14:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bad3bed4b323

8006006: [parfait] Memory leak at hotspot/src/share/tools/launcher/wildcard.c
Summary: a simple fix to add FileList_free(fl) before returning NULL.
Reviewed-by: zgu, coleenp, minqi

! src/share/tools/launcher/wildcard.c

Changeset: 17bf4d428955
Author:    ccheung
Date:      2013-04-03 16:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/17bf4d428955

8006103: [parfait] Possible null pointer dereference at hotspot/src/os/linux/vm/os_linux.cpp; os_windows.cpp; os_solaris.cpp; os_bsd.cpp
Reviewed-by: zgu, iklam

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp

Changeset: cc32ccaaf47f
Author:    mikael
Date:      2013-04-04 10:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cc32ccaaf47f

8003310: Enable -Wunused-function when compiling with gcc
Summary: Add the -Wunused-function flag and remove a number of unused functions.
Reviewed-by: dholmes, coleenp, kvn

! make/linux/makefiles/gcc.make
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/x86_64.ad
! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/compiler/compileLog.cpp
! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/ptrQueue.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/memory/heap.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/opto/block.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/connode.cpp
! src/share/vm/opto/subnode.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jniCheck.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/safepoint.cpp
! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/runtime/synchronizer.hpp
! src/share/vm/utilities/debug.cpp
! src/share/vm/utilities/globalDefinitions.cpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 4c8bb5e4f68f
Author:    zgu
Date:      2013-04-05 12:19 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4c8bb5e4f68f

8011161: NMT: Memory leak when encountering out of memory error while initializing memory snapshot
Summary: Fix memory leaks when NMT fails to initialize snapshot and worker thread
Reviewed-by: dcubed, ccheung, rdurbin

! src/share/vm/services/memTracker.cpp

Changeset: 8be1318fbe77
Author:    dcubed
Date:      2013-04-05 10:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8be1318fbe77

Merge

! src/cpu/x86/vm/x86_64.ad
! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/runtime/arguments.cpp
- test/runtime/NMT/AllocTestType.java

Changeset: 46d24f112c27
Author:    dcubed
Date:      2013-04-05 16:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/46d24f112c27

Merge

- make/bsd/build.sh
- make/linux/build.sh
- make/solaris/build.sh

Changeset: 4b7cf00ccb08
Author:    ccheung
Date:      2013-04-05 11:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4b7cf00ccb08

8006001: [parfait] Possible file leak in hotspot/src/os/linux/vm/perfMemory_linux.cpp
Reviewed-by: zgu, coleenp, hseigel, dholmes

! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/os/windows/vm/perfMemory_windows.cpp

Changeset: b933e75e7cbe
Author:    zgu
Date:      2013-04-05 23:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b933e75e7cbe

Merge


Changeset: 09b0d3e9ba6c
Author:    bharadwaj
Date:      2013-04-09 08:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/09b0d3e9ba6c

8011671: JCK tests on static interface methods fail under b84: Illegal type at constant pool entry 5
Summary: Restore incorrect removal of support for static interface method verification in Java 8
Reviewed-by: kvn, coleenp

! src/share/vm/classfile/verifier.cpp

Changeset: 9b4a6a172a8a
Author:    amurillo
Date:      2013-04-11 01:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9b4a6a172a8a

Added tag hs25-b27 for changeset 09b0d3e9ba6c

! .hgtags

Changeset: 511e334ee345
Author:    amurillo
Date:      2013-04-11 16:35 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/511e334ee345

Merge

! .hgtags
- test/runtime/NMT/AllocTestType.java

Changeset: e437668ced9d
Author:    amurillo
Date:      2013-04-11 01:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e437668ced9d

8011948: new hotspot build - hs25-b28
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 68fe50d4f1d5
Author:    johnc
Date:      2013-04-05 10:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/68fe50d4f1d5

8011343: Add new flag for verifying the heap during startup
Summary: Perform verification during VM startup under control of new flag and within a VMOperation.
Reviewed-by: stefank, jmasa, brutisso

! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vm_operations.cpp
! src/share/vm/runtime/vm_operations.hpp
- test/gc/TestVerifyBeforeGCDuringStartup.java
+ test/gc/TestVerifyDuringStartup.java

Changeset: 8617e38bb4cb
Author:    jmasa
Date:      2013-02-11 10:31 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8617e38bb4cb

8008508: CMS does not correctly reduce heap size after a Full GC
Reviewed-by: johnc, ysr

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.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/vmStructs.cpp

Changeset: 83f27710f5f7
Author:    brutisso
Date:      2013-04-08 07:49 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/83f27710f5f7

7197666: java -d64 -version core dumps in a box with lots of memory
Summary: Allow task queues to be mmapped instead of malloced on Solaris
Reviewed-by: coleenp, jmasa, johnc, tschatzl

! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/taskqueue.hpp

Changeset: 63f57a8c5283
Author:    mgerdin
Date:      2013-04-09 15:32 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/63f57a8c5283

8009808: TEST-BUG : test case is using bash style tests. Default shell for jtreg is bourne. thus failure
Summary: Rewrite test to use Java only instead of shell script
Reviewed-by: mgerdin, brutisso
Contributed-by: leonid.mesnik at oracle.com

+ test/gc/6941923/Test6941923.java
- test/gc/6941923/test6941923.sh

Changeset: ba42fd5e00e6
Author:    mgerdin
Date:      2013-04-10 13:27 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ba42fd5e00e6

8010196: NPG: Internal Error: Metaspace allocation lock -- possible deadlock
Summary: Refactor the CLD dependency list into a separate class. Use an ObjectLocker to synchronize additions to the CLD dependency list.
Reviewed-by: stefank, coleenp

! src/share/vm/classfile/classLoaderData.cpp
! src/share/vm/classfile/classLoaderData.hpp
+ test/gc/metaspace/G1AddMetaspaceDependency.java

Changeset: 7b835924c31c
Author:    stefank
Date:      2013-04-10 14:26 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7b835924c31c

8011872: Include Bit Map addresses in the hs_err files
Reviewed-by: brutisso, jmasa

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp
! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/utilities/bitMap.cpp
! src/share/vm/utilities/bitMap.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: 480d934f62a8
Author:    mgerdin
Date:      2013-04-11 16:35 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/480d934f62a8

Merge

! src/share/vm/runtime/arguments.cpp
- test/runtime/NMT/AllocTestType.java

Changeset: 7a5aec879506
Author:    bharadwaj
Date:      2013-04-11 17:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7a5aec879506

Merge

! src/share/vm/prims/whitebox.cpp
! src/share/vm/utilities/globalDefinitions.hpp
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 6d88a566d369
Author:    amurillo
Date:      2013-04-11 21:45 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6d88a566d369

Merge

- test/gc/6941923/test6941923.sh
- test/gc/TestVerifyBeforeGCDuringStartup.java

Changeset: 5201379fe487
Author:    amurillo
Date:      2013-04-11 21:45 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5201379fe487

Added tag hs25-b28 for changeset 6d88a566d369

! .hgtags

Changeset: c60f69931e1a
Author:    amurillo
Date:      2013-04-11 21:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c60f69931e1a

8011949: new hotspot build - hs25-b29
Reviewed-by: jcoomes

! make/hotspot_version


From vladimir.kozlov at oracle.com  Fri Apr 12 11:14:45 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 12 Apr 2013 11:14:45 -0700
Subject: RFR(M) 8011621: Keep the "live range id - node" mapping in a
	separate class
In-Reply-To: <2650A2B9-507B-4031-BF2F-CA636160197E@oracle.com>
References: <941B0F67-1B66-45EF-8150-BB9F435EB9CD@oracle.com>
	<51630DAA.8060906@oracle.com>
	<2650A2B9-507B-4031-BF2F-CA636160197E@oracle.com>
Message-ID: <51684F15.10701@oracle.com>

Hurray :) more dead code removed.

Move small PhaseChaitin::clone_projs() methods which calls 
clone_projs_shared() into the header file.

May be you should move the rest of PhaseChaitin methods from 
coalesce.cpp to chaitin.cpp where they are logically belong.

You added clone_projs() to PhaseCoalesce class but it is not defined or 
used.

Thanks,
Vladimir

On 4/12/13 5:01 AM, Niclas Adlertz wrote:
> Hi again,
>
> Thank you for your comments.
>
> Vladimir:
> ---------
>
>> ${JAVA_HOME}/bin/java -server -Xss4m -verify -XX:+CompileTheWorld -XX:+TimeCompiler -Xbootclasspath/p:${JAVA_HOME}/jre/lib/rt.jar
>
> Base: Total compilation: 2235.880 sec.
> Fix: Total compilation: 2226.020 sec.
>
> So the fix should be ok in terms of compilation time.
>
>> Can you use full name LiveRangeMap instead of LRGMap?
> Sure, fixed.
>
>> Don't put big methods with loops into header file, we don't want to increase code size without need.
> Ok, fixed.
>
>> Explicitly declare private: and public: parts in class. Add comment what is class for.
> Done.
>
>> I like Roland's suggestion (LRGMap _lrg_map;) because it avoids a reference through _lrg_map pointer (in compiled code C++ needs only one PhaseChaitin* pointer).
> Done.
>
> Roland:
> -------
>
>> In vmStructs.cpp, you need to add a declaration for PhaseChaitin::_lrg_map otherwise:
>> c2_nonstatic_field(LRGMap,             _max_lrg_id,              uint)
>> is useless.
> I removed it from vmStructs.cpp completely instead, since it's not used by the agent.
>
>> Why not declare: LRGMap _lrg_map; rather than stack allocate it and set a pointer.
> I just followed the old pattern, but that's a good remark, thank you.
> Fixed.
>
>> Can you add comments describing what LRGMap is before its declaration?
>>
>> Shouldn't that:
>> 242   if (C->unique() > _lrg_map->_names.Size()) {
>> 243     _lrg_map->_names.extend(C->unique() - 1, 0);
>> 244   }
>>
>> be moved to the LRGMap constructor?
>
> This code is not necessary anymore, because I also took the liberty of removing
> pd_preallocate_hook();
> and
> pd_postallocate_verify_hook();
>
> which are not needed anymore because they only added nodes for Win95 and Win 98.
>
>> Shouldn't you make _max_lrg_id, _uf_map and _names private and have accessors?
> I have now made public methods for performing operations on _max_lrg_id, _uf_map and _names.
>
> ---------
>
> The new webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011621/webrev02/
>
> Thank you.
>
> Regards,
> Niclas Adlertz
>
> On 8 apr 2013, at 20:34, Vladimir Kozlov wrote:
>
>> Niclas,
>>
>> Thank you for doing this cleanup.
>>
>> Please, test affection on RA performance. You can use CTW for this and fastdebug VM:
>>
>> ${JAVA_HOME}/bin/java -server -Xss4m -verify -XX:+CompileTheWorld -XX:+TimeCompiler -Xbootclasspath/p:${JAVA_HOME}/jre/lib/rt.jar
>>
>> Or build optimized VM and run jvm08, for example, with -XX:+TimeCompiler.
>>
>> Can you use full name LiveRangeMap instead of LRGMap?
>> Don't put big methods with loops into header file, we don't want to increase code size without need.
>>
>> Explicitly declare private: and public: parts in class. Add comment what is class for.
>>
>> I like Roland's suggestion (LRGMap _lrg_map;) because it avoids a reference through _lrg_map pointer (in compiled code C++ needs only one PhaseChaitin* pointer).
>>
>> Thanks,
>> Vladimir
>>
>> On 4/8/13 3:05 AM, Niclas Adlertz wrote:
>>> Hi all.
>>>
>>> Problem:
>>> In order to clean up the Split code (in opto/reg_split.cpp) making it easier to maintain and (hopefully) making it easier to improve (https://jbs.oracle.com/bugs/browse/JDK-7022320), it would be good to have the Split code more isolated with as few dependencies to other parts of the code as possible.
>>> The Split code could reside in an own module (class), just having references to classes and data it really needs. Right now it would need to have a reference to PhaseChaitin, only to access the "live range id - node" mapping. However, it does not need to know about everything in the PhaseChaitin class. This may also introduce cross reference problems since PhaseChaitin would use the Split module and the Split module would need a reference to PhaseChaitin.
>>>
>>> Solution:
>>> Move the "live range id - node" mapping to a separate class, instantiated by PhaseChaitin, which can then be passed to the Split module as a reference.
>>>
>>> Regards,
>>> Niclas Adlertz
>>>
>>> (Note that the webrev title is named JDK-7022320. That's just the local folder name that the code resides in. The bug is indeed 8011621)
>>>
>>> -----------------------------------------------------------------
>>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011621/webrev00/
>>>     jbs: https://jbs.oracle.com/bugs/browse/JDK-8011621
>>>    bugs: http://bugs.sun.com/view_bug.do?bug_id=8011621
>>>
>>>
>

From vladimir.kozlov at oracle.com  Fri Apr 12 11:41:39 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 12 Apr 2013 11:41:39 -0700
Subject: RFR(XS): 8012037: Test8009761.java "Failed: init recursive calls:
	7224. After deopt 58824"
In-Reply-To: <35515493-8A97-44C5-B1E4-F5CD05C98A3D@oracle.com>
References: <35515493-8A97-44C5-B1E4-F5CD05C98A3D@oracle.com>
Message-ID: <51685563.2090505@oracle.com>

Roland,

Excluding m2() from compilation (and, as result, from inlining) may help 
to run with any flags: -XX:CompileCommand=exclude,Test8009761::m2

Add -XssN flag to set small stack size so that on all platforms (of same 
bitness, 32 and 64- bit will still be different) you overflow stack at 
the same depths at reasonable time.

thanks,
Vladimir

On 4/12/13 7:17 AM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8012037/webrev.00/
>
> Test shouldn't be run with a different CompileThreshold.
>
> Roland.
>

From yumin.qi at oracle.com  Fri Apr 12 11:51:43 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Fri, 12 Apr 2013 11:51:43 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <2008251.VQ1tnDndxf@trisuli>
References: <5167A5B4.4060100@oracle.com> <2008251.VQ1tnDndxf@trisuli>
Message-ID: <516857BF.4000802@oracle.com>

Pavel,

On 4/12/2013 3:14 AM, Pavel Punegov wrote:
>
> Yumin,
>
> Should the bug [*] be closed as a duplicate of this as you changed the 
> failing part?
>
Yes.
>
> Also, do you have a JPRT build with your changes? Was there any 
> testing done?
>
Not final, will send you a link when done.

Thanks
Yumin
>
> [*] JDK-7045180 unexpected C++ exception in ObjectSynchronizer::inflate
>
> ( https://jbs.oracle.com/bugs/browse/JDK-7045180 )
>
> On Thursday 11 April 2013 23:12:04 Yumin Qi wrote:
>
> > Hi,
>
> >
>
> > Can I have your inputs for the fix?
>
> > webrev:
>
> >
>
> > http://cr.openjdk.java.net/~minqi/8010992/webrev/
>
> > 
>
> >
>
> > Bug: 8010992: Remove calls to global ::operator new[] and new
>
> > https://jbs.oracle.com/bugs/browse/JDK-8010992
>
> >
>
> > Problem description: Remove the usage of global operator ::new[] and
>
> >
>
> > ::new. In hotspot debug build, disable the usage of global new[] and
>
> >
>
> > new. Hotspot does not throw c++ exceptions, but it cannot prevent third
>
> > party code to catch such exceptions. By disabling use of global
>
> > operator new[] and new, we constrain the exception disposal within
>
> > hotspot. C++ classes (as same for structs) in hotspot have to either
>
> > extends from CHeapObj or ResourceObj unless they are stack objects or
>
> > values which have to be from StackObj or _ValueObj respectively. Or
>
> > they have to implement their own operator new[] or new.
>
> >
>
> > Thanks
>
> > Yumin
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130412/c810b42e/attachment-0001.html 

From vladimir.kozlov at oracle.com  Fri Apr 12 12:39:12 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 12 Apr 2013 12:39:12 -0700
Subject: RFR(S) : 8011971 : WB API doesn't accept j.l.reflect.Constructor
In-Reply-To: <51682863.3020800@oracle.com>
References: <51682863.3020800@oracle.com>
Message-ID: <516862E0.5080109@oracle.com>

Igor,

Could you explain why you need j.l.reflect.Constructor in WB compiler 
tests? As java coding exercise it may be good (I am lost in it). But how 
it helps to JIT compiler testing?

Do you know about 'comments' in a code? :)

Using argument 'true' say nothing what it does since the corresponding 
code is in different class file:

+        super(testCase, true);

Why do you need to set dontinline in costructor?
Would be better explicitly call new method from CompilerWhiteBoxTest 
class when needed:

setDontInlineMethod() {
   WHITE_BOX.testSetDontInlineMethod(method, true);
}

Regards,
Vladimir

On 4/12/13 8:29 AM, Igor Ignatyev wrote:
> Hi all,
>
> Please review patch.
>
> 1. changed signature of all methods where j.l.reflect.Method is used
> 2. added tests which use j.l.reflect.Constructor
>
> webrev: http://cr.openjdk.java.net/~iignatyev/8011971/webrev.00/
> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011971

From igor.ignatyev at oracle.com  Fri Apr 12 13:14:57 2013
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Sat, 13 Apr 2013 00:14:57 +0400
Subject: RFR(S) : 8011971 : WB API doesn't accept j.l.reflect.Constructor
In-Reply-To: <516862E0.5080109@oracle.com>
References: <51682863.3020800@oracle.com> <516862E0.5080109@oracle.com>
Message-ID: <51686B41.3060502@oracle.com>

 > Could you explain why you need j.l.reflect.Constructor in WB compiler
 > tests? As java coding exercise it may be good (I am lost in it). But how
 > it helps to JIT compiler testing?
we have plan to create replacement of current CTW. main goal is to make 
available using CTW in product build. but it must be equals to current 
implementation in terms of functionality. since CTW compile constructor, 
we also must to compile constructor. so we need api for that.

 > Do you know about 'comments' in a code? :)
yes. i know, but i think that all is clear and self-documented :)
but if you insist, i can add javadoc to all public and protected 
methods/fields.

 > Why do you need to set dontinline in costructor?
 > Would be better explicitly call new method from CompilerWhiteBoxTest
 > class when needed:
 >
 > setDontInlineMethod() {
 >    WHITE_BOX.testSetDontInlineMethod(method, true);
 > }
i need to set dontinline in constructor to prevent inlining of 'method' 
into others methods (fix for 8008211).

Best regards,
Igor Ignatyev

On 04/12/2013 11:39 PM, Vladimir Kozlov wrote:
> Igor,
>
> Could you explain why you need j.l.reflect.Constructor in WB compiler
> tests? As java coding exercise it may be good (I am lost in it). But how
> it helps to JIT compiler testing?
>
> Do you know about 'comments' in a code? :)
>
> Using argument 'true' say nothing what it does since the corresponding
> code is in different class file:
>
> +        super(testCase, true);
>
> Why do you need to set dontinline in costructor?
> Would be better explicitly call new method from CompilerWhiteBoxTest
> class when needed:
>
> setDontInlineMethod() {
>    WHITE_BOX.testSetDontInlineMethod(method, true);
> }
>
> Regards,
> Vladimir
>
> On 4/12/13 8:29 AM, Igor Ignatyev wrote:
>> Hi all,
>>
>> Please review patch.
>>
>> 1. changed signature of all methods where j.l.reflect.Method is used
>> 2. added tests which use j.l.reflect.Constructor
>>
>> webrev: http://cr.openjdk.java.net/~iignatyev/8011971/webrev.00/
>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011971

From vladimir.kozlov at oracle.com  Fri Apr 12 13:59:40 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 12 Apr 2013 13:59:40 -0700
Subject: RFR(S) : 8011971 : WB API doesn't accept j.l.reflect.Constructor
In-Reply-To: <51686B41.3060502@oracle.com>
References: <51682863.3020800@oracle.com> <516862E0.5080109@oracle.com>
	<51686B41.3060502@oracle.com>
Message-ID: <516875BC.9000308@oracle.com>

On 4/12/13 1:14 PM, Igor Ignatyev wrote:
>  > Could you explain why you need j.l.reflect.Constructor in WB compiler
>  > tests? As java coding exercise it may be good (I am lost in it). But how
>  > it helps to JIT compiler testing?

Here is a good comment ;) :

> we have plan to create replacement of current CTW. main goal is to make
> available using CTW in product build. but it must be equals to current
> implementation in terms of functionality. since CTW compile constructor,
> we also must to compile constructor. so we need api for that.
>
>  > Do you know about 'comments' in a code? :)
> yes. i know, but i think that all is clear and self-documented :)
> but if you insist, i can add javadoc to all public and protected
> methods/fields.

Please, do. Especially for methods and tests classes.

>
>  > Why do you need to set dontinline in costructor?
>  > Would be better explicitly call new method from CompilerWhiteBoxTest
>  > class when needed:
>  >
>  > setDontInlineMethod() {
>  >    WHITE_BOX.testSetDontInlineMethod(method, true);
>  > }
> i need to set dontinline in constructor to prevent inlining of 'method'
> into others methods (fix for 8008211).

I meant, why you need to do it in 'super' constructor?
You can call setDontInlineMethod() in local constructor. Test methods 
will be executed only after constructor executed.

Thanks,
Vladimir

>
> Best regards,
> Igor Ignatyev
>
> On 04/12/2013 11:39 PM, Vladimir Kozlov wrote:
>> Igor,
>>
>> Could you explain why you need j.l.reflect.Constructor in WB compiler
>> tests? As java coding exercise it may be good (I am lost in it). But how
>> it helps to JIT compiler testing?
>>
>> Do you know about 'comments' in a code? :)
>>
>> Using argument 'true' say nothing what it does since the corresponding
>> code is in different class file:
>>
>> +        super(testCase, true);
>>
>> Why do you need to set dontinline in costructor?
>> Would be better explicitly call new method from CompilerWhiteBoxTest
>> class when needed:
>>
>> setDontInlineMethod() {
>>    WHITE_BOX.testSetDontInlineMethod(method, true);
>> }
>>
>> Regards,
>> Vladimir
>>
>> On 4/12/13 8:29 AM, Igor Ignatyev wrote:
>>> Hi all,
>>>
>>> Please review patch.
>>>
>>> 1. changed signature of all methods where j.l.reflect.Method is used
>>> 2. added tests which use j.l.reflect.Constructor
>>>
>>> webrev: http://cr.openjdk.java.net/~iignatyev/8011971/webrev.00/
>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011971

From christian.thalinger at oracle.com  Fri Apr 12 14:03:35 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 12 Apr 2013 14:03:35 -0700
Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp
	stub [Was: Re: RFR (S): Specify offset of IC load in
	java_to_interp stub.]
In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFB1EDE@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC0CFA7D32@DEWDFEMB12A.global.corp.sap>
	<03C4DFDE-CD52-446E-92AA-A6F12903FE29@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB116E@DEWDFEMB12A.global.corp.sap>
	<7D07437F-CFF7-4298-B9A1-DE9F2E32D77D@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB1EDE@DEWDFEMB12A.global.corp.sap>
Message-ID: <8A8B46F8-0C91-4E8C-950A-0E65095DB2E0@oracle.com>


On Apr 11, 2013, at 2:46 PM, "Lindenmaier, Goetz"  wrote:

> Hi all,
> 
> I prepared the webrev for the changes discussed below:
> http://cr.openjdk.java.net/~goetz/webrevs/8003853/
> 
> To fix the issues we have with the PPC port with finding ICs, this change 
> cleans up the code handling compiled static Java calls:
> - Methods using native instructions are moved from compiledIC.cpp
>   to compiledIC_.cpp.
> - Methods emitting the call patched by CompiledStaticCall are
>   moved from the ad file to this class.
>   As a side effect this reduces redundancies in x86_64.ad and x86_32.ad.
> - We get rid of extern declarations in output.cpp.

I like this.  Two comments:

1) Does it make sense to have emit_to_interp_stub when it's only used in one place?

2) Before we can push this someone has to do the same thing for ARM and PPC.  Any volunteers from the embedded team?

-- Chris

> 
> Now all code concerning CompiledStaticCalls is collected in one class.
> The PPC port needs not change shared code any more to implement them.
> I also got around to move code to MacroAssembler, as only a simple call 
> was needed on x86 and sparc.
> 
> Probably this is (M) now, no more (S).
> 
> Please review and send comments.  I'll be happy to adapt to them!
> 
> Best regards,
>  Goetz Lindenmaier
> 
> -----Original Message-----
> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
> Sent: Thursday, April 11, 2013 4:50 AM
> To: Lindenmaier, Goetz
> Cc: 'hotspot-compiler-dev at openjdk.java.net'
> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
> 
> 
> On Apr 9, 2013, at 7:35 AM, "Lindenmaier, Goetz"  wrote:
> 
>> Hi Chris, 
>> 
>> I'm now working on this issue.  Sorry for the delay...
>> 
>> What do you think about moving 
>>   void emit_java_to_interp(CodeBuffer& cbuf);
>> and
>>  void size_java_to_interp();
>> to compiledIC.hpp and the new platform file, too?
> 
> I like that.
> 
>> 
>> This would also allow to overcome the ugly 
>>  extern uint size_java_to_interp();
>> in output.cpp, as it could be replaced by CompiledStaticCall::size_java_to_interp().
> 
> Great.
> 
>> 
>> I also would like to name this
>> CompiledStaticCall::emit_to_interp_stub()
>> CompiledStaticCall::to_interp_stub_size()
> 
> I'm okay with that.  Not sure if others have objections.
> 
>> 
>> I could also extract code from enc_class Java_Static_Call 
>> to form a routine
>> CompiledStaticCall::emit_call(CodeBuffer *cbuf, intptr_t entry_point, relocInfo::relocType rtype) {
>>   emit_call_reloc(cbuf, entry_point, rtype)
>>   if (rtype != relocInfo::runtime_call_type) {
>>       emit_java_to_interp(cbuf);
>>     }
>> }
>> With this, also 
>> extern uint reloc_java_to_interp();
>> from output.cpp could be moved into this class.
> 
> On SPARC only or the other architectures as well?
> 
>> 
>> Then handling of CompiledStaticCalls would be completely implemented in this
>> one class.
> 
> That's tempting.
> 
>> 
>> (I would have to move emit_call_reloc to MacroAssembler.)
> 
> Could you send a webrev with these changes?
> 
> -- Chris
> 
>> 
>> Best regards,
>> Goetz.
>> 
>> 
>> 
>> -----Original Message-----
>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>> Sent: Montag, 25. M?rz 2013 23:29
>> To: Lindenmaier, Goetz
>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>> 
>> 
>> On Mar 4, 2013, at 8:34 AM, "Lindenmaier, Goetz"  wrote:
>> 
>>> Hi Chris, 
>>> 
>>> I would like to take up this issue again. 
>>> I'm about to put our changes on the jdk8 branch, and it would be convenient
>>> to have a final solution for this.
>>> 
>>> Should I prepare a webrev with a different solution adding a new file
>>> for this?  What should go into that file? 
>> 
>> Sorry for answering that late.
>> 
>> Yes, to see a patch for that would be good.  We need to put all platform dependent Compiled* methods in that new file.  Platform dependent means every method that uses a native* method from nativeInst_:
>> 
>> CompiledIC::cleanup_call_site
>> CompiledIC::is_icholder_call_site
>> CompiledIC::CompiledIC
>> 
>> CompiledStaticCall::set_to_interpreted
>> CompiledStaticCall::set_stub_to_clean
>> CompiledStaticCall::verify
>> 
>> -- Chris
>> 
>>> 
>>> Best regards,
>>> Goetz.
>>> 
>>> 
>>> 
>>> -----Original Message-----
>>> From: goetz.lindenmaier at sap.com 
>>> Sent: Dienstag, 18. Dezember 2012 10:42
>>> To: 'Christian Thalinger'
>>> Subject: RE: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>> 
>>> Hi Chris, 
>>> 
>>> What would you put into that file?  The offset, or the class CompiledStaticCall?
>>> You could also put it into nativeInst_  to avoid adding another file.
>>> 
>>> But basically I think the offset is the best solution, because it's very small
>>> and straight forward, and the offset is set where the code is generated 
>>> that defines the offset.
>>> 
>>> Only the #ifndef COMPILER2 is ugly, but here I think the solution is to 
>>> guard the whole class CompiledStaticCall with #ifdef COMPILER2.
>>> 
>>> But I'm happy with any placement of the code.
>>> 
>>> Best regards,
>>> Goetz.
>>> 
>>> 
>>> 
>>> -----Original Message-----
>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>> Sent: Montag, 17. Dezember 2012 21:34
>>> To: Lindenmaier, Goetz
>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>> 
>>> 
>>> On Nov 29, 2012, at 2:10 PM, "Lindenmaier, Goetz"  wrote:
>>> 
>>>> Hi Chris, 
>>>> 
>>>> Loading the constant takes 5 instructions, the other way only three,
>>>> in the code only one, if the constant pool base is in a register.
>>>> The 5 instructions are hard to patch atomically.  The constant pool 
>>>> is just a 64 bit store.  
>>>> 
>>>>> Sorry for being so persistent on this :-)  
>>>> That's ok, I already found several places in our VM where it was easy to 
>>>> change our code to get along without the shared changes we did in 
>>>> first place.  But I can't redesign everything, and I can not risk to break
>>>> anything in our product.
>>>> 
>>>> If you feel like doing so, you can have a look at 
>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/600ce596eea9
>>>> which contains our bytecode interpreter profiling implementation.
>>>> If you think this is currently of use in the main branch, I would lift it to HS25 
>>>> (the permgen changes might cause trouble) and contribute it to hsx.
>>> 
>>> Sorry for the long delay.
>>> 
>>> Thinking about this problem again it seems that the correct solution would be to have a compiledIC_.cpp file.
>>> 
>>> The CompiledIC instruction layout is platform dependent; it just happens to be the same for all architectures we have right now (well, except PPC) because we made it to be the same.  Actually on SPARC we could also use a load from the constant table which would be simpler.
>>> 
>>> Having a platform dependent file for this code feels right.  What do you think?
>>> 
>>> -- Chris
>>> 
>>>> 
>>>> Best regards,
>>>> Goetz.
>>>> 
>>>> -----Original Message-----
>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>> Sent: Thursday, November 29, 2012 7:53 PM
>>>> To: Lindenmaier, Goetz
>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>> 
>>>> 
>>>> On Nov 29, 2012, at 12:27 AM, "Lindenmaier, Goetz"  wrote:
>>>> 
>>>>> Hi Chris, 
>>>>> 
>>>>>> Why can't you point the relocation to the method load instruction?  It doesn't seem right to do that in shared code.
>>>>> Because the relocation is used 
>>>>> 1.) to find the beginning of the stub to patch the call to go there 
>>>>> 2.) to find the load to patch the IC.
>>>> 
>>>> Got it.
>>>> 
>>>>> 
>>>>> Just have a look at CompiledStaticCall::set_to_interpreted(),
>>>>> the variable 'stub' is used twice.  
>>>> 
>>>> Sorry for being so persistent on this :-)  What is the reason you have to load the constant from the constant table?  On other architectures we materialize the constant.
>>>> 
>>>> -- Chris
>>>> 
>>>>> 
>>>>> Best regards, 
>>>>> Goetz.
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>> Sent: Donnerstag, 29. November 2012 01:35
>>>>> To: Lindenmaier, Goetz
>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>> 
>>>>> 
>>>>> On Nov 27, 2012, at 4:24 AM, "Lindenmaier, Goetz"  wrote:
>>>>> 
>>>>>> Hi Chris,
>>>>>> 
>>>>>>> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub?
>>>>>> Shared code (class CompiledStaticCall) wants to patch the inline cache 
>>>>>> in the stub which is emitted in platform code.
>>>>>> So the platform code should specify how the shared code can find the inline cache 
>>>>>> in the stub, which it does through the constant I introduced.
>>>>>> 
>>>>>>> Do you need two relocations?  I'm confused.
>>>>>> No, three ;)
>>>>>> The relocation you mention is used to find the stub given the call.
>>>>>> The other relocations are needed to find the inline cache / call target
>>>>>> once the stub is found (see CompiledStaticCall::set_to_interpreted()).
>>>>>> It's just the same on x86_64:
>>>>>> 
>>>>>> // static stub relocation stores the instruction address of the call
>>>>>> __ relocate(static_stub_Relocation::spec(mark), RELOC_IMM64); 
>>>>>> // static stub relocation also tags the methodOop in the code-stream.
>>>>>> __ movoop(rbx, (jobject) NULL);  // method is zapped till fixup time
>>>>>> // This is recognized as unresolved by relocs/nativeinst/ic code
>>>>>> __ jump(RuntimeAddress(__ pc()));
>>>>>> 
>>>>>> On PPC, we have to load the base of the constant table after generating the 
>>>>>> static_stub_relocation and before emitting the ppc equivalent for moveoop(). This offset is 
>>>>>> exactly what we store in the  CompiledStaticCall::comp_to_int_load_offset constant.
>>>>> 
>>>>> Why can't you point the relocation to the method load instruction?  It doesn't seem right to do that in shared code.
>>>>> 
>>>>> -- Chris
>>>>> 
>>>>>> 
>>>>>> Best regards,
>>>>>> Goetz.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>>> Sent: Dienstag, 27. November 2012 01:53
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>>> 
>>>>>> 
>>>>>> On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz"  wrote:
>>>>>> 
>>>>>>> Hi Chris,
>>>>>>> 
>>>>>>> We put it into the ad file because it describes an offset into the stub that is
>>>>>>> generated from the ad file by emit_java_to_interp(CodeBuffer& cbuf), 
>>>>>>> used by ir  node CallStaticJavaDirect.  Maybe I should not call it stub, but it's 
>>>>>>> generated into the stubs section of the code buffer.
>>>>>>> If that stub generator is moved out of the ad file to shared compiler code, one should
>>>>>>> move the field with it, but for the current implementation I think that's fine.
>>>>>>> 
>>>>>>> Does C1 generate the same stub? Or is the CompiledStaticCall a C2 feature?
>>>>>>> If so, one could protect the whole thing by #ifdef COMPILER2.
>>>>>> 
>>>>>> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub?
>>>>>> 
>>>>>> // Create a static stub relocation which relates this stub
>>>>>> // with the call instruction at insts_call_instruction_offset in the
>>>>>> // instructions code-section.
>>>>>> __ relocate(static_stub_Relocation::spec(__ code()->insts()->start() + insts_relocation_offset));
>>>>>> 
>>>>>> Do you need two relocations?  I'm confused.
>>>>>> 
>>>>>> -- Chris
>>>>>> 
>>>>>>> 
>>>>>>> Thanks for all the bugids!
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> Goetz.
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>>>> Sent: Mittwoch, 21. November 2012 19:53
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>> Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>>>> 
>>>>>>> 
>>>>>>> On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz"  wrote:
>>>>>>> 
>>>>>>>> Hi Chris, 
>>>>>>>> 
>>>>>>>> yes, there is no C1 on ppc.  
>>>>>>>> We do tiered compilation with a stripped C2.
>>>>>>> 
>>>>>>> Right.  But some other architecture (or in the future) might need this for C1 as well.  We should find a better place for the value than the ad file.  The obvious place would be compiledIC_.hpp but we don't have that file, yet.
>>>>>>> 
>>>>>>> I filed:
>>>>>>> 
>>>>>>> 8003853: specify offset of IC load in java_to_interp stub
>>>>>>> 
>>>>>>> -- Chris
>>>>>>> 
>>>>>>>> 
>>>>>>>> Best regards,
>>>>>>>> Goetz
>>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>>>>> Sent: Dienstag, 20. November 2012 22:19
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>> Subject: Re: RFR (S): Specify offset of IC load in java_to_interp stub.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz"  wrote:
>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub
>>>>>>>>> to update the IC  with NativeMovConstReg.  The current implementation assumes that
>>>>>>>>> the load is always the first instruction in the stub.  This is an artificial restriction. E.g.,
>>>>>>>>> it might be useful to load the constant pool address (MachConstantBase) before the
>>>>>>>>> IC load (as we do on PPC).
>>>>>>>>> 
>>>>>>>>> This change adds a constant specifying an offset from the beginning of the stub to
>>>>>>>>> the  IC load. The offset is platform specific and 0 on sparc and x86.
>>>>>>>>> 
>>>>>>>>> You can find the change here:
>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/
>>>>>>>> 
>>>>>>>> That should be fixed indeed.  
>>>>>>>> 
>>>>>>>> +#ifndef COMPILER2
>>>>>>>> +const int CompiledStaticCall::comp_to_int_load_offset = 0;
>>>>>>>> 
>>>>>>>> There is no C1 for PPC (sorry, I didn't check)?
>>>>>>>> 
>>>>>>>> -- Chris
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> or in our ppc port:
>>>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33
>>>>>>>>> 
>>>>>>>>> Thank you and best regards,
>>>>>>>>> Goetz
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


From yumin.qi at oracle.com  Fri Apr 12 14:07:03 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Fri, 12 Apr 2013 14:07:03 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <5168482F.6040607@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
Message-ID: <51687777.1070500@oracle.com>

After take feedback and modify, new webrev

http://cr.openjdk.java.net/~minqi/8010992/webrev1 




Thanks
Yumin

On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
> .
>>> cardTableModRefBS.cpp
>>>   #87 and #88, why set_start(NULL) are needed?
>>>
>> This is default constructor does, here just copy that code. Since we 
>> did not call constructor by using this MACRO. It is a _ValueObj, 
>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which 
>> will call ctors.
> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what 
> allocation.hpp #618 does.
>
> Thanks,
>
> -Zhengyu
>
>
>>> carTableRS.cpp
>>>   #70, why it is commented out? If so, you don't need the dstor
>>>
>>>
>> See reply to David H.
>>
>>
>> Thanks
>> Yumin
>>> -Zhengyu
>>>
>>>
>>>
>>>
>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>> Hi,
>>>>
>>>>   Can I have your inputs for the fix?
>>>>   webrev:
>>>>
>>>>  http://cr.openjdk.java.net/~minqi/8010992/webrev/ 
>>>> 
>>>>
>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>
>>>> Problem description:  Remove the usage of global operator ::new[] 
>>>> and ::new. In hotspot debug build, disable the usage of global 
>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it 
>>>> cannot prevent third party code to catch such exceptions.  By 
>>>> disabling use of global operator new[] and new, we constrain the 
>>>> exception disposal within hotspot. C++ classes (as same for 
>>>> structs) in hotspot have to either extends from CHeapObj or 
>>>> ResourceObj unless they are stack objects or values which have to 
>>>> be from StackObj or _ValueObj respectively.  Or they have to 
>>>> implement their own operator new[] or new.
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>>
>>>
>>
>


From christian.thalinger at oracle.com  Fri Apr 12 14:18:38 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 12 Apr 2013 14:18:38 -0700
Subject: RFR(M) 8011621: Keep the "live range id - node" mapping in a
	separate class
In-Reply-To: <51684F15.10701@oracle.com>
References: <941B0F67-1B66-45EF-8150-BB9F435EB9CD@oracle.com>
	<51630DAA.8060906@oracle.com>
	<2650A2B9-507B-4031-BF2F-CA636160197E@oracle.com>
	<51684F15.10701@oracle.com>
Message-ID: <166470D8-5C28-4904-95C9-3400BFE00ECB@oracle.com>


On Apr 12, 2013, at 11:14 AM, Vladimir Kozlov  wrote:

> Hurray :) more dead code removed.

Now that the chaitin_.cpp files are gone I think we can remove these references in the Makefiles:

$ ack -a chaitin make/
make/bsd/makefiles/vm.make
190:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*

make/linux/makefiles/vm.make
192:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*

make/solaris/makefiles/vm.make
205:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*

make/windows/create_obj_files.sh
117:COMPILER2_SPECIFIC_FILES="opto libadt bcEscapeAnalyzer.cpp chaitin* c2_* runtime_*"

-- Chris

> 
> Move small PhaseChaitin::clone_projs() methods which calls clone_projs_shared() into the header file.
> 
> May be you should move the rest of PhaseChaitin methods from coalesce.cpp to chaitin.cpp where they are logically belong.
> 
> You added clone_projs() to PhaseCoalesce class but it is not defined or used.
> 
> Thanks,
> Vladimir
> 
> On 4/12/13 5:01 AM, Niclas Adlertz wrote:
>> Hi again,
>> 
>> Thank you for your comments.
>> 
>> Vladimir:
>> ---------
>> 
>>> ${JAVA_HOME}/bin/java -server -Xss4m -verify -XX:+CompileTheWorld -XX:+TimeCompiler -Xbootclasspath/p:${JAVA_HOME}/jre/lib/rt.jar
>> 
>> Base: Total compilation: 2235.880 sec.
>> Fix: Total compilation: 2226.020 sec.
>> 
>> So the fix should be ok in terms of compilation time.
>> 
>>> Can you use full name LiveRangeMap instead of LRGMap?
>> Sure, fixed.
>> 
>>> Don't put big methods with loops into header file, we don't want to increase code size without need.
>> Ok, fixed.
>> 
>>> Explicitly declare private: and public: parts in class. Add comment what is class for.
>> Done.
>> 
>>> I like Roland's suggestion (LRGMap _lrg_map;) because it avoids a reference through _lrg_map pointer (in compiled code C++ needs only one PhaseChaitin* pointer).
>> Done.
>> 
>> Roland:
>> -------
>> 
>>> In vmStructs.cpp, you need to add a declaration for PhaseChaitin::_lrg_map otherwise:
>>> c2_nonstatic_field(LRGMap,             _max_lrg_id,              uint)
>>> is useless.
>> I removed it from vmStructs.cpp completely instead, since it's not used by the agent.
>> 
>>> Why not declare: LRGMap _lrg_map; rather than stack allocate it and set a pointer.
>> I just followed the old pattern, but that's a good remark, thank you.
>> Fixed.
>> 
>>> Can you add comments describing what LRGMap is before its declaration?
>>> 
>>> Shouldn't that:
>>> 242   if (C->unique() > _lrg_map->_names.Size()) {
>>> 243     _lrg_map->_names.extend(C->unique() - 1, 0);
>>> 244   }
>>> 
>>> be moved to the LRGMap constructor?
>> 
>> This code is not necessary anymore, because I also took the liberty of removing
>> pd_preallocate_hook();
>> and
>> pd_postallocate_verify_hook();
>> 
>> which are not needed anymore because they only added nodes for Win95 and Win 98.
>> 
>>> Shouldn't you make _max_lrg_id, _uf_map and _names private and have accessors?
>> I have now made public methods for performing operations on _max_lrg_id, _uf_map and _names.
>> 
>> ---------
>> 
>> The new webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011621/webrev02/
>> 
>> Thank you.
>> 
>> Regards,
>> Niclas Adlertz
>> 
>> On 8 apr 2013, at 20:34, Vladimir Kozlov wrote:
>> 
>>> Niclas,
>>> 
>>> Thank you for doing this cleanup.
>>> 
>>> Please, test affection on RA performance. You can use CTW for this and fastdebug VM:
>>> 
>>> ${JAVA_HOME}/bin/java -server -Xss4m -verify -XX:+CompileTheWorld -XX:+TimeCompiler -Xbootclasspath/p:${JAVA_HOME}/jre/lib/rt.jar
>>> 
>>> Or build optimized VM and run jvm08, for example, with -XX:+TimeCompiler.
>>> 
>>> Can you use full name LiveRangeMap instead of LRGMap?
>>> Don't put big methods with loops into header file, we don't want to increase code size without need.
>>> 
>>> Explicitly declare private: and public: parts in class. Add comment what is class for.
>>> 
>>> I like Roland's suggestion (LRGMap _lrg_map;) because it avoids a reference through _lrg_map pointer (in compiled code C++ needs only one PhaseChaitin* pointer).
>>> 
>>> Thanks,
>>> Vladimir
>>> 
>>> On 4/8/13 3:05 AM, Niclas Adlertz wrote:
>>>> Hi all.
>>>> 
>>>> Problem:
>>>> In order to clean up the Split code (in opto/reg_split.cpp) making it easier to maintain and (hopefully) making it easier to improve (https://jbs.oracle.com/bugs/browse/JDK-7022320), it would be good to have the Split code more isolated with as few dependencies to other parts of the code as possible.
>>>> The Split code could reside in an own module (class), just having references to classes and data it really needs. Right now it would need to have a reference to PhaseChaitin, only to access the "live range id - node" mapping. However, it does not need to know about everything in the PhaseChaitin class. This may also introduce cross reference problems since PhaseChaitin would use the Split module and the Split module would need a reference to PhaseChaitin.
>>>> 
>>>> Solution:
>>>> Move the "live range id - node" mapping to a separate class, instantiated by PhaseChaitin, which can then be passed to the Split module as a reference.
>>>> 
>>>> Regards,
>>>> Niclas Adlertz
>>>> 
>>>> (Note that the webrev title is named JDK-7022320. That's just the local folder name that the code resides in. The bug is indeed 8011621)
>>>> 
>>>> -----------------------------------------------------------------
>>>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011621/webrev00/
>>>>    jbs: https://jbs.oracle.com/bugs/browse/JDK-8011621
>>>>   bugs: http://bugs.sun.com/view_bug.do?bug_id=8011621
>>>> 
>>>> 
>> 


From vladimir.kozlov at oracle.com  Fri Apr 12 15:14:35 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 12 Apr 2013 15:14:35 -0700
Subject: RFR(S) : 8011675: adding compilation level to replay data
In-Reply-To: <516827EA.3040001@oracle.com>
References: <51631AEA.9080702@oracle.com> <51635E89.30808@oracle.com>
	<5163BD9A.5080308@oracle.com> <5163C5F4.7020605@oracle.com>
	<516827EA.3040001@oracle.com>
Message-ID: <5168874B.9080407@oracle.com>

I would set CrashAfterCompileId default to -1 as indication it is not 
set. Then you don't need to check CrashAfterCompileId == 0 since 
compile_id is positive. By the way, it is very nice idea but add a 
comment about what that code for. I did not get it first :)

About name. For such flags we use CI: CIBreakAt, CIStop. So I would 
suggest to use CICrashAt. Which means VM crash with that compile id, not 
when it is greater.

If you replaying C1 compilation next setting will be incorrect. Should 
we use CompLevel_highest_tier instead so that following check pass?:

+     if (had_error() && (error_message() == comp_level_label)) {
+       comp_level = CompLevel_full_optimization;


About tests.

Add -Xmx32m, -XX:ParallelGCThreads=2 and other flags (codecache 
,metaspace) to limit core size on big machines.

Add tests for tiered with different -XX:TieredStopAtLevel=n.

I would add more info in output why the test is skipped:
      echo TEST SKIPPED

typo 'java':
  124 is_tiered=`${JAVA} ${TESTVMOPTS} java -XX:+PrintFlagsFinal 
-version 2>&1 | grep TieredCompilation | grep -c true`


I don't like next:

  130 ${JAVA} ${TESTVMOPTS} -Xcomp -XX:CrashAfterCompileId=1 
-XX:+CreateMinidumpOnCrash -XX:+DumpReplayDataOnError -version &
  131 crash_pid=$!
  132 wait $crash_pid

  On windows 'wait $crash_pid' may not work (happened before) because 
before you execute 'wait' OS may assign the same pid to different process.

You may still not find core file. Or ulimit -c unlimited will not work
(windows, OS X?). You need to bailout in such case as success. Next code 
is incorrect for that:

   48 if [ -z "${core_file}" -o ! -r "${core_file}" ]
   49 then
   50     echo TEST FAILED: core wasn\'t generated
   51     exit 2
   52 fi

Thanks
Vladimir

On 4/12/13 8:27 AM, Igor Ignatyev wrote:
> updated webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.02/
> added:
>    1. more informative message on unsupported comp_level
>    2. not-product flag 'CrashAfterCompileId' and assert in
> compileBroker.cpp for assured generation of replay.txt
>    2. tests for ciReplay
>
> Best regards,
> Igor Ignatyev
>
> On 04/09/2013 11:40 AM, Vladimir Kozlov wrote:
>> Igor,
>>
>> Sorry, I may said it not clear. What I meant is to set error (call
>> report_error()) in such case and return from process_compile() without
>> compilation. But let ciReplay::replay() finish and exit. replay_impl()
>> should print the problem so you don't need to do it in
>> process_compile(). And, please, test it.
>> The message should be more informative, something like:
>> "compilation level %d requires TieredCompilation"
>> An other bad cases is when failure happened in Client (C1) or Server
>> (C2) but the replay is run with opposite VM.
>>
>> thanks,
>> Vladimir
>>
>> On 4/9/13 12:04 AM, Igor Ignatyev wrote:
>>> Vladimir,
>>>
>>> Thank you for review.
>>>
>>> updated webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.01/
>>>
>>> Best regards,
>>> Igor Ignatyev
>>>
>>> On 04/09/2013 04:19 AM, Vladimir Kozlov wrote:
>>>> Igor,
>>>>
>>>> Thank you for fixing and cleaning this.
>>>>
>>>> In vmStructs.cpp move _comp_level after _compile_id as in nmethod
>>>> class.
>>>>
>>>> Typo in ciReplay.cpp:
>>>> +      comp_level != CompLevel_highest_tier;
>>>>
>>>> Actually it is useless to replay compilation at different level, it
>>>> should exit with error. Could happened because incorrectly run without
>>>> Tiered when the crush happened with Tiered.
>>>>
>>>> In ciReplay.cpp use parenthesis around equality checks: if (. && (. ==
>>>> .)).
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 4/8/13 12:30 PM, Igor Ignatyev wrote:
>>>>> Hi all,
>>>>>
>>>>> Please review patch.
>>>>>
>>>>> Problem:
>>>>> Replay of compilations supports c1 and tiered as well as c2, the only
>>>>> thing missing is comp_level.
>>>>>
>>>>> Fix:
>>>>> 1. added comp_level into dump and usage during replay
>>>>> 2. minor changes in agent/doc:
>>>>>    - escaped '<', '>'
>>>>>    - renamed 'C2 Replay'/'C2 compiler replay' to 'Replay'/'Compiler
>>>>> replay'
>>>>>
>>>>> Testing:
>>>>> manually launched the replay from JDK-8010934 (assert specifically to
>>>>> c1) on jvm w/o corresponded fix. assert was triggered w/ patch and
>>>>> wasn't triggered w/o.
>>>>>
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.00/
>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011675

From christian.thalinger at oracle.com  Fri Apr 12 15:32:02 2013
From: christian.thalinger at oracle.com (christian.thalinger at oracle.com)
Date: Fri, 12 Apr 2013 22:32:02 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 8011933: add number of classes,
	methods and time spent to CompileTheWorld
Message-ID: <20130412223205.54FBA482A1@hg.openjdk.java.net>

Changeset: b8b081e53312
Author:    twisti
Date:      2013-04-12 12:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b8b081e53312

8011933: add number of classes, methods and time spent to CompileTheWorld
Reviewed-by: jrose, kvn

! src/share/vm/classfile/classLoader.cpp
! src/share/vm/classfile/classLoader.hpp


From christian.thalinger at oracle.com  Fri Apr 12 17:33:02 2013
From: christian.thalinger at oracle.com (christian.thalinger at oracle.com)
Date: Sat, 13 Apr 2013 00:33:02 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 8011678: test/Makefile should pick up
	JT_HOME environment variable
Message-ID: <20130413003305.BBF95482A5@hg.openjdk.java.net>

Changeset: 393fd4ef89c4
Author:    twisti
Date:      2013-04-12 15:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/393fd4ef89c4

8011678: test/Makefile should pick up JT_HOME environment variable
Reviewed-by: kvn

! test/Makefile


From vladimir.kozlov at oracle.com  Fri Apr 12 19:10:55 2013
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Sat, 13 Apr 2013 02:10:55 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets
Message-ID: <20130413021101.3BF1D482AE@hg.openjdk.java.net>

Changeset: f36e073d56a4
Author:    drchase
Date:      2013-04-12 15:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f36e073d56a4

7104565: trim jprt build targets
Summary: remove JPRT debug builds, remove -DDEBUG -DFASTDEBUG and use ASSERT instead in sources
Reviewed-by: dholmes, kvn, coleenp

! make/Makefile
! make/bsd/Makefile
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/debug.make
! make/bsd/makefiles/defs.make
! make/bsd/makefiles/fastdebug.make
- make/bsd/makefiles/jvmg.make
- make/bsd/makefiles/profiled.make
! make/jprt.properties
! make/linux/Makefile
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/debug.make
! make/linux/makefiles/defs.make
! make/linux/makefiles/fastdebug.make
- make/linux/makefiles/jvmg.make
- make/linux/makefiles/profiled.make
! make/solaris/Makefile
! make/solaris/makefiles/buildtree.make
! make/solaris/makefiles/debug.make
! make/solaris/makefiles/defs.make
! make/solaris/makefiles/fastdebug.make
- make/solaris/makefiles/jvmg.make
- make/solaris/makefiles/profiled.make
! make/windows/build.make
! make/windows/makefiles/defs.make
! make/windows/makefiles/vm.make
! make/windows/projectfiles/compiler2/ADLCompiler.dsp
! make/windows/projectfiles/tiered/ADLCompiler.dsp
! src/cpu/sparc/vm/frame_sparc.cpp
! src/os/bsd/dtrace/generateJvmOffsets.cpp
! src/os/solaris/dtrace/generateJvmOffsets.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/tools/hsdis/Makefile
! src/share/vm/classfile/stackMapFrame.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/runtime/vmThread.cpp

Changeset: bc63dd2539a4
Author:    kvn
Date:      2013-04-12 20:37 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bc63dd2539a4

Merge

! make/bsd/makefiles/debug.make
- make/bsd/makefiles/jvmg.make
- make/bsd/makefiles/profiled.make
! make/linux/makefiles/debug.make
- make/linux/makefiles/jvmg.make
- make/linux/makefiles/profiled.make
! make/solaris/makefiles/debug.make
- make/solaris/makefiles/jvmg.make
- make/solaris/makefiles/profiled.make


From vladimir.kozlov at oracle.com  Fri Apr 12 21:31:10 2013
From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com)
Date: Sat, 13 Apr 2013 04:31:10 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 6443505: Ideal() function for CmpLTMask
Message-ID: <20130413043115.EB43B482B3@hg.openjdk.java.net>

Changeset: 886d1fd67dc3
Author:    drchase
Date:      2013-04-12 19:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/886d1fd67dc3

6443505: Ideal() function for CmpLTMask
Summary: Repair wrong code generation, added new matching rule
Reviewed-by: kvn, twisti

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/opto/cfgnode.cpp
+ test/compiler/6443505/Test6443505.java


From igor.ignatyev at oracle.com  Sat Apr 13 12:14:42 2013
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Sat, 13 Apr 2013 23:14:42 +0400
Subject: RFR(S) : 8011675: adding compilation level to replay data
In-Reply-To: <5168874B.9080407@oracle.com>
References: <51631AEA.9080702@oracle.com> <51635E89.30808@oracle.com>
	<5163BD9A.5080308@oracle.com> <5163C5F4.7020605@oracle.com>
	<516827EA.3040001@oracle.com> <5168874B.9080407@oracle.com>
Message-ID: <5169AEA2.7060103@oracle.com>

> If you replaying C1 compilation next setting will be incorrect. Should
> we use CompLevel_highest_tier instead so that following check pass?:
>
> +     if (had_error() && (error_message() == comp_level_label)) {
> +       comp_level = CompLevel_full_optimization;
>

i added this code for compatible with old version and i think that it 
must has the same behavior (use 'CompLevel_full_optimization'). in new 
version we always will have comp_level in replay.txt.
so i think we shouldn't use CompLevel_highest_tier.

> Add tests for tiered with different -XX:TieredStopAtLevel=n.
what exactly did you mean?
1) generate replay.txt by VM with different value of 'TieredStopAtLevel'
2) use different 'TieredStopAtLevel' during replay of compilation

if 1st, i don't think that test must to iterate through all possible 
values, it must be done by harness, test execution etc
if 2nd, current implementation of ciReplay ignore TieredStopAtLevel 
flags, so these tests will be useless.

> You may still not find core file. Or ulimit -c unlimited will not work
> (windows, OS X?). You need to bailout in such case as success.
for windows i added '-XX:+CreateMinidumpOnCrash', but whatever case of 
not found core-file need to treat as a environment issue, a test bug or 
may even be a product bug. anyway if it happened, i think it would be 
better to know about this than just skip the test.

i updated webrev according to the rest of your suggestions, but i'm not 
sure about flags to limit core size.

also i added one more check of comp_level and moved validation to 
separate method.

http://cr.openjdk.java.net/~iignatyev/8011675/webrev.03/

Best regards,
Igor Ignatyev

On 04/13/2013 02:14 AM, Vladimir Kozlov wrote:
> I would set CrashAfterCompileId default to -1 as indication it is not
> set. Then you don't need to check CrashAfterCompileId == 0 since
> compile_id is positive. By the way, it is very nice idea but add a
> comment about what that code for. I did not get it first :)
>
> About name. For such flags we use CI: CIBreakAt, CIStop. So I would
> suggest to use CICrashAt. Which means VM crash with that compile id, not
> when it is greater.
>
> If you replaying C1 compilation next setting will be incorrect. Should
> we use CompLevel_highest_tier instead so that following check pass?:
>
> +     if (had_error() && (error_message() == comp_level_label)) {
> +       comp_level = CompLevel_full_optimization;
>
>
> About tests.
>
> Add -Xmx32m, -XX:ParallelGCThreads=2 and other flags (codecache
> ,metaspace) to limit core size on big machines.
>
> Add tests for tiered with different -XX:TieredStopAtLevel=n.
>
> I would add more info in output why the test is skipped:
>       echo TEST SKIPPED
>
> typo 'java':
>   124 is_tiered=`${JAVA} ${TESTVMOPTS} java -XX:+PrintFlagsFinal
> -version 2>&1 | grep TieredCompilation | grep -c true`
>
>
> I don't like next:
>
>   130 ${JAVA} ${TESTVMOPTS} -Xcomp -XX:CrashAfterCompileId=1
> -XX:+CreateMinidumpOnCrash -XX:+DumpReplayDataOnError -version &
>   131 crash_pid=$!
>   132 wait $crash_pid
>
>   On windows 'wait $crash_pid' may not work (happened before) because
> before you execute 'wait' OS may assign the same pid to different process.
>
> You may still not find core file. Or ulimit -c unlimited will not work
> (windows, OS X?). You need to bailout in such case as success. Next code
> is incorrect for that:
>
>    48 if [ -z "${core_file}" -o ! -r "${core_file}" ]
>    49 then
>    50     echo TEST FAILED: core wasn\'t generated
>    51     exit 2
>    52 fi
>
> Thanks
> Vladimir
>
> On 4/12/13 8:27 AM, Igor Ignatyev wrote:
>> updated webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.02/
>> added:
>>    1. more informative message on unsupported comp_level
>>    2. not-product flag 'CrashAfterCompileId' and assert in
>> compileBroker.cpp for assured generation of replay.txt
>>    2. tests for ciReplay
>>
>> Best regards,
>> Igor Ignatyev
>>
>> On 04/09/2013 11:40 AM, Vladimir Kozlov wrote:
>>> Igor,
>>>
>>> Sorry, I may said it not clear. What I meant is to set error (call
>>> report_error()) in such case and return from process_compile() without
>>> compilation. But let ciReplay::replay() finish and exit. replay_impl()
>>> should print the problem so you don't need to do it in
>>> process_compile(). And, please, test it.
>>> The message should be more informative, something like:
>>> "compilation level %d requires TieredCompilation"
>>> An other bad cases is when failure happened in Client (C1) or Server
>>> (C2) but the replay is run with opposite VM.
>>>
>>> thanks,
>>> Vladimir
>>>
>>> On 4/9/13 12:04 AM, Igor Ignatyev wrote:
>>>> Vladimir,
>>>>
>>>> Thank you for review.
>>>>
>>>> updated webrev:
>>>> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.01/
>>>>
>>>> Best regards,
>>>> Igor Ignatyev
>>>>
>>>> On 04/09/2013 04:19 AM, Vladimir Kozlov wrote:
>>>>> Igor,
>>>>>
>>>>> Thank you for fixing and cleaning this.
>>>>>
>>>>> In vmStructs.cpp move _comp_level after _compile_id as in nmethod
>>>>> class.
>>>>>
>>>>> Typo in ciReplay.cpp:
>>>>> +      comp_level != CompLevel_highest_tier;
>>>>>
>>>>> Actually it is useless to replay compilation at different level, it
>>>>> should exit with error. Could happened because incorrectly run without
>>>>> Tiered when the crush happened with Tiered.
>>>>>
>>>>> In ciReplay.cpp use parenthesis around equality checks: if (. && (. ==
>>>>> .)).
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 4/8/13 12:30 PM, Igor Ignatyev wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Please review patch.
>>>>>>
>>>>>> Problem:
>>>>>> Replay of compilations supports c1 and tiered as well as c2, the only
>>>>>> thing missing is comp_level.
>>>>>>
>>>>>> Fix:
>>>>>> 1. added comp_level into dump and usage during replay
>>>>>> 2. minor changes in agent/doc:
>>>>>>    - escaped '<', '>'
>>>>>>    - renamed 'C2 Replay'/'C2 compiler replay' to 'Replay'/'Compiler
>>>>>> replay'
>>>>>>
>>>>>> Testing:
>>>>>> manually launched the replay from JDK-8010934 (assert specifically to
>>>>>> c1) on jvm w/o corresponded fix. assert was triggered w/ patch and
>>>>>> wasn't triggered w/o.
>>>>>>
>>>>>>
>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.00/
>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011675

From igor.ignatyev at oracle.com  Sun Apr 14 10:04:24 2013
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Sun, 14 Apr 2013 21:04:24 +0400
Subject: RFR(S) : 8011971 : WB API doesn't accept j.l.reflect.Constructor
In-Reply-To: <516875BC.9000308@oracle.com>
References: <51682863.3020800@oracle.com> <516862E0.5080109@oracle.com>
	<51686B41.3060502@oracle.com> <516875BC.9000308@oracle.com>
Message-ID: <516AE198.1030805@oracle.com>

> Please, do. Especially for methods and tests classes.
i'm really not very good in code's commentation, but i did my best.

in addition to changes according to your suggestions, i added ability to 
specify comp_level in WB::makeMethodNotCompilable() and found some 
strange behavior of 'CompilationPolicy::can_be_compiled':

124   if (comp_level == CompLevel_all) {
125     return !m->is_not_compilable(CompLevel_simple) && 
!m->is_not_compilable(CompLevel_full_optimization);
126   }

if method is 'not_compilable' in C1 or C2, method 'can_be_compiled' will 
return false for 'CompLevel_all' even it is compilable in another level. 
is it expected behavior or it is a bug?

updated webrev: http://cr.openjdk.java.net/~iignatyev/8011971/webrev.01/

Best regards,
Igor Ignatyev

On 04/13/2013 12:59 AM, Vladimir Kozlov wrote:
> On 4/12/13 1:14 PM, Igor Ignatyev wrote:
>>  > Could you explain why you need j.l.reflect.Constructor in WB compiler
>>  > tests? As java coding exercise it may be good (I am lost in it).
>> But how
>>  > it helps to JIT compiler testing?
>
> Here is a good comment ;) :
>
>> we have plan to create replacement of current CTW. main goal is to make
>> available using CTW in product build. but it must be equals to current
>> implementation in terms of functionality. since CTW compile constructor,
>> we also must to compile constructor. so we need api for that.
>>
>>  > Do you know about 'comments' in a code? :)
>> yes. i know, but i think that all is clear and self-documented :)
>> but if you insist, i can add javadoc to all public and protected
>> methods/fields.
>
> Please, do. Especially for methods and tests classes.
>
>>
>>  > Why do you need to set dontinline in costructor?
>>  > Would be better explicitly call new method from CompilerWhiteBoxTest
>>  > class when needed:
>>  >
>>  > setDontInlineMethod() {
>>  >    WHITE_BOX.testSetDontInlineMethod(method, true);
>>  > }
>> i need to set dontinline in constructor to prevent inlining of 'method'
>> into others methods (fix for 8008211).
>
> I meant, why you need to do it in 'super' constructor?
> You can call setDontInlineMethod() in local constructor. Test methods
> will be executed only after constructor executed.
>
> Thanks,
> Vladimir
>
>>
>> Best regards,
>> Igor Ignatyev
>>
>> On 04/12/2013 11:39 PM, Vladimir Kozlov wrote:
>>> Igor,
>>>
>>> Could you explain why you need j.l.reflect.Constructor in WB compiler
>>> tests? As java coding exercise it may be good (I am lost in it). But how
>>> it helps to JIT compiler testing?
>>>
>>> Do you know about 'comments' in a code? :)
>>>
>>> Using argument 'true' say nothing what it does since the corresponding
>>> code is in different class file:
>>>
>>> +        super(testCase, true);
>>>
>>> Why do you need to set dontinline in costructor?
>>> Would be better explicitly call new method from CompilerWhiteBoxTest
>>> class when needed:
>>>
>>> setDontInlineMethod() {
>>>    WHITE_BOX.testSetDontInlineMethod(method, true);
>>> }
>>>
>>> Regards,
>>> Vladimir
>>>
>>> On 4/12/13 8:29 AM, Igor Ignatyev wrote:
>>>> Hi all,
>>>>
>>>> Please review patch.
>>>>
>>>> 1. changed signature of all methods where j.l.reflect.Method is used
>>>> 2. added tests which use j.l.reflect.Constructor
>>>>
>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8011971/webrev.00/
>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011971

From christian.thalinger at oracle.com  Sun Apr 14 22:50:43 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Sun, 14 Apr 2013 22:50:43 -0700
Subject: RFR(S) : 8011971 : WB API doesn't accept j.l.reflect.Constructor
In-Reply-To: <51686B41.3060502@oracle.com>
References: <51682863.3020800@oracle.com> <516862E0.5080109@oracle.com>
	<51686B41.3060502@oracle.com>
Message-ID: <3A60B5DA-5771-4036-B402-FE4872086E62@oracle.com>


On Apr 12, 2013, at 1:14 PM, Igor Ignatyev  wrote:

> > Could you explain why you need j.l.reflect.Constructor in WB compiler
> > tests? As java coding exercise it may be good (I am lost in it). But how
> > it helps to JIT compiler testing?
> we have plan to create replacement of current CTW. main goal is to make available using CTW in product build. but it must be equals to current implementation in terms of functionality. since CTW compile constructor, we also must to compile constructor. so we need api for that.

Interesting.  I just pushed a Java CTW implementation to Graal:

http://cr.openjdk.java.net/~twisti/GRAAL-218/

It (almost) does the same as the implementation in C++.  Somewhere I'm dropping a couple compiles on the floor but I haven't investigated why (probably class initialization or constant pool pre-loading).

-- Chris

> 
> > Do you know about 'comments' in a code? :)
> yes. i know, but i think that all is clear and self-documented :)
> but if you insist, i can add javadoc to all public and protected methods/fields.
> 
> > Why do you need to set dontinline in costructor?
> > Would be better explicitly call new method from CompilerWhiteBoxTest
> > class when needed:
> >
> > setDontInlineMethod() {
> >    WHITE_BOX.testSetDontInlineMethod(method, true);
> > }
> i need to set dontinline in constructor to prevent inlining of 'method' into others methods (fix for 8008211).
> 
> Best regards,
> Igor Ignatyev
> 
> On 04/12/2013 11:39 PM, Vladimir Kozlov wrote:
>> Igor,
>> 
>> Could you explain why you need j.l.reflect.Constructor in WB compiler
>> tests? As java coding exercise it may be good (I am lost in it). But how
>> it helps to JIT compiler testing?
>> 
>> Do you know about 'comments' in a code? :)
>> 
>> Using argument 'true' say nothing what it does since the corresponding
>> code is in different class file:
>> 
>> +        super(testCase, true);
>> 
>> Why do you need to set dontinline in costructor?
>> Would be better explicitly call new method from CompilerWhiteBoxTest
>> class when needed:
>> 
>> setDontInlineMethod() {
>>   WHITE_BOX.testSetDontInlineMethod(method, true);
>> }
>> 
>> Regards,
>> Vladimir
>> 
>> On 4/12/13 8:29 AM, Igor Ignatyev wrote:
>>> Hi all,
>>> 
>>> Please review patch.
>>> 
>>> 1. changed signature of all methods where j.l.reflect.Method is used
>>> 2. added tests which use j.l.reflect.Constructor
>>> 
>>> webrev: http://cr.openjdk.java.net/~iignatyev/8011971/webrev.00/
>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011971


From david.holmes at oracle.com  Sun Apr 14 23:07:30 2013
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 15 Apr 2013 16:07:30 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <51687777.1070500@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com>
Message-ID: <516B9922.4050306@oracle.com>

Hi Yumin,

On 13/04/2013 7:07 AM, Yumin Qi wrote:
> After take feedback and modify, new webrev
>
> http://cr.openjdk.java.net/~minqi/8010992/webrev1
> 

I still find the HandleMark changes unsatisfactory. The CHeap allocated 
HandleMark in the Thread() constructor is a bit of a hack. HandleMarks 
should be stack-allocated. Plus we seem to leak that CHeap allocated 
HandleMark as we don't keep any pointer to it! I think this needs to be 
re-visited, but as a separate CR.

---

allocation.hpp:

If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element 
don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's before 
deallocating ?

---

src/share/vm/utilities/quickSort.cpp

Why does only Solaris need the allocation headers included ?? I would 
expect all platforms to need to the same headers here.

Thanks,
David

>
>
> Thanks
> Yumin
>
> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>> .
>>>> cardTableModRefBS.cpp
>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>
>>> This is default constructor does, here just copy that code. Since we
>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which
>>> will call ctors.
>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>> allocation.hpp #618 does.
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>
>>>> carTableRS.cpp
>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>
>>>>
>>> See reply to David H.
>>>
>>>
>>> Thanks
>>> Yumin
>>>> -Zhengyu
>>>>
>>>>
>>>>
>>>>
>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>> Hi,
>>>>>
>>>>>   Can I have your inputs for the fix?
>>>>>   webrev:
>>>>>
>>>>>  http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>> 
>>>>>
>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>
>>>>> Problem description:  Remove the usage of global operator ::new[]
>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>> disabling use of global operator new[] and new, we constrain the
>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>> ResourceObj unless they are stack objects or values which have to
>>>>> be from StackObj or _ValueObj respectively.  Or they have to
>>>>> implement their own operator new[] or new.
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>
>>>>>
>>>>
>>>
>>
>

From goetz.lindenmaier at sap.com  Mon Apr 15 01:49:02 2013
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 15 Apr 2013 08:49:02 +0000
Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp
	stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp
	stub.]
In-Reply-To: <8A8B46F8-0C91-4E8C-950A-0E65095DB2E0@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC0CFA7D32@DEWDFEMB12A.global.corp.sap>
	<03C4DFDE-CD52-446E-92AA-A6F12903FE29@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB116E@DEWDFEMB12A.global.corp.sap>
	<7D07437F-CFF7-4298-B9A1-DE9F2E32D77D@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB1EDE@DEWDFEMB12A.global.corp.sap>
	<8A8B46F8-0C91-4E8C-950A-0E65095DB2E0@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC0CFB24B3@DEWDFEMB12A.global.corp.sap>

Hi Goetz,

to 1).
I kept it seperate because it was like that before. Further it shows the separation of 
concerns: one emits to the code section, the other an isolated stub.
But I'll inline it if you like, it's only static in that file anyways.

Best regards,
  Goetz.


-----Original Message-----
From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
Sent: Freitag, 12. April 2013 23:04
To: Lindenmaier, Goetz
Cc: 'hotspot-compiler-dev at openjdk.java.net'
Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]


On Apr 11, 2013, at 2:46 PM, "Lindenmaier, Goetz"  wrote:

> Hi all,
> 
> I prepared the webrev for the changes discussed below:
> http://cr.openjdk.java.net/~goetz/webrevs/8003853/
> 
> To fix the issues we have with the PPC port with finding ICs, this change 
> cleans up the code handling compiled static Java calls:
> - Methods using native instructions are moved from compiledIC.cpp
>   to compiledIC_.cpp.
> - Methods emitting the call patched by CompiledStaticCall are
>   moved from the ad file to this class.
>   As a side effect this reduces redundancies in x86_64.ad and x86_32.ad.
> - We get rid of extern declarations in output.cpp.

I like this.  Two comments:

1) Does it make sense to have emit_to_interp_stub when it's only used in one place?

2) Before we can push this someone has to do the same thing for ARM and PPC.  Any volunteers from the embedded team?

-- Chris

> 
> Now all code concerning CompiledStaticCalls is collected in one class.
> The PPC port needs not change shared code any more to implement them.
> I also got around to move code to MacroAssembler, as only a simple call 
> was needed on x86 and sparc.
> 
> Probably this is (M) now, no more (S).
> 
> Please review and send comments.  I'll be happy to adapt to them!
> 
> Best regards,
>  Goetz Lindenmaier
> 
> -----Original Message-----
> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
> Sent: Thursday, April 11, 2013 4:50 AM
> To: Lindenmaier, Goetz
> Cc: 'hotspot-compiler-dev at openjdk.java.net'
> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
> 
> 
> On Apr 9, 2013, at 7:35 AM, "Lindenmaier, Goetz"  wrote:
> 
>> Hi Chris, 
>> 
>> I'm now working on this issue.  Sorry for the delay...
>> 
>> What do you think about moving 
>>   void emit_java_to_interp(CodeBuffer& cbuf);
>> and
>>  void size_java_to_interp();
>> to compiledIC.hpp and the new platform file, too?
> 
> I like that.
> 
>> 
>> This would also allow to overcome the ugly 
>>  extern uint size_java_to_interp();
>> in output.cpp, as it could be replaced by CompiledStaticCall::size_java_to_interp().
> 
> Great.
> 
>> 
>> I also would like to name this
>> CompiledStaticCall::emit_to_interp_stub()
>> CompiledStaticCall::to_interp_stub_size()
> 
> I'm okay with that.  Not sure if others have objections.
> 
>> 
>> I could also extract code from enc_class Java_Static_Call 
>> to form a routine
>> CompiledStaticCall::emit_call(CodeBuffer *cbuf, intptr_t entry_point, relocInfo::relocType rtype) {
>>   emit_call_reloc(cbuf, entry_point, rtype)
>>   if (rtype != relocInfo::runtime_call_type) {
>>       emit_java_to_interp(cbuf);
>>     }
>> }
>> With this, also 
>> extern uint reloc_java_to_interp();
>> from output.cpp could be moved into this class.
> 
> On SPARC only or the other architectures as well?
> 
>> 
>> Then handling of CompiledStaticCalls would be completely implemented in this
>> one class.
> 
> That's tempting.
> 
>> 
>> (I would have to move emit_call_reloc to MacroAssembler.)
> 
> Could you send a webrev with these changes?
> 
> -- Chris
> 
>> 
>> Best regards,
>> Goetz.
>> 
>> 
>> 
>> -----Original Message-----
>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>> Sent: Montag, 25. M?rz 2013 23:29
>> To: Lindenmaier, Goetz
>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>> 
>> 
>> On Mar 4, 2013, at 8:34 AM, "Lindenmaier, Goetz"  wrote:
>> 
>>> Hi Chris, 
>>> 
>>> I would like to take up this issue again. 
>>> I'm about to put our changes on the jdk8 branch, and it would be convenient
>>> to have a final solution for this.
>>> 
>>> Should I prepare a webrev with a different solution adding a new file
>>> for this?  What should go into that file? 
>> 
>> Sorry for answering that late.
>> 
>> Yes, to see a patch for that would be good.  We need to put all platform dependent Compiled* methods in that new file.  Platform dependent means every method that uses a native* method from nativeInst_:
>> 
>> CompiledIC::cleanup_call_site
>> CompiledIC::is_icholder_call_site
>> CompiledIC::CompiledIC
>> 
>> CompiledStaticCall::set_to_interpreted
>> CompiledStaticCall::set_stub_to_clean
>> CompiledStaticCall::verify
>> 
>> -- Chris
>> 
>>> 
>>> Best regards,
>>> Goetz.
>>> 
>>> 
>>> 
>>> -----Original Message-----
>>> From: goetz.lindenmaier at sap.com 
>>> Sent: Dienstag, 18. Dezember 2012 10:42
>>> To: 'Christian Thalinger'
>>> Subject: RE: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>> 
>>> Hi Chris, 
>>> 
>>> What would you put into that file?  The offset, or the class CompiledStaticCall?
>>> You could also put it into nativeInst_  to avoid adding another file.
>>> 
>>> But basically I think the offset is the best solution, because it's very small
>>> and straight forward, and the offset is set where the code is generated 
>>> that defines the offset.
>>> 
>>> Only the #ifndef COMPILER2 is ugly, but here I think the solution is to 
>>> guard the whole class CompiledStaticCall with #ifdef COMPILER2.
>>> 
>>> But I'm happy with any placement of the code.
>>> 
>>> Best regards,
>>> Goetz.
>>> 
>>> 
>>> 
>>> -----Original Message-----
>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>> Sent: Montag, 17. Dezember 2012 21:34
>>> To: Lindenmaier, Goetz
>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>> 
>>> 
>>> On Nov 29, 2012, at 2:10 PM, "Lindenmaier, Goetz"  wrote:
>>> 
>>>> Hi Chris, 
>>>> 
>>>> Loading the constant takes 5 instructions, the other way only three,
>>>> in the code only one, if the constant pool base is in a register.
>>>> The 5 instructions are hard to patch atomically.  The constant pool 
>>>> is just a 64 bit store.  
>>>> 
>>>>> Sorry for being so persistent on this :-)  
>>>> That's ok, I already found several places in our VM where it was easy to 
>>>> change our code to get along without the shared changes we did in 
>>>> first place.  But I can't redesign everything, and I can not risk to break
>>>> anything in our product.
>>>> 
>>>> If you feel like doing so, you can have a look at 
>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/600ce596eea9
>>>> which contains our bytecode interpreter profiling implementation.
>>>> If you think this is currently of use in the main branch, I would lift it to HS25 
>>>> (the permgen changes might cause trouble) and contribute it to hsx.
>>> 
>>> Sorry for the long delay.
>>> 
>>> Thinking about this problem again it seems that the correct solution would be to have a compiledIC_.cpp file.
>>> 
>>> The CompiledIC instruction layout is platform dependent; it just happens to be the same for all architectures we have right now (well, except PPC) because we made it to be the same.  Actually on SPARC we could also use a load from the constant table which would be simpler.
>>> 
>>> Having a platform dependent file for this code feels right.  What do you think?
>>> 
>>> -- Chris
>>> 
>>>> 
>>>> Best regards,
>>>> Goetz.
>>>> 
>>>> -----Original Message-----
>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>> Sent: Thursday, November 29, 2012 7:53 PM
>>>> To: Lindenmaier, Goetz
>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>> 
>>>> 
>>>> On Nov 29, 2012, at 12:27 AM, "Lindenmaier, Goetz"  wrote:
>>>> 
>>>>> Hi Chris, 
>>>>> 
>>>>>> Why can't you point the relocation to the method load instruction?  It doesn't seem right to do that in shared code.
>>>>> Because the relocation is used 
>>>>> 1.) to find the beginning of the stub to patch the call to go there 
>>>>> 2.) to find the load to patch the IC.
>>>> 
>>>> Got it.
>>>> 
>>>>> 
>>>>> Just have a look at CompiledStaticCall::set_to_interpreted(),
>>>>> the variable 'stub' is used twice.  
>>>> 
>>>> Sorry for being so persistent on this :-)  What is the reason you have to load the constant from the constant table?  On other architectures we materialize the constant.
>>>> 
>>>> -- Chris
>>>> 
>>>>> 
>>>>> Best regards, 
>>>>> Goetz.
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>> Sent: Donnerstag, 29. November 2012 01:35
>>>>> To: Lindenmaier, Goetz
>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>> 
>>>>> 
>>>>> On Nov 27, 2012, at 4:24 AM, "Lindenmaier, Goetz"  wrote:
>>>>> 
>>>>>> Hi Chris,
>>>>>> 
>>>>>>> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub?
>>>>>> Shared code (class CompiledStaticCall) wants to patch the inline cache 
>>>>>> in the stub which is emitted in platform code.
>>>>>> So the platform code should specify how the shared code can find the inline cache 
>>>>>> in the stub, which it does through the constant I introduced.
>>>>>> 
>>>>>>> Do you need two relocations?  I'm confused.
>>>>>> No, three ;)
>>>>>> The relocation you mention is used to find the stub given the call.
>>>>>> The other relocations are needed to find the inline cache / call target
>>>>>> once the stub is found (see CompiledStaticCall::set_to_interpreted()).
>>>>>> It's just the same on x86_64:
>>>>>> 
>>>>>> // static stub relocation stores the instruction address of the call
>>>>>> __ relocate(static_stub_Relocation::spec(mark), RELOC_IMM64); 
>>>>>> // static stub relocation also tags the methodOop in the code-stream.
>>>>>> __ movoop(rbx, (jobject) NULL);  // method is zapped till fixup time
>>>>>> // This is recognized as unresolved by relocs/nativeinst/ic code
>>>>>> __ jump(RuntimeAddress(__ pc()));
>>>>>> 
>>>>>> On PPC, we have to load the base of the constant table after generating the 
>>>>>> static_stub_relocation and before emitting the ppc equivalent for moveoop(). This offset is 
>>>>>> exactly what we store in the  CompiledStaticCall::comp_to_int_load_offset constant.
>>>>> 
>>>>> Why can't you point the relocation to the method load instruction?  It doesn't seem right to do that in shared code.
>>>>> 
>>>>> -- Chris
>>>>> 
>>>>>> 
>>>>>> Best regards,
>>>>>> Goetz.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>>> Sent: Dienstag, 27. November 2012 01:53
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>>> 
>>>>>> 
>>>>>> On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz"  wrote:
>>>>>> 
>>>>>>> Hi Chris,
>>>>>>> 
>>>>>>> We put it into the ad file because it describes an offset into the stub that is
>>>>>>> generated from the ad file by emit_java_to_interp(CodeBuffer& cbuf), 
>>>>>>> used by ir  node CallStaticJavaDirect.  Maybe I should not call it stub, but it's 
>>>>>>> generated into the stubs section of the code buffer.
>>>>>>> If that stub generator is moved out of the ad file to shared compiler code, one should
>>>>>>> move the field with it, but for the current implementation I think that's fine.
>>>>>>> 
>>>>>>> Does C1 generate the same stub? Or is the CompiledStaticCall a C2 feature?
>>>>>>> If so, one could protect the whole thing by #ifdef COMPILER2.
>>>>>> 
>>>>>> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub?
>>>>>> 
>>>>>> // Create a static stub relocation which relates this stub
>>>>>> // with the call instruction at insts_call_instruction_offset in the
>>>>>> // instructions code-section.
>>>>>> __ relocate(static_stub_Relocation::spec(__ code()->insts()->start() + insts_relocation_offset));
>>>>>> 
>>>>>> Do you need two relocations?  I'm confused.
>>>>>> 
>>>>>> -- Chris
>>>>>> 
>>>>>>> 
>>>>>>> Thanks for all the bugids!
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> Goetz.
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>>>> Sent: Mittwoch, 21. November 2012 19:53
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>> Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>>>> 
>>>>>>> 
>>>>>>> On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz"  wrote:
>>>>>>> 
>>>>>>>> Hi Chris, 
>>>>>>>> 
>>>>>>>> yes, there is no C1 on ppc.  
>>>>>>>> We do tiered compilation with a stripped C2.
>>>>>>> 
>>>>>>> Right.  But some other architecture (or in the future) might need this for C1 as well.  We should find a better place for the value than the ad file.  The obvious place would be compiledIC_.hpp but we don't have that file, yet.
>>>>>>> 
>>>>>>> I filed:
>>>>>>> 
>>>>>>> 8003853: specify offset of IC load in java_to_interp stub
>>>>>>> 
>>>>>>> -- Chris
>>>>>>> 
>>>>>>>> 
>>>>>>>> Best regards,
>>>>>>>> Goetz
>>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>>>>> Sent: Dienstag, 20. November 2012 22:19
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>> Subject: Re: RFR (S): Specify offset of IC load in java_to_interp stub.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz"  wrote:
>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub
>>>>>>>>> to update the IC  with NativeMovConstReg.  The current implementation assumes that
>>>>>>>>> the load is always the first instruction in the stub.  This is an artificial restriction. E.g.,
>>>>>>>>> it might be useful to load the constant pool address (MachConstantBase) before the
>>>>>>>>> IC load (as we do on PPC).
>>>>>>>>> 
>>>>>>>>> This change adds a constant specifying an offset from the beginning of the stub to
>>>>>>>>> the  IC load. The offset is platform specific and 0 on sparc and x86.
>>>>>>>>> 
>>>>>>>>> You can find the change here:
>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/
>>>>>>>> 
>>>>>>>> That should be fixed indeed.  
>>>>>>>> 
>>>>>>>> +#ifndef COMPILER2
>>>>>>>> +const int CompiledStaticCall::comp_to_int_load_offset = 0;
>>>>>>>> 
>>>>>>>> There is no C1 for PPC (sorry, I didn't check)?
>>>>>>>> 
>>>>>>>> -- Chris
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> or in our ppc port:
>>>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33
>>>>>>>>> 
>>>>>>>>> Thank you and best regards,
>>>>>>>>> Goetz
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


From nils.eliasson at oracle.com  Mon Apr 15 03:36:26 2013
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Mon, 15 Apr 2013 12:36:26 +0200
Subject: RFR (M): 8006952: Slow VM due to excessive code cache freelist
	iteration
In-Reply-To: <51684283.7010304@oracle.com>
References: <5107AADF.6010501@oracle.com> <51082499.3000905@oracle.com>
	<51093FAC.6090803@oracle.com> <51097FA6.3050709@oracle.com>
	<510ABAB9.8020909@oracle.com>
	<15E6C57378C5FE43AD074594DD824E501C8AB7E7@DEWDFEMB15A.global.corp.sap>
	<511511A5.8050101@oracle.com> <5167DFC2.6020007@oracle.com>
	<51684283.7010304@oracle.com>
Message-ID: <516BD82A.7050302@oracle.com>


Hi,

On 2013-04-12 19:21, Vladimir Kozlov wrote:
> Nils,
>
> It is sad that you have to reverse parfait fix but I agree that your 
> changes are more clean.

Please - don't be! I taken extra precaution and have verified that there 
is a null check between the call to new and the constructor. This is 
consistent with both the C++ spec and the behaviour we rely on when 
running out of code cache. The CodeCache::has_space would have forced me 
to do it more complex, it would have to copy/wrap the heap::allocate 
algorithm but returning a bool instead of actually allocating.

Sorry for forgetting to add it to the change log in my request. I did 
not intend to revert it without being open about it.

I don't understand why Parfait is confused about 'this' being null in 
the constructor. I will open a bug on Parfait if I can find where to 
submit it.

>
> After these changes largest_free_block() is used only in statistics 
> output which is useless since it is not participating in codecache 
> allocations.  May be we should remove it and use 
> heap_unallocated_capacity() instead (do we need lock then?):

Yes, good idea. Must check that I don't break any log tool if I change 
the output though.

>
> size_t CodeCache::largest_free_block() {
>   return _heap->heap_unallocated_capacity();
> }
>
> Also red_zone_start() is confusing because it does not show how it is 
> related to heap_unallocated_capacity(). In one place you use one:
>
>  211     if (size(length) > (heap_unallocated_capacity() - 
> CodeCacheMinimumFreeSpace)) {
>
> and in an other use second:
>
>  437     if (((size_t)cur + length) >= (size_t)red_zone_start()) {
>
> Can we just use only heap_unallocated_capacity()?

I agree that it is confusing. The background is that they serve a bit 
different purpose. In one case we are allocating from the freelist and 
need to check against the adress where the 'red zone/critical allocation 
area begins.' In the other it is a block allocation from the contiguous 
heap where we know heap_unallocated_capacity is the size of the block at 
the end of the heap. I'll come up with something better.

Thanks for taking your time!
//Nils

>
> Thanks,
> Vladimir
>
> On 4/12/13 3:19 AM, Nils Eliasson wrote:
>> I have now incorporated both Vladimirs and Andreas suggestion:
>>
>> Changes to previous revision includes:
>> 1) Updated the checks in both heap::allocate and heap::search_freelist
>> so that non critical allocation never stride into the
>> CodeCacheMinimumFreeSpace.
>> 2) Inverted the critical condition - now all allocations default to not
>> critical. Only the places where we would go fatal if the allocation
>> returns null are critical.
>> 3) Refactored some names and removed duplicate methods in heap.cpp.
>>
>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.08/
>> 
>>
>> This changes also opens up for decreasing the CodeCacheMinimumFreeSpace
>> since we now guarantee that only critical allocation will end up there.
>> And they will not grow to 500K when compilation have stopped anyways.
>>
>> Kind regards,
>> //Nils
>>
>>
>> On 2013-02-08 15:54, Nils Eliasson wrote:
>>> Vladimir and Andreas, thanks for your feedback! I am considering your
>>> suggestions.
>>>
>>> My fix is a step in the right direction but I realize it is not enough.
>>>
>>> Initially, it works good reserving the last part of the heap block.
>>> But if the application has a bigger active code footprint that what
>>> can fit in the code cache, there will be new flushes that will
>>> increase fragmentation and slowly reduce the usable part of the code
>>> cache. So I will add functionality for backing off.
>>>
>>> //Nils
>>>
>>> Schoesser, Andreas skrev 2013-02-01 10:58:
>>>> Hi Nils,
>>>>
>>>> this is IMO a good idea since we experienced the same problem with
>>>> one of our ports. I think in our case it was not the nmethod sweeper
>>>> continuously running (there's MinCodeCacheFlushingInterval to only
>>>> speculatively disconnect nmethods every 30 seconds) but from the
>>>> compiler loop constantly polling the freelist without the nmethod
>>>> sweeper making any progress.
>>>>
>>>> You also might consider to propagate the "critical" flag down to
>>>> search_freelist(). Then, a simple address compare would do to keep
>>>> the end of the code cache free from nmethods:
>>>> - For non-critical blobs, search_freelist() may only fit free blocks
>>>> < CodeCache::end() - CodeCacheMinimumFreeSpace
>>>> - For critical blocks, search_freelist() may fit all free blocks
>>>>
>>>> Best regards,
>>>> Andreas
>>>>
>>>> -----Original Message-----
>>>> From: hotspot-compiler-dev-bounces at openjdk.java.net
>>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of
>>>> Nils Eliasson
>>>> Sent: Donnerstag, 31. Januar 2013 19:41
>>>> To: hotspot-compiler-dev at openjdk.java.net
>>>> Subject: Re: RFR (M): 8006952: Slow VM due to excessive code cache
>>>> freelist iteration
>>>>
>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.04/
>>>>
>>>> //N
>>>>
>>>> Vladimir Kozlov skrev 2013-01-30 21:16:
>>>>> Nils, you sent webrev for other bug fix.
>>>>>
>>>>> Vladimir
>>>>>
>>>>> On 1/30/13 7:43 AM, Nils Eliasson wrote:
>>>>>> Thanks for the link, interesting background.
>>>>>>
>>>>>> Even if finding the largest block on the freelist is free, we would
>>>>>> still have a misbehavior when the free heap block is less than 1,5M
>>>>>> and
>>>>>> the flushing begins to create a 1,5M freelist block.
>>>>>>
>>>>>> Unallocated memory is a good measurement if have some continuous
>>>>>> memory
>>>>>> in reserve for critical blobs. I am thinking of using the thresholds
>>>>>> against unallocated memory, but forbidding nmethods from using the
>>>>>> last
>>>>>> 0,5M (MinimumFreeSpace) from the heap block. That would prevent 
>>>>>> the VM
>>>>>> from fragmenting the last continuous memory space, and allow the 
>>>>>> VM to
>>>>>> use all of the freelist.
>>>>>>
>>>>>> Like this:
>>>>>> http://cr.openjdk.java.net/~neliasso/8002364/webrev.03
>>>>>>
>>>>>> //Nils
>>>>>>
>>>>>> Vladimir Kozlov skrev 2013-01-29 20:35:
>>>>>>> Nils,
>>>>>>>
>>>>>>> You are reversing 7025742 fix. I would prefer to keep track of a
>>>>>>> largest free block during allocation in CodeCache (by using ordered
>>>>>>> list or other technique) to avoid scanning the list.
>>>>>>>
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 1/29/13 2:56 AM, Nils Eliasson wrote:
>>>>>>>> Remove continuous free block requirement for code cache 
>>>>>>>> flushing and
>>>>>>>> minimum free space.
>>>>>>>>
>>>>>>>> This causes a degenerate behavior when the VM are repeatedly
>>>>>>>> flushing
>>>>>>>> the code cache trying to free up a continuous 1,5M block. Since 
>>>>>>>> the
>>>>>>>> freelist is fragmented a significant part of the code cache is 
>>>>>>>> kept
>>>>>>>> unallocated. A significant amount of time is spent traversing the
>>>>>>>> freelist holding the code cache lock or waiting for other threads
>>>>>>>> doing
>>>>>>>> the same.
>>>>>>>>
>>>>>>>> I don't see any reason for why a continuous block is required. 
>>>>>>>> Code
>>>>>>>> cache flushing threshold (CodeCacheFlushingMinimumFreeSpace) is
>>>>>>>> default
>>>>>>>> 1,5M and code cache minimum threshold 
>>>>>>>> (CodeCacheMinimumFreeSpace) is
>>>>>>>> 0,5M. Finding such a block on the freelist is often unrealistic,
>>>>>>>> and has
>>>>>>>> not any purpose. The largest nmethods are in the order of 250k, 
>>>>>>>> and
>>>>>>>> they
>>>>>>>> are not allocated when code cache is starting to run out. All
>>>>>>>> critical
>>>>>>>> adapters are small and will fit easily in the freelist or in the
>>>>>>>> remaining heap space.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.02/
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Nils Eliasson
>>>
>>


From niclas.adlertz at oracle.com  Mon Apr 15 04:19:36 2013
From: niclas.adlertz at oracle.com (Niclas Adlertz)
Date: Mon, 15 Apr 2013 13:19:36 +0200
Subject: RFR(M) 8011621: Keep the "live range id - node" mapping in a
	separate class
In-Reply-To: <166470D8-5C28-4904-95C9-3400BFE00ECB@oracle.com>
References: <941B0F67-1B66-45EF-8150-BB9F435EB9CD@oracle.com>
	<51630DAA.8060906@oracle.com>
	<2650A2B9-507B-4031-BF2F-CA636160197E@oracle.com>
	<51684F15.10701@oracle.com>
	<166470D8-5C28-4904-95C9-3400BFE00ECB@oracle.com>
Message-ID: 

Hi, thank you all for the comments.

Christian
---------
> Now that the chaitin_.cpp files are gone I think we can remove these references in the Makefiles:
> 
> $ ack -a chaitin make/
> make/bsd/makefiles/vm.make
> 190:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*
> 
> make/linux/makefiles/vm.make
> 192:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*
> 
> make/solaris/makefiles/vm.make
> 205:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*
> 
> make/windows/create_obj_files.sh
> 117:COMPILER2_SPECIFIC_FILES="opto libadt bcEscapeAnalyzer.cpp chaitin* c2_* runtime_*"

Thank you, fixed. 

Vladimir
--------
> Move small PhaseChaitin::clone_projs() methods which calls clone_projs_shared() into the header file.
Ok, fixed.

> May be you should move the rest of PhaseChaitin methods from coalesce.cpp to chaitin.cpp where they are logically belong.
Sounds like a good idea, thank you. Fixed.

> You added clone_projs() to PhaseCoalesce class but it is not defined or used.
Good catch. Removed.


Roland
------

> Did you use hg remove for the files that are not needed anymore?
I did rm file, hg qnew and hg qrefresh.

> Shouldn't LiveRangeMap be VALUE_OBJ_CLASS_SPEC?
It should, thank you. Fixed.

> live.hpp: comment not aligned anymore. 
Fixed.


The new webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011621/webrev03/

Regards,
Niclas Adlertz

On 12 apr 2013, at 23:18, Christian Thalinger wrote:

> 
> On Apr 12, 2013, at 11:14 AM, Vladimir Kozlov  wrote:
> 
>> Hurray :) more dead code removed.
> 
> Now that the chaitin_.cpp files are gone I think we can remove these references in the Makefiles:
> 
> $ ack -a chaitin make/
> make/bsd/makefiles/vm.make
> 190:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*
> 
> make/linux/makefiles/vm.make
> 192:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*
> 
> make/solaris/makefiles/vm.make
> 205:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*
> 
> make/windows/create_obj_files.sh
> 117:COMPILER2_SPECIFIC_FILES="opto libadt bcEscapeAnalyzer.cpp chaitin* c2_* runtime_*"
> 
> -- Chris
> 
>> 
>> Move small PhaseChaitin::clone_projs() methods which calls clone_projs_shared() into the header file.
>> 
>> May be you should move the rest of PhaseChaitin methods from coalesce.cpp to chaitin.cpp where they are logically belong.
>> 
>> You added clone_projs() to PhaseCoalesce class but it is not defined or used.
>> 
>> Thanks,
>> Vladimir
>> 
>> On 4/12/13 5:01 AM, Niclas Adlertz wrote:
>>> Hi again,
>>> 
>>> Thank you for your comments.
>>> 
>>> Vladimir:
>>> ---------
>>> 
>>>> ${JAVA_HOME}/bin/java -server -Xss4m -verify -XX:+CompileTheWorld -XX:+TimeCompiler -Xbootclasspath/p:${JAVA_HOME}/jre/lib/rt.jar
>>> 
>>> Base: Total compilation: 2235.880 sec.
>>> Fix: Total compilation: 2226.020 sec.
>>> 
>>> So the fix should be ok in terms of compilation time.
>>> 
>>>> Can you use full name LiveRangeMap instead of LRGMap?
>>> Sure, fixed.
>>> 
>>>> Don't put big methods with loops into header file, we don't want to increase code size without need.
>>> Ok, fixed.
>>> 
>>>> Explicitly declare private: and public: parts in class. Add comment what is class for.
>>> Done.
>>> 
>>>> I like Roland's suggestion (LRGMap _lrg_map;) because it avoids a reference through _lrg_map pointer (in compiled code C++ needs only one PhaseChaitin* pointer).
>>> Done.
>>> 
>>> Roland:
>>> -------
>>> 
>>>> In vmStructs.cpp, you need to add a declaration for PhaseChaitin::_lrg_map otherwise:
>>>> c2_nonstatic_field(LRGMap,             _max_lrg_id,              uint)
>>>> is useless.
>>> I removed it from vmStructs.cpp completely instead, since it's not used by the agent.
>>> 
>>>> Why not declare: LRGMap _lrg_map; rather than stack allocate it and set a pointer.
>>> I just followed the old pattern, but that's a good remark, thank you.
>>> Fixed.
>>> 
>>>> Can you add comments describing what LRGMap is before its declaration?
>>>> 
>>>> Shouldn't that:
>>>> 242   if (C->unique() > _lrg_map->_names.Size()) {
>>>> 243     _lrg_map->_names.extend(C->unique() - 1, 0);
>>>> 244   }
>>>> 
>>>> be moved to the LRGMap constructor?
>>> 
>>> This code is not necessary anymore, because I also took the liberty of removing
>>> pd_preallocate_hook();
>>> and
>>> pd_postallocate_verify_hook();
>>> 
>>> which are not needed anymore because they only added nodes for Win95 and Win 98.
>>> 
>>>> Shouldn't you make _max_lrg_id, _uf_map and _names private and have accessors?
>>> I have now made public methods for performing operations on _max_lrg_id, _uf_map and _names.
>>> 
>>> ---------
>>> 
>>> The new webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011621/webrev02/
>>> 
>>> Thank you.
>>> 
>>> Regards,
>>> Niclas Adlertz
>>> 
>>> On 8 apr 2013, at 20:34, Vladimir Kozlov wrote:
>>> 
>>>> Niclas,
>>>> 
>>>> Thank you for doing this cleanup.
>>>> 
>>>> Please, test affection on RA performance. You can use CTW for this and fastdebug VM:
>>>> 
>>>> ${JAVA_HOME}/bin/java -server -Xss4m -verify -XX:+CompileTheWorld -XX:+TimeCompiler -Xbootclasspath/p:${JAVA_HOME}/jre/lib/rt.jar
>>>> 
>>>> Or build optimized VM and run jvm08, for example, with -XX:+TimeCompiler.
>>>> 
>>>> Can you use full name LiveRangeMap instead of LRGMap?
>>>> Don't put big methods with loops into header file, we don't want to increase code size without need.
>>>> 
>>>> Explicitly declare private: and public: parts in class. Add comment what is class for.
>>>> 
>>>> I like Roland's suggestion (LRGMap _lrg_map;) because it avoids a reference through _lrg_map pointer (in compiled code C++ needs only one PhaseChaitin* pointer).
>>>> 
>>>> Thanks,
>>>> Vladimir
>>>> 
>>>> On 4/8/13 3:05 AM, Niclas Adlertz wrote:
>>>>> Hi all.
>>>>> 
>>>>> Problem:
>>>>> In order to clean up the Split code (in opto/reg_split.cpp) making it easier to maintain and (hopefully) making it easier to improve (https://jbs.oracle.com/bugs/browse/JDK-7022320), it would be good to have the Split code more isolated with as few dependencies to other parts of the code as possible.
>>>>> The Split code could reside in an own module (class), just having references to classes and data it really needs. Right now it would need to have a reference to PhaseChaitin, only to access the "live range id - node" mapping. However, it does not need to know about everything in the PhaseChaitin class. This may also introduce cross reference problems since PhaseChaitin would use the Split module and the Split module would need a reference to PhaseChaitin.
>>>>> 
>>>>> Solution:
>>>>> Move the "live range id - node" mapping to a separate class, instantiated by PhaseChaitin, which can then be passed to the Split module as a reference.
>>>>> 
>>>>> Regards,
>>>>> Niclas Adlertz
>>>>> 
>>>>> (Note that the webrev title is named JDK-7022320. That's just the local folder name that the code resides in. The bug is indeed 8011621)
>>>>> 
>>>>> -----------------------------------------------------------------
>>>>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011621/webrev00/
>>>>>   jbs: https://jbs.oracle.com/bugs/browse/JDK-8011621
>>>>>  bugs: http://bugs.sun.com/view_bug.do?bug_id=8011621
>>>>> 
>>>>> 
>>> 
> 


From roland.westrelin at oracle.com  Mon Apr 15 08:23:01 2013
From: roland.westrelin at oracle.com (roland.westrelin at oracle.com)
Date: Mon, 15 Apr 2013 15:23:01 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 8011582: assert(nbits == 32 || (-(1 <<
	nbits-1) <= x && x < ( 1 << nbits-1))) failed: value out of range
Message-ID: <20130415152305.4AF7D482F3@hg.openjdk.java.net>

Changeset: bb4a966cc68f
Author:    roland
Date:      2013-04-15 09:42 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bb4a966cc68f

8011582: assert(nbits == 32 || (-(1 << nbits-1) <= x && x < ( 1 << nbits-1))) failed: value out of range
Summary: c1 runtime's predicate_failed_trap should use jump_to on sparc
Reviewed-by: kvn

! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp


From christian.thalinger at oracle.com  Mon Apr 15 09:31:16 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 15 Apr 2013 09:31:16 -0700
Subject: RFR(XS): 8011648: C1: optimized build is broken after 7153771
In-Reply-To: <48F03646-093E-42DC-9D7D-99403532C5FD@oracle.com>
References: <48F03646-093E-42DC-9D7D-99403532C5FD@oracle.com>
Message-ID: <0173C8AF-189F-49D0-BF32-301CDE5BE9CE@oracle.com>

Looks good.  -- Chris

On Apr 9, 2013, at 4:19 AM, Roland Westrelin  wrote:

> Some missing #ifdef ASSERT
> 
> http://cr.openjdk.java.net/~roland/8011648/webrev.00/
> 
> Roland.


From roland.westrelin at oracle.com  Mon Apr 15 09:32:44 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 15 Apr 2013 18:32:44 +0200
Subject: RFR(XS): 8011648: C1: optimized build is broken after 7153771
In-Reply-To: <0173C8AF-189F-49D0-BF32-301CDE5BE9CE@oracle.com>
References: <48F03646-093E-42DC-9D7D-99403532C5FD@oracle.com>
	<0173C8AF-189F-49D0-BF32-301CDE5BE9CE@oracle.com>
Message-ID: <39744BC5-A9FC-40CB-8828-CA5427D699E7@oracle.com>

> Looks good.  -- Chris

Thanks for the review but it's already in the jprt queue?

Roland.

From yumin.qi at oracle.com  Mon Apr 15 10:01:39 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Mon, 15 Apr 2013 10:01:39 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516B9922.4050306@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
Message-ID: <516C3273.1040003@oracle.com>

David,

On 4/14/2013 11:07 PM, David Holmes wrote:
> Hi Yumin,
>
> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>> After take feedback and modify, new webrev
>>
>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>> 
>
> I still find the HandleMark changes unsatisfactory. The CHeap 
> allocated HandleMark in the Thread() constructor is a bit of a hack. 
> HandleMarks should be stack-allocated. Plus we seem to leak that CHeap 
> allocated HandleMark as we don't keep any pointer to it! I think this 
> needs to be re-visited, but as a separate CR.
>
I agree, will file a separate CR for this problem to be fixed.
> ---
>
> allocation.hpp:
>
> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element 
> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's 
> before deallocating ?
>
In fact, CardTableRS and CardTableModRefBS are only created once when GC 
flavor specified. It will be cleaned at JVM exit, this is why there is 
no memory leak. To keep a better coding practice, I will add 
FREE_C_HEAP_OBJECT_ARRAY to call dtos, also to free other allocated 
arrays during ctos called.

> ---
>
> src/share/vm/utilities/quickSort.cpp
>
> Why does only Solaris need the allocation headers included ?? I would 
> expect all platforms to need to the same headers here.
>
This is due to SunStudio compilation setting. It will issue error on 
solaris like:

src/share/vm/utilities/quickSort.cpp", line 192: Error: The function 
"AllocateHeap" must have a prototype.

in precompiled.hpp:

// Precompiled headers are turned off for Sun Studion,
// or if the user passes USE_PRECOMPILED_HEADER=0 to the makefiles.

#ifndef DONT_USE_PRECOMPILED_HEADER

I could add the including for all platforms, since it will be excluded 
by other platforms except for solaris --- precompiled.hpp already 
includes those two files. Adding #ifdef SOLARIS here to indicate they 
are only needed for Solaris.

I will send new webrev out.

Thanks
Yumin


> Thanks,
> David
>
>>
>>
>> Thanks
>> Yumin
>>
>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>> .
>>>>> cardTableModRefBS.cpp
>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>
>>>> This is default constructor does, here just copy that code. Since we
>>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which
>>>> will call ctors.
>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>> allocation.hpp #618 does.
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>>>> carTableRS.cpp
>>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>>
>>>>>
>>>> See reply to David H.
>>>>
>>>>
>>>> Thanks
>>>> Yumin
>>>>> -Zhengyu
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>> Hi,
>>>>>>
>>>>>>   Can I have your inputs for the fix?
>>>>>>   webrev:
>>>>>>
>>>>>>  http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>> 
>>>>>>
>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>
>>>>>> Problem description:  Remove the usage of global operator ::new[]
>>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>> disabling use of global operator new[] and new, we constrain the
>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>> ResourceObj unless they are stack objects or values which have to
>>>>>> be from StackObj or _ValueObj respectively.  Or they have to
>>>>>> implement their own operator new[] or new.
>>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>


From vladimir.kozlov at oracle.com  Mon Apr 15 10:14:06 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 15 Apr 2013 10:14:06 -0700
Subject: RFR(M) 8011621: Keep the "live range id - node" mapping in a
	separate class
In-Reply-To: 
References: <941B0F67-1B66-45EF-8150-BB9F435EB9CD@oracle.com>
	<51630DAA.8060906@oracle.com>
	<2650A2B9-507B-4031-BF2F-CA636160197E@oracle.com>
	<51684F15.10701@oracle.com>
	<166470D8-5C28-4904-95C9-3400BFE00ECB@oracle.com>
	
Message-ID: <516C355E.9030608@oracle.com>

Looks good.

Thanks,
Vladimir

On 4/15/13 4:19 AM, Niclas Adlertz wrote:
> Hi, thank you all for the comments.
>
> Christian
> ---------
>> Now that the chaitin_.cpp files are gone I think we can remove these references in the Makefiles:
>>
>> $ ack -a chaitin make/
>> make/bsd/makefiles/vm.make
>> 190:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*
>>
>> make/linux/makefiles/vm.make
>> 192:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*
>>
>> make/solaris/makefiles/vm.make
>> 205:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*
>>
>> make/windows/create_obj_files.sh
>> 117:COMPILER2_SPECIFIC_FILES="opto libadt bcEscapeAnalyzer.cpp chaitin* c2_* runtime_*"
>
> Thank you, fixed.
>
> Vladimir
> --------
>> Move small PhaseChaitin::clone_projs() methods which calls clone_projs_shared() into the header file.
> Ok, fixed.
>
>> May be you should move the rest of PhaseChaitin methods from coalesce.cpp to chaitin.cpp where they are logically belong.
> Sounds like a good idea, thank you. Fixed.
>
>> You added clone_projs() to PhaseCoalesce class but it is not defined or used.
> Good catch. Removed.
>
>
> Roland
> ------
>
>> Did you use hg remove for the files that are not needed anymore?
> I did rm file, hg qnew and hg qrefresh.
>
>> Shouldn't LiveRangeMap be VALUE_OBJ_CLASS_SPEC?
> It should, thank you. Fixed.
>
>> live.hpp: comment not aligned anymore.
> Fixed.
>
>
> The new webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011621/webrev03/
>
> Regards,
> Niclas Adlertz
>
> On 12 apr 2013, at 23:18, Christian Thalinger wrote:
>
>>
>> On Apr 12, 2013, at 11:14 AM, Vladimir Kozlov  wrote:
>>
>>> Hurray :) more dead code removed.
>>
>> Now that the chaitin_.cpp files are gone I think we can remove these references in the Makefiles:
>>
>> $ ack -a chaitin make/
>> make/bsd/makefiles/vm.make
>> 190:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*
>>
>> make/linux/makefiles/vm.make
>> 192:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*
>>
>> make/solaris/makefiles/vm.make
>> 205:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*
>>
>> make/windows/create_obj_files.sh
>> 117:COMPILER2_SPECIFIC_FILES="opto libadt bcEscapeAnalyzer.cpp chaitin* c2_* runtime_*"
>>
>> -- Chris
>>
>>>
>>> Move small PhaseChaitin::clone_projs() methods which calls clone_projs_shared() into the header file.
>>>
>>> May be you should move the rest of PhaseChaitin methods from coalesce.cpp to chaitin.cpp where they are logically belong.
>>>
>>> You added clone_projs() to PhaseCoalesce class but it is not defined or used.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 4/12/13 5:01 AM, Niclas Adlertz wrote:
>>>> Hi again,
>>>>
>>>> Thank you for your comments.
>>>>
>>>> Vladimir:
>>>> ---------
>>>>
>>>>> ${JAVA_HOME}/bin/java -server -Xss4m -verify -XX:+CompileTheWorld -XX:+TimeCompiler -Xbootclasspath/p:${JAVA_HOME}/jre/lib/rt.jar
>>>>
>>>> Base: Total compilation: 2235.880 sec.
>>>> Fix: Total compilation: 2226.020 sec.
>>>>
>>>> So the fix should be ok in terms of compilation time.
>>>>
>>>>> Can you use full name LiveRangeMap instead of LRGMap?
>>>> Sure, fixed.
>>>>
>>>>> Don't put big methods with loops into header file, we don't want to increase code size without need.
>>>> Ok, fixed.
>>>>
>>>>> Explicitly declare private: and public: parts in class. Add comment what is class for.
>>>> Done.
>>>>
>>>>> I like Roland's suggestion (LRGMap _lrg_map;) because it avoids a reference through _lrg_map pointer (in compiled code C++ needs only one PhaseChaitin* pointer).
>>>> Done.
>>>>
>>>> Roland:
>>>> -------
>>>>
>>>>> In vmStructs.cpp, you need to add a declaration for PhaseChaitin::_lrg_map otherwise:
>>>>> c2_nonstatic_field(LRGMap,             _max_lrg_id,              uint)
>>>>> is useless.
>>>> I removed it from vmStructs.cpp completely instead, since it's not used by the agent.
>>>>
>>>>> Why not declare: LRGMap _lrg_map; rather than stack allocate it and set a pointer.
>>>> I just followed the old pattern, but that's a good remark, thank you.
>>>> Fixed.
>>>>
>>>>> Can you add comments describing what LRGMap is before its declaration?
>>>>>
>>>>> Shouldn't that:
>>>>> 242   if (C->unique() > _lrg_map->_names.Size()) {
>>>>> 243     _lrg_map->_names.extend(C->unique() - 1, 0);
>>>>> 244   }
>>>>>
>>>>> be moved to the LRGMap constructor?
>>>>
>>>> This code is not necessary anymore, because I also took the liberty of removing
>>>> pd_preallocate_hook();
>>>> and
>>>> pd_postallocate_verify_hook();
>>>>
>>>> which are not needed anymore because they only added nodes for Win95 and Win 98.
>>>>
>>>>> Shouldn't you make _max_lrg_id, _uf_map and _names private and have accessors?
>>>> I have now made public methods for performing operations on _max_lrg_id, _uf_map and _names.
>>>>
>>>> ---------
>>>>
>>>> The new webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011621/webrev02/
>>>>
>>>> Thank you.
>>>>
>>>> Regards,
>>>> Niclas Adlertz
>>>>
>>>> On 8 apr 2013, at 20:34, Vladimir Kozlov wrote:
>>>>
>>>>> Niclas,
>>>>>
>>>>> Thank you for doing this cleanup.
>>>>>
>>>>> Please, test affection on RA performance. You can use CTW for this and fastdebug VM:
>>>>>
>>>>> ${JAVA_HOME}/bin/java -server -Xss4m -verify -XX:+CompileTheWorld -XX:+TimeCompiler -Xbootclasspath/p:${JAVA_HOME}/jre/lib/rt.jar
>>>>>
>>>>> Or build optimized VM and run jvm08, for example, with -XX:+TimeCompiler.
>>>>>
>>>>> Can you use full name LiveRangeMap instead of LRGMap?
>>>>> Don't put big methods with loops into header file, we don't want to increase code size without need.
>>>>>
>>>>> Explicitly declare private: and public: parts in class. Add comment what is class for.
>>>>>
>>>>> I like Roland's suggestion (LRGMap _lrg_map;) because it avoids a reference through _lrg_map pointer (in compiled code C++ needs only one PhaseChaitin* pointer).
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 4/8/13 3:05 AM, Niclas Adlertz wrote:
>>>>>> Hi all.
>>>>>>
>>>>>> Problem:
>>>>>> In order to clean up the Split code (in opto/reg_split.cpp) making it easier to maintain and (hopefully) making it easier to improve (https://jbs.oracle.com/bugs/browse/JDK-7022320), it would be good to have the Split code more isolated with as few dependencies to other parts of the code as possible.
>>>>>> The Split code could reside in an own module (class), just having references to classes and data it really needs. Right now it would need to have a reference to PhaseChaitin, only to access the "live range id - node" mapping. However, it does not need to know about everything in the PhaseChaitin class. This may also introduce cross reference problems since PhaseChaitin would use the Split module and the Split module would need a reference to PhaseChaitin.
>>>>>>
>>>>>> Solution:
>>>>>> Move the "live range id - node" mapping to a separate class, instantiated by PhaseChaitin, which can then be passed to the Split module as a reference.
>>>>>>
>>>>>> Regards,
>>>>>> Niclas Adlertz
>>>>>>
>>>>>> (Note that the webrev title is named JDK-7022320. That's just the local folder name that the code resides in. The bug is indeed 8011621)
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011621/webrev00/
>>>>>>    jbs: https://jbs.oracle.com/bugs/browse/JDK-8011621
>>>>>>   bugs: http://bugs.sun.com/view_bug.do?bug_id=8011621
>>>>>>
>>>>>>
>>>>
>>
>

From yumin.qi at oracle.com  Mon Apr 15 10:41:28 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Mon, 15 Apr 2013 10:41:28 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516B9922.4050306@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
Message-ID: <516C3BC8.2040001@oracle.com>

new webrev at:

http://cr.openjdk.java.net/~minqi/8010992/webrev2

Can I have a review from GC team for this change?

Thanks
Yumin

On 4/14/2013 11:07 PM, David Holmes wrote:
> Hi Yumin,
>
> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>> After take feedback and modify, new webrev
>>
>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>> 
>
> I still find the HandleMark changes unsatisfactory. The CHeap 
> allocated HandleMark in the Thread() constructor is a bit of a hack. 
> HandleMarks should be stack-allocated. Plus we seem to leak that CHeap 
> allocated HandleMark as we don't keep any pointer to it! I think this 
> needs to be re-visited, but as a separate CR.
>
> ---
>
> allocation.hpp:
>
> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element 
> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's 
> before deallocating ?
>
> ---
>
> src/share/vm/utilities/quickSort.cpp
>
> Why does only Solaris need the allocation headers included ?? I would 
> expect all platforms to need to the same headers here.
>
> Thanks,
> David
>
>>
>>
>> Thanks
>> Yumin
>>
>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>> .
>>>>> cardTableModRefBS.cpp
>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>
>>>> This is default constructor does, here just copy that code. Since we
>>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which
>>>> will call ctors.
>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>> allocation.hpp #618 does.
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>>>> carTableRS.cpp
>>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>>
>>>>>
>>>> See reply to David H.
>>>>
>>>>
>>>> Thanks
>>>> Yumin
>>>>> -Zhengyu
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>> Hi,
>>>>>>
>>>>>>   Can I have your inputs for the fix?
>>>>>>   webrev:
>>>>>>
>>>>>>  http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>> 
>>>>>>
>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>
>>>>>> Problem description:  Remove the usage of global operator ::new[]
>>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>> disabling use of global operator new[] and new, we constrain the
>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>> ResourceObj unless they are stack objects or values which have to
>>>>>> be from StackObj or _ValueObj respectively.  Or they have to
>>>>>> implement their own operator new[] or new.
>>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>


From zhengyu.gu at oracle.com  Mon Apr 15 11:42:53 2013
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Mon, 15 Apr 2013 14:42:53 -0400
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516C3BC8.2040001@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com>
Message-ID: <516C4A2D.8060902@oracle.com>

  623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size, memflags)                  \
  624   {                                                                                 \
  625     if (array_name != NULL) {                                                       \
  626       for (int index = 0; index < size; index ++) {                                 \
  627         /* placement to call dtor on type */                                        \
  628         ((type*)&array_name[index])->~type();                                       \
  629       }                                                                             \
  630       FREE_C_HEAP_ARRAY(type, array_name, memflags);                                \
  631     }                                                                               \
  632   }


I really don't like this, calling dtor ...

Thanks,

-Zhengyu


On 4/15/2013 1:41 PM, Yumin Qi wrote:
> new webrev at:
>
> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>
> Can I have a review from GC team for this change?
>
> Thanks
> Yumin
>
> On 4/14/2013 11:07 PM, David Holmes wrote:
>> Hi Yumin,
>>
>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>> After take feedback and modify, new webrev
>>>
>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>> 
>>
>> I still find the HandleMark changes unsatisfactory. The CHeap 
>> allocated HandleMark in the Thread() constructor is a bit of a hack. 
>> HandleMarks should be stack-allocated. Plus we seem to leak that 
>> CHeap allocated HandleMark as we don't keep any pointer to it! I 
>> think this needs to be re-visited, but as a separate CR.
>>
>> ---
>>
>> allocation.hpp:
>>
>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element 
>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's 
>> before deallocating ?
>>
>> ---
>>
>> src/share/vm/utilities/quickSort.cpp
>>
>> Why does only Solaris need the allocation headers included ?? I would 
>> expect all platforms to need to the same headers here.
>>
>> Thanks,
>> David
>>
>>>
>>>
>>> Thanks
>>> Yumin
>>>
>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>> .
>>>>>> cardTableModRefBS.cpp
>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>
>>>>> This is default constructor does, here just copy that code. Since we
>>>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which
>>>>> will call ctors.
>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>> allocation.hpp #618 does.
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>>
>>>>>> carTableRS.cpp
>>>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>>>
>>>>>>
>>>>> See reply to David H.
>>>>>
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>> -Zhengyu
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>   Can I have your inputs for the fix?
>>>>>>>   webrev:
>>>>>>>
>>>>>>>  http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>> 
>>>>>>>
>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>
>>>>>>> Problem description:  Remove the usage of global operator ::new[]
>>>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>>> disabling use of global operator new[] and new, we constrain the
>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>> ResourceObj unless they are stack objects or values which have to
>>>>>>> be from StackObj or _ValueObj respectively.  Or they have to
>>>>>>> implement their own operator new[] or new.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130415/4b102058/attachment.html 

From ioi.lam at oracle.com  Mon Apr 15 11:46:12 2013
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 15 Apr 2013 11:46:12 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516B9922.4050306@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
Message-ID: <516C4AF4.7090808@oracle.com>

On 04/14/2013 11:07 PM, David Holmes wrote:
> Hi Yumin,
>
> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>> After take feedback and modify, new webrev
>>
>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>> 
>
> I still find the HandleMark changes unsatisfactory. The CHeap 
> allocated HandleMark in the Thread() constructor is a bit of a hack. 
> HandleMarks should be stack-allocated. Plus we seem to leak that CHeap 
> allocated HandleMark as we don't keep any pointer to it! I think this 
> needs to be re-visited, but as a separate CR.
>
David,

The HandleMark is not leaked. It is freed in the Thread destructor:

before:

    355   delete last_handle_mark();

after:

    355   FREE_C_HEAP_ARRAY(HandleMark, last_handle_mark(), mtInternal);

- Ioi

From vladimir.kozlov at oracle.com  Mon Apr 15 12:38:56 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 15 Apr 2013 12:38:56 -0700
Subject: RFR(S) : 8011971 : WB API doesn't accept j.l.reflect.Constructor
In-Reply-To: <516AE198.1030805@oracle.com>
References: <51682863.3020800@oracle.com> <516862E0.5080109@oracle.com>
	<51686B41.3060502@oracle.com> <516875BC.9000308@oracle.com>
	<516AE198.1030805@oracle.com>
Message-ID: <516C5750.40608@oracle.com>

On 4/14/13 10:04 AM, Igor Ignatyev wrote:
>> Please, do. Especially for methods and tests classes.
> i'm really not very good in code's commentation, but i did my best.

I would prefer more detailed comments but current is good enough. Thank you.

>
> in addition to changes according to your suggestions, i added ability to
> specify comp_level in WB::makeMethodNotCompilable() and found some
> strange behavior of 'CompilationPolicy::can_be_compiled':
>
> 124   if (comp_level == CompLevel_all) {
> 125     return !m->is_not_compilable(CompLevel_simple) &&
> !m->is_not_compilable(CompLevel_full_optimization);
> 126   }
>
> if method is 'not_compilable' in C1 or C2, method 'can_be_compiled' will
> return false for 'CompLevel_all' even it is compilable in another level.
> is it expected behavior or it is a bug?

It is bug but only in Tiered where both C1 and C2 are present. Most 
important, I think, we should always pass comp_level to this method 
(don't use default CompLevel_all). I looked and all call site have 
comp_level information.

>
> updated webrev: http://cr.openjdk.java.net/~iignatyev/8011971/webrev.01/

Looks good.

Thanks,
Vladimir

>
> Best regards,
> Igor Ignatyev
>
> On 04/13/2013 12:59 AM, Vladimir Kozlov wrote:
>> On 4/12/13 1:14 PM, Igor Ignatyev wrote:
>>>  > Could you explain why you need j.l.reflect.Constructor in WB compiler
>>>  > tests? As java coding exercise it may be good (I am lost in it).
>>> But how
>>>  > it helps to JIT compiler testing?
>>
>> Here is a good comment ;) :
>>
>>> we have plan to create replacement of current CTW. main goal is to make
>>> available using CTW in product build. but it must be equals to current
>>> implementation in terms of functionality. since CTW compile constructor,
>>> we also must to compile constructor. so we need api for that.
>>>
>>>  > Do you know about 'comments' in a code? :)
>>> yes. i know, but i think that all is clear and self-documented :)
>>> but if you insist, i can add javadoc to all public and protected
>>> methods/fields.
>>
>> Please, do. Especially for methods and tests classes.
>>
>>>
>>>  > Why do you need to set dontinline in costructor?
>>>  > Would be better explicitly call new method from CompilerWhiteBoxTest
>>>  > class when needed:
>>>  >
>>>  > setDontInlineMethod() {
>>>  >    WHITE_BOX.testSetDontInlineMethod(method, true);
>>>  > }
>>> i need to set dontinline in constructor to prevent inlining of 'method'
>>> into others methods (fix for 8008211).
>>
>> I meant, why you need to do it in 'super' constructor?
>> You can call setDontInlineMethod() in local constructor. Test methods
>> will be executed only after constructor executed.
>>
>> Thanks,
>> Vladimir
>>
>>>
>>> Best regards,
>>> Igor Ignatyev
>>>
>>> On 04/12/2013 11:39 PM, Vladimir Kozlov wrote:
>>>> Igor,
>>>>
>>>> Could you explain why you need j.l.reflect.Constructor in WB compiler
>>>> tests? As java coding exercise it may be good (I am lost in it). But
>>>> how
>>>> it helps to JIT compiler testing?
>>>>
>>>> Do you know about 'comments' in a code? :)
>>>>
>>>> Using argument 'true' say nothing what it does since the corresponding
>>>> code is in different class file:
>>>>
>>>> +        super(testCase, true);
>>>>
>>>> Why do you need to set dontinline in costructor?
>>>> Would be better explicitly call new method from CompilerWhiteBoxTest
>>>> class when needed:
>>>>
>>>> setDontInlineMethod() {
>>>>    WHITE_BOX.testSetDontInlineMethod(method, true);
>>>> }
>>>>
>>>> Regards,
>>>> Vladimir
>>>>
>>>> On 4/12/13 8:29 AM, Igor Ignatyev wrote:
>>>>> Hi all,
>>>>>
>>>>> Please review patch.
>>>>>
>>>>> 1. changed signature of all methods where j.l.reflect.Method is used
>>>>> 2. added tests which use j.l.reflect.Constructor
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8011971/webrev.00/
>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011971

From igor.ignatyev at oracle.com  Mon Apr 15 12:44:52 2013
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 15 Apr 2013 23:44:52 +0400
Subject: RFR(S) : 8011971 : WB API doesn't accept j.l.reflect.Constructor
In-Reply-To: <516C5750.40608@oracle.com>
References: <51682863.3020800@oracle.com> <516862E0.5080109@oracle.com>
	<51686B41.3060502@oracle.com> <516875BC.9000308@oracle.com>
	<516AE198.1030805@oracle.com> <516C5750.40608@oracle.com>
Message-ID: <516C58B4.3070808@oracle.com>

Vladimir,

thank you for review.

> It is bug but only in Tiered where both C1 and C2 are present. Most
> important, I think, we should always pass comp_level to this method
> (don't use default CompLevel_all). I looked and all call site have
> comp_level information.
ok, i will file a bug for it.

Best regards,
Igor Ignatyev

On 04/15/2013 11:38 PM, Vladimir Kozlov wrote:
> On 4/14/13 10:04 AM, Igor Ignatyev wrote:
>>> Please, do. Especially for methods and tests classes.
>> i'm really not very good in code's commentation, but i did my best.
>
> I would prefer more detailed comments but current is good enough. Thank
> you.
>
>>
>> in addition to changes according to your suggestions, i added ability to
>> specify comp_level in WB::makeMethodNotCompilable() and found some
>> strange behavior of 'CompilationPolicy::can_be_compiled':
>>
>> 124   if (comp_level == CompLevel_all) {
>> 125     return !m->is_not_compilable(CompLevel_simple) &&
>> !m->is_not_compilable(CompLevel_full_optimization);
>> 126   }
>>
>> if method is 'not_compilable' in C1 or C2, method 'can_be_compiled' will
>> return false for 'CompLevel_all' even it is compilable in another level.
>> is it expected behavior or it is a bug?
>
> It is bug but only in Tiered where both C1 and C2 are present. Most
> important, I think, we should always pass comp_level to this method
> (don't use default CompLevel_all). I looked and all call site have
> comp_level information.
>
>>
>> updated webrev: http://cr.openjdk.java.net/~iignatyev/8011971/webrev.01/
>
> Looks good.
>
> Thanks,
> Vladimir
>
>>
>> Best regards,
>> Igor Ignatyev
>>
>> On 04/13/2013 12:59 AM, Vladimir Kozlov wrote:
>>> On 4/12/13 1:14 PM, Igor Ignatyev wrote:
>>>>  > Could you explain why you need j.l.reflect.Constructor in WB
>>>> compiler
>>>>  > tests? As java coding exercise it may be good (I am lost in it).
>>>> But how
>>>>  > it helps to JIT compiler testing?
>>>
>>> Here is a good comment ;) :
>>>
>>>> we have plan to create replacement of current CTW. main goal is to make
>>>> available using CTW in product build. but it must be equals to current
>>>> implementation in terms of functionality. since CTW compile
>>>> constructor,
>>>> we also must to compile constructor. so we need api for that.
>>>>
>>>>  > Do you know about 'comments' in a code? :)
>>>> yes. i know, but i think that all is clear and self-documented :)
>>>> but if you insist, i can add javadoc to all public and protected
>>>> methods/fields.
>>>
>>> Please, do. Especially for methods and tests classes.
>>>
>>>>
>>>>  > Why do you need to set dontinline in costructor?
>>>>  > Would be better explicitly call new method from CompilerWhiteBoxTest
>>>>  > class when needed:
>>>>  >
>>>>  > setDontInlineMethod() {
>>>>  >    WHITE_BOX.testSetDontInlineMethod(method, true);
>>>>  > }
>>>> i need to set dontinline in constructor to prevent inlining of 'method'
>>>> into others methods (fix for 8008211).
>>>
>>> I meant, why you need to do it in 'super' constructor?
>>> You can call setDontInlineMethod() in local constructor. Test methods
>>> will be executed only after constructor executed.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>>>
>>>> Best regards,
>>>> Igor Ignatyev
>>>>
>>>> On 04/12/2013 11:39 PM, Vladimir Kozlov wrote:
>>>>> Igor,
>>>>>
>>>>> Could you explain why you need j.l.reflect.Constructor in WB compiler
>>>>> tests? As java coding exercise it may be good (I am lost in it). But
>>>>> how
>>>>> it helps to JIT compiler testing?
>>>>>
>>>>> Do you know about 'comments' in a code? :)
>>>>>
>>>>> Using argument 'true' say nothing what it does since the corresponding
>>>>> code is in different class file:
>>>>>
>>>>> +        super(testCase, true);
>>>>>
>>>>> Why do you need to set dontinline in costructor?
>>>>> Would be better explicitly call new method from CompilerWhiteBoxTest
>>>>> class when needed:
>>>>>
>>>>> setDontInlineMethod() {
>>>>>    WHITE_BOX.testSetDontInlineMethod(method, true);
>>>>> }
>>>>>
>>>>> Regards,
>>>>> Vladimir
>>>>>
>>>>> On 4/12/13 8:29 AM, Igor Ignatyev wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Please review patch.
>>>>>>
>>>>>> 1. changed signature of all methods where j.l.reflect.Method is used
>>>>>> 2. added tests which use j.l.reflect.Constructor
>>>>>>
>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8011971/webrev.00/
>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011971

From vladimir.kozlov at oracle.com  Mon Apr 15 14:35:03 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 15 Apr 2013 14:35:03 -0700
Subject: RFR(S) : 8011675: adding compilation level to replay data
In-Reply-To: <5169AEA2.7060103@oracle.com>
References: <51631AEA.9080702@oracle.com> <51635E89.30808@oracle.com>
	<5163BD9A.5080308@oracle.com> <5163C5F4.7020605@oracle.com>
	<516827EA.3040001@oracle.com> <5168874B.9080407@oracle.com>
	<5169AEA2.7060103@oracle.com>
Message-ID: <516C7287.8070600@oracle.com>

On 4/13/13 12:14 PM, Igor Ignatyev wrote:
>> If you replaying C1 compilation next setting will be incorrect. Should
>> we use CompLevel_highest_tier instead so that following check pass?:
>>
>> +     if (had_error() && (error_message() == comp_level_label)) {
>> +       comp_level = CompLevel_full_optimization;
>>
>
> i added this code for compatible with old version and i think that it
> must has the same behavior (use 'CompLevel_full_optimization'). in new
> version we always will have comp_level in replay.txt.
> so i think we shouldn't use CompLevel_highest_tier.

Okay. Please, test it: generate replay.txt with C1 without recording 
comp_level (old style) and then try to replay it with new code.

>
>> Add tests for tiered with different -XX:TieredStopAtLevel=n.
> what exactly did you mean?
> 1) generate replay.txt by VM with different value of 'TieredStopAtLevel'
> 2) use different 'TieredStopAtLevel' during replay of compilation

I meant 1). VM could crash at any level of compilation because they are 
different so we need to be able replay all of them. So I want to verify 
that it works (positive tests).

>
> if 1st, i don't think that test must to iterate through all possible
> values, it must be done by harness, test execution etc

I agree with you but, unfortunately, we are short on testing hardware to 
add an other testing variation. You should know. So adding this testing 
here when tiered VM is tested will help us now.

> if 2nd, current implementation of ciReplay ignore TieredStopAtLevel
> flags, so these tests will be useless.
>
>> You may still not find core file. Or ulimit -c unlimited will not work
>> (windows, OS X?). You need to bailout in such case as success.
> for windows i added '-XX:+CreateMinidumpOnCrash', but whatever case of
> not found core-file need to treat as a environment issue, a test bug or
> may even be a product bug. anyway if it happened, i think it would be
> better to know about this than just skip the test.
>
> i updated webrev according to the rest of your suggestions, but i'm not
> sure about flags to limit core size.

Run in JPRT to verify that tests work on all platforms.

>
> also i added one more check of comp_level and moved validation to
> separate method.

OK.

Thanks,
Vladimir

>
> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.03/
>
> Best regards,
> Igor Ignatyev
>
> On 04/13/2013 02:14 AM, Vladimir Kozlov wrote:
>> I would set CrashAfterCompileId default to -1 as indication it is not
>> set. Then you don't need to check CrashAfterCompileId == 0 since
>> compile_id is positive. By the way, it is very nice idea but add a
>> comment about what that code for. I did not get it first :)
>>
>> About name. For such flags we use CI: CIBreakAt, CIStop. So I would
>> suggest to use CICrashAt. Which means VM crash with that compile id, not
>> when it is greater.
>>
>> If you replaying C1 compilation next setting will be incorrect. Should
>> we use CompLevel_highest_tier instead so that following check pass?:
>>
>> +     if (had_error() && (error_message() == comp_level_label)) {
>> +       comp_level = CompLevel_full_optimization;
>>
>>
>> About tests.
>>
>> Add -Xmx32m, -XX:ParallelGCThreads=2 and other flags (codecache
>> ,metaspace) to limit core size on big machines.
>>
>> Add tests for tiered with different -XX:TieredStopAtLevel=n.
>>
>> I would add more info in output why the test is skipped:
>>       echo TEST SKIPPED
>>
>> typo 'java':
>>   124 is_tiered=`${JAVA} ${TESTVMOPTS} java -XX:+PrintFlagsFinal
>> -version 2>&1 | grep TieredCompilation | grep -c true`
>>
>>
>> I don't like next:
>>
>>   130 ${JAVA} ${TESTVMOPTS} -Xcomp -XX:CrashAfterCompileId=1
>> -XX:+CreateMinidumpOnCrash -XX:+DumpReplayDataOnError -version &
>>   131 crash_pid=$!
>>   132 wait $crash_pid
>>
>>   On windows 'wait $crash_pid' may not work (happened before) because
>> before you execute 'wait' OS may assign the same pid to different
>> process.
>>
>> You may still not find core file. Or ulimit -c unlimited will not work
>> (windows, OS X?). You need to bailout in such case as success. Next code
>> is incorrect for that:
>>
>>    48 if [ -z "${core_file}" -o ! -r "${core_file}" ]
>>    49 then
>>    50     echo TEST FAILED: core wasn\'t generated
>>    51     exit 2
>>    52 fi
>>
>> Thanks
>> Vladimir
>>
>> On 4/12/13 8:27 AM, Igor Ignatyev wrote:
>>> updated webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.02/
>>> added:
>>>    1. more informative message on unsupported comp_level
>>>    2. not-product flag 'CrashAfterCompileId' and assert in
>>> compileBroker.cpp for assured generation of replay.txt
>>>    2. tests for ciReplay
>>>
>>> Best regards,
>>> Igor Ignatyev
>>>
>>> On 04/09/2013 11:40 AM, Vladimir Kozlov wrote:
>>>> Igor,
>>>>
>>>> Sorry, I may said it not clear. What I meant is to set error (call
>>>> report_error()) in such case and return from process_compile() without
>>>> compilation. But let ciReplay::replay() finish and exit. replay_impl()
>>>> should print the problem so you don't need to do it in
>>>> process_compile(). And, please, test it.
>>>> The message should be more informative, something like:
>>>> "compilation level %d requires TieredCompilation"
>>>> An other bad cases is when failure happened in Client (C1) or Server
>>>> (C2) but the replay is run with opposite VM.
>>>>
>>>> thanks,
>>>> Vladimir
>>>>
>>>> On 4/9/13 12:04 AM, Igor Ignatyev wrote:
>>>>> Vladimir,
>>>>>
>>>>> Thank you for review.
>>>>>
>>>>> updated webrev:
>>>>> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.01/
>>>>>
>>>>> Best regards,
>>>>> Igor Ignatyev
>>>>>
>>>>> On 04/09/2013 04:19 AM, Vladimir Kozlov wrote:
>>>>>> Igor,
>>>>>>
>>>>>> Thank you for fixing and cleaning this.
>>>>>>
>>>>>> In vmStructs.cpp move _comp_level after _compile_id as in nmethod
>>>>>> class.
>>>>>>
>>>>>> Typo in ciReplay.cpp:
>>>>>> +      comp_level != CompLevel_highest_tier;
>>>>>>
>>>>>> Actually it is useless to replay compilation at different level, it
>>>>>> should exit with error. Could happened because incorrectly run
>>>>>> without
>>>>>> Tiered when the crush happened with Tiered.
>>>>>>
>>>>>> In ciReplay.cpp use parenthesis around equality checks: if (. &&
>>>>>> (. ==
>>>>>> .)).
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 4/8/13 12:30 PM, Igor Ignatyev wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Please review patch.
>>>>>>>
>>>>>>> Problem:
>>>>>>> Replay of compilations supports c1 and tiered as well as c2, the
>>>>>>> only
>>>>>>> thing missing is comp_level.
>>>>>>>
>>>>>>> Fix:
>>>>>>> 1. added comp_level into dump and usage during replay
>>>>>>> 2. minor changes in agent/doc:
>>>>>>>    - escaped '<', '>'
>>>>>>>    - renamed 'C2 Replay'/'C2 compiler replay' to 'Replay'/'Compiler
>>>>>>> replay'
>>>>>>>
>>>>>>> Testing:
>>>>>>> manually launched the replay from JDK-8010934 (assert
>>>>>>> specifically to
>>>>>>> c1) on jvm w/o corresponded fix. assert was triggered w/ patch and
>>>>>>> wasn't triggered w/o.
>>>>>>>
>>>>>>>
>>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.00/
>>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011675

From david.holmes at oracle.com  Mon Apr 15 16:03:32 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 16 Apr 2013 09:03:32 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516C3273.1040003@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3273.1040003@oracle.com>
Message-ID: <516C8744.3030601@oracle.com>

On 16/04/2013 3:01 AM, Yumin Qi wrote:
> On 4/14/2013 11:07 PM, David Holmes wrote:
>> allocation.hpp:
>>
>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element
>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>> before deallocating ?
>>
> In fact, CardTableRS and CardTableModRefBS are only created once when GC
> flavor specified. It will be cleaned at JVM exit, this is why there is
> no memory leak. To keep a better coding practice, I will add
> FREE_C_HEAP_OBJECT_ARRAY to call dtos, also to free other allocated
> arrays during ctos called.

Thanks. Just because those uses are not freed it doesn't mean this won't 
get used for something else.

>> ---
>>
>> src/share/vm/utilities/quickSort.cpp
>>
>> Why does only Solaris need the allocation headers included ?? I would
>> expect all platforms to need to the same headers here.
>>
> This is due to SunStudio compilation setting. It will issue error on
> solaris like:
>
> src/share/vm/utilities/quickSort.cpp", line 192: Error: The function
> "AllocateHeap" must have a prototype.
>
> in precompiled.hpp:
>
> // Precompiled headers are turned off for Sun Studion,
> // or if the user passes USE_PRECOMPILED_HEADER=0 to the makefiles.
>
> #ifndef DONT_USE_PRECOMPILED_HEADER
>
> I could add the including for all platforms, since it will be excluded
> by other platforms except for solaris --- precompiled.hpp already
> includes those two files. Adding #ifdef SOLARIS here to indicate they
> are only needed for Solaris.

The solaris case is showing you that this only works if precompiled 
headers are enabled. If you disable them you should find this fails to 
compile on the other platforms too. There is a missing #include needed 
for the allocation header.

David
-----


> I will send new webrev out.
>
> Thanks
> Yumin
>
>
>> Thanks,
>> David
>>
>>>
>>>
>>> Thanks
>>> Yumin
>>>
>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>> .
>>>>>> cardTableModRefBS.cpp
>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>
>>>>> This is default constructor does, here just copy that code. Since we
>>>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which
>>>>> will call ctors.
>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>> allocation.hpp #618 does.
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>>
>>>>>> carTableRS.cpp
>>>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>>>
>>>>>>
>>>>> See reply to David H.
>>>>>
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>> -Zhengyu
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>   Can I have your inputs for the fix?
>>>>>>>   webrev:
>>>>>>>
>>>>>>>  http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>> 
>>>>>>>
>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>
>>>>>>> Problem description:  Remove the usage of global operator ::new[]
>>>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>>> disabling use of global operator new[] and new, we constrain the
>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>> ResourceObj unless they are stack objects or values which have to
>>>>>>> be from StackObj or _ValueObj respectively.  Or they have to
>>>>>>> implement their own operator new[] or new.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>

From david.holmes at oracle.com  Mon Apr 15 16:15:01 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 16 Apr 2013 09:15:01 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516C4AF4.7090808@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C4AF4.7090808@oracle.com>
Message-ID: <516C89F5.2090600@oracle.com>

On 16/04/2013 4:46 AM, Ioi Lam wrote:
> On 04/14/2013 11:07 PM, David Holmes wrote:
>> Hi Yumin,
>>
>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>> After take feedback and modify, new webrev
>>>
>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>> 
>>
>> I still find the HandleMark changes unsatisfactory. The CHeap
>> allocated HandleMark in the Thread() constructor is a bit of a hack.
>> HandleMarks should be stack-allocated. Plus we seem to leak that CHeap
>> allocated HandleMark as we don't keep any pointer to it! I think this
>> needs to be re-visited, but as a separate CR.
>>
> David,
>
> The HandleMark is not leaked. It is freed in the Thread destructor:
>
> before:
>
>     355   delete last_handle_mark();

Ah! I see - thanks Ioi.

> after:
>
>     355   FREE_C_HEAP_ARRAY(HandleMark, last_handle_mark(), mtInternal);

Hmmmm - but it isn't an array - makes this part even uglier.

And this doesn't trigger the HandleMark destructor!

David
-----



> - Ioi

From david.holmes at oracle.com  Mon Apr 15 16:20:26 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 16 Apr 2013 09:20:26 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516C75B7.6010700@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
Message-ID: <516C8B3A.9060606@oracle.com>

Adding back compiler and gc teams

On 16/04/2013 7:48 AM, Yumin Qi wrote:
> Zhenyu,
>
> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>> Maybe you need a replacement delete operator, please check
>> http://www.cplusplus.com/reference/new/operator%20delete/
>>
> i can just do
>
> delete ((type *)&array_name[index]);
>
> so the destructor will be called, is this right?

No, it will also deallocate the memory unless you use a variant of 
delete (which is what I think Zhengyu was referring to) that doesn't 
actually deallocate the memory.

I think this is getting out of hand - if we go this path then we should 
simply have a custom operator new[] and operator delete[] and not need 
NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple enough to 
actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that allocates and 
constructs then we need a FREE_C_HEAP_OBJ_ARRAY that destructs and then 
de-allocates.

I have no issue with calling destructors explicitly.

David
-----

> Thanks
> Yumin
>> Thanks,
>>
>> -Zhengyu
>>
>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size, memflags)                  \
>>>   624   {                                                                                 \
>>>   625     if (array_name != NULL) {                                                       \
>>>   626       for (int index = 0; index < size; index ++) {                                 \
>>>   627         /* placement to call dtor on type */                                        \
>>>   628         ((type*)&array_name[index])->~type();                                       \
>>>   629       }                                                                             \
>>>   630       FREE_C_HEAP_ARRAY(type, array_name, memflags);                                \
>>>   631     }                                                                               \
>>>   632   }
>>>
>>>
>>> I really don't like this, calling dtor  ...
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>> new webrev at:
>>>>
>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>
>>>> Can I have a review from GC team for this change?
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>> Hi Yumin,
>>>>>
>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>> After take feedback and modify, new webrev
>>>>>>
>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>> 
>>>>>
>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to leak
>>>>> that CHeap allocated HandleMark as we don't keep any pointer to it!
>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>
>>>>> ---
>>>>>
>>>>> allocation.hpp:
>>>>>
>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element
>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>>>>> before deallocating ?
>>>>>
>>>>> ---
>>>>>
>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>
>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>> would expect all platforms to need to the same headers here.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>
>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>> .
>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>
>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>> Since we
>>>>>>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which
>>>>>>>> will call ctors.
>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>>>>> allocation.hpp #618 does.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Zhengyu
>>>>>>>
>>>>>>>
>>>>>>>>> carTableRS.cpp
>>>>>>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>>>>>>
>>>>>>>>>
>>>>>>>> See reply to David H.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Yumin
>>>>>>>>> -Zhengyu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>   webrev:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>> 
>>>>>>>>>>
>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>
>>>>>>>>>> Problem description:  Remove the usage of global operator ::new[]
>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>>>>>> disabling use of global operator new[] and new, we constrain the
>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>> ResourceObj unless they are stack objects or values which have to
>>>>>>>>>> be from StackObj or _ValueObj respectively.  Or they have to
>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>

From christian.thalinger at oracle.com  Mon Apr 15 17:09:51 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 15 Apr 2013 17:09:51 -0700
Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp
	stub [Was: Re: RFR (S): Specify offset of IC load in
	java_to_interp stub.]
In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFB24B3@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC0CFA7D32@DEWDFEMB12A.global.corp.sap>
	<03C4DFDE-CD52-446E-92AA-A6F12903FE29@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB116E@DEWDFEMB12A.global.corp.sap>
	<7D07437F-CFF7-4298-B9A1-DE9F2E32D77D@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB1EDE@DEWDFEMB12A.global.corp.sap>
	<8A8B46F8-0C91-4E8C-950A-0E65095DB2E0@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB24B3@DEWDFEMB12A.global.corp.sap>
Message-ID: 


On Apr 15, 2013, at 1:49 AM, "Lindenmaier, Goetz"  wrote:

> Hi Goetz,
> 
> to 1).
> I kept it seperate because it was like that before. Further it shows the separation of 
> concerns: one emits to the code section, the other an isolated stub.
> But I'll inline it if you like, it's only static in that file anyways.

No, keep it.  Maybe Dean Long is doing 2).

-- Chris

> 
> Best regards,
>  Goetz.
> 
> 
> -----Original Message-----
> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
> Sent: Freitag, 12. April 2013 23:04
> To: Lindenmaier, Goetz
> Cc: 'hotspot-compiler-dev at openjdk.java.net'
> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
> 
> 
> On Apr 11, 2013, at 2:46 PM, "Lindenmaier, Goetz"  wrote:
> 
>> Hi all,
>> 
>> I prepared the webrev for the changes discussed below:
>> http://cr.openjdk.java.net/~goetz/webrevs/8003853/
>> 
>> To fix the issues we have with the PPC port with finding ICs, this change 
>> cleans up the code handling compiled static Java calls:
>> - Methods using native instructions are moved from compiledIC.cpp
>>  to compiledIC_.cpp.
>> - Methods emitting the call patched by CompiledStaticCall are
>>  moved from the ad file to this class.
>>  As a side effect this reduces redundancies in x86_64.ad and x86_32.ad.
>> - We get rid of extern declarations in output.cpp.
> 
> I like this.  Two comments:
> 
> 1) Does it make sense to have emit_to_interp_stub when it's only used in one place?
> 
> 2) Before we can push this someone has to do the same thing for ARM and PPC.  Any volunteers from the embedded team?
> 
> -- Chris
> 
>> 
>> Now all code concerning CompiledStaticCalls is collected in one class.
>> The PPC port needs not change shared code any more to implement them.
>> I also got around to move code to MacroAssembler, as only a simple call 
>> was needed on x86 and sparc.
>> 
>> Probably this is (M) now, no more (S).
>> 
>> Please review and send comments.  I'll be happy to adapt to them!
>> 
>> Best regards,
>> Goetz Lindenmaier
>> 
>> -----Original Message-----
>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>> Sent: Thursday, April 11, 2013 4:50 AM
>> To: Lindenmaier, Goetz
>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>> 
>> 
>> On Apr 9, 2013, at 7:35 AM, "Lindenmaier, Goetz"  wrote:
>> 
>>> Hi Chris, 
>>> 
>>> I'm now working on this issue.  Sorry for the delay...
>>> 
>>> What do you think about moving 
>>>  void emit_java_to_interp(CodeBuffer& cbuf);
>>> and
>>> void size_java_to_interp();
>>> to compiledIC.hpp and the new platform file, too?
>> 
>> I like that.
>> 
>>> 
>>> This would also allow to overcome the ugly 
>>> extern uint size_java_to_interp();
>>> in output.cpp, as it could be replaced by CompiledStaticCall::size_java_to_interp().
>> 
>> Great.
>> 
>>> 
>>> I also would like to name this
>>> CompiledStaticCall::emit_to_interp_stub()
>>> CompiledStaticCall::to_interp_stub_size()
>> 
>> I'm okay with that.  Not sure if others have objections.
>> 
>>> 
>>> I could also extract code from enc_class Java_Static_Call 
>>> to form a routine
>>> CompiledStaticCall::emit_call(CodeBuffer *cbuf, intptr_t entry_point, relocInfo::relocType rtype) {
>>>  emit_call_reloc(cbuf, entry_point, rtype)
>>>  if (rtype != relocInfo::runtime_call_type) {
>>>      emit_java_to_interp(cbuf);
>>>    }
>>> }
>>> With this, also 
>>> extern uint reloc_java_to_interp();
>>> from output.cpp could be moved into this class.
>> 
>> On SPARC only or the other architectures as well?
>> 
>>> 
>>> Then handling of CompiledStaticCalls would be completely implemented in this
>>> one class.
>> 
>> That's tempting.
>> 
>>> 
>>> (I would have to move emit_call_reloc to MacroAssembler.)
>> 
>> Could you send a webrev with these changes?
>> 
>> -- Chris
>> 
>>> 
>>> Best regards,
>>> Goetz.
>>> 
>>> 
>>> 
>>> -----Original Message-----
>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>> Sent: Montag, 25. M?rz 2013 23:29
>>> To: Lindenmaier, Goetz
>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>> 
>>> 
>>> On Mar 4, 2013, at 8:34 AM, "Lindenmaier, Goetz"  wrote:
>>> 
>>>> Hi Chris, 
>>>> 
>>>> I would like to take up this issue again. 
>>>> I'm about to put our changes on the jdk8 branch, and it would be convenient
>>>> to have a final solution for this.
>>>> 
>>>> Should I prepare a webrev with a different solution adding a new file
>>>> for this?  What should go into that file? 
>>> 
>>> Sorry for answering that late.
>>> 
>>> Yes, to see a patch for that would be good.  We need to put all platform dependent Compiled* methods in that new file.  Platform dependent means every method that uses a native* method from nativeInst_:
>>> 
>>> CompiledIC::cleanup_call_site
>>> CompiledIC::is_icholder_call_site
>>> CompiledIC::CompiledIC
>>> 
>>> CompiledStaticCall::set_to_interpreted
>>> CompiledStaticCall::set_stub_to_clean
>>> CompiledStaticCall::verify
>>> 
>>> -- Chris
>>> 
>>>> 
>>>> Best regards,
>>>> Goetz.
>>>> 
>>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: goetz.lindenmaier at sap.com 
>>>> Sent: Dienstag, 18. Dezember 2012 10:42
>>>> To: 'Christian Thalinger'
>>>> Subject: RE: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>> 
>>>> Hi Chris, 
>>>> 
>>>> What would you put into that file?  The offset, or the class CompiledStaticCall?
>>>> You could also put it into nativeInst_  to avoid adding another file.
>>>> 
>>>> But basically I think the offset is the best solution, because it's very small
>>>> and straight forward, and the offset is set where the code is generated 
>>>> that defines the offset.
>>>> 
>>>> Only the #ifndef COMPILER2 is ugly, but here I think the solution is to 
>>>> guard the whole class CompiledStaticCall with #ifdef COMPILER2.
>>>> 
>>>> But I'm happy with any placement of the code.
>>>> 
>>>> Best regards,
>>>> Goetz.
>>>> 
>>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>> Sent: Montag, 17. Dezember 2012 21:34
>>>> To: Lindenmaier, Goetz
>>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>> 
>>>> 
>>>> On Nov 29, 2012, at 2:10 PM, "Lindenmaier, Goetz"  wrote:
>>>> 
>>>>> Hi Chris, 
>>>>> 
>>>>> Loading the constant takes 5 instructions, the other way only three,
>>>>> in the code only one, if the constant pool base is in a register.
>>>>> The 5 instructions are hard to patch atomically.  The constant pool 
>>>>> is just a 64 bit store.  
>>>>> 
>>>>>> Sorry for being so persistent on this :-)  
>>>>> That's ok, I already found several places in our VM where it was easy to 
>>>>> change our code to get along without the shared changes we did in 
>>>>> first place.  But I can't redesign everything, and I can not risk to break
>>>>> anything in our product.
>>>>> 
>>>>> If you feel like doing so, you can have a look at 
>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/600ce596eea9
>>>>> which contains our bytecode interpreter profiling implementation.
>>>>> If you think this is currently of use in the main branch, I would lift it to HS25 
>>>>> (the permgen changes might cause trouble) and contribute it to hsx.
>>>> 
>>>> Sorry for the long delay.
>>>> 
>>>> Thinking about this problem again it seems that the correct solution would be to have a compiledIC_.cpp file.
>>>> 
>>>> The CompiledIC instruction layout is platform dependent; it just happens to be the same for all architectures we have right now (well, except PPC) because we made it to be the same.  Actually on SPARC we could also use a load from the constant table which would be simpler.
>>>> 
>>>> Having a platform dependent file for this code feels right.  What do you think?
>>>> 
>>>> -- Chris
>>>> 
>>>>> 
>>>>> Best regards,
>>>>> Goetz.
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>> Sent: Thursday, November 29, 2012 7:53 PM
>>>>> To: Lindenmaier, Goetz
>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>> 
>>>>> 
>>>>> On Nov 29, 2012, at 12:27 AM, "Lindenmaier, Goetz"  wrote:
>>>>> 
>>>>>> Hi Chris, 
>>>>>> 
>>>>>>> Why can't you point the relocation to the method load instruction?  It doesn't seem right to do that in shared code.
>>>>>> Because the relocation is used 
>>>>>> 1.) to find the beginning of the stub to patch the call to go there 
>>>>>> 2.) to find the load to patch the IC.
>>>>> 
>>>>> Got it.
>>>>> 
>>>>>> 
>>>>>> Just have a look at CompiledStaticCall::set_to_interpreted(),
>>>>>> the variable 'stub' is used twice.  
>>>>> 
>>>>> Sorry for being so persistent on this :-)  What is the reason you have to load the constant from the constant table?  On other architectures we materialize the constant.
>>>>> 
>>>>> -- Chris
>>>>> 
>>>>>> 
>>>>>> Best regards, 
>>>>>> Goetz.
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>>> Sent: Donnerstag, 29. November 2012 01:35
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>>> 
>>>>>> 
>>>>>> On Nov 27, 2012, at 4:24 AM, "Lindenmaier, Goetz"  wrote:
>>>>>> 
>>>>>>> Hi Chris,
>>>>>>> 
>>>>>>>> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub?
>>>>>>> Shared code (class CompiledStaticCall) wants to patch the inline cache 
>>>>>>> in the stub which is emitted in platform code.
>>>>>>> So the platform code should specify how the shared code can find the inline cache 
>>>>>>> in the stub, which it does through the constant I introduced.
>>>>>>> 
>>>>>>>> Do you need two relocations?  I'm confused.
>>>>>>> No, three ;)
>>>>>>> The relocation you mention is used to find the stub given the call.
>>>>>>> The other relocations are needed to find the inline cache / call target
>>>>>>> once the stub is found (see CompiledStaticCall::set_to_interpreted()).
>>>>>>> It's just the same on x86_64:
>>>>>>> 
>>>>>>> // static stub relocation stores the instruction address of the call
>>>>>>> __ relocate(static_stub_Relocation::spec(mark), RELOC_IMM64); 
>>>>>>> // static stub relocation also tags the methodOop in the code-stream.
>>>>>>> __ movoop(rbx, (jobject) NULL);  // method is zapped till fixup time
>>>>>>> // This is recognized as unresolved by relocs/nativeinst/ic code
>>>>>>> __ jump(RuntimeAddress(__ pc()));
>>>>>>> 
>>>>>>> On PPC, we have to load the base of the constant table after generating the 
>>>>>>> static_stub_relocation and before emitting the ppc equivalent for moveoop(). This offset is 
>>>>>>> exactly what we store in the  CompiledStaticCall::comp_to_int_load_offset constant.
>>>>>> 
>>>>>> Why can't you point the relocation to the method load instruction?  It doesn't seem right to do that in shared code.
>>>>>> 
>>>>>> -- Chris
>>>>>> 
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> Goetz.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>>>> Sent: Dienstag, 27. November 2012 01:53
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>>>> 
>>>>>>> 
>>>>>>> On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz"  wrote:
>>>>>>> 
>>>>>>>> Hi Chris,
>>>>>>>> 
>>>>>>>> We put it into the ad file because it describes an offset into the stub that is
>>>>>>>> generated from the ad file by emit_java_to_interp(CodeBuffer& cbuf), 
>>>>>>>> used by ir  node CallStaticJavaDirect.  Maybe I should not call it stub, but it's 
>>>>>>>> generated into the stubs section of the code buffer.
>>>>>>>> If that stub generator is moved out of the ad file to shared compiler code, one should
>>>>>>>> move the field with it, but for the current implementation I think that's fine.
>>>>>>>> 
>>>>>>>> Does C1 generate the same stub? Or is the CompiledStaticCall a C2 feature?
>>>>>>>> If so, one could protect the whole thing by #ifdef COMPILER2.
>>>>>>> 
>>>>>>> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub?
>>>>>>> 
>>>>>>> // Create a static stub relocation which relates this stub
>>>>>>> // with the call instruction at insts_call_instruction_offset in the
>>>>>>> // instructions code-section.
>>>>>>> __ relocate(static_stub_Relocation::spec(__ code()->insts()->start() + insts_relocation_offset));
>>>>>>> 
>>>>>>> Do you need two relocations?  I'm confused.
>>>>>>> 
>>>>>>> -- Chris
>>>>>>> 
>>>>>>>> 
>>>>>>>> Thanks for all the bugids!
>>>>>>>> 
>>>>>>>> Best regards,
>>>>>>>> Goetz.
>>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>>>>> Sent: Mittwoch, 21. November 2012 19:53
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>> Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz"  wrote:
>>>>>>>> 
>>>>>>>>> Hi Chris, 
>>>>>>>>> 
>>>>>>>>> yes, there is no C1 on ppc.  
>>>>>>>>> We do tiered compilation with a stripped C2.
>>>>>>>> 
>>>>>>>> Right.  But some other architecture (or in the future) might need this for C1 as well.  We should find a better place for the value than the ad file.  The obvious place would be compiledIC_.hpp but we don't have that file, yet.
>>>>>>>> 
>>>>>>>> I filed:
>>>>>>>> 
>>>>>>>> 8003853: specify offset of IC load in java_to_interp stub
>>>>>>>> 
>>>>>>>> -- Chris
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Best regards,
>>>>>>>>> Goetz
>>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>>>>>>>>> Sent: Dienstag, 20. November 2012 22:19
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>> Subject: Re: RFR (S): Specify offset of IC load in java_to_interp stub.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz"  wrote:
>>>>>>>>> 
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub
>>>>>>>>>> to update the IC  with NativeMovConstReg.  The current implementation assumes that
>>>>>>>>>> the load is always the first instruction in the stub.  This is an artificial restriction. E.g.,
>>>>>>>>>> it might be useful to load the constant pool address (MachConstantBase) before the
>>>>>>>>>> IC load (as we do on PPC).
>>>>>>>>>> 
>>>>>>>>>> This change adds a constant specifying an offset from the beginning of the stub to
>>>>>>>>>> the  IC load. The offset is platform specific and 0 on sparc and x86.
>>>>>>>>>> 
>>>>>>>>>> You can find the change here:
>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/
>>>>>>>>> 
>>>>>>>>> That should be fixed indeed.  
>>>>>>>>> 
>>>>>>>>> +#ifndef COMPILER2
>>>>>>>>> +const int CompiledStaticCall::comp_to_int_load_offset = 0;
>>>>>>>>> 
>>>>>>>>> There is no C1 for PPC (sorry, I didn't check)?
>>>>>>>>> 
>>>>>>>>> -- Chris
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> or in our ppc port:
>>>>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33
>>>>>>>>>> 
>>>>>>>>>> Thank you and best regards,
>>>>>>>>>> Goetz
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


From christian.thalinger at oracle.com  Mon Apr 15 18:32:31 2013
From: christian.thalinger at oracle.com (christian.thalinger at oracle.com)
Date: Tue, 16 Apr 2013 01:32:31 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 7172922: export_ makefile targets do
	not work unless all supported variants are built
Message-ID: <20130416013233.79E124831C@hg.openjdk.java.net>

Changeset: 1c6887c9afaa
Author:    twisti
Date:      2013-04-15 16:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1c6887c9afaa

7172922: export_ makefile targets do not work unless all supported variants are built
Reviewed-by: dholmes, kvn

! make/Makefile


From niclas.adlertz at oracle.com  Mon Apr 15 21:52:37 2013
From: niclas.adlertz at oracle.com (Niclas Adlertz)
Date: Tue, 16 Apr 2013 06:52:37 +0200
Subject: RFR(M) 8011621: Keep the "live range id - node" mapping in a
	separate class
In-Reply-To: <516C355E.9030608@oracle.com>
References: <941B0F67-1B66-45EF-8150-BB9F435EB9CD@oracle.com>
	<51630DAA.8060906@oracle.com>
	<2650A2B9-507B-4031-BF2F-CA636160197E@oracle.com>
	<51684F15.10701@oracle.com>
	<166470D8-5C28-4904-95C9-3400BFE00ECB@oracle.com>
	
	<516C355E.9030608@oracle.com>
Message-ID: <0B61BA60-504E-4EAD-A04B-EDCB7FCBCC1C@oracle.com>

Thank you Vladimir.

Regards,
Niclas 

On 15 apr 2013, at 19:14, Vladimir Kozlov wrote:

> Looks good.
> 
> Thanks,
> Vladimir
> 
> On 4/15/13 4:19 AM, Niclas Adlertz wrote:
>> Hi, thank you all for the comments.
>> 
>> Christian
>> ---------
>>> Now that the chaitin_.cpp files are gone I think we can remove these references in the Makefiles:
>>> 
>>> $ ack -a chaitin make/
>>> make/bsd/makefiles/vm.make
>>> 190:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*
>>> 
>>> make/linux/makefiles/vm.make
>>> 192:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*
>>> 
>>> make/solaris/makefiles/vm.make
>>> 205:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*
>>> 
>>> make/windows/create_obj_files.sh
>>> 117:COMPILER2_SPECIFIC_FILES="opto libadt bcEscapeAnalyzer.cpp chaitin* c2_* runtime_*"
>> 
>> Thank you, fixed.
>> 
>> Vladimir
>> --------
>>> Move small PhaseChaitin::clone_projs() methods which calls clone_projs_shared() into the header file.
>> Ok, fixed.
>> 
>>> May be you should move the rest of PhaseChaitin methods from coalesce.cpp to chaitin.cpp where they are logically belong.
>> Sounds like a good idea, thank you. Fixed.
>> 
>>> You added clone_projs() to PhaseCoalesce class but it is not defined or used.
>> Good catch. Removed.
>> 
>> 
>> Roland
>> ------
>> 
>>> Did you use hg remove for the files that are not needed anymore?
>> I did rm file, hg qnew and hg qrefresh.
>> 
>>> Shouldn't LiveRangeMap be VALUE_OBJ_CLASS_SPEC?
>> It should, thank you. Fixed.
>> 
>>> live.hpp: comment not aligned anymore.
>> Fixed.
>> 
>> 
>> The new webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011621/webrev03/
>> 
>> Regards,
>> Niclas Adlertz
>> 
>> On 12 apr 2013, at 23:18, Christian Thalinger wrote:
>> 
>>> 
>>> On Apr 12, 2013, at 11:14 AM, Vladimir Kozlov  wrote:
>>> 
>>>> Hurray :) more dead code removed.
>>> 
>>> Now that the chaitin_.cpp files are gone I think we can remove these references in the Makefiles:
>>> 
>>> $ ack -a chaitin make/
>>> make/bsd/makefiles/vm.make
>>> 190:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*
>>> 
>>> make/linux/makefiles/vm.make
>>> 192:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*
>>> 
>>> make/solaris/makefiles/vm.make
>>> 205:COMPILER2_SPECIFIC_FILES := opto libadt bcEscapeAnalyzer.cpp chaitin\* c2_\* runtime_\*
>>> 
>>> make/windows/create_obj_files.sh
>>> 117:COMPILER2_SPECIFIC_FILES="opto libadt bcEscapeAnalyzer.cpp chaitin* c2_* runtime_*"
>>> 
>>> -- Chris
>>> 
>>>> 
>>>> Move small PhaseChaitin::clone_projs() methods which calls clone_projs_shared() into the header file.
>>>> 
>>>> May be you should move the rest of PhaseChaitin methods from coalesce.cpp to chaitin.cpp where they are logically belong.
>>>> 
>>>> You added clone_projs() to PhaseCoalesce class but it is not defined or used.
>>>> 
>>>> Thanks,
>>>> Vladimir
>>>> 
>>>> On 4/12/13 5:01 AM, Niclas Adlertz wrote:
>>>>> Hi again,
>>>>> 
>>>>> Thank you for your comments.
>>>>> 
>>>>> Vladimir:
>>>>> ---------
>>>>> 
>>>>>> ${JAVA_HOME}/bin/java -server -Xss4m -verify -XX:+CompileTheWorld -XX:+TimeCompiler -Xbootclasspath/p:${JAVA_HOME}/jre/lib/rt.jar
>>>>> 
>>>>> Base: Total compilation: 2235.880 sec.
>>>>> Fix: Total compilation: 2226.020 sec.
>>>>> 
>>>>> So the fix should be ok in terms of compilation time.
>>>>> 
>>>>>> Can you use full name LiveRangeMap instead of LRGMap?
>>>>> Sure, fixed.
>>>>> 
>>>>>> Don't put big methods with loops into header file, we don't want to increase code size without need.
>>>>> Ok, fixed.
>>>>> 
>>>>>> Explicitly declare private: and public: parts in class. Add comment what is class for.
>>>>> Done.
>>>>> 
>>>>>> I like Roland's suggestion (LRGMap _lrg_map;) because it avoids a reference through _lrg_map pointer (in compiled code C++ needs only one PhaseChaitin* pointer).
>>>>> Done.
>>>>> 
>>>>> Roland:
>>>>> -------
>>>>> 
>>>>>> In vmStructs.cpp, you need to add a declaration for PhaseChaitin::_lrg_map otherwise:
>>>>>> c2_nonstatic_field(LRGMap,             _max_lrg_id,              uint)
>>>>>> is useless.
>>>>> I removed it from vmStructs.cpp completely instead, since it's not used by the agent.
>>>>> 
>>>>>> Why not declare: LRGMap _lrg_map; rather than stack allocate it and set a pointer.
>>>>> I just followed the old pattern, but that's a good remark, thank you.
>>>>> Fixed.
>>>>> 
>>>>>> Can you add comments describing what LRGMap is before its declaration?
>>>>>> 
>>>>>> Shouldn't that:
>>>>>> 242   if (C->unique() > _lrg_map->_names.Size()) {
>>>>>> 243     _lrg_map->_names.extend(C->unique() - 1, 0);
>>>>>> 244   }
>>>>>> 
>>>>>> be moved to the LRGMap constructor?
>>>>> 
>>>>> This code is not necessary anymore, because I also took the liberty of removing
>>>>> pd_preallocate_hook();
>>>>> and
>>>>> pd_postallocate_verify_hook();
>>>>> 
>>>>> which are not needed anymore because they only added nodes for Win95 and Win 98.
>>>>> 
>>>>>> Shouldn't you make _max_lrg_id, _uf_map and _names private and have accessors?
>>>>> I have now made public methods for performing operations on _max_lrg_id, _uf_map and _names.
>>>>> 
>>>>> ---------
>>>>> 
>>>>> The new webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011621/webrev02/
>>>>> 
>>>>> Thank you.
>>>>> 
>>>>> Regards,
>>>>> Niclas Adlertz
>>>>> 
>>>>> On 8 apr 2013, at 20:34, Vladimir Kozlov wrote:
>>>>> 
>>>>>> Niclas,
>>>>>> 
>>>>>> Thank you for doing this cleanup.
>>>>>> 
>>>>>> Please, test affection on RA performance. You can use CTW for this and fastdebug VM:
>>>>>> 
>>>>>> ${JAVA_HOME}/bin/java -server -Xss4m -verify -XX:+CompileTheWorld -XX:+TimeCompiler -Xbootclasspath/p:${JAVA_HOME}/jre/lib/rt.jar
>>>>>> 
>>>>>> Or build optimized VM and run jvm08, for example, with -XX:+TimeCompiler.
>>>>>> 
>>>>>> Can you use full name LiveRangeMap instead of LRGMap?
>>>>>> Don't put big methods with loops into header file, we don't want to increase code size without need.
>>>>>> 
>>>>>> Explicitly declare private: and public: parts in class. Add comment what is class for.
>>>>>> 
>>>>>> I like Roland's suggestion (LRGMap _lrg_map;) because it avoids a reference through _lrg_map pointer (in compiled code C++ needs only one PhaseChaitin* pointer).
>>>>>> 
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>> 
>>>>>> On 4/8/13 3:05 AM, Niclas Adlertz wrote:
>>>>>>> Hi all.
>>>>>>> 
>>>>>>> Problem:
>>>>>>> In order to clean up the Split code (in opto/reg_split.cpp) making it easier to maintain and (hopefully) making it easier to improve (https://jbs.oracle.com/bugs/browse/JDK-7022320), it would be good to have the Split code more isolated with as few dependencies to other parts of the code as possible.
>>>>>>> The Split code could reside in an own module (class), just having references to classes and data it really needs. Right now it would need to have a reference to PhaseChaitin, only to access the "live range id - node" mapping. However, it does not need to know about everything in the PhaseChaitin class. This may also introduce cross reference problems since PhaseChaitin would use the Split module and the Split module would need a reference to PhaseChaitin.
>>>>>>> 
>>>>>>> Solution:
>>>>>>> Move the "live range id - node" mapping to a separate class, instantiated by PhaseChaitin, which can then be passed to the Split module as a reference.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Niclas Adlertz
>>>>>>> 
>>>>>>> (Note that the webrev title is named JDK-7022320. That's just the local folder name that the code resides in. The bug is indeed 8011621)
>>>>>>> 
>>>>>>> -----------------------------------------------------------------
>>>>>>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011621/webrev00/
>>>>>>>   jbs: https://jbs.oracle.com/bugs/browse/JDK-8011621
>>>>>>>  bugs: http://bugs.sun.com/view_bug.do?bug_id=8011621
>>>>>>> 
>>>>>>> 
>>>>> 
>>> 
>> 


From dean.long at oracle.com  Mon Apr 15 21:54:59 2013
From: dean.long at oracle.com (Dean Long)
Date: Mon, 15 Apr 2013 21:54:59 -0700
Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp
	stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp
	stub.]
In-Reply-To: <8A8B46F8-0C91-4E8C-950A-0E65095DB2E0@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC0CFA7D32@DEWDFEMB12A.global.corp.sap>
	<03C4DFDE-CD52-446E-92AA-A6F12903FE29@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB116E@DEWDFEMB12A.global.corp.sap>
	<7D07437F-CFF7-4298-B9A1-DE9F2E32D77D@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB1EDE@DEWDFEMB12A.global.corp.sap>
	<8A8B46F8-0C91-4E8C-950A-0E65095DB2E0@oracle.com>
Message-ID: <516CD9A3.3030202@oracle.com>

sparc.ad:

2538       CompiledStaticCall::emit_call(cbuf,
2539                                     (int) ($meth$$method - ((intptr_t) cbuf.insts_end()) - 4),
2540                                     rtype);

I think this should be:

CompiledStaticCall::emit_call(cbuf,$meth$$method,  rtype);

Computing the PC-relative offset probably only applies to x86.

dl

On 4/12/2013 2:03 PM, Christian Thalinger wrote:
> On Apr 11, 2013, at 2:46 PM, "Lindenmaier, Goetz"  wrote:
>
>> Hi all,
>>
>> I prepared the webrev for the changes discussed below:
>> http://cr.openjdk.java.net/~goetz/webrevs/8003853/
>>
>> To fix the issues we have with the PPC port with finding ICs, this change
>> cleans up the code handling compiled static Java calls:
>> - Methods using native instructions are moved from compiledIC.cpp
>>    to compiledIC_.cpp.
>> - Methods emitting the call patched by CompiledStaticCall are
>>    moved from the ad file to this class.
>>    As a side effect this reduces redundancies in x86_64.ad and x86_32.ad.
>> - We get rid of extern declarations in output.cpp.
> I like this.  Two comments:
>
> 1) Does it make sense to have emit_to_interp_stub when it's only used in one place?
>
> 2) Before we can push this someone has to do the same thing for ARM and PPC.  Any volunteers from the embedded team?
>
> -- Chris
>
>> Now all code concerning CompiledStaticCalls is collected in one class.
>> The PPC port needs not change shared code any more to implement them.
>> I also got around to move code to MacroAssembler, as only a simple call
>> was needed on x86 and sparc.
>>
>> Probably this is (M) now, no more (S).
>>
>> Please review and send comments.  I'll be happy to adapt to them!
>>
>> Best regards,
>>   Goetz Lindenmaier
>>
>> -----Original Message-----
>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>> Sent: Thursday, April 11, 2013 4:50 AM
>> To: Lindenmaier, Goetz
>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>
>>
>> On Apr 9, 2013, at 7:35 AM, "Lindenmaier, Goetz"  wrote:
>>
>>> Hi Chris,
>>>
>>> I'm now working on this issue.  Sorry for the delay...
>>>
>>> What do you think about moving
>>>    void emit_java_to_interp(CodeBuffer& cbuf);
>>> and
>>>   void size_java_to_interp();
>>> to compiledIC.hpp and the new platform file, too?
>> I like that.
>>
>>> This would also allow to overcome the ugly
>>>   extern uint size_java_to_interp();
>>> in output.cpp, as it could be replaced by CompiledStaticCall::size_java_to_interp().
>> Great.
>>
>>> I also would like to name this
>>> CompiledStaticCall::emit_to_interp_stub()
>>> CompiledStaticCall::to_interp_stub_size()
>> I'm okay with that.  Not sure if others have objections.
>>
>>> I could also extract code from enc_class Java_Static_Call
>>> to form a routine
>>> CompiledStaticCall::emit_call(CodeBuffer *cbuf, intptr_t entry_point, relocInfo::relocType rtype) {
>>>    emit_call_reloc(cbuf, entry_point, rtype)
>>>    if (rtype != relocInfo::runtime_call_type) {
>>>        emit_java_to_interp(cbuf);
>>>      }
>>> }
>>> With this, also
>>> extern uint reloc_java_to_interp();
>>> from output.cpp could be moved into this class.
>> On SPARC only or the other architectures as well?
>>
>>> Then handling of CompiledStaticCalls would be completely implemented in this
>>> one class.
>> That's tempting.
>>
>>> (I would have to move emit_call_reloc to MacroAssembler.)
>> Could you send a webrev with these changes?
>>
>> -- Chris
>>
>>> Best regards,
>>> Goetz.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>> Sent: Montag, 25. M?rz 2013 23:29
>>> To: Lindenmaier, Goetz
>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>
>>>
>>> On Mar 4, 2013, at 8:34 AM, "Lindenmaier, Goetz"  wrote:
>>>
>>>> Hi Chris,
>>>>
>>>> I would like to take up this issue again.
>>>> I'm about to put our changes on the jdk8 branch, and it would be convenient
>>>> to have a final solution for this.
>>>>
>>>> Should I prepare a webrev with a different solution adding a new file
>>>> for this?  What should go into that file?
>>> Sorry for answering that late.
>>>
>>> Yes, to see a patch for that would be good.  We need to put all platform dependent Compiled* methods in that new file.  Platform dependent means every method that uses a native* method from nativeInst_:
>>>
>>> CompiledIC::cleanup_call_site
>>> CompiledIC::is_icholder_call_site
>>> CompiledIC::CompiledIC
>>>
>>> CompiledStaticCall::set_to_interpreted
>>> CompiledStaticCall::set_stub_to_clean
>>> CompiledStaticCall::verify
>>>
>>> -- Chris
>>>
>>>> Best regards,
>>>> Goetz.
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: goetz.lindenmaier at sap.com
>>>> Sent: Dienstag, 18. Dezember 2012 10:42
>>>> To: 'Christian Thalinger'
>>>> Subject: RE: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>
>>>> Hi Chris,
>>>>
>>>> What would you put into that file?  The offset, or the class CompiledStaticCall?
>>>> You could also put it into nativeInst_  to avoid adding another file.
>>>>
>>>> But basically I think the offset is the best solution, because it's very small
>>>> and straight forward, and the offset is set where the code is generated
>>>> that defines the offset.
>>>>
>>>> Only the #ifndef COMPILER2 is ugly, but here I think the solution is to
>>>> guard the whole class CompiledStaticCall with #ifdef COMPILER2.
>>>>
>>>> But I'm happy with any placement of the code.
>>>>
>>>> Best regards,
>>>> Goetz.
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>> Sent: Montag, 17. Dezember 2012 21:34
>>>> To: Lindenmaier, Goetz
>>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>
>>>>
>>>> On Nov 29, 2012, at 2:10 PM, "Lindenmaier, Goetz"  wrote:
>>>>
>>>>> Hi Chris,
>>>>>
>>>>> Loading the constant takes 5 instructions, the other way only three,
>>>>> in the code only one, if the constant pool base is in a register.
>>>>> The 5 instructions are hard to patch atomically.  The constant pool
>>>>> is just a 64 bit store.
>>>>>
>>>>>> Sorry for being so persistent on this :-)
>>>>> That's ok, I already found several places in our VM where it was easy to
>>>>> change our code to get along without the shared changes we did in
>>>>> first place.  But I can't redesign everything, and I can not risk to break
>>>>> anything in our product.
>>>>>
>>>>> If you feel like doing so, you can have a look at
>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/600ce596eea9
>>>>> which contains our bytecode interpreter profiling implementation.
>>>>> If you think this is currently of use in the main branch, I would lift it to HS25
>>>>> (the permgen changes might cause trouble) and contribute it to hsx.
>>>> Sorry for the long delay.
>>>>
>>>> Thinking about this problem again it seems that the correct solution would be to have a compiledIC_.cpp file.
>>>>
>>>> The CompiledIC instruction layout is platform dependent; it just happens to be the same for all architectures we have right now (well, except PPC) because we made it to be the same.  Actually on SPARC we could also use a load from the constant table which would be simpler.
>>>>
>>>> Having a platform dependent file for this code feels right.  What do you think?
>>>>
>>>> -- Chris
>>>>
>>>>> Best regards,
>>>>> Goetz.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>> Sent: Thursday, November 29, 2012 7:53 PM
>>>>> To: Lindenmaier, Goetz
>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>>
>>>>>
>>>>> On Nov 29, 2012, at 12:27 AM, "Lindenmaier, Goetz"  wrote:
>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>>> Why can't you point the relocation to the method load instruction?  It doesn't seem right to do that in shared code.
>>>>>> Because the relocation is used
>>>>>> 1.) to find the beginning of the stub to patch the call to go there
>>>>>> 2.) to find the load to patch the IC.
>>>>> Got it.
>>>>>
>>>>>> Just have a look at CompiledStaticCall::set_to_interpreted(),
>>>>>> the variable 'stub' is used twice.
>>>>> Sorry for being so persistent on this :-)  What is the reason you have to load the constant from the constant table?  On other architectures we materialize the constant.
>>>>>
>>>>> -- Chris
>>>>>
>>>>>> Best regards,
>>>>>> Goetz.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>> Sent: Donnerstag, 29. November 2012 01:35
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>>>
>>>>>>
>>>>>> On Nov 27, 2012, at 4:24 AM, "Lindenmaier, Goetz"  wrote:
>>>>>>
>>>>>>> Hi Chris,
>>>>>>>
>>>>>>>> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub?
>>>>>>> Shared code (class CompiledStaticCall) wants to patch the inline cache
>>>>>>> in the stub which is emitted in platform code.
>>>>>>> So the platform code should specify how the shared code can find the inline cache
>>>>>>> in the stub, which it does through the constant I introduced.
>>>>>>>
>>>>>>>> Do you need two relocations?  I'm confused.
>>>>>>> No, three ;)
>>>>>>> The relocation you mention is used to find the stub given the call.
>>>>>>> The other relocations are needed to find the inline cache / call target
>>>>>>> once the stub is found (see CompiledStaticCall::set_to_interpreted()).
>>>>>>> It's just the same on x86_64:
>>>>>>>
>>>>>>> // static stub relocation stores the instruction address of the call
>>>>>>> __ relocate(static_stub_Relocation::spec(mark), RELOC_IMM64);
>>>>>>> // static stub relocation also tags the methodOop in the code-stream.
>>>>>>> __ movoop(rbx, (jobject) NULL);  // method is zapped till fixup time
>>>>>>> // This is recognized as unresolved by relocs/nativeinst/ic code
>>>>>>> __ jump(RuntimeAddress(__ pc()));
>>>>>>>
>>>>>>> On PPC, we have to load the base of the constant table after generating the
>>>>>>> static_stub_relocation and before emitting the ppc equivalent for moveoop(). This offset is
>>>>>>> exactly what we store in the  CompiledStaticCall::comp_to_int_load_offset constant.
>>>>>> Why can't you point the relocation to the method load instruction?  It doesn't seem right to do that in shared code.
>>>>>>
>>>>>> -- Chris
>>>>>>
>>>>>>> Best regards,
>>>>>>> Goetz.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>> Sent: Dienstag, 27. November 2012 01:53
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>>>>
>>>>>>>
>>>>>>> On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz"  wrote:
>>>>>>>
>>>>>>>> Hi Chris,
>>>>>>>>
>>>>>>>> We put it into the ad file because it describes an offset into the stub that is
>>>>>>>> generated from the ad file by emit_java_to_interp(CodeBuffer& cbuf),
>>>>>>>> used by ir  node CallStaticJavaDirect.  Maybe I should not call it stub, but it's
>>>>>>>> generated into the stubs section of the code buffer.
>>>>>>>> If that stub generator is moved out of the ad file to shared compiler code, one should
>>>>>>>> move the field with it, but for the current implementation I think that's fine.
>>>>>>>>
>>>>>>>> Does C1 generate the same stub? Or is the CompiledStaticCall a C2 feature?
>>>>>>>> If so, one could protect the whole thing by #ifdef COMPILER2.
>>>>>>> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub?
>>>>>>>
>>>>>>> // Create a static stub relocation which relates this stub
>>>>>>> // with the call instruction at insts_call_instruction_offset in the
>>>>>>> // instructions code-section.
>>>>>>> __ relocate(static_stub_Relocation::spec(__ code()->insts()->start() + insts_relocation_offset));
>>>>>>>
>>>>>>> Do you need two relocations?  I'm confused.
>>>>>>>
>>>>>>> -- Chris
>>>>>>>
>>>>>>>> Thanks for all the bugids!
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Goetz.
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>>> Sent: Mittwoch, 21. November 2012 19:53
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>> Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>>>>>
>>>>>>>>
>>>>>>>> On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz"  wrote:
>>>>>>>>
>>>>>>>>> Hi Chris,
>>>>>>>>>
>>>>>>>>> yes, there is no C1 on ppc.
>>>>>>>>> We do tiered compilation with a stripped C2.
>>>>>>>> Right.  But some other architecture (or in the future) might need this for C1 as well.  We should find a better place for the value than the ad file.  The obvious place would be compiledIC_.hpp but we don't have that file, yet.
>>>>>>>>
>>>>>>>> I filed:
>>>>>>>>
>>>>>>>> 8003853: specify offset of IC load in java_to_interp stub
>>>>>>>>
>>>>>>>> -- Chris
>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Goetz
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>>>> Sent: Dienstag, 20. November 2012 22:19
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>> Subject: Re: RFR (S): Specify offset of IC load in java_to_interp stub.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz"  wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub
>>>>>>>>>> to update the IC  with NativeMovConstReg.  The current implementation assumes that
>>>>>>>>>> the load is always the first instruction in the stub.  This is an artificial restriction. E.g.,
>>>>>>>>>> it might be useful to load the constant pool address (MachConstantBase) before the
>>>>>>>>>> IC load (as we do on PPC).
>>>>>>>>>>
>>>>>>>>>> This change adds a constant specifying an offset from the beginning of the stub to
>>>>>>>>>> the  IC load. The offset is platform specific and 0 on sparc and x86.
>>>>>>>>>>
>>>>>>>>>> You can find the change here:
>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/
>>>>>>>>> That should be fixed indeed.
>>>>>>>>>
>>>>>>>>> +#ifndef COMPILER2
>>>>>>>>> +const int CompiledStaticCall::comp_to_int_load_offset = 0;
>>>>>>>>>
>>>>>>>>> There is no C1 for PPC (sorry, I didn't check)?
>>>>>>>>>
>>>>>>>>> -- Chris
>>>>>>>>>
>>>>>>>>>> or in our ppc port:
>>>>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33
>>>>>>>>>>
>>>>>>>>>> Thank you and best regards,
>>>>>>>>>> Goetz
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>


From dean.long at oracle.com  Mon Apr 15 22:19:38 2013
From: dean.long at oracle.com (Dean Long)
Date: Mon, 15 Apr 2013 22:19:38 -0700
Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp
	stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp
	stub.]
In-Reply-To: <516CD9A3.3030202@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC0CFA7D32@DEWDFEMB12A.global.corp.sap>
	<03C4DFDE-CD52-446E-92AA-A6F12903FE29@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB116E@DEWDFEMB12A.global.corp.sap>
	<7D07437F-CFF7-4298-B9A1-DE9F2E32D77D@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB1EDE@DEWDFEMB12A.global.corp.sap>
	<8A8B46F8-0C91-4E8C-950A-0E65095DB2E0@oracle.com>
	<516CD9A3.3030202@oracle.com>
Message-ID: <516CDF6A.4080900@oracle.com>

Also, is moving the call into CompiledStaticCall::emit_call() really 
needed for PPC?  I'd prefer to move the
stub emitter instead (sample sparc code):

     if ( !_method ) {
       emit_call_reloc(cbuf, $meth$$method, relocInfo::runtime_call_type);
     } else if (_optimized_virtual) {
       emit_call_reloc(cbuf, $meth$$method, 
relocInfo::opt_virtual_call_type);
     } else {
       emit_call_reloc(cbuf, $meth$$method, relocInfo::static_call_type);
     }
     if( _method ) {  // Emit stub for static call
       CompiledStaticCall::emit_java_to_interp(cbuf);<---
     }

dl

On 4/15/2013 9:54 PM, Dean Long wrote:
> sparc.ad:
>
> 2538       CompiledStaticCall::emit_call(cbuf,
> 2539                                     (int) ($meth$$method - 
> ((intptr_t) cbuf.insts_end()) - 4),
> 2540                                     rtype);
>
> I think this should be:
>
> CompiledStaticCall::emit_call(cbuf,$meth$$method,  rtype);
>
> Computing the PC-relative offset probably only applies to x86.
>
> dl
>
> On 4/12/2013 2:03 PM, Christian Thalinger wrote:
>> On Apr 11, 2013, at 2:46 PM, "Lindenmaier, Goetz" 
>>  wrote:
>>
>>> Hi all,
>>>
>>> I prepared the webrev for the changes discussed below:
>>> http://cr.openjdk.java.net/~goetz/webrevs/8003853/
>>>
>>> To fix the issues we have with the PPC port with finding ICs, this 
>>> change
>>> cleans up the code handling compiled static Java calls:
>>> - Methods using native instructions are moved from compiledIC.cpp
>>>    to compiledIC_.cpp.
>>> - Methods emitting the call patched by CompiledStaticCall are
>>>    moved from the ad file to this class.
>>>    As a side effect this reduces redundancies in x86_64.ad and 
>>> x86_32.ad.
>>> - We get rid of extern declarations in output.cpp.
>> I like this.  Two comments:
>>
>> 1) Does it make sense to have emit_to_interp_stub when it's only used 
>> in one place?
>>
>> 2) Before we can push this someone has to do the same thing for ARM 
>> and PPC.  Any volunteers from the embedded team?
>>
>> -- Chris
>>
>>> Now all code concerning CompiledStaticCalls is collected in one class.
>>> The PPC port needs not change shared code any more to implement them.
>>> I also got around to move code to MacroAssembler, as only a simple call
>>> was needed on x86 and sparc.
>>>
>>> Probably this is (M) now, no more (S).
>>>
>>> Please review and send comments.  I'll be happy to adapt to them!
>>>
>>> Best regards,
>>>   Goetz Lindenmaier
>>>
>>> -----Original Message-----
>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>> Sent: Thursday, April 11, 2013 4:50 AM
>>> To: Lindenmaier, Goetz
>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in 
>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in 
>>> java_to_interp stub.]
>>>
>>>
>>> On Apr 9, 2013, at 7:35 AM, "Lindenmaier, Goetz" 
>>>  wrote:
>>>
>>>> Hi Chris,
>>>>
>>>> I'm now working on this issue.  Sorry for the delay...
>>>>
>>>> What do you think about moving
>>>>    void emit_java_to_interp(CodeBuffer& cbuf);
>>>> and
>>>>   void size_java_to_interp();
>>>> to compiledIC.hpp and the new platform file, too?
>>> I like that.
>>>
>>>> This would also allow to overcome the ugly
>>>>   extern uint size_java_to_interp();
>>>> in output.cpp, as it could be replaced by 
>>>> CompiledStaticCall::size_java_to_interp().
>>> Great.
>>>
>>>> I also would like to name this
>>>> CompiledStaticCall::emit_to_interp_stub()
>>>> CompiledStaticCall::to_interp_stub_size()
>>> I'm okay with that.  Not sure if others have objections.
>>>
>>>> I could also extract code from enc_class Java_Static_Call
>>>> to form a routine
>>>> CompiledStaticCall::emit_call(CodeBuffer *cbuf, intptr_t 
>>>> entry_point, relocInfo::relocType rtype) {
>>>>    emit_call_reloc(cbuf, entry_point, rtype)
>>>>    if (rtype != relocInfo::runtime_call_type) {
>>>>        emit_java_to_interp(cbuf);
>>>>      }
>>>> }
>>>> With this, also
>>>> extern uint reloc_java_to_interp();
>>>> from output.cpp could be moved into this class.
>>> On SPARC only or the other architectures as well?
>>>
>>>> Then handling of CompiledStaticCalls would be completely 
>>>> implemented in this
>>>> one class.
>>> That's tempting.
>>>
>>>> (I would have to move emit_call_reloc to MacroAssembler.)
>>> Could you send a webrev with these changes?
>>>
>>> -- Chris
>>>
>>>> Best regards,
>>>> Goetz.
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>> Sent: Montag, 25. M?rz 2013 23:29
>>>> To: Lindenmaier, Goetz
>>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in 
>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in 
>>>> java_to_interp stub.]
>>>>
>>>>
>>>> On Mar 4, 2013, at 8:34 AM, "Lindenmaier, Goetz" 
>>>>  wrote:
>>>>
>>>>> Hi Chris,
>>>>>
>>>>> I would like to take up this issue again.
>>>>> I'm about to put our changes on the jdk8 branch, and it would be 
>>>>> convenient
>>>>> to have a final solution for this.
>>>>>
>>>>> Should I prepare a webrev with a different solution adding a new file
>>>>> for this?  What should go into that file?
>>>> Sorry for answering that late.
>>>>
>>>> Yes, to see a patch for that would be good.  We need to put all 
>>>> platform dependent Compiled* methods in that new file. Platform 
>>>> dependent means every method that uses a native* method from 
>>>> nativeInst_:
>>>>
>>>> CompiledIC::cleanup_call_site
>>>> CompiledIC::is_icholder_call_site
>>>> CompiledIC::CompiledIC
>>>>
>>>> CompiledStaticCall::set_to_interpreted
>>>> CompiledStaticCall::set_stub_to_clean
>>>> CompiledStaticCall::verify
>>>>
>>>> -- Chris
>>>>
>>>>> Best regards,
>>>>> Goetz.
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: goetz.lindenmaier at sap.com
>>>>> Sent: Dienstag, 18. Dezember 2012 10:42
>>>>> To: 'Christian Thalinger'
>>>>> Subject: RE: RFR (S): 8003853: specify offset of IC load in 
>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load 
>>>>> in java_to_interp stub.]
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> What would you put into that file?  The offset, or the class 
>>>>> CompiledStaticCall?
>>>>> You could also put it into nativeInst_  to avoid adding 
>>>>> another file.
>>>>>
>>>>> But basically I think the offset is the best solution, because 
>>>>> it's very small
>>>>> and straight forward, and the offset is set where the code is 
>>>>> generated
>>>>> that defines the offset.
>>>>>
>>>>> Only the #ifndef COMPILER2 is ugly, but here I think the solution 
>>>>> is to
>>>>> guard the whole class CompiledStaticCall with #ifdef COMPILER2.
>>>>>
>>>>> But I'm happy with any placement of the code.
>>>>>
>>>>> Best regards,
>>>>> Goetz.
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>> Sent: Montag, 17. Dezember 2012 21:34
>>>>> To: Lindenmaier, Goetz
>>>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in 
>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load 
>>>>> in java_to_interp stub.]
>>>>>
>>>>>
>>>>> On Nov 29, 2012, at 2:10 PM, "Lindenmaier, Goetz" 
>>>>>  wrote:
>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> Loading the constant takes 5 instructions, the other way only three,
>>>>>> in the code only one, if the constant pool base is in a register.
>>>>>> The 5 instructions are hard to patch atomically.  The constant pool
>>>>>> is just a 64 bit store.
>>>>>>
>>>>>>> Sorry for being so persistent on this :-)
>>>>>> That's ok, I already found several places in our VM where it was 
>>>>>> easy to
>>>>>> change our code to get along without the shared changes we did in
>>>>>> first place.  But I can't redesign everything, and I can not risk 
>>>>>> to break
>>>>>> anything in our product.
>>>>>>
>>>>>> If you feel like doing so, you can have a look at
>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/600ce596eea9 
>>>>>>
>>>>>> which contains our bytecode interpreter profiling implementation.
>>>>>> If you think this is currently of use in the main branch, I would 
>>>>>> lift it to HS25
>>>>>> (the permgen changes might cause trouble) and contribute it to hsx.
>>>>> Sorry for the long delay.
>>>>>
>>>>> Thinking about this problem again it seems that the correct 
>>>>> solution would be to have a compiledIC_.cpp file.
>>>>>
>>>>> The CompiledIC instruction layout is platform dependent; it just 
>>>>> happens to be the same for all architectures we have right now 
>>>>> (well, except PPC) because we made it to be the same.  Actually on 
>>>>> SPARC we could also use a load from the constant table which would 
>>>>> be simpler.
>>>>>
>>>>> Having a platform dependent file for this code feels right.  What 
>>>>> do you think?
>>>>>
>>>>> -- Chris
>>>>>
>>>>>> Best regards,
>>>>>> Goetz.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>> Sent: Thursday, November 29, 2012 7:53 PM
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in 
>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load 
>>>>>> in java_to_interp stub.]
>>>>>>
>>>>>>
>>>>>> On Nov 29, 2012, at 12:27 AM, "Lindenmaier, Goetz" 
>>>>>>  wrote:
>>>>>>
>>>>>>> Hi Chris,
>>>>>>>
>>>>>>>> Why can't you point the relocation to the method load 
>>>>>>>> instruction?  It doesn't seem right to do that in shared code.
>>>>>>> Because the relocation is used
>>>>>>> 1.) to find the beginning of the stub to patch the call to go there
>>>>>>> 2.) to find the load to patch the IC.
>>>>>> Got it.
>>>>>>
>>>>>>> Just have a look at CompiledStaticCall::set_to_interpreted(),
>>>>>>> the variable 'stub' is used twice.
>>>>>> Sorry for being so persistent on this :-)  What is the reason you 
>>>>>> have to load the constant from the constant table?  On other 
>>>>>> architectures we materialize the constant.
>>>>>>
>>>>>> -- Chris
>>>>>>
>>>>>>> Best regards,
>>>>>>> Goetz.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>> Sent: Donnerstag, 29. November 2012 01:35
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in 
>>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load 
>>>>>>> in java_to_interp stub.]
>>>>>>>
>>>>>>>
>>>>>>> On Nov 27, 2012, at 4:24 AM, "Lindenmaier, Goetz" 
>>>>>>>  wrote:
>>>>>>>
>>>>>>>> Hi Chris,
>>>>>>>>
>>>>>>>>> Why do you need all these shared code changes when you have 
>>>>>>>>> this in emit_java_to_interp_stub?
>>>>>>>> Shared code (class CompiledStaticCall) wants to patch the 
>>>>>>>> inline cache
>>>>>>>> in the stub which is emitted in platform code.
>>>>>>>> So the platform code should specify how the shared code can 
>>>>>>>> find the inline cache
>>>>>>>> in the stub, which it does through the constant I introduced.
>>>>>>>>
>>>>>>>>> Do you need two relocations?  I'm confused.
>>>>>>>> No, three ;)
>>>>>>>> The relocation you mention is used to find the stub given the 
>>>>>>>> call.
>>>>>>>> The other relocations are needed to find the inline cache / 
>>>>>>>> call target
>>>>>>>> once the stub is found (see 
>>>>>>>> CompiledStaticCall::set_to_interpreted()).
>>>>>>>> It's just the same on x86_64:
>>>>>>>>
>>>>>>>> // static stub relocation stores the instruction address of the 
>>>>>>>> call
>>>>>>>> __ relocate(static_stub_Relocation::spec(mark), RELOC_IMM64);
>>>>>>>> // static stub relocation also tags the methodOop in the 
>>>>>>>> code-stream.
>>>>>>>> __ movoop(rbx, (jobject) NULL);  // method is zapped till fixup 
>>>>>>>> time
>>>>>>>> // This is recognized as unresolved by relocs/nativeinst/ic code
>>>>>>>> __ jump(RuntimeAddress(__ pc()));
>>>>>>>>
>>>>>>>> On PPC, we have to load the base of the constant table after 
>>>>>>>> generating the
>>>>>>>> static_stub_relocation and before emitting the ppc equivalent 
>>>>>>>> for moveoop(). This offset is
>>>>>>>> exactly what we store in the 
>>>>>>>> CompiledStaticCall::comp_to_int_load_offset constant.
>>>>>>> Why can't you point the relocation to the method load 
>>>>>>> instruction?  It doesn't seem right to do that in shared code.
>>>>>>>
>>>>>>> -- Chris
>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Goetz.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>>> Sent: Dienstag, 27. November 2012 01:53
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in 
>>>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC 
>>>>>>>> load in java_to_interp stub.]
>>>>>>>>
>>>>>>>>
>>>>>>>> On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz" 
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>> Hi Chris,
>>>>>>>>>
>>>>>>>>> We put it into the ad file because it describes an offset into 
>>>>>>>>> the stub that is
>>>>>>>>> generated from the ad file by emit_java_to_interp(CodeBuffer& 
>>>>>>>>> cbuf),
>>>>>>>>> used by ir  node CallStaticJavaDirect.  Maybe I should not 
>>>>>>>>> call it stub, but it's
>>>>>>>>> generated into the stubs section of the code buffer.
>>>>>>>>> If that stub generator is moved out of the ad file to shared 
>>>>>>>>> compiler code, one should
>>>>>>>>> move the field with it, but for the current implementation I 
>>>>>>>>> think that's fine.
>>>>>>>>>
>>>>>>>>> Does C1 generate the same stub? Or is the CompiledStaticCall a 
>>>>>>>>> C2 feature?
>>>>>>>>> If so, one could protect the whole thing by #ifdef COMPILER2.
>>>>>>>> Why do you need all these shared code changes when you have 
>>>>>>>> this in emit_java_to_interp_stub?
>>>>>>>>
>>>>>>>> // Create a static stub relocation which relates this stub
>>>>>>>> // with the call instruction at insts_call_instruction_offset 
>>>>>>>> in the
>>>>>>>> // instructions code-section.
>>>>>>>> __ relocate(static_stub_Relocation::spec(__ 
>>>>>>>> code()->insts()->start() + insts_relocation_offset));
>>>>>>>>
>>>>>>>> Do you need two relocations?  I'm confused.
>>>>>>>>
>>>>>>>> -- Chris
>>>>>>>>
>>>>>>>>> Thanks for all the bugids!
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Goetz.
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>>>> Sent: Mittwoch, 21. November 2012 19:53
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>> Subject: RFR (S): 8003853: specify offset of IC load in 
>>>>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC 
>>>>>>>>> load in java_to_interp stub.]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz" 
>>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>>> Hi Chris,
>>>>>>>>>>
>>>>>>>>>> yes, there is no C1 on ppc.
>>>>>>>>>> We do tiered compilation with a stripped C2.
>>>>>>>>> Right.  But some other architecture (or in the future) might 
>>>>>>>>> need this for C1 as well.  We should find a better place for 
>>>>>>>>> the value than the ad file.  The obvious place would be 
>>>>>>>>> compiledIC_.hpp but we don't have that file, yet.
>>>>>>>>>
>>>>>>>>> I filed:
>>>>>>>>>
>>>>>>>>> 8003853: specify offset of IC load in java_to_interp stub
>>>>>>>>>
>>>>>>>>> -- Chris
>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Goetz
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Christian Thalinger 
>>>>>>>>>> [mailto:christian.thalinger at oracle.com]
>>>>>>>>>> Sent: Dienstag, 20. November 2012 22:19
>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>>> Subject: Re: RFR (S): Specify offset of IC load in 
>>>>>>>>>> java_to_interp stub.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz" 
>>>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> The class CompiledStaticCall must know the location of the 
>>>>>>>>>>> IC load in the java_to_interp stub
>>>>>>>>>>> to update the IC  with NativeMovConstReg.  The current 
>>>>>>>>>>> implementation assumes that
>>>>>>>>>>> the load is always the first instruction in the stub.  This 
>>>>>>>>>>> is an artificial restriction. E.g.,
>>>>>>>>>>> it might be useful to load the constant pool address 
>>>>>>>>>>> (MachConstantBase) before the
>>>>>>>>>>> IC load (as we do on PPC).
>>>>>>>>>>>
>>>>>>>>>>> This change adds a constant specifying an offset from the 
>>>>>>>>>>> beginning of the stub to
>>>>>>>>>>> the  IC load. The offset is platform specific and 0 on sparc 
>>>>>>>>>>> and x86.
>>>>>>>>>>>
>>>>>>>>>>> You can find the change here:
>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/
>>>>>>>>>> That should be fixed indeed.
>>>>>>>>>>
>>>>>>>>>> +#ifndef COMPILER2
>>>>>>>>>> +const int CompiledStaticCall::comp_to_int_load_offset = 0;
>>>>>>>>>>
>>>>>>>>>> There is no C1 for PPC (sorry, I didn't check)?
>>>>>>>>>>
>>>>>>>>>> -- Chris
>>>>>>>>>>
>>>>>>>>>>> or in our ppc port:
>>>>>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33 
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thank you and best regards,
>>>>>>>>>>> Goetz
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>


From yumin.qi at oracle.com  Mon Apr 15 22:44:38 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Mon, 15 Apr 2013 22:44:38 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516B9922.4050306@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
Message-ID: <516CE546.7060309@oracle.com>

For HandleMark,


On 4/14/2013 11:07 PM, David Holmes wrote:
> Hi Yumin,
>
> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>> After take feedback and modify, new webrev
>>
>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>> 
>
> I still find the HandleMark changes unsatisfactory. The CHeap 
> allocated HandleMark in the Thread() constructor is a bit of a hack. 
> HandleMarks should be stack-allocated. Plus we seem to leak that CHeap 
> allocated HandleMark as we don't keep any pointer to it! I think this 
> needs to be re-visited, but as a separate CR.
>

The default constructor for HandleMark:
inline HandleMark::HandleMark() {
   initialize(Thread::current());
}

In thread.cpp, Thread::Thread(), the last HandleMark is created in heap,
-  new HandleMark(this);
-
+  HandleMark *hm = NEW_C_HEAP_OBJ(HandleMark, mtThread);
+  hm->initialize(this);
The original code, is calling the constructor with 'this'.  Unless we 
code a macro to pass 'this' as argument, which looks specific not 
generic, to call the constructor.  When call default constructor here, 
will assert current thread is NULL --- the real native thread has not 
created yet , the thread id is not cached so we get back a NULL for 
Thread::current(). That is, we could not call the default constructor at 
this time, this change seems strange but works --- first created the 
object without calling constructor in heap, then initialize with 'this'.

The problem is ~HandleMark is not called this way. Need to have a 
version to call dtor which seems ugly.

The handle mark here for what? I could  not spot any handle allocated 
from this point in Thread creation.

Thanks
Yumin


> ---
>
> allocation.hpp:
>
> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element 
> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's 
> before deallocating ?
>
> ---
>
> src/share/vm/utilities/quickSort.cpp
>
> Why does only Solaris need the allocation headers included ?? I would 
> expect all platforms to need to the same headers here.
>
> Thanks,
> David
>
>>
>>
>> Thanks
>> Yumin
>>
>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>> .
>>>>> cardTableModRefBS.cpp
>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>
>>>> This is default constructor does, here just copy that code. Since we
>>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which
>>>> will call ctors.
>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>> allocation.hpp #618 does.
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>>>> carTableRS.cpp
>>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>>
>>>>>
>>>> See reply to David H.
>>>>
>>>>
>>>> Thanks
>>>> Yumin
>>>>> -Zhengyu
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>> Hi,
>>>>>>
>>>>>>   Can I have your inputs for the fix?
>>>>>>   webrev:
>>>>>>
>>>>>>  http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>> 
>>>>>>
>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>
>>>>>> Problem description:  Remove the usage of global operator ::new[]
>>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>> disabling use of global operator new[] and new, we constrain the
>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>> ResourceObj unless they are stack objects or values which have to
>>>>>> be from StackObj or _ValueObj respectively.  Or they have to
>>>>>> implement their own operator new[] or new.
>>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>


From david.holmes at oracle.com  Mon Apr 15 23:02:38 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 16 Apr 2013 16:02:38 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516CE546.7060309@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516CE546.7060309@oracle.com>
Message-ID: <516CE97E.7090500@oracle.com>

On 16/04/2013 3:44 PM, Yumin Qi wrote:
> For HandleMark,
>
>
> On 4/14/2013 11:07 PM, David Holmes wrote:
>> Hi Yumin,
>>
>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>> After take feedback and modify, new webrev
>>>
>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>> 
>>
>> I still find the HandleMark changes unsatisfactory. The CHeap
>> allocated HandleMark in the Thread() constructor is a bit of a hack.
>> HandleMarks should be stack-allocated. Plus we seem to leak that CHeap
>> allocated HandleMark as we don't keep any pointer to it! I think this
>> needs to be re-visited, but as a separate CR.
>>
>
> The default constructor for HandleMark:
> inline HandleMark::HandleMark() {
>    initialize(Thread::current());
> }
>
> In thread.cpp, Thread::Thread(), the last HandleMark is created in heap,
> -  new HandleMark(this);
> -
> +  HandleMark *hm = NEW_C_HEAP_OBJ(HandleMark, mtThread);
> +  hm->initialize(this);
> The original code, is calling the constructor with 'this'.  Unless we
> code a macro to pass 'this' as argument, which looks specific not
> generic, to call the constructor.  When call default constructor here,
> will assert current thread is NULL --- the real native thread has not
> created yet , the thread id is not cached so we get back a NULL for
> Thread::current(). That is, we could not call the default constructor at
> this time, this change seems strange but works --- first created the
> object without calling constructor in heap, then initialize with 'this'.

I understand why you had to make the change to make the code work, but 
it is still a horrible change to have to make. :)

> The problem is ~HandleMark is not called this way. Need to have a
> version to call dtor which seems ugly.
>
> The handle mark here for what? I could  not spot any handle allocated
> from this point in Thread creation.

As I commented in the new CR I also can not see why we need this initial 
HandleMark. It's presence greatly complicates things.

David

> Thanks
> Yumin
>
>
>> ---
>>
>> allocation.hpp:
>>
>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element
>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>> before deallocating ?
>>
>> ---
>>
>> src/share/vm/utilities/quickSort.cpp
>>
>> Why does only Solaris need the allocation headers included ?? I would
>> expect all platforms to need to the same headers here.
>>
>> Thanks,
>> David
>>
>>>
>>>
>>> Thanks
>>> Yumin
>>>
>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>> .
>>>>>> cardTableModRefBS.cpp
>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>
>>>>> This is default constructor does, here just copy that code. Since we
>>>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, which
>>>>> will call ctors.
>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>> allocation.hpp #618 does.
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>>
>>>>>> carTableRS.cpp
>>>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>>>
>>>>>>
>>>>> See reply to David H.
>>>>>
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>> -Zhengyu
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>   Can I have your inputs for the fix?
>>>>>>>   webrev:
>>>>>>>
>>>>>>>  http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>> 
>>>>>>>
>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and new
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>
>>>>>>> Problem description:  Remove the usage of global operator ::new[]
>>>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>>> disabling use of global operator new[] and new, we constrain the
>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>> ResourceObj unless they are stack objects or values which have to
>>>>>>> be from StackObj or _ValueObj respectively.  Or they have to
>>>>>>> implement their own operator new[] or new.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>

From nils.eliasson at oracle.com  Tue Apr 16 03:16:30 2013
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Tue, 16 Apr 2013 12:16:30 +0200
Subject: RFR (M): 8006952: Slow VM due to excessive code cache freelist
	iteration
In-Reply-To: <516BD82A.7050302@oracle.com>
References: <5107AADF.6010501@oracle.com> <51082499.3000905@oracle.com>
	<51093FAC.6090803@oracle.com> <51097FA6.3050709@oracle.com>
	<510ABAB9.8020909@oracle.com>
	<15E6C57378C5FE43AD074594DD824E501C8AB7E7@DEWDFEMB15A.global.corp.sap>
	<511511A5.8050101@oracle.com> <5167DFC2.6020007@oracle.com>
	<51684283.7010304@oracle.com> <516BD82A.7050302@oracle.com>
Message-ID: <516D24FE.1090105@oracle.com>

Latest webrev: http://cr.openjdk.java.net/~neliasso/8006952/webrev.09/ 


Updates after comments from Vladimir K. and Niclas.

- Removed 'red_zone' naming and refined comments
- Refined naming in heap.cpp/hpp on conversion methods 
size(...)/number_of_segments(...) to 
size_to_segments(...)/segments_to_size(...)
- Bool flags as verbs (critical -> is_critical)
- Removed get_largest_block() and all its uses.

Enjoy!

//Nils

On 2013-04-15 12:36, Nils Eliasson wrote:
>
> Hi,
>
> On 2013-04-12 19:21, Vladimir Kozlov wrote:
>> Nils,
>>
>> It is sad that you have to reverse parfait fix but I agree that your 
>> changes are more clean.
>
> Please - don't be! I taken extra precaution and have verified that 
> there is a null check between the call to new and the constructor. 
> This is consistent with both the C++ spec and the behaviour we rely on 
> when running out of code cache. The CodeCache::has_space would have 
> forced me to do it more complex, it would have to copy/wrap the 
> heap::allocate algorithm but returning a bool instead of actually 
> allocating.
>
> Sorry for forgetting to add it to the change log in my request. I did 
> not intend to revert it without being open about it.
>
> I don't understand why Parfait is confused about 'this' being null in 
> the constructor. I will open a bug on Parfait if I can find where to 
> submit it.
>
>>
>> After these changes largest_free_block() is used only in statistics 
>> output which is useless since it is not participating in codecache 
>> allocations.  May be we should remove it and use 
>> heap_unallocated_capacity() instead (do we need lock then?):
>
> Yes, good idea. Must check that I don't break any log tool if I change 
> the output though.
>
>>
>> size_t CodeCache::largest_free_block() {
>>   return _heap->heap_unallocated_capacity();
>> }
>>
>> Also red_zone_start() is confusing because it does not show how it is 
>> related to heap_unallocated_capacity(). In one place you use one:
>>
>>  211     if (size(length) > (heap_unallocated_capacity() - 
>> CodeCacheMinimumFreeSpace)) {
>>
>> and in an other use second:
>>
>>  437     if (((size_t)cur + length) >= (size_t)red_zone_start()) {
>>
>> Can we just use only heap_unallocated_capacity()?
>
> I agree that it is confusing. The background is that they serve a bit 
> different purpose. In one case we are allocating from the freelist and 
> need to check against the adress where the 'red zone/critical 
> allocation area begins.' In the other it is a block allocation from 
> the contiguous heap where we know heap_unallocated_capacity is the 
> size of the block at the end of the heap. I'll come up with something 
> better.
>
> Thanks for taking your time!
> //Nils
>
>>
>> Thanks,
>> Vladimir
>>
>> On 4/12/13 3:19 AM, Nils Eliasson wrote:
>>> I have now incorporated both Vladimirs and Andreas suggestion:
>>>
>>> Changes to previous revision includes:
>>> 1) Updated the checks in both heap::allocate and heap::search_freelist
>>> so that non critical allocation never stride into the
>>> CodeCacheMinimumFreeSpace.
>>> 2) Inverted the critical condition - now all allocations default to not
>>> critical. Only the places where we would go fatal if the allocation
>>> returns null are critical.
>>> 3) Refactored some names and removed duplicate methods in heap.cpp.
>>>
>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.08/
>>> 
>>>
>>> This changes also opens up for decreasing the CodeCacheMinimumFreeSpace
>>> since we now guarantee that only critical allocation will end up there.
>>> And they will not grow to 500K when compilation have stopped anyways.
>>>
>>> Kind regards,
>>> //Nils
>>>
>>>
>>> On 2013-02-08 15:54, Nils Eliasson wrote:
>>>> Vladimir and Andreas, thanks for your feedback! I am considering your
>>>> suggestions.
>>>>
>>>> My fix is a step in the right direction but I realize it is not 
>>>> enough.
>>>>
>>>> Initially, it works good reserving the last part of the heap block.
>>>> But if the application has a bigger active code footprint that what
>>>> can fit in the code cache, there will be new flushes that will
>>>> increase fragmentation and slowly reduce the usable part of the code
>>>> cache. So I will add functionality for backing off.
>>>>
>>>> //Nils
>>>>
>>>> Schoesser, Andreas skrev 2013-02-01 10:58:
>>>>> Hi Nils,
>>>>>
>>>>> this is IMO a good idea since we experienced the same problem with
>>>>> one of our ports. I think in our case it was not the nmethod sweeper
>>>>> continuously running (there's MinCodeCacheFlushingInterval to only
>>>>> speculatively disconnect nmethods every 30 seconds) but from the
>>>>> compiler loop constantly polling the freelist without the nmethod
>>>>> sweeper making any progress.
>>>>>
>>>>> You also might consider to propagate the "critical" flag down to
>>>>> search_freelist(). Then, a simple address compare would do to keep
>>>>> the end of the code cache free from nmethods:
>>>>> - For non-critical blobs, search_freelist() may only fit free blocks
>>>>> < CodeCache::end() - CodeCacheMinimumFreeSpace
>>>>> - For critical blocks, search_freelist() may fit all free blocks
>>>>>
>>>>> Best regards,
>>>>> Andreas
>>>>>
>>>>> -----Original Message-----
>>>>> From: hotspot-compiler-dev-bounces at openjdk.java.net
>>>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of
>>>>> Nils Eliasson
>>>>> Sent: Donnerstag, 31. Januar 2013 19:41
>>>>> To: hotspot-compiler-dev at openjdk.java.net
>>>>> Subject: Re: RFR (M): 8006952: Slow VM due to excessive code cache
>>>>> freelist iteration
>>>>>
>>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.04/
>>>>>
>>>>> //N
>>>>>
>>>>> Vladimir Kozlov skrev 2013-01-30 21:16:
>>>>>> Nils, you sent webrev for other bug fix.
>>>>>>
>>>>>> Vladimir
>>>>>>
>>>>>> On 1/30/13 7:43 AM, Nils Eliasson wrote:
>>>>>>> Thanks for the link, interesting background.
>>>>>>>
>>>>>>> Even if finding the largest block on the freelist is free, we would
>>>>>>> still have a misbehavior when the free heap block is less than 1,5M
>>>>>>> and
>>>>>>> the flushing begins to create a 1,5M freelist block.
>>>>>>>
>>>>>>> Unallocated memory is a good measurement if have some continuous
>>>>>>> memory
>>>>>>> in reserve for critical blobs. I am thinking of using the 
>>>>>>> thresholds
>>>>>>> against unallocated memory, but forbidding nmethods from using the
>>>>>>> last
>>>>>>> 0,5M (MinimumFreeSpace) from the heap block. That would prevent 
>>>>>>> the VM
>>>>>>> from fragmenting the last continuous memory space, and allow the 
>>>>>>> VM to
>>>>>>> use all of the freelist.
>>>>>>>
>>>>>>> Like this:
>>>>>>> http://cr.openjdk.java.net/~neliasso/8002364/webrev.03
>>>>>>>
>>>>>>> //Nils
>>>>>>>
>>>>>>> Vladimir Kozlov skrev 2013-01-29 20:35:
>>>>>>>> Nils,
>>>>>>>>
>>>>>>>> You are reversing 7025742 fix. I would prefer to keep track of a
>>>>>>>> largest free block during allocation in CodeCache (by using 
>>>>>>>> ordered
>>>>>>>> list or other technique) to avoid scanning the list.
>>>>>>>>
>>>>>>>> Vladimir
>>>>>>>>
>>>>>>>> On 1/29/13 2:56 AM, Nils Eliasson wrote:
>>>>>>>>> Remove continuous free block requirement for code cache 
>>>>>>>>> flushing and
>>>>>>>>> minimum free space.
>>>>>>>>>
>>>>>>>>> This causes a degenerate behavior when the VM are repeatedly
>>>>>>>>> flushing
>>>>>>>>> the code cache trying to free up a continuous 1,5M block. 
>>>>>>>>> Since the
>>>>>>>>> freelist is fragmented a significant part of the code cache is 
>>>>>>>>> kept
>>>>>>>>> unallocated. A significant amount of time is spent traversing the
>>>>>>>>> freelist holding the code cache lock or waiting for other threads
>>>>>>>>> doing
>>>>>>>>> the same.
>>>>>>>>>
>>>>>>>>> I don't see any reason for why a continuous block is required. 
>>>>>>>>> Code
>>>>>>>>> cache flushing threshold (CodeCacheFlushingMinimumFreeSpace) is
>>>>>>>>> default
>>>>>>>>> 1,5M and code cache minimum threshold 
>>>>>>>>> (CodeCacheMinimumFreeSpace) is
>>>>>>>>> 0,5M. Finding such a block on the freelist is often unrealistic,
>>>>>>>>> and has
>>>>>>>>> not any purpose. The largest nmethods are in the order of 
>>>>>>>>> 250k, and
>>>>>>>>> they
>>>>>>>>> are not allocated when code cache is starting to run out. All
>>>>>>>>> critical
>>>>>>>>> adapters are small and will fit easily in the freelist or in the
>>>>>>>>> remaining heap space.
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.02/
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Nils Eliasson
>>>>
>>>
>


From david.holmes at oracle.com  Tue Apr 16 05:56:38 2013
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 16 Apr 2013 22:56:38 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516D4675.8060308@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
Message-ID: <516D4A86.90405@oracle.com>

On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
> On 4/15/2013 7:20 PM, David Holmes wrote:
>> Adding back compiler and gc teams
>>
>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>> Zhenyu,
>>>
>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>> Maybe you need a replacement delete operator, please check
>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>
>>> i can just do
>>>
>>> delete ((type *)&array_name[index]);
>>>
>>> so the destructor will be called, is this right?
>>
>> No, it will also deallocate the memory unless you use a variant of
>> delete (which is what I think Zhengyu was referring to) that doesn't
>> actually deallocate the memory.
>>
> Yes, I meant placement delete operator, which takes two pointers.

But you can only call that explicitly as a function. The delete 
expression will never use it, so I don't see how it applies. We need to 
call the destructor without de-allocating and the only way I can see to 
do that is to call the destructor explicitly.

David
-----


> -Zhengyu
>
>
>> I think this is getting out of hand - if we go this path then we
>> should simply have a custom operator new[] and operator delete[] and
>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>> destructs and then de-allocates.
>>
>> I have no issue with calling destructors explicitly.
>>
>> David
>> -----
>>
>>> Thanks
>>> Yumin
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>> memflags)                  \
>>>>>   624 { \
>>>>>   625     if (array_name != NULL)
>>>>> {                                                       \
>>>>>   626       for (int index = 0; index < size; index ++)
>>>>> {                                 \
>>>>>   627         /* placement to call dtor on type
>>>>> */                                        \
>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>   629 } \
>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>> memflags);                                \
>>>>>   631 } \
>>>>>   632   }
>>>>>
>>>>>
>>>>> I really don't like this, calling dtor  ...
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Zhengyu
>>>>>
>>>>>
>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>> new webrev at:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>
>>>>>> Can I have a review from GC team for this change?
>>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>
>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>> Hi Yumin,
>>>>>>>
>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>> 
>>>>>>>
>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to leak
>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer to it!
>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> allocation.hpp:
>>>>>>>
>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element
>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>>>>>>> before deallocating ?
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>
>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Yumin
>>>>>>>>
>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>> .
>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>
>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>> Since we
>>>>>>>>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>> which
>>>>>>>>>> will call ctors.
>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> -Zhengyu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> See reply to David H.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>> 
>>>>>>>>>>>>
>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and
>>>>>>>>>>>> new
>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>
>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>> ::new[]
>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>>>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>>>>>>>> disabling use of global operator new[] and new, we constrain
>>>>>>>>>>>> the
>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>> have to
>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they have to
>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Yumin
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>

From zhengyu.gu at oracle.com  Tue Apr 16 05:39:17 2013
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Tue, 16 Apr 2013 08:39:17 -0400
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516C8B3A.9060606@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com>
Message-ID: <516D4675.8060308@oracle.com>


On 4/15/2013 7:20 PM, David Holmes wrote:
> Adding back compiler and gc teams
>
> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>> Zhenyu,
>>
>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>> Maybe you need a replacement delete operator, please check
>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>
>> i can just do
>>
>> delete ((type *)&array_name[index]);
>>
>> so the destructor will be called, is this right?
>
> No, it will also deallocate the memory unless you use a variant of 
> delete (which is what I think Zhengyu was referring to) that doesn't 
> actually deallocate the memory.
>
Yes, I meant placement delete operator, which takes two pointers.

-Zhengyu


> I think this is getting out of hand - if we go this path then we 
> should simply have a custom operator new[] and operator delete[] and 
> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple 
> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that 
> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that 
> destructs and then de-allocates.
>
> I have no issue with calling destructors explicitly.
>
> David
> -----
>
>> Thanks
>> Yumin
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size, 
>>>> memflags)                  \
>>>>   624 { \
>>>>   625     if (array_name != NULL) 
>>>> {                                                       \
>>>>   626       for (int index = 0; index < size; index ++) 
>>>> {                                 \
>>>>   627         /* placement to call dtor on type 
>>>> */                                        \
>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>   629 } \
>>>>   630       FREE_C_HEAP_ARRAY(type, array_name, 
>>>> memflags);                                \
>>>>   631 } \
>>>>   632   }
>>>>
>>>>
>>>> I really don't like this, calling dtor  ...
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>>
>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>> new webrev at:
>>>>>
>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>
>>>>> Can I have a review from GC team for this change?
>>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>
>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>> Hi Yumin,
>>>>>>
>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>> After take feedback and modify, new webrev
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>> 
>>>>>>
>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to leak
>>>>>> that CHeap allocated HandleMark as we don't keep any pointer to it!
>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> allocation.hpp:
>>>>>>
>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array element
>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>>>>>> before deallocating ?
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>
>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>> would expect all platforms to need to the same headers here.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>
>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>> .
>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>
>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>> Since we
>>>>>>>>> did not call constructor by using this MACRO. It is a _ValueObj,
>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3, 
>>>>>>>>> which
>>>>>>>>> will call ctors.
>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>>>>>> allocation.hpp #618 does.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>>
>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>   #70, why it is commented out? If so, you don't need the dstor
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> See reply to David H.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Yumin
>>>>>>>>>> -Zhengyu
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>   webrev:
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>> 
>>>>>>>>>>>
>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and 
>>>>>>>>>>> new
>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>
>>>>>>>>>>> Problem description:  Remove the usage of global operator 
>>>>>>>>>>> ::new[]
>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of global
>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>>>>>>> disabling use of global operator new[] and new, we constrain 
>>>>>>>>>>> the
>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>>> ResourceObj unless they are stack objects or values which 
>>>>>>>>>>> have to
>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they have to
>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Yumin
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>


From jesper.wilhelmsson at oracle.com  Tue Apr 16 07:16:55 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Tue, 16 Apr 2013 16:16:55 +0200
Subject: RFR (S): 8010090 - GC ID has the wrong type
Message-ID: <516D5D57.2060804@oracle.com>

Hi,

Could I have a couple of reviews for this really small change.

The type of the GC ID and the Compile ID in the different tracing events should 
be UINT as the values put into these fields are uint.

Webrev: http://cr.openjdk.java.net/~jwilhelm/8010090/webrev/

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010090

Thanks,
/Jesper

From goetz.lindenmaier at sap.com  Tue Apr 16 07:22:34 2013
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 16 Apr 2013 14:22:34 +0000
Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp
	stub [Was: Re: RFR (S): Specify offset of IC load in
	java_to_interp	stub.]
In-Reply-To: <516CDF6A.4080900@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC0CFA7D32@DEWDFEMB12A.global.corp.sap>
	<03C4DFDE-CD52-446E-92AA-A6F12903FE29@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB116E@DEWDFEMB12A.global.corp.sap>
	<7D07437F-CFF7-4298-B9A1-DE9F2E32D77D@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB1EDE@DEWDFEMB12A.global.corp.sap>
	<8A8B46F8-0C91-4E8C-950A-0E65095DB2E0@oracle.com>
	<516CD9A3.3030202@oracle.com> <516CDF6A.4080900@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC0CFB36A3@DEWDFEMB12A.global.corp.sap>

Hi Dean, 

I left the runtime call in the ad file, as it's got nothing to do with 
CompiledStaticCalls that call Java.

I thought this is a better separation of concerns.
Anyways, you would have to pass in _method and
_optimized_virtual, which are fields of the machnode.

Best regards,
  Goetz.





-----Original Message-----
From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Dean Long
Sent: Dienstag, 16. April 2013 07:20
To: hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]

Also, is moving the call into CompiledStaticCall::emit_call() really 
needed for PPC?  I'd prefer to move the
stub emitter instead (sample sparc code):

     if ( !_method ) {
       emit_call_reloc(cbuf, $meth$$method, relocInfo::runtime_call_type);
     } else if (_optimized_virtual) {
       emit_call_reloc(cbuf, $meth$$method, 
relocInfo::opt_virtual_call_type);
     } else {
       emit_call_reloc(cbuf, $meth$$method, relocInfo::static_call_type);
     }
     if( _method ) {  // Emit stub for static call
       CompiledStaticCall::emit_java_to_interp(cbuf);<---
     }

dl

On 4/15/2013 9:54 PM, Dean Long wrote:
> sparc.ad:
>
> 2538       CompiledStaticCall::emit_call(cbuf,
> 2539                                     (int) ($meth$$method - 
> ((intptr_t) cbuf.insts_end()) - 4),
> 2540                                     rtype);
>
> I think this should be:
>
> CompiledStaticCall::emit_call(cbuf,$meth$$method,  rtype);
>
> Computing the PC-relative offset probably only applies to x86.
>
> dl
>
> On 4/12/2013 2:03 PM, Christian Thalinger wrote:
>> On Apr 11, 2013, at 2:46 PM, "Lindenmaier, Goetz" 
>>  wrote:
>>
>>> Hi all,
>>>
>>> I prepared the webrev for the changes discussed below:
>>> http://cr.openjdk.java.net/~goetz/webrevs/8003853/
>>>
>>> To fix the issues we have with the PPC port with finding ICs, this 
>>> change
>>> cleans up the code handling compiled static Java calls:
>>> - Methods using native instructions are moved from compiledIC.cpp
>>>    to compiledIC_.cpp.
>>> - Methods emitting the call patched by CompiledStaticCall are
>>>    moved from the ad file to this class.
>>>    As a side effect this reduces redundancies in x86_64.ad and 
>>> x86_32.ad.
>>> - We get rid of extern declarations in output.cpp.
>> I like this.  Two comments:
>>
>> 1) Does it make sense to have emit_to_interp_stub when it's only used 
>> in one place?
>>
>> 2) Before we can push this someone has to do the same thing for ARM 
>> and PPC.  Any volunteers from the embedded team?
>>
>> -- Chris
>>
>>> Now all code concerning CompiledStaticCalls is collected in one class.
>>> The PPC port needs not change shared code any more to implement them.
>>> I also got around to move code to MacroAssembler, as only a simple call
>>> was needed on x86 and sparc.
>>>
>>> Probably this is (M) now, no more (S).
>>>
>>> Please review and send comments.  I'll be happy to adapt to them!
>>>
>>> Best regards,
>>>   Goetz Lindenmaier
>>>
>>> -----Original Message-----
>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>> Sent: Thursday, April 11, 2013 4:50 AM
>>> To: Lindenmaier, Goetz
>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in 
>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in 
>>> java_to_interp stub.]
>>>
>>>
>>> On Apr 9, 2013, at 7:35 AM, "Lindenmaier, Goetz" 
>>>  wrote:
>>>
>>>> Hi Chris,
>>>>
>>>> I'm now working on this issue.  Sorry for the delay...
>>>>
>>>> What do you think about moving
>>>>    void emit_java_to_interp(CodeBuffer& cbuf);
>>>> and
>>>>   void size_java_to_interp();
>>>> to compiledIC.hpp and the new platform file, too?
>>> I like that.
>>>
>>>> This would also allow to overcome the ugly
>>>>   extern uint size_java_to_interp();
>>>> in output.cpp, as it could be replaced by 
>>>> CompiledStaticCall::size_java_to_interp().
>>> Great.
>>>
>>>> I also would like to name this
>>>> CompiledStaticCall::emit_to_interp_stub()
>>>> CompiledStaticCall::to_interp_stub_size()
>>> I'm okay with that.  Not sure if others have objections.
>>>
>>>> I could also extract code from enc_class Java_Static_Call
>>>> to form a routine
>>>> CompiledStaticCall::emit_call(CodeBuffer *cbuf, intptr_t 
>>>> entry_point, relocInfo::relocType rtype) {
>>>>    emit_call_reloc(cbuf, entry_point, rtype)
>>>>    if (rtype != relocInfo::runtime_call_type) {
>>>>        emit_java_to_interp(cbuf);
>>>>      }
>>>> }
>>>> With this, also
>>>> extern uint reloc_java_to_interp();
>>>> from output.cpp could be moved into this class.
>>> On SPARC only or the other architectures as well?
>>>
>>>> Then handling of CompiledStaticCalls would be completely 
>>>> implemented in this
>>>> one class.
>>> That's tempting.
>>>
>>>> (I would have to move emit_call_reloc to MacroAssembler.)
>>> Could you send a webrev with these changes?
>>>
>>> -- Chris
>>>
>>>> Best regards,
>>>> Goetz.
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>> Sent: Montag, 25. M?rz 2013 23:29
>>>> To: Lindenmaier, Goetz
>>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in 
>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in 
>>>> java_to_interp stub.]
>>>>
>>>>
>>>> On Mar 4, 2013, at 8:34 AM, "Lindenmaier, Goetz" 
>>>>  wrote:
>>>>
>>>>> Hi Chris,
>>>>>
>>>>> I would like to take up this issue again.
>>>>> I'm about to put our changes on the jdk8 branch, and it would be 
>>>>> convenient
>>>>> to have a final solution for this.
>>>>>
>>>>> Should I prepare a webrev with a different solution adding a new file
>>>>> for this?  What should go into that file?
>>>> Sorry for answering that late.
>>>>
>>>> Yes, to see a patch for that would be good.  We need to put all 
>>>> platform dependent Compiled* methods in that new file. Platform 
>>>> dependent means every method that uses a native* method from 
>>>> nativeInst_:
>>>>
>>>> CompiledIC::cleanup_call_site
>>>> CompiledIC::is_icholder_call_site
>>>> CompiledIC::CompiledIC
>>>>
>>>> CompiledStaticCall::set_to_interpreted
>>>> CompiledStaticCall::set_stub_to_clean
>>>> CompiledStaticCall::verify
>>>>
>>>> -- Chris
>>>>
>>>>> Best regards,
>>>>> Goetz.
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: goetz.lindenmaier at sap.com
>>>>> Sent: Dienstag, 18. Dezember 2012 10:42
>>>>> To: 'Christian Thalinger'
>>>>> Subject: RE: RFR (S): 8003853: specify offset of IC load in 
>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load 
>>>>> in java_to_interp stub.]
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> What would you put into that file?  The offset, or the class 
>>>>> CompiledStaticCall?
>>>>> You could also put it into nativeInst_  to avoid adding 
>>>>> another file.
>>>>>
>>>>> But basically I think the offset is the best solution, because 
>>>>> it's very small
>>>>> and straight forward, and the offset is set where the code is 
>>>>> generated
>>>>> that defines the offset.
>>>>>
>>>>> Only the #ifndef COMPILER2 is ugly, but here I think the solution 
>>>>> is to
>>>>> guard the whole class CompiledStaticCall with #ifdef COMPILER2.
>>>>>
>>>>> But I'm happy with any placement of the code.
>>>>>
>>>>> Best regards,
>>>>> Goetz.
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>> Sent: Montag, 17. Dezember 2012 21:34
>>>>> To: Lindenmaier, Goetz
>>>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in 
>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load 
>>>>> in java_to_interp stub.]
>>>>>
>>>>>
>>>>> On Nov 29, 2012, at 2:10 PM, "Lindenmaier, Goetz" 
>>>>>  wrote:
>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> Loading the constant takes 5 instructions, the other way only three,
>>>>>> in the code only one, if the constant pool base is in a register.
>>>>>> The 5 instructions are hard to patch atomically.  The constant pool
>>>>>> is just a 64 bit store.
>>>>>>
>>>>>>> Sorry for being so persistent on this :-)
>>>>>> That's ok, I already found several places in our VM where it was 
>>>>>> easy to
>>>>>> change our code to get along without the shared changes we did in
>>>>>> first place.  But I can't redesign everything, and I can not risk 
>>>>>> to break
>>>>>> anything in our product.
>>>>>>
>>>>>> If you feel like doing so, you can have a look at
>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/600ce596eea9 
>>>>>>
>>>>>> which contains our bytecode interpreter profiling implementation.
>>>>>> If you think this is currently of use in the main branch, I would 
>>>>>> lift it to HS25
>>>>>> (the permgen changes might cause trouble) and contribute it to hsx.
>>>>> Sorry for the long delay.
>>>>>
>>>>> Thinking about this problem again it seems that the correct 
>>>>> solution would be to have a compiledIC_.cpp file.
>>>>>
>>>>> The CompiledIC instruction layout is platform dependent; it just 
>>>>> happens to be the same for all architectures we have right now 
>>>>> (well, except PPC) because we made it to be the same.  Actually on 
>>>>> SPARC we could also use a load from the constant table which would 
>>>>> be simpler.
>>>>>
>>>>> Having a platform dependent file for this code feels right.  What 
>>>>> do you think?
>>>>>
>>>>> -- Chris
>>>>>
>>>>>> Best regards,
>>>>>> Goetz.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>> Sent: Thursday, November 29, 2012 7:53 PM
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in 
>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load 
>>>>>> in java_to_interp stub.]
>>>>>>
>>>>>>
>>>>>> On Nov 29, 2012, at 12:27 AM, "Lindenmaier, Goetz" 
>>>>>>  wrote:
>>>>>>
>>>>>>> Hi Chris,
>>>>>>>
>>>>>>>> Why can't you point the relocation to the method load 
>>>>>>>> instruction?  It doesn't seem right to do that in shared code.
>>>>>>> Because the relocation is used
>>>>>>> 1.) to find the beginning of the stub to patch the call to go there
>>>>>>> 2.) to find the load to patch the IC.
>>>>>> Got it.
>>>>>>
>>>>>>> Just have a look at CompiledStaticCall::set_to_interpreted(),
>>>>>>> the variable 'stub' is used twice.
>>>>>> Sorry for being so persistent on this :-)  What is the reason you 
>>>>>> have to load the constant from the constant table?  On other 
>>>>>> architectures we materialize the constant.
>>>>>>
>>>>>> -- Chris
>>>>>>
>>>>>>> Best regards,
>>>>>>> Goetz.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>> Sent: Donnerstag, 29. November 2012 01:35
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in 
>>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load 
>>>>>>> in java_to_interp stub.]
>>>>>>>
>>>>>>>
>>>>>>> On Nov 27, 2012, at 4:24 AM, "Lindenmaier, Goetz" 
>>>>>>>  wrote:
>>>>>>>
>>>>>>>> Hi Chris,
>>>>>>>>
>>>>>>>>> Why do you need all these shared code changes when you have 
>>>>>>>>> this in emit_java_to_interp_stub?
>>>>>>>> Shared code (class CompiledStaticCall) wants to patch the 
>>>>>>>> inline cache
>>>>>>>> in the stub which is emitted in platform code.
>>>>>>>> So the platform code should specify how the shared code can 
>>>>>>>> find the inline cache
>>>>>>>> in the stub, which it does through the constant I introduced.
>>>>>>>>
>>>>>>>>> Do you need two relocations?  I'm confused.
>>>>>>>> No, three ;)
>>>>>>>> The relocation you mention is used to find the stub given the 
>>>>>>>> call.
>>>>>>>> The other relocations are needed to find the inline cache / 
>>>>>>>> call target
>>>>>>>> once the stub is found (see 
>>>>>>>> CompiledStaticCall::set_to_interpreted()).
>>>>>>>> It's just the same on x86_64:
>>>>>>>>
>>>>>>>> // static stub relocation stores the instruction address of the 
>>>>>>>> call
>>>>>>>> __ relocate(static_stub_Relocation::spec(mark), RELOC_IMM64);
>>>>>>>> // static stub relocation also tags the methodOop in the 
>>>>>>>> code-stream.
>>>>>>>> __ movoop(rbx, (jobject) NULL);  // method is zapped till fixup 
>>>>>>>> time
>>>>>>>> // This is recognized as unresolved by relocs/nativeinst/ic code
>>>>>>>> __ jump(RuntimeAddress(__ pc()));
>>>>>>>>
>>>>>>>> On PPC, we have to load the base of the constant table after 
>>>>>>>> generating the
>>>>>>>> static_stub_relocation and before emitting the ppc equivalent 
>>>>>>>> for moveoop(). This offset is
>>>>>>>> exactly what we store in the 
>>>>>>>> CompiledStaticCall::comp_to_int_load_offset constant.
>>>>>>> Why can't you point the relocation to the method load 
>>>>>>> instruction?  It doesn't seem right to do that in shared code.
>>>>>>>
>>>>>>> -- Chris
>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Goetz.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>>> Sent: Dienstag, 27. November 2012 01:53
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in 
>>>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC 
>>>>>>>> load in java_to_interp stub.]
>>>>>>>>
>>>>>>>>
>>>>>>>> On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz" 
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>> Hi Chris,
>>>>>>>>>
>>>>>>>>> We put it into the ad file because it describes an offset into 
>>>>>>>>> the stub that is
>>>>>>>>> generated from the ad file by emit_java_to_interp(CodeBuffer& 
>>>>>>>>> cbuf),
>>>>>>>>> used by ir  node CallStaticJavaDirect.  Maybe I should not 
>>>>>>>>> call it stub, but it's
>>>>>>>>> generated into the stubs section of the code buffer.
>>>>>>>>> If that stub generator is moved out of the ad file to shared 
>>>>>>>>> compiler code, one should
>>>>>>>>> move the field with it, but for the current implementation I 
>>>>>>>>> think that's fine.
>>>>>>>>>
>>>>>>>>> Does C1 generate the same stub? Or is the CompiledStaticCall a 
>>>>>>>>> C2 feature?
>>>>>>>>> If so, one could protect the whole thing by #ifdef COMPILER2.
>>>>>>>> Why do you need all these shared code changes when you have 
>>>>>>>> this in emit_java_to_interp_stub?
>>>>>>>>
>>>>>>>> // Create a static stub relocation which relates this stub
>>>>>>>> // with the call instruction at insts_call_instruction_offset 
>>>>>>>> in the
>>>>>>>> // instructions code-section.
>>>>>>>> __ relocate(static_stub_Relocation::spec(__ 
>>>>>>>> code()->insts()->start() + insts_relocation_offset));
>>>>>>>>
>>>>>>>> Do you need two relocations?  I'm confused.
>>>>>>>>
>>>>>>>> -- Chris
>>>>>>>>
>>>>>>>>> Thanks for all the bugids!
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Goetz.
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>>>> Sent: Mittwoch, 21. November 2012 19:53
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>> Subject: RFR (S): 8003853: specify offset of IC load in 
>>>>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC 
>>>>>>>>> load in java_to_interp stub.]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz" 
>>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>>> Hi Chris,
>>>>>>>>>>
>>>>>>>>>> yes, there is no C1 on ppc.
>>>>>>>>>> We do tiered compilation with a stripped C2.
>>>>>>>>> Right.  But some other architecture (or in the future) might 
>>>>>>>>> need this for C1 as well.  We should find a better place for 
>>>>>>>>> the value than the ad file.  The obvious place would be 
>>>>>>>>> compiledIC_.hpp but we don't have that file, yet.
>>>>>>>>>
>>>>>>>>> I filed:
>>>>>>>>>
>>>>>>>>> 8003853: specify offset of IC load in java_to_interp stub
>>>>>>>>>
>>>>>>>>> -- Chris
>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Goetz
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Christian Thalinger 
>>>>>>>>>> [mailto:christian.thalinger at oracle.com]
>>>>>>>>>> Sent: Dienstag, 20. November 2012 22:19
>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>>> Subject: Re: RFR (S): Specify offset of IC load in 
>>>>>>>>>> java_to_interp stub.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz" 
>>>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> The class CompiledStaticCall must know the location of the 
>>>>>>>>>>> IC load in the java_to_interp stub
>>>>>>>>>>> to update the IC  with NativeMovConstReg.  The current 
>>>>>>>>>>> implementation assumes that
>>>>>>>>>>> the load is always the first instruction in the stub.  This 
>>>>>>>>>>> is an artificial restriction. E.g.,
>>>>>>>>>>> it might be useful to load the constant pool address 
>>>>>>>>>>> (MachConstantBase) before the
>>>>>>>>>>> IC load (as we do on PPC).
>>>>>>>>>>>
>>>>>>>>>>> This change adds a constant specifying an offset from the 
>>>>>>>>>>> beginning of the stub to
>>>>>>>>>>> the  IC load. The offset is platform specific and 0 on sparc 
>>>>>>>>>>> and x86.
>>>>>>>>>>>
>>>>>>>>>>> You can find the change here:
>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/
>>>>>>>>>> That should be fixed indeed.
>>>>>>>>>>
>>>>>>>>>> +#ifndef COMPILER2
>>>>>>>>>> +const int CompiledStaticCall::comp_to_int_load_offset = 0;
>>>>>>>>>>
>>>>>>>>>> There is no C1 for PPC (sorry, I didn't check)?
>>>>>>>>>>
>>>>>>>>>> -- Chris
>>>>>>>>>>
>>>>>>>>>>> or in our ppc port:
>>>>>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33 
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thank you and best regards,
>>>>>>>>>>> Goetz
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>


From goetz.lindenmaier at sap.com  Tue Apr 16 07:23:56 2013
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 16 Apr 2013 14:23:56 +0000
Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp
	stub [Was: Re: RFR (S): Specify offset of IC load in
	java_to_interp	stub.]
In-Reply-To: <516CD9A3.3030202@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC0CFA7D32@DEWDFEMB12A.global.corp.sap>
	<03C4DFDE-CD52-446E-92AA-A6F12903FE29@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB116E@DEWDFEMB12A.global.corp.sap>
	<7D07437F-CFF7-4298-B9A1-DE9F2E32D77D@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB1EDE@DEWDFEMB12A.global.corp.sap>
	<8A8B46F8-0C91-4E8C-950A-0E65095DB2E0@oracle.com>
	<516CD9A3.3030202@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC0CFB36B2@DEWDFEMB12A.global.corp.sap>

Hi Dean, 

yes, you are right.  Sorry for that.

Best regards,
  Goetz.

-----Original Message-----
From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Dean Long
Sent: Dienstag, 16. April 2013 06:55
To: hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]

sparc.ad:

2538       CompiledStaticCall::emit_call(cbuf,
2539                                     (int) ($meth$$method - ((intptr_t) cbuf.insts_end()) - 4),
2540                                     rtype);

I think this should be:

CompiledStaticCall::emit_call(cbuf,$meth$$method,  rtype);

Computing the PC-relative offset probably only applies to x86.

dl

On 4/12/2013 2:03 PM, Christian Thalinger wrote:
> On Apr 11, 2013, at 2:46 PM, "Lindenmaier, Goetz"  wrote:
>
>> Hi all,
>>
>> I prepared the webrev for the changes discussed below:
>> http://cr.openjdk.java.net/~goetz/webrevs/8003853/
>>
>> To fix the issues we have with the PPC port with finding ICs, this change
>> cleans up the code handling compiled static Java calls:
>> - Methods using native instructions are moved from compiledIC.cpp
>>    to compiledIC_.cpp.
>> - Methods emitting the call patched by CompiledStaticCall are
>>    moved from the ad file to this class.
>>    As a side effect this reduces redundancies in x86_64.ad and x86_32.ad.
>> - We get rid of extern declarations in output.cpp.
> I like this.  Two comments:
>
> 1) Does it make sense to have emit_to_interp_stub when it's only used in one place?
>
> 2) Before we can push this someone has to do the same thing for ARM and PPC.  Any volunteers from the embedded team?
>
> -- Chris
>
>> Now all code concerning CompiledStaticCalls is collected in one class.
>> The PPC port needs not change shared code any more to implement them.
>> I also got around to move code to MacroAssembler, as only a simple call
>> was needed on x86 and sparc.
>>
>> Probably this is (M) now, no more (S).
>>
>> Please review and send comments.  I'll be happy to adapt to them!
>>
>> Best regards,
>>   Goetz Lindenmaier
>>
>> -----Original Message-----
>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>> Sent: Thursday, April 11, 2013 4:50 AM
>> To: Lindenmaier, Goetz
>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>
>>
>> On Apr 9, 2013, at 7:35 AM, "Lindenmaier, Goetz"  wrote:
>>
>>> Hi Chris,
>>>
>>> I'm now working on this issue.  Sorry for the delay...
>>>
>>> What do you think about moving
>>>    void emit_java_to_interp(CodeBuffer& cbuf);
>>> and
>>>   void size_java_to_interp();
>>> to compiledIC.hpp and the new platform file, too?
>> I like that.
>>
>>> This would also allow to overcome the ugly
>>>   extern uint size_java_to_interp();
>>> in output.cpp, as it could be replaced by CompiledStaticCall::size_java_to_interp().
>> Great.
>>
>>> I also would like to name this
>>> CompiledStaticCall::emit_to_interp_stub()
>>> CompiledStaticCall::to_interp_stub_size()
>> I'm okay with that.  Not sure if others have objections.
>>
>>> I could also extract code from enc_class Java_Static_Call
>>> to form a routine
>>> CompiledStaticCall::emit_call(CodeBuffer *cbuf, intptr_t entry_point, relocInfo::relocType rtype) {
>>>    emit_call_reloc(cbuf, entry_point, rtype)
>>>    if (rtype != relocInfo::runtime_call_type) {
>>>        emit_java_to_interp(cbuf);
>>>      }
>>> }
>>> With this, also
>>> extern uint reloc_java_to_interp();
>>> from output.cpp could be moved into this class.
>> On SPARC only or the other architectures as well?
>>
>>> Then handling of CompiledStaticCalls would be completely implemented in this
>>> one class.
>> That's tempting.
>>
>>> (I would have to move emit_call_reloc to MacroAssembler.)
>> Could you send a webrev with these changes?
>>
>> -- Chris
>>
>>> Best regards,
>>> Goetz.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>> Sent: Montag, 25. M?rz 2013 23:29
>>> To: Lindenmaier, Goetz
>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>
>>>
>>> On Mar 4, 2013, at 8:34 AM, "Lindenmaier, Goetz"  wrote:
>>>
>>>> Hi Chris,
>>>>
>>>> I would like to take up this issue again.
>>>> I'm about to put our changes on the jdk8 branch, and it would be convenient
>>>> to have a final solution for this.
>>>>
>>>> Should I prepare a webrev with a different solution adding a new file
>>>> for this?  What should go into that file?
>>> Sorry for answering that late.
>>>
>>> Yes, to see a patch for that would be good.  We need to put all platform dependent Compiled* methods in that new file.  Platform dependent means every method that uses a native* method from nativeInst_:
>>>
>>> CompiledIC::cleanup_call_site
>>> CompiledIC::is_icholder_call_site
>>> CompiledIC::CompiledIC
>>>
>>> CompiledStaticCall::set_to_interpreted
>>> CompiledStaticCall::set_stub_to_clean
>>> CompiledStaticCall::verify
>>>
>>> -- Chris
>>>
>>>> Best regards,
>>>> Goetz.
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: goetz.lindenmaier at sap.com
>>>> Sent: Dienstag, 18. Dezember 2012 10:42
>>>> To: 'Christian Thalinger'
>>>> Subject: RE: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>
>>>> Hi Chris,
>>>>
>>>> What would you put into that file?  The offset, or the class CompiledStaticCall?
>>>> You could also put it into nativeInst_  to avoid adding another file.
>>>>
>>>> But basically I think the offset is the best solution, because it's very small
>>>> and straight forward, and the offset is set where the code is generated
>>>> that defines the offset.
>>>>
>>>> Only the #ifndef COMPILER2 is ugly, but here I think the solution is to
>>>> guard the whole class CompiledStaticCall with #ifdef COMPILER2.
>>>>
>>>> But I'm happy with any placement of the code.
>>>>
>>>> Best regards,
>>>> Goetz.
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>> Sent: Montag, 17. Dezember 2012 21:34
>>>> To: Lindenmaier, Goetz
>>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>
>>>>
>>>> On Nov 29, 2012, at 2:10 PM, "Lindenmaier, Goetz"  wrote:
>>>>
>>>>> Hi Chris,
>>>>>
>>>>> Loading the constant takes 5 instructions, the other way only three,
>>>>> in the code only one, if the constant pool base is in a register.
>>>>> The 5 instructions are hard to patch atomically.  The constant pool
>>>>> is just a 64 bit store.
>>>>>
>>>>>> Sorry for being so persistent on this :-)
>>>>> That's ok, I already found several places in our VM where it was easy to
>>>>> change our code to get along without the shared changes we did in
>>>>> first place.  But I can't redesign everything, and I can not risk to break
>>>>> anything in our product.
>>>>>
>>>>> If you feel like doing so, you can have a look at
>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/600ce596eea9
>>>>> which contains our bytecode interpreter profiling implementation.
>>>>> If you think this is currently of use in the main branch, I would lift it to HS25
>>>>> (the permgen changes might cause trouble) and contribute it to hsx.
>>>> Sorry for the long delay.
>>>>
>>>> Thinking about this problem again it seems that the correct solution would be to have a compiledIC_.cpp file.
>>>>
>>>> The CompiledIC instruction layout is platform dependent; it just happens to be the same for all architectures we have right now (well, except PPC) because we made it to be the same.  Actually on SPARC we could also use a load from the constant table which would be simpler.
>>>>
>>>> Having a platform dependent file for this code feels right.  What do you think?
>>>>
>>>> -- Chris
>>>>
>>>>> Best regards,
>>>>> Goetz.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>> Sent: Thursday, November 29, 2012 7:53 PM
>>>>> To: Lindenmaier, Goetz
>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>>
>>>>>
>>>>> On Nov 29, 2012, at 12:27 AM, "Lindenmaier, Goetz"  wrote:
>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>>> Why can't you point the relocation to the method load instruction?  It doesn't seem right to do that in shared code.
>>>>>> Because the relocation is used
>>>>>> 1.) to find the beginning of the stub to patch the call to go there
>>>>>> 2.) to find the load to patch the IC.
>>>>> Got it.
>>>>>
>>>>>> Just have a look at CompiledStaticCall::set_to_interpreted(),
>>>>>> the variable 'stub' is used twice.
>>>>> Sorry for being so persistent on this :-)  What is the reason you have to load the constant from the constant table?  On other architectures we materialize the constant.
>>>>>
>>>>> -- Chris
>>>>>
>>>>>> Best regards,
>>>>>> Goetz.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>> Sent: Donnerstag, 29. November 2012 01:35
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>>>
>>>>>>
>>>>>> On Nov 27, 2012, at 4:24 AM, "Lindenmaier, Goetz"  wrote:
>>>>>>
>>>>>>> Hi Chris,
>>>>>>>
>>>>>>>> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub?
>>>>>>> Shared code (class CompiledStaticCall) wants to patch the inline cache
>>>>>>> in the stub which is emitted in platform code.
>>>>>>> So the platform code should specify how the shared code can find the inline cache
>>>>>>> in the stub, which it does through the constant I introduced.
>>>>>>>
>>>>>>>> Do you need two relocations?  I'm confused.
>>>>>>> No, three ;)
>>>>>>> The relocation you mention is used to find the stub given the call.
>>>>>>> The other relocations are needed to find the inline cache / call target
>>>>>>> once the stub is found (see CompiledStaticCall::set_to_interpreted()).
>>>>>>> It's just the same on x86_64:
>>>>>>>
>>>>>>> // static stub relocation stores the instruction address of the call
>>>>>>> __ relocate(static_stub_Relocation::spec(mark), RELOC_IMM64);
>>>>>>> // static stub relocation also tags the methodOop in the code-stream.
>>>>>>> __ movoop(rbx, (jobject) NULL);  // method is zapped till fixup time
>>>>>>> // This is recognized as unresolved by relocs/nativeinst/ic code
>>>>>>> __ jump(RuntimeAddress(__ pc()));
>>>>>>>
>>>>>>> On PPC, we have to load the base of the constant table after generating the
>>>>>>> static_stub_relocation and before emitting the ppc equivalent for moveoop(). This offset is
>>>>>>> exactly what we store in the  CompiledStaticCall::comp_to_int_load_offset constant.
>>>>>> Why can't you point the relocation to the method load instruction?  It doesn't seem right to do that in shared code.
>>>>>>
>>>>>> -- Chris
>>>>>>
>>>>>>> Best regards,
>>>>>>> Goetz.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>> Sent: Dienstag, 27. November 2012 01:53
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>>>>
>>>>>>>
>>>>>>> On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz"  wrote:
>>>>>>>
>>>>>>>> Hi Chris,
>>>>>>>>
>>>>>>>> We put it into the ad file because it describes an offset into the stub that is
>>>>>>>> generated from the ad file by emit_java_to_interp(CodeBuffer& cbuf),
>>>>>>>> used by ir  node CallStaticJavaDirect.  Maybe I should not call it stub, but it's
>>>>>>>> generated into the stubs section of the code buffer.
>>>>>>>> If that stub generator is moved out of the ad file to shared compiler code, one should
>>>>>>>> move the field with it, but for the current implementation I think that's fine.
>>>>>>>>
>>>>>>>> Does C1 generate the same stub? Or is the CompiledStaticCall a C2 feature?
>>>>>>>> If so, one could protect the whole thing by #ifdef COMPILER2.
>>>>>>> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub?
>>>>>>>
>>>>>>> // Create a static stub relocation which relates this stub
>>>>>>> // with the call instruction at insts_call_instruction_offset in the
>>>>>>> // instructions code-section.
>>>>>>> __ relocate(static_stub_Relocation::spec(__ code()->insts()->start() + insts_relocation_offset));
>>>>>>>
>>>>>>> Do you need two relocations?  I'm confused.
>>>>>>>
>>>>>>> -- Chris
>>>>>>>
>>>>>>>> Thanks for all the bugids!
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Goetz.
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>>> Sent: Mittwoch, 21. November 2012 19:53
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>> Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>>>>>>>
>>>>>>>>
>>>>>>>> On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz"  wrote:
>>>>>>>>
>>>>>>>>> Hi Chris,
>>>>>>>>>
>>>>>>>>> yes, there is no C1 on ppc.
>>>>>>>>> We do tiered compilation with a stripped C2.
>>>>>>>> Right.  But some other architecture (or in the future) might need this for C1 as well.  We should find a better place for the value than the ad file.  The obvious place would be compiledIC_.hpp but we don't have that file, yet.
>>>>>>>>
>>>>>>>> I filed:
>>>>>>>>
>>>>>>>> 8003853: specify offset of IC load in java_to_interp stub
>>>>>>>>
>>>>>>>> -- Chris
>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Goetz
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>>>> Sent: Dienstag, 20. November 2012 22:19
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>> Subject: Re: RFR (S): Specify offset of IC load in java_to_interp stub.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz"  wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub
>>>>>>>>>> to update the IC  with NativeMovConstReg.  The current implementation assumes that
>>>>>>>>>> the load is always the first instruction in the stub.  This is an artificial restriction. E.g.,
>>>>>>>>>> it might be useful to load the constant pool address (MachConstantBase) before the
>>>>>>>>>> IC load (as we do on PPC).
>>>>>>>>>>
>>>>>>>>>> This change adds a constant specifying an offset from the beginning of the stub to
>>>>>>>>>> the  IC load. The offset is platform specific and 0 on sparc and x86.
>>>>>>>>>>
>>>>>>>>>> You can find the change here:
>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/
>>>>>>>>> That should be fixed indeed.
>>>>>>>>>
>>>>>>>>> +#ifndef COMPILER2
>>>>>>>>> +const int CompiledStaticCall::comp_to_int_load_offset = 0;
>>>>>>>>>
>>>>>>>>> There is no C1 for PPC (sorry, I didn't check)?
>>>>>>>>>
>>>>>>>>> -- Chris
>>>>>>>>>
>>>>>>>>>> or in our ppc port:
>>>>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33
>>>>>>>>>>
>>>>>>>>>> Thank you and best regards,
>>>>>>>>>> Goetz
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>


From roland.westrelin at oracle.com  Tue Apr 16 07:34:24 2013
From: roland.westrelin at oracle.com (roland.westrelin at oracle.com)
Date: Tue, 16 Apr 2013 14:34:24 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets
Message-ID: <20130416143432.37BFC48334@hg.openjdk.java.net>

Changeset: acadb114c818
Author:    roland
Date:      2013-04-15 17:17 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/acadb114c818

8011648: C1: optimized build is broken after 7153771
Summary: missing #ifdef ASSERT
Reviewed-by: kvn

! src/share/vm/c1/c1_Canonicalizer.cpp
! src/share/vm/c1/c1_Canonicalizer.hpp
! 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_LIRGenerator.cpp
! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/c1/c1_Optimizer.cpp
! src/share/vm/c1/c1_RangeCheckElimination.hpp
! src/share/vm/c1/c1_ValueMap.hpp

Changeset: b105029fdbfd
Author:    roland
Date:      2013-04-15 18:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b105029fdbfd

Merge



From vladimir.kozlov at oracle.com  Tue Apr 16 08:00:49 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 16 Apr 2013 08:00:49 -0700
Subject: RFR (M): 8006952: Slow VM due to excessive code cache freelist
	iteration
In-Reply-To: <516D24FE.1090105@oracle.com>
References: <5107AADF.6010501@oracle.com> <51082499.3000905@oracle.com>
	<51093FAC.6090803@oracle.com> <51097FA6.3050709@oracle.com>
	<510ABAB9.8020909@oracle.com>
	<15E6C57378C5FE43AD074594DD824E501C8AB7E7@DEWDFEMB15A.global.corp.sap>
	<511511A5.8050101@oracle.com> <5167DFC2.6020007@oracle.com>
	<51684283.7010304@oracle.com> <516BD82A.7050302@oracle.com>
	<516D24FE.1090105@oracle.com>
Message-ID: <516D67A1.1060002@oracle.com>

Looks good.

Do I understand correctly that now we bailout from in compileBroker 
conservatively if no enough space at the end of code cache? But in a 
middle we could have a big free block. Right?

Thanks,
Vladimir

On 4/16/13 3:16 AM, Nils Eliasson wrote:
> Latest webrev: http://cr.openjdk.java.net/~neliasso/8006952/webrev.09/
> 
>
> Updates after comments from Vladimir K. and Niclas.
>
> - Removed 'red_zone' naming and refined comments
> - Refined naming in heap.cpp/hpp on conversion methods
> size(...)/number_of_segments(...) to
> size_to_segments(...)/segments_to_size(...)
> - Bool flags as verbs (critical -> is_critical)
> - Removed get_largest_block() and all its uses.
>
> Enjoy!
>
> //Nils
>
> On 2013-04-15 12:36, Nils Eliasson wrote:
>>
>> Hi,
>>
>> On 2013-04-12 19:21, Vladimir Kozlov wrote:
>>> Nils,
>>>
>>> It is sad that you have to reverse parfait fix but I agree that your
>>> changes are more clean.
>>
>> Please - don't be! I taken extra precaution and have verified that
>> there is a null check between the call to new and the constructor.
>> This is consistent with both the C++ spec and the behaviour we rely on
>> when running out of code cache. The CodeCache::has_space would have
>> forced me to do it more complex, it would have to copy/wrap the
>> heap::allocate algorithm but returning a bool instead of actually
>> allocating.
>>
>> Sorry for forgetting to add it to the change log in my request. I did
>> not intend to revert it without being open about it.
>>
>> I don't understand why Parfait is confused about 'this' being null in
>> the constructor. I will open a bug on Parfait if I can find where to
>> submit it.
>>
>>>
>>> After these changes largest_free_block() is used only in statistics
>>> output which is useless since it is not participating in codecache
>>> allocations.  May be we should remove it and use
>>> heap_unallocated_capacity() instead (do we need lock then?):
>>
>> Yes, good idea. Must check that I don't break any log tool if I change
>> the output though.
>>
>>>
>>> size_t CodeCache::largest_free_block() {
>>>   return _heap->heap_unallocated_capacity();
>>> }
>>>
>>> Also red_zone_start() is confusing because it does not show how it is
>>> related to heap_unallocated_capacity(). In one place you use one:
>>>
>>>  211     if (size(length) > (heap_unallocated_capacity() -
>>> CodeCacheMinimumFreeSpace)) {
>>>
>>> and in an other use second:
>>>
>>>  437     if (((size_t)cur + length) >= (size_t)red_zone_start()) {
>>>
>>> Can we just use only heap_unallocated_capacity()?
>>
>> I agree that it is confusing. The background is that they serve a bit
>> different purpose. In one case we are allocating from the freelist and
>> need to check against the adress where the 'red zone/critical
>> allocation area begins.' In the other it is a block allocation from
>> the contiguous heap where we know heap_unallocated_capacity is the
>> size of the block at the end of the heap. I'll come up with something
>> better.
>>
>> Thanks for taking your time!
>> //Nils
>>
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 4/12/13 3:19 AM, Nils Eliasson wrote:
>>>> I have now incorporated both Vladimirs and Andreas suggestion:
>>>>
>>>> Changes to previous revision includes:
>>>> 1) Updated the checks in both heap::allocate and heap::search_freelist
>>>> so that non critical allocation never stride into the
>>>> CodeCacheMinimumFreeSpace.
>>>> 2) Inverted the critical condition - now all allocations default to not
>>>> critical. Only the places where we would go fatal if the allocation
>>>> returns null are critical.
>>>> 3) Refactored some names and removed duplicate methods in heap.cpp.
>>>>
>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.08/
>>>> 
>>>>
>>>> This changes also opens up for decreasing the CodeCacheMinimumFreeSpace
>>>> since we now guarantee that only critical allocation will end up there.
>>>> And they will not grow to 500K when compilation have stopped anyways.
>>>>
>>>> Kind regards,
>>>> //Nils
>>>>
>>>>
>>>> On 2013-02-08 15:54, Nils Eliasson wrote:
>>>>> Vladimir and Andreas, thanks for your feedback! I am considering your
>>>>> suggestions.
>>>>>
>>>>> My fix is a step in the right direction but I realize it is not
>>>>> enough.
>>>>>
>>>>> Initially, it works good reserving the last part of the heap block.
>>>>> But if the application has a bigger active code footprint that what
>>>>> can fit in the code cache, there will be new flushes that will
>>>>> increase fragmentation and slowly reduce the usable part of the code
>>>>> cache. So I will add functionality for backing off.
>>>>>
>>>>> //Nils
>>>>>
>>>>> Schoesser, Andreas skrev 2013-02-01 10:58:
>>>>>> Hi Nils,
>>>>>>
>>>>>> this is IMO a good idea since we experienced the same problem with
>>>>>> one of our ports. I think in our case it was not the nmethod sweeper
>>>>>> continuously running (there's MinCodeCacheFlushingInterval to only
>>>>>> speculatively disconnect nmethods every 30 seconds) but from the
>>>>>> compiler loop constantly polling the freelist without the nmethod
>>>>>> sweeper making any progress.
>>>>>>
>>>>>> You also might consider to propagate the "critical" flag down to
>>>>>> search_freelist(). Then, a simple address compare would do to keep
>>>>>> the end of the code cache free from nmethods:
>>>>>> - For non-critical blobs, search_freelist() may only fit free blocks
>>>>>> < CodeCache::end() - CodeCacheMinimumFreeSpace
>>>>>> - For critical blocks, search_freelist() may fit all free blocks
>>>>>>
>>>>>> Best regards,
>>>>>> Andreas
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: hotspot-compiler-dev-bounces at openjdk.java.net
>>>>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of
>>>>>> Nils Eliasson
>>>>>> Sent: Donnerstag, 31. Januar 2013 19:41
>>>>>> To: hotspot-compiler-dev at openjdk.java.net
>>>>>> Subject: Re: RFR (M): 8006952: Slow VM due to excessive code cache
>>>>>> freelist iteration
>>>>>>
>>>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.04/
>>>>>>
>>>>>> //N
>>>>>>
>>>>>> Vladimir Kozlov skrev 2013-01-30 21:16:
>>>>>>> Nils, you sent webrev for other bug fix.
>>>>>>>
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 1/30/13 7:43 AM, Nils Eliasson wrote:
>>>>>>>> Thanks for the link, interesting background.
>>>>>>>>
>>>>>>>> Even if finding the largest block on the freelist is free, we would
>>>>>>>> still have a misbehavior when the free heap block is less than 1,5M
>>>>>>>> and
>>>>>>>> the flushing begins to create a 1,5M freelist block.
>>>>>>>>
>>>>>>>> Unallocated memory is a good measurement if have some continuous
>>>>>>>> memory
>>>>>>>> in reserve for critical blobs. I am thinking of using the
>>>>>>>> thresholds
>>>>>>>> against unallocated memory, but forbidding nmethods from using the
>>>>>>>> last
>>>>>>>> 0,5M (MinimumFreeSpace) from the heap block. That would prevent
>>>>>>>> the VM
>>>>>>>> from fragmenting the last continuous memory space, and allow the
>>>>>>>> VM to
>>>>>>>> use all of the freelist.
>>>>>>>>
>>>>>>>> Like this:
>>>>>>>> http://cr.openjdk.java.net/~neliasso/8002364/webrev.03
>>>>>>>>
>>>>>>>> //Nils
>>>>>>>>
>>>>>>>> Vladimir Kozlov skrev 2013-01-29 20:35:
>>>>>>>>> Nils,
>>>>>>>>>
>>>>>>>>> You are reversing 7025742 fix. I would prefer to keep track of a
>>>>>>>>> largest free block during allocation in CodeCache (by using
>>>>>>>>> ordered
>>>>>>>>> list or other technique) to avoid scanning the list.
>>>>>>>>>
>>>>>>>>> Vladimir
>>>>>>>>>
>>>>>>>>> On 1/29/13 2:56 AM, Nils Eliasson wrote:
>>>>>>>>>> Remove continuous free block requirement for code cache
>>>>>>>>>> flushing and
>>>>>>>>>> minimum free space.
>>>>>>>>>>
>>>>>>>>>> This causes a degenerate behavior when the VM are repeatedly
>>>>>>>>>> flushing
>>>>>>>>>> the code cache trying to free up a continuous 1,5M block.
>>>>>>>>>> Since the
>>>>>>>>>> freelist is fragmented a significant part of the code cache is
>>>>>>>>>> kept
>>>>>>>>>> unallocated. A significant amount of time is spent traversing the
>>>>>>>>>> freelist holding the code cache lock or waiting for other threads
>>>>>>>>>> doing
>>>>>>>>>> the same.
>>>>>>>>>>
>>>>>>>>>> I don't see any reason for why a continuous block is required.
>>>>>>>>>> Code
>>>>>>>>>> cache flushing threshold (CodeCacheFlushingMinimumFreeSpace) is
>>>>>>>>>> default
>>>>>>>>>> 1,5M and code cache minimum threshold
>>>>>>>>>> (CodeCacheMinimumFreeSpace) is
>>>>>>>>>> 0,5M. Finding such a block on the freelist is often unrealistic,
>>>>>>>>>> and has
>>>>>>>>>> not any purpose. The largest nmethods are in the order of
>>>>>>>>>> 250k, and
>>>>>>>>>> they
>>>>>>>>>> are not allocated when code cache is starting to run out. All
>>>>>>>>>> critical
>>>>>>>>>> adapters are small and will fit easily in the freelist or in the
>>>>>>>>>> remaining heap space.
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.02/
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Nils Eliasson
>>>>>
>>>>
>>
>

From roland.westrelin at oracle.com  Tue Apr 16 08:06:41 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 16 Apr 2013 17:06:41 +0200
Subject: RFR(XS): 8011901:  Unsafe.getAndAddLong(obj, off,
	delta) does not work properly with long deltas
In-Reply-To: <51683740.7090107@oracle.com>
References: <2234A456-8619-4B27-AF7F-4D9F9181E08D@oracle.com>
	<51683740.7090107@oracle.com>
Message-ID: <1BEC12D9-2395-4676-93F3-41F442EF208A@oracle.com>


> Looks good. Fixes the test on Linux/x86_64, as well as the original
> problem this testcase was derived from.

Thanks for checking. And providing a test case. And doing most of the analysis.

Roland.

From roland.westrelin at oracle.com  Tue Apr 16 08:15:09 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 16 Apr 2013 17:15:09 +0200
Subject: RFR(XS): 8011901:  Unsafe.getAndAddLong(obj, off,
	delta) does not work properly with long deltas
In-Reply-To: <516847BB.8010007@oracle.com>
References: <2234A456-8619-4B27-AF7F-4D9F9181E08D@oracle.com>
	<516847BB.8010007@oracle.com>
Message-ID: <5F87EDC9-0F07-45FF-B59A-4458E72DA1BE@oracle.com>

Hi Vladimir,

> The fix is correct, only movq instruction can load 64bit immediate value. I looked on other instructions (in x86_64.ad and x86.ad) with immL parameter and all of them use movq only. Could you double check?

Thanks for the review. I checked and I don't see immL being used with anything but movq either.

> Also remove unused "enc_class Con64" to avoid its usage by accident.

I will.

Roland.

From igor.ignatyev at oracle.com  Tue Apr 16 09:06:12 2013
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 16 Apr 2013 20:06:12 +0400
Subject: RFR(S) : 8011675: adding compilation level to replay data
In-Reply-To: <516C7287.8070600@oracle.com>
References: <51631AEA.9080702@oracle.com> <51635E89.30808@oracle.com>
	<5163BD9A.5080308@oracle.com> <5163C5F4.7020605@oracle.com>
	<516827EA.3040001@oracle.com> <5168874B.9080407@oracle.com>
	<5169AEA2.7060103@oracle.com> <516C7287.8070600@oracle.com>
Message-ID: <516D76F4.9010305@oracle.com>

 > Okay. Please, test it: generate replay.txt with C1 without recording
 > comp_level (old style) and then try to replay it with new code.
'TestVM_no_comp_level.sh' emulates old style of replay data.

 >>> Add tests for tiered with different -XX:TieredStopAtLevel=n.
 >> what exactly did you mean?
 >> 1) generate replay.txt by VM with different value of 'TieredStopAtLevel'
 >> 2) use different 'TieredStopAtLevel' during replay of compilation
 >
 > I meant 1). VM could crash at any level of compilation because they are
 > different so we need to be able replay all of them. So I want to verify
 > that it works (positive tests).
block 'if [ $is_tiered -eq 1 ]' was added to TestVM.sh

> Run in JPRT to verify that tests work on all platforms.
There are some failures in TestSA.sh due to known bugs in SA 
(JDK-8011888, JDK-6326653) and environment/infra issue on macosx (core 
wasn't generated because '/cores' directory doesn't exist or isn't 
writable by current user[1]).

updated webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.04/

[1] 
http://developer.apple.com/library/mac/technotes/tn2124/_index.html#//apple_ref/doc/uid/DTS10003391-CH1-SECCOREDUMPS

Best regards,
Igor Ignatyev

On 04/16/2013 01:35 AM, Vladimir Kozlov wrote:
> On 4/13/13 12:14 PM, Igor Ignatyev wrote:
>>> If you replaying C1 compilation next setting will be incorrect. Should
>>> we use CompLevel_highest_tier instead so that following check pass?:
>>>
>>> +     if (had_error() && (error_message() == comp_level_label)) {
>>> +       comp_level = CompLevel_full_optimization;
>>>
>>
>> i added this code for compatible with old version and i think that it
>> must has the same behavior (use 'CompLevel_full_optimization'). in new
>> version we always will have comp_level in replay.txt.
>> so i think we shouldn't use CompLevel_highest_tier.
>
> Okay. Please, test it: generate replay.txt with C1 without recording
> comp_level (old style) and then try to replay it with new code.
>
>>
>>> Add tests for tiered with different -XX:TieredStopAtLevel=n.
>> what exactly did you mean?
>> 1) generate replay.txt by VM with different value of 'TieredStopAtLevel'
>> 2) use different 'TieredStopAtLevel' during replay of compilation
>
> I meant 1). VM could crash at any level of compilation because they are
> different so we need to be able replay all of them. So I want to verify
> that it works (positive tests).
>
>>
>> if 1st, i don't think that test must to iterate through all possible
>> values, it must be done by harness, test execution etc
>
> I agree with you but, unfortunately, we are short on testing hardware to
> add an other testing variation. You should know. So adding this testing
> here when tiered VM is tested will help us now.
>
>> if 2nd, current implementation of ciReplay ignore TieredStopAtLevel
>> flags, so these tests will be useless.
>>
>>> You may still not find core file. Or ulimit -c unlimited will not work
>>> (windows, OS X?). You need to bailout in such case as success.
>> for windows i added '-XX:+CreateMinidumpOnCrash', but whatever case of
>> not found core-file need to treat as a environment issue, a test bug or
>> may even be a product bug. anyway if it happened, i think it would be
>> better to know about this than just skip the test.
>>
>> i updated webrev according to the rest of your suggestions, but i'm not
>> sure about flags to limit core size.
>
> Run in JPRT to verify that tests work on all platforms.
>
>>
>> also i added one more check of comp_level and moved validation to
>> separate method.
>
> OK.
>
> Thanks,
> Vladimir
>
>>
>> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.03/
>>
>> Best regards,
>> Igor Ignatyev
>>
>> On 04/13/2013 02:14 AM, Vladimir Kozlov wrote:
>>> I would set CrashAfterCompileId default to -1 as indication it is not
>>> set. Then you don't need to check CrashAfterCompileId == 0 since
>>> compile_id is positive. By the way, it is very nice idea but add a
>>> comment about what that code for. I did not get it first :)
>>>
>>> About name. For such flags we use CI: CIBreakAt, CIStop. So I would
>>> suggest to use CICrashAt. Which means VM crash with that compile id, not
>>> when it is greater.
>>>
>>> If you replaying C1 compilation next setting will be incorrect. Should
>>> we use CompLevel_highest_tier instead so that following check pass?:
>>>
>>> +     if (had_error() && (error_message() == comp_level_label)) {
>>> +       comp_level = CompLevel_full_optimization;
>>>
>>>
>>> About tests.
>>>
>>> Add -Xmx32m, -XX:ParallelGCThreads=2 and other flags (codecache
>>> ,metaspace) to limit core size on big machines.
>>>
>>> Add tests for tiered with different -XX:TieredStopAtLevel=n.
>>>
>>> I would add more info in output why the test is skipped:
>>>       echo TEST SKIPPED
>>>
>>> typo 'java':
>>>   124 is_tiered=`${JAVA} ${TESTVMOPTS} java -XX:+PrintFlagsFinal
>>> -version 2>&1 | grep TieredCompilation | grep -c true`
>>>
>>>
>>> I don't like next:
>>>
>>>   130 ${JAVA} ${TESTVMOPTS} -Xcomp -XX:CrashAfterCompileId=1
>>> -XX:+CreateMinidumpOnCrash -XX:+DumpReplayDataOnError -version &
>>>   131 crash_pid=$!
>>>   132 wait $crash_pid
>>>
>>>   On windows 'wait $crash_pid' may not work (happened before) because
>>> before you execute 'wait' OS may assign the same pid to different
>>> process.
>>>
>>> You may still not find core file. Or ulimit -c unlimited will not work
>>> (windows, OS X?). You need to bailout in such case as success. Next code
>>> is incorrect for that:
>>>
>>>    48 if [ -z "${core_file}" -o ! -r "${core_file}" ]
>>>    49 then
>>>    50     echo TEST FAILED: core wasn\'t generated
>>>    51     exit 2
>>>    52 fi
>>>
>>> Thanks
>>> Vladimir
>>>
>>> On 4/12/13 8:27 AM, Igor Ignatyev wrote:
>>>> updated webrev:
>>>> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.02/
>>>> added:
>>>>    1. more informative message on unsupported comp_level
>>>>    2. not-product flag 'CrashAfterCompileId' and assert in
>>>> compileBroker.cpp for assured generation of replay.txt
>>>>    2. tests for ciReplay
>>>>
>>>> Best regards,
>>>> Igor Ignatyev
>>>>
>>>> On 04/09/2013 11:40 AM, Vladimir Kozlov wrote:
>>>>> Igor,
>>>>>
>>>>> Sorry, I may said it not clear. What I meant is to set error (call
>>>>> report_error()) in such case and return from process_compile() without
>>>>> compilation. But let ciReplay::replay() finish and exit. replay_impl()
>>>>> should print the problem so you don't need to do it in
>>>>> process_compile(). And, please, test it.
>>>>> The message should be more informative, something like:
>>>>> "compilation level %d requires TieredCompilation"
>>>>> An other bad cases is when failure happened in Client (C1) or Server
>>>>> (C2) but the replay is run with opposite VM.
>>>>>
>>>>> thanks,
>>>>> Vladimir
>>>>>
>>>>> On 4/9/13 12:04 AM, Igor Ignatyev wrote:
>>>>>> Vladimir,
>>>>>>
>>>>>> Thank you for review.
>>>>>>
>>>>>> updated webrev:
>>>>>> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.01/
>>>>>>
>>>>>> Best regards,
>>>>>> Igor Ignatyev
>>>>>>
>>>>>> On 04/09/2013 04:19 AM, Vladimir Kozlov wrote:
>>>>>>> Igor,
>>>>>>>
>>>>>>> Thank you for fixing and cleaning this.
>>>>>>>
>>>>>>> In vmStructs.cpp move _comp_level after _compile_id as in nmethod
>>>>>>> class.
>>>>>>>
>>>>>>> Typo in ciReplay.cpp:
>>>>>>> +      comp_level != CompLevel_highest_tier;
>>>>>>>
>>>>>>> Actually it is useless to replay compilation at different level, it
>>>>>>> should exit with error. Could happened because incorrectly run
>>>>>>> without
>>>>>>> Tiered when the crush happened with Tiered.
>>>>>>>
>>>>>>> In ciReplay.cpp use parenthesis around equality checks: if (. &&
>>>>>>> (. ==
>>>>>>> .)).
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 4/8/13 12:30 PM, Igor Ignatyev wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Please review patch.
>>>>>>>>
>>>>>>>> Problem:
>>>>>>>> Replay of compilations supports c1 and tiered as well as c2, the
>>>>>>>> only
>>>>>>>> thing missing is comp_level.
>>>>>>>>
>>>>>>>> Fix:
>>>>>>>> 1. added comp_level into dump and usage during replay
>>>>>>>> 2. minor changes in agent/doc:
>>>>>>>>    - escaped '<', '>'
>>>>>>>>    - renamed 'C2 Replay'/'C2 compiler replay' to 'Replay'/'Compiler
>>>>>>>> replay'
>>>>>>>>
>>>>>>>> Testing:
>>>>>>>> manually launched the replay from JDK-8010934 (assert
>>>>>>>> specifically to
>>>>>>>> c1) on jvm w/o corresponded fix. assert was triggered w/ patch and
>>>>>>>> wasn't triggered w/o.
>>>>>>>>
>>>>>>>>
>>>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.00/
>>>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011675

From roland.westrelin at oracle.com  Tue Apr 16 09:17:20 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 16 Apr 2013 18:17:20 +0200
Subject: RFR(XS): 8012292: optimized build with GCC broken
Message-ID: <9A5E5A4F-F829-40C8-BF08-AFDC90C1E51C@oracle.com>

http://cr.openjdk.java.net/~roland/8012292/webrev.00/

Contributed by Gilles Duboscq (openjdk: grub).

Roland.

From dean.long at oracle.com  Tue Apr 16 09:22:38 2013
From: dean.long at oracle.com (Dean Long)
Date: Tue, 16 Apr 2013 09:22:38 -0700
Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp
	stub [Was: Re: RFR (S): Specify offset of IC load in
	java_to_interp	stub.]
In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFB36A3@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC0CFA7D32@DEWDFEMB12A.global.corp.sap>
	<03C4DFDE-CD52-446E-92AA-A6F12903FE29@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB116E@DEWDFEMB12A.global.corp.sap>
	<7D07437F-CFF7-4298-B9A1-DE9F2E32D77D@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB1EDE@DEWDFEMB12A.global.corp.sap>
	<8A8B46F8-0C91-4E8C-950A-0E65095DB2E0@oracle.com>
	<516CD9A3.3030202@oracle.com> <516CDF6A.4080900@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB36A3@DEWDFEMB12A.global.corp.sap>
Message-ID: <516D7ACE.9010305@oracle.com>

What I'm suggesting is leaving all calls in the .ad file. "enc_class 
Java_Static_Call" would remain largely unchanged
except renaming emit_java_to_interp() to 
CompiledStaticCall::emit_to_interp_stub() .
The motivation for keeping the call code in the .ad file is because it 
has to match what MachCall*Node::ret_addr_offset()
is returning.

compiledIC.hpp:
+  // Code
+  static void emit_to_interp_stub(CodeBuffer &cbuf);
+  static uint to_interp_stub_size();
+  static uint reloc_to_interp_stub();

dl

On 4/16/2013 7:22 AM, Lindenmaier, Goetz wrote:
> Hi Dean,
>
> I left the runtime call in the ad file, as it's got nothing to do with
> CompiledStaticCalls that call Java.
>
> I thought this is a better separation of concerns.
> Anyways, you would have to pass in _method and
> _optimized_virtual, which are fields of the machnode.
>
> Best regards,
>    Goetz.
>
>
>
>
>
> -----Original Message-----
> From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Dean Long
> Sent: Dienstag, 16. April 2013 07:20
> To: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>
> Also, is moving the call into CompiledStaticCall::emit_call() really
> needed for PPC?  I'd prefer to move the
> stub emitter instead (sample sparc code):
>
>       if ( !_method ) {
>         emit_call_reloc(cbuf, $meth$$method, relocInfo::runtime_call_type);
>       } else if (_optimized_virtual) {
>         emit_call_reloc(cbuf, $meth$$method,
> relocInfo::opt_virtual_call_type);
>       } else {
>         emit_call_reloc(cbuf, $meth$$method, relocInfo::static_call_type);
>       }
>       if( _method ) {  // Emit stub for static call
>         CompiledStaticCall::emit_java_to_interp(cbuf);<---
>       }
>
> dl
>
> On 4/15/2013 9:54 PM, Dean Long wrote:
>> sparc.ad:
>>
>> 2538       CompiledStaticCall::emit_call(cbuf,
>> 2539                                     (int) ($meth$$method -
>> ((intptr_t) cbuf.insts_end()) - 4),
>> 2540                                     rtype);
>>
>> I think this should be:
>>
>> CompiledStaticCall::emit_call(cbuf,$meth$$method,  rtype);
>>
>> Computing the PC-relative offset probably only applies to x86.
>>
>> dl
>>
>> On 4/12/2013 2:03 PM, Christian Thalinger wrote:
>>> On Apr 11, 2013, at 2:46 PM, "Lindenmaier, Goetz"
>>>  wrote:
>>>
>>>> Hi all,
>>>>
>>>> I prepared the webrev for the changes discussed below:
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8003853/
>>>>
>>>> To fix the issues we have with the PPC port with finding ICs, this
>>>> change
>>>> cleans up the code handling compiled static Java calls:
>>>> - Methods using native instructions are moved from compiledIC.cpp
>>>>     to compiledIC_.cpp.
>>>> - Methods emitting the call patched by CompiledStaticCall are
>>>>     moved from the ad file to this class.
>>>>     As a side effect this reduces redundancies in x86_64.ad and
>>>> x86_32.ad.
>>>> - We get rid of extern declarations in output.cpp.
>>> I like this.  Two comments:
>>>
>>> 1) Does it make sense to have emit_to_interp_stub when it's only used
>>> in one place?
>>>
>>> 2) Before we can push this someone has to do the same thing for ARM
>>> and PPC.  Any volunteers from the embedded team?
>>>
>>> -- Chris
>>>
>>>> Now all code concerning CompiledStaticCalls is collected in one class.
>>>> The PPC port needs not change shared code any more to implement them.
>>>> I also got around to move code to MacroAssembler, as only a simple call
>>>> was needed on x86 and sparc.
>>>>
>>>> Probably this is (M) now, no more (S).
>>>>
>>>> Please review and send comments.  I'll be happy to adapt to them!
>>>>
>>>> Best regards,
>>>>    Goetz Lindenmaier
>>>>
>>>> -----Original Message-----
>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>> Sent: Thursday, April 11, 2013 4:50 AM
>>>> To: Lindenmaier, Goetz
>>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in
>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in
>>>> java_to_interp stub.]
>>>>
>>>>
>>>> On Apr 9, 2013, at 7:35 AM, "Lindenmaier, Goetz"
>>>>  wrote:
>>>>
>>>>> Hi Chris,
>>>>>
>>>>> I'm now working on this issue.  Sorry for the delay...
>>>>>
>>>>> What do you think about moving
>>>>>     void emit_java_to_interp(CodeBuffer& cbuf);
>>>>> and
>>>>>    void size_java_to_interp();
>>>>> to compiledIC.hpp and the new platform file, too?
>>>> I like that.
>>>>
>>>>> This would also allow to overcome the ugly
>>>>>    extern uint size_java_to_interp();
>>>>> in output.cpp, as it could be replaced by
>>>>> CompiledStaticCall::size_java_to_interp().
>>>> Great.
>>>>
>>>>> I also would like to name this
>>>>> CompiledStaticCall::emit_to_interp_stub()
>>>>> CompiledStaticCall::to_interp_stub_size()
>>>> I'm okay with that.  Not sure if others have objections.
>>>>
>>>>> I could also extract code from enc_class Java_Static_Call
>>>>> to form a routine
>>>>> CompiledStaticCall::emit_call(CodeBuffer *cbuf, intptr_t
>>>>> entry_point, relocInfo::relocType rtype) {
>>>>>     emit_call_reloc(cbuf, entry_point, rtype)
>>>>>     if (rtype != relocInfo::runtime_call_type) {
>>>>>         emit_java_to_interp(cbuf);
>>>>>       }
>>>>> }
>>>>> With this, also
>>>>> extern uint reloc_java_to_interp();
>>>>> from output.cpp could be moved into this class.
>>>> On SPARC only or the other architectures as well?
>>>>
>>>>> Then handling of CompiledStaticCalls would be completely
>>>>> implemented in this
>>>>> one class.
>>>> That's tempting.
>>>>
>>>>> (I would have to move emit_call_reloc to MacroAssembler.)
>>>> Could you send a webrev with these changes?
>>>>
>>>> -- Chris
>>>>
>>>>> Best regards,
>>>>> Goetz.
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>> Sent: Montag, 25. M?rz 2013 23:29
>>>>> To: Lindenmaier, Goetz
>>>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in
>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in
>>>>> java_to_interp stub.]
>>>>>
>>>>>
>>>>> On Mar 4, 2013, at 8:34 AM, "Lindenmaier, Goetz"
>>>>>  wrote:
>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> I would like to take up this issue again.
>>>>>> I'm about to put our changes on the jdk8 branch, and it would be
>>>>>> convenient
>>>>>> to have a final solution for this.
>>>>>>
>>>>>> Should I prepare a webrev with a different solution adding a new file
>>>>>> for this?  What should go into that file?
>>>>> Sorry for answering that late.
>>>>>
>>>>> Yes, to see a patch for that would be good.  We need to put all
>>>>> platform dependent Compiled* methods in that new file. Platform
>>>>> dependent means every method that uses a native* method from
>>>>> nativeInst_:
>>>>>
>>>>> CompiledIC::cleanup_call_site
>>>>> CompiledIC::is_icholder_call_site
>>>>> CompiledIC::CompiledIC
>>>>>
>>>>> CompiledStaticCall::set_to_interpreted
>>>>> CompiledStaticCall::set_stub_to_clean
>>>>> CompiledStaticCall::verify
>>>>>
>>>>> -- Chris
>>>>>
>>>>>> Best regards,
>>>>>> Goetz.
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: goetz.lindenmaier at sap.com
>>>>>> Sent: Dienstag, 18. Dezember 2012 10:42
>>>>>> To: 'Christian Thalinger'
>>>>>> Subject: RE: RFR (S): 8003853: specify offset of IC load in
>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load
>>>>>> in java_to_interp stub.]
>>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> What would you put into that file?  The offset, or the class
>>>>>> CompiledStaticCall?
>>>>>> You could also put it into nativeInst_  to avoid adding
>>>>>> another file.
>>>>>>
>>>>>> But basically I think the offset is the best solution, because
>>>>>> it's very small
>>>>>> and straight forward, and the offset is set where the code is
>>>>>> generated
>>>>>> that defines the offset.
>>>>>>
>>>>>> Only the #ifndef COMPILER2 is ugly, but here I think the solution
>>>>>> is to
>>>>>> guard the whole class CompiledStaticCall with #ifdef COMPILER2.
>>>>>>
>>>>>> But I'm happy with any placement of the code.
>>>>>>
>>>>>> Best regards,
>>>>>> Goetz.
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>> Sent: Montag, 17. Dezember 2012 21:34
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in
>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load
>>>>>> in java_to_interp stub.]
>>>>>>
>>>>>>
>>>>>> On Nov 29, 2012, at 2:10 PM, "Lindenmaier, Goetz"
>>>>>>  wrote:
>>>>>>
>>>>>>> Hi Chris,
>>>>>>>
>>>>>>> Loading the constant takes 5 instructions, the other way only three,
>>>>>>> in the code only one, if the constant pool base is in a register.
>>>>>>> The 5 instructions are hard to patch atomically.  The constant pool
>>>>>>> is just a 64 bit store.
>>>>>>>
>>>>>>>> Sorry for being so persistent on this :-)
>>>>>>> That's ok, I already found several places in our VM where it was
>>>>>>> easy to
>>>>>>> change our code to get along without the shared changes we did in
>>>>>>> first place.  But I can't redesign everything, and I can not risk
>>>>>>> to break
>>>>>>> anything in our product.
>>>>>>>
>>>>>>> If you feel like doing so, you can have a look at
>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/600ce596eea9
>>>>>>>
>>>>>>> which contains our bytecode interpreter profiling implementation.
>>>>>>> If you think this is currently of use in the main branch, I would
>>>>>>> lift it to HS25
>>>>>>> (the permgen changes might cause trouble) and contribute it to hsx.
>>>>>> Sorry for the long delay.
>>>>>>
>>>>>> Thinking about this problem again it seems that the correct
>>>>>> solution would be to have a compiledIC_.cpp file.
>>>>>>
>>>>>> The CompiledIC instruction layout is platform dependent; it just
>>>>>> happens to be the same for all architectures we have right now
>>>>>> (well, except PPC) because we made it to be the same.  Actually on
>>>>>> SPARC we could also use a load from the constant table which would
>>>>>> be simpler.
>>>>>>
>>>>>> Having a platform dependent file for this code feels right.  What
>>>>>> do you think?
>>>>>>
>>>>>> -- Chris
>>>>>>
>>>>>>> Best regards,
>>>>>>> Goetz.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>> Sent: Thursday, November 29, 2012 7:53 PM
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in
>>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load
>>>>>>> in java_to_interp stub.]
>>>>>>>
>>>>>>>
>>>>>>> On Nov 29, 2012, at 12:27 AM, "Lindenmaier, Goetz"
>>>>>>>  wrote:
>>>>>>>
>>>>>>>> Hi Chris,
>>>>>>>>
>>>>>>>>> Why can't you point the relocation to the method load
>>>>>>>>> instruction?  It doesn't seem right to do that in shared code.
>>>>>>>> Because the relocation is used
>>>>>>>> 1.) to find the beginning of the stub to patch the call to go there
>>>>>>>> 2.) to find the load to patch the IC.
>>>>>>> Got it.
>>>>>>>
>>>>>>>> Just have a look at CompiledStaticCall::set_to_interpreted(),
>>>>>>>> the variable 'stub' is used twice.
>>>>>>> Sorry for being so persistent on this :-)  What is the reason you
>>>>>>> have to load the constant from the constant table?  On other
>>>>>>> architectures we materialize the constant.
>>>>>>>
>>>>>>> -- Chris
>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Goetz.
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>>> Sent: Donnerstag, 29. November 2012 01:35
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in
>>>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load
>>>>>>>> in java_to_interp stub.]
>>>>>>>>
>>>>>>>>
>>>>>>>> On Nov 27, 2012, at 4:24 AM, "Lindenmaier, Goetz"
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>> Hi Chris,
>>>>>>>>>
>>>>>>>>>> Why do you need all these shared code changes when you have
>>>>>>>>>> this in emit_java_to_interp_stub?
>>>>>>>>> Shared code (class CompiledStaticCall) wants to patch the
>>>>>>>>> inline cache
>>>>>>>>> in the stub which is emitted in platform code.
>>>>>>>>> So the platform code should specify how the shared code can
>>>>>>>>> find the inline cache
>>>>>>>>> in the stub, which it does through the constant I introduced.
>>>>>>>>>
>>>>>>>>>> Do you need two relocations?  I'm confused.
>>>>>>>>> No, three ;)
>>>>>>>>> The relocation you mention is used to find the stub given the
>>>>>>>>> call.
>>>>>>>>> The other relocations are needed to find the inline cache /
>>>>>>>>> call target
>>>>>>>>> once the stub is found (see
>>>>>>>>> CompiledStaticCall::set_to_interpreted()).
>>>>>>>>> It's just the same on x86_64:
>>>>>>>>>
>>>>>>>>> // static stub relocation stores the instruction address of the
>>>>>>>>> call
>>>>>>>>> __ relocate(static_stub_Relocation::spec(mark), RELOC_IMM64);
>>>>>>>>> // static stub relocation also tags the methodOop in the
>>>>>>>>> code-stream.
>>>>>>>>> __ movoop(rbx, (jobject) NULL);  // method is zapped till fixup
>>>>>>>>> time
>>>>>>>>> // This is recognized as unresolved by relocs/nativeinst/ic code
>>>>>>>>> __ jump(RuntimeAddress(__ pc()));
>>>>>>>>>
>>>>>>>>> On PPC, we have to load the base of the constant table after
>>>>>>>>> generating the
>>>>>>>>> static_stub_relocation and before emitting the ppc equivalent
>>>>>>>>> for moveoop(). This offset is
>>>>>>>>> exactly what we store in the
>>>>>>>>> CompiledStaticCall::comp_to_int_load_offset constant.
>>>>>>>> Why can't you point the relocation to the method load
>>>>>>>> instruction?  It doesn't seem right to do that in shared code.
>>>>>>>>
>>>>>>>> -- Chris
>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Goetz.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>>>> Sent: Dienstag, 27. November 2012 01:53
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in
>>>>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC
>>>>>>>>> load in java_to_interp stub.]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz"
>>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>>> Hi Chris,
>>>>>>>>>>
>>>>>>>>>> We put it into the ad file because it describes an offset into
>>>>>>>>>> the stub that is
>>>>>>>>>> generated from the ad file by emit_java_to_interp(CodeBuffer&
>>>>>>>>>> cbuf),
>>>>>>>>>> used by ir  node CallStaticJavaDirect.  Maybe I should not
>>>>>>>>>> call it stub, but it's
>>>>>>>>>> generated into the stubs section of the code buffer.
>>>>>>>>>> If that stub generator is moved out of the ad file to shared
>>>>>>>>>> compiler code, one should
>>>>>>>>>> move the field with it, but for the current implementation I
>>>>>>>>>> think that's fine.
>>>>>>>>>>
>>>>>>>>>> Does C1 generate the same stub? Or is the CompiledStaticCall a
>>>>>>>>>> C2 feature?
>>>>>>>>>> If so, one could protect the whole thing by #ifdef COMPILER2.
>>>>>>>>> Why do you need all these shared code changes when you have
>>>>>>>>> this in emit_java_to_interp_stub?
>>>>>>>>>
>>>>>>>>> // Create a static stub relocation which relates this stub
>>>>>>>>> // with the call instruction at insts_call_instruction_offset
>>>>>>>>> in the
>>>>>>>>> // instructions code-section.
>>>>>>>>> __ relocate(static_stub_Relocation::spec(__
>>>>>>>>> code()->insts()->start() + insts_relocation_offset));
>>>>>>>>>
>>>>>>>>> Do you need two relocations?  I'm confused.
>>>>>>>>>
>>>>>>>>> -- Chris
>>>>>>>>>
>>>>>>>>>> Thanks for all the bugids!
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Goetz.
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>>>>> Sent: Mittwoch, 21. November 2012 19:53
>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>>> Subject: RFR (S): 8003853: specify offset of IC load in
>>>>>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC
>>>>>>>>>> load in java_to_interp stub.]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz"
>>>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Chris,
>>>>>>>>>>>
>>>>>>>>>>> yes, there is no C1 on ppc.
>>>>>>>>>>> We do tiered compilation with a stripped C2.
>>>>>>>>>> Right.  But some other architecture (or in the future) might
>>>>>>>>>> need this for C1 as well.  We should find a better place for
>>>>>>>>>> the value than the ad file.  The obvious place would be
>>>>>>>>>> compiledIC_.hpp but we don't have that file, yet.
>>>>>>>>>>
>>>>>>>>>> I filed:
>>>>>>>>>>
>>>>>>>>>> 8003853: specify offset of IC load in java_to_interp stub
>>>>>>>>>>
>>>>>>>>>> -- Chris
>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Goetz
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Christian Thalinger
>>>>>>>>>>> [mailto:christian.thalinger at oracle.com]
>>>>>>>>>>> Sent: Dienstag, 20. November 2012 22:19
>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>>>> Subject: Re: RFR (S): Specify offset of IC load in
>>>>>>>>>>> java_to_interp stub.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz"
>>>>>>>>>>>  wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> The class CompiledStaticCall must know the location of the
>>>>>>>>>>>> IC load in the java_to_interp stub
>>>>>>>>>>>> to update the IC  with NativeMovConstReg.  The current
>>>>>>>>>>>> implementation assumes that
>>>>>>>>>>>> the load is always the first instruction in the stub.  This
>>>>>>>>>>>> is an artificial restriction. E.g.,
>>>>>>>>>>>> it might be useful to load the constant pool address
>>>>>>>>>>>> (MachConstantBase) before the
>>>>>>>>>>>> IC load (as we do on PPC).
>>>>>>>>>>>>
>>>>>>>>>>>> This change adds a constant specifying an offset from the
>>>>>>>>>>>> beginning of the stub to
>>>>>>>>>>>> the  IC load. The offset is platform specific and 0 on sparc
>>>>>>>>>>>> and x86.
>>>>>>>>>>>>
>>>>>>>>>>>> You can find the change here:
>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/
>>>>>>>>>>> That should be fixed indeed.
>>>>>>>>>>>
>>>>>>>>>>> +#ifndef COMPILER2
>>>>>>>>>>> +const int CompiledStaticCall::comp_to_int_load_offset = 0;
>>>>>>>>>>>
>>>>>>>>>>> There is no C1 for PPC (sorry, I didn't check)?
>>>>>>>>>>>
>>>>>>>>>>> -- Chris
>>>>>>>>>>>
>>>>>>>>>>>> or in our ppc port:
>>>>>>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you and best regards,
>>>>>>>>>>>> Goetz
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>


From duboscq at ssw.jku.at  Tue Apr 16 09:30:01 2013
From: duboscq at ssw.jku.at (Gilles Duboscq)
Date: Tue, 16 Apr 2013 18:30:01 +0200
Subject: RFR(XS): 8012292: optimized build with GCC broken
In-Reply-To: <9A5E5A4F-F829-40C8-BF08-AFDC90C1E51C@oracle.com>
References: <9A5E5A4F-F829-40C8-BF08-AFDC90C1E51C@oracle.com>
Message-ID: 

s/grub/gdub


On Tue, Apr 16, 2013 at 6:17 PM, Roland Westrelin <
roland.westrelin at oracle.com> wrote:

> http://cr.openjdk.java.net/~roland/8012292/webrev.00/
>
> Contributed by Gilles Duboscq (openjdk: grub).
>
> Roland.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130416/78da1e5f/attachment.html 

From nils.eliasson at oracle.com  Tue Apr 16 09:32:39 2013
From: nils.eliasson at oracle.com (nils.eliasson at oracle.com)
Date: Tue, 16 Apr 2013 16:32:39 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets
Message-ID: <20130416163245.9BF1B4833B@hg.openjdk.java.net>

Changeset: 8373c19be854
Author:    neliasso
Date:      2013-04-16 10:08 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8373c19be854

8011621: live_ranges_in_separate_class.patch
Reviewed-by: kvn, roland
Contributed-by: niclas.adlertz at oracle.com

! make/bsd/makefiles/vm.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/vm.make
! make/windows/create_obj_files.sh
- src/os/bsd/vm/chaitin_bsd.cpp
- src/os/linux/vm/chaitin_linux.cpp
- src/os/solaris/vm/chaitin_solaris.cpp
- src/os/windows/vm/chaitin_windows.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/chaitin.hpp
! src/share/vm/opto/coalesce.cpp
! src/share/vm/opto/coalesce.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/idealGraphPrinter.cpp
! src/share/vm/opto/ifg.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/live.hpp
! src/share/vm/opto/postaloc.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/opto/regalloc.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: c89eab0b6b30
Author:    neliasso
Date:      2013-04-16 10:37 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c89eab0b6b30

Merge

- src/os/bsd/vm/chaitin_bsd.cpp
- src/os/linux/vm/chaitin_linux.cpp
- src/os/solaris/vm/chaitin_solaris.cpp
- src/os/windows/vm/chaitin_windows.cpp


From vladimir.kozlov at oracle.com  Tue Apr 16 09:39:37 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 16 Apr 2013 09:39:37 -0700
Subject: RFR(XS): 8012292: optimized build with GCC broken
In-Reply-To: <9A5E5A4F-F829-40C8-BF08-AFDC90C1E51C@oracle.com>
References: <9A5E5A4F-F829-40C8-BF08-AFDC90C1E51C@oracle.com>
Message-ID: <516D7EC9.6090102@oracle.com>

Looks good. May be it is time to add optimized build (only build and no 
testing) as JPRT build targets on systems which are not bottlenecks.

Thanks,
Vladimir

On 4/16/13 9:17 AM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8012292/webrev.00/
>
> Contributed by Gilles Duboscq (openjdk: grub).
>
> Roland.
>

From christian.thalinger at oracle.com  Tue Apr 16 10:47:09 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 16 Apr 2013 10:47:09 -0700
Subject: RFR(XS): 8012292: optimized build with GCC broken
In-Reply-To: <9A5E5A4F-F829-40C8-BF08-AFDC90C1E51C@oracle.com>
References: <9A5E5A4F-F829-40C8-BF08-AFDC90C1E51C@oracle.com>
Message-ID: <8C39F4F8-BC46-4A0C-9166-337EC3372E8B@oracle.com>

Looks good.  I had the same patch ;-)  -- Chris

On Apr 16, 2013, at 9:17 AM, Roland Westrelin  wrote:

> http://cr.openjdk.java.net/~roland/8012292/webrev.00/
> 
> Contributed by Gilles Duboscq (openjdk: grub).
> 
> Roland.


From vladimir.kozlov at oracle.com  Tue Apr 16 10:55:26 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 16 Apr 2013 10:55:26 -0700
Subject: RFR(S) : 8011675: adding compilation level to replay data
In-Reply-To: <516D76F4.9010305@oracle.com>
References: <51631AEA.9080702@oracle.com> <51635E89.30808@oracle.com>
	<5163BD9A.5080308@oracle.com> <5163C5F4.7020605@oracle.com>
	<516827EA.3040001@oracle.com> <5168874B.9080407@oracle.com>
	<5169AEA2.7060103@oracle.com> <516C7287.8070600@oracle.com>
	<516D76F4.9010305@oracle.com>
Message-ID: <516D908E.9070408@oracle.com>

Sorry, I notice only now that next tests will fail because there is no 
Tiered in Client VM and not because there is a problem in Replay code. 
So it does not test Replay code:

TestVM_no_comp_level.sh:

   61     negative_test 10 -XX:-TieredCompilation -client
   62     negative_test 11 -XX:+TieredCompilation -client

common.sh:

  107         negative_test $1 -XX:-TieredCompilation -client
  108         negative_test `expr $1 + 1` -XX:+TieredCompilation -client

Also instead of number for error code can you use messages? It will be 
very difficult to trace which test failed by number especially since you 
use expressions for it.

On 4/16/13 9:06 AM, Igor Ignatyev wrote:
>  > Okay. Please, test it: generate replay.txt with C1 without recording
>  > comp_level (old style) and then try to replay it with new code.
> 'TestVM_no_comp_level.sh' emulates old style of replay data.

Okay.

>
>  >>> Add tests for tiered with different -XX:TieredStopAtLevel=n.
>  >> what exactly did you mean?
>  >> 1) generate replay.txt by VM with different value of
> 'TieredStopAtLevel'
>  >> 2) use different 'TieredStopAtLevel' during replay of compilation
>  >
>  > I meant 1). VM could crash at any level of compilation because they are
>  > different so we need to be able replay all of them. So I want to verify
>  > that it works (positive tests).
> block 'if [ $is_tiered -eq 1 ]' was added to TestVM.sh

Thanks.

>
>> Run in JPRT to verify that tests work on all platforms.
> There are some failures in TestSA.sh due to known bugs in SA
> (JDK-8011888, JDK-6326653) and environment/infra issue on macosx (core
> wasn't generated because '/cores' directory doesn't exist or isn't
> writable by current user[1]).

We should disable core files generation and tests on Mac OS. The Nightly 
should be clean.

Thanks,
Vladimir

>
> updated webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.04/
>
> [1]
> http://developer.apple.com/library/mac/technotes/tn2124/_index.html#//apple_ref/doc/uid/DTS10003391-CH1-SECCOREDUMPS
>
>
> Best regards,
> Igor Ignatyev
>
> On 04/16/2013 01:35 AM, Vladimir Kozlov wrote:
>> On 4/13/13 12:14 PM, Igor Ignatyev wrote:
>>>> If you replaying C1 compilation next setting will be incorrect. Should
>>>> we use CompLevel_highest_tier instead so that following check pass?:
>>>>
>>>> +     if (had_error() && (error_message() == comp_level_label)) {
>>>> +       comp_level = CompLevel_full_optimization;
>>>>
>>>
>>> i added this code for compatible with old version and i think that it
>>> must has the same behavior (use 'CompLevel_full_optimization'). in new
>>> version we always will have comp_level in replay.txt.
>>> so i think we shouldn't use CompLevel_highest_tier.
>>
>> Okay. Please, test it: generate replay.txt with C1 without recording
>> comp_level (old style) and then try to replay it with new code.
>>
>>>
>>>> Add tests for tiered with different -XX:TieredStopAtLevel=n.
>>> what exactly did you mean?
>>> 1) generate replay.txt by VM with different value of 'TieredStopAtLevel'
>>> 2) use different 'TieredStopAtLevel' during replay of compilation
>>
>> I meant 1). VM could crash at any level of compilation because they are
>> different so we need to be able replay all of them. So I want to verify
>> that it works (positive tests).
>>
>>>
>>> if 1st, i don't think that test must to iterate through all possible
>>> values, it must be done by harness, test execution etc
>>
>> I agree with you but, unfortunately, we are short on testing hardware to
>> add an other testing variation. You should know. So adding this testing
>> here when tiered VM is tested will help us now.
>>
>>> if 2nd, current implementation of ciReplay ignore TieredStopAtLevel
>>> flags, so these tests will be useless.
>>>
>>>> You may still not find core file. Or ulimit -c unlimited will not work
>>>> (windows, OS X?). You need to bailout in such case as success.
>>> for windows i added '-XX:+CreateMinidumpOnCrash', but whatever case of
>>> not found core-file need to treat as a environment issue, a test bug or
>>> may even be a product bug. anyway if it happened, i think it would be
>>> better to know about this than just skip the test.
>>>
>>> i updated webrev according to the rest of your suggestions, but i'm not
>>> sure about flags to limit core size.
>>
>> Run in JPRT to verify that tests work on all platforms.
>>
>>>
>>> also i added one more check of comp_level and moved validation to
>>> separate method.
>>
>> OK.
>>
>> Thanks,
>> Vladimir
>>
>>>
>>> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.03/
>>>
>>> Best regards,
>>> Igor Ignatyev
>>>
>>> On 04/13/2013 02:14 AM, Vladimir Kozlov wrote:
>>>> I would set CrashAfterCompileId default to -1 as indication it is not
>>>> set. Then you don't need to check CrashAfterCompileId == 0 since
>>>> compile_id is positive. By the way, it is very nice idea but add a
>>>> comment about what that code for. I did not get it first :)
>>>>
>>>> About name. For such flags we use CI: CIBreakAt, CIStop. So I would
>>>> suggest to use CICrashAt. Which means VM crash with that compile id,
>>>> not
>>>> when it is greater.
>>>>
>>>> If you replaying C1 compilation next setting will be incorrect. Should
>>>> we use CompLevel_highest_tier instead so that following check pass?:
>>>>
>>>> +     if (had_error() && (error_message() == comp_level_label)) {
>>>> +       comp_level = CompLevel_full_optimization;
>>>>
>>>>
>>>> About tests.
>>>>
>>>> Add -Xmx32m, -XX:ParallelGCThreads=2 and other flags (codecache
>>>> ,metaspace) to limit core size on big machines.
>>>>
>>>> Add tests for tiered with different -XX:TieredStopAtLevel=n.
>>>>
>>>> I would add more info in output why the test is skipped:
>>>>       echo TEST SKIPPED
>>>>
>>>> typo 'java':
>>>>   124 is_tiered=`${JAVA} ${TESTVMOPTS} java -XX:+PrintFlagsFinal
>>>> -version 2>&1 | grep TieredCompilation | grep -c true`
>>>>
>>>>
>>>> I don't like next:
>>>>
>>>>   130 ${JAVA} ${TESTVMOPTS} -Xcomp -XX:CrashAfterCompileId=1
>>>> -XX:+CreateMinidumpOnCrash -XX:+DumpReplayDataOnError -version &
>>>>   131 crash_pid=$!
>>>>   132 wait $crash_pid
>>>>
>>>>   On windows 'wait $crash_pid' may not work (happened before) because
>>>> before you execute 'wait' OS may assign the same pid to different
>>>> process.
>>>>
>>>> You may still not find core file. Or ulimit -c unlimited will not work
>>>> (windows, OS X?). You need to bailout in such case as success. Next
>>>> code
>>>> is incorrect for that:
>>>>
>>>>    48 if [ -z "${core_file}" -o ! -r "${core_file}" ]
>>>>    49 then
>>>>    50     echo TEST FAILED: core wasn\'t generated
>>>>    51     exit 2
>>>>    52 fi
>>>>
>>>> Thanks
>>>> Vladimir
>>>>
>>>> On 4/12/13 8:27 AM, Igor Ignatyev wrote:
>>>>> updated webrev:
>>>>> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.02/
>>>>> added:
>>>>>    1. more informative message on unsupported comp_level
>>>>>    2. not-product flag 'CrashAfterCompileId' and assert in
>>>>> compileBroker.cpp for assured generation of replay.txt
>>>>>    2. tests for ciReplay
>>>>>
>>>>> Best regards,
>>>>> Igor Ignatyev
>>>>>
>>>>> On 04/09/2013 11:40 AM, Vladimir Kozlov wrote:
>>>>>> Igor,
>>>>>>
>>>>>> Sorry, I may said it not clear. What I meant is to set error (call
>>>>>> report_error()) in such case and return from process_compile()
>>>>>> without
>>>>>> compilation. But let ciReplay::replay() finish and exit.
>>>>>> replay_impl()
>>>>>> should print the problem so you don't need to do it in
>>>>>> process_compile(). And, please, test it.
>>>>>> The message should be more informative, something like:
>>>>>> "compilation level %d requires TieredCompilation"
>>>>>> An other bad cases is when failure happened in Client (C1) or Server
>>>>>> (C2) but the replay is run with opposite VM.
>>>>>>
>>>>>> thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 4/9/13 12:04 AM, Igor Ignatyev wrote:
>>>>>>> Vladimir,
>>>>>>>
>>>>>>> Thank you for review.
>>>>>>>
>>>>>>> updated webrev:
>>>>>>> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.01/
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Igor Ignatyev
>>>>>>>
>>>>>>> On 04/09/2013 04:19 AM, Vladimir Kozlov wrote:
>>>>>>>> Igor,
>>>>>>>>
>>>>>>>> Thank you for fixing and cleaning this.
>>>>>>>>
>>>>>>>> In vmStructs.cpp move _comp_level after _compile_id as in nmethod
>>>>>>>> class.
>>>>>>>>
>>>>>>>> Typo in ciReplay.cpp:
>>>>>>>> +      comp_level != CompLevel_highest_tier;
>>>>>>>>
>>>>>>>> Actually it is useless to replay compilation at different level, it
>>>>>>>> should exit with error. Could happened because incorrectly run
>>>>>>>> without
>>>>>>>> Tiered when the crush happened with Tiered.
>>>>>>>>
>>>>>>>> In ciReplay.cpp use parenthesis around equality checks: if (. &&
>>>>>>>> (. ==
>>>>>>>> .)).
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Vladimir
>>>>>>>>
>>>>>>>> On 4/8/13 12:30 PM, Igor Ignatyev wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Please review patch.
>>>>>>>>>
>>>>>>>>> Problem:
>>>>>>>>> Replay of compilations supports c1 and tiered as well as c2, the
>>>>>>>>> only
>>>>>>>>> thing missing is comp_level.
>>>>>>>>>
>>>>>>>>> Fix:
>>>>>>>>> 1. added comp_level into dump and usage during replay
>>>>>>>>> 2. minor changes in agent/doc:
>>>>>>>>>    - escaped '<', '>'
>>>>>>>>>    - renamed 'C2 Replay'/'C2 compiler replay' to
>>>>>>>>> 'Replay'/'Compiler
>>>>>>>>> replay'
>>>>>>>>>
>>>>>>>>> Testing:
>>>>>>>>> manually launched the replay from JDK-8010934 (assert
>>>>>>>>> specifically to
>>>>>>>>> c1) on jvm w/o corresponded fix. assert was triggered w/ patch and
>>>>>>>>> wasn't triggered w/o.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.00/
>>>>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011675

From nils.eliasson at oracle.com  Tue Apr 16 11:18:40 2013
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Tue, 16 Apr 2013 20:18:40 +0200
Subject: RFR (M): 8006952: Slow VM due to excessive code cache freelist
	iteration
In-Reply-To: <516D67A1.1060002@oracle.com>
References: <5107AADF.6010501@oracle.com> <51082499.3000905@oracle.com>
	<51093FAC.6090803@oracle.com> <51097FA6.3050709@oracle.com>
	<510ABAB9.8020909@oracle.com>
	<15E6C57378C5FE43AD074594DD824E501C8AB7E7@DEWDFEMB15A.global.corp.sap>
	<511511A5.8050101@oracle.com> <5167DFC2.6020007@oracle.com>
	<51684283.7010304@oracle.com> <516BD82A.7050302@oracle.com>
	<516D24FE.1090105@oracle.com> <516D67A1.1060002@oracle.com>
Message-ID: <516D9600.9060208@oracle.com>

Yes.

So its pretty much like it was before:

1) Try to allocate from the free list using best fit
2) Allocate a new chunk from the code cache heap (always increasing, 
reclaimed memory always goes to the free list)

With the addition that for both 1 and 2, stubs and adapters have a 
strict monopoly on the last 500k of address space. But they are 
themselves free to be placed wherever possible, and will essentially 
only use the last part as a last resort.

I belive this will allow us to decrease the CodeCacheMinimumThreshold 
since we now have strong guarantees that nmethods will not eat up or 
fragment the last part. But that is for another change.

Thanks for your time!
//Nils




On 2013-04-16 17:00, Vladimir Kozlov wrote:
> Looks good.
>
> Do I understand correctly that now we bailout from in compileBroker 
> conservatively if no enough space at the end of code cache? But in a 
> middle we could have a big free block. Right?
>
> Thanks,
> Vladimir
>
> On 4/16/13 3:16 AM, Nils Eliasson wrote:
>> Latest webrev: http://cr.openjdk.java.net/~neliasso/8006952/webrev.09/
>> 
>>
>> Updates after comments from Vladimir K. and Niclas.
>>
>> - Removed 'red_zone' naming and refined comments
>> - Refined naming in heap.cpp/hpp on conversion methods
>> size(...)/number_of_segments(...) to
>> size_to_segments(...)/segments_to_size(...)
>> - Bool flags as verbs (critical -> is_critical)
>> - Removed get_largest_block() and all its uses.
>>
>> Enjoy!
>>
>> //Nils
>>
>> On 2013-04-15 12:36, Nils Eliasson wrote:
>>>
>>> Hi,
>>>
>>> On 2013-04-12 19:21, Vladimir Kozlov wrote:
>>>> Nils,
>>>>
>>>> It is sad that you have to reverse parfait fix but I agree that your
>>>> changes are more clean.
>>>
>>> Please - don't be! I taken extra precaution and have verified that
>>> there is a null check between the call to new and the constructor.
>>> This is consistent with both the C++ spec and the behaviour we rely on
>>> when running out of code cache. The CodeCache::has_space would have
>>> forced me to do it more complex, it would have to copy/wrap the
>>> heap::allocate algorithm but returning a bool instead of actually
>>> allocating.
>>>
>>> Sorry for forgetting to add it to the change log in my request. I did
>>> not intend to revert it without being open about it.
>>>
>>> I don't understand why Parfait is confused about 'this' being null in
>>> the constructor. I will open a bug on Parfait if I can find where to
>>> submit it.
>>>
>>>>
>>>> After these changes largest_free_block() is used only in statistics
>>>> output which is useless since it is not participating in codecache
>>>> allocations.  May be we should remove it and use
>>>> heap_unallocated_capacity() instead (do we need lock then?):
>>>
>>> Yes, good idea. Must check that I don't break any log tool if I change
>>> the output though.
>>>
>>>>
>>>> size_t CodeCache::largest_free_block() {
>>>>   return _heap->heap_unallocated_capacity();
>>>> }
>>>>
>>>> Also red_zone_start() is confusing because it does not show how it is
>>>> related to heap_unallocated_capacity(). In one place you use one:
>>>>
>>>>  211     if (size(length) > (heap_unallocated_capacity() -
>>>> CodeCacheMinimumFreeSpace)) {
>>>>
>>>> and in an other use second:
>>>>
>>>>  437     if (((size_t)cur + length) >= (size_t)red_zone_start()) {
>>>>
>>>> Can we just use only heap_unallocated_capacity()?
>>>
>>> I agree that it is confusing. The background is that they serve a bit
>>> different purpose. In one case we are allocating from the freelist and
>>> need to check against the adress where the 'red zone/critical
>>> allocation area begins.' In the other it is a block allocation from
>>> the contiguous heap where we know heap_unallocated_capacity is the
>>> size of the block at the end of the heap. I'll come up with something
>>> better.
>>>
>>> Thanks for taking your time!
>>> //Nils
>>>
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 4/12/13 3:19 AM, Nils Eliasson wrote:
>>>>> I have now incorporated both Vladimirs and Andreas suggestion:
>>>>>
>>>>> Changes to previous revision includes:
>>>>> 1) Updated the checks in both heap::allocate and 
>>>>> heap::search_freelist
>>>>> so that non critical allocation never stride into the
>>>>> CodeCacheMinimumFreeSpace.
>>>>> 2) Inverted the critical condition - now all allocations default 
>>>>> to not
>>>>> critical. Only the places where we would go fatal if the allocation
>>>>> returns null are critical.
>>>>> 3) Refactored some names and removed duplicate methods in heap.cpp.
>>>>>
>>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.08/
>>>>> 
>>>>>
>>>>> This changes also opens up for decreasing the 
>>>>> CodeCacheMinimumFreeSpace
>>>>> since we now guarantee that only critical allocation will end up 
>>>>> there.
>>>>> And they will not grow to 500K when compilation have stopped anyways.
>>>>>
>>>>> Kind regards,
>>>>> //Nils
>>>>>
>>>>>
>>>>> On 2013-02-08 15:54, Nils Eliasson wrote:
>>>>>> Vladimir and Andreas, thanks for your feedback! I am considering 
>>>>>> your
>>>>>> suggestions.
>>>>>>
>>>>>> My fix is a step in the right direction but I realize it is not
>>>>>> enough.
>>>>>>
>>>>>> Initially, it works good reserving the last part of the heap block.
>>>>>> But if the application has a bigger active code footprint that what
>>>>>> can fit in the code cache, there will be new flushes that will
>>>>>> increase fragmentation and slowly reduce the usable part of the code
>>>>>> cache. So I will add functionality for backing off.
>>>>>>
>>>>>> //Nils
>>>>>>
>>>>>> Schoesser, Andreas skrev 2013-02-01 10:58:
>>>>>>> Hi Nils,
>>>>>>>
>>>>>>> this is IMO a good idea since we experienced the same problem with
>>>>>>> one of our ports. I think in our case it was not the nmethod 
>>>>>>> sweeper
>>>>>>> continuously running (there's MinCodeCacheFlushingInterval to only
>>>>>>> speculatively disconnect nmethods every 30 seconds) but from the
>>>>>>> compiler loop constantly polling the freelist without the nmethod
>>>>>>> sweeper making any progress.
>>>>>>>
>>>>>>> You also might consider to propagate the "critical" flag down to
>>>>>>> search_freelist(). Then, a simple address compare would do to keep
>>>>>>> the end of the code cache free from nmethods:
>>>>>>> - For non-critical blobs, search_freelist() may only fit free 
>>>>>>> blocks
>>>>>>> < CodeCache::end() - CodeCacheMinimumFreeSpace
>>>>>>> - For critical blocks, search_freelist() may fit all free blocks
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Andreas
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: hotspot-compiler-dev-bounces at openjdk.java.net
>>>>>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of
>>>>>>> Nils Eliasson
>>>>>>> Sent: Donnerstag, 31. Januar 2013 19:41
>>>>>>> To: hotspot-compiler-dev at openjdk.java.net
>>>>>>> Subject: Re: RFR (M): 8006952: Slow VM due to excessive code cache
>>>>>>> freelist iteration
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.04/
>>>>>>>
>>>>>>> //N
>>>>>>>
>>>>>>> Vladimir Kozlov skrev 2013-01-30 21:16:
>>>>>>>> Nils, you sent webrev for other bug fix.
>>>>>>>>
>>>>>>>> Vladimir
>>>>>>>>
>>>>>>>> On 1/30/13 7:43 AM, Nils Eliasson wrote:
>>>>>>>>> Thanks for the link, interesting background.
>>>>>>>>>
>>>>>>>>> Even if finding the largest block on the freelist is free, we 
>>>>>>>>> would
>>>>>>>>> still have a misbehavior when the free heap block is less than 
>>>>>>>>> 1,5M
>>>>>>>>> and
>>>>>>>>> the flushing begins to create a 1,5M freelist block.
>>>>>>>>>
>>>>>>>>> Unallocated memory is a good measurement if have some continuous
>>>>>>>>> memory
>>>>>>>>> in reserve for critical blobs. I am thinking of using the
>>>>>>>>> thresholds
>>>>>>>>> against unallocated memory, but forbidding nmethods from using 
>>>>>>>>> the
>>>>>>>>> last
>>>>>>>>> 0,5M (MinimumFreeSpace) from the heap block. That would prevent
>>>>>>>>> the VM
>>>>>>>>> from fragmenting the last continuous memory space, and allow the
>>>>>>>>> VM to
>>>>>>>>> use all of the freelist.
>>>>>>>>>
>>>>>>>>> Like this:
>>>>>>>>> http://cr.openjdk.java.net/~neliasso/8002364/webrev.03
>>>>>>>>>
>>>>>>>>> //Nils
>>>>>>>>>
>>>>>>>>> Vladimir Kozlov skrev 2013-01-29 20:35:
>>>>>>>>>> Nils,
>>>>>>>>>>
>>>>>>>>>> You are reversing 7025742 fix. I would prefer to keep track of a
>>>>>>>>>> largest free block during allocation in CodeCache (by using
>>>>>>>>>> ordered
>>>>>>>>>> list or other technique) to avoid scanning the list.
>>>>>>>>>>
>>>>>>>>>> Vladimir
>>>>>>>>>>
>>>>>>>>>> On 1/29/13 2:56 AM, Nils Eliasson wrote:
>>>>>>>>>>> Remove continuous free block requirement for code cache
>>>>>>>>>>> flushing and
>>>>>>>>>>> minimum free space.
>>>>>>>>>>>
>>>>>>>>>>> This causes a degenerate behavior when the VM are repeatedly
>>>>>>>>>>> flushing
>>>>>>>>>>> the code cache trying to free up a continuous 1,5M block.
>>>>>>>>>>> Since the
>>>>>>>>>>> freelist is fragmented a significant part of the code cache is
>>>>>>>>>>> kept
>>>>>>>>>>> unallocated. A significant amount of time is spent 
>>>>>>>>>>> traversing the
>>>>>>>>>>> freelist holding the code cache lock or waiting for other 
>>>>>>>>>>> threads
>>>>>>>>>>> doing
>>>>>>>>>>> the same.
>>>>>>>>>>>
>>>>>>>>>>> I don't see any reason for why a continuous block is required.
>>>>>>>>>>> Code
>>>>>>>>>>> cache flushing threshold (CodeCacheFlushingMinimumFreeSpace) is
>>>>>>>>>>> default
>>>>>>>>>>> 1,5M and code cache minimum threshold
>>>>>>>>>>> (CodeCacheMinimumFreeSpace) is
>>>>>>>>>>> 0,5M. Finding such a block on the freelist is often 
>>>>>>>>>>> unrealistic,
>>>>>>>>>>> and has
>>>>>>>>>>> not any purpose. The largest nmethods are in the order of
>>>>>>>>>>> 250k, and
>>>>>>>>>>> they
>>>>>>>>>>> are not allocated when code cache is starting to run out. All
>>>>>>>>>>> critical
>>>>>>>>>>> adapters are small and will fit easily in the freelist or in 
>>>>>>>>>>> the
>>>>>>>>>>> remaining heap space.
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.02/
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Nils Eliasson
>>>>>>
>>>>>
>>>
>>


From vladimir.kozlov at oracle.com  Tue Apr 16 11:39:01 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 16 Apr 2013 11:39:01 -0700
Subject: RFR (M): 8006952: Slow VM due to excessive code cache freelist
	iteration
In-Reply-To: <516D9600.9060208@oracle.com>
References: <5107AADF.6010501@oracle.com> <51082499.3000905@oracle.com>
	<51093FAC.6090803@oracle.com> <51097FA6.3050709@oracle.com>
	<510ABAB9.8020909@oracle.com>
	<15E6C57378C5FE43AD074594DD824E501C8AB7E7@DEWDFEMB15A.global.corp.sap>
	<511511A5.8050101@oracle.com> <5167DFC2.6020007@oracle.com>
	<51684283.7010304@oracle.com> <516BD82A.7050302@oracle.com>
	<516D24FE.1090105@oracle.com> <516D67A1.1060002@oracle.com>
	<516D9600.9060208@oracle.com>
Message-ID: <516D9AC5.4060307@oracle.com>

I asked about changes in CompileBroker::compiler_thread_loop():

1584       if (CodeCache::unallocated_capacity() < 
CodeCacheMinimumFreeSpace) {
1585         // the code cache is really full
1586         handle_full_code_cache();

It is executed before we compile a method.

For example, if we have a hot method at the end of codecache which is 
used then the check above will prevent us from compiling any methods 
even when codecache has enough space in the middle (a block on 
free_list). Do I get it right?

Thanks,
Vladimir

On 4/16/13 11:18 AM, Nils Eliasson wrote:
> Yes.
>
> So its pretty much like it was before:
>
> 1) Try to allocate from the free list using best fit
> 2) Allocate a new chunk from the code cache heap (always increasing,
> reclaimed memory always goes to the free list)
>
> With the addition that for both 1 and 2, stubs and adapters have a
> strict monopoly on the last 500k of address space. But they are
> themselves free to be placed wherever possible, and will essentially
> only use the last part as a last resort.
>
> I belive this will allow us to decrease the CodeCacheMinimumThreshold
> since we now have strong guarantees that nmethods will not eat up or
> fragment the last part. But that is for another change.
>
> Thanks for your time!
> //Nils
>
>
>
>
> On 2013-04-16 17:00, Vladimir Kozlov wrote:
>> Looks good.
>>
>> Do I understand correctly that now we bailout from in compileBroker
>> conservatively if no enough space at the end of code cache? But in a
>> middle we could have a big free block. Right?
>>
>> Thanks,
>> Vladimir
>>
>> On 4/16/13 3:16 AM, Nils Eliasson wrote:
>>> Latest webrev: http://cr.openjdk.java.net/~neliasso/8006952/webrev.09/
>>> 
>>>
>>> Updates after comments from Vladimir K. and Niclas.
>>>
>>> - Removed 'red_zone' naming and refined comments
>>> - Refined naming in heap.cpp/hpp on conversion methods
>>> size(...)/number_of_segments(...) to
>>> size_to_segments(...)/segments_to_size(...)
>>> - Bool flags as verbs (critical -> is_critical)
>>> - Removed get_largest_block() and all its uses.
>>>
>>> Enjoy!
>>>
>>> //Nils
>>>
>>> On 2013-04-15 12:36, Nils Eliasson wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 2013-04-12 19:21, Vladimir Kozlov wrote:
>>>>> Nils,
>>>>>
>>>>> It is sad that you have to reverse parfait fix but I agree that your
>>>>> changes are more clean.
>>>>
>>>> Please - don't be! I taken extra precaution and have verified that
>>>> there is a null check between the call to new and the constructor.
>>>> This is consistent with both the C++ spec and the behaviour we rely on
>>>> when running out of code cache. The CodeCache::has_space would have
>>>> forced me to do it more complex, it would have to copy/wrap the
>>>> heap::allocate algorithm but returning a bool instead of actually
>>>> allocating.
>>>>
>>>> Sorry for forgetting to add it to the change log in my request. I did
>>>> not intend to revert it without being open about it.
>>>>
>>>> I don't understand why Parfait is confused about 'this' being null in
>>>> the constructor. I will open a bug on Parfait if I can find where to
>>>> submit it.
>>>>
>>>>>
>>>>> After these changes largest_free_block() is used only in statistics
>>>>> output which is useless since it is not participating in codecache
>>>>> allocations.  May be we should remove it and use
>>>>> heap_unallocated_capacity() instead (do we need lock then?):
>>>>
>>>> Yes, good idea. Must check that I don't break any log tool if I change
>>>> the output though.
>>>>
>>>>>
>>>>> size_t CodeCache::largest_free_block() {
>>>>>   return _heap->heap_unallocated_capacity();
>>>>> }
>>>>>
>>>>> Also red_zone_start() is confusing because it does not show how it is
>>>>> related to heap_unallocated_capacity(). In one place you use one:
>>>>>
>>>>>  211     if (size(length) > (heap_unallocated_capacity() -
>>>>> CodeCacheMinimumFreeSpace)) {
>>>>>
>>>>> and in an other use second:
>>>>>
>>>>>  437     if (((size_t)cur + length) >= (size_t)red_zone_start()) {
>>>>>
>>>>> Can we just use only heap_unallocated_capacity()?
>>>>
>>>> I agree that it is confusing. The background is that they serve a bit
>>>> different purpose. In one case we are allocating from the freelist and
>>>> need to check against the adress where the 'red zone/critical
>>>> allocation area begins.' In the other it is a block allocation from
>>>> the contiguous heap where we know heap_unallocated_capacity is the
>>>> size of the block at the end of the heap. I'll come up with something
>>>> better.
>>>>
>>>> Thanks for taking your time!
>>>> //Nils
>>>>
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 4/12/13 3:19 AM, Nils Eliasson wrote:
>>>>>> I have now incorporated both Vladimirs and Andreas suggestion:
>>>>>>
>>>>>> Changes to previous revision includes:
>>>>>> 1) Updated the checks in both heap::allocate and
>>>>>> heap::search_freelist
>>>>>> so that non critical allocation never stride into the
>>>>>> CodeCacheMinimumFreeSpace.
>>>>>> 2) Inverted the critical condition - now all allocations default
>>>>>> to not
>>>>>> critical. Only the places where we would go fatal if the allocation
>>>>>> returns null are critical.
>>>>>> 3) Refactored some names and removed duplicate methods in heap.cpp.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.08/
>>>>>> 
>>>>>>
>>>>>> This changes also opens up for decreasing the
>>>>>> CodeCacheMinimumFreeSpace
>>>>>> since we now guarantee that only critical allocation will end up
>>>>>> there.
>>>>>> And they will not grow to 500K when compilation have stopped anyways.
>>>>>>
>>>>>> Kind regards,
>>>>>> //Nils
>>>>>>
>>>>>>
>>>>>> On 2013-02-08 15:54, Nils Eliasson wrote:
>>>>>>> Vladimir and Andreas, thanks for your feedback! I am considering
>>>>>>> your
>>>>>>> suggestions.
>>>>>>>
>>>>>>> My fix is a step in the right direction but I realize it is not
>>>>>>> enough.
>>>>>>>
>>>>>>> Initially, it works good reserving the last part of the heap block.
>>>>>>> But if the application has a bigger active code footprint that what
>>>>>>> can fit in the code cache, there will be new flushes that will
>>>>>>> increase fragmentation and slowly reduce the usable part of the code
>>>>>>> cache. So I will add functionality for backing off.
>>>>>>>
>>>>>>> //Nils
>>>>>>>
>>>>>>> Schoesser, Andreas skrev 2013-02-01 10:58:
>>>>>>>> Hi Nils,
>>>>>>>>
>>>>>>>> this is IMO a good idea since we experienced the same problem with
>>>>>>>> one of our ports. I think in our case it was not the nmethod
>>>>>>>> sweeper
>>>>>>>> continuously running (there's MinCodeCacheFlushingInterval to only
>>>>>>>> speculatively disconnect nmethods every 30 seconds) but from the
>>>>>>>> compiler loop constantly polling the freelist without the nmethod
>>>>>>>> sweeper making any progress.
>>>>>>>>
>>>>>>>> You also might consider to propagate the "critical" flag down to
>>>>>>>> search_freelist(). Then, a simple address compare would do to keep
>>>>>>>> the end of the code cache free from nmethods:
>>>>>>>> - For non-critical blobs, search_freelist() may only fit free
>>>>>>>> blocks
>>>>>>>> < CodeCache::end() - CodeCacheMinimumFreeSpace
>>>>>>>> - For critical blocks, search_freelist() may fit all free blocks
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Andreas
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: hotspot-compiler-dev-bounces at openjdk.java.net
>>>>>>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of
>>>>>>>> Nils Eliasson
>>>>>>>> Sent: Donnerstag, 31. Januar 2013 19:41
>>>>>>>> To: hotspot-compiler-dev at openjdk.java.net
>>>>>>>> Subject: Re: RFR (M): 8006952: Slow VM due to excessive code cache
>>>>>>>> freelist iteration
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.04/
>>>>>>>>
>>>>>>>> //N
>>>>>>>>
>>>>>>>> Vladimir Kozlov skrev 2013-01-30 21:16:
>>>>>>>>> Nils, you sent webrev for other bug fix.
>>>>>>>>>
>>>>>>>>> Vladimir
>>>>>>>>>
>>>>>>>>> On 1/30/13 7:43 AM, Nils Eliasson wrote:
>>>>>>>>>> Thanks for the link, interesting background.
>>>>>>>>>>
>>>>>>>>>> Even if finding the largest block on the freelist is free, we
>>>>>>>>>> would
>>>>>>>>>> still have a misbehavior when the free heap block is less than
>>>>>>>>>> 1,5M
>>>>>>>>>> and
>>>>>>>>>> the flushing begins to create a 1,5M freelist block.
>>>>>>>>>>
>>>>>>>>>> Unallocated memory is a good measurement if have some continuous
>>>>>>>>>> memory
>>>>>>>>>> in reserve for critical blobs. I am thinking of using the
>>>>>>>>>> thresholds
>>>>>>>>>> against unallocated memory, but forbidding nmethods from using
>>>>>>>>>> the
>>>>>>>>>> last
>>>>>>>>>> 0,5M (MinimumFreeSpace) from the heap block. That would prevent
>>>>>>>>>> the VM
>>>>>>>>>> from fragmenting the last continuous memory space, and allow the
>>>>>>>>>> VM to
>>>>>>>>>> use all of the freelist.
>>>>>>>>>>
>>>>>>>>>> Like this:
>>>>>>>>>> http://cr.openjdk.java.net/~neliasso/8002364/webrev.03
>>>>>>>>>>
>>>>>>>>>> //Nils
>>>>>>>>>>
>>>>>>>>>> Vladimir Kozlov skrev 2013-01-29 20:35:
>>>>>>>>>>> Nils,
>>>>>>>>>>>
>>>>>>>>>>> You are reversing 7025742 fix. I would prefer to keep track of a
>>>>>>>>>>> largest free block during allocation in CodeCache (by using
>>>>>>>>>>> ordered
>>>>>>>>>>> list or other technique) to avoid scanning the list.
>>>>>>>>>>>
>>>>>>>>>>> Vladimir
>>>>>>>>>>>
>>>>>>>>>>> On 1/29/13 2:56 AM, Nils Eliasson wrote:
>>>>>>>>>>>> Remove continuous free block requirement for code cache
>>>>>>>>>>>> flushing and
>>>>>>>>>>>> minimum free space.
>>>>>>>>>>>>
>>>>>>>>>>>> This causes a degenerate behavior when the VM are repeatedly
>>>>>>>>>>>> flushing
>>>>>>>>>>>> the code cache trying to free up a continuous 1,5M block.
>>>>>>>>>>>> Since the
>>>>>>>>>>>> freelist is fragmented a significant part of the code cache is
>>>>>>>>>>>> kept
>>>>>>>>>>>> unallocated. A significant amount of time is spent
>>>>>>>>>>>> traversing the
>>>>>>>>>>>> freelist holding the code cache lock or waiting for other
>>>>>>>>>>>> threads
>>>>>>>>>>>> doing
>>>>>>>>>>>> the same.
>>>>>>>>>>>>
>>>>>>>>>>>> I don't see any reason for why a continuous block is required.
>>>>>>>>>>>> Code
>>>>>>>>>>>> cache flushing threshold (CodeCacheFlushingMinimumFreeSpace) is
>>>>>>>>>>>> default
>>>>>>>>>>>> 1,5M and code cache minimum threshold
>>>>>>>>>>>> (CodeCacheMinimumFreeSpace) is
>>>>>>>>>>>> 0,5M. Finding such a block on the freelist is often
>>>>>>>>>>>> unrealistic,
>>>>>>>>>>>> and has
>>>>>>>>>>>> not any purpose. The largest nmethods are in the order of
>>>>>>>>>>>> 250k, and
>>>>>>>>>>>> they
>>>>>>>>>>>> are not allocated when code cache is starting to run out. All
>>>>>>>>>>>> critical
>>>>>>>>>>>> adapters are small and will fit easily in the freelist or in
>>>>>>>>>>>> the
>>>>>>>>>>>> remaining heap space.
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.02/
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Nils Eliasson
>>>>>>>
>>>>>>
>>>>
>>>
>

From nils.eliasson at oracle.com  Tue Apr 16 13:44:38 2013
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Tue, 16 Apr 2013 22:44:38 +0200
Subject: RFR (M): 8006952: Slow VM due to excessive code cache freelist
	iteration
In-Reply-To: <516D9AC5.4060307@oracle.com>
References: <5107AADF.6010501@oracle.com> <51082499.3000905@oracle.com>
	<51093FAC.6090803@oracle.com> <51097FA6.3050709@oracle.com>
	<510ABAB9.8020909@oracle.com>
	<15E6C57378C5FE43AD074594DD824E501C8AB7E7@DEWDFEMB15A.global.corp.sap>
	<511511A5.8050101@oracle.com> <5167DFC2.6020007@oracle.com>
	<51684283.7010304@oracle.com> <516BD82A.7050302@oracle.com>
	<516D24FE.1090105@oracle.com> <516D67A1.1060002@oracle.com>
	<516D9600.9060208@oracle.com> <516D9AC5.4060307@oracle.com>
Message-ID: <516DB836.5000401@oracle.com>


On 2013-04-16 20:39, Vladimir Kozlov wrote:
> I asked about changes in CompileBroker::compiler_thread_loop():
>
> 1584       if (CodeCache::unallocated_capacity() < 
> CodeCacheMinimumFreeSpace) {
> 1585         // the code cache is really full
> 1586         handle_full_code_cache();
>
> It is executed before we compile a method.
>
> For example, if we have a hot method at the end of codecache which is 
> used then the check above will prevent us from compiling any methods 
> even when codecache has enough space in the middle (a block on 
> free_list). Do I get it right?

No, the space on the free list is included in 
CodeCache::unallocated_capacity().

But we might have 1500k of really fragmented space on the free list, and 
nothing but the adapter/stub-reserved space in the heap. Then compiles 
will pass the check at 1584 and 1587, but later fail on 
bufferblob/nmethod allocation. But that case is handled by calls too 
handle_full_code_cache() at the allocation sites.

//N

>
> Thanks,
> Vladimir
>
> On 4/16/13 11:18 AM, Nils Eliasson wrote:
>> Yes.
>>
>> So its pretty much like it was before:
>>
>> 1) Try to allocate from the free list using best fit
>> 2) Allocate a new chunk from the code cache heap (always increasing,
>> reclaimed memory always goes to the free list)
>>
>> With the addition that for both 1 and 2, stubs and adapters have a
>> strict monopoly on the last 500k of address space. But they are
>> themselves free to be placed wherever possible, and will essentially
>> only use the last part as a last resort.
>>
>> I belive this will allow us to decrease the CodeCacheMinimumThreshold
>> since we now have strong guarantees that nmethods will not eat up or
>> fragment the last part. But that is for another change.
>>
>> Thanks for your time!
>> //Nils
>>
>>
>>
>>
>> On 2013-04-16 17:00, Vladimir Kozlov wrote:
>>> Looks good.
>>>
>>> Do I understand correctly that now we bailout from in compileBroker
>>> conservatively if no enough space at the end of code cache? But in a
>>> middle we could have a big free block. Right?
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 4/16/13 3:16 AM, Nils Eliasson wrote:
>>>> Latest webrev: http://cr.openjdk.java.net/~neliasso/8006952/webrev.09/
>>>> 
>>>>
>>>> Updates after comments from Vladimir K. and Niclas.
>>>>
>>>> - Removed 'red_zone' naming and refined comments
>>>> - Refined naming in heap.cpp/hpp on conversion methods
>>>> size(...)/number_of_segments(...) to
>>>> size_to_segments(...)/segments_to_size(...)
>>>> - Bool flags as verbs (critical -> is_critical)
>>>> - Removed get_largest_block() and all its uses.
>>>>
>>>> Enjoy!
>>>>
>>>> //Nils
>>>>
>>>> On 2013-04-15 12:36, Nils Eliasson wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 2013-04-12 19:21, Vladimir Kozlov wrote:
>>>>>> Nils,
>>>>>>
>>>>>> It is sad that you have to reverse parfait fix but I agree that your
>>>>>> changes are more clean.
>>>>>
>>>>> Please - don't be! I taken extra precaution and have verified that
>>>>> there is a null check between the call to new and the constructor.
>>>>> This is consistent with both the C++ spec and the behaviour we 
>>>>> rely on
>>>>> when running out of code cache. The CodeCache::has_space would have
>>>>> forced me to do it more complex, it would have to copy/wrap the
>>>>> heap::allocate algorithm but returning a bool instead of actually
>>>>> allocating.
>>>>>
>>>>> Sorry for forgetting to add it to the change log in my request. I did
>>>>> not intend to revert it without being open about it.
>>>>>
>>>>> I don't understand why Parfait is confused about 'this' being null in
>>>>> the constructor. I will open a bug on Parfait if I can find where to
>>>>> submit it.
>>>>>
>>>>>>
>>>>>> After these changes largest_free_block() is used only in statistics
>>>>>> output which is useless since it is not participating in codecache
>>>>>> allocations.  May be we should remove it and use
>>>>>> heap_unallocated_capacity() instead (do we need lock then?):
>>>>>
>>>>> Yes, good idea. Must check that I don't break any log tool if I 
>>>>> change
>>>>> the output though.
>>>>>
>>>>>>
>>>>>> size_t CodeCache::largest_free_block() {
>>>>>>   return _heap->heap_unallocated_capacity();
>>>>>> }
>>>>>>
>>>>>> Also red_zone_start() is confusing because it does not show how 
>>>>>> it is
>>>>>> related to heap_unallocated_capacity(). In one place you use one:
>>>>>>
>>>>>>  211     if (size(length) > (heap_unallocated_capacity() -
>>>>>> CodeCacheMinimumFreeSpace)) {
>>>>>>
>>>>>> and in an other use second:
>>>>>>
>>>>>>  437     if (((size_t)cur + length) >= (size_t)red_zone_start()) {
>>>>>>
>>>>>> Can we just use only heap_unallocated_capacity()?
>>>>>
>>>>> I agree that it is confusing. The background is that they serve a bit
>>>>> different purpose. In one case we are allocating from the freelist 
>>>>> and
>>>>> need to check against the adress where the 'red zone/critical
>>>>> allocation area begins.' In the other it is a block allocation from
>>>>> the contiguous heap where we know heap_unallocated_capacity is the
>>>>> size of the block at the end of the heap. I'll come up with something
>>>>> better.
>>>>>
>>>>> Thanks for taking your time!
>>>>> //Nils
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 4/12/13 3:19 AM, Nils Eliasson wrote:
>>>>>>> I have now incorporated both Vladimirs and Andreas suggestion:
>>>>>>>
>>>>>>> Changes to previous revision includes:
>>>>>>> 1) Updated the checks in both heap::allocate and
>>>>>>> heap::search_freelist
>>>>>>> so that non critical allocation never stride into the
>>>>>>> CodeCacheMinimumFreeSpace.
>>>>>>> 2) Inverted the critical condition - now all allocations default
>>>>>>> to not
>>>>>>> critical. Only the places where we would go fatal if the allocation
>>>>>>> returns null are critical.
>>>>>>> 3) Refactored some names and removed duplicate methods in heap.cpp.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.08/
>>>>>>> 
>>>>>>>
>>>>>>> This changes also opens up for decreasing the
>>>>>>> CodeCacheMinimumFreeSpace
>>>>>>> since we now guarantee that only critical allocation will end up
>>>>>>> there.
>>>>>>> And they will not grow to 500K when compilation have stopped 
>>>>>>> anyways.
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> //Nils
>>>>>>>
>>>>>>>
>>>>>>> On 2013-02-08 15:54, Nils Eliasson wrote:
>>>>>>>> Vladimir and Andreas, thanks for your feedback! I am considering
>>>>>>>> your
>>>>>>>> suggestions.
>>>>>>>>
>>>>>>>> My fix is a step in the right direction but I realize it is not
>>>>>>>> enough.
>>>>>>>>
>>>>>>>> Initially, it works good reserving the last part of the heap 
>>>>>>>> block.
>>>>>>>> But if the application has a bigger active code footprint that 
>>>>>>>> what
>>>>>>>> can fit in the code cache, there will be new flushes that will
>>>>>>>> increase fragmentation and slowly reduce the usable part of the 
>>>>>>>> code
>>>>>>>> cache. So I will add functionality for backing off.
>>>>>>>>
>>>>>>>> //Nils
>>>>>>>>
>>>>>>>> Schoesser, Andreas skrev 2013-02-01 10:58:
>>>>>>>>> Hi Nils,
>>>>>>>>>
>>>>>>>>> this is IMO a good idea since we experienced the same problem 
>>>>>>>>> with
>>>>>>>>> one of our ports. I think in our case it was not the nmethod
>>>>>>>>> sweeper
>>>>>>>>> continuously running (there's MinCodeCacheFlushingInterval to 
>>>>>>>>> only
>>>>>>>>> speculatively disconnect nmethods every 30 seconds) but from the
>>>>>>>>> compiler loop constantly polling the freelist without the nmethod
>>>>>>>>> sweeper making any progress.
>>>>>>>>>
>>>>>>>>> You also might consider to propagate the "critical" flag down to
>>>>>>>>> search_freelist(). Then, a simple address compare would do to 
>>>>>>>>> keep
>>>>>>>>> the end of the code cache free from nmethods:
>>>>>>>>> - For non-critical blobs, search_freelist() may only fit free
>>>>>>>>> blocks
>>>>>>>>> < CodeCache::end() - CodeCacheMinimumFreeSpace
>>>>>>>>> - For critical blocks, search_freelist() may fit all free blocks
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Andreas
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: hotspot-compiler-dev-bounces at openjdk.java.net
>>>>>>>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On 
>>>>>>>>> Behalf Of
>>>>>>>>> Nils Eliasson
>>>>>>>>> Sent: Donnerstag, 31. Januar 2013 19:41
>>>>>>>>> To: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>> Subject: Re: RFR (M): 8006952: Slow VM due to excessive code 
>>>>>>>>> cache
>>>>>>>>> freelist iteration
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.04/
>>>>>>>>>
>>>>>>>>> //N
>>>>>>>>>
>>>>>>>>> Vladimir Kozlov skrev 2013-01-30 21:16:
>>>>>>>>>> Nils, you sent webrev for other bug fix.
>>>>>>>>>>
>>>>>>>>>> Vladimir
>>>>>>>>>>
>>>>>>>>>> On 1/30/13 7:43 AM, Nils Eliasson wrote:
>>>>>>>>>>> Thanks for the link, interesting background.
>>>>>>>>>>>
>>>>>>>>>>> Even if finding the largest block on the freelist is free, we
>>>>>>>>>>> would
>>>>>>>>>>> still have a misbehavior when the free heap block is less than
>>>>>>>>>>> 1,5M
>>>>>>>>>>> and
>>>>>>>>>>> the flushing begins to create a 1,5M freelist block.
>>>>>>>>>>>
>>>>>>>>>>> Unallocated memory is a good measurement if have some 
>>>>>>>>>>> continuous
>>>>>>>>>>> memory
>>>>>>>>>>> in reserve for critical blobs. I am thinking of using the
>>>>>>>>>>> thresholds
>>>>>>>>>>> against unallocated memory, but forbidding nmethods from using
>>>>>>>>>>> the
>>>>>>>>>>> last
>>>>>>>>>>> 0,5M (MinimumFreeSpace) from the heap block. That would prevent
>>>>>>>>>>> the VM
>>>>>>>>>>> from fragmenting the last continuous memory space, and allow 
>>>>>>>>>>> the
>>>>>>>>>>> VM to
>>>>>>>>>>> use all of the freelist.
>>>>>>>>>>>
>>>>>>>>>>> Like this:
>>>>>>>>>>> http://cr.openjdk.java.net/~neliasso/8002364/webrev.03
>>>>>>>>>>>
>>>>>>>>>>> //Nils
>>>>>>>>>>>
>>>>>>>>>>> Vladimir Kozlov skrev 2013-01-29 20:35:
>>>>>>>>>>>> Nils,
>>>>>>>>>>>>
>>>>>>>>>>>> You are reversing 7025742 fix. I would prefer to keep track 
>>>>>>>>>>>> of a
>>>>>>>>>>>> largest free block during allocation in CodeCache (by using
>>>>>>>>>>>> ordered
>>>>>>>>>>>> list or other technique) to avoid scanning the list.
>>>>>>>>>>>>
>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>
>>>>>>>>>>>> On 1/29/13 2:56 AM, Nils Eliasson wrote:
>>>>>>>>>>>>> Remove continuous free block requirement for code cache
>>>>>>>>>>>>> flushing and
>>>>>>>>>>>>> minimum free space.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This causes a degenerate behavior when the VM are repeatedly
>>>>>>>>>>>>> flushing
>>>>>>>>>>>>> the code cache trying to free up a continuous 1,5M block.
>>>>>>>>>>>>> Since the
>>>>>>>>>>>>> freelist is fragmented a significant part of the code 
>>>>>>>>>>>>> cache is
>>>>>>>>>>>>> kept
>>>>>>>>>>>>> unallocated. A significant amount of time is spent
>>>>>>>>>>>>> traversing the
>>>>>>>>>>>>> freelist holding the code cache lock or waiting for other
>>>>>>>>>>>>> threads
>>>>>>>>>>>>> doing
>>>>>>>>>>>>> the same.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don't see any reason for why a continuous block is 
>>>>>>>>>>>>> required.
>>>>>>>>>>>>> Code
>>>>>>>>>>>>> cache flushing threshold 
>>>>>>>>>>>>> (CodeCacheFlushingMinimumFreeSpace) is
>>>>>>>>>>>>> default
>>>>>>>>>>>>> 1,5M and code cache minimum threshold
>>>>>>>>>>>>> (CodeCacheMinimumFreeSpace) is
>>>>>>>>>>>>> 0,5M. Finding such a block on the freelist is often
>>>>>>>>>>>>> unrealistic,
>>>>>>>>>>>>> and has
>>>>>>>>>>>>> not any purpose. The largest nmethods are in the order of
>>>>>>>>>>>>> 250k, and
>>>>>>>>>>>>> they
>>>>>>>>>>>>> are not allocated when code cache is starting to run out. All
>>>>>>>>>>>>> critical
>>>>>>>>>>>>> adapters are small and will fit easily in the freelist or in
>>>>>>>>>>>>> the
>>>>>>>>>>>>> remaining heap space.
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.02/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Nils Eliasson
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>


From yumin.qi at oracle.com  Tue Apr 16 13:52:25 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Tue, 16 Apr 2013 13:52:25 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516D4A86.90405@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com>
Message-ID: <516DBA09.9070400@oracle.com>

Hi, all

   new webrev at
   http://cr.openjdk.java.net/~minqi/8010992/webrev3

   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread, 
use FREE_C_HEAP_OBJECT to free it in ~Thread.
                     quickSort.cpp, remove conditional includes.

Thanks
Yumin


On 4/16/2013 5:56 AM, David Holmes wrote:
> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>> Adding back compiler and gc teams
>>>
>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>> Zhenyu,
>>>>
>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>> Maybe you need a replacement delete operator, please check
>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>
>>>> i can just do
>>>>
>>>> delete ((type *)&array_name[index]);
>>>>
>>>> so the destructor will be called, is this right?
>>>
>>> No, it will also deallocate the memory unless you use a variant of
>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>> actually deallocate the memory.
>>>
>> Yes, I meant placement delete operator, which takes two pointers.
>
> But you can only call that explicitly as a function. The delete 
> expression will never use it, so I don't see how it applies. We need 
> to call the destructor without de-allocating and the only way I can 
> see to do that is to call the destructor explicitly.
>
> David
> -----
>
>
>> -Zhengyu
>>
>>
>>> I think this is getting out of hand - if we go this path then we
>>> should simply have a custom operator new[] and operator delete[] and
>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>> destructs and then de-allocates.
>>>
>>> I have no issue with calling destructors explicitly.
>>>
>>> David
>>> -----
>>>
>>>> Thanks
>>>> Yumin
>>>>> Thanks,
>>>>>
>>>>> -Zhengyu
>>>>>
>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>> memflags)                  \
>>>>>>   624 { \
>>>>>>   625     if (array_name != NULL)
>>>>>> { \
>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>> {                                 \
>>>>>>   627         /* placement to call dtor on type
>>>>>> */                                        \
>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>   629 } \
>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>> memflags);                                \
>>>>>>   631 } \
>>>>>>   632   }
>>>>>>
>>>>>>
>>>>>> I really don't like this, calling dtor  ...
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Zhengyu
>>>>>>
>>>>>>
>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>> new webrev at:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>
>>>>>>> Can I have a review from GC team for this change?
>>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>
>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>> Hi Yumin,
>>>>>>>>
>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>> 
>>>>>>>>
>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to leak
>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer to 
>>>>>>>> it!
>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> allocation.hpp:
>>>>>>>>
>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array 
>>>>>>>> element
>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>>>>>>>> before deallocating ?
>>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>
>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Yumin
>>>>>>>>>
>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>> .
>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>
>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>> Since we
>>>>>>>>>>> did not call constructor by using this MACRO. It is a 
>>>>>>>>>>> _ValueObj,
>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>> which
>>>>>>>>>>> will call ctors.
>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> -Zhengyu
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the 
>>>>>>>>>>>> dstor
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Yumin
>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>> 
>>>>>>>>>>>>>
>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and
>>>>>>>>>>>>> new
>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>
>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of 
>>>>>>>>>>>>> global
>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, but it
>>>>>>>>>>>>> cannot prevent third party code to catch such exceptions.  By
>>>>>>>>>>>>> disabling use of global operator new[] and new, we constrain
>>>>>>>>>>>>> the
>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>> have to
>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they have to
>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>


From vladimir.kozlov at oracle.com  Tue Apr 16 14:34:20 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 16 Apr 2013 14:34:20 -0700
Subject: RFR (M): 8006952: Slow VM due to excessive code cache freelist
	iteration
In-Reply-To: <516DB836.5000401@oracle.com>
References: <5107AADF.6010501@oracle.com> <51082499.3000905@oracle.com>
	<51093FAC.6090803@oracle.com> <51097FA6.3050709@oracle.com>
	<510ABAB9.8020909@oracle.com>
	<15E6C57378C5FE43AD074594DD824E501C8AB7E7@DEWDFEMB15A.global.corp.sap>
	<511511A5.8050101@oracle.com> <5167DFC2.6020007@oracle.com>
	<51684283.7010304@oracle.com> <516BD82A.7050302@oracle.com>
	<516D24FE.1090105@oracle.com> <516D67A1.1060002@oracle.com>
	<516D9600.9060208@oracle.com> <516D9AC5.4060307@oracle.com>
	<516DB836.5000401@oracle.com>
Message-ID: <516DC3DC.4050907@oracle.com>

On 4/16/13 1:44 PM, Nils Eliasson wrote:
>
> On 2013-04-16 20:39, Vladimir Kozlov wrote:
>> I asked about changes in CompileBroker::compiler_thread_loop():
>>
>> 1584       if (CodeCache::unallocated_capacity() <
>> CodeCacheMinimumFreeSpace) {
>> 1585         // the code cache is really full
>> 1586         handle_full_code_cache();
>>
>> It is executed before we compile a method.
>>
>> For example, if we have a hot method at the end of codecache which is
>> used then the check above will prevent us from compiling any methods
>> even when codecache has enough space in the middle (a block on
>> free_list). Do I get it right?
>
> No, the space on the free list is included in
> CodeCache::unallocated_capacity().

I am sorry, I mistook CodeHeap::heap_unallocated_capacity() method for 
CodeHeap::unallocated_capacity(). And unallocated_capacity() takes into 
account free_list as you said.

Changes are good for push.

Thanks,
Vladimir

>
> But we might have 1500k of really fragmented space on the free list, and
> nothing but the adapter/stub-reserved space in the heap. Then compiles
> will pass the check at 1584 and 1587, but later fail on
> bufferblob/nmethod allocation. But that case is handled by calls too
> handle_full_code_cache() at the allocation sites.
>
> //N
>
>>
>> Thanks,
>> Vladimir
>>
>> On 4/16/13 11:18 AM, Nils Eliasson wrote:
>>> Yes.
>>>
>>> So its pretty much like it was before:
>>>
>>> 1) Try to allocate from the free list using best fit
>>> 2) Allocate a new chunk from the code cache heap (always increasing,
>>> reclaimed memory always goes to the free list)
>>>
>>> With the addition that for both 1 and 2, stubs and adapters have a
>>> strict monopoly on the last 500k of address space. But they are
>>> themselves free to be placed wherever possible, and will essentially
>>> only use the last part as a last resort.
>>>
>>> I belive this will allow us to decrease the CodeCacheMinimumThreshold
>>> since we now have strong guarantees that nmethods will not eat up or
>>> fragment the last part. But that is for another change.
>>>
>>> Thanks for your time!
>>> //Nils
>>>
>>>
>>>
>>>
>>> On 2013-04-16 17:00, Vladimir Kozlov wrote:
>>>> Looks good.
>>>>
>>>> Do I understand correctly that now we bailout from in compileBroker
>>>> conservatively if no enough space at the end of code cache? But in a
>>>> middle we could have a big free block. Right?
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 4/16/13 3:16 AM, Nils Eliasson wrote:
>>>>> Latest webrev: http://cr.openjdk.java.net/~neliasso/8006952/webrev.09/
>>>>> 
>>>>>
>>>>> Updates after comments from Vladimir K. and Niclas.
>>>>>
>>>>> - Removed 'red_zone' naming and refined comments
>>>>> - Refined naming in heap.cpp/hpp on conversion methods
>>>>> size(...)/number_of_segments(...) to
>>>>> size_to_segments(...)/segments_to_size(...)
>>>>> - Bool flags as verbs (critical -> is_critical)
>>>>> - Removed get_largest_block() and all its uses.
>>>>>
>>>>> Enjoy!
>>>>>
>>>>> //Nils
>>>>>
>>>>> On 2013-04-15 12:36, Nils Eliasson wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 2013-04-12 19:21, Vladimir Kozlov wrote:
>>>>>>> Nils,
>>>>>>>
>>>>>>> It is sad that you have to reverse parfait fix but I agree that your
>>>>>>> changes are more clean.
>>>>>>
>>>>>> Please - don't be! I taken extra precaution and have verified that
>>>>>> there is a null check between the call to new and the constructor.
>>>>>> This is consistent with both the C++ spec and the behaviour we
>>>>>> rely on
>>>>>> when running out of code cache. The CodeCache::has_space would have
>>>>>> forced me to do it more complex, it would have to copy/wrap the
>>>>>> heap::allocate algorithm but returning a bool instead of actually
>>>>>> allocating.
>>>>>>
>>>>>> Sorry for forgetting to add it to the change log in my request. I did
>>>>>> not intend to revert it without being open about it.
>>>>>>
>>>>>> I don't understand why Parfait is confused about 'this' being null in
>>>>>> the constructor. I will open a bug on Parfait if I can find where to
>>>>>> submit it.
>>>>>>
>>>>>>>
>>>>>>> After these changes largest_free_block() is used only in statistics
>>>>>>> output which is useless since it is not participating in codecache
>>>>>>> allocations.  May be we should remove it and use
>>>>>>> heap_unallocated_capacity() instead (do we need lock then?):
>>>>>>
>>>>>> Yes, good idea. Must check that I don't break any log tool if I
>>>>>> change
>>>>>> the output though.
>>>>>>
>>>>>>>
>>>>>>> size_t CodeCache::largest_free_block() {
>>>>>>>   return _heap->heap_unallocated_capacity();
>>>>>>> }
>>>>>>>
>>>>>>> Also red_zone_start() is confusing because it does not show how
>>>>>>> it is
>>>>>>> related to heap_unallocated_capacity(). In one place you use one:
>>>>>>>
>>>>>>>  211     if (size(length) > (heap_unallocated_capacity() -
>>>>>>> CodeCacheMinimumFreeSpace)) {
>>>>>>>
>>>>>>> and in an other use second:
>>>>>>>
>>>>>>>  437     if (((size_t)cur + length) >= (size_t)red_zone_start()) {
>>>>>>>
>>>>>>> Can we just use only heap_unallocated_capacity()?
>>>>>>
>>>>>> I agree that it is confusing. The background is that they serve a bit
>>>>>> different purpose. In one case we are allocating from the freelist
>>>>>> and
>>>>>> need to check against the adress where the 'red zone/critical
>>>>>> allocation area begins.' In the other it is a block allocation from
>>>>>> the contiguous heap where we know heap_unallocated_capacity is the
>>>>>> size of the block at the end of the heap. I'll come up with something
>>>>>> better.
>>>>>>
>>>>>> Thanks for taking your time!
>>>>>> //Nils
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 4/12/13 3:19 AM, Nils Eliasson wrote:
>>>>>>>> I have now incorporated both Vladimirs and Andreas suggestion:
>>>>>>>>
>>>>>>>> Changes to previous revision includes:
>>>>>>>> 1) Updated the checks in both heap::allocate and
>>>>>>>> heap::search_freelist
>>>>>>>> so that non critical allocation never stride into the
>>>>>>>> CodeCacheMinimumFreeSpace.
>>>>>>>> 2) Inverted the critical condition - now all allocations default
>>>>>>>> to not
>>>>>>>> critical. Only the places where we would go fatal if the allocation
>>>>>>>> returns null are critical.
>>>>>>>> 3) Refactored some names and removed duplicate methods in heap.cpp.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.08/
>>>>>>>> 
>>>>>>>>
>>>>>>>> This changes also opens up for decreasing the
>>>>>>>> CodeCacheMinimumFreeSpace
>>>>>>>> since we now guarantee that only critical allocation will end up
>>>>>>>> there.
>>>>>>>> And they will not grow to 500K when compilation have stopped
>>>>>>>> anyways.
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> //Nils
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2013-02-08 15:54, Nils Eliasson wrote:
>>>>>>>>> Vladimir and Andreas, thanks for your feedback! I am considering
>>>>>>>>> your
>>>>>>>>> suggestions.
>>>>>>>>>
>>>>>>>>> My fix is a step in the right direction but I realize it is not
>>>>>>>>> enough.
>>>>>>>>>
>>>>>>>>> Initially, it works good reserving the last part of the heap
>>>>>>>>> block.
>>>>>>>>> But if the application has a bigger active code footprint that
>>>>>>>>> what
>>>>>>>>> can fit in the code cache, there will be new flushes that will
>>>>>>>>> increase fragmentation and slowly reduce the usable part of the
>>>>>>>>> code
>>>>>>>>> cache. So I will add functionality for backing off.
>>>>>>>>>
>>>>>>>>> //Nils
>>>>>>>>>
>>>>>>>>> Schoesser, Andreas skrev 2013-02-01 10:58:
>>>>>>>>>> Hi Nils,
>>>>>>>>>>
>>>>>>>>>> this is IMO a good idea since we experienced the same problem
>>>>>>>>>> with
>>>>>>>>>> one of our ports. I think in our case it was not the nmethod
>>>>>>>>>> sweeper
>>>>>>>>>> continuously running (there's MinCodeCacheFlushingInterval to
>>>>>>>>>> only
>>>>>>>>>> speculatively disconnect nmethods every 30 seconds) but from the
>>>>>>>>>> compiler loop constantly polling the freelist without the nmethod
>>>>>>>>>> sweeper making any progress.
>>>>>>>>>>
>>>>>>>>>> You also might consider to propagate the "critical" flag down to
>>>>>>>>>> search_freelist(). Then, a simple address compare would do to
>>>>>>>>>> keep
>>>>>>>>>> the end of the code cache free from nmethods:
>>>>>>>>>> - For non-critical blobs, search_freelist() may only fit free
>>>>>>>>>> blocks
>>>>>>>>>> < CodeCache::end() - CodeCacheMinimumFreeSpace
>>>>>>>>>> - For critical blocks, search_freelist() may fit all free blocks
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Andreas
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: hotspot-compiler-dev-bounces at openjdk.java.net
>>>>>>>>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On
>>>>>>>>>> Behalf Of
>>>>>>>>>> Nils Eliasson
>>>>>>>>>> Sent: Donnerstag, 31. Januar 2013 19:41
>>>>>>>>>> To: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>>> Subject: Re: RFR (M): 8006952: Slow VM due to excessive code
>>>>>>>>>> cache
>>>>>>>>>> freelist iteration
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.04/
>>>>>>>>>>
>>>>>>>>>> //N
>>>>>>>>>>
>>>>>>>>>> Vladimir Kozlov skrev 2013-01-30 21:16:
>>>>>>>>>>> Nils, you sent webrev for other bug fix.
>>>>>>>>>>>
>>>>>>>>>>> Vladimir
>>>>>>>>>>>
>>>>>>>>>>> On 1/30/13 7:43 AM, Nils Eliasson wrote:
>>>>>>>>>>>> Thanks for the link, interesting background.
>>>>>>>>>>>>
>>>>>>>>>>>> Even if finding the largest block on the freelist is free, we
>>>>>>>>>>>> would
>>>>>>>>>>>> still have a misbehavior when the free heap block is less than
>>>>>>>>>>>> 1,5M
>>>>>>>>>>>> and
>>>>>>>>>>>> the flushing begins to create a 1,5M freelist block.
>>>>>>>>>>>>
>>>>>>>>>>>> Unallocated memory is a good measurement if have some
>>>>>>>>>>>> continuous
>>>>>>>>>>>> memory
>>>>>>>>>>>> in reserve for critical blobs. I am thinking of using the
>>>>>>>>>>>> thresholds
>>>>>>>>>>>> against unallocated memory, but forbidding nmethods from using
>>>>>>>>>>>> the
>>>>>>>>>>>> last
>>>>>>>>>>>> 0,5M (MinimumFreeSpace) from the heap block. That would prevent
>>>>>>>>>>>> the VM
>>>>>>>>>>>> from fragmenting the last continuous memory space, and allow
>>>>>>>>>>>> the
>>>>>>>>>>>> VM to
>>>>>>>>>>>> use all of the freelist.
>>>>>>>>>>>>
>>>>>>>>>>>> Like this:
>>>>>>>>>>>> http://cr.openjdk.java.net/~neliasso/8002364/webrev.03
>>>>>>>>>>>>
>>>>>>>>>>>> //Nils
>>>>>>>>>>>>
>>>>>>>>>>>> Vladimir Kozlov skrev 2013-01-29 20:35:
>>>>>>>>>>>>> Nils,
>>>>>>>>>>>>>
>>>>>>>>>>>>> You are reversing 7025742 fix. I would prefer to keep track
>>>>>>>>>>>>> of a
>>>>>>>>>>>>> largest free block during allocation in CodeCache (by using
>>>>>>>>>>>>> ordered
>>>>>>>>>>>>> list or other technique) to avoid scanning the list.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Vladimir
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 1/29/13 2:56 AM, Nils Eliasson wrote:
>>>>>>>>>>>>>> Remove continuous free block requirement for code cache
>>>>>>>>>>>>>> flushing and
>>>>>>>>>>>>>> minimum free space.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This causes a degenerate behavior when the VM are repeatedly
>>>>>>>>>>>>>> flushing
>>>>>>>>>>>>>> the code cache trying to free up a continuous 1,5M block.
>>>>>>>>>>>>>> Since the
>>>>>>>>>>>>>> freelist is fragmented a significant part of the code
>>>>>>>>>>>>>> cache is
>>>>>>>>>>>>>> kept
>>>>>>>>>>>>>> unallocated. A significant amount of time is spent
>>>>>>>>>>>>>> traversing the
>>>>>>>>>>>>>> freelist holding the code cache lock or waiting for other
>>>>>>>>>>>>>> threads
>>>>>>>>>>>>>> doing
>>>>>>>>>>>>>> the same.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don't see any reason for why a continuous block is
>>>>>>>>>>>>>> required.
>>>>>>>>>>>>>> Code
>>>>>>>>>>>>>> cache flushing threshold
>>>>>>>>>>>>>> (CodeCacheFlushingMinimumFreeSpace) is
>>>>>>>>>>>>>> default
>>>>>>>>>>>>>> 1,5M and code cache minimum threshold
>>>>>>>>>>>>>> (CodeCacheMinimumFreeSpace) is
>>>>>>>>>>>>>> 0,5M. Finding such a block on the freelist is often
>>>>>>>>>>>>>> unrealistic,
>>>>>>>>>>>>>> and has
>>>>>>>>>>>>>> not any purpose. The largest nmethods are in the order of
>>>>>>>>>>>>>> 250k, and
>>>>>>>>>>>>>> they
>>>>>>>>>>>>>> are not allocated when code cache is starting to run out. All
>>>>>>>>>>>>>> critical
>>>>>>>>>>>>>> adapters are small and will fit easily in the freelist or in
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> remaining heap space.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~neliasso/8006952/webrev.02/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Nils Eliasson
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
>

From coleen.phillimore at oracle.com  Tue Apr 16 14:45:49 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 16 Apr 2013 17:45:49 -0400
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516DBA09.9070400@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
Message-ID: <516DC68D.8040906@oracle.com>


Hi Yumin,

It's a bit confusing that there's both a NEW_C_HEAP_OBJ and a 
NEW_C_HEAP_OBJECT.  I assume the latter was supposed to be symmetric 
with NEW_C_HEAP_OBJECT_ARRAY, but it is never used and sort of unclear 
when you'd want to use it.   The NEW_C_HEAP_OBJ call in thread.cpp could 
use the latter and not need the call to HandleMark::initialize().    And 
the change in handles.hpp wouldn't be needed then either.

The rest looks good.  I see why you didn't use placement delete because 
it isn't really supported by C++ (checking some web searching engine).

Coleen


On 04/16/2013 04:52 PM, Yumin Qi wrote:
> Hi, all
>
>   new webrev at
>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>
>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread, 
> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>                     quickSort.cpp, remove conditional includes.
>
> Thanks
> Yumin
>
>
> On 4/16/2013 5:56 AM, David Holmes wrote:
>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>> Adding back compiler and gc teams
>>>>
>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>> Zhenyu,
>>>>>
>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>> Maybe you need a replacement delete operator, please check
>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>
>>>>> i can just do
>>>>>
>>>>> delete ((type *)&array_name[index]);
>>>>>
>>>>> so the destructor will be called, is this right?
>>>>
>>>> No, it will also deallocate the memory unless you use a variant of
>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>> actually deallocate the memory.
>>>>
>>> Yes, I meant placement delete operator, which takes two pointers.
>>
>> But you can only call that explicitly as a function. The delete 
>> expression will never use it, so I don't see how it applies. We need 
>> to call the destructor without de-allocating and the only way I can 
>> see to do that is to call the destructor explicitly.
>>
>> David
>> -----
>>
>>
>>> -Zhengyu
>>>
>>>
>>>> I think this is getting out of hand - if we go this path then we
>>>> should simply have a custom operator new[] and operator delete[] and
>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>> destructs and then de-allocates.
>>>>
>>>> I have no issue with calling destructors explicitly.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>> Thanks,
>>>>>>
>>>>>> -Zhengyu
>>>>>>
>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>> memflags)                  \
>>>>>>>   624 { \
>>>>>>>   625     if (array_name != NULL)
>>>>>>> { \
>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>> {                                 \
>>>>>>>   627         /* placement to call dtor on type
>>>>>>> */                                        \
>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>   629 } \
>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>> memflags);                                \
>>>>>>>   631 } \
>>>>>>>   632   }
>>>>>>>
>>>>>>>
>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Zhengyu
>>>>>>>
>>>>>>>
>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>> new webrev at:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>
>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Yumin
>>>>>>>>
>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>> Hi Yumin,
>>>>>>>>>
>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>> 
>>>>>>>>>
>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to leak
>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer 
>>>>>>>>> to it!
>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> allocation.hpp:
>>>>>>>>>
>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array 
>>>>>>>>> element
>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>>>>>>>>> before deallocating ?
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>
>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>>
>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>> .
>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>
>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>> Since we
>>>>>>>>>>>> did not call constructor by using this MACRO. It is a 
>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>> which
>>>>>>>>>>>> will call ctors.
>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the 
>>>>>>>>>>>>> dstor
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Yumin
>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and
>>>>>>>>>>>>>> new
>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of 
>>>>>>>>>>>>>> global
>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, 
>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>> cannot prevent third party code to catch such 
>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>> disabling use of global operator new[] and new, we constrain
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they have to
>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>


From zhengyu.gu at oracle.com  Tue Apr 16 14:59:06 2013
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Tue, 16 Apr 2013 17:59:06 -0400
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516DC68D.8040906@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516DC68D.8040906@oracle.com>
Message-ID: <516DC9AA.9040103@oracle.com>

Agree with Coleen. NEW_C_HEAP_OBJ and NEW_C_HEAP_OBJECT are really 
confusing, maybe NEW_C_HEAP_CLASS_OBJ (?)

Otherwise, it is good.

Thanks,

-Zhengyu


On 4/16/2013 5:45 PM, Coleen Phillimore wrote:
>
> Hi Yumin,
>
> It's a bit confusing that there's both a NEW_C_HEAP_OBJ and a 
> NEW_C_HEAP_OBJECT.  I assume the latter was supposed to be symmetric 
> with NEW_C_HEAP_OBJECT_ARRAY, but it is never used and sort of unclear 
> when you'd want to use it.   The NEW_C_HEAP_OBJ call in thread.cpp 
> could use the latter and not need the call to 
> HandleMark::initialize().    And the change in handles.hpp wouldn't be 
> needed then either.
>
> The rest looks good.  I see why you didn't use placement delete 
> because it isn't really supported by C++ (checking some web searching 
> engine).
>
> Coleen
>
>
> On 04/16/2013 04:52 PM, Yumin Qi wrote:
>> Hi, all
>>
>>   new webrev at
>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>
>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread, 
>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>                     quickSort.cpp, remove conditional includes.
>>
>> Thanks
>> Yumin
>>
>>
>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>> Adding back compiler and gc teams
>>>>>
>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>> Zhenyu,
>>>>>>
>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>
>>>>>> i can just do
>>>>>>
>>>>>> delete ((type *)&array_name[index]);
>>>>>>
>>>>>> so the destructor will be called, is this right?
>>>>>
>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>>> actually deallocate the memory.
>>>>>
>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>
>>> But you can only call that explicitly as a function. The delete 
>>> expression will never use it, so I don't see how it applies. We need 
>>> to call the destructor without de-allocating and the only way I can 
>>> see to do that is to call the destructor explicitly.
>>>
>>> David
>>> -----
>>>
>>>
>>>> -Zhengyu
>>>>
>>>>
>>>>> I think this is getting out of hand - if we go this path then we
>>>>> should simply have a custom operator new[] and operator delete[] and
>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>> destructs and then de-allocates.
>>>>>
>>>>> I have no issue with calling destructors explicitly.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Zhengyu
>>>>>>>
>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>> memflags)                  \
>>>>>>>>   624 { \
>>>>>>>>   625     if (array_name != NULL)
>>>>>>>> { \
>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>> {                                 \
>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>> */                                        \
>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>   629 } \
>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>> memflags);                                \
>>>>>>>>   631 } \
>>>>>>>>   632   }
>>>>>>>>
>>>>>>>>
>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>> new webrev at:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>
>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Yumin
>>>>>>>>>
>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>> Hi Yumin,
>>>>>>>>>>
>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>> 
>>>>>>>>>>
>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to 
>>>>>>>>>> leak
>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer 
>>>>>>>>>> to it!
>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> allocation.hpp:
>>>>>>>>>>
>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array 
>>>>>>>>>> element
>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the 
>>>>>>>>>> dtor's
>>>>>>>>>> before deallocating ?
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>
>>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Yumin
>>>>>>>>>>>
>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>> .
>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>> Since we
>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a 
>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>> which
>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is 
>>>>>>>>>>>> what
>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the 
>>>>>>>>>>>>>> dstor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] 
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of 
>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, 
>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>> cannot prevent third party code to catch such 
>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we 
>>>>>>>>>>>>>>> constrain
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they have to
>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>


From yumin.qi at oracle.com  Tue Apr 16 15:08:22 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Tue, 16 Apr 2013 15:08:22 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516DC9AA.9040103@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516DC68D.8040906@oracle.com> <516DC9AA.9040103@oracle.com>
Message-ID: <516DCBD6.4050702@oracle.com>


On 4/16/2013 2:59 PM, Zhengyu Gu wrote:
> Agree with Coleen. NEW_C_HEAP_OBJ and NEW_C_HEAP_OBJECT are really 
> confusing, maybe NEW_C_HEAP_CLASS_OBJ (?)
>
Yes, that will be better.

Thanks
Yumin
> Otherwise, it is good.
>
> Thanks,
>
> -Zhengyu
>
>
> On 4/16/2013 5:45 PM, Coleen Phillimore wrote:
>>
>> Hi Yumin,
>>
>> It's a bit confusing that there's both a NEW_C_HEAP_OBJ and a 
>> NEW_C_HEAP_OBJECT.  I assume the latter was supposed to be symmetric 
>> with NEW_C_HEAP_OBJECT_ARRAY, but it is never used and sort of 
>> unclear when you'd want to use it.   The NEW_C_HEAP_OBJ call in 
>> thread.cpp could use the latter and not need the call to 
>> HandleMark::initialize().    And the change in handles.hpp wouldn't 
>> be needed then either.
>>
>> The rest looks good.  I see why you didn't use placement delete 
>> because it isn't really supported by C++ (checking some web searching 
>> engine).
>>
>> Coleen
>>
>>
>> On 04/16/2013 04:52 PM, Yumin Qi wrote:
>>> Hi, all
>>>
>>>   new webrev at
>>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>>
>>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread, 
>>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>>                     quickSort.cpp, remove conditional includes.
>>>
>>> Thanks
>>> Yumin
>>>
>>>
>>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>>> Adding back compiler and gc teams
>>>>>>
>>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>>> Zhenyu,
>>>>>>>
>>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>>
>>>>>>> i can just do
>>>>>>>
>>>>>>> delete ((type *)&array_name[index]);
>>>>>>>
>>>>>>> so the destructor will be called, is this right?
>>>>>>
>>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>>>> actually deallocate the memory.
>>>>>>
>>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>>
>>>> But you can only call that explicitly as a function. The delete 
>>>> expression will never use it, so I don't see how it applies. We 
>>>> need to call the destructor without de-allocating and the only way 
>>>> I can see to do that is to call the destructor explicitly.
>>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>>> -Zhengyu
>>>>>
>>>>>
>>>>>> I think this is getting out of hand - if we go this path then we
>>>>>> should simply have a custom operator new[] and operator delete[] and
>>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>>> destructs and then de-allocates.
>>>>>>
>>>>>> I have no issue with calling destructors explicitly.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>>> memflags)                  \
>>>>>>>>>   624 { \
>>>>>>>>>   625     if (array_name != NULL)
>>>>>>>>> { \
>>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>>> {                                 \
>>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>>> */                                        \
>>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>>   629 } \
>>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>>> memflags);                                \
>>>>>>>>>   631 } \
>>>>>>>>>   632   }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> -Zhengyu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>>> new webrev at:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>>
>>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>>
>>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>>> Hi Yumin,
>>>>>>>>>>>
>>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>>> 
>>>>>>>>>>>
>>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to 
>>>>>>>>>>> leak
>>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer 
>>>>>>>>>>> to it!
>>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> allocation.hpp:
>>>>>>>>>>>
>>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array 
>>>>>>>>>>> element
>>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the 
>>>>>>>>>>> dtor's
>>>>>>>>>>> before deallocating ?
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>>
>>>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Yumin
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>>> .
>>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>>> Since we
>>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a 
>>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>>> which
>>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is 
>>>>>>>>>>>>> what
>>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need 
>>>>>>>>>>>>>>> the dstor
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator 
>>>>>>>>>>>>>>>> new[] and
>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of 
>>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, 
>>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>>> cannot prevent third party code to catch such 
>>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we 
>>>>>>>>>>>>>>>> constrain
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same 
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> structs) in hotspot have to either extends from 
>>>>>>>>>>>>>>>> CHeapObj or
>>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they 
>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>


From coleen.phillimore at oracle.com  Tue Apr 16 15:05:13 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 16 Apr 2013 18:05:13 -0400
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516DC9AA.9040103@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516DC68D.8040906@oracle.com> <516DC9AA.9040103@oracle.com>
Message-ID: <516DCB19.2050600@oracle.com>


On 04/16/2013 05:59 PM, Zhengyu Gu wrote:
> Agree with Coleen. NEW_C_HEAP_OBJ and NEW_C_HEAP_OBJECT are really 
> confusing, maybe NEW_C_HEAP_CLASS_OBJ (?)

Or change the other 2 occurrences of NEW_C_HEAP_OBJ's to 
NEW_C_HEAP_OBJECT (better name) and completely remove NEW_C_HEAP_OBJ.  
Most code uses NEW_C_HEAP_ARRAY() with 1 element to get the 
NEW_C_HEAP_OBJ behavior anyway.

The other uses are structs, they won't change behavior.

Coleen

>
> Otherwise, it is good.
>
> Thanks,
>
> -Zhengyu
>
>
> On 4/16/2013 5:45 PM, Coleen Phillimore wrote:
>>
>> Hi Yumin,
>>
>> It's a bit confusing that there's both a NEW_C_HEAP_OBJ and a 
>> NEW_C_HEAP_OBJECT.  I assume the latter was supposed to be symmetric 
>> with NEW_C_HEAP_OBJECT_ARRAY, but it is never used and sort of 
>> unclear when you'd want to use it.   The NEW_C_HEAP_OBJ call in 
>> thread.cpp could use the latter and not need the call to 
>> HandleMark::initialize().    And the change in handles.hpp wouldn't 
>> be needed then either.
>>
>> The rest looks good.  I see why you didn't use placement delete 
>> because it isn't really supported by C++ (checking some web searching 
>> engine).
>>
>> Coleen
>>
>>
>> On 04/16/2013 04:52 PM, Yumin Qi wrote:
>>> Hi, all
>>>
>>>   new webrev at
>>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>>
>>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread, 
>>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>>                     quickSort.cpp, remove conditional includes.
>>>
>>> Thanks
>>> Yumin
>>>
>>>
>>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>>> Adding back compiler and gc teams
>>>>>>
>>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>>> Zhenyu,
>>>>>>>
>>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>>
>>>>>>> i can just do
>>>>>>>
>>>>>>> delete ((type *)&array_name[index]);
>>>>>>>
>>>>>>> so the destructor will be called, is this right?
>>>>>>
>>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>>>> actually deallocate the memory.
>>>>>>
>>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>>
>>>> But you can only call that explicitly as a function. The delete 
>>>> expression will never use it, so I don't see how it applies. We 
>>>> need to call the destructor without de-allocating and the only way 
>>>> I can see to do that is to call the destructor explicitly.
>>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>>> -Zhengyu
>>>>>
>>>>>
>>>>>> I think this is getting out of hand - if we go this path then we
>>>>>> should simply have a custom operator new[] and operator delete[] and
>>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>>> destructs and then de-allocates.
>>>>>>
>>>>>> I have no issue with calling destructors explicitly.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>>> memflags)                  \
>>>>>>>>>   624 { \
>>>>>>>>>   625     if (array_name != NULL)
>>>>>>>>> { \
>>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>>> {                                 \
>>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>>> */                                        \
>>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>>   629 } \
>>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>>> memflags);                                \
>>>>>>>>>   631 } \
>>>>>>>>>   632   }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> -Zhengyu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>>> new webrev at:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>>
>>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>>
>>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>>> Hi Yumin,
>>>>>>>>>>>
>>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>>> 
>>>>>>>>>>>
>>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to 
>>>>>>>>>>> leak
>>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer 
>>>>>>>>>>> to it!
>>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> allocation.hpp:
>>>>>>>>>>>
>>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array 
>>>>>>>>>>> element
>>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the 
>>>>>>>>>>> dtor's
>>>>>>>>>>> before deallocating ?
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>>
>>>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Yumin
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>>> .
>>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>>> Since we
>>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a 
>>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>>> which
>>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is 
>>>>>>>>>>>>> what
>>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need 
>>>>>>>>>>>>>>> the dstor
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator 
>>>>>>>>>>>>>>>> new[] and
>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of 
>>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, 
>>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>>> cannot prevent third party code to catch such 
>>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we 
>>>>>>>>>>>>>>>> constrain
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same 
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> structs) in hotspot have to either extends from 
>>>>>>>>>>>>>>>> CHeapObj or
>>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they 
>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>


From yumin.qi at oracle.com  Tue Apr 16 15:12:06 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Tue, 16 Apr 2013 15:12:06 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516DCB19.2050600@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516DC68D.8040906@oracle.com> <516DC9AA.9040103@oracle.com>
	<516DCB19.2050600@oracle.com>
Message-ID: <516DCCB6.9060304@oracle.com>

Let me check how many places NEW_C_HEAP_OBJ  used in hotspot.

Thanks
Yumin
On 4/16/2013 3:05 PM, Coleen Phillimore wrote:
>
> On 04/16/2013 05:59 PM, Zhengyu Gu wrote:
>> Agree with Coleen. NEW_C_HEAP_OBJ and NEW_C_HEAP_OBJECT are really 
>> confusing, maybe NEW_C_HEAP_CLASS_OBJ (?)
>
> Or change the other 2 occurrences of NEW_C_HEAP_OBJ's to 
> NEW_C_HEAP_OBJECT (better name) and completely remove NEW_C_HEAP_OBJ.  
> Most code uses NEW_C_HEAP_ARRAY() with 1 element to get the 
> NEW_C_HEAP_OBJ behavior anyway.
>
> The other uses are structs, they won't change behavior.
>
> Coleen
>
>>
>> Otherwise, it is good.
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>
>> On 4/16/2013 5:45 PM, Coleen Phillimore wrote:
>>>
>>> Hi Yumin,
>>>
>>> It's a bit confusing that there's both a NEW_C_HEAP_OBJ and a 
>>> NEW_C_HEAP_OBJECT.  I assume the latter was supposed to be symmetric 
>>> with NEW_C_HEAP_OBJECT_ARRAY, but it is never used and sort of 
>>> unclear when you'd want to use it.   The NEW_C_HEAP_OBJ call in 
>>> thread.cpp could use the latter and not need the call to 
>>> HandleMark::initialize().    And the change in handles.hpp wouldn't 
>>> be needed then either.
>>>
>>> The rest looks good.  I see why you didn't use placement delete 
>>> because it isn't really supported by C++ (checking some web 
>>> searching engine).
>>>
>>> Coleen
>>>
>>>
>>> On 04/16/2013 04:52 PM, Yumin Qi wrote:
>>>> Hi, all
>>>>
>>>>   new webrev at
>>>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>>>
>>>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in 
>>>> Thread::Thread, use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>>>                     quickSort.cpp, remove conditional includes.
>>>>
>>>> Thanks
>>>> Yumin
>>>>
>>>>
>>>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>>>> Adding back compiler and gc teams
>>>>>>>
>>>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>>>> Zhenyu,
>>>>>>>>
>>>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>>>
>>>>>>>> i can just do
>>>>>>>>
>>>>>>>> delete ((type *)&array_name[index]);
>>>>>>>>
>>>>>>>> so the destructor will be called, is this right?
>>>>>>>
>>>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>>>> delete (which is what I think Zhengyu was referring to) that 
>>>>>>> doesn't
>>>>>>> actually deallocate the memory.
>>>>>>>
>>>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>>>
>>>>> But you can only call that explicitly as a function. The delete 
>>>>> expression will never use it, so I don't see how it applies. We 
>>>>> need to call the destructor without de-allocating and the only way 
>>>>> I can see to do that is to call the destructor explicitly.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>
>>>>>> -Zhengyu
>>>>>>
>>>>>>
>>>>>>> I think this is getting out of hand - if we go this path then we
>>>>>>> should simply have a custom operator new[] and operator delete[] 
>>>>>>> and
>>>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is 
>>>>>>> simple
>>>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>>>> destructs and then de-allocates.
>>>>>>>
>>>>>>> I have no issue with calling destructors explicitly.
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Yumin
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> -Zhengyu
>>>>>>>>>
>>>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>>>> memflags)                  \
>>>>>>>>>>   624 { \
>>>>>>>>>>   625     if (array_name != NULL)
>>>>>>>>>> { \
>>>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>>>> {                                 \
>>>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>>>> */                                        \
>>>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>>>   629 } \
>>>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>>>> memflags);                                \
>>>>>>>>>>   631 } \
>>>>>>>>>>   632   }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> -Zhengyu
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>>>> new webrev at:
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>>>
>>>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Yumin
>>>>>>>>>>>
>>>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>>>> Hi Yumin,
>>>>>>>>>>>>
>>>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>>>> 
>>>>>>>>>>>>
>>>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem 
>>>>>>>>>>>> to leak
>>>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any 
>>>>>>>>>>>> pointer to it!
>>>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>>>
>>>>>>>>>>>> ---
>>>>>>>>>>>>
>>>>>>>>>>>> allocation.hpp:
>>>>>>>>>>>>
>>>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array 
>>>>>>>>>>>> element
>>>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the 
>>>>>>>>>>>> dtor's
>>>>>>>>>>>> before deallocating ?
>>>>>>>>>>>>
>>>>>>>>>>>> ---
>>>>>>>>>>>>
>>>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>>>
>>>>>>>>>>>> Why does only Solaris need the allocation headers included 
>>>>>>>>>>>> ?? I
>>>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>>>> Since we
>>>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a 
>>>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>>>> should not call new, but I think we can use 
>>>>>>>>>>>>>>> NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that 
>>>>>>>>>>>>>> is what
>>>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need 
>>>>>>>>>>>>>>>> the dstor
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator 
>>>>>>>>>>>>>>>>> new[] and
>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage 
>>>>>>>>>>>>>>>>> of global
>>>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, 
>>>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>>>> cannot prevent third party code to catch such 
>>>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we 
>>>>>>>>>>>>>>>>> constrain
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as 
>>>>>>>>>>>>>>>>> same for
>>>>>>>>>>>>>>>>> structs) in hotspot have to either extends from 
>>>>>>>>>>>>>>>>> CHeapObj or
>>>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they 
>>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>>
>


From vladimir.x.ivanov at oracle.com  Tue Apr 16 16:16:30 2013
From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com)
Date: Tue, 16 Apr 2013 23:16:30 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 8011971: WB API doesn't accept
	j.l.reflect.Constructor
Message-ID: <20130416231636.51EC648361@hg.openjdk.java.net>

Changeset: 4b2eebe03f93
Author:    iignatyev
Date:      2013-04-16 10:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4b2eebe03f93

8011971: WB API doesn't accept j.l.reflect.Constructor
Reviewed-by: kvn, vlivanov

! src/share/vm/prims/whitebox.cpp
! test/compiler/whitebox/ClearMethodStateTest.java
! test/compiler/whitebox/CompilerWhiteBoxTest.java
! test/compiler/whitebox/DeoptimizeAllTest.java
! test/compiler/whitebox/DeoptimizeMethodTest.java
! test/compiler/whitebox/EnqueueMethodForCompilationTest.java
! test/compiler/whitebox/IsMethodCompilableTest.java
! test/compiler/whitebox/MakeMethodNotCompilableTest.java
! test/compiler/whitebox/SetDontInlineMethodTest.java
! test/compiler/whitebox/SetForceInlineMethodTest.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java


From vladimir.x.ivanov at oracle.com  Tue Apr 16 17:01:13 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 17 Apr 2013 04:01:13 +0400
Subject: RFR (S): 8012260: ciReplay: Include PID into the name of replay data
	file
Message-ID: <516DE649.9020105@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8012260/webrev.00
43 lines changed: 16 ins; 21 del; 6 mod;

Changed naming scheme for compilation replay data files from 
'replay.txt' to 'replay_pid%p.log', where %p is substituted w/ pid. It 
allows to easily correspond replay file with hs_err file and makes 
overwriting of existing files very unlikely.

Also, converted ReplayDataFile & DumpReplayDataOnError flags from 
develop to diagnostic, since they are useful in product binaries. Did 
some small cleanups.

One question still bothers me. There's a memory allocation in 
VMError::report_and_die() I don't know how to avoid:
+         fileStream* replay_data_stream = new (ResourceObj::C_HEAP, 
mtCompiler) fileStream(replay_data_file);

It's not new, I just moved it up from auxiliary method. Any ideas how to 
make VMError::report_and_die() allocation-free again? :-)

Best regards,
Vladimir Ivanov


From david.holmes at oracle.com  Tue Apr 16 18:12:43 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 Apr 2013 11:12:43 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516DC68D.8040906@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516DC68D.8040906@oracle.com>
Message-ID: <516DF70B.6000302@oracle.com>

On 17/04/2013 7:45 AM, Coleen Phillimore wrote:
>
> Hi Yumin,
>
> It's a bit confusing that there's both a NEW_C_HEAP_OBJ and a
> NEW_C_HEAP_OBJECT.  I assume the latter was supposed to be symmetric
> with NEW_C_HEAP_OBJECT_ARRAY, but it is never used and sort of unclear
> when you'd want to use it.

The critical difference is the invocation of the default constructor.

I think we have gone done the wrong path here because we really want the 
language to handle correct allocation and initialization (and 
de-allocation, destruction) of arrays. The allocation side seems correct 
but for deallocation I see a couple of problems:

a) you now need to know how big the array is so you can iterate through 
and invoke the destructor for each element. This might not be an issue 
for current usage but may be in general.

b) The destruction logic is incorrect I think:

((type*)&array_name[index])->~type();

This will only work correctly if the object is exactly of type "type". 
If a subclass has been stored into the array then we will invoke the 
destructor of the baseclass, due to the explicit cast to the base type. 
I don't even think a virtual destructor will be of any help there.

Aside - this comment is not relevant (allocation.hpp):

637         /* placement to call dtor on type */ 
                 \


> The NEW_C_HEAP_OBJ call in thread.cpp could
> use the latter and not need the call to HandleMark::initialize().    And
> the change in handles.hpp wouldn't be needed then either.

I'm not clear on the proposal here. But HandleMark is a PITA!

> The rest looks good.  I see why you didn't use placement delete because
> it isn't really supported by C++ (checking some web searching engine).

Placement delete doesn't help because it doesn't involve invoking 
destructors.

David

> Coleen
>
>
> On 04/16/2013 04:52 PM, Yumin Qi wrote:
>> Hi, all
>>
>>   new webrev at
>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>
>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread,
>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>                     quickSort.cpp, remove conditional includes.
>>
>> Thanks
>> Yumin
>>
>>
>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>> Adding back compiler and gc teams
>>>>>
>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>> Zhenyu,
>>>>>>
>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>
>>>>>> i can just do
>>>>>>
>>>>>> delete ((type *)&array_name[index]);
>>>>>>
>>>>>> so the destructor will be called, is this right?
>>>>>
>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>>> actually deallocate the memory.
>>>>>
>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>
>>> But you can only call that explicitly as a function. The delete
>>> expression will never use it, so I don't see how it applies. We need
>>> to call the destructor without de-allocating and the only way I can
>>> see to do that is to call the destructor explicitly.
>>>
>>> David
>>> -----
>>>
>>>
>>>> -Zhengyu
>>>>
>>>>
>>>>> I think this is getting out of hand - if we go this path then we
>>>>> should simply have a custom operator new[] and operator delete[] and
>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>> destructs and then de-allocates.
>>>>>
>>>>> I have no issue with calling destructors explicitly.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Zhengyu
>>>>>>>
>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>> memflags)                  \
>>>>>>>>   624 { \
>>>>>>>>   625     if (array_name != NULL)
>>>>>>>> { \
>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>> {                                 \
>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>> */                                        \
>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>   629 } \
>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>> memflags);                                \
>>>>>>>>   631 } \
>>>>>>>>   632   }
>>>>>>>>
>>>>>>>>
>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>> new webrev at:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>
>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Yumin
>>>>>>>>>
>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>> Hi Yumin,
>>>>>>>>>>
>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>> 
>>>>>>>>>>
>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to leak
>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer
>>>>>>>>>> to it!
>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> allocation.hpp:
>>>>>>>>>>
>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array
>>>>>>>>>> element
>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>>>>>>>>>> before deallocating ?
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>
>>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Yumin
>>>>>>>>>>>
>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>> .
>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>> Since we
>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a
>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>> which
>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the
>>>>>>>>>>>>>> dstor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and
>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of
>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions,
>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>> cannot prevent third party code to catch such
>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we constrain
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they have to
>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>

From david.holmes at oracle.com  Tue Apr 16 19:16:26 2013
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 Apr 2013 12:16:26 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516DF70B.6000302@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516DC68D.8040906@oracle.com> <516DF70B.6000302@oracle.com>
Message-ID: <516E05FA.4050804@oracle.com>

Bah! Now hotspot-runtime got left off the cc list. :(

David

On 17/04/2013 11:12 AM, David Holmes wrote:
> On 17/04/2013 7:45 AM, Coleen Phillimore wrote:
>>
>> Hi Yumin,
>>
>> It's a bit confusing that there's both a NEW_C_HEAP_OBJ and a
>> NEW_C_HEAP_OBJECT.  I assume the latter was supposed to be symmetric
>> with NEW_C_HEAP_OBJECT_ARRAY, but it is never used and sort of unclear
>> when you'd want to use it.
>
> The critical difference is the invocation of the default constructor.
>
> I think we have gone done the wrong path here because we really want the
> language to handle correct allocation and initialization (and
> de-allocation, destruction) of arrays. The allocation side seems correct
> but for deallocation I see a couple of problems:
>
> a) you now need to know how big the array is so you can iterate through
> and invoke the destructor for each element. This might not be an issue
> for current usage but may be in general.
>
> b) The destruction logic is incorrect I think:
>
> ((type*)&array_name[index])->~type();
>
> This will only work correctly if the object is exactly of type "type".
> If a subclass has been stored into the array then we will invoke the
> destructor of the baseclass, due to the explicit cast to the base type.
> I don't even think a virtual destructor will be of any help there.
>
> Aside - this comment is not relevant (allocation.hpp):
>
> 637         /* placement to call dtor on type */                 \
>
>
>> The NEW_C_HEAP_OBJ call in thread.cpp could
>> use the latter and not need the call to HandleMark::initialize().    And
>> the change in handles.hpp wouldn't be needed then either.
>
> I'm not clear on the proposal here. But HandleMark is a PITA!
>
>> The rest looks good.  I see why you didn't use placement delete because
>> it isn't really supported by C++ (checking some web searching engine).
>
> Placement delete doesn't help because it doesn't involve invoking
> destructors.
>
> David
>
>> Coleen
>>
>>
>> On 04/16/2013 04:52 PM, Yumin Qi wrote:
>>> Hi, all
>>>
>>>   new webrev at
>>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>>
>>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread,
>>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>>                     quickSort.cpp, remove conditional includes.
>>>
>>> Thanks
>>> Yumin
>>>
>>>
>>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>>> Adding back compiler and gc teams
>>>>>>
>>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>>> Zhenyu,
>>>>>>>
>>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>>
>>>>>>> i can just do
>>>>>>>
>>>>>>> delete ((type *)&array_name[index]);
>>>>>>>
>>>>>>> so the destructor will be called, is this right?
>>>>>>
>>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>>>> actually deallocate the memory.
>>>>>>
>>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>>
>>>> But you can only call that explicitly as a function. The delete
>>>> expression will never use it, so I don't see how it applies. We need
>>>> to call the destructor without de-allocating and the only way I can
>>>> see to do that is to call the destructor explicitly.
>>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>>> -Zhengyu
>>>>>
>>>>>
>>>>>> I think this is getting out of hand - if we go this path then we
>>>>>> should simply have a custom operator new[] and operator delete[] and
>>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>>> destructs and then de-allocates.
>>>>>>
>>>>>> I have no issue with calling destructors explicitly.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>>> memflags)                  \
>>>>>>>>>   624 { \
>>>>>>>>>   625     if (array_name != NULL)
>>>>>>>>> { \
>>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>>> {                                 \
>>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>>> */                                        \
>>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>>   629 } \
>>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>>> memflags);                                \
>>>>>>>>>   631 } \
>>>>>>>>>   632   }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> -Zhengyu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>>> new webrev at:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>>
>>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>>
>>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>>> Hi Yumin,
>>>>>>>>>>>
>>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>>> 
>>>>>>>>>>>
>>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to
>>>>>>>>>>> leak
>>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer
>>>>>>>>>>> to it!
>>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> allocation.hpp:
>>>>>>>>>>>
>>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array
>>>>>>>>>>> element
>>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the
>>>>>>>>>>> dtor's
>>>>>>>>>>> before deallocating ?
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>>
>>>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Yumin
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>>> .
>>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>>> Since we
>>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a
>>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>>> which
>>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is
>>>>>>>>>>>>> what
>>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the
>>>>>>>>>>>>>>> dstor
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[]
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of
>>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions,
>>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>>> cannot prevent third party code to catch such
>>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we
>>>>>>>>>>>>>>>> constrain
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they have to
>>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>

From vladimir.kozlov at oracle.com  Tue Apr 16 22:22:25 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 16 Apr 2013 22:22:25 -0700
Subject: RFR (S): 8012260: ciReplay: Include PID into the name of replay
	data file
In-Reply-To: <516DE649.9020105@oracle.com>
References: <516DE649.9020105@oracle.com>
Message-ID: <516E3191.4020401@oracle.com>

Make it product flag since it is ON by default (and it is not diagnostic 
but error dump).

Also why not reuse code which opens ErrorFile (hs_err*)?

Compilation::compile_only_this_method() allocates fileStream on stack:

   fileStream stream(fopen("c1_compile_only", "wt"));

thanks,
Vladimir

On 4/16/13 5:01 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.00
> 43 lines changed: 16 ins; 21 del; 6 mod;
>
> Changed naming scheme for compilation replay data files from
> 'replay.txt' to 'replay_pid%p.log', where %p is substituted w/ pid. It
> allows to easily correspond replay file with hs_err file and makes
> overwriting of existing files very unlikely.
>
> Also, converted ReplayDataFile & DumpReplayDataOnError flags from
> develop to diagnostic, since they are useful in product binaries. Did
> some small cleanups.
>
> One question still bothers me. There's a memory allocation in
> VMError::report_and_die() I don't know how to avoid:
> +         fileStream* replay_data_stream = new (ResourceObj::C_HEAP,
> mtCompiler) fileStream(replay_data_file);
>
> It's not new, I just moved it up from auxiliary method. Any ideas how to
> make VMError::report_and_die() allocation-free again? :-)
>
> Best regards,
> Vladimir Ivanov
>

From nils.eliasson at oracle.com  Wed Apr 17 02:40:53 2013
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Wed, 17 Apr 2013 11:40:53 +0200
Subject: RFR (S): 8010090 - GC ID has the wrong type
In-Reply-To: <516D5D57.2060804@oracle.com>
References: <516D5D57.2060804@oracle.com>
Message-ID: <516E6E25.1090908@oracle.com>

Compiler part looks good.

//Nils

On 2013-04-16 16:16, Jesper Wilhelmsson wrote:
> Hi,
>
> Could I have a couple of reviews for this really small change.
>
> The type of the GC ID and the Compile ID in the different tracing 
> events should be UINT as the values put into these fields are uint.
>
> Webrev: http://cr.openjdk.java.net/~jwilhelm/8010090/webrev/
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010090
>
> Thanks,
> /Jesper


From nils.eliasson at oracle.com  Wed Apr 17 03:16:25 2013
From: nils.eliasson at oracle.com (nils.eliasson at oracle.com)
Date: Wed, 17 Apr 2013 10:16:25 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 8006952: Slow VM due to excessive code
	cache freelist iteration
Message-ID: <20130417101643.209FC48387@hg.openjdk.java.net>

Changeset: a7fb14888912
Author:    neliasso
Date:      2013-04-11 13:57 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a7fb14888912

8006952: Slow VM due to excessive code cache freelist iteration
Summary: Remove continous free block requirement
Reviewed-by: kvn

! src/share/vm/code/codeBlob.cpp
! src/share/vm/code/codeCache.cpp
! src/share/vm/code/codeCache.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/memory/heap.cpp
! src/share/vm/memory/heap.hpp
! src/share/vm/opto/output.cpp


From goetz.lindenmaier at sap.com  Wed Apr 17 03:54:30 2013
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 17 Apr 2013 10:54:30 +0000
Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp
	stub [Was: Re: RFR (S): Specify offset of IC load in
	java_to_interp	stub.]
In-Reply-To: <516D7ACE.9010305@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC0CFA7D32@DEWDFEMB12A.global.corp.sap>
	<03C4DFDE-CD52-446E-92AA-A6F12903FE29@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB116E@DEWDFEMB12A.global.corp.sap>
	<7D07437F-CFF7-4298-B9A1-DE9F2E32D77D@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB1EDE@DEWDFEMB12A.global.corp.sap>
	<8A8B46F8-0C91-4E8C-950A-0E65095DB2E0@oracle.com>
	<516CD9A3.3030202@oracle.com> <516CDF6A.4080900@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB36A3@DEWDFEMB12A.global.corp.sap>
	<516D7ACE.9010305@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC0CFB3999@DEWDFEMB12A.global.corp.sap>

Hi, 

> The motivation for keeping the call code in the .ad file is because it 
> has to match what MachCall*Node::ret_addr_offset()
> is returning.
I see. If one would change the call in the compiledIC_.cpp this function
would have to be adapted.

On the other side, if somebody changes the relocations in emit_call_reloc, 
he has to adapt CompiledStaticCall::reloc_to_interp_stub().

This is all quite entangled, so we will not find a completely clean version.
I'm fine with any version, it has no effect on the ppc port.

Best regards,
  Goetz.

-----Original Message-----
From: Dean Long [mailto:dean.long at oracle.com] 
Sent: Dienstag, 16. April 2013 18:23
To: Lindenmaier, Goetz
Cc: hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]

What I'm suggesting is leaving all calls in the .ad file. "enc_class 
Java_Static_Call" would remain largely unchanged
except renaming emit_java_to_interp() to 
CompiledStaticCall::emit_to_interp_stub() .
The motivation for keeping the call code in the .ad file is because it 
has to match what MachCall*Node::ret_addr_offset()
is returning.

compiledIC.hpp:
+  // Code
+  static void emit_to_interp_stub(CodeBuffer &cbuf);
+  static uint to_interp_stub_size();
+  static uint reloc_to_interp_stub();

dl

On 4/16/2013 7:22 AM, Lindenmaier, Goetz wrote:
> Hi Dean,
>
> I left the runtime call in the ad file, as it's got nothing to do with
> CompiledStaticCalls that call Java.
>
> I thought this is a better separation of concerns.
> Anyways, you would have to pass in _method and
> _optimized_virtual, which are fields of the machnode.
>
> Best regards,
>    Goetz.
>
>
>
>
>
> -----Original Message-----
> From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Dean Long
> Sent: Dienstag, 16. April 2013 07:20
> To: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>
> Also, is moving the call into CompiledStaticCall::emit_call() really
> needed for PPC?  I'd prefer to move the
> stub emitter instead (sample sparc code):
>
>       if ( !_method ) {
>         emit_call_reloc(cbuf, $meth$$method, relocInfo::runtime_call_type);
>       } else if (_optimized_virtual) {
>         emit_call_reloc(cbuf, $meth$$method,
> relocInfo::opt_virtual_call_type);
>       } else {
>         emit_call_reloc(cbuf, $meth$$method, relocInfo::static_call_type);
>       }
>       if( _method ) {  // Emit stub for static call
>         CompiledStaticCall::emit_java_to_interp(cbuf);<---
>       }
>
> dl
>
> On 4/15/2013 9:54 PM, Dean Long wrote:
>> sparc.ad:
>>
>> 2538       CompiledStaticCall::emit_call(cbuf,
>> 2539                                     (int) ($meth$$method -
>> ((intptr_t) cbuf.insts_end()) - 4),
>> 2540                                     rtype);
>>
>> I think this should be:
>>
>> CompiledStaticCall::emit_call(cbuf,$meth$$method,  rtype);
>>
>> Computing the PC-relative offset probably only applies to x86.
>>
>> dl
>>
>> On 4/12/2013 2:03 PM, Christian Thalinger wrote:
>>> On Apr 11, 2013, at 2:46 PM, "Lindenmaier, Goetz"
>>>  wrote:
>>>
>>>> Hi all,
>>>>
>>>> I prepared the webrev for the changes discussed below:
>>>> http://cr.openjdk.java.net/~goetz/webrevs/8003853/
>>>>
>>>> To fix the issues we have with the PPC port with finding ICs, this
>>>> change
>>>> cleans up the code handling compiled static Java calls:
>>>> - Methods using native instructions are moved from compiledIC.cpp
>>>>     to compiledIC_.cpp.
>>>> - Methods emitting the call patched by CompiledStaticCall are
>>>>     moved from the ad file to this class.
>>>>     As a side effect this reduces redundancies in x86_64.ad and
>>>> x86_32.ad.
>>>> - We get rid of extern declarations in output.cpp.
>>> I like this.  Two comments:
>>>
>>> 1) Does it make sense to have emit_to_interp_stub when it's only used
>>> in one place?
>>>
>>> 2) Before we can push this someone has to do the same thing for ARM
>>> and PPC.  Any volunteers from the embedded team?
>>>
>>> -- Chris
>>>
>>>> Now all code concerning CompiledStaticCalls is collected in one class.
>>>> The PPC port needs not change shared code any more to implement them.
>>>> I also got around to move code to MacroAssembler, as only a simple call
>>>> was needed on x86 and sparc.
>>>>
>>>> Probably this is (M) now, no more (S).
>>>>
>>>> Please review and send comments.  I'll be happy to adapt to them!
>>>>
>>>> Best regards,
>>>>    Goetz Lindenmaier
>>>>
>>>> -----Original Message-----
>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>> Sent: Thursday, April 11, 2013 4:50 AM
>>>> To: Lindenmaier, Goetz
>>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in
>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in
>>>> java_to_interp stub.]
>>>>
>>>>
>>>> On Apr 9, 2013, at 7:35 AM, "Lindenmaier, Goetz"
>>>>  wrote:
>>>>
>>>>> Hi Chris,
>>>>>
>>>>> I'm now working on this issue.  Sorry for the delay...
>>>>>
>>>>> What do you think about moving
>>>>>     void emit_java_to_interp(CodeBuffer& cbuf);
>>>>> and
>>>>>    void size_java_to_interp();
>>>>> to compiledIC.hpp and the new platform file, too?
>>>> I like that.
>>>>
>>>>> This would also allow to overcome the ugly
>>>>>    extern uint size_java_to_interp();
>>>>> in output.cpp, as it could be replaced by
>>>>> CompiledStaticCall::size_java_to_interp().
>>>> Great.
>>>>
>>>>> I also would like to name this
>>>>> CompiledStaticCall::emit_to_interp_stub()
>>>>> CompiledStaticCall::to_interp_stub_size()
>>>> I'm okay with that.  Not sure if others have objections.
>>>>
>>>>> I could also extract code from enc_class Java_Static_Call
>>>>> to form a routine
>>>>> CompiledStaticCall::emit_call(CodeBuffer *cbuf, intptr_t
>>>>> entry_point, relocInfo::relocType rtype) {
>>>>>     emit_call_reloc(cbuf, entry_point, rtype)
>>>>>     if (rtype != relocInfo::runtime_call_type) {
>>>>>         emit_java_to_interp(cbuf);
>>>>>       }
>>>>> }
>>>>> With this, also
>>>>> extern uint reloc_java_to_interp();
>>>>> from output.cpp could be moved into this class.
>>>> On SPARC only or the other architectures as well?
>>>>
>>>>> Then handling of CompiledStaticCalls would be completely
>>>>> implemented in this
>>>>> one class.
>>>> That's tempting.
>>>>
>>>>> (I would have to move emit_call_reloc to MacroAssembler.)
>>>> Could you send a webrev with these changes?
>>>>
>>>> -- Chris
>>>>
>>>>> Best regards,
>>>>> Goetz.
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>> Sent: Montag, 25. M?rz 2013 23:29
>>>>> To: Lindenmaier, Goetz
>>>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in
>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in
>>>>> java_to_interp stub.]
>>>>>
>>>>>
>>>>> On Mar 4, 2013, at 8:34 AM, "Lindenmaier, Goetz"
>>>>>  wrote:
>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> I would like to take up this issue again.
>>>>>> I'm about to put our changes on the jdk8 branch, and it would be
>>>>>> convenient
>>>>>> to have a final solution for this.
>>>>>>
>>>>>> Should I prepare a webrev with a different solution adding a new file
>>>>>> for this?  What should go into that file?
>>>>> Sorry for answering that late.
>>>>>
>>>>> Yes, to see a patch for that would be good.  We need to put all
>>>>> platform dependent Compiled* methods in that new file. Platform
>>>>> dependent means every method that uses a native* method from
>>>>> nativeInst_:
>>>>>
>>>>> CompiledIC::cleanup_call_site
>>>>> CompiledIC::is_icholder_call_site
>>>>> CompiledIC::CompiledIC
>>>>>
>>>>> CompiledStaticCall::set_to_interpreted
>>>>> CompiledStaticCall::set_stub_to_clean
>>>>> CompiledStaticCall::verify
>>>>>
>>>>> -- Chris
>>>>>
>>>>>> Best regards,
>>>>>> Goetz.
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: goetz.lindenmaier at sap.com
>>>>>> Sent: Dienstag, 18. Dezember 2012 10:42
>>>>>> To: 'Christian Thalinger'
>>>>>> Subject: RE: RFR (S): 8003853: specify offset of IC load in
>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load
>>>>>> in java_to_interp stub.]
>>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> What would you put into that file?  The offset, or the class
>>>>>> CompiledStaticCall?
>>>>>> You could also put it into nativeInst_  to avoid adding
>>>>>> another file.
>>>>>>
>>>>>> But basically I think the offset is the best solution, because
>>>>>> it's very small
>>>>>> and straight forward, and the offset is set where the code is
>>>>>> generated
>>>>>> that defines the offset.
>>>>>>
>>>>>> Only the #ifndef COMPILER2 is ugly, but here I think the solution
>>>>>> is to
>>>>>> guard the whole class CompiledStaticCall with #ifdef COMPILER2.
>>>>>>
>>>>>> But I'm happy with any placement of the code.
>>>>>>
>>>>>> Best regards,
>>>>>> Goetz.
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>> Sent: Montag, 17. Dezember 2012 21:34
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in
>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load
>>>>>> in java_to_interp stub.]
>>>>>>
>>>>>>
>>>>>> On Nov 29, 2012, at 2:10 PM, "Lindenmaier, Goetz"
>>>>>>  wrote:
>>>>>>
>>>>>>> Hi Chris,
>>>>>>>
>>>>>>> Loading the constant takes 5 instructions, the other way only three,
>>>>>>> in the code only one, if the constant pool base is in a register.
>>>>>>> The 5 instructions are hard to patch atomically.  The constant pool
>>>>>>> is just a 64 bit store.
>>>>>>>
>>>>>>>> Sorry for being so persistent on this :-)
>>>>>>> That's ok, I already found several places in our VM where it was
>>>>>>> easy to
>>>>>>> change our code to get along without the shared changes we did in
>>>>>>> first place.  But I can't redesign everything, and I can not risk
>>>>>>> to break
>>>>>>> anything in our product.
>>>>>>>
>>>>>>> If you feel like doing so, you can have a look at
>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/600ce596eea9
>>>>>>>
>>>>>>> which contains our bytecode interpreter profiling implementation.
>>>>>>> If you think this is currently of use in the main branch, I would
>>>>>>> lift it to HS25
>>>>>>> (the permgen changes might cause trouble) and contribute it to hsx.
>>>>>> Sorry for the long delay.
>>>>>>
>>>>>> Thinking about this problem again it seems that the correct
>>>>>> solution would be to have a compiledIC_.cpp file.
>>>>>>
>>>>>> The CompiledIC instruction layout is platform dependent; it just
>>>>>> happens to be the same for all architectures we have right now
>>>>>> (well, except PPC) because we made it to be the same.  Actually on
>>>>>> SPARC we could also use a load from the constant table which would
>>>>>> be simpler.
>>>>>>
>>>>>> Having a platform dependent file for this code feels right.  What
>>>>>> do you think?
>>>>>>
>>>>>> -- Chris
>>>>>>
>>>>>>> Best regards,
>>>>>>> Goetz.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>> Sent: Thursday, November 29, 2012 7:53 PM
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in
>>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load
>>>>>>> in java_to_interp stub.]
>>>>>>>
>>>>>>>
>>>>>>> On Nov 29, 2012, at 12:27 AM, "Lindenmaier, Goetz"
>>>>>>>  wrote:
>>>>>>>
>>>>>>>> Hi Chris,
>>>>>>>>
>>>>>>>>> Why can't you point the relocation to the method load
>>>>>>>>> instruction?  It doesn't seem right to do that in shared code.
>>>>>>>> Because the relocation is used
>>>>>>>> 1.) to find the beginning of the stub to patch the call to go there
>>>>>>>> 2.) to find the load to patch the IC.
>>>>>>> Got it.
>>>>>>>
>>>>>>>> Just have a look at CompiledStaticCall::set_to_interpreted(),
>>>>>>>> the variable 'stub' is used twice.
>>>>>>> Sorry for being so persistent on this :-)  What is the reason you
>>>>>>> have to load the constant from the constant table?  On other
>>>>>>> architectures we materialize the constant.
>>>>>>>
>>>>>>> -- Chris
>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Goetz.
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>>> Sent: Donnerstag, 29. November 2012 01:35
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in
>>>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load
>>>>>>>> in java_to_interp stub.]
>>>>>>>>
>>>>>>>>
>>>>>>>> On Nov 27, 2012, at 4:24 AM, "Lindenmaier, Goetz"
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>> Hi Chris,
>>>>>>>>>
>>>>>>>>>> Why do you need all these shared code changes when you have
>>>>>>>>>> this in emit_java_to_interp_stub?
>>>>>>>>> Shared code (class CompiledStaticCall) wants to patch the
>>>>>>>>> inline cache
>>>>>>>>> in the stub which is emitted in platform code.
>>>>>>>>> So the platform code should specify how the shared code can
>>>>>>>>> find the inline cache
>>>>>>>>> in the stub, which it does through the constant I introduced.
>>>>>>>>>
>>>>>>>>>> Do you need two relocations?  I'm confused.
>>>>>>>>> No, three ;)
>>>>>>>>> The relocation you mention is used to find the stub given the
>>>>>>>>> call.
>>>>>>>>> The other relocations are needed to find the inline cache /
>>>>>>>>> call target
>>>>>>>>> once the stub is found (see
>>>>>>>>> CompiledStaticCall::set_to_interpreted()).
>>>>>>>>> It's just the same on x86_64:
>>>>>>>>>
>>>>>>>>> // static stub relocation stores the instruction address of the
>>>>>>>>> call
>>>>>>>>> __ relocate(static_stub_Relocation::spec(mark), RELOC_IMM64);
>>>>>>>>> // static stub relocation also tags the methodOop in the
>>>>>>>>> code-stream.
>>>>>>>>> __ movoop(rbx, (jobject) NULL);  // method is zapped till fixup
>>>>>>>>> time
>>>>>>>>> // This is recognized as unresolved by relocs/nativeinst/ic code
>>>>>>>>> __ jump(RuntimeAddress(__ pc()));
>>>>>>>>>
>>>>>>>>> On PPC, we have to load the base of the constant table after
>>>>>>>>> generating the
>>>>>>>>> static_stub_relocation and before emitting the ppc equivalent
>>>>>>>>> for moveoop(). This offset is
>>>>>>>>> exactly what we store in the
>>>>>>>>> CompiledStaticCall::comp_to_int_load_offset constant.
>>>>>>>> Why can't you point the relocation to the method load
>>>>>>>> instruction?  It doesn't seem right to do that in shared code.
>>>>>>>>
>>>>>>>> -- Chris
>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Goetz.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>>>> Sent: Dienstag, 27. November 2012 01:53
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in
>>>>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC
>>>>>>>>> load in java_to_interp stub.]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz"
>>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>>> Hi Chris,
>>>>>>>>>>
>>>>>>>>>> We put it into the ad file because it describes an offset into
>>>>>>>>>> the stub that is
>>>>>>>>>> generated from the ad file by emit_java_to_interp(CodeBuffer&
>>>>>>>>>> cbuf),
>>>>>>>>>> used by ir  node CallStaticJavaDirect.  Maybe I should not
>>>>>>>>>> call it stub, but it's
>>>>>>>>>> generated into the stubs section of the code buffer.
>>>>>>>>>> If that stub generator is moved out of the ad file to shared
>>>>>>>>>> compiler code, one should
>>>>>>>>>> move the field with it, but for the current implementation I
>>>>>>>>>> think that's fine.
>>>>>>>>>>
>>>>>>>>>> Does C1 generate the same stub? Or is the CompiledStaticCall a
>>>>>>>>>> C2 feature?
>>>>>>>>>> If so, one could protect the whole thing by #ifdef COMPILER2.
>>>>>>>>> Why do you need all these shared code changes when you have
>>>>>>>>> this in emit_java_to_interp_stub?
>>>>>>>>>
>>>>>>>>> // Create a static stub relocation which relates this stub
>>>>>>>>> // with the call instruction at insts_call_instruction_offset
>>>>>>>>> in the
>>>>>>>>> // instructions code-section.
>>>>>>>>> __ relocate(static_stub_Relocation::spec(__
>>>>>>>>> code()->insts()->start() + insts_relocation_offset));
>>>>>>>>>
>>>>>>>>> Do you need two relocations?  I'm confused.
>>>>>>>>>
>>>>>>>>> -- Chris
>>>>>>>>>
>>>>>>>>>> Thanks for all the bugids!
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Goetz.
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>>>>> Sent: Mittwoch, 21. November 2012 19:53
>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>>> Subject: RFR (S): 8003853: specify offset of IC load in
>>>>>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC
>>>>>>>>>> load in java_to_interp stub.]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz"
>>>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Chris,
>>>>>>>>>>>
>>>>>>>>>>> yes, there is no C1 on ppc.
>>>>>>>>>>> We do tiered compilation with a stripped C2.
>>>>>>>>>> Right.  But some other architecture (or in the future) might
>>>>>>>>>> need this for C1 as well.  We should find a better place for
>>>>>>>>>> the value than the ad file.  The obvious place would be
>>>>>>>>>> compiledIC_.hpp but we don't have that file, yet.
>>>>>>>>>>
>>>>>>>>>> I filed:
>>>>>>>>>>
>>>>>>>>>> 8003853: specify offset of IC load in java_to_interp stub
>>>>>>>>>>
>>>>>>>>>> -- Chris
>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Goetz
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Christian Thalinger
>>>>>>>>>>> [mailto:christian.thalinger at oracle.com]
>>>>>>>>>>> Sent: Dienstag, 20. November 2012 22:19
>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>>>> Subject: Re: RFR (S): Specify offset of IC load in
>>>>>>>>>>> java_to_interp stub.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz"
>>>>>>>>>>>  wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> The class CompiledStaticCall must know the location of the
>>>>>>>>>>>> IC load in the java_to_interp stub
>>>>>>>>>>>> to update the IC  with NativeMovConstReg.  The current
>>>>>>>>>>>> implementation assumes that
>>>>>>>>>>>> the load is always the first instruction in the stub.  This
>>>>>>>>>>>> is an artificial restriction. E.g.,
>>>>>>>>>>>> it might be useful to load the constant pool address
>>>>>>>>>>>> (MachConstantBase) before the
>>>>>>>>>>>> IC load (as we do on PPC).
>>>>>>>>>>>>
>>>>>>>>>>>> This change adds a constant specifying an offset from the
>>>>>>>>>>>> beginning of the stub to
>>>>>>>>>>>> the  IC load. The offset is platform specific and 0 on sparc
>>>>>>>>>>>> and x86.
>>>>>>>>>>>>
>>>>>>>>>>>> You can find the change here:
>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/
>>>>>>>>>>> That should be fixed indeed.
>>>>>>>>>>>
>>>>>>>>>>> +#ifndef COMPILER2
>>>>>>>>>>> +const int CompiledStaticCall::comp_to_int_load_offset = 0;
>>>>>>>>>>>
>>>>>>>>>>> There is no C1 for PPC (sorry, I didn't check)?
>>>>>>>>>>>
>>>>>>>>>>> -- Chris
>>>>>>>>>>>
>>>>>>>>>>>> or in our ppc port:
>>>>>>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you and best regards,
>>>>>>>>>>>> Goetz
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>


From vladimir.x.ivanov at oracle.com  Wed Apr 17 08:19:38 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 17 Apr 2013 19:19:38 +0400
Subject: RFR (S): 8012260: ciReplay: Include PID into the name of replay
	data file
In-Reply-To: <516E3191.4020401@oracle.com>
References: <516DE649.9020105@oracle.com> <516E3191.4020401@oracle.com>
Message-ID: <516EBD8A.9090009@oracle.com>

Thanks for feedback, Vladimir!

Here's updated version:
http://cr.openjdk.java.net/~vlivanov/8012260/webrev.01

Best regards,
Vladimir Ivanov

On 4/17/13 9:22 AM, Vladimir Kozlov wrote:
> Make it product flag since it is ON by default (and it is not diagnostic
> but error dump).
>
> Also why not reuse code which opens ErrorFile (hs_err*)?
>
> Compilation::compile_only_this_method() allocates fileStream on stack:
>
>    fileStream stream(fopen("c1_compile_only", "wt"));
>
> thanks,
> Vladimir
>
> On 4/16/13 5:01 PM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.00
>> 43 lines changed: 16 ins; 21 del; 6 mod;
>>
>> Changed naming scheme for compilation replay data files from
>> 'replay.txt' to 'replay_pid%p.log', where %p is substituted w/ pid. It
>> allows to easily correspond replay file with hs_err file and makes
>> overwriting of existing files very unlikely.
>>
>> Also, converted ReplayDataFile & DumpReplayDataOnError flags from
>> develop to diagnostic, since they are useful in product binaries. Did
>> some small cleanups.
>>
>> One question still bothers me. There's a memory allocation in
>> VMError::report_and_die() I don't know how to avoid:
>> +         fileStream* replay_data_stream = new (ResourceObj::C_HEAP,
>> mtCompiler) fileStream(replay_data_file);
>>
>> It's not new, I just moved it up from auxiliary method. Any ideas how to
>> make VMError::report_and_die() allocation-free again? :-)
>>
>> Best regards,
>> Vladimir Ivanov
>>

From dean.long at oracle.com  Wed Apr 17 08:42:13 2013
From: dean.long at oracle.com (Dean Long)
Date: Wed, 17 Apr 2013 08:42:13 -0700
Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp
	stub [Was: Re: RFR (S): Specify offset of IC load in
	java_to_interp	stub.]
In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFB3999@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC0CFA7D32@DEWDFEMB12A.global.corp.sap>
	<03C4DFDE-CD52-446E-92AA-A6F12903FE29@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB116E@DEWDFEMB12A.global.corp.sap>
	<7D07437F-CFF7-4298-B9A1-DE9F2E32D77D@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB1EDE@DEWDFEMB12A.global.corp.sap>
	<8A8B46F8-0C91-4E8C-950A-0E65095DB2E0@oracle.com>
	<516CD9A3.3030202@oracle.com> <516CDF6A.4080900@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB36A3@DEWDFEMB12A.global.corp.sap>
	<516D7ACE.9010305@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB3999@DEWDFEMB12A.global.corp.sap>
Message-ID: <516EC2D5.1040500@oracle.com>

Hi Goetz,

On 4/17/2013 3:54 AM, Lindenmaier, Goetz wrote:
> Hi,
>
>> The motivation for keeping the call code in the .ad file is because it
>> has to match what MachCall*Node::ret_addr_offset()
>> is returning.
> I see. If one would change the call in the compiledIC_.cpp this function
> would have to be adapted.
>
> On the other side, if somebody changes the relocations in emit_call_reloc,
> he has to adapt CompiledStaticCall::reloc_to_interp_stub().
>
> This is all quite entangled, so we will not find a completely clean version.
> I'm fine with any version, it has no effect on the ppc port.
It also simplifies the port to our embedded platforms, so if you're fine 
with my suggestion then
could you send a new webrev with that version?

thanks,

dl

> Best regards,
>    Goetz.
>
> -----Original Message-----
> From: Dean Long [mailto:dean.long at oracle.com]
> Sent: Dienstag, 16. April 2013 18:23
> To: Lindenmaier, Goetz
> Cc: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>
> What I'm suggesting is leaving all calls in the .ad file. "enc_class
> Java_Static_Call" would remain largely unchanged
> except renaming emit_java_to_interp() to
> CompiledStaticCall::emit_to_interp_stub() .
> The motivation for keeping the call code in the .ad file is because it
> has to match what MachCall*Node::ret_addr_offset()
> is returning.
>
> compiledIC.hpp:
> +  // Code
> +  static void emit_to_interp_stub(CodeBuffer &cbuf);
> +  static uint to_interp_stub_size();
> +  static uint reloc_to_interp_stub();
>
> dl
>
> On 4/16/2013 7:22 AM, Lindenmaier, Goetz wrote:
>> Hi Dean,
>>
>> I left the runtime call in the ad file, as it's got nothing to do with
>> CompiledStaticCalls that call Java.
>>
>> I thought this is a better separation of concerns.
>> Anyways, you would have to pass in _method and
>> _optimized_virtual, which are fields of the machnode.
>>
>> Best regards,
>>     Goetz.
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Dean Long
>> Sent: Dienstag, 16. April 2013 07:20
>> To: hotspot-compiler-dev at openjdk.java.net
>> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.]
>>
>> Also, is moving the call into CompiledStaticCall::emit_call() really
>> needed for PPC?  I'd prefer to move the
>> stub emitter instead (sample sparc code):
>>
>>        if ( !_method ) {
>>          emit_call_reloc(cbuf, $meth$$method, relocInfo::runtime_call_type);
>>        } else if (_optimized_virtual) {
>>          emit_call_reloc(cbuf, $meth$$method,
>> relocInfo::opt_virtual_call_type);
>>        } else {
>>          emit_call_reloc(cbuf, $meth$$method, relocInfo::static_call_type);
>>        }
>>        if( _method ) {  // Emit stub for static call
>>          CompiledStaticCall::emit_java_to_interp(cbuf);<---
>>        }
>>
>> dl
>>
>> On 4/15/2013 9:54 PM, Dean Long wrote:
>>> sparc.ad:
>>>
>>> 2538       CompiledStaticCall::emit_call(cbuf,
>>> 2539                                     (int) ($meth$$method -
>>> ((intptr_t) cbuf.insts_end()) - 4),
>>> 2540                                     rtype);
>>>
>>> I think this should be:
>>>
>>> CompiledStaticCall::emit_call(cbuf,$meth$$method,  rtype);
>>>
>>> Computing the PC-relative offset probably only applies to x86.
>>>
>>> dl
>>>
>>> On 4/12/2013 2:03 PM, Christian Thalinger wrote:
>>>> On Apr 11, 2013, at 2:46 PM, "Lindenmaier, Goetz"
>>>>  wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I prepared the webrev for the changes discussed below:
>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8003853/
>>>>>
>>>>> To fix the issues we have with the PPC port with finding ICs, this
>>>>> change
>>>>> cleans up the code handling compiled static Java calls:
>>>>> - Methods using native instructions are moved from compiledIC.cpp
>>>>>      to compiledIC_.cpp.
>>>>> - Methods emitting the call patched by CompiledStaticCall are
>>>>>      moved from the ad file to this class.
>>>>>      As a side effect this reduces redundancies in x86_64.ad and
>>>>> x86_32.ad.
>>>>> - We get rid of extern declarations in output.cpp.
>>>> I like this.  Two comments:
>>>>
>>>> 1) Does it make sense to have emit_to_interp_stub when it's only used
>>>> in one place?
>>>>
>>>> 2) Before we can push this someone has to do the same thing for ARM
>>>> and PPC.  Any volunteers from the embedded team?
>>>>
>>>> -- Chris
>>>>
>>>>> Now all code concerning CompiledStaticCalls is collected in one class.
>>>>> The PPC port needs not change shared code any more to implement them.
>>>>> I also got around to move code to MacroAssembler, as only a simple call
>>>>> was needed on x86 and sparc.
>>>>>
>>>>> Probably this is (M) now, no more (S).
>>>>>
>>>>> Please review and send comments.  I'll be happy to adapt to them!
>>>>>
>>>>> Best regards,
>>>>>     Goetz Lindenmaier
>>>>>
>>>>> -----Original Message-----
>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>> Sent: Thursday, April 11, 2013 4:50 AM
>>>>> To: Lindenmaier, Goetz
>>>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in
>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in
>>>>> java_to_interp stub.]
>>>>>
>>>>>
>>>>> On Apr 9, 2013, at 7:35 AM, "Lindenmaier, Goetz"
>>>>>  wrote:
>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> I'm now working on this issue.  Sorry for the delay...
>>>>>>
>>>>>> What do you think about moving
>>>>>>      void emit_java_to_interp(CodeBuffer& cbuf);
>>>>>> and
>>>>>>     void size_java_to_interp();
>>>>>> to compiledIC.hpp and the new platform file, too?
>>>>> I like that.
>>>>>
>>>>>> This would also allow to overcome the ugly
>>>>>>     extern uint size_java_to_interp();
>>>>>> in output.cpp, as it could be replaced by
>>>>>> CompiledStaticCall::size_java_to_interp().
>>>>> Great.
>>>>>
>>>>>> I also would like to name this
>>>>>> CompiledStaticCall::emit_to_interp_stub()
>>>>>> CompiledStaticCall::to_interp_stub_size()
>>>>> I'm okay with that.  Not sure if others have objections.
>>>>>
>>>>>> I could also extract code from enc_class Java_Static_Call
>>>>>> to form a routine
>>>>>> CompiledStaticCall::emit_call(CodeBuffer *cbuf, intptr_t
>>>>>> entry_point, relocInfo::relocType rtype) {
>>>>>>      emit_call_reloc(cbuf, entry_point, rtype)
>>>>>>      if (rtype != relocInfo::runtime_call_type) {
>>>>>>          emit_java_to_interp(cbuf);
>>>>>>        }
>>>>>> }
>>>>>> With this, also
>>>>>> extern uint reloc_java_to_interp();
>>>>>> from output.cpp could be moved into this class.
>>>>> On SPARC only or the other architectures as well?
>>>>>
>>>>>> Then handling of CompiledStaticCalls would be completely
>>>>>> implemented in this
>>>>>> one class.
>>>>> That's tempting.
>>>>>
>>>>>> (I would have to move emit_call_reloc to MacroAssembler.)
>>>>> Could you send a webrev with these changes?
>>>>>
>>>>> -- Chris
>>>>>
>>>>>> Best regards,
>>>>>> Goetz.
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>> Sent: Montag, 25. M?rz 2013 23:29
>>>>>> To: Lindenmaier, Goetz
>>>>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in
>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in
>>>>>> java_to_interp stub.]
>>>>>>
>>>>>>
>>>>>> On Mar 4, 2013, at 8:34 AM, "Lindenmaier, Goetz"
>>>>>>  wrote:
>>>>>>
>>>>>>> Hi Chris,
>>>>>>>
>>>>>>> I would like to take up this issue again.
>>>>>>> I'm about to put our changes on the jdk8 branch, and it would be
>>>>>>> convenient
>>>>>>> to have a final solution for this.
>>>>>>>
>>>>>>> Should I prepare a webrev with a different solution adding a new file
>>>>>>> for this?  What should go into that file?
>>>>>> Sorry for answering that late.
>>>>>>
>>>>>> Yes, to see a patch for that would be good.  We need to put all
>>>>>> platform dependent Compiled* methods in that new file. Platform
>>>>>> dependent means every method that uses a native* method from
>>>>>> nativeInst_:
>>>>>>
>>>>>> CompiledIC::cleanup_call_site
>>>>>> CompiledIC::is_icholder_call_site
>>>>>> CompiledIC::CompiledIC
>>>>>>
>>>>>> CompiledStaticCall::set_to_interpreted
>>>>>> CompiledStaticCall::set_stub_to_clean
>>>>>> CompiledStaticCall::verify
>>>>>>
>>>>>> -- Chris
>>>>>>
>>>>>>> Best regards,
>>>>>>> Goetz.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: goetz.lindenmaier at sap.com
>>>>>>> Sent: Dienstag, 18. Dezember 2012 10:42
>>>>>>> To: 'Christian Thalinger'
>>>>>>> Subject: RE: RFR (S): 8003853: specify offset of IC load in
>>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load
>>>>>>> in java_to_interp stub.]
>>>>>>>
>>>>>>> Hi Chris,
>>>>>>>
>>>>>>> What would you put into that file?  The offset, or the class
>>>>>>> CompiledStaticCall?
>>>>>>> You could also put it into nativeInst_  to avoid adding
>>>>>>> another file.
>>>>>>>
>>>>>>> But basically I think the offset is the best solution, because
>>>>>>> it's very small
>>>>>>> and straight forward, and the offset is set where the code is
>>>>>>> generated
>>>>>>> that defines the offset.
>>>>>>>
>>>>>>> Only the #ifndef COMPILER2 is ugly, but here I think the solution
>>>>>>> is to
>>>>>>> guard the whole class CompiledStaticCall with #ifdef COMPILER2.
>>>>>>>
>>>>>>> But I'm happy with any placement of the code.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Goetz.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>> Sent: Montag, 17. Dezember 2012 21:34
>>>>>>> To: Lindenmaier, Goetz
>>>>>>> Cc: 'hotspot-compiler-dev at openjdk.java.net'
>>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in
>>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load
>>>>>>> in java_to_interp stub.]
>>>>>>>
>>>>>>>
>>>>>>> On Nov 29, 2012, at 2:10 PM, "Lindenmaier, Goetz"
>>>>>>>  wrote:
>>>>>>>
>>>>>>>> Hi Chris,
>>>>>>>>
>>>>>>>> Loading the constant takes 5 instructions, the other way only three,
>>>>>>>> in the code only one, if the constant pool base is in a register.
>>>>>>>> The 5 instructions are hard to patch atomically.  The constant pool
>>>>>>>> is just a 64 bit store.
>>>>>>>>
>>>>>>>>> Sorry for being so persistent on this :-)
>>>>>>>> That's ok, I already found several places in our VM where it was
>>>>>>>> easy to
>>>>>>>> change our code to get along without the shared changes we did in
>>>>>>>> first place.  But I can't redesign everything, and I can not risk
>>>>>>>> to break
>>>>>>>> anything in our product.
>>>>>>>>
>>>>>>>> If you feel like doing so, you can have a look at
>>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/600ce596eea9
>>>>>>>>
>>>>>>>> which contains our bytecode interpreter profiling implementation.
>>>>>>>> If you think this is currently of use in the main branch, I would
>>>>>>>> lift it to HS25
>>>>>>>> (the permgen changes might cause trouble) and contribute it to hsx.
>>>>>>> Sorry for the long delay.
>>>>>>>
>>>>>>> Thinking about this problem again it seems that the correct
>>>>>>> solution would be to have a compiledIC_.cpp file.
>>>>>>>
>>>>>>> The CompiledIC instruction layout is platform dependent; it just
>>>>>>> happens to be the same for all architectures we have right now
>>>>>>> (well, except PPC) because we made it to be the same.  Actually on
>>>>>>> SPARC we could also use a load from the constant table which would
>>>>>>> be simpler.
>>>>>>>
>>>>>>> Having a platform dependent file for this code feels right.  What
>>>>>>> do you think?
>>>>>>>
>>>>>>> -- Chris
>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Goetz.
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>>> Sent: Thursday, November 29, 2012 7:53 PM
>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in
>>>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load
>>>>>>>> in java_to_interp stub.]
>>>>>>>>
>>>>>>>>
>>>>>>>> On Nov 29, 2012, at 12:27 AM, "Lindenmaier, Goetz"
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>> Hi Chris,
>>>>>>>>>
>>>>>>>>>> Why can't you point the relocation to the method load
>>>>>>>>>> instruction?  It doesn't seem right to do that in shared code.
>>>>>>>>> Because the relocation is used
>>>>>>>>> 1.) to find the beginning of the stub to patch the call to go there
>>>>>>>>> 2.) to find the load to patch the IC.
>>>>>>>> Got it.
>>>>>>>>
>>>>>>>>> Just have a look at CompiledStaticCall::set_to_interpreted(),
>>>>>>>>> the variable 'stub' is used twice.
>>>>>>>> Sorry for being so persistent on this :-)  What is the reason you
>>>>>>>> have to load the constant from the constant table?  On other
>>>>>>>> architectures we materialize the constant.
>>>>>>>>
>>>>>>>> -- Chris
>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Goetz.
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>>>> Sent: Donnerstag, 29. November 2012 01:35
>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in
>>>>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load
>>>>>>>>> in java_to_interp stub.]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Nov 27, 2012, at 4:24 AM, "Lindenmaier, Goetz"
>>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>>> Hi Chris,
>>>>>>>>>>
>>>>>>>>>>> Why do you need all these shared code changes when you have
>>>>>>>>>>> this in emit_java_to_interp_stub?
>>>>>>>>>> Shared code (class CompiledStaticCall) wants to patch the
>>>>>>>>>> inline cache
>>>>>>>>>> in the stub which is emitted in platform code.
>>>>>>>>>> So the platform code should specify how the shared code can
>>>>>>>>>> find the inline cache
>>>>>>>>>> in the stub, which it does through the constant I introduced.
>>>>>>>>>>
>>>>>>>>>>> Do you need two relocations?  I'm confused.
>>>>>>>>>> No, three ;)
>>>>>>>>>> The relocation you mention is used to find the stub given the
>>>>>>>>>> call.
>>>>>>>>>> The other relocations are needed to find the inline cache /
>>>>>>>>>> call target
>>>>>>>>>> once the stub is found (see
>>>>>>>>>> CompiledStaticCall::set_to_interpreted()).
>>>>>>>>>> It's just the same on x86_64:
>>>>>>>>>>
>>>>>>>>>> // static stub relocation stores the instruction address of the
>>>>>>>>>> call
>>>>>>>>>> __ relocate(static_stub_Relocation::spec(mark), RELOC_IMM64);
>>>>>>>>>> // static stub relocation also tags the methodOop in the
>>>>>>>>>> code-stream.
>>>>>>>>>> __ movoop(rbx, (jobject) NULL);  // method is zapped till fixup
>>>>>>>>>> time
>>>>>>>>>> // This is recognized as unresolved by relocs/nativeinst/ic code
>>>>>>>>>> __ jump(RuntimeAddress(__ pc()));
>>>>>>>>>>
>>>>>>>>>> On PPC, we have to load the base of the constant table after
>>>>>>>>>> generating the
>>>>>>>>>> static_stub_relocation and before emitting the ppc equivalent
>>>>>>>>>> for moveoop(). This offset is
>>>>>>>>>> exactly what we store in the
>>>>>>>>>> CompiledStaticCall::comp_to_int_load_offset constant.
>>>>>>>>> Why can't you point the relocation to the method load
>>>>>>>>> instruction?  It doesn't seem right to do that in shared code.
>>>>>>>>>
>>>>>>>>> -- Chris
>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Goetz.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>>>>> Sent: Dienstag, 27. November 2012 01:53
>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>>> Subject: Re: RFR (S): 8003853: specify offset of IC load in
>>>>>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC
>>>>>>>>>> load in java_to_interp stub.]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz"
>>>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Chris,
>>>>>>>>>>>
>>>>>>>>>>> We put it into the ad file because it describes an offset into
>>>>>>>>>>> the stub that is
>>>>>>>>>>> generated from the ad file by emit_java_to_interp(CodeBuffer&
>>>>>>>>>>> cbuf),
>>>>>>>>>>> used by ir  node CallStaticJavaDirect.  Maybe I should not
>>>>>>>>>>> call it stub, but it's
>>>>>>>>>>> generated into the stubs section of the code buffer.
>>>>>>>>>>> If that stub generator is moved out of the ad file to shared
>>>>>>>>>>> compiler code, one should
>>>>>>>>>>> move the field with it, but for the current implementation I
>>>>>>>>>>> think that's fine.
>>>>>>>>>>>
>>>>>>>>>>> Does C1 generate the same stub? Or is the CompiledStaticCall a
>>>>>>>>>>> C2 feature?
>>>>>>>>>>> If so, one could protect the whole thing by #ifdef COMPILER2.
>>>>>>>>>> Why do you need all these shared code changes when you have
>>>>>>>>>> this in emit_java_to_interp_stub?
>>>>>>>>>>
>>>>>>>>>> // Create a static stub relocation which relates this stub
>>>>>>>>>> // with the call instruction at insts_call_instruction_offset
>>>>>>>>>> in the
>>>>>>>>>> // instructions code-section.
>>>>>>>>>> __ relocate(static_stub_Relocation::spec(__
>>>>>>>>>> code()->insts()->start() + insts_relocation_offset));
>>>>>>>>>>
>>>>>>>>>> Do you need two relocations?  I'm confused.
>>>>>>>>>>
>>>>>>>>>> -- Chris
>>>>>>>>>>
>>>>>>>>>>> Thanks for all the bugids!
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Goetz.
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
>>>>>>>>>>> Sent: Mittwoch, 21. November 2012 19:53
>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>>>> Subject: RFR (S): 8003853: specify offset of IC load in
>>>>>>>>>>> java_to_interp stub [Was: Re: RFR (S): Specify offset of IC
>>>>>>>>>>> load in java_to_interp stub.]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz"
>>>>>>>>>>>  wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Chris,
>>>>>>>>>>>>
>>>>>>>>>>>> yes, there is no C1 on ppc.
>>>>>>>>>>>> We do tiered compilation with a stripped C2.
>>>>>>>>>>> Right.  But some other architecture (or in the future) might
>>>>>>>>>>> need this for C1 as well.  We should find a better place for
>>>>>>>>>>> the value than the ad file.  The obvious place would be
>>>>>>>>>>> compiledIC_.hpp but we don't have that file, yet.
>>>>>>>>>>>
>>>>>>>>>>> I filed:
>>>>>>>>>>>
>>>>>>>>>>> 8003853: specify offset of IC load in java_to_interp stub
>>>>>>>>>>>
>>>>>>>>>>> -- Chris
>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Goetz
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Christian Thalinger
>>>>>>>>>>>> [mailto:christian.thalinger at oracle.com]
>>>>>>>>>>>> Sent: Dienstag, 20. November 2012 22:19
>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>>>>>>>>>>> Subject: Re: RFR (S): Specify offset of IC load in
>>>>>>>>>>>> java_to_interp stub.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz"
>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> The class CompiledStaticCall must know the location of the
>>>>>>>>>>>>> IC load in the java_to_interp stub
>>>>>>>>>>>>> to update the IC  with NativeMovConstReg.  The current
>>>>>>>>>>>>> implementation assumes that
>>>>>>>>>>>>> the load is always the first instruction in the stub.  This
>>>>>>>>>>>>> is an artificial restriction. E.g.,
>>>>>>>>>>>>> it might be useful to load the constant pool address
>>>>>>>>>>>>> (MachConstantBase) before the
>>>>>>>>>>>>> IC load (as we do on PPC).
>>>>>>>>>>>>>
>>>>>>>>>>>>> This change adds a constant specifying an offset from the
>>>>>>>>>>>>> beginning of the stub to
>>>>>>>>>>>>> the  IC load. The offset is platform specific and 0 on sparc
>>>>>>>>>>>>> and x86.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You can find the change here:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/
>>>>>>>>>>>> That should be fixed indeed.
>>>>>>>>>>>>
>>>>>>>>>>>> +#ifndef COMPILER2
>>>>>>>>>>>> +const int CompiledStaticCall::comp_to_int_load_offset = 0;
>>>>>>>>>>>>
>>>>>>>>>>>> There is no C1 for PPC (sorry, I didn't check)?
>>>>>>>>>>>>
>>>>>>>>>>>> -- Chris
>>>>>>>>>>>>
>>>>>>>>>>>>> or in our ppc port:
>>>>>>>>>>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you and best regards,
>>>>>>>>>>>>> Goetz
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>


From vladimir.kozlov at oracle.com  Wed Apr 17 08:54:01 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 17 Apr 2013 08:54:01 -0700
Subject: RFR (S): 8012260: ciReplay: Include PID into the name of replay
	data file
In-Reply-To: <516EBD8A.9090009@oracle.com>
References: <516DE649.9020105@oracle.com> <516E3191.4020401@oracle.com>
	<516EBD8A.9090009@oracle.com>
Message-ID: <516EC599.5000401@oracle.com>

Missing check (fd != -1) before fdopen:

1036       FILE* replay_data_file = fdopen(fd, "w");

Vladimir

On 4/17/13 8:19 AM, Vladimir Ivanov wrote:
> Thanks for feedback, Vladimir!
>
> Here's updated version:
> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.01
>
> Best regards,
> Vladimir Ivanov
>
> On 4/17/13 9:22 AM, Vladimir Kozlov wrote:
>> Make it product flag since it is ON by default (and it is not diagnostic
>> but error dump).
>>
>> Also why not reuse code which opens ErrorFile (hs_err*)?
>>
>> Compilation::compile_only_this_method() allocates fileStream on stack:
>>
>>    fileStream stream(fopen("c1_compile_only", "wt"));
>>
>> thanks,
>> Vladimir
>>
>> On 4/16/13 5:01 PM, Vladimir Ivanov wrote:
>>> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.00
>>> 43 lines changed: 16 ins; 21 del; 6 mod;
>>>
>>> Changed naming scheme for compilation replay data files from
>>> 'replay.txt' to 'replay_pid%p.log', where %p is substituted w/ pid. It
>>> allows to easily correspond replay file with hs_err file and makes
>>> overwriting of existing files very unlikely.
>>>
>>> Also, converted ReplayDataFile & DumpReplayDataOnError flags from
>>> develop to diagnostic, since they are useful in product binaries. Did
>>> some small cleanups.
>>>
>>> One question still bothers me. There's a memory allocation in
>>> VMError::report_and_die() I don't know how to avoid:
>>> +         fileStream* replay_data_stream = new (ResourceObj::C_HEAP,
>>> mtCompiler) fileStream(replay_data_file);
>>>
>>> It's not new, I just moved it up from auxiliary method. Any ideas how to
>>> make VMError::report_and_die() allocation-free again? :-)
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>

From vladimir.x.ivanov at oracle.com  Wed Apr 17 09:03:46 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 17 Apr 2013 20:03:46 +0400
Subject: RFR (S): 8012260: ciReplay: Include PID into the name of replay
	data file
In-Reply-To: <516EC599.5000401@oracle.com>
References: <516DE649.9020105@oracle.com> <516E3191.4020401@oracle.com>
	<516EBD8A.9090009@oracle.com> <516EC599.5000401@oracle.com>
Message-ID: <516EC7E2.40401@oracle.com>

I considered it redundant since fdopen returns NULL when a call fails 
[1] and I already check replay_data_file. Was my reasoning wrong?

I checked on MacOS and when (fd == -1) it produces the following error 
message:
# Can't open file to dump replay data. Error: Bad file descriptor

Best regards,
Vladimir Ivanov

[1] Excerpt from fdopen man page:
RETURN VALUES
      Upon successful completion fopen(), fdopen(), and freopen() return 
a FILE pointer.  Otherwise, NULL is returned and the global variable 
errno is set to indicate the error.

On 4/17/13 7:54 PM, Vladimir Kozlov wrote:
> Missing check (fd != -1) before fdopen:
>
> 1036       FILE* replay_data_file = fdopen(fd, "w");
>
> Vladimir
>
> On 4/17/13 8:19 AM, Vladimir Ivanov wrote:
>> Thanks for feedback, Vladimir!
>>
>> Here's updated version:
>> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.01
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 4/17/13 9:22 AM, Vladimir Kozlov wrote:
>>> Make it product flag since it is ON by default (and it is not diagnostic
>>> but error dump).
>>>
>>> Also why not reuse code which opens ErrorFile (hs_err*)?
>>>
>>> Compilation::compile_only_this_method() allocates fileStream on stack:
>>>
>>>    fileStream stream(fopen("c1_compile_only", "wt"));
>>>
>>> thanks,
>>> Vladimir
>>>
>>> On 4/16/13 5:01 PM, Vladimir Ivanov wrote:
>>>> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.00
>>>> 43 lines changed: 16 ins; 21 del; 6 mod;
>>>>
>>>> Changed naming scheme for compilation replay data files from
>>>> 'replay.txt' to 'replay_pid%p.log', where %p is substituted w/ pid. It
>>>> allows to easily correspond replay file with hs_err file and makes
>>>> overwriting of existing files very unlikely.
>>>>
>>>> Also, converted ReplayDataFile & DumpReplayDataOnError flags from
>>>> develop to diagnostic, since they are useful in product binaries. Did
>>>> some small cleanups.
>>>>
>>>> One question still bothers me. There's a memory allocation in
>>>> VMError::report_and_die() I don't know how to avoid:
>>>> +         fileStream* replay_data_stream = new (ResourceObj::C_HEAP,
>>>> mtCompiler) fileStream(replay_data_file);
>>>>
>>>> It's not new, I just moved it up from auxiliary method. Any ideas
>>>> how to
>>>> make VMError::report_and_die() allocation-free again? :-)
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>

From vladimir.kozlov at oracle.com  Wed Apr 17 09:30:06 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 17 Apr 2013 09:30:06 -0700
Subject: RFR (S): 8012260: ciReplay: Include PID into the name of replay
	data file
In-Reply-To: <516EC7E2.40401@oracle.com>
References: <516DE649.9020105@oracle.com> <516E3191.4020401@oracle.com>
	<516EBD8A.9090009@oracle.com> <516EC599.5000401@oracle.com>
	<516EC7E2.40401@oracle.com>
Message-ID: <516ECE0E.8010006@oracle.com>

On 4/17/13 9:03 AM, Vladimir Ivanov wrote:
> I considered it redundant since fdopen returns NULL when a call fails
> [1] and I already check replay_data_file. Was my reasoning wrong?

My understanding was that you can't pass fd == -1 to fdopen() and I 
can't find any docs about such case so you may be right. And I am more 
concern about Windows/Cygwin implementation of fdopen.

Vladimir

>
> I checked on MacOS and when (fd == -1) it produces the following error
> message:
> # Can't open file to dump replay data. Error: Bad file descriptor
>
> Best regards,
> Vladimir Ivanov
>
> [1] Excerpt from fdopen man page:
> RETURN VALUES
>       Upon successful completion fopen(), fdopen(), and freopen() return
> a FILE pointer.  Otherwise, NULL is returned and the global variable
> errno is set to indicate the error.
>
> On 4/17/13 7:54 PM, Vladimir Kozlov wrote:
>> Missing check (fd != -1) before fdopen:
>>
>> 1036       FILE* replay_data_file = fdopen(fd, "w");
>>
>> Vladimir
>>
>> On 4/17/13 8:19 AM, Vladimir Ivanov wrote:
>>> Thanks for feedback, Vladimir!
>>>
>>> Here's updated version:
>>> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.01
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> On 4/17/13 9:22 AM, Vladimir Kozlov wrote:
>>>> Make it product flag since it is ON by default (and it is not
>>>> diagnostic
>>>> but error dump).
>>>>
>>>> Also why not reuse code which opens ErrorFile (hs_err*)?
>>>>
>>>> Compilation::compile_only_this_method() allocates fileStream on stack:
>>>>
>>>>    fileStream stream(fopen("c1_compile_only", "wt"));
>>>>
>>>> thanks,
>>>> Vladimir
>>>>
>>>> On 4/16/13 5:01 PM, Vladimir Ivanov wrote:
>>>>> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.00
>>>>> 43 lines changed: 16 ins; 21 del; 6 mod;
>>>>>
>>>>> Changed naming scheme for compilation replay data files from
>>>>> 'replay.txt' to 'replay_pid%p.log', where %p is substituted w/ pid. It
>>>>> allows to easily correspond replay file with hs_err file and makes
>>>>> overwriting of existing files very unlikely.
>>>>>
>>>>> Also, converted ReplayDataFile & DumpReplayDataOnError flags from
>>>>> develop to diagnostic, since they are useful in product binaries. Did
>>>>> some small cleanups.
>>>>>
>>>>> One question still bothers me. There's a memory allocation in
>>>>> VMError::report_and_die() I don't know how to avoid:
>>>>> +         fileStream* replay_data_stream = new (ResourceObj::C_HEAP,
>>>>> mtCompiler) fileStream(replay_data_file);
>>>>>
>>>>> It's not new, I just moved it up from auxiliary method. Any ideas
>>>>> how to
>>>>> make VMError::report_and_die() allocation-free again? :-)
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>>

From igor.ignatyev at oracle.com  Wed Apr 17 10:08:13 2013
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 17 Apr 2013 21:08:13 +0400
Subject: RFR(S) : 8011675: adding compilation level to replay data
In-Reply-To: <516D908E.9070408@oracle.com>
References: <51631AEA.9080702@oracle.com> <51635E89.30808@oracle.com>
	<5163BD9A.5080308@oracle.com> <5163C5F4.7020605@oracle.com>
	<516827EA.3040001@oracle.com> <5168874B.9080407@oracle.com>
	<5169AEA2.7060103@oracle.com> <516C7287.8070600@oracle.com>
	<516D76F4.9010305@oracle.com> <516D908E.9070408@oracle.com>
Message-ID: <516ED6FD.4080405@oracle.com>

http://cr.openjdk.java.net/~iignatyev/8011675/webrev.05/

> TestVM_no_comp_level.sh:
>
>    61     negative_test 10 -XX:-TieredCompilation -client
>    62     negative_test 11 -XX:+TieredCompilation -client
>
replaced by one negative test with just '-client' as option

> common.sh:
>
>   107         negative_test $1 -XX:-TieredCompilation -client
>   108         negative_test `expr $1 + 1` -XX:+TieredCompilation -client
>
also replaced by one negative test with just '-client' as option

> Also instead of number for error code can you use messages? It will be
> very difficult to trace which test failed by number especially since you
> use expressions for it.
added test name to test's output. Using of different exit codes is 
necessary for better bug matching.

> We should disable core files generation and tests on Mac OS. The Nightly
> should be clean.
'TestSA.sh' will be skipped on Mac OS, if it isn't configured for core 
dumping

Best regards,
Igor Ignatyev

On 04/16/2013 09:55 PM, Vladimir Kozlov wrote:
> Sorry, I notice only now that next tests will fail because there is no
> Tiered in Client VM and not because there is a problem in Replay code.
> So it does not test Replay code:
>
> TestVM_no_comp_level.sh:
>
>    61     negative_test 10 -XX:-TieredCompilation -client
>    62     negative_test 11 -XX:+TieredCompilation -client
>
> common.sh:
>
>   107         negative_test $1 -XX:-TieredCompilation -client
>   108         negative_test `expr $1 + 1` -XX:+TieredCompilation -client
>
> Also instead of number for error code can you use messages? It will be
> very difficult to trace which test failed by number especially since you
> use expressions for it.
>
> On 4/16/13 9:06 AM, Igor Ignatyev wrote:
>>  > Okay. Please, test it: generate replay.txt with C1 without recording
>>  > comp_level (old style) and then try to replay it with new code.
>> 'TestVM_no_comp_level.sh' emulates old style of replay data.
>
> Okay.
>
>>
>>  >>> Add tests for tiered with different -XX:TieredStopAtLevel=n.
>>  >> what exactly did you mean?
>>  >> 1) generate replay.txt by VM with different value of
>> 'TieredStopAtLevel'
>>  >> 2) use different 'TieredStopAtLevel' during replay of compilation
>>  >
>>  > I meant 1). VM could crash at any level of compilation because they
>> are
>>  > different so we need to be able replay all of them. So I want to
>> verify
>>  > that it works (positive tests).
>> block 'if [ $is_tiered -eq 1 ]' was added to TestVM.sh
>
> Thanks.
>
>>
>>> Run in JPRT to verify that tests work on all platforms.
>> There are some failures in TestSA.sh due to known bugs in SA
>> (JDK-8011888, JDK-6326653) and environment/infra issue on macosx (core
>> wasn't generated because '/cores' directory doesn't exist or isn't
>> writable by current user[1]).
>
> We should disable core files generation and tests on Mac OS. The Nightly
> should be clean.
>
> Thanks,
> Vladimir
>
>>
>> updated webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.04/
>>
>> [1]
>> http://developer.apple.com/library/mac/technotes/tn2124/_index.html#//apple_ref/doc/uid/DTS10003391-CH1-SECCOREDUMPS
>>
>>
>>
>> Best regards,
>> Igor Ignatyev
>>
>> On 04/16/2013 01:35 AM, Vladimir Kozlov wrote:
>>> On 4/13/13 12:14 PM, Igor Ignatyev wrote:
>>>>> If you replaying C1 compilation next setting will be incorrect. Should
>>>>> we use CompLevel_highest_tier instead so that following check pass?:
>>>>>
>>>>> +     if (had_error() && (error_message() == comp_level_label)) {
>>>>> +       comp_level = CompLevel_full_optimization;
>>>>>
>>>>
>>>> i added this code for compatible with old version and i think that it
>>>> must has the same behavior (use 'CompLevel_full_optimization'). in new
>>>> version we always will have comp_level in replay.txt.
>>>> so i think we shouldn't use CompLevel_highest_tier.
>>>
>>> Okay. Please, test it: generate replay.txt with C1 without recording
>>> comp_level (old style) and then try to replay it with new code.
>>>
>>>>
>>>>> Add tests for tiered with different -XX:TieredStopAtLevel=n.
>>>> what exactly did you mean?
>>>> 1) generate replay.txt by VM with different value of
>>>> 'TieredStopAtLevel'
>>>> 2) use different 'TieredStopAtLevel' during replay of compilation
>>>
>>> I meant 1). VM could crash at any level of compilation because they are
>>> different so we need to be able replay all of them. So I want to verify
>>> that it works (positive tests).
>>>
>>>>
>>>> if 1st, i don't think that test must to iterate through all possible
>>>> values, it must be done by harness, test execution etc
>>>
>>> I agree with you but, unfortunately, we are short on testing hardware to
>>> add an other testing variation. You should know. So adding this testing
>>> here when tiered VM is tested will help us now.
>>>
>>>> if 2nd, current implementation of ciReplay ignore TieredStopAtLevel
>>>> flags, so these tests will be useless.
>>>>
>>>>> You may still not find core file. Or ulimit -c unlimited will not work
>>>>> (windows, OS X?). You need to bailout in such case as success.
>>>> for windows i added '-XX:+CreateMinidumpOnCrash', but whatever case of
>>>> not found core-file need to treat as a environment issue, a test bug or
>>>> may even be a product bug. anyway if it happened, i think it would be
>>>> better to know about this than just skip the test.
>>>>
>>>> i updated webrev according to the rest of your suggestions, but i'm not
>>>> sure about flags to limit core size.
>>>
>>> Run in JPRT to verify that tests work on all platforms.
>>>
>>>>
>>>> also i added one more check of comp_level and moved validation to
>>>> separate method.
>>>
>>> OK.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>>>
>>>> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.03/
>>>>
>>>> Best regards,
>>>> Igor Ignatyev
>>>>
>>>> On 04/13/2013 02:14 AM, Vladimir Kozlov wrote:
>>>>> I would set CrashAfterCompileId default to -1 as indication it is not
>>>>> set. Then you don't need to check CrashAfterCompileId == 0 since
>>>>> compile_id is positive. By the way, it is very nice idea but add a
>>>>> comment about what that code for. I did not get it first :)
>>>>>
>>>>> About name. For such flags we use CI: CIBreakAt, CIStop. So I would
>>>>> suggest to use CICrashAt. Which means VM crash with that compile id,
>>>>> not
>>>>> when it is greater.
>>>>>
>>>>> If you replaying C1 compilation next setting will be incorrect. Should
>>>>> we use CompLevel_highest_tier instead so that following check pass?:
>>>>>
>>>>> +     if (had_error() && (error_message() == comp_level_label)) {
>>>>> +       comp_level = CompLevel_full_optimization;
>>>>>
>>>>>
>>>>> About tests.
>>>>>
>>>>> Add -Xmx32m, -XX:ParallelGCThreads=2 and other flags (codecache
>>>>> ,metaspace) to limit core size on big machines.
>>>>>
>>>>> Add tests for tiered with different -XX:TieredStopAtLevel=n.
>>>>>
>>>>> I would add more info in output why the test is skipped:
>>>>>       echo TEST SKIPPED
>>>>>
>>>>> typo 'java':
>>>>>   124 is_tiered=`${JAVA} ${TESTVMOPTS} java -XX:+PrintFlagsFinal
>>>>> -version 2>&1 | grep TieredCompilation | grep -c true`
>>>>>
>>>>>
>>>>> I don't like next:
>>>>>
>>>>>   130 ${JAVA} ${TESTVMOPTS} -Xcomp -XX:CrashAfterCompileId=1
>>>>> -XX:+CreateMinidumpOnCrash -XX:+DumpReplayDataOnError -version &
>>>>>   131 crash_pid=$!
>>>>>   132 wait $crash_pid
>>>>>
>>>>>   On windows 'wait $crash_pid' may not work (happened before) because
>>>>> before you execute 'wait' OS may assign the same pid to different
>>>>> process.
>>>>>
>>>>> You may still not find core file. Or ulimit -c unlimited will not work
>>>>> (windows, OS X?). You need to bailout in such case as success. Next
>>>>> code
>>>>> is incorrect for that:
>>>>>
>>>>>    48 if [ -z "${core_file}" -o ! -r "${core_file}" ]
>>>>>    49 then
>>>>>    50     echo TEST FAILED: core wasn\'t generated
>>>>>    51     exit 2
>>>>>    52 fi
>>>>>
>>>>> Thanks
>>>>> Vladimir
>>>>>
>>>>> On 4/12/13 8:27 AM, Igor Ignatyev wrote:
>>>>>> updated webrev:
>>>>>> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.02/
>>>>>> added:
>>>>>>    1. more informative message on unsupported comp_level
>>>>>>    2. not-product flag 'CrashAfterCompileId' and assert in
>>>>>> compileBroker.cpp for assured generation of replay.txt
>>>>>>    2. tests for ciReplay
>>>>>>
>>>>>> Best regards,
>>>>>> Igor Ignatyev
>>>>>>
>>>>>> On 04/09/2013 11:40 AM, Vladimir Kozlov wrote:
>>>>>>> Igor,
>>>>>>>
>>>>>>> Sorry, I may said it not clear. What I meant is to set error (call
>>>>>>> report_error()) in such case and return from process_compile()
>>>>>>> without
>>>>>>> compilation. But let ciReplay::replay() finish and exit.
>>>>>>> replay_impl()
>>>>>>> should print the problem so you don't need to do it in
>>>>>>> process_compile(). And, please, test it.
>>>>>>> The message should be more informative, something like:
>>>>>>> "compilation level %d requires TieredCompilation"
>>>>>>> An other bad cases is when failure happened in Client (C1) or Server
>>>>>>> (C2) but the replay is run with opposite VM.
>>>>>>>
>>>>>>> thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 4/9/13 12:04 AM, Igor Ignatyev wrote:
>>>>>>>> Vladimir,
>>>>>>>>
>>>>>>>> Thank you for review.
>>>>>>>>
>>>>>>>> updated webrev:
>>>>>>>> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.01/
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Igor Ignatyev
>>>>>>>>
>>>>>>>> On 04/09/2013 04:19 AM, Vladimir Kozlov wrote:
>>>>>>>>> Igor,
>>>>>>>>>
>>>>>>>>> Thank you for fixing and cleaning this.
>>>>>>>>>
>>>>>>>>> In vmStructs.cpp move _comp_level after _compile_id as in nmethod
>>>>>>>>> class.
>>>>>>>>>
>>>>>>>>> Typo in ciReplay.cpp:
>>>>>>>>> +      comp_level != CompLevel_highest_tier;
>>>>>>>>>
>>>>>>>>> Actually it is useless to replay compilation at different
>>>>>>>>> level, it
>>>>>>>>> should exit with error. Could happened because incorrectly run
>>>>>>>>> without
>>>>>>>>> Tiered when the crush happened with Tiered.
>>>>>>>>>
>>>>>>>>> In ciReplay.cpp use parenthesis around equality checks: if (. &&
>>>>>>>>> (. ==
>>>>>>>>> .)).
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Vladimir
>>>>>>>>>
>>>>>>>>> On 4/8/13 12:30 PM, Igor Ignatyev wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> Please review patch.
>>>>>>>>>>
>>>>>>>>>> Problem:
>>>>>>>>>> Replay of compilations supports c1 and tiered as well as c2, the
>>>>>>>>>> only
>>>>>>>>>> thing missing is comp_level.
>>>>>>>>>>
>>>>>>>>>> Fix:
>>>>>>>>>> 1. added comp_level into dump and usage during replay
>>>>>>>>>> 2. minor changes in agent/doc:
>>>>>>>>>>    - escaped '<', '>'
>>>>>>>>>>    - renamed 'C2 Replay'/'C2 compiler replay' to
>>>>>>>>>> 'Replay'/'Compiler
>>>>>>>>>> replay'
>>>>>>>>>>
>>>>>>>>>> Testing:
>>>>>>>>>> manually launched the replay from JDK-8010934 (assert
>>>>>>>>>> specifically to
>>>>>>>>>> c1) on jvm w/o corresponded fix. assert was triggered w/ patch
>>>>>>>>>> and
>>>>>>>>>> wasn't triggered w/o.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.00/
>>>>>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011675

From vladimir.kozlov at oracle.com  Wed Apr 17 10:36:01 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 17 Apr 2013 10:36:01 -0700
Subject: RFR(S) : 8011675: adding compilation level to replay data
In-Reply-To: <516ED6FD.4080405@oracle.com>
References: <51631AEA.9080702@oracle.com> <51635E89.30808@oracle.com>
	<5163BD9A.5080308@oracle.com> <5163C5F4.7020605@oracle.com>
	<516827EA.3040001@oracle.com> <5168874B.9080407@oracle.com>
	<5169AEA2.7060103@oracle.com> <516C7287.8070600@oracle.com>
	<516D76F4.9010305@oracle.com> <516D908E.9070408@oracle.com>
	<516ED6FD.4080405@oracle.com>
Message-ID: <516EDD81.5000101@oracle.com>

This looks good.

Thanks,
Vladimir

On 4/17/13 10:08 AM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.05/
>
>> TestVM_no_comp_level.sh:
>>
>>    61     negative_test 10 -XX:-TieredCompilation -client
>>    62     negative_test 11 -XX:+TieredCompilation -client
>>
> replaced by one negative test with just '-client' as option
>
>> common.sh:
>>
>>   107         negative_test $1 -XX:-TieredCompilation -client
>>   108         negative_test `expr $1 + 1` -XX:+TieredCompilation -client
>>
> also replaced by one negative test with just '-client' as option
>
>> Also instead of number for error code can you use messages? It will be
>> very difficult to trace which test failed by number especially since you
>> use expressions for it.
> added test name to test's output. Using of different exit codes is
> necessary for better bug matching.
>
>> We should disable core files generation and tests on Mac OS. The Nightly
>> should be clean.
> 'TestSA.sh' will be skipped on Mac OS, if it isn't configured for core
> dumping
>
> Best regards,
> Igor Ignatyev
>
> On 04/16/2013 09:55 PM, Vladimir Kozlov wrote:
>> Sorry, I notice only now that next tests will fail because there is no
>> Tiered in Client VM and not because there is a problem in Replay code.
>> So it does not test Replay code:
>>
>> TestVM_no_comp_level.sh:
>>
>>    61     negative_test 10 -XX:-TieredCompilation -client
>>    62     negative_test 11 -XX:+TieredCompilation -client
>>
>> common.sh:
>>
>>   107         negative_test $1 -XX:-TieredCompilation -client
>>   108         negative_test `expr $1 + 1` -XX:+TieredCompilation -client
>>
>> Also instead of number for error code can you use messages? It will be
>> very difficult to trace which test failed by number especially since you
>> use expressions for it.
>>
>> On 4/16/13 9:06 AM, Igor Ignatyev wrote:
>>>  > Okay. Please, test it: generate replay.txt with C1 without recording
>>>  > comp_level (old style) and then try to replay it with new code.
>>> 'TestVM_no_comp_level.sh' emulates old style of replay data.
>>
>> Okay.
>>
>>>
>>>  >>> Add tests for tiered with different -XX:TieredStopAtLevel=n.
>>>  >> what exactly did you mean?
>>>  >> 1) generate replay.txt by VM with different value of
>>> 'TieredStopAtLevel'
>>>  >> 2) use different 'TieredStopAtLevel' during replay of compilation
>>>  >
>>>  > I meant 1). VM could crash at any level of compilation because they
>>> are
>>>  > different so we need to be able replay all of them. So I want to
>>> verify
>>>  > that it works (positive tests).
>>> block 'if [ $is_tiered -eq 1 ]' was added to TestVM.sh
>>
>> Thanks.
>>
>>>
>>>> Run in JPRT to verify that tests work on all platforms.
>>> There are some failures in TestSA.sh due to known bugs in SA
>>> (JDK-8011888, JDK-6326653) and environment/infra issue on macosx (core
>>> wasn't generated because '/cores' directory doesn't exist or isn't
>>> writable by current user[1]).
>>
>> We should disable core files generation and tests on Mac OS. The Nightly
>> should be clean.
>>
>> Thanks,
>> Vladimir
>>
>>>
>>> updated webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.04/
>>>
>>> [1]
>>> http://developer.apple.com/library/mac/technotes/tn2124/_index.html#//apple_ref/doc/uid/DTS10003391-CH1-SECCOREDUMPS
>>>
>>>
>>>
>>>
>>> Best regards,
>>> Igor Ignatyev
>>>
>>> On 04/16/2013 01:35 AM, Vladimir Kozlov wrote:
>>>> On 4/13/13 12:14 PM, Igor Ignatyev wrote:
>>>>>> If you replaying C1 compilation next setting will be incorrect.
>>>>>> Should
>>>>>> we use CompLevel_highest_tier instead so that following check pass?:
>>>>>>
>>>>>> +     if (had_error() && (error_message() == comp_level_label)) {
>>>>>> +       comp_level = CompLevel_full_optimization;
>>>>>>
>>>>>
>>>>> i added this code for compatible with old version and i think that it
>>>>> must has the same behavior (use 'CompLevel_full_optimization'). in new
>>>>> version we always will have comp_level in replay.txt.
>>>>> so i think we shouldn't use CompLevel_highest_tier.
>>>>
>>>> Okay. Please, test it: generate replay.txt with C1 without recording
>>>> comp_level (old style) and then try to replay it with new code.
>>>>
>>>>>
>>>>>> Add tests for tiered with different -XX:TieredStopAtLevel=n.
>>>>> what exactly did you mean?
>>>>> 1) generate replay.txt by VM with different value of
>>>>> 'TieredStopAtLevel'
>>>>> 2) use different 'TieredStopAtLevel' during replay of compilation
>>>>
>>>> I meant 1). VM could crash at any level of compilation because they are
>>>> different so we need to be able replay all of them. So I want to verify
>>>> that it works (positive tests).
>>>>
>>>>>
>>>>> if 1st, i don't think that test must to iterate through all possible
>>>>> values, it must be done by harness, test execution etc
>>>>
>>>> I agree with you but, unfortunately, we are short on testing
>>>> hardware to
>>>> add an other testing variation. You should know. So adding this testing
>>>> here when tiered VM is tested will help us now.
>>>>
>>>>> if 2nd, current implementation of ciReplay ignore TieredStopAtLevel
>>>>> flags, so these tests will be useless.
>>>>>
>>>>>> You may still not find core file. Or ulimit -c unlimited will not
>>>>>> work
>>>>>> (windows, OS X?). You need to bailout in such case as success.
>>>>> for windows i added '-XX:+CreateMinidumpOnCrash', but whatever case of
>>>>> not found core-file need to treat as a environment issue, a test
>>>>> bug or
>>>>> may even be a product bug. anyway if it happened, i think it would be
>>>>> better to know about this than just skip the test.
>>>>>
>>>>> i updated webrev according to the rest of your suggestions, but i'm
>>>>> not
>>>>> sure about flags to limit core size.
>>>>
>>>> Run in JPRT to verify that tests work on all platforms.
>>>>
>>>>>
>>>>> also i added one more check of comp_level and moved validation to
>>>>> separate method.
>>>>
>>>> OK.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>>>
>>>>> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.03/
>>>>>
>>>>> Best regards,
>>>>> Igor Ignatyev
>>>>>
>>>>> On 04/13/2013 02:14 AM, Vladimir Kozlov wrote:
>>>>>> I would set CrashAfterCompileId default to -1 as indication it is not
>>>>>> set. Then you don't need to check CrashAfterCompileId == 0 since
>>>>>> compile_id is positive. By the way, it is very nice idea but add a
>>>>>> comment about what that code for. I did not get it first :)
>>>>>>
>>>>>> About name. For such flags we use CI: CIBreakAt, CIStop. So I would
>>>>>> suggest to use CICrashAt. Which means VM crash with that compile id,
>>>>>> not
>>>>>> when it is greater.
>>>>>>
>>>>>> If you replaying C1 compilation next setting will be incorrect.
>>>>>> Should
>>>>>> we use CompLevel_highest_tier instead so that following check pass?:
>>>>>>
>>>>>> +     if (had_error() && (error_message() == comp_level_label)) {
>>>>>> +       comp_level = CompLevel_full_optimization;
>>>>>>
>>>>>>
>>>>>> About tests.
>>>>>>
>>>>>> Add -Xmx32m, -XX:ParallelGCThreads=2 and other flags (codecache
>>>>>> ,metaspace) to limit core size on big machines.
>>>>>>
>>>>>> Add tests for tiered with different -XX:TieredStopAtLevel=n.
>>>>>>
>>>>>> I would add more info in output why the test is skipped:
>>>>>>       echo TEST SKIPPED
>>>>>>
>>>>>> typo 'java':
>>>>>>   124 is_tiered=`${JAVA} ${TESTVMOPTS} java -XX:+PrintFlagsFinal
>>>>>> -version 2>&1 | grep TieredCompilation | grep -c true`
>>>>>>
>>>>>>
>>>>>> I don't like next:
>>>>>>
>>>>>>   130 ${JAVA} ${TESTVMOPTS} -Xcomp -XX:CrashAfterCompileId=1
>>>>>> -XX:+CreateMinidumpOnCrash -XX:+DumpReplayDataOnError -version &
>>>>>>   131 crash_pid=$!
>>>>>>   132 wait $crash_pid
>>>>>>
>>>>>>   On windows 'wait $crash_pid' may not work (happened before) because
>>>>>> before you execute 'wait' OS may assign the same pid to different
>>>>>> process.
>>>>>>
>>>>>> You may still not find core file. Or ulimit -c unlimited will not
>>>>>> work
>>>>>> (windows, OS X?). You need to bailout in such case as success. Next
>>>>>> code
>>>>>> is incorrect for that:
>>>>>>
>>>>>>    48 if [ -z "${core_file}" -o ! -r "${core_file}" ]
>>>>>>    49 then
>>>>>>    50     echo TEST FAILED: core wasn\'t generated
>>>>>>    51     exit 2
>>>>>>    52 fi
>>>>>>
>>>>>> Thanks
>>>>>> Vladimir
>>>>>>
>>>>>> On 4/12/13 8:27 AM, Igor Ignatyev wrote:
>>>>>>> updated webrev:
>>>>>>> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.02/
>>>>>>> added:
>>>>>>>    1. more informative message on unsupported comp_level
>>>>>>>    2. not-product flag 'CrashAfterCompileId' and assert in
>>>>>>> compileBroker.cpp for assured generation of replay.txt
>>>>>>>    2. tests for ciReplay
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Igor Ignatyev
>>>>>>>
>>>>>>> On 04/09/2013 11:40 AM, Vladimir Kozlov wrote:
>>>>>>>> Igor,
>>>>>>>>
>>>>>>>> Sorry, I may said it not clear. What I meant is to set error (call
>>>>>>>> report_error()) in such case and return from process_compile()
>>>>>>>> without
>>>>>>>> compilation. But let ciReplay::replay() finish and exit.
>>>>>>>> replay_impl()
>>>>>>>> should print the problem so you don't need to do it in
>>>>>>>> process_compile(). And, please, test it.
>>>>>>>> The message should be more informative, something like:
>>>>>>>> "compilation level %d requires TieredCompilation"
>>>>>>>> An other bad cases is when failure happened in Client (C1) or
>>>>>>>> Server
>>>>>>>> (C2) but the replay is run with opposite VM.
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>> Vladimir
>>>>>>>>
>>>>>>>> On 4/9/13 12:04 AM, Igor Ignatyev wrote:
>>>>>>>>> Vladimir,
>>>>>>>>>
>>>>>>>>> Thank you for review.
>>>>>>>>>
>>>>>>>>> updated webrev:
>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.01/
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Igor Ignatyev
>>>>>>>>>
>>>>>>>>> On 04/09/2013 04:19 AM, Vladimir Kozlov wrote:
>>>>>>>>>> Igor,
>>>>>>>>>>
>>>>>>>>>> Thank you for fixing and cleaning this.
>>>>>>>>>>
>>>>>>>>>> In vmStructs.cpp move _comp_level after _compile_id as in nmethod
>>>>>>>>>> class.
>>>>>>>>>>
>>>>>>>>>> Typo in ciReplay.cpp:
>>>>>>>>>> +      comp_level != CompLevel_highest_tier;
>>>>>>>>>>
>>>>>>>>>> Actually it is useless to replay compilation at different
>>>>>>>>>> level, it
>>>>>>>>>> should exit with error. Could happened because incorrectly run
>>>>>>>>>> without
>>>>>>>>>> Tiered when the crush happened with Tiered.
>>>>>>>>>>
>>>>>>>>>> In ciReplay.cpp use parenthesis around equality checks: if (. &&
>>>>>>>>>> (. ==
>>>>>>>>>> .)).
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Vladimir
>>>>>>>>>>
>>>>>>>>>> On 4/8/13 12:30 PM, Igor Ignatyev wrote:
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> Please review patch.
>>>>>>>>>>>
>>>>>>>>>>> Problem:
>>>>>>>>>>> Replay of compilations supports c1 and tiered as well as c2, the
>>>>>>>>>>> only
>>>>>>>>>>> thing missing is comp_level.
>>>>>>>>>>>
>>>>>>>>>>> Fix:
>>>>>>>>>>> 1. added comp_level into dump and usage during replay
>>>>>>>>>>> 2. minor changes in agent/doc:
>>>>>>>>>>>    - escaped '<', '>'
>>>>>>>>>>>    - renamed 'C2 Replay'/'C2 compiler replay' to
>>>>>>>>>>> 'Replay'/'Compiler
>>>>>>>>>>> replay'
>>>>>>>>>>>
>>>>>>>>>>> Testing:
>>>>>>>>>>> manually launched the replay from JDK-8010934 (assert
>>>>>>>>>>> specifically to
>>>>>>>>>>> c1) on jvm w/o corresponded fix. assert was triggered w/ patch
>>>>>>>>>>> and
>>>>>>>>>>> wasn't triggered w/o.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8011675/webrev.00/
>>>>>>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8011675

From yumin.qi at oracle.com  Wed Apr 17 10:54:11 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Wed, 17 Apr 2013 10:54:11 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516DBA09.9070400@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
Message-ID: <516EE1C3.9010106@oracle.com>

Hi,  This version Change back the HandleMark creating in Thread creation 
back to previous version and add more comments to allocation.hpp for 
documenting the usage of newly introduced macros.

http://cr.openjdk.java.net/~minqi/8010992/webrev3

Thanks
Yumin

On 4/16/2013 1:52 PM, Yumin Qi wrote:
> Hi, all
>
>   new webrev at
>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>
>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread, 
> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>                     quickSort.cpp, remove conditional includes.
>
> Thanks
> Yumin
>
>
> On 4/16/2013 5:56 AM, David Holmes wrote:
>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>> Adding back compiler and gc teams
>>>>
>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>> Zhenyu,
>>>>>
>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>> Maybe you need a replacement delete operator, please check
>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>
>>>>> i can just do
>>>>>
>>>>> delete ((type *)&array_name[index]);
>>>>>
>>>>> so the destructor will be called, is this right?
>>>>
>>>> No, it will also deallocate the memory unless you use a variant of
>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>> actually deallocate the memory.
>>>>
>>> Yes, I meant placement delete operator, which takes two pointers.
>>
>> But you can only call that explicitly as a function. The delete 
>> expression will never use it, so I don't see how it applies. We need 
>> to call the destructor without de-allocating and the only way I can 
>> see to do that is to call the destructor explicitly.
>>
>> David
>> -----
>>
>>
>>> -Zhengyu
>>>
>>>
>>>> I think this is getting out of hand - if we go this path then we
>>>> should simply have a custom operator new[] and operator delete[] and
>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>> destructs and then de-allocates.
>>>>
>>>> I have no issue with calling destructors explicitly.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> Thanks
>>>>> Yumin
>>>>>> Thanks,
>>>>>>
>>>>>> -Zhengyu
>>>>>>
>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>> memflags)                  \
>>>>>>>   624 { \
>>>>>>>   625     if (array_name != NULL)
>>>>>>> { \
>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>> {                                 \
>>>>>>>   627         /* placement to call dtor on type
>>>>>>> */                                        \
>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>   629 } \
>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>> memflags);                                \
>>>>>>>   631 } \
>>>>>>>   632   }
>>>>>>>
>>>>>>>
>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Zhengyu
>>>>>>>
>>>>>>>
>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>> new webrev at:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>
>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Yumin
>>>>>>>>
>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>> Hi Yumin,
>>>>>>>>>
>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>> 
>>>>>>>>>
>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to leak
>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer 
>>>>>>>>> to it!
>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> allocation.hpp:
>>>>>>>>>
>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array 
>>>>>>>>> element
>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>>>>>>>>> before deallocating ?
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>
>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>>
>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>> .
>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>
>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>> Since we
>>>>>>>>>>>> did not call constructor by using this MACRO. It is a 
>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>> which
>>>>>>>>>>>> will call ctors.
>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the 
>>>>>>>>>>>>> dstor
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Yumin
>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and
>>>>>>>>>>>>>> new
>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of 
>>>>>>>>>>>>>> global
>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, 
>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>> cannot prevent third party code to catch such 
>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>> disabling use of global operator new[] and new, we constrain
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they have to
>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>


From coleen.phillimore at oracle.com  Wed Apr 17 14:35:32 2013
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 17 Apr 2013 17:35:32 -0400
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516EE1C3.9010106@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516EE1C3.9010106@oracle.com>
Message-ID: <516F15A4.8000309@oracle.com>


I still think this looks great.  Thanks for adding the comments.
Coleen

On 4/17/2013 1:54 PM, Yumin Qi wrote:
> Hi, This version Change back the HandleMark creating in Thread 
> creation back to previous version and add more comments to 
> allocation.hpp for documenting the usage of newly introduced macros.
>
> http://cr.openjdk.java.net/~minqi/8010992/webrev3
>
> Thanks
> Yumin
>
> On 4/16/2013 1:52 PM, Yumin Qi wrote:
>> Hi, all
>>
>>   new webrev at
>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>
>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread, 
>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>                     quickSort.cpp, remove conditional includes.
>>
>> Thanks
>> Yumin
>>
>>
>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>> Adding back compiler and gc teams
>>>>>
>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>> Zhenyu,
>>>>>>
>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>
>>>>>> i can just do
>>>>>>
>>>>>> delete ((type *)&array_name[index]);
>>>>>>
>>>>>> so the destructor will be called, is this right?
>>>>>
>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>>> actually deallocate the memory.
>>>>>
>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>
>>> But you can only call that explicitly as a function. The delete 
>>> expression will never use it, so I don't see how it applies. We need 
>>> to call the destructor without de-allocating and the only way I can 
>>> see to do that is to call the destructor explicitly.
>>>
>>> David
>>> -----
>>>
>>>
>>>> -Zhengyu
>>>>
>>>>
>>>>> I think this is getting out of hand - if we go this path then we
>>>>> should simply have a custom operator new[] and operator delete[] and
>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>> destructs and then de-allocates.
>>>>>
>>>>> I have no issue with calling destructors explicitly.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Zhengyu
>>>>>>>
>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>> memflags)                  \
>>>>>>>>   624 { \
>>>>>>>>   625     if (array_name != NULL)
>>>>>>>> { \
>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>> {                                 \
>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>> */                                        \
>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>   629 } \
>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>> memflags);                                \
>>>>>>>>   631 } \
>>>>>>>>   632   }
>>>>>>>>
>>>>>>>>
>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>> new webrev at:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>
>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Yumin
>>>>>>>>>
>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>> Hi Yumin,
>>>>>>>>>>
>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>> 
>>>>>>>>>>
>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to 
>>>>>>>>>> leak
>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer 
>>>>>>>>>> to it!
>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> allocation.hpp:
>>>>>>>>>>
>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array 
>>>>>>>>>> element
>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the 
>>>>>>>>>> dtor's
>>>>>>>>>> before deallocating ?
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>
>>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Yumin
>>>>>>>>>>>
>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>> .
>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>> Since we
>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a 
>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>> which
>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is 
>>>>>>>>>>>> what
>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the 
>>>>>>>>>>>>>> dstor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] 
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of 
>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, 
>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>> cannot prevent third party code to catch such 
>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we 
>>>>>>>>>>>>>>> constrain
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they have to
>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>


From yumin.qi at oracle.com  Wed Apr 17 15:30:47 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Wed, 17 Apr 2013 15:30:47 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516F15A4.8000309@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516EE1C3.9010106@oracle.com> <516F15A4.8000309@oracle.com>
Message-ID: <516F2297.9010604@oracle.com>

Thanks Coleen!

On 4/17/2013 2:35 PM, Coleen Phillimore wrote:
>
> I still think this looks great.  Thanks for adding the comments.
> Coleen
>
> On 4/17/2013 1:54 PM, Yumin Qi wrote:
>> Hi, This version Change back the HandleMark creating in Thread 
>> creation back to previous version and add more comments to 
>> allocation.hpp for documenting the usage of newly introduced macros.
>>
>> http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>
>> Thanks
>> Yumin
>>
>> On 4/16/2013 1:52 PM, Yumin Qi wrote:
>>> Hi, all
>>>
>>>   new webrev at
>>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>>
>>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread, 
>>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>>                     quickSort.cpp, remove conditional includes.
>>>
>>> Thanks
>>> Yumin
>>>
>>>
>>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>>> Adding back compiler and gc teams
>>>>>>
>>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>>> Zhenyu,
>>>>>>>
>>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>>
>>>>>>> i can just do
>>>>>>>
>>>>>>> delete ((type *)&array_name[index]);
>>>>>>>
>>>>>>> so the destructor will be called, is this right?
>>>>>>
>>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>>>> actually deallocate the memory.
>>>>>>
>>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>>
>>>> But you can only call that explicitly as a function. The delete 
>>>> expression will never use it, so I don't see how it applies. We 
>>>> need to call the destructor without de-allocating and the only way 
>>>> I can see to do that is to call the destructor explicitly.
>>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>>> -Zhengyu
>>>>>
>>>>>
>>>>>> I think this is getting out of hand - if we go this path then we
>>>>>> should simply have a custom operator new[] and operator delete[] and
>>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>>> destructs and then de-allocates.
>>>>>>
>>>>>> I have no issue with calling destructors explicitly.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>>> memflags)                  \
>>>>>>>>>   624 { \
>>>>>>>>>   625     if (array_name != NULL)
>>>>>>>>> { \
>>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>>> {                                 \
>>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>>> */                                        \
>>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>>   629 } \
>>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>>> memflags);                                \
>>>>>>>>>   631 } \
>>>>>>>>>   632   }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> -Zhengyu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>>> new webrev at:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>>
>>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>>
>>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>>> Hi Yumin,
>>>>>>>>>>>
>>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>>> 
>>>>>>>>>>>
>>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to 
>>>>>>>>>>> leak
>>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer 
>>>>>>>>>>> to it!
>>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> allocation.hpp:
>>>>>>>>>>>
>>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array 
>>>>>>>>>>> element
>>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the 
>>>>>>>>>>> dtor's
>>>>>>>>>>> before deallocating ?
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>>
>>>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Yumin
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>>> .
>>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>>> Since we
>>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a 
>>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>>> which
>>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is 
>>>>>>>>>>>>> what
>>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need 
>>>>>>>>>>>>>>> the dstor
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator 
>>>>>>>>>>>>>>>> new[] and
>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of 
>>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions, 
>>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>>> cannot prevent third party code to catch such 
>>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we 
>>>>>>>>>>>>>>>> constrain
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same 
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> structs) in hotspot have to either extends from 
>>>>>>>>>>>>>>>> CHeapObj or
>>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they 
>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>


From david.holmes at oracle.com  Wed Apr 17 19:52:05 2013
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 Apr 2013 12:52:05 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516EE1C3.9010106@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516EE1C3.9010106@oracle.com>
Message-ID: <516F5FD5.8020406@oracle.com>

Hi Yumin,

Only thing missing - as discussed - is that HandleMark should now extend 
StackObj, with a comment about the special CHeap HandleMark in thread.

Thanks for your perseverance on this.

David

On 18/04/2013 3:54 AM, Yumin Qi wrote:
> Hi,  This version Change back the HandleMark creating in Thread creation
> back to previous version and add more comments to allocation.hpp for
> documenting the usage of newly introduced macros.
>
> http://cr.openjdk.java.net/~minqi/8010992/webrev3
>
> Thanks
> Yumin
>
> On 4/16/2013 1:52 PM, Yumin Qi wrote:
>> Hi, all
>>
>>   new webrev at
>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>
>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread,
>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>                     quickSort.cpp, remove conditional includes.
>>
>> Thanks
>> Yumin
>>
>>
>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>> Adding back compiler and gc teams
>>>>>
>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>> Zhenyu,
>>>>>>
>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>
>>>>>> i can just do
>>>>>>
>>>>>> delete ((type *)&array_name[index]);
>>>>>>
>>>>>> so the destructor will be called, is this right?
>>>>>
>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>>> actually deallocate the memory.
>>>>>
>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>
>>> But you can only call that explicitly as a function. The delete
>>> expression will never use it, so I don't see how it applies. We need
>>> to call the destructor without de-allocating and the only way I can
>>> see to do that is to call the destructor explicitly.
>>>
>>> David
>>> -----
>>>
>>>
>>>> -Zhengyu
>>>>
>>>>
>>>>> I think this is getting out of hand - if we go this path then we
>>>>> should simply have a custom operator new[] and operator delete[] and
>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>> destructs and then de-allocates.
>>>>>
>>>>> I have no issue with calling destructors explicitly.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> Thanks
>>>>>> Yumin
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Zhengyu
>>>>>>>
>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>> memflags)                  \
>>>>>>>>   624 { \
>>>>>>>>   625     if (array_name != NULL)
>>>>>>>> { \
>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>> {                                 \
>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>> */                                        \
>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>   629 } \
>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>> memflags);                                \
>>>>>>>>   631 } \
>>>>>>>>   632   }
>>>>>>>>
>>>>>>>>
>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>> new webrev at:
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>
>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Yumin
>>>>>>>>>
>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>> Hi Yumin,
>>>>>>>>>>
>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>> 
>>>>>>>>>>
>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to leak
>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer
>>>>>>>>>> to it!
>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> allocation.hpp:
>>>>>>>>>>
>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array
>>>>>>>>>> element
>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the dtor's
>>>>>>>>>> before deallocating ?
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>
>>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Yumin
>>>>>>>>>>>
>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>> .
>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>> Since we
>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a
>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>> which
>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is what
>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the
>>>>>>>>>>>>>> dstor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator new[] and
>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of
>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions,
>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>> cannot prevent third party code to catch such
>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we constrain
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same for
>>>>>>>>>>>>>>> structs) in hotspot have to either extends from CHeapObj or
>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they have to
>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>

From yumin.qi at oracle.com  Thu Apr 18 00:53:31 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Thu, 18 Apr 2013 00:53:31 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516F5FD5.8020406@oracle.com>
References: <5167A5B4.4060100@oracle.com> <51681AB8.3010500@oracle.com>
	<51684625.8010603@oracle.com> <5168482F.6040607@oracle.com>
	<51687777.1070500@oracle.com> <516B9922.4050306@oracle.com>
	<516C3BC8.2040001@oracle.com> <516C4A2D.8060902@oracle.com>
	<516C6B03.2070209@oracle.com> <516C75B7.6010700@oracle.com>
	<516C8B3A.9060606@oracle.com> <516D4675.8060308@oracle.com>
	<516D4A86.90405@oracle.com> <516DBA09.9070400@oracle.com>
	<516EE1C3.9010106@oracle.com> <516F5FD5.8020406@oracle.com>
Message-ID: <516FA67B.20308@oracle.com>

Thanks Coleen and David, I update the webrev (same URL) for 
HandleMark(handles.hpp) and also several files' Copyright year.

Thanks
Yumin

On 4/17/2013 7:52 PM, David Holmes wrote:
> Hi Yumin,
>
> Only thing missing - as discussed - is that HandleMark should now 
> extend StackObj, with a comment about the special CHeap HandleMark in 
> thread.
>
> Thanks for your perseverance on this.
>
> David
>
> On 18/04/2013 3:54 AM, Yumin Qi wrote:
>> Hi,  This version Change back the HandleMark creating in Thread creation
>> back to previous version and add more comments to allocation.hpp for
>> documenting the usage of newly introduced macros.
>>
>> http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>
>> Thanks
>> Yumin
>>
>> On 4/16/2013 1:52 PM, Yumin Qi wrote:
>>> Hi, all
>>>
>>>   new webrev at
>>>   http://cr.openjdk.java.net/~minqi/8010992/webrev3
>>>
>>>   Changes:  NEW_C_HEAP_ARRAY to create HandleMark in Thread::Thread,
>>> use FREE_C_HEAP_OBJECT to free it in ~Thread.
>>>                     quickSort.cpp, remove conditional includes.
>>>
>>> Thanks
>>> Yumin
>>>
>>>
>>> On 4/16/2013 5:56 AM, David Holmes wrote:
>>>> On 16/04/2013 10:39 PM, Zhengyu Gu wrote:
>>>>> On 4/15/2013 7:20 PM, David Holmes wrote:
>>>>>> Adding back compiler and gc teams
>>>>>>
>>>>>> On 16/04/2013 7:48 AM, Yumin Qi wrote:
>>>>>>> Zhenyu,
>>>>>>>
>>>>>>> On 4/15/2013 2:02 PM, Zhengyu Gu wrote:
>>>>>>>> Maybe you need a replacement delete operator, please check
>>>>>>>> http://www.cplusplus.com/reference/new/operator%20delete/
>>>>>>>>
>>>>>>> i can just do
>>>>>>>
>>>>>>> delete ((type *)&array_name[index]);
>>>>>>>
>>>>>>> so the destructor will be called, is this right?
>>>>>>
>>>>>> No, it will also deallocate the memory unless you use a variant of
>>>>>> delete (which is what I think Zhengyu was referring to) that doesn't
>>>>>> actually deallocate the memory.
>>>>>>
>>>>> Yes, I meant placement delete operator, which takes two pointers.
>>>>
>>>> But you can only call that explicitly as a function. The delete
>>>> expression will never use it, so I don't see how it applies. We need
>>>> to call the destructor without de-allocating and the only way I can
>>>> see to do that is to call the destructor explicitly.
>>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>>> -Zhengyu
>>>>>
>>>>>
>>>>>> I think this is getting out of hand - if we go this path then we
>>>>>> should simply have a custom operator new[] and operator delete[] and
>>>>>> not need NEW_C_HEAP_ARRAY etc. But I don't think our usage is simple
>>>>>> enough to actually do that. So if we need NEW_C_HEAP_OBJ_ARRAY that
>>>>>> allocates and constructs then we need a FREE_C_HEAP_OBJ_ARRAY that
>>>>>> destructs and then de-allocates.
>>>>>>
>>>>>> I have no issue with calling destructors explicitly.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> Thanks
>>>>>>> Yumin
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Zhengyu
>>>>>>>>
>>>>>>>> On 4/15/2013 2:42 PM, Zhengyu Gu wrote:
>>>>>>>>>   623 #define FREE_C_HEAP_OBJECT_ARRAY(type, array_name, size,
>>>>>>>>> memflags)                  \
>>>>>>>>>   624 { \
>>>>>>>>>   625     if (array_name != NULL)
>>>>>>>>> { \
>>>>>>>>>   626       for (int index = 0; index < size; index ++)
>>>>>>>>> {                                 \
>>>>>>>>>   627         /* placement to call dtor on type
>>>>>>>>> */                                        \
>>>>>>>>>   628 ((type*)&array_name[index])->~type(); \
>>>>>>>>>   629 } \
>>>>>>>>>   630       FREE_C_HEAP_ARRAY(type, array_name,
>>>>>>>>> memflags);                                \
>>>>>>>>>   631 } \
>>>>>>>>>   632   }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I really don't like this, calling dtor  ...
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> -Zhengyu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/15/2013 1:41 PM, Yumin Qi wrote:
>>>>>>>>>> new webrev at:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev2
>>>>>>>>>>
>>>>>>>>>> Can I have a review from GC team for this change?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Yumin
>>>>>>>>>>
>>>>>>>>>> On 4/14/2013 11:07 PM, David Holmes wrote:
>>>>>>>>>>> Hi Yumin,
>>>>>>>>>>>
>>>>>>>>>>> On 13/04/2013 7:07 AM, Yumin Qi wrote:
>>>>>>>>>>>> After take feedback and modify, new webrev
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev1
>>>>>>>>>>>> 
>>>>>>>>>>>
>>>>>>>>>>> I still find the HandleMark changes unsatisfactory. The CHeap
>>>>>>>>>>> allocated HandleMark in the Thread() constructor is a bit of a
>>>>>>>>>>> hack. HandleMarks should be stack-allocated. Plus we seem to 
>>>>>>>>>>> leak
>>>>>>>>>>> that CHeap allocated HandleMark as we don't keep any pointer
>>>>>>>>>>> to it!
>>>>>>>>>>> I think this needs to be re-visited, but as a separate CR.
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> allocation.hpp:
>>>>>>>>>>>
>>>>>>>>>>> If  NEW_C_HEAP_OBJECT_ARRAY invokes the ctor for each array
>>>>>>>>>>> element
>>>>>>>>>>> don't we need a new FREE_C_HEAP_OBJECT_ARRAY to invoke the 
>>>>>>>>>>> dtor's
>>>>>>>>>>> before deallocating ?
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> src/share/vm/utilities/quickSort.cpp
>>>>>>>>>>>
>>>>>>>>>>> Why does only Solaris need the allocation headers included ?? I
>>>>>>>>>>> would expect all platforms to need to the same headers here.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Yumin
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/12/2013 10:45 AM, Zhengyu Gu wrote:
>>>>>>>>>>>>> .
>>>>>>>>>>>>>>> cardTableModRefBS.cpp
>>>>>>>>>>>>>>>   #87 and #88, why set_start(NULL) are needed?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is default constructor does, here just copy that code.
>>>>>>>>>>>>>> Since we
>>>>>>>>>>>>>> did not call constructor by using this MACRO. It is a
>>>>>>>>>>>>>> _ValueObj,
>>>>>>>>>>>>>> should not call new, but I think we can use NEW_C_HEAP_OBJ3,
>>>>>>>>>>>>>> which
>>>>>>>>>>>>>> will call ctors.
>>>>>>>>>>>>> NEW_C_HEAP_OBJECT_ARRAY macro does invoke ctor ... that is 
>>>>>>>>>>>>> what
>>>>>>>>>>>>> allocation.hpp #618 does.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> carTableRS.cpp
>>>>>>>>>>>>>>>   #70, why it is commented out? If so, you don't need the
>>>>>>>>>>>>>>> dstor
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> See reply to David H.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>> -Zhengyu
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/12/2013 2:12 AM, Yumin Qi wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Can I have your inputs for the fix?
>>>>>>>>>>>>>>>>   webrev:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~minqi/8010992/webrev/
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   Bug:  8010992: Remove calls to global ::operator 
>>>>>>>>>>>>>>>> new[] and
>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8010992
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Problem description:  Remove the usage of global operator
>>>>>>>>>>>>>>>> ::new[]
>>>>>>>>>>>>>>>> and ::new. In hotspot debug build, disable the usage of
>>>>>>>>>>>>>>>> global
>>>>>>>>>>>>>>>> new[] and new.  Hotspot does not throw c++ exceptions,
>>>>>>>>>>>>>>>> but it
>>>>>>>>>>>>>>>> cannot prevent third party code to catch such
>>>>>>>>>>>>>>>> exceptions.  By
>>>>>>>>>>>>>>>> disabling use of global operator new[] and new, we 
>>>>>>>>>>>>>>>> constrain
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> exception disposal within hotspot. C++ classes (as same 
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> structs) in hotspot have to either extends from 
>>>>>>>>>>>>>>>> CHeapObj or
>>>>>>>>>>>>>>>> ResourceObj unless they are stack objects or values which
>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>> be from StackObj or _ValueObj respectively. Or they 
>>>>>>>>>>>>>>>> have to
>>>>>>>>>>>>>>>> implement their own operator new[] or new.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>> Yumin
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>


From yunda.mly at taobao.com  Thu Apr 18 01:05:53 2013
From: yunda.mly at taobao.com (=?utf-8?B?5LqR6L6+KFl1bmRhKQ==?=)
Date: Thu, 18 Apr 2013 08:05:53 +0000
Subject: RFR (S): 8010090 - GC ID has the wrong type
In-Reply-To: <516FA293.8080607@oracle.com>
References: <516D5D57.2060804@oracle.com>
	
	<516FA293.8080607@oracle.com>
Message-ID: 

Jesper,

Thanks for your clear explanation and I think you are right that it's a bug that the method compile_id() doesn't have the return type unit.

Regards,
Yunda


> -----Original Message-----
> From: Jesper Wilhelmsson [mailto:jesper.wilhelmsson at oracle.com]
> Sent: Thursday, April 18, 2013 3:37 PM
> To: ??(Yunda)
> Cc: hotspot-gc-dev openjdk.java.net; hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR (S): 8010090 - GC ID has the wrong type
>
> ??,
>
> Thanks for looking at this!
>
> Looking at the code, it is not that easy to determine the intention when it
> comes to the signedness of compile id. But judging from the original variable it
> should be unsigned.
>
> The original variable in which the compile id is stored, _compile_id in the class
> CompileTask, is a uint. The method compile_id() that is its getter has the return
> type int (this is likely a bug).
>
> In CompileBroker::invoke_compiler_on_method, compile_id() is called and the
> result is stored in compile_id which is a uint. The variable compile_id is then
> used to populate the compileID in the Compilation event which used to be
> INTEGER
> (signed) but is about to become a UINT. Nils Eliasson from the compiler team
> has approved this change.
>
> Thanks,
> /Jesper
>
>
> ??(Yunda) skrev 18/4/13 5:48 AM:
> > Jesper,
> >
> > I think the GC part looks good. But I found the value put into Compile ID is
> actually int, not uint(share/vm/opto/compile.hpp):
> > 470   int               compile_id() const          { return
> _compile_id; }
> > Are you sure it is non-negative?
> >
> >
> > Regards,
> > Yunda
> >
> >
> >> -----Original Message-----
> >> From: hotspot-gc-dev-bounces at openjdk.java.net
> >> [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Jesper
> >> Wilhelmsson
> >> Sent: Tuesday, April 16, 2013 10:17 PM
> >> To: hotspot-gc-dev openjdk.java.net;
> >> hotspot-compiler-dev at openjdk.java.net
> >> Subject: RFR (S): 8010090 - GC ID has the wrong type
> >>
> >> Hi,
> >>
> >> Could I have a couple of reviews for this really small change.
> >>
> >> The type of the GC ID and the Compile ID in the different tracing
> >> events should be UINT as the values put into these fields are uint.
> >>
> >> Webrev: http://cr.openjdk.java.net/~jwilhelm/8010090/webrev/
> >>
> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010090
> >>
> >> Thanks,
> >> /Jesper
> >
> > ________________________________
> >
> > This email (including any attachments) is confidential and may be legally
> privileged. If you received this email in error, please delete it immediately and
> do not copy it or use it for any purpose or disclose its contents to any other
> person. Thank you.
>
> >
> > ???(??????)??????????????????????
> ????????????????????????????????
> ?????
> > ???????????
> >

________________________________

This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you.

???(??????)??????????????????????????????????????????????????????????????????????

From nils.eliasson at oracle.com  Thu Apr 18 06:09:30 2013
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Thu, 18 Apr 2013 15:09:30 +0200
Subject: RFR (S/M): 8012547: Reclamation of flushed methods can be slow
Message-ID: <516FF08A.2080808@oracle.com>

Hi!

I have another fix to the code cache sweeper and flushing that needs a 
review.

The major change is to remove a check in scan_stacks that stops the 
sweeper when the cache is getting  full. The normal mode is to sweep and 
record if any change has happened that require another sweep. This check 
stops the sweeper early causing some methods that are speculatively 
disconnected to stay so for an unnecessa