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 unnecessary long time sometimes causing 
unnecessary new flushes.

Also some refactoring
- remove state variable _do_sweep that was unnecessary. It marked if a 
sweep was active or not, but just a duplicate way of checking if any 
methods are being sweept (nmethodsweeper::current != NULL).
- rename _rescan to _resweep. When _resweep is set there will be another 
sweep started when the current ends. That sweep will start with a scan, 
but it is not only a scan.
- rename _advise_to_sweep to _flush_token. Is CASed by the first thread 
that wants to flush and reset by scan_stacks when the flush is finished 
and a proper time has passed.

http://cr.openjdk.java.net/~neliasso/8012547/ 

https://jbs.oracle.com/bugs/browse/JDK-8012547

Thanks,
Nils E.

From yunda.mly at taobao.com  Wed Apr 17 20:48:16 2013
From: yunda.mly at taobao.com (=?utf-8?B?5LqR6L6+KFl1bmRhKQ==?=)
Date: Thu, 18 Apr 2013 03:48:16 +0000
Subject: RFR (S): 8010090 - GC ID has the wrong type
In-Reply-To: <516D5D57.2060804@oracle.com>
References: <516D5D57.2060804@oracle.com>
Message-ID: 

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.

???(??????)??????????????????????????????????????????????????????????????????????

From jesper.wilhelmsson at oracle.com  Thu Apr 18 00:36:51 2013
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Thu, 18 Apr 2013 09:36:51 +0200
Subject: RFR (S): 8010090 - GC ID has the wrong type
In-Reply-To: 
References: <516D5D57.2060804@oracle.com>
	
Message-ID: <516FA293.8080607@oracle.com>

??,

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.
>
> ???(??????)??????????????????????????????????????????????????????????????????????
>

From vladimir.kozlov at oracle.com  Thu Apr 18 10:30:00 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 18 Apr 2013 10:30:00 -0700
Subject: RFR (S/M): 8012547: Reclamation of flushed methods can be slow
In-Reply-To: <516FF08A.2080808@oracle.com>
References: <516FF08A.2080808@oracle.com>
Message-ID: <51702D98.80907@oracle.com>

Nils,

this looks good.

Thanks,
Vladimir

On 4/18/13 6:09 AM, Nils Eliasson wrote:
> 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 unnecessary long time sometimes causing
> unnecessary new flushes.
>
> Also some refactoring
> - remove state variable _do_sweep that was unnecessary. It marked if a
> sweep was active or not, but just a duplicate way of checking if any
> methods are being sweept (nmethodsweeper::current != NULL).
> - rename _rescan to _resweep. When _resweep is set there will be another
> sweep started when the current ends. That sweep will start with a scan,
> but it is not only a scan.
> - rename _advise_to_sweep to _flush_token. Is CASed by the first thread
> that wants to flush and reset by scan_stacks when the flush is finished
> and a proper time has passed.
>
> http://cr.openjdk.java.net/~neliasso/8012547/
> 
> https://jbs.oracle.com/bugs/browse/JDK-8012547
>
> Thanks,
> Nils E.

From igor.ignatyev at oracle.com  Thu Apr 18 10:30:34 2013
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 18 Apr 2013 21:30:34 +0400
Subject: RFR(S): 8012322 : Tiered:
	CompilationPolicy::can_be_compiled(CompLevel_all)
	mistakenly return false
Message-ID: <51702DBA.6030302@oracle.com>

Hi all,

Please review the patch.

Problem:
if method is 'not_compilable' in C1 or C2, 
'CompilationPolicy::can_be_compiled' will return false for 
'CompLevel_all' even it is compilable in another level

Fix:
1. added explicit comp_level to all calls of 
CompilationPolicy::can_be_compiled
2. in CompilationPolicy::can_be_compiled()
   - added assert for checking legality of comp_level
   - changed logic for comp_level == CompLevel_all

Testing:
JPRT 'compiler/whitebox'

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

From vladimir.kozlov at oracle.com  Thu Apr 18 11:02:44 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 18 Apr 2013 11:02:44 -0700
Subject: RFR(S): 8012322 : Tiered:
	CompilationPolicy::can_be_compiled(CompLevel_all)
	mistakenly return false
In-Reply-To: <51702DBA.6030302@oracle.com>
References: <51702DBA.6030302@oracle.com>
Message-ID: <51703544.20305@oracle.com>

Changes are good. My only complain is variables naming:

!             final int n = TIERED_STOP_AT_LEVEL + 1;
+             for (int i = 1; i < n; ++i) {

+         for (int j = 1, n = TIERED_STOP_AT_LEVEL + 1; j < n; ++j) {

For the code to be "clear and self-documented" :) use some meaningful 
names instead of 'i', 'j' and 'n'.

Thanks,
Vladimir

On 4/18/13 10:30 AM, Igor Ignatyev wrote:
> Hi all,
>
> Please review the patch.
>
> Problem:
> if method is 'not_compilable' in C1 or C2,
> 'CompilationPolicy::can_be_compiled' will return false for
> 'CompLevel_all' even it is compilable in another level
>
> Fix:
> 1. added explicit comp_level to all calls of
> CompilationPolicy::can_be_compiled
> 2. in CompilationPolicy::can_be_compiled()
>    - added assert for checking legality of comp_level
>    - changed logic for comp_level == CompLevel_all
>
> Testing:
> JPRT 'compiler/whitebox'
>
> webrev: http://cr.openjdk.java.net/~iignatyev/8012322/webrev.00/
> jbs: https://jbs.oracle.com/bugs/browse/JDK-8012322

From igor.ignatyev at oracle.com  Thu Apr 18 13:48:35 2013
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 19 Apr 2013 00:48:35 +0400
Subject: RFR(S) : 8011675: adding compilation level to replay data
In-Reply-To: <516EDD81.5000101@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> <516EDD81.5000101@oracle.com>
Message-ID: <51705C23.90206@oracle.com>

Vladimir,
thank you for review.

i have additional small changes for it:
- improved finding of coredump location, now it correctly works on mac os.

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

Best regards,
Igor Ignatyev

On 04/17/2013 09:36 PM, Vladimir Kozlov wrote:
> 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 igor.ignatyev at oracle.com  Thu Apr 18 15:11:59 2013
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 19 Apr 2013 02:11:59 +0400
Subject: RFR(S): 8012322 : Tiered:
	CompilationPolicy::can_be_compiled(CompLevel_all)
	mistakenly return false
In-Reply-To: <51703544.20305@oracle.com>
References: <51702DBA.6030302@oracle.com> <51703544.20305@oracle.com>
Message-ID: <51706FAF.1020303@oracle.com>

 > For the code to be "clear and self-documented" :) use some meaningful
 > names instead of 'i', 'j' and 'n'.
renamed

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

Best regards,
Igor Ignatyev

On 04/18/2013 10:02 PM, Vladimir Kozlov wrote:
> Changes are good. My only complain is variables naming:
>
> !             final int n = TIERED_STOP_AT_LEVEL + 1;
> +             for (int i = 1; i < n; ++i) {
>
> +         for (int j = 1, n = TIERED_STOP_AT_LEVEL + 1; j < n; ++j) {
>
> For the code to be "clear and self-documented" :) use some meaningful
> names instead of 'i', 'j' and 'n'.
>
> Thanks,
> Vladimir
>
> On 4/18/13 10:30 AM, Igor Ignatyev wrote:
>> Hi all,
>>
>> Please review the patch.
>>
>> Problem:
>> if method is 'not_compilable' in C1 or C2,
>> 'CompilationPolicy::can_be_compiled' will return false for
>> 'CompLevel_all' even it is compilable in another level
>>
>> Fix:
>> 1. added explicit comp_level to all calls of
>> CompilationPolicy::can_be_compiled
>> 2. in CompilationPolicy::can_be_compiled()
>>    - added assert for checking legality of comp_level
>>    - changed logic for comp_level == CompLevel_all
>>
>> Testing:
>> JPRT 'compiler/whitebox'
>>
>> webrev: http://cr.openjdk.java.net/~iignatyev/8012322/webrev.00/
>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8012322

From vladimir.kozlov at oracle.com  Thu Apr 18 15:25:16 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 18 Apr 2013 15:25:16 -0700
Subject: RFR(S) : 8011675: adding compilation level to replay data
In-Reply-To: <51705C23.90206@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> <516EDD81.5000101@oracle.com>
	<51705C23.90206@oracle.com>
Message-ID: <517072CC.2070204@oracle.com>

I wish we also record core's location in hs_err file so you can grep it 
instead of stderr output.

Can you save command's output (stderr and stdout) into a file and grep 
it instead?

Thanks,
Vladimir

On 4/18/13 1:48 PM, Igor Ignatyev wrote:
> Vladimir,
> thank you for review.
>
> i have additional small changes for it:
> - improved finding of coredump location, now it correctly works on mac os.
>
> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.06/
>
> Best regards,
> Igor Ignatyev
>
> On 04/17/2013 09:36 PM, Vladimir Kozlov wrote:
>> 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 vladimir.kozlov at oracle.com  Thu Apr 18 15:39:30 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 18 Apr 2013 15:39:30 -0700
Subject: RFR(S): 8012322 : Tiered:
	CompilationPolicy::can_be_compiled(CompLevel_all)
	mistakenly return false
In-Reply-To: <51706FAF.1020303@oracle.com>
References: <51702DBA.6030302@oracle.com> <51703544.20305@oracle.com>
	<51706FAF.1020303@oracle.com>
Message-ID: <51707622.5010206@oracle.com>

Good.

Thanks,
Vladimir

On 4/18/13 3:11 PM, Igor Ignatyev wrote:
>  > For the code to be "clear and self-documented" :) use some meaningful
>  > names instead of 'i', 'j' and 'n'.
> renamed
>
> http://cr.openjdk.java.net/~iignatyev/8012322/webrev.01/
>
> Best regards,
> Igor Ignatyev
>
> On 04/18/2013 10:02 PM, Vladimir Kozlov wrote:
>> Changes are good. My only complain is variables naming:
>>
>> !             final int n = TIERED_STOP_AT_LEVEL + 1;
>> +             for (int i = 1; i < n; ++i) {
>>
>> +         for (int j = 1, n = TIERED_STOP_AT_LEVEL + 1; j < n; ++j) {
>>
>> For the code to be "clear and self-documented" :) use some meaningful
>> names instead of 'i', 'j' and 'n'.
>>
>> Thanks,
>> Vladimir
>>
>> On 4/18/13 10:30 AM, Igor Ignatyev wrote:
>>> Hi all,
>>>
>>> Please review the patch.
>>>
>>> Problem:
>>> if method is 'not_compilable' in C1 or C2,
>>> 'CompilationPolicy::can_be_compiled' will return false for
>>> 'CompLevel_all' even it is compilable in another level
>>>
>>> Fix:
>>> 1. added explicit comp_level to all calls of
>>> CompilationPolicy::can_be_compiled
>>> 2. in CompilationPolicy::can_be_compiled()
>>>    - added assert for checking legality of comp_level
>>>    - changed logic for comp_level == CompLevel_all
>>>
>>> Testing:
>>> JPRT 'compiler/whitebox'
>>>
>>> webrev: http://cr.openjdk.java.net/~iignatyev/8012322/webrev.00/
>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8012322

From david.holmes at oracle.com  Thu Apr 18 19:10:02 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Apr 2013 12:10:02 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <516FA67B.20308@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>
	<516FA67B.20308@oracle.com>
Message-ID: <5170A77A.6080006@oracle.com>

On 18/04/2013 5:53 PM, Yumin Qi wrote:
> Thanks Coleen and David, I update the webrev (same URL) for
> HandleMark(handles.hpp) and also several files' Copyright year.

Thanks for that.

One thing that just occurred to me is that NEW_C_HEAP_OBJ can only be 
used for classes that have no virtual methods - as there is nothing to 
initialize the vtable pointer. I think we got lucky with HandleMark in 
that regard, but there should be a warning attached to it as well.

Thanks,
David

> 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 john.coomes at oracle.com  Thu Apr 18 20:54:44 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 19 Apr 2013 03:54:44 +0000
Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b86 for changeset
	ca71ec37b2ef
Message-ID: <20130419035451.9B6364844B@hg.openjdk.java.net>

Changeset: 9550aab82b5d
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/9550aab82b5d

Added tag jdk8-b86 for changeset ca71ec37b2ef

! .hgtags


From john.coomes at oracle.com  Thu Apr 18 20:54:32 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 19 Apr 2013 03:54:32 +0000
Subject: hg: hsx/hotspot-comp: 12 new changesets
Message-ID: <20130419035432.E5DB448449@hg.openjdk.java.net>

Changeset: fc1e08c2bb27
Author:    mduigou
Date:      2013-04-01 11:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/fc1e08c2bb27

8010267: Add test-clean for cleaning of testoutput directory from output directory. Add depedency on test-clean to clean
Reviewed-by: mchung, tbell

! common/makefiles/Main.gmk

Changeset: 26a4456cb19e
Author:    jgish
Date:      2013-03-26 13:41 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/26a4456cb19e

8009824: webrev.ksh generated jdk.patch files do not handle renames, copies, and shouldn't be applied
Summary: use hg export --git to produce proper patch file
Reviewed-by: mduigou

! make/scripts/webrev.ksh

Changeset: 760074bec012
Author:    mduigou
Date:      2013-04-01 21:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/760074bec012

8011178: improve common/bin/hgforest.sh python detection (MacOS)
Reviewed-by: ohair

! common/bin/hgforest.sh

Changeset: bcbdbcfe7ed8
Author:    lana
Date:      2013-04-02 11:55 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/bcbdbcfe7ed8

Merge


Changeset: 7320922b694e
Author:    mduigou
Date:      2013-04-02 14:56 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/7320922b694e

8011342: hgforest.sh : 'python --version' not supported on older python
Reviewed-by: wetmore

! common/bin/hgforest.sh

Changeset: 575f2ca947ab
Author:    mduigou
Date:      2013-04-03 16:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/575f2ca947ab

8011350: hgforest.sh uses non-POSIX sh features that may fail with some shells
Reviewed-by: tbell, katleman, dholmes

! common/bin/hgforest.sh

Changeset: 11c057460b91
Author:    lana
Date:      2013-04-05 14:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/11c057460b91

Merge


Changeset: 4c13b7994f38
Author:    lana
Date:      2013-04-16 08:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/4c13b7994f38

Merge

! common/makefiles/Main.gmk

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

8012048: JDK8 b85 source with GPL header errors
Reviewed-by: iris, mduigou, jjg

! common/autoconf/compare.sh.in
! common/bin/compare.sh

Changeset: 8c5b18d6f4fb
Author:    katleman
Date:      2013-04-15 14:19 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/8c5b18d6f4fb

Merge


Changeset: df9b5240f0a7
Author:    katleman
Date:      2013-04-16 14:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/df9b5240f0a7

Merge


Changeset: 6981694f7674
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/6981694f7674

Added tag jdk8-b86 for changeset df9b5240f0a7

! .hgtags


From john.coomes at oracle.com  Thu Apr 18 20:54:37 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 19 Apr 2013 03:54:37 +0000
Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b86 for changeset
	44a8ce4a759f
Message-ID: <20130419035439.A47724844A@hg.openjdk.java.net>

Changeset: f1709874d55a
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/f1709874d55a

Added tag jdk8-b86 for changeset 44a8ce4a759f

! .hgtags


From john.coomes at oracle.com  Thu Apr 18 20:56:34 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 19 Apr 2013 03:56:34 +0000
Subject: hg: hsx/hotspot-comp/jdk: 50 new changesets
Message-ID: <20130419040658.2EE464844D@hg.openjdk.java.net>

Changeset: 87c62f03bc07
Author:    jgodinez
Date:      2013-03-27 12:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/87c62f03bc07

8010005: [parfait] Memory leak in jdk/src/macosx/native/sun/awt/CTextPipe.m
Reviewed-by: bae, prr
Contributed-by: jia-hong.chen at oracle.com

! src/macosx/native/sun/awt/CTextPipe.m

Changeset: 9d4f539e36b6
Author:    lana
Date:      2013-04-02 17:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9d4f539e36b6

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: 2904672aed21
Author:    lana
Date:      2013-04-09 14:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2904672aed21

Merge


Changeset: 96750ebc769b
Author:    denis
Date:      2013-03-27 16:19 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/96750ebc769b

7075105: WIN: Provide a way to format HTML on drop
Reviewed-by: uta, serb

! src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java
! src/share/classes/java/awt/datatransfer/DataFlavor.java
! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java
! src/share/classes/sun/awt/datatransfer/DataTransferer.java
! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java
! src/solaris/classes/sun/awt/X11/XDataTransferer.java
! src/windows/classes/sun/awt/windows/WDataTransferer.java
+ test/java/awt/datatransfer/HTMLDataFlavors/HTMLDataFlavorTest.java
+ test/java/awt/datatransfer/HTMLDataFlavors/HtmlTransferable.java
+ test/java/awt/datatransfer/HTMLDataFlavors/ManualHTMLDataFlavorTest.html
+ test/java/awt/datatransfer/HTMLDataFlavors/ManualHTMLDataFlavorTest.java
+ test/java/awt/datatransfer/HTMLDataFlavors/PutAllHtmlFlavorsOnClipboard.java
+ test/java/awt/datatransfer/HTMLDataFlavors/PutOnlyAllHtmlFlavorOnClipboard.java
+ test/java/awt/datatransfer/HTMLDataFlavors/PutSelectionAndFragmentHtmlFlavorsOnClipboard.java

Changeset: 29570523b6cb
Author:    ant
Date:      2013-03-29 16:12 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/29570523b6cb

8010375: sun.swing.JLightweightFrame should be implemented for XToolkit
Reviewed-by: anthony

! src/share/classes/sun/swing/JLightweightFrame.java
! src/solaris/classes/sun/awt/X11/XFramePeer.java
+ src/solaris/classes/sun/awt/X11/XLightweightFramePeer.java
! src/solaris/classes/sun/awt/X11/XToolkit.java

Changeset: c23d58901aa6
Author:    lana
Date:      2013-04-02 16:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c23d58901aa6

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: 36cb7921bc98
Author:    mcherkas
Date:      2013-04-03 20:42 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/36cb7921bc98

8011123: serialVersionUID of java.awt.dnd.InvalidDnDOperationException changed in JDK8-b82
Reviewed-by: anthony, serb

! src/share/classes/java/awt/dnd/InvalidDnDOperationException.java

Changeset: 35da3878deef
Author:    mcherkas
Date:      2013-04-03 20:54 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/35da3878deef

8010925: COPY AND PASTE TO AND FROM SIGNED APPLET FAILS AFTER FIRST INTERNAL COPY PRFRMD
Reviewed-by: anthony, serb

! src/macosx/classes/sun/lwawt/macosx/CClipboard.java
! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java
! src/macosx/native/sun/awt/CClipboard.m

Changeset: 2c36899500a0
Author:    pchelko
Date:      2013-04-05 18:29 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2c36899500a0

8006941: [macosx] Deadlock in drag and drop
7199783: Setting cursor on DragSourceContext does not work on OSX
Reviewed-by: anthony, serb

! src/macosx/classes/sun/lwawt/LWComponentPeer.java
! src/macosx/classes/sun/lwawt/macosx/CCursorManager.java
! src/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java
! src/macosx/classes/sun/lwawt/macosx/CDropTarget.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/CDragSource.h
! src/macosx/native/sun/awt/CDragSource.m
! src/macosx/native/sun/awt/CDragSourceContextPeer.m
! src/macosx/native/sun/awt/CDropTarget.m
! src/share/classes/sun/awt/dnd/SunDragSourceContextPeer.java
+ test/java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java

Changeset: 0b083b0e8e63
Author:    kshefov
Date:      2013-04-08 17:18 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0b083b0e8e63

7153702: [TEST_BUG] [macosx] Synchronization problem in test javax/swing/JPopupMenu/6827786/bug6827786.java
Reviewed-by: serb, alexsch

! test/javax/swing/JPopupMenu/6827786/bug6827786.java

Changeset: 981142561d1b
Author:    lana
Date:      2013-04-09 15:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/981142561d1b

Merge


Changeset: 3b56ef8e1ce1
Author:    martin
Date:      2013-03-26 13:34 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3b56ef8e1ce1

8007905: To add a system property to create zip file without using ZIP64 end table when entry count > 64k
Summary: Provide a system property to inhibit ZIP64 mode for >64k entries
Reviewed-by: alanb, sherman

! src/share/classes/java/util/zip/ZipOutputStream.java
+ test/java/util/zip/EntryCount64k.java

Changeset: 266b43683a2c
Author:    martin
Date:      2013-03-26 13:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/266b43683a2c

8010316: Improve handling of char sequences containing surrogates
Summary: Fix and optimize codePointAt, codePointBefore and similar methods
Reviewed-by: sherman, okutsu, ulfzibis, kizune

! src/share/classes/java/lang/AbstractStringBuilder.java
! src/share/classes/java/lang/Character.java
! test/java/lang/StringBuilder/Supplementary.java

Changeset: caafe6dca35d
Author:    ehelin
Date:      2013-03-21 20:35 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/caafe6dca35d

8009427: Re-enable tests that were disable to ease complicated push
Reviewed-by: sla, mchung, dcubed
Contributed-by: Erik Helin 

! test/ProblemList.txt

Changeset: 49602f599c08
Author:    dxu
Date:      2013-03-27 09:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/49602f599c08

8010837: FileInputStream.available() throw IOException when encountering negative available values
Summary: Remove the check in the native code to allow negative values
Reviewed-by: mchung

! src/solaris/native/java/io/io_util_md.c
+ test/java/io/FileInputStream/NegativeAvailable.java

Changeset: ae03282ba501
Author:    darcy
Date:      2013-03-27 09:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ae03282ba501

7185456: (ann) Optimize Annotation handling in java/sun.reflect.* code for small number of annotations
Reviewed-by: mduigou, jfranck

! src/share/classes/sun/reflect/annotation/AnnotationType.java

Changeset: d254a5f9b93f
Author:    acorn
Date:      2013-03-27 13:40 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d254a5f9b93f

8010846: Update the corresponding test in test/vm/verifier/TestStaticIF.java
Summary: Remove test flag -XX:-UseSplitVerifier, not supported classfile 52
Reviewed-by: acorn, hseigel

! test/vm/verifier/TestStaticIF.java

Changeset: 811c771acf65
Author:    sundar
Date:      2013-03-28 14:36 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/811c771acf65

8010991: Enable test/javax/script/GetInterfaceTest.java again
Reviewed-by: lagergren, hannesw

! test/javax/script/GetInterfaceTest.java

Changeset: a87fac00915e
Author:    weijun
Date:      2013-03-28 20:27 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a87fac00915e

8010125: keytool -importkeystore could create a pkcs12 keystore with different storepass and keypass
Reviewed-by: vinnie

! src/share/classes/sun/security/tools/keytool/Main.java
! src/share/classes/sun/security/tools/keytool/Resources.java
+ test/sun/security/tools/keytool/p12importks.sh

Changeset: e433ed08b733
Author:    mchung
Date:      2013-03-28 13:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e433ed08b733

8010309: Improve PlatformLogger.isLoggable performance by direct mapping from an integer to Level
Reviewed-by: mchung
Contributed-by: peter.levart at gmail.com, bourges.laurent at gmail.com

! src/share/classes/sun/util/logging/PlatformLogger.java
! test/sun/util/logging/PlatformLoggerTest.java

Changeset: b590bd37a6d0
Author:    mduigou
Date:      2013-04-01 12:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b590bd37a6d0

8010268: Remove dependence upon clean target from jdk/test/Makefile prep target
Reviewed-by: tbell, mchung

! test/Makefile

Changeset: 0cccdb9a9a4c
Author:    mduigou
Date:      2013-04-01 20:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0cccdb9a9a4c

7143928: Optimize empty HashMap and ArrayList
Reviewed-by: mduigou
Contributed-by: Sergey Linetskiy , John Rose , Mike Duigou 

! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/HashMap.java
+ test/java/util/Map/BasicSerialization.java

Changeset: 5ee837ba093a
Author:    mduigou
Date:      2013-04-01 20:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5ee837ba093a

8011187: Remove obsolete/unused targets from jdk/test/Makefile
Reviewed-by: ohair

! test/Makefile

Changeset: de228734b742
Author:    mduigou
Date:      2013-04-01 20:51 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/de228734b742

8011199: Backout changeset JDK-7143928 (0cccdb9a9a4c)
Reviewed-by: darcy, dholmes

! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/HashMap.java
- test/java/util/Map/BasicSerialization.java

Changeset: f1b89d4cce82
Author:    sla
Date:      2013-04-02 10:32 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f1b89d4cce82

8009558: linked_md.c::dll_build_name can get stuck in an infinite loop
Reviewed-by: alanb, sspitsyn

! src/share/back/export/sys.h
! src/share/back/transport.c
! src/share/demo/jvmti/hprof/hprof_md.h
! src/solaris/back/linker_md.c
! src/solaris/demo/jvmti/hprof/hprof_md.c
! src/windows/back/linker_md.c
! src/windows/demo/jvmti/hprof/hprof_md.c

Changeset: e6c3b8e74e50
Author:    sherman
Date:      2013-04-02 10:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e6c3b8e74e50

8007379: Base64.getMimeDecoder().decode() throws IAE for a non-base64 character after padding
8008925: Base64.getMimeDecoder().decode() does not ignore padding chars
Summary: updated implementation and spec for corner cases.
Reviewed-by: alanb

! src/share/classes/java/util/Base64.java
! test/java/util/Base64/TestBase64.java

Changeset: 7fbae9125437
Author:    lana
Date:      2013-04-02 11:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7fbae9125437

Merge


Changeset: b4f68aca1000
Author:    darcy
Date:      2013-04-02 16:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b4f68aca1000

8004979: java.lang.reflect.Modifier.toString should include "default"
Reviewed-by: mduigou

! src/share/classes/java/lang/reflect/Constructor.java
! src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/java/lang/reflect/Field.java
! src/share/classes/java/lang/reflect/Method.java
! src/share/classes/java/lang/reflect/Modifier.java
! test/java/lang/reflect/Method/GenericStringTest.java

Changeset: c534937f6e94
Author:    alanb
Date:      2013-04-03 13:15 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c534937f6e94

8011234: Performance regression with ftp protocol when uploading in image mode
Reviewed-by: chegar

! src/share/classes/sun/net/ftp/impl/FtpClient.java

Changeset: eb8f7bc6f964
Author:    alanb
Date:      2013-04-03 13:41 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/eb8f7bc6f964

8011373: Property java.runtime.profile should be removed (left-over code)
Reviewed-by: lancea, dholmes

! src/share/classes/sun/misc/Version.java.template

Changeset: 27ae4f9c7826
Author:    lancea
Date:      2013-04-03 12:47 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/27ae4f9c7826

8011393: Typo in javadoc for SerialClob.truncate
Reviewed-by: darcy

! src/share/classes/javax/sql/rowset/serial/SerialClob.java

Changeset: 9a6ef3391f32
Author:    naoto
Date:      2013-04-03 10:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9a6ef3391f32

7091601: Arabic Locale: can not set type of digit in application level
Reviewed-by: okutsu

! src/macosx/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c
! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java

Changeset: 7b1189bf1d7b
Author:    dxu
Date:      2013-04-04 15:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7b1189bf1d7b

8000406: change files using @GenerateNativeHeader to use @Native
Summary: Use @Native annotation to mark constants interested by native codes
Reviewed-by: alanb, anthony, prr

! src/macosx/classes/apple/laf/JRSUIConstants.java
! src/macosx/classes/com/apple/eawt/FullScreenHandler.java
! src/macosx/classes/com/apple/eawt/event/GestureHandler.java
! src/macosx/classes/sun/java2d/OSXSurfaceData.java
! src/macosx/classes/sun/lwawt/macosx/CocoaConstants.java
! src/macosx/native/jobjc/src/core/PrimitiveCoder.hs
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/CFType.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/FFIType.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Function.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/ID.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Invoke.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/MacOSXFramework.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NSClass.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeArgumentBuffer.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeBuffer.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeObjectLifecycleManager.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Opaque.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Pointer.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/PrimitiveCoder.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/SEL.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Struct.java
! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Subclassing.java
! src/macosx/native/jobjc/src/core/native/Invoke.m
! src/macosx/native/jobjc/src/core/native/JObjCRuntime.m
! src/macosx/native/sun/awt/PrinterView.m
! src/share/classes/java/awt/Adjustable.java
! src/share/classes/java/awt/AlphaComposite.java
! src/share/classes/java/awt/BasicStroke.java
! src/share/classes/java/awt/Choice.java
! src/share/classes/java/awt/DisplayMode.java
! src/share/classes/java/awt/Image.java
! src/share/classes/java/awt/List.java
! src/share/classes/java/awt/PopupMenu.java
! src/share/classes/java/awt/SystemColor.java
! src/share/classes/java/awt/TextComponent.java
! src/share/classes/java/awt/Transparency.java
! src/share/classes/java/awt/color/ColorSpace.java
! src/share/classes/java/awt/color/ICC_Profile.java
! src/share/classes/java/awt/datatransfer/StringSelection.java
! src/share/classes/java/awt/dnd/DnDConstants.java
! src/share/classes/java/awt/event/ActionEvent.java
! src/share/classes/java/awt/event/AdjustmentEvent.java
! src/share/classes/java/awt/event/ComponentEvent.java
! src/share/classes/java/awt/event/FocusEvent.java
! src/share/classes/java/awt/event/InputMethodEvent.java
! src/share/classes/java/awt/event/MouseWheelEvent.java
! src/share/classes/java/awt/event/WindowEvent.java
! src/share/classes/java/awt/geom/PathIterator.java
! src/share/classes/java/awt/image/AffineTransformOp.java
! src/share/classes/java/awt/image/ConvolveOp.java
! src/share/classes/java/awt/image/DataBuffer.java
! src/share/classes/java/awt/image/ImageConsumer.java
! src/share/classes/java/awt/image/ImageObserver.java
! src/share/classes/java/awt/peer/ComponentPeer.java
! src/share/classes/java/awt/print/PageFormat.java
! src/share/classes/java/awt/print/Pageable.java
! src/share/classes/java/awt/print/Printable.java
! src/share/classes/sun/awt/EmbeddedFrame.java
! src/share/classes/sun/awt/SunHints.java
! src/share/classes/sun/awt/dnd/SunDragSourceContextPeer.java
! src/share/classes/sun/awt/image/BufImgSurfaceData.java
! src/share/classes/sun/font/FontManager.java
! src/share/classes/sun/java2d/SunGraphics2D.java
! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java
! src/share/classes/sun/java2d/opengl/OGLContext.java
! src/share/classes/sun/java2d/pipe/BufferedContext.java
! src/share/classes/sun/java2d/pipe/BufferedOpCodes.java
! src/share/classes/sun/java2d/pipe/BufferedPaints.java
! src/share/classes/sun/java2d/pipe/BufferedTextPipe.java
! src/share/classes/sun/java2d/pipe/RenderBuffer.java
! src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventNotifier.java
! src/share/classes/sun/java2d/pipe/hw/AccelSurface.java
! src/share/classes/sun/java2d/pipe/hw/ContextCapabilities.java
! src/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/share/classes/sun/nio/ch/sctp/SctpStdSocketOption.java
! src/share/classes/sun/security/pkcs11/Secmod.java
! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java
! src/solaris/classes/sun/awt/X11/XComponentPeer.java
! src/solaris/classes/sun/nio/ch/sctp/AssociationChange.java
! src/solaris/classes/sun/nio/ch/sctp/PeerAddrChange.java
! src/solaris/classes/sun/nio/ch/sctp/ResultContainer.java
! src/solaris/native/sun/awt/awt_InputMethod.c
! src/solaris/native/sun/awt/fontpath.c
! src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java
! src/windows/classes/sun/java2d/d3d/D3DContext.java
! src/windows/classes/sun/java2d/d3d/D3DPaints.java
! src/windows/native/sun/java2d/d3d/D3DContext.h
! src/windows/native/sun/windows/awt_Component.h
! src/windows/native/sun/windows/awt_DnDDS.cpp
! src/windows/native/sun/windows/awt_Frame.cpp
! src/windows/native/sun/windows/awt_List.h
! src/windows/native/sun/windows/awt_PopupMenu.cpp
! src/windows/native/sun/windows/awt_PopupMenu.h
! src/windows/native/sun/windows/awt_TextComponent.h
! src/windows/native/sun/windows/awt_Toolkit.cpp

Changeset: 7d4e30730f80
Author:    valeriep
Date:      2013-04-04 20:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7d4e30730f80

7155720: PKCS11 minor issues in native code
Summary: Added OOM handling to address the two issues found by parfait.
Reviewed-by: weijun

! src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c

Changeset: b62a76763bf3
Author:    mchung
Date:      2013-04-05 10:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b62a76763bf3

8011380: FX dependency on PlatformLogger broken by 8010309
Reviewed-by: alanb

! src/share/classes/java/util/logging/LoggingProxyImpl.java
! src/share/classes/sun/util/logging/LoggingProxy.java
! src/share/classes/sun/util/logging/LoggingSupport.java
! src/share/classes/sun/util/logging/PlatformLogger.java
! test/sun/util/logging/PlatformLoggerTest.java

Changeset: b702977e7212
Author:    khazra
Date:      2013-04-05 12:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b702977e7212

5001942: Missings SOCKS support for direct connections
Summary: Add support for socksNonProxyHosts
Reviewed-by: chegar, khazra
Contributed-by: Christos Zoulas 

! src/share/classes/sun/net/spi/DefaultProxySelector.java
! test/java/net/Socks/SocksProxyVersion.java

Changeset: ba231ac2890a
Author:    lana
Date:      2013-04-05 14:51 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ba231ac2890a

Merge


Changeset: 785f3a04ee05
Author:    dxu
Date:      2013-04-05 17:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/785f3a04ee05

8011602: jobjc build failure on Mac
Summary: Remove @Native annotation from macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java
Reviewed-by: mchung, dholmes

! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java
! src/share/classes/sun/java2d/opengl/OGLContext.java

Changeset: 16f63a94c231
Author:    darcy
Date:      2013-04-05 18:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/16f63a94c231

8011590: More tests for core reflection modeling of default methods
Reviewed-by: mduigou

+ test/java/lang/reflect/Method/DefaultMethodModeling.java

Changeset: 04617e462512
Author:    lancea
Date:      2013-04-08 15:29 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/04617e462512

8006036: (process) cleanup code in java/lang/Runtime/exec/WinCommand.java
Reviewed-by: lancea
Contributed-by: Jim Gish 

! test/java/lang/Runtime/exec/WinCommand.java

Changeset: 3db793b080d8
Author:    martin
Date:      2013-04-08 16:37 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3db793b080d8

8010849: (str) Optimize StringBuilder.append(null)
Summary: Append 4 chars instead of the string "null"
Reviewed-by: mduigou, forax, jgish

! src/share/classes/java/lang/AbstractStringBuilder.java

Changeset: 3e5a18c3e599
Author:    darcy
Date:      2013-04-08 17:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3e5a18c3e599

6298888: Add toGenericString to j.l.Class and getTypeName to j.l.reflect.Type
6992705: Include modifiers in Class.toGenericString()
Summary: Class.toGenericString and supporting changes; additional reviews by Peter Levart
Reviewed-by: alanb

! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/reflect/Constructor.java
! src/share/classes/java/lang/reflect/Executable.java
! src/share/classes/java/lang/reflect/Field.java
! src/share/classes/java/lang/reflect/Method.java
! src/share/classes/java/lang/reflect/Modifier.java
! src/share/classes/java/lang/reflect/Parameter.java
! src/share/classes/java/lang/reflect/Type.java
+ test/java/lang/Class/GenericStringTest.java

Changeset: 57e9eaeca323
Author:    alanb
Date:      2013-04-09 15:51 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/57e9eaeca323

8010393: Update JAX-WS RI to 2.2.9-b12941
Reviewed-by: mullan

! 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: 50bc8e085a09
Author:    chegar
Date:      2013-04-09 17:27 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/50bc8e085a09

8005696: Add CompletableFuture
Reviewed-by: chegar, martin

! make/java/java/FILES_java.gmk
+ src/share/classes/java/util/concurrent/CompletableFuture.java
+ src/share/classes/java/util/concurrent/CompletionException.java
+ test/java/util/concurrent/CompletableFuture/Basic.java

Changeset: f304311cfe9f
Author:    lana
Date:      2013-04-09 15:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f304311cfe9f

Merge

! src/share/classes/sun/awt/dnd/SunDragSourceContextPeer.java

Changeset: 6e3763e737b0
Author:    lana
Date:      2013-04-16 08:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6e3763e737b0

Merge


Changeset: e5c5e369af6a
Author:    katleman
Date:      2013-04-12 15:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e5c5e369af6a

8012048: JDK8 b85 source with GPL header errors
Reviewed-by: iris, mduigou, jjg

! src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
! src/share/classes/java/util/function/DoublePredicate.java
! src/share/classes/java/util/function/IntPredicate.java
! src/share/classes/java/util/function/LongPredicate.java
! src/share/classes/java/util/function/ObjIntConsumer.java
! src/share/classes/java/util/function/ToDoubleBiFunction.java
! test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh
! test/java/lang/reflect/Method/IsDefaultTest.java
! test/java/net/URLConnection/RequestProperties.java
! test/java/util/Optional/BasicDouble.java
! test/javax/swing/text/html/7189299/bug7189299.java
! test/sun/management/jdp/JdpTest.sh
! test/sun/misc/URLClassPath/JarLoaderTest.java
! test/sun/util/calendar/zi/ZoneInfoFile.java

Changeset: b45456703c65
Author:    katleman
Date:      2013-04-15 14:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b45456703c65

Merge


Changeset: 7989cd0cc3a9
Author:    katleman
Date:      2013-04-16 15:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7989cd0cc3a9

Merge


Changeset: f4c62eecf7fa
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f4c62eecf7fa

Added tag jdk8-b86 for changeset 7989cd0cc3a9

! .hgtags


From john.coomes at oracle.com  Thu Apr 18 21:11:32 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 19 Apr 2013 04:11:32 +0000
Subject: hg: hsx/hotspot-comp/nashorn: 33 new changesets
Message-ID: <20130419041155.BBFD348450@hg.openjdk.java.net>

Changeset: 41a212ea8c0c
Author:    sundar
Date:      2013-03-28 20:48 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/41a212ea8c0c

8010924: Dealing with undefined property gets you a fatal stack
Reviewed-by: lagergren, jlaskey

! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js
+ test/script/basic/JDK-8010924.js

Changeset: e2ea7a29b9c1
Author:    lagergren
Date:      2013-03-29 08:55 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/e2ea7a29b9c1

8010995: The bug ID 8010710 accidentally got two digits transposed in the checkin and unit test name
Reviewed-by: hannesw, sundar

+ test/script/basic/JDK-8010710.js
+ test/script/basic/JDK-8010710.js.EXPECTED
- test/script/basic/JDK-8017010.js
- test/script/basic/JDK-8017010.js.EXPECTED

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

8011063: With older ant, we get the error "The  type doesn't support nested text data ("${run.te...jvmargs}")."
Reviewed-by: hannesw, ksrini

! make/build.xml

Changeset: a094fc010120
Author:    jlaskey
Date:      2013-03-31 08:19 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/a094fc010120

8011095: PropertyHashMap.rehash() does not grow enough
Reviewed-by: hannesw, lagergren
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/runtime/PropertyHashMap.java
! src/jdk/nashorn/internal/runtime/PropertyMap.java

Changeset: 3e4369fb810b
Author:    hannesw
Date:      2013-04-02 13:55 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/3e4369fb810b

8011219: Regression with recent PropertyMap history changes
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/runtime/PropertyMap.java

Changeset: 5362d96d5915
Author:    sundar
Date:      2013-04-02 17:40 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/5362d96d5915

8011209: Object.getOwnPropertyDescriptor(function(){"use strict"},"caller").get.length is not 0
Reviewed-by: lagergren, hannesw, jlaskey

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

Changeset: 9b845033c888
Author:    lana
Date:      2013-04-02 12:01 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/9b845033c888

Merge


Changeset: d82bc6ba3981
Author:    lana
Date:      2013-04-05 14:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/d82bc6ba3981

Merge


Changeset: af6fc67aa73d
Author:    jlaskey
Date:      2013-04-02 11:37 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/af6fc67aa73d

8011233: Create a Nashorn shell for JavaFX
Reviewed-by: lagergren, sundar
Contributed-by: james.laskey at oracle.com

! make/build.xml
! make/project.properties
+ tools/fxshell/jdk/nashorn/tools/FXShell.java

Changeset: be5d2e472e22
Author:    jlaskey
Date:      2013-04-02 11:38 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/be5d2e472e22

Merge


Changeset: 159dbe2e02eb
Author:    sundar
Date:      2013-04-02 20:42 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/159dbe2e02eb

8011237: Object.isExtensible(Object.getOwnPropertyDescriptor(function(){"use strict"},"caller").get) should be false
Reviewed-by: lagergren, jlaskey

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

Changeset: e9af5451d2d1
Author:    sundar
Date:      2013-04-02 23:01 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/e9af5451d2d1

8011274: Object.getOwnPropertyDescriptor(function(){"use strict"},"caller").get.hasOwnProperty("prototype") should be false
Reviewed-by: lagergren, jlaskey

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

Changeset: e63b20d4f08a
Author:    sundar
Date:      2013-04-03 11:41 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/e63b20d4f08a

8011357: Array.prototype.slice and Array.prototype.splice should not call user defined valueOf of start, end arguments more than once
Reviewed-by: lagergren, hannesw

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

Changeset: 51da1afbab26
Author:    attila
Date:      2013-04-03 11:13 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/51da1afbab26

8011362: Overloaded method resolution foiled by nulls
Reviewed-by: hannesw, sundar

! src/jdk/internal/dynalink/beans/ClassString.java
! src/jdk/internal/dynalink/beans/OverloadedMethod.java
+ test/script/basic/JDK-8011362.js
+ test/script/basic/JDK-8011362.js.EXPECTED
+ test/src/jdk/nashorn/test/models/Jdk8011362TestSubject.java

Changeset: b4191da366be
Author:    sundar
Date:      2013-04-03 15:27 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/b4191da366be

8011365: Array.prototype.join and Array.prototype.toString do not throw TypeError on null, undefined
Reviewed-by: attila, hannesw, lagergren

! src/jdk/nashorn/internal/objects/NativeArray.java
! test/script/basic/JDK-8011362.js.EXPECTED
+ test/script/basic/JDK-8011365.js

Changeset: 4f7d7576e8c4
Author:    hannesw
Date:      2013-04-03 12:43 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/4f7d7576e8c4

8007774: Enable code cache again
Reviewed-by: lagergren, attila, sundar

! src/jdk/nashorn/internal/runtime/resources/Options.properties

Changeset: 82fed56d8dce
Author:    sundar
Date:      2013-04-03 20:17 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/82fed56d8dce

8011382: Data prototype methods and constructor do not call user defined toISOString, valueOf methods per spec.
Reviewed-by: lagergren, jlaskey

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

Changeset: a5a8ddc2e028
Author:    sundar
Date:      2013-04-04 10:24 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/a5a8ddc2e028

8011394: RegExp.prototype.test() does not call valueOf on lastIndex property as per the spec.
Reviewed-by: lagergren, jlaskey, hannesw

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

Changeset: 0548c134b9ac
Author:    sundar
Date:      2013-04-04 13:54 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/0548c134b9ac

8011421: When using Object.defineProperty on arrays, PropertyDescriptor's property accessors are invoked multiple times
Reviewed-by: lagergren, hannesw

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

Changeset: f638f2f094f7
Author:    jlaskey
Date:      2013-04-04 09:05 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/f638f2f094f7

8011540: PropertyMap histories should not begin with empty map
Reviewed-by: lagergren, sundar
Contributed-by: james.laskey at oracle.com

! src/jdk/nashorn/internal/runtime/PropertyMap.java

Changeset: 069923cc9de5
Author:    jlaskey
Date:      2013-04-04 09:06 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/069923cc9de5

Merge


Changeset: 18df6640e63f
Author:    sundar
Date:      2013-04-04 18:30 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/18df6640e63f

8011543: "".split(undefined,{valueOf:function(){throw 2}}) does not throw exception
Reviewed-by: lagergren, jlaskey

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

Changeset: 5eb1427b6a6d
Author:    attila
Date:      2013-04-04 15:53 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/5eb1427b6a6d

8011544: Allow subclassing Java classes from script without creating instances
Reviewed-by: jlaskey, sundar

! src/jdk/nashorn/internal/objects/NativeJava.java
+ src/jdk/nashorn/internal/runtime/linker/AdaptationException.java
+ src/jdk/nashorn/internal/runtime/linker/AdaptationResult.java
+ src/jdk/nashorn/internal/runtime/linker/ClassAndLoader.java
+ src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java
+ src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java
! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java
+ src/jdk/nashorn/internal/runtime/linker/JavaAdapterGeneratorBase.java
+ src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java
! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java
! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java
! src/jdk/nashorn/internal/runtime/resources/Messages.properties
+ test/script/basic/javaclassoverrides.js
+ test/script/basic/javaclassoverrides.js.EXPECTED

Changeset: 73e1270b240c
Author:    attila
Date:      2013-04-04 15:55 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/73e1270b240c

Merge


Changeset: 349360cc1df5
Author:    sundar
Date:      2013-04-04 20:46 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/349360cc1df5

8011552: Arrays with missing elements are not properly sorted
Reviewed-by: jlaskey, lagergren

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

Changeset: 050fd5696bcb
Author:    attila
Date:      2013-04-04 18:32 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/050fd5696bcb

8011555: Invalid class name in with block with JavaImporter causes MH type mismatch
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/runtime/WithObject.java
+ test/script/basic/JDK-8011555.js
+ test/script/basic/JDK-8011555.js.EXPECTED

Changeset: 1c29dc809de2
Author:    hannesw
Date:      2013-04-05 19:50 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/1c29dc809de2

8009230: Nashorn rejects extended RegExp syntax accepted by all major JS engines
Reviewed-by: jlaskey, lagergren

! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/script/basic/JDK-8009230.js
+ test/script/basic/JDK-8009230.js.EXPECTED

Changeset: 437861485ffa
Author:    jlaskey
Date:      2013-04-09 08:36 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/437861485ffa

Merge


Changeset: 35881a9d0fc2
Author:    lana
Date:      2013-04-16 08:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/35881a9d0fc2

Merge

- test/script/basic/JDK-8017010.js
- test/script/basic/JDK-8017010.js.EXPECTED

Changeset: e7e82c1e9aed
Author:    katleman
Date:      2013-04-12 15:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/e7e82c1e9aed

8012048: JDK8 b85 source with GPL header errors
Reviewed-by: iris, mduigou, jjg

! docs/JavaScriptingProgrammersGuide.html
! src/jdk/nashorn/api/scripting/Formatter.java

Changeset: 399a4b8e4607
Author:    katleman
Date:      2013-04-15 14:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/399a4b8e4607

Merge


Changeset: 002ad9d6735f
Author:    katleman
Date:      2013-04-16 15:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/002ad9d6735f

Merge


Changeset: 899cbeee7253
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/899cbeee7253

Added tag jdk8-b86 for changeset 002ad9d6735f

! .hgtags


From john.coomes at oracle.com  Thu Apr 18 21:10:18 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 19 Apr 2013 04:10:18 +0000
Subject: hg: hsx/hotspot-comp/langtools: 22 new changesets
Message-ID: <20130419041125.894414844F@hg.openjdk.java.net>

Changeset: 330b35b27e68
Author:    darcy
Date:      2013-03-26 17:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/330b35b27e68

7041251: Use j.u.Objects utility methods in langtools
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/util/Pair.java
! src/share/classes/javax/annotation/processing/AbstractProcessor.java

Changeset: 33b6a52f0037
Author:    darcy
Date:      2013-03-26 18:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/33b6a52f0037

7059170: Assume availablility of URLClassLoader.close
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java
- src/share/classes/com/sun/tools/javac/util/CloseableURLClassLoader.java

Changeset: 7bebe17ff323
Author:    mcimadamore
Date:      2013-03-28 11:38 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/7bebe17ff323

8010469: Bad assertion in LambdaToMethod
Summary: Add assertion in LambdaToMethod.serializedLambdaName
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java

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

8010490: FindBugs: double assignments in LambdaToMethod.visitIdent
Summary: Remove dead code from LambdaToMethod
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java

Changeset: 991f11e13598
Author:    jjg
Date:      2013-03-28 10:49 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/991f11e13598

8006346: doclint should make allowance for headers generated by standard doclet
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/doclint/Checker.java
! src/share/classes/com/sun/tools/doclint/DocLint.java
! src/share/classes/com/sun/tools/doclint/Env.java
! src/share/classes/com/sun/tools/javac/main/Main.java
! src/share/classes/com/sun/tools/javadoc/DocEnv.java
+ test/tools/javac/doclint/ImplicitHeadersTest.java
+ test/tools/javadoc/doclint/ImplicitHeadersTest.java

Changeset: d3648557391b
Author:    jjg
Date:      2013-03-28 10:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/d3648557391b

8010511: Tests are creating files in /tmp
Reviewed-by: darcy

! test/tools/javac/T6558476.java
! test/tools/javac/T6900149.java
! test/tools/javac/diags/CheckExamples.java
! test/tools/javac/diags/RunExamples.java

Changeset: 29c6984a1673
Author:    vromero
Date:      2013-04-02 10:51 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/29c6984a1673

4965689: class literal code wastes a byte
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/jvm/Items.java
+ test/tools/javac/T4965689/ClassLiteralWastesByteTest.java

Changeset: 46d2f144ebbd
Author:    lana
Date:      2013-04-02 12:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/46d2f144ebbd

Merge


Changeset: 0d47e6131490
Author:    darcy
Date:      2013-04-03 12:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/0d47e6131490

8011052: Add DEFAULT to javax.lang.model.Modifier
Reviewed-by: abuckley, jjg

! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/javax/lang/model/element/Modifier.java
! test/tools/javac/processing/model/element/TestExecutableElement.java

Changeset: e06dc8345d9c
Author:    lana
Date:      2013-04-05 14:51 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/e06dc8345d9c

Merge


Changeset: b71a61d39cf7
Author:    mcimadamore
Date:      2013-04-08 15:51 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/b71a61d39cf7

8010922: Cleanup: add support for ad-hoc method check logic
Summary: Support pluggable method checkers
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java

Changeset: b54122b9372d
Author:    mcimadamore
Date:      2013-04-08 15:52 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/b54122b9372d

8010823: DefaultMethodTest.testReflectCall fails with new lambda VM
Summary: Fix lambda test
Reviewed-by: jjg

! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java

Changeset: e9d986381414
Author:    mcimadamore
Date:      2013-04-08 15:53 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/e9d986381414

8010404: Lambda debugging: redundant LineNumberTable entry for lambda capture
Summary: Ignore indy entries in LineNumberTable
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! test/tools/javac/lambda/TestInvokeDynamic.java

Changeset: 94a202228ec2
Author:    mcimadamore
Date:      2013-04-08 15:57 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/94a202228ec2

8009131: Overload: javac should discard methods that lead to errors in lambdas with implicit parameter types
Summary: Lambdas that have errors in their bodies should make enclosing overload resolution fail
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/diags/examples/BadArgTypesInLambda.java
! test/tools/javac/lambda/BadRecovery.out
! test/tools/javac/lambda/TargetType01.java
- test/tools/javac/lambda/TargetType01.out
! test/tools/javac/lambda/TargetType43.out
+ test/tools/javac/lambda/TargetType66.java
+ test/tools/javac/lambda/TargetType66.out

Changeset: c635a966ce84
Author:    mcimadamore
Date:      2013-04-08 15:59 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/c635a966ce84

8010822: Intersection type cast for functional expressions does not follow spec EDR
Summary: Remove support for marker interfaces; redefine intersection type casts to be order-independent
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Type.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/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
+ test/tools/javac/diags/examples/NotAnInterfaceComponent.java
- test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java
! test/tools/javac/lambda/Intersection01.java
- test/tools/javac/lambda/Intersection01.out
! test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java

Changeset: b402b93cbe38
Author:    jjg
Date:      2013-04-08 11:54 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/b402b93cbe38

8011676: Instances of Tokens.Comment should not be defined in inner classes
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java
! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java

Changeset: 3f3cc8d3f13c
Author:    jjg
Date:      2013-04-08 11:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/3f3cc8d3f13c

8011677: EndPosTables should avoid hidden references to Parser
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/parser/JavacParser.java

Changeset: 1f19b84efa6d
Author:    lana
Date:      2013-04-16 08:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/1f19b84efa6d

Merge

- src/share/classes/com/sun/tools/javac/util/CloseableURLClassLoader.java
- test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java
- test/tools/javac/lambda/Intersection01.out
- test/tools/javac/lambda/TargetType01.out

Changeset: 2b585be0da7a
Author:    katleman
Date:      2013-04-12 15:22 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/2b585be0da7a

8012048: JDK8 b85 source with GPL header errors
Reviewed-by: iris, mduigou, jjg

! test/com/sun/javadoc/testAnnotationOptional/TestAnnotationOptional.java
! test/com/sun/javadoc/testAnnotationOptional/pkg/AnnotationOptional.java
! test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java
! test/com/sun/javadoc/typeAnnotations/smoke/pkg/TargetTypes.java

Changeset: 717bcda533f2
Author:    katleman
Date:      2013-04-15 14:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/717bcda533f2

Merge


Changeset: 6ab578e141df
Author:    katleman
Date:      2013-04-16 15:00 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/6ab578e141df

Merge


Changeset: 4f4509c2fe35
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/4f4509c2fe35

Added tag jdk8-b86 for changeset 6ab578e141df

! .hgtags


From yumin.qi at oracle.com  Thu Apr 18 22:21:28 2013
From: yumin.qi at oracle.com (Yumin Qi)
Date: Thu, 18 Apr 2013 22:21:28 -0700
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <5170A77A.6080006@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>
	<516FA67B.20308@oracle.com> <5170A77A.6080006@oracle.com>
Message-ID: <5170D458.5090102@oracle.com>


On 4/18/2013 7:10 PM, David Holmes wrote:
> On 18/04/2013 5:53 PM, Yumin Qi wrote:
>> Thanks Coleen and David, I update the webrev (same URL) for
>> HandleMark(handles.hpp) and also several files' Copyright year.
>
> Thanks for that.
>
> One thing that just occurred to me is that NEW_C_HEAP_OBJ can only be 
> used for classes that have no virtual methods - as there is nothing to 
> initialize the vtable pointer. I think we got lucky with HandleMark in 
> that regard, but there should be a warning attached to it as well.
>
Thanks! I tried, it will segment fault!

+// allocate type in heap without calling ctor
+// WARNING: type must not have virtual functions!!! There is no way to 
initialize vtable.
  #define NEW_C_HEAP_OBJ(type, memflags)\
    NEW_C_HEAP_ARRAY(type, 1, memflags)

Same link update.

Thanks
Yumin
> Thanks,
> David
>
>> 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 david.holmes at oracle.com  Thu Apr 18 22:46:59 2013
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Apr 2013 15:46:59 +1000
Subject: RFR: 8010992: Remove calls to global ::operator new[] and new
In-Reply-To: <5170D458.5090102@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>
	<516FA67B.20308@oracle.com> <5170A77A.6080006@oracle.com>
	<5170D458.5090102@oracle.com>
Message-ID: <5170DA53.8090505@oracle.com>

Ship it! :)

TGIF I need a break :)

Thanks,
David

On 19/04/2013 3:21 PM, Yumin Qi wrote:
>
> On 4/18/2013 7:10 PM, David Holmes wrote:
>> On 18/04/2013 5:53 PM, Yumin Qi wrote:
>>> Thanks Coleen and David, I update the webrev (same URL) for
>>> HandleMark(handles.hpp) and also several files' Copyright year.
>>
>> Thanks for that.
>>
>> One thing that just occurred to me is that NEW_C_HEAP_OBJ can only be
>> used for classes that have no virtual methods - as there is nothing to
>> initialize the vtable pointer. I think we got lucky with HandleMark in
>> that regard, but there should be a warning attached to it as well.
>>
> Thanks! I tried, it will segment fault!
>
> +// allocate type in heap without calling ctor
> +// WARNING: type must not have virtual functions!!! There is no way to
> initialize vtable.
>   #define NEW_C_HEAP_OBJ(type, memflags)\
>     NEW_C_HEAP_ARRAY(type, 1, memflags)
>
> Same link update.
>
> Thanks
> Yumin
>> Thanks,
>> David
>>
>>> 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 martin.doerr at sap.com  Fri Apr 19 05:02:55 2013
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 19 Apr 2013 12:02:55 +0000
Subject: RFR (S): G1: Fix bug in graphKit.cpp accessing PtrQueue::_index
Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165668F433AD@DEWDFEMB13A.global.corp.sap>

Hi all,

we found a bug in the G1 barriers generated by the C2 compiler.

In graphKit INT operations were generated to access PtrQueue::_index which
has type size_t. This is 64 bit on 64-bit machines. No problems occur on
little endian machines as long as the index fits into 32 bit, but on
big endian machines the upper part is read, which is zero. This leads
to unnecessary branches to the slow path into the runtime.

The fix introduces X operations where INT was used:
http://cr.openjdk.java.net/~goetz/webrevs/g1-size_t_bug/

This also removes a cast node.

We have also added a type T_X in globalDefinitions.hpp. Is there
already a mechanism to express this?

Please supply a bug id and review this change.

Best regards,
Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130419/621ee71e/attachment.html 

From vladimir.x.ivanov at oracle.com  Fri Apr 19 07:17:04 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 19 Apr 2013 18:17:04 +0400
Subject: RFR (S): 8012260: ciReplay: Include PID into the name of replay
	data file
In-Reply-To: <516ECE0E.8010006@oracle.com>
References: <516DE649.9020105@oracle.com> <516E3191.4020401@oracle.com>
	<516EBD8A.9090009@oracle.com> <516EC599.5000401@oracle.com>
	<516EC7E2.40401@oracle.com> <516ECE0E.8010006@oracle.com>
Message-ID: <517151E0.8080909@oracle.com>

Updated fix:
http://cr.openjdk.java.net/~vlivanov/8012260/webrev.02/

Did some additional cleanup: changed get_current_directory to accept 
size_t instead of int as a buffer size.

Best regards,
Vladimir Ivanov

On 4/17/13 8:30 PM, Vladimir Kozlov wrote:
> 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 vladimir.kozlov at oracle.com  Fri Apr 19 08:22:03 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 19 Apr 2013 08:22:03 -0700
Subject: RFR (S): 8012260: ciReplay: Include PID into the name of replay
	data file
In-Reply-To: <517151E0.8080909@oracle.com>
References: <516DE649.9020105@oracle.com> <516E3191.4020401@oracle.com>
	<516EBD8A.9090009@oracle.com> <516EC599.5000401@oracle.com>
	<516EC7E2.40401@oracle.com> <516ECE0E.8010006@oracle.com>
	<517151E0.8080909@oracle.com>
Message-ID: <5171611B.7000403@oracle.com>

Looks good.

Thanks,
Vladimir

On 4/19/13 7:17 AM, Vladimir Ivanov wrote:
> Updated fix:
> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.02/
>
> Did some additional cleanup: changed get_current_directory to accept
> size_t instead of int as a buffer size.
>
> Best regards,
> Vladimir Ivanov
>
> On 4/17/13 8:30 PM, Vladimir Kozlov wrote:
>> 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 vladimir.x.ivanov at oracle.com  Fri Apr 19 09:34:49 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 19 Apr 2013 20:34:49 +0400
Subject: RFR (S): 8012260: ciReplay: Include PID into the name of replay
	data file
In-Reply-To: <5171611B.7000403@oracle.com>
References: <516DE649.9020105@oracle.com> <516E3191.4020401@oracle.com>
	<516EBD8A.9090009@oracle.com> <516EC599.5000401@oracle.com>
	<516EC7E2.40401@oracle.com> <516ECE0E.8010006@oracle.com>
	<517151E0.8080909@oracle.com> <5171611B.7000403@oracle.com>
Message-ID: <51717229.9000800@oracle.com>

Thank you, Vladimir.

Best regards,
Vladimir Ivanov

On 4/19/13 7:22 PM, Vladimir Kozlov wrote:
> Looks good.
>
> Thanks,
> Vladimir
>
> On 4/19/13 7:17 AM, Vladimir Ivanov wrote:
>> Updated fix:
>> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.02/
>>
>> Did some additional cleanup: changed get_current_directory to accept
>> size_t instead of int as a buffer size.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 4/17/13 8:30 PM, Vladimir Kozlov wrote:
>>> 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  Fri Apr 19 09:38:24 2013
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 19 Apr 2013 20:38:24 +0400
Subject: RFR(S) : 8011675: adding compilation level to replay data
In-Reply-To: <517072CC.2070204@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> <516EDD81.5000101@oracle.com>
	<51705C23.90206@oracle.com> <517072CC.2070204@oracle.com>
Message-ID: <51717300.6090803@oracle.com>

> Can you save command's output (stderr and stdout) into a file and grep
> it instead?
i did it, even i don't see any reason for it. could you explain the 
cause of your request?

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

Best regards,
Igor Ignatyev

On 04/19/2013 02:25 AM, Vladimir Kozlov wrote:
> I wish we also record core's location in hs_err file so you can grep it
> instead of stderr output.
>
> Can you save command's output (stderr and stdout) into a file and grep
> it instead?
>
> Thanks,
> Vladimir
>
> On 4/18/13 1:48 PM, Igor Ignatyev wrote:
>> Vladimir,
>> thank you for review.
>>
>> i have additional small changes for it:
>> - improved finding of coredump location, now it correctly works on mac
>> os.
>>
>> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.06/
>>
>> Best regards,
>> Igor Ignatyev
>>
>> On 04/17/2013 09:36 PM, Vladimir Kozlov wrote:
>>> 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 vladimir.x.ivanov at oracle.com  Fri Apr 19 10:03:49 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 19 Apr 2013 21:03:49 +0400
Subject: RFR (S): 8012260: ciReplay: Include PID into the name of replay
	data file
In-Reply-To: <5171611B.7000403@oracle.com>
References: <516DE649.9020105@oracle.com> <516E3191.4020401@oracle.com>
	<516EBD8A.9090009@oracle.com> <516EC599.5000401@oracle.com>
	<516EC7E2.40401@oracle.com> <516ECE0E.8010006@oracle.com>
	<517151E0.8080909@oracle.com> <5171611B.7000403@oracle.com>
Message-ID: <517178F5.9030604@oracle.com>

I need one more "official" review. Any volunteers? :-)

Thanks!

Best regards,
Vladimir Ivanov

On 4/19/13 7:22 PM, Vladimir Kozlov wrote:
> Looks good.
>
> Thanks,
> Vladimir
>
> On 4/19/13 7:17 AM, Vladimir Ivanov wrote:
>> Updated fix:
>> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.02/
>>
>> Did some additional cleanup: changed get_current_directory to accept
>> size_t instead of int as a buffer size.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 4/17/13 8:30 PM, Vladimir Kozlov wrote:
>>> 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 christian.thalinger at oracle.com  Fri Apr 19 11:28:11 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 19 Apr 2013 11:28:11 -0700
Subject: RFR (S/M): 8012547: Reclamation of flushed methods can be slow
In-Reply-To: <516FF08A.2080808@oracle.com>
References: <516FF08A.2080808@oracle.com>
Message-ID: 

Looks good.  One minor comment:

src/share/vm/runtime/sweeper.hpp:

   static void notify(nmethod* nm) {
     // Perform a full scan of the code cache from the beginning.  No
     // need to synchronize the setting of this flag since it only
     // changes to false at safepoint so we can never overwrite it with false.
-     _rescan = true;
+     _resweep = true;
   }

Could you change the comment to not only talk about a full scan but also the sweeping?

-- Chris

On Apr 18, 2013, at 6:09 AM, Nils Eliasson  wrote:

> 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 unnecessary long time sometimes causing unnecessary new flushes.
> 
> Also some refactoring
> - remove state variable _do_sweep that was unnecessary. It marked if a sweep was active or not, but just a duplicate way of checking if any methods are being sweept (nmethodsweeper::current != NULL).
> - rename _rescan to _resweep. When _resweep is set there will be another sweep started when the current ends. That sweep will start with a scan, but it is not only a scan.
> - rename _advise_to_sweep to _flush_token. Is CASed by the first thread that wants to flush and reset by scan_stacks when the flush is finished and a proper time has passed.
> 
> http://cr.openjdk.java.net/~neliasso/8012547/ 
> https://jbs.oracle.com/bugs/browse/JDK-8012547
> 
> Thanks,
> Nils E.


From christian.thalinger at oracle.com  Fri Apr 19 11:36:58 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 19 Apr 2013 11:36:58 -0700
Subject: 8012715: GraphKit accesses PtrQueue::_index as int but is size_t
	[Was: Re: RFR (S): G1: Fix bug in graphKit.cpp accessing
	PtrQueue::_index]
In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165668F433AD@DEWDFEMB13A.global.corp.sap>
References: <7C9B87B351A4BA4AA9EC95BB4181165668F433AD@DEWDFEMB13A.global.corp.sap>
Message-ID: 

Here is a bug number:

8012715: GraphKit accesses PtrQueue::_index as int but is size_t

I don't really like T_X.  Let me talk to Vladimir about this.

-- Chris

On Apr 19, 2013, at 5:02 AM, "Doerr, Martin"  wrote:

> Hi all,
>  
> we found a bug in the G1 barriers generated by the C2 compiler.
>  
> In graphKit INT operations were generated to access PtrQueue::_index which
> has type size_t. This is 64 bit on 64-bit machines. No problems occur on
> little endian machines as long as the index fits into 32 bit, but on
> big endian machines the upper part is read, which is zero. This leads
> to unnecessary branches to the slow path into the runtime.
>  
> The fix introduces X operations where INT was used:
> http://cr.openjdk.java.net/~goetz/webrevs/g1-size_t_bug/
>  
> This also removes a cast node.
>  
> We have also added a type T_X in globalDefinitions.hpp. Is there
> already a mechanism to express this?
>  
> Please supply a bug id and review this change.
>  
> Best regards,
> Martin
>  

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

From christian.thalinger at oracle.com  Fri Apr 19 11:52:48 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 19 Apr 2013 11:52:48 -0700
Subject: RFR (S): 8012260: ciReplay: Include PID into the name of replay
	data file
In-Reply-To: <517178F5.9030604@oracle.com>
References: <516DE649.9020105@oracle.com> <516E3191.4020401@oracle.com>
	<516EBD8A.9090009@oracle.com> <516EC599.5000401@oracle.com>
	<516EC7E2.40401@oracle.com> <516ECE0E.8010006@oracle.com>
	<517151E0.8080909@oracle.com> <5171611B.7000403@oracle.com>
	<517178F5.9030604@oracle.com>
Message-ID: 

src/os/windows/vm/os_windows.cpp:

+   if (buflen > INT_MAX)  n = INT_MAX;

Why do we have this check on Windows?

src/share/vm/utilities/ostream.hpp:

!   fileStream(FILE* file, bool need_close=false) { _file = file; _need_close = need_close; }

Please put spaces before and after "=".

+        if (pos > 0 &&
+            Arguments::copy_expand_pid(default_pattern, strlen(default_pattern),
+                                       &buf[pos], buflen-pos)) {
+          fd = open(buf, O_RDWR | O_CREAT | O_TRUNC, 0666);
+        }

Could you factor this code into a method?  It's duplicated three times.

Otherwise this looks good.

-- Chris

On Apr 19, 2013, at 10:03 AM, Vladimir Ivanov  wrote:

> I need one more "official" review. Any volunteers? :-)
> 
> Thanks!
> 
> Best regards,
> Vladimir Ivanov
> 
> On 4/19/13 7:22 PM, Vladimir Kozlov wrote:
>> Looks good.
>> 
>> Thanks,
>> Vladimir
>> 
>> On 4/19/13 7:17 AM, Vladimir Ivanov wrote:
>>> Updated fix:
>>> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.02/
>>> 
>>> Did some additional cleanup: changed get_current_directory to accept
>>> size_t instead of int as a buffer size.
>>> 
>>> Best regards,
>>> Vladimir Ivanov
>>> 
>>> On 4/17/13 8:30 PM, Vladimir Kozlov wrote:
>>>> 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  Fri Apr 19 13:54:17 2013
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Sat, 20 Apr 2013 00:54:17 +0400
Subject: RFR(S): 8012322 : Tiered:
	CompilationPolicy::can_be_compiled(CompLevel_all)
	mistakenly return false
In-Reply-To: <51707622.5010206@oracle.com>
References: <51702DBA.6030302@oracle.com> <51703544.20305@oracle.com>
	<51706FAF.1020303@oracle.com> <51707622.5010206@oracle.com>
Message-ID: <5171AEF9.3050005@oracle.com>

Vladimir,

Thank you for review.

Best regards,
Igor Ignatyev

On 04/19/2013 02:39 AM, Vladimir Kozlov wrote:
> Good.
>
> Thanks,
> Vladimir
>
> On 4/18/13 3:11 PM, Igor Ignatyev wrote:
>>  > For the code to be "clear and self-documented" :) use some meaningful
>>  > names instead of 'i', 'j' and 'n'.
>> renamed
>>
>> http://cr.openjdk.java.net/~iignatyev/8012322/webrev.01/
>>
>> Best regards,
>> Igor Ignatyev
>>
>> On 04/18/2013 10:02 PM, Vladimir Kozlov wrote:
>>> Changes are good. My only complain is variables naming:
>>>
>>> !             final int n = TIERED_STOP_AT_LEVEL + 1;
>>> +             for (int i = 1; i < n; ++i) {
>>>
>>> +         for (int j = 1, n = TIERED_STOP_AT_LEVEL + 1; j < n; ++j) {
>>>
>>> For the code to be "clear and self-documented" :) use some meaningful
>>> names instead of 'i', 'j' and 'n'.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 4/18/13 10:30 AM, Igor Ignatyev wrote:
>>>> Hi all,
>>>>
>>>> Please review the patch.
>>>>
>>>> Problem:
>>>> if method is 'not_compilable' in C1 or C2,
>>>> 'CompilationPolicy::can_be_compiled' will return false for
>>>> 'CompLevel_all' even it is compilable in another level
>>>>
>>>> Fix:
>>>> 1. added explicit comp_level to all calls of
>>>> CompilationPolicy::can_be_compiled
>>>> 2. in CompilationPolicy::can_be_compiled()
>>>>    - added assert for checking legality of comp_level
>>>>    - changed logic for comp_level == CompLevel_all
>>>>
>>>> Testing:
>>>> JPRT 'compiler/whitebox'
>>>>
>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8012322/webrev.00/
>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8012322

From alejandro.murillo at oracle.com  Fri Apr 19 14:57:05 2013
From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com)
Date: Fri, 19 Apr 2013 21:57:05 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 22 new changesets
Message-ID: <20130419215751.29D7D48493@hg.openjdk.java.net>

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

8012048: JDK8 b85 source with GPL header errors
Reviewed-by: iris, mduigou, jjg

! make/bsd/makefiles/fastdebug.make
! src/share/vm/services/diagnosticArgument.cpp
! test/sanity/WBApi.java
! test/serviceability/ParserTest.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java
! test/testlibrary/whitebox/sun/hotspot/parser/DiagnosticCommand.java

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

Merge

! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 86db4847f195
Author:    katleman
Date:      2013-04-17 12:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/86db4847f195

Merge

! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 2e657354f6bc
Author:    katleman
Date:      2013-04-18 10:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2e657354f6bc

Added tag jdk8-b86 for changeset 86db4847f195

! .hgtags

Changeset: 35f8765422b9
Author:    zgu
Date:      2013-04-10 08:55 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/35f8765422b9

8010151: nsk/regression/b6653214 fails "assert(snapshot != NULL) failed: Worker should not be started"
Summary: Fixed a racing condition when shutting down NMT while worker thread is being started, also fixed a few mis-declared volatile pointers.
Reviewed-by: dholmes, dlong

! src/share/vm/runtime/thread.hpp
! src/share/vm/services/memTrackWorker.cpp
! src/share/vm/services/memTrackWorker.hpp
! src/share/vm/services/memTracker.cpp
! src/share/vm/services/memTracker.hpp

Changeset: f2c0ccccc6b6
Author:    rdurbin
Date:      2013-04-16 08:59 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f2c0ccccc6b6

Merge


Changeset: 71013d764f6e
Author:    johnc
Date:      2013-04-10 10:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/71013d764f6e

8010780: G1: Eden occupancy/capacity output wrong after a full GC
Summary: Move the calculation and recording of eden capacity to the start of a GC and print a detailed heap transition for full GCs.
Reviewed-by: tschatzl, jmasa

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp

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

Merge

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: 9aa8d8037ee3
Author:    mgerdin
Date:      2013-04-16 12:46 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9aa8d8037ee3

Merge

! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp

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

8011173: NPG: Replace the ChunkList implementation with class FreeList
Reviewed-by: mgerdin, tschatzl, johnc, coleenp

! src/share/vm/memory/metaspace.cpp

Changeset: f2e682ef3156
Author:    johnc
Date:      2013-04-17 10:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f2e682ef3156

8012335: G1: Fix bug with compressed oops in template interpreter on x86 and sparc.
Summary: In do_oop_store the uncompressed value of the oop being stored needs to be preserved and passed to g1_write_barrier_post. This is necessary for the heap region cross check to work correctly.
Reviewed-by: coleenp, johnc
Contributed-by: Martin Doerr 

! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp

Changeset: 07a4efc5ed14
Author:    brutisso
Date:      2013-04-18 06:50 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/07a4efc5ed14

8012455: Missing time and date stamps for PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime
Summary: also reviewed by: kirk at kodewerk.com, brandon at twitter.com
Reviewed-by: tschatzl, stefank, johnc

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

Changeset: cbf8c8c25bbe
Author:    mgerdin
Date:      2013-04-18 14:38 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cbf8c8c25bbe

Merge


Changeset: aeaca88565e6
Author:    jiangli
Date:      2013-04-09 17:17 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/aeaca88565e6

8010862: The Method counter fields used for profiling can be allocated lazily.
Summary: Allocate the method's profiling related metadata until they are needed.
Reviewed-by: coleenp, roland

! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java
+ agent/src/share/classes/sun/jvm/hotspot/oops/MethodCounters.java
! src/cpu/sparc/vm/cppInterpreter_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.cpp
! src/cpu/sparc/vm/interp_masm_sparc.hpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interp_masm_x86_32.hpp
! src/cpu/x86/vm/interp_masm_x86_64.cpp
! src/cpu/x86/vm/interp_masm_x86_64.hpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/ci/ciMethod.cpp
! src/share/vm/ci/ciMethod.hpp
! src/share/vm/ci/ciReplay.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/interpreterRuntime.hpp
! src/share/vm/interpreter/invocationCounter.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
+ src/share/vm/oops/methodCounters.cpp
+ src/share/vm/oops/methodCounters.hpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/runtime/advancedThresholdPolicy.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/fprofiler.cpp
! src/share/vm/runtime/simpleThresholdPolicy.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 42a42da29fd7
Author:    jiangli
Date:      2013-04-11 23:06 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/42a42da29fd7

8012052: java/lang/invoke/6987555/Test6987555.java crashes with assert(mcs != NULL) failed: MethodCounters cannot be NULL.
Summary: Skip counter decay if the MethodCounters is NULL in NonTieredCompPolicy::delay_compilation().
Reviewed-by: kvn, dholmes

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

Changeset: 8df6ddda8090
Author:    jiangli
Date:      2013-04-15 21:25 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8df6ddda8090

Merge

! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/oops/methodData.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 9500809ceead
Author:    jiangli
Date:      2013-04-18 17:00 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9500809ceead

Merge

! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp

Changeset: dedc8563e33d
Author:    bharadwaj
Date:      2013-04-18 16:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dedc8563e33d

Merge

- make/bsd/makefiles/jvmg.make
- make/bsd/makefiles/profiled.make
- make/linux/makefiles/jvmg.make
- make/linux/makefiles/profiled.make
- make/solaris/makefiles/jvmg.make
- make/solaris/makefiles/profiled.make
- 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

Changeset: 2a9d97b57920
Author:    bharadwaj
Date:      2013-04-19 03:13 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2a9d97b57920

Merge

- make/bsd/makefiles/jvmg.make
- make/bsd/makefiles/profiled.make
- make/linux/makefiles/jvmg.make
- make/linux/makefiles/profiled.make
- make/solaris/makefiles/jvmg.make
- make/solaris/makefiles/profiled.make
- 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/c1/c1_LIRGenerator.cpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 01d5f04e64dc
Author:    amurillo
Date:      2013-04-19 09:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/01d5f04e64dc

Merge

! make/bsd/makefiles/fastdebug.make
- make/bsd/makefiles/jvmg.make
- make/bsd/makefiles/profiled.make
- make/linux/makefiles/jvmg.make
- make/linux/makefiles/profiled.make
- make/solaris/makefiles/jvmg.make
- make/solaris/makefiles/profiled.make
- 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
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

Changeset: 0491c26b1f1d
Author:    amurillo
Date:      2013-04-19 09:58 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0491c26b1f1d

Added tag hs25-b29 for changeset 01d5f04e64dc

! .hgtags

Changeset: f78763f49817
Author:    amurillo
Date:      2013-04-19 10:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f78763f49817

8012559: new hotspot build - hs25-b30
Reviewed-by: jcoomes

! make/hotspot_version


From vladimir.x.ivanov at oracle.com  Fri Apr 19 15:17:05 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Sat, 20 Apr 2013 02:17:05 +0400
Subject: RFR (S): 8012260: ciReplay: Include PID into the name of replay
	data file
In-Reply-To: 
References: <516DE649.9020105@oracle.com> <516E3191.4020401@oracle.com>
	<516EBD8A.9090009@oracle.com> <516EC599.5000401@oracle.com>
	<516EC7E2.40401@oracle.com> <516ECE0E.8010006@oracle.com>
	<517151E0.8080909@oracle.com> <5171611B.7000403@oracle.com>
	<517178F5.9030604@oracle.com>
	
Message-ID: <5171C261.1060207@oracle.com>

Thank you for review, Chris!

> src/os/windows/vm/os_windows.cpp:
>
> +   if (buflen > INT_MAX)  n = INT_MAX;
>
> Why do we have this check on Windows?
Since _getcwd requires int on Windows, this is a consequence of size_t 
-> int conversion.

> src/share/vm/utilities/ostream.hpp:
>
> !   fileStream(FILE* file, bool need_close=false) { _file = file; _need_close = need_close; }
>
> Please put spaces before and after "=".
Sure, will do.

> +        if (pos > 0 &&
> +            Arguments::copy_expand_pid(default_pattern, strlen(default_pattern),
> +                                       &buf[pos], buflen-pos)) {
> +          fd = open(buf, O_RDWR | O_CREAT | O_TRUNC, 0666);
> +        }
>
> Could you factor this code into a method?  It's duplicated three times.
Yeah, I don't like it either :-) But I don't think that a function call 
will help here. Maybe factoring parameters may help, but I'm not sure. 
What do you prefer?

Best regards,
Vladimir Ivanov

> Otherwise this looks good.
>
> -- Chris
>
> On Apr 19, 2013, at 10:03 AM, Vladimir Ivanov  wrote:
>
>> I need one more "official" review. Any volunteers? :-)
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 4/19/13 7:22 PM, Vladimir Kozlov wrote:
>>> Looks good.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 4/19/13 7:17 AM, Vladimir Ivanov wrote:
>>>> Updated fix:
>>>> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.02/
>>>>
>>>> Did some additional cleanup: changed get_current_directory to accept
>>>> size_t instead of int as a buffer size.
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>> On 4/17/13 8:30 PM, Vladimir Kozlov wrote:
>>>>> 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 andrew_nuss at yahoo.com  Fri Apr 19 17:08:23 2013
From: andrew_nuss at yahoo.com (Andy Nuss)
Date: Fri, 19 Apr 2013 17:08:23 -0700 (PDT)
Subject: do generic member functions have 2 physical versions
Message-ID: <1366416503.61528.YahooMailNeo@web141102.mail.bf1.yahoo.com>

Hi,

Lets say I have a class:

public abstract class AbstractVar {
???? public abstract T get ();
???? public abstract void set (T t);
}

and a subclass for a general T:

public class Var extends AbstractVar {
???? private T t;
???? public T get ()
???? {
????????? return t;
???? }
???? // ??? is the byte code signature the same as if: set (Object t)

???? public void set (T t)
???? {
????????? this.t = t;

???? }
}

and another for a specific kind of T:

public class VarString extends AbstractVar {
???? private String s;
???? public String get ()
???? {
????????? return s;
???? }
???? public void set (String s)
???? {
????????? this.s = s;
???? }

}

My question regards the generated bytecode and virtual functions.? It would see that for Var, since the member variable is of type T, it really is of type Object, so that Var can work for all parameterizations of T without bloating the generic.? Yet VarString implements the same abstract interface.? It would seem that with Var, the setter actually takes an argument of type Object, while the setter in VarString takes an argument of type String, making them different functions that satisfy the same virtual function in the abstract contract.? If so, how does it work, especially given that the two non-abstract getters would have the same signature and different results?

Thanks,
Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130419/4477b10b/attachment-0001.html 

From christian.thalinger at oracle.com  Fri Apr 19 21:03:29 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 19 Apr 2013 21:03:29 -0700
Subject: RFR (S): 8012260: ciReplay: Include PID into the name of replay
	data file
In-Reply-To: <5171C261.1060207@oracle.com>
References: <516DE649.9020105@oracle.com> <516E3191.4020401@oracle.com>
	<516EBD8A.9090009@oracle.com> <516EC599.5000401@oracle.com>
	<516EC7E2.40401@oracle.com> <516ECE0E.8010006@oracle.com>
	<517151E0.8080909@oracle.com> <5171611B.7000403@oracle.com>
	<517178F5.9030604@oracle.com>
	
	<5171C261.1060207@oracle.com>
Message-ID: 


On Apr 19, 2013, at 3:17 PM, Vladimir Ivanov  wrote:

> Thank you for review, Chris!
> 
>> src/os/windows/vm/os_windows.cpp:
>> 
>> +   if (buflen > INT_MAX)  n = INT_MAX;
>> 
>> Why do we have this check on Windows?
> Since _getcwd requires int on Windows, this is a consequence of size_t -> int conversion.

Got it.

> 
>> src/share/vm/utilities/ostream.hpp:
>> 
>> !   fileStream(FILE* file, bool need_close=false) { _file = file; _need_close = need_close; }
>> 
>> Please put spaces before and after "=".
> Sure, will do.
> 
>> +        if (pos > 0 &&
>> +            Arguments::copy_expand_pid(default_pattern, strlen(default_pattern),
>> +                                       &buf[pos], buflen-pos)) {
>> +          fd = open(buf, O_RDWR | O_CREAT | O_TRUNC, 0666);
>> +        }
>> 
>> Could you factor this code into a method?  It's duplicated three times.
> Yeah, I don't like it either :-) But I don't think that a function call will help here. Maybe factoring parameters may help, but I'm not sure. What do you prefer?

Putting Arguments::copy_expand_pid and open calls into a method sounds like a win to me.

-- Chris

> 
> Best regards,
> Vladimir Ivanov
> 
>> Otherwise this looks good.
>> 
>> -- Chris
>> 
>> On Apr 19, 2013, at 10:03 AM, Vladimir Ivanov  wrote:
>> 
>>> I need one more "official" review. Any volunteers? :-)
>>> 
>>> Thanks!
>>> 
>>> Best regards,
>>> Vladimir Ivanov
>>> 
>>> On 4/19/13 7:22 PM, Vladimir Kozlov wrote:
>>>> Looks good.
>>>> 
>>>> Thanks,
>>>> Vladimir
>>>> 
>>>> On 4/19/13 7:17 AM, Vladimir Ivanov wrote:
>>>>> Updated fix:
>>>>> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.02/
>>>>> 
>>>>> Did some additional cleanup: changed get_current_directory to accept
>>>>> size_t instead of int as a buffer size.
>>>>> 
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>> 
>>>>> On 4/17/13 8:30 PM, Vladimir Kozlov wrote:
>>>>>> 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 david.r.chase at oracle.com  Sun Apr 21 14:06:54 2013
From: david.r.chase at oracle.com (David Chase)
Date: Sun, 21 Apr 2013 17:06:54 -0400
Subject: RFR(S): 8010770 : Zero: back port of 8000780 to HS24 broke JSR 292
Message-ID: <41BE1F4C-1A44-42FD-ACE9-5B7173A5455C@oracle.com>

Bug: changes made to Zero for jdk8 compatibility broke jsr292 when they were backported
to HS24.  This patch fixes that.

Fix: from Volker Simonis
"I've just realized that something must have gone wrong during the downport of 8000780 to hsx24 (probably because of the change of the content of the f1 and f2 fields in the ConstantPoolCacheEntry between hsx24 and hsx25). Unfortunately now both, '_invokedynamic' as well as '_invokehandle' don't work in the CC-interpreter anymore. The attached patch (against hsx24) fixes the problem and lets the Zero-VM pass the java/lang/invoke JTreg tests again. 

These changes are needed for making JSR292 work in the Zero-port in jdk7u with hsx24."

Testing:
1) jtreg with zero applied to jdk/test/java/lang/invoke -- very broken without patch, works with patch.  
2) JPRT
Repositories used for test:
http://hg.openjdk.java.net/jdk7u/jdk7u-dev + http://hg.openjdk.java.net/hsx/hsx24/hotspot/hotspot

Webrev: http://cr.openjdk.java.net/~drchase/8010770/webrev.00/


From volker.simonis at gmail.com  Mon Apr 22 01:31:34 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 22 Apr 2013 10:31:34 +0200
Subject: RFR(S): 8010770 : Zero: back port of 8000780 to HS24 broke JSR 292
In-Reply-To: <41BE1F4C-1A44-42FD-ACE9-5B7173A5455C@oracle.com>
References: <41BE1F4C-1A44-42FD-ACE9-5B7173A5455C@oracle.com>
Message-ID: 

Hi David,

thank you for dealing with this.

I'm not a formal reviewer, but as I wrote before, I can confirm that this
changes fixes JSR292 in the CC_Interpreter in hsx24.

For actual reviewers, here's a short description on how I build the ZERO-VM
on Linux/AMD64 and how I ran the java/lang/invoke JTreg tests:

in hsx24/hotspot/make (with the patch) do:

ALT_BOOTDIR=/share/software/Java/jdk1.7.0
ALT_OUTPUTDIR=../../output_64_zero_opt ARCH_DATA_MODEL=64 ZERO_BUILD=true
ZERO_LIBARCH=amd64 ZERO_ARCHDEF=AMD64 ZERO_ENDIANNESS=little
LIBFFI_LIBS=-lffi DEBUG_BINARIES=true JVM_VARIANT_ZERO=true make productzero

copy the resulting libjvm.so into a corresponding JDK image
('/tmp/j2sdk-image_for_zero' in my case) and do:

JT_JAVA=/tmp/j2sdk-image_for_zero
/share/software/Java/jtreg/linux/bin/jtreg
-J-Djunit.jar=/share/software/Java/junit4.5/junit-4.5.jar
-jdk:/tmp/j2sdk-image_for_zero
-dir:/usr/work/OpenJDK/ppc-aix-port/jdk7u/jdk/test
-reportDir:/tmp/jtreg/JTreport -workDir:/tmp/jtreg/JTwork
-timeoutFactor:100 java/lang/invoke

Note that the big 'timeoutFactor' is necessary in order to pass all tests.

Thank you and best regards,
Volker


On Sun, Apr 21, 2013 at 11:06 PM, David Chase wrote:

> Bug: changes made to Zero for jdk8 compatibility broke jsr292 when they
> were backported
> to HS24.  This patch fixes that.
>
> Fix: from Volker Simonis
> "I've just realized that something must have gone wrong during the
> downport of 8000780 to hsx24 (probably because of the change of the content
> of the f1 and f2 fields in the ConstantPoolCacheEntry between hsx24 and
> hsx25). Unfortunately now both, '_invokedynamic' as well as '_invokehandle'
> don't work in the CC-interpreter anymore. The attached patch (against
> hsx24) fixes the problem and lets the Zero-VM pass the java/lang/invoke
> JTreg tests again.
>
> These changes are needed for making JSR292 work in the Zero-port in jdk7u
> with hsx24."
>
> Testing:
> 1) jtreg with zero applied to jdk/test/java/lang/invoke -- very broken
> without patch, works with patch.
> 2) JPRT
> Repositories used for test:
> http://hg.openjdk.java.net/jdk7u/jdk7u-dev +
> http://hg.openjdk.java.net/hsx/hsx24/hotspot/hotspot
>
> Webrev: http://cr.openjdk.java.net/~drchase/8010770/webrev.00/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130422/53e7f969/attachment.html 

From david.r.chase at oracle.com  Mon Apr 22 04:26:04 2013
From: david.r.chase at oracle.com (David Chase)
Date: Mon, 22 Apr 2013 07:26:04 -0400
Subject: RFR(S): 8010770 : Zero: back port of 8000780 to HS24 broke JSR 292
In-Reply-To: 
References: <41BE1F4C-1A44-42FD-ACE9-5B7173A5455C@oracle.com>
	
Message-ID: <0F634B05-8635-4DD6-AAFD-A6C6EF867008@oracle.com>

It's CallSiteTest.java that requires most of the extra time -- 5x was insufficient, 20x was adequate.
This was on a Mac.

My build script (looks a lot like yours):

SEVEN=/Library/Java/JavaVirtualMachines/jdk1.7.0_13.jdk/Contents/Home
export ALT_BOOTDIR=${SEVEN}
export ALT_JDK_IMPORT_PATH=/Users/dr2chase/work/8010770/built/macosx-x86_64/j2sdk-image
export JVM_VARIANT_ZERO=true
export ZERO_BUILD=true
export ZERO_LIBARCH=amd64
export ZERO_ENDIANNESS=little
export ZERO_ARCHDEF=AMD64
export ZERO_ARCHFLAG=-m64
export LIBFFI_CFLAGS="-I/usr/include/ffi"
export LIBFFI_LIBS="-lffi"
export ARCH_DATA_MODEL=64
export LP64=1
export DEBUG_BINARIES=true
export SHARK_BUILD=false
export OPENJDK=true
make "$@"

> ALT_BOOTDIR=/share/software/Java/jdk1.7.0 ALT_OUTPUTDIR=../../output_64_zero_opt ARCH_DATA_MODEL=64 ZERO_BUILD=true ZERO_LIBARCH=amd64 ZERO_ARCHDEF=AMD64 ZERO_ENDIANNESS=little LIBFFI_LIBS=-lffi DEBUG_BINARIES=true JVM_VARIANT_ZERO=true make productzero


Builds would flake out testing with gamma, probably because of pilot error, but who knows?

cd bsd_amd64_zero/product && ./test_gamma
Using java runtime at: /Library/Java/JavaVirtualMachines/jdk1.7.0_13.jdk/Contents/Home/jre
Error occurred during initialization of VM
java/lang/NoClassDefFoundError: java/lang/Object
make[2]: *** [productzero] Error 1
make[1]: *** [generic_buildzero] Error 2
make: *** [productzero] Error 2

On 2013-04-22, at 4:31 AM, Volker Simonis  wrote:
> 
> JT_JAVA=/tmp/j2sdk-image_for_zero /share/software/Java/jtreg/linux/bin/jtreg -J-Djunit.jar=/share/software/Java/junit4.5/junit-4.5.jar -jdk:/tmp/j2sdk-image_for_zero -dir:/usr/work/OpenJDK/ppc-aix-port/jdk7u/jdk/test -reportDir:/tmp/jtreg/JTreport -workDir:/tmp/jtreg/JTwork -timeoutFactor:100 java/lang/invoke
> 
> Note that the big 'timeoutFactor' is necessary in order to pass all tests.


From volker.simonis at gmail.com  Mon Apr 22 05:05:26 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 22 Apr 2013 14:05:26 +0200
Subject: RFR(S): 8010770 : Zero: back port of 8000780 to HS24 broke JSR 292
In-Reply-To: <0F634B05-8635-4DD6-AAFD-A6C6EF867008@oracle.com>
References: <41BE1F4C-1A44-42FD-ACE9-5B7173A5455C@oracle.com>
	
	<0F634B05-8635-4DD6-AAFD-A6C6EF867008@oracle.com>
Message-ID: 

On Mon, Apr 22, 2013 at 1:26 PM, David Chase 
wrote:
> It's CallSiteTest.java that requires most of the extra time -- 5x was
insufficient, 20x was adequate.
> This was on a Mac.
>
> My build script (looks a lot like yours):
>
> SEVEN=/Library/Java/JavaVirtualMachines/jdk1.7.0_13.jdk/Contents/Home
> export ALT_BOOTDIR=${SEVEN}
> export
ALT_JDK_IMPORT_PATH=/Users/dr2chase/work/8010770/built/macosx-x86_64/j2sdk-image
> export JVM_VARIANT_ZERO=true
> export ZERO_BUILD=true
> export ZERO_LIBARCH=amd64
> export ZERO_ENDIANNESS=little
> export ZERO_ARCHDEF=AMD64
> export ZERO_ARCHFLAG=-m64
> export LIBFFI_CFLAGS="-I/usr/include/ffi"
> export LIBFFI_LIBS="-lffi"
> export ARCH_DATA_MODEL=64
> export LP64=1
> export DEBUG_BINARIES=true
> export SHARK_BUILD=false
> export OPENJDK=true
> make "$@"
>
>> ALT_BOOTDIR=/share/software/Java/jdk1.7.0
ALT_OUTPUTDIR=../../output_64_zero_opt ARCH_DATA_MODEL=64 ZERO_BUILD=true
ZERO_LIBARCH=amd64 ZERO_ARCHDEF=AMD64 ZERO_ENDIANNESS=little
LIBFFI_LIBS=-lffi DEBUG_BINARIES=true JVM_VARIANT_ZERO=true make productzero
>
>
> Builds would flake out testing with gamma, probably because of pilot
error, but who knows?
>
> cd bsd_amd64_zero/product && ./test_gamma
> Using java runtime at:
/Library/Java/JavaVirtualMachines/jdk1.7.0_13.jdk/Contents/Home/jre
> Error occurred during initialization of VM
> java/lang/NoClassDefFoundError: java/lang/Object
> make[2]: *** [productzero] Error 1
> make[1]: *** [generic_buildzero] Error 2
> make: *** [productzero] Error 2
>

Strange... Maybe this is Mac related?

I get:

cd linux_amd64_zero/product && ./test_gamma
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b142)
OpenJDK 64-Bit Zero VM (build 24.0-b38-internal, interpreted mode)

 1. A1 B5 C8 D6 E3 F7 G2 H4
...
92. A8 B4 C1 D3 E6 F2 G7 H5
Using java runtime at: /share/software/Java/jdk1.7.0/jre


> On 2013-04-22, at 4:31 AM, Volker Simonis 
wrote:
>>
>> JT_JAVA=/tmp/j2sdk-image_for_zero
/share/software/Java/jtreg/linux/bin/jtreg
-J-Djunit.jar=/share/software/Java/junit4.5/junit-4.5.jar
-jdk:/tmp/j2sdk-image_for_zero
-dir:/usr/work/OpenJDK/ppc-aix-port/jdk7u/jdk/test
-reportDir:/tmp/jtreg/JTreport -workDir:/tmp/jtreg/JTwork
-timeoutFactor:100 java/lang/invoke
>>
>> Note that the big 'timeoutFactor' is necessary in order to pass all
tests.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130422/4e1aed94/attachment.html 

From david.r.chase at oracle.com  Mon Apr 22 05:58:19 2013
From: david.r.chase at oracle.com (David Chase)
Date: Mon, 22 Apr 2013 08:58:19 -0400
Subject: RFR(S): 8010770 : Zero: back port of 8000780 to HS24 broke JSR 292
In-Reply-To: 
References: <41BE1F4C-1A44-42FD-ACE9-5B7173A5455C@oracle.com>
	
	<0F634B05-8635-4DD6-AAFD-A6C6EF867008@oracle.com>
	
Message-ID: <37B79F8D-1E23-4B6D-A641-69FD906EB39B@oracle.com>


On 2013-04-22, at 8:05 AM, Volker Simonis  wrote:
> > Builds would flake out testing with gamma, probably because of pilot error, but who knows?
> >
> > cd bsd_amd64_zero/product && ./test_gamma
> > Using java runtime at: /Library/Java/JavaVirtualMachines/jdk1.7.0_13.jdk/Contents/Home/jre
> > Error occurred during initialization of VM
> > java/lang/NoClassDefFoundError: java/lang/Object
> > make[2]: *** [productzero] Error 1
> > make[1]: *** [generic_buildzero] Error 2
> > make: *** [productzero] Error 2
> >
> 
> Strange... Maybe this is Mac related?
> 
> I get:
> [success]

It might be Mac-related, but who can tell?  I've become a big fan of the new build system.  Not perfect, but a huge improvement on what it replaces.

David



From igor.ignatyev at oracle.com  Mon Apr 22 06:58:55 2013
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 22 Apr 2013 17:58:55 +0400
Subject: RFR(S) : 8011675: adding compilation level to replay data
In-Reply-To: <51717300.6090803@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> <516EDD81.5000101@oracle.com>
	<51705C23.90206@oracle.com> <517072CC.2070204@oracle.com>
	<51717300.6090803@oracle.com>
Message-ID: <5175421F.4010201@oracle.com>

I have rerun JPRT:
  - TestSA.sh passed on macosx
  - TestSA.sh failed only due to known bugs in SA.
  - other ciReplay tests passed

Best regards,
Igor Ignatyev

On 04/19/2013 08:38 PM, Igor Ignatyev wrote:
>> Can you save command's output (stderr and stdout) into a file and grep
>> it instead?
> i did it, even i don't see any reason for it. could you explain the
> cause of your request?
>
> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.07/
>
> Best regards,
> Igor Ignatyev
>
> On 04/19/2013 02:25 AM, Vladimir Kozlov wrote:
>> I wish we also record core's location in hs_err file so you can grep it
>> instead of stderr output.
>>
>> Can you save command's output (stderr and stdout) into a file and grep
>> it instead?
>>
>> Thanks,
>> Vladimir
>>
>> On 4/18/13 1:48 PM, Igor Ignatyev wrote:
>>> Vladimir,
>>> thank you for review.
>>>
>>> i have additional small changes for it:
>>> - improved finding of coredump location, now it correctly works on mac
>>> os.
>>>
>>> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.06/
>>>
>>> Best regards,
>>> Igor Ignatyev
>>>
>>> On 04/17/2013 09:36 PM, Vladimir Kozlov wrote:
>>>> 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 vladimir.kozlov at oracle.com  Mon Apr 22 08:00:42 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 22 Apr 2013 08:00:42 -0700
Subject: RFR(S): 8010770 : Zero: back port of 8000780 to HS24 broke JSR 292
In-Reply-To: <41BE1F4C-1A44-42FD-ACE9-5B7173A5455C@oracle.com>
References: <41BE1F4C-1A44-42FD-ACE9-5B7173A5455C@oracle.com>
Message-ID: <5175509A.6020901@oracle.com>

Looks good.

Vladimir

On 4/21/13 2:06 PM, David Chase wrote:
> Bug: changes made to Zero for jdk8 compatibility broke jsr292 when they were backported
> to HS24.  This patch fixes that.
>
> Fix: from Volker Simonis
> "I've just realized that something must have gone wrong during the downport of 8000780 to hsx24 (probably because of the change of the content of the f1 and f2 fields in the ConstantPoolCacheEntry between hsx24 and hsx25). Unfortunately now both, '_invokedynamic' as well as '_invokehandle' don't work in the CC-interpreter anymore. The attached patch (against hsx24) fixes the problem and lets the Zero-VM pass the java/lang/invoke JTreg tests again.
>
> These changes are needed for making JSR292 work in the Zero-port in jdk7u with hsx24."
>
> Testing:
> 1) jtreg with zero applied to jdk/test/java/lang/invoke -- very broken without patch, works with patch.
> 2) JPRT
> Repositories used for test:
> http://hg.openjdk.java.net/jdk7u/jdk7u-dev + http://hg.openjdk.java.net/hsx/hsx24/hotspot/hotspot
>
> Webrev: http://cr.openjdk.java.net/~drchase/8010770/webrev.00/
>

From vladimir.kozlov at oracle.com  Mon Apr 22 08:08:37 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 22 Apr 2013 08:08:37 -0700
Subject: RFR(S) : 8011675: adding compilation level to replay data
In-Reply-To: <5175421F.4010201@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> <516EDD81.5000101@oracle.com>
	<51705C23.90206@oracle.com> <517072CC.2070204@oracle.com>
	<51717300.6090803@oracle.com> <5175421F.4010201@oracle.com>
Message-ID: <51755275.3050606@oracle.com>

Looks good.

thanks,
Vladimir

On 4/22/13 6:58 AM, Igor Ignatyev wrote:
> I have rerun JPRT:
>   - TestSA.sh passed on macosx
>   - TestSA.sh failed only due to known bugs in SA.
>   - other ciReplay tests passed
>
> Best regards,
> Igor Ignatyev
>
> On 04/19/2013 08:38 PM, Igor Ignatyev wrote:
>>> Can you save command's output (stderr and stdout) into a file and grep
>>> it instead?
>> i did it, even i don't see any reason for it. could you explain the
>> cause of your request?
>>
>> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.07/
>>
>> Best regards,
>> Igor Ignatyev
>>
>> On 04/19/2013 02:25 AM, Vladimir Kozlov wrote:
>>> I wish we also record core's location in hs_err file so you can grep it
>>> instead of stderr output.
>>>
>>> Can you save command's output (stderr and stdout) into a file and grep
>>> it instead?
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 4/18/13 1:48 PM, Igor Ignatyev wrote:
>>>> Vladimir,
>>>> thank you for review.
>>>>
>>>> i have additional small changes for it:
>>>> - improved finding of coredump location, now it correctly works on mac
>>>> os.
>>>>
>>>> http://cr.openjdk.java.net/~iignatyev/8011675/webrev.06/
>>>>
>>>> Best regards,
>>>> Igor Ignatyev
>>>>
>>>> On 04/17/2013 09:36 PM, Vladimir Kozlov wrote:
>>>>> 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 christian.thalinger at oracle.com  Mon Apr 22 09:45:57 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 22 Apr 2013 09:45:57 -0700
Subject: RFR(S): 8010770 : Zero: back port of 8000780 to HS24 broke JSR 292
In-Reply-To: <41BE1F4C-1A44-42FD-ACE9-5B7173A5455C@oracle.com>
References: <41BE1F4C-1A44-42FD-ACE9-5B7173A5455C@oracle.com>
Message-ID: <3733968F-EC3F-4F65-9B67-C799B20AF4AA@oracle.com>

Looks good.  -- Chris

On Apr 21, 2013, at 2:06 PM, David Chase  wrote:

> Bug: changes made to Zero for jdk8 compatibility broke jsr292 when they were backported
> to HS24.  This patch fixes that.
> 
> Fix: from Volker Simonis
> "I've just realized that something must have gone wrong during the downport of 8000780 to hsx24 (probably because of the change of the content of the f1 and f2 fields in the ConstantPoolCacheEntry between hsx24 and hsx25). Unfortunately now both, '_invokedynamic' as well as '_invokehandle' don't work in the CC-interpreter anymore. The attached patch (against hsx24) fixes the problem and lets the Zero-VM pass the java/lang/invoke JTreg tests again. 
> 
> These changes are needed for making JSR292 work in the Zero-port in jdk7u with hsx24."
> 
> Testing:
> 1) jtreg with zero applied to jdk/test/java/lang/invoke -- very broken without patch, works with patch.  
> 2) JPRT
> Repositories used for test:
> http://hg.openjdk.java.net/jdk7u/jdk7u-dev + http://hg.openjdk.java.net/hsx/hsx24/hotspot/hotspot
> 
> Webrev: http://cr.openjdk.java.net/~drchase/8010770/webrev.00/
> 


From roland.westrelin at oracle.com  Tue Apr 23 00:24:44 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 23 Apr 2013 09:24:44 +0200
Subject: RFR(S): 8011771: runThese crashed with EAV
Message-ID: <9CCE54C2-8792-4D87-8784-7AB6BC33A244@oracle.com>

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

During in block motion, a step of array bound check elimination, the code doesn't always reset its data structures correctly when it moves from one array to another (it does when optimistic optimizations are on, not otherwise). As a result, some bound checks are incorrectly optimized out.

Roland.

From goetz.lindenmaier at sap.com  Tue Apr 23 01:09:00 2013
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 23 Apr 2013 08:09:00 +0000
Subject: RFR (M): 8003853: specify offset of IC load in java_to_interp stub
Message-ID: <4295855A5C1DE049A61835A1887419CC0CFB4FFC@DEWDFEMB12A.global.corp.sap>

Hi all,

In the java_to_interp stub of CompiledStaticCalls one relocation is used to find
two code locations:

-          the beginning of the stub

-          the IC load instruction.
On x86 and sparc, the IC load instruction is the first instruction of the stub,
thus both locations have the same address.
On PPC, the IC load instruction is not the first instruction in the stub, thus
we must add an offset to the relocation to access it.

As the manipulation of  CompiledStaticCalls is in shared code, we would have
to introduce platform dependencies there.

This change moves the platform dependent code from CompiledStaticCall
to a new file compiledIC_.cpp.  It also moves the code issuing the
stub from the ad file to this new file into the class CompiledStaticCall.
This removes redundancies between x86_64.ad and x86_32.ad.  Also,
'extern' declarations in compile.cpp can be replaced by properly typed
Calls to methods in CompiledStaticCall.

Dean Long ran this change through JPRT with status OK (thanks!).

Please review and push this change.
http://cr.openjdk.java.net/~goetz/webrevs/8003853-3/

Best regards,
  Goetz Lindenmaier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130423/3825dccb/attachment.html 

From roland.westrelin at oracle.com  Tue Apr 23 03:52:11 2013
From: roland.westrelin at oracle.com (roland.westrelin at oracle.com)
Date: Tue, 23 Apr 2013 10:52:11 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 8011901: Unsafe.getAndAddLong(obj, off, 
	delta) does not work properly with long deltas
Message-ID: <20130423105215.CE9A54850F@hg.openjdk.java.net>

Changeset: 35c15dad89ea
Author:    roland
Date:      2013-04-16 17:06 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/35c15dad89ea

8011901: Unsafe.getAndAddLong(obj, off, delta) does not work properly with long deltas
Summary: instruct xaddL_no_res shouldn't allow 64 bit constants.
Reviewed-by: kvn

! src/cpu/x86/vm/x86_64.ad
+ test/compiler/8011901/Test8011901.java


From roland.westrelin at oracle.com  Tue Apr 23 05:04:46 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 23 Apr 2013 14:04:46 +0200
Subject: RFR(XS): 8012292: optimized build with GCC broken
In-Reply-To: <8C39F4F8-BC46-4A0C-9166-337EC3372E8B@oracle.com>
References: <9A5E5A4F-F829-40C8-BF08-AFDC90C1E51C@oracle.com>
	<8C39F4F8-BC46-4A0C-9166-337EC3372E8B@oracle.com>
Message-ID: <275F46FC-B55B-43EA-AEDC-A3D9104EF9DF@oracle.com>

Thanks for the review.

Roland.

From roland.westrelin at oracle.com  Tue Apr 23 05:05:31 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 23 Apr 2013 14:05:31 +0200
Subject: RFR(XS): 8012292: optimized build with GCC broken
In-Reply-To: <516D7EC9.6090102@oracle.com>
References: <9A5E5A4F-F829-40C8-BF08-AFDC90C1E51C@oracle.com>
	<516D7EC9.6090102@oracle.com>
Message-ID: 

> 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 for the review.
Are you suggesting I do anything else as part of this change?

Roland.

From vladimir.kozlov at oracle.com  Tue Apr 23 07:58:31 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 23 Apr 2013 07:58:31 -0700
Subject: RFR(S): 8011771: runThese crashed with EAV
In-Reply-To: <9CCE54C2-8792-4D87-8784-7AB6BC33A244@oracle.com>
References: <9CCE54C2-8792-4D87-8784-7AB6BC33A244@oracle.com>
Message-ID: <5176A197.6010109@oracle.com>

Looks good. Could you fix spaces around '=' and '<' in for() statement?

Thanks,
Vladimir

On 4/23/13 12:24 AM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8011771/webrev.00/
>
> During in block motion, a step of array bound check elimination, the code doesn't always reset its data structures correctly when it moves from one array to another (it does when optimistic optimizations are on, not otherwise). As a result, some bound checks are incorrectly optimized out.
>
> Roland.
>

From vladimir.kozlov at oracle.com  Tue Apr 23 08:09:49 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 23 Apr 2013 08:09:49 -0700
Subject: RFR(XS): 8012292: optimized build with GCC broken
In-Reply-To: 
References: <9A5E5A4F-F829-40C8-BF08-AFDC90C1E51C@oracle.com>
	<516D7EC9.6090102@oracle.com>
	
Message-ID: <5176A43D.5020700@oracle.com>

On 4/23/13 5:05 AM, Roland Westrelin wrote:
>> 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 for the review.
> Are you suggesting I do anything else as part of this change?

Yes, please. At least on some platforms (Linux 64 ? and Win 64?). Look 
on east and hotspotwest queues result and see which finished build and 
testing first. And we just removed debug build - so it should not affect 
much JPRT job time.

thanks,
Vladimir

>
> Roland.
>

From roland.westrelin at oracle.com  Tue Apr 23 08:10:48 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 23 Apr 2013 17:10:48 +0200
Subject: RFR(S): 8011771: runThese crashed with EAV
In-Reply-To: <5176A197.6010109@oracle.com>
References: <9CCE54C2-8792-4D87-8784-7AB6BC33A244@oracle.com>
	<5176A197.6010109@oracle.com>
Message-ID: <342C971C-7E00-45DB-9A68-DBA65A033F7B@oracle.com>

> Looks good. Could you fix spaces around '=' and '<' in for() statement?

Thanks for the review, Vladimir. I'll fix the spaces.

Roland.

From dean.long at oracle.com  Tue Apr 23 10:31:20 2013
From: dean.long at oracle.com (Dean Long)
Date: Tue, 23 Apr 2013 10:31:20 -0700
Subject: RFR (M): 8003853: specify offset of IC load in java_to_interp stub
In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFB4FFC@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC0CFB4FFC@DEWDFEMB12A.global.corp.sap>
Message-ID: <5176C568.80007@oracle.com>

Looks good.

dl

On 4/23/2013 1:09 AM, Lindenmaier, Goetz wrote:
>
> Hi all,
>
> In the java_to_interp stub of CompiledStaticCalls one relocation is 
> used to find
>
> two code locations:
>
> -the beginning of the stub
>
> -the IC load instruction.
>
> On x86 and sparc, the IC load instruction is the first instruction of 
> the stub,
>
> thus both locations have the same address.
>
> On PPC, the IC load instruction is not the first instruction in the 
> stub, thus
>
> we must add an offset to the relocation to access it.
>
> As the manipulation of  CompiledStaticCalls is in shared code, we 
> would have
>
> to introduce platform dependencies there.
>
> This change moves the platform dependent code from CompiledStaticCall
>
> to a new file compiledIC_.cpp.  It also moves the code issuing the
>
> stub from the ad file to this new file into the class CompiledStaticCall.
>
> This removes redundancies between x86_64.ad and x86_32.ad.  Also,
>
> 'extern' declarations in compile.cpp can be replaced by properly typed
>
> Calls to methods in CompiledStaticCall.
>
> Dean Long ran this change through JPRT with status OK (thanks!).
>
> Please review and push this change.
>
> http://cr.openjdk.java.net/~goetz/webrevs/8003853-3/ 
> 
>
> Best regards,
>
>   Goetz Lindenmaier
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130423/5e9df42f/attachment.html 

From john.cuthbertson at oracle.com  Tue Apr 23 10:31:49 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 23 Apr 2013 10:31:49 -0700
Subject: RFR (S): 8012715: G1: Fix bug in graphKit.cpp accessing
	PtrQueue::_index
In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165668F433AD@DEWDFEMB13A.global.corp.sap>
References: <7C9B87B351A4BA4AA9EC95BB4181165668F433AD@DEWDFEMB13A.global.corp.sap>
Message-ID: <5176C585.8020805@oracle.com>

Hi Martin,

Overall the changes look good to me. I kind of agree with Christian 
though and I don't like the addition of T_X as an alias for a BasicType. 
I would prefer something like:

   __ if_then(marking, BoolTest::ne, zero); {
     BasicType index_bt = TypeX_X->basic_type();
     assert(sizeof(size_t) == type2aelembytes(index_bt), "Loading G1 
PtrQueue::_index with wrong size.");
     Node* index   = __ load(__ ctrl(), index_adr, TypeX_X, index_bt, 
Compile::AliasIdxRaw);

i.e. using the basic_type() routine in TypeLong or TypeInt.

Minor nit:
* Instead of __ ConX(0), can you define a zeroX and use that instead? 
That will make:

       // is the queue for this thread full?
       __ if_then(index, BoolTest::ne, zeroX, likely); {

look more consistent with:

   // if (!marking)
   __ if_then(marking, BoolTest::ne, zero); {

Thanks,

JohnC

On 4/19/2013 5:02 AM, Doerr, Martin wrote:
>
> Hi all,
>
> we found a bug in the G1 barriers generated by the C2 compiler.
>
> In graphKit INT operations were generated to access PtrQueue::_index which
>
> has type size_t. This is 64 bit on 64-bit machines. No problems occur on
>
> little endian machines as long as the index fits into 32 bit, but on
>
> big endian machines the upper part is read, which is zero. This leads
>
> to unnecessary branches to the slow path into the runtime.
>
> The fix introduces X operations where INT was used:
>
> http://cr.openjdk.java.net/~goetz/webrevs/g1-size_t_bug/ 
> 
>
> This also removes a cast node.
>
> We have also added a type T_X in globalDefinitions.hpp. Is there
>
> already a mechanism to express this?
>
> Please supply a bug id and review this change.
>
> Best regards,
>
> Martin
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130423/0ee7b4bf/attachment.html 

From christian.thalinger at oracle.com  Tue Apr 23 10:34:52 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 23 Apr 2013 10:34:52 -0700
Subject: RFR(S): 8011771: runThese crashed with EAV
In-Reply-To: <9CCE54C2-8792-4D87-8784-7AB6BC33A244@oracle.com>
References: <9CCE54C2-8792-4D87-8784-7AB6BC33A244@oracle.com>
Message-ID: <20036ADA-3C3E-4D2C-891D-176C7539CC9C@oracle.com>

Looks good.  -- Chris

On Apr 23, 2013, at 12:24 AM, Roland Westrelin  wrote:

> http://cr.openjdk.java.net/~roland/8011771/webrev.00/
> 
> During in block motion, a step of array bound check elimination, the code doesn't always reset its data structures correctly when it moves from one array to another (it does when optimistic optimizations are on, not otherwise). As a result, some bound checks are incorrectly optimized out.
> 
> Roland.


From christian.thalinger at oracle.com  Tue Apr 23 11:00:09 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 23 Apr 2013 11:00:09 -0700
Subject: RFR (M): 8003853: specify offset of IC load in java_to_interp stub
In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFB4FFC@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC0CFB4FFC@DEWDFEMB12A.global.corp.sap>
Message-ID: 

The change looks good.  I have some minor comments though:
src/share/vm/code/compiledIC.hpp:

+  static uint to_interp_stub_size();
+  static uint reloc_to_interp_stub();
+            stub_size  += CompiledStaticCall::to_interp_stub_size();
+            reloc_size += CompiledStaticCall::reloc_to_interp_stub();
stub_size and reloc_size are ints.  We should change the return type from uint to int.

src/cpu/x86/vm/compiledIC_x86.cpp:
 108 uint CompiledStaticCall::to_interp_stub_size() {
 109   return 10              // movl; jmp
 110          LP64_ONLY(+5);  // movq (1+1+8); jmp (1+4)
 111 }
In expectancy of future changes we should do:
 108 uint CompiledStaticCall::to_interp_stub_size() {
 109   return NOT_LP64(10)    // movl; jmp
 110          LP64_ONLY(15);  // movq (1+1+8); jmp (1+4)
 111 }
And one question unrelated to this change (because it was there before):

src/cpu/sparc/vm/compiledIC_sparc.cpp:
 126 // Relocation entries for call stub, compiled java to interpreter.
 127 uint CompiledStaticCall::reloc_to_interp_stub() {
 128   return 10;  // 4 in emit_java_to_interp + 1 in Java_Static_Call
 129 }
Why does it say 5 relocations but returns 10?

Did someone try a Zero build?

-- Chris

On Apr 23, 2013, at 1:09 AM, "Lindenmaier, Goetz"  wrote:

> Hi all,
>  
> In the java_to_interp stub of CompiledStaticCalls one relocation is used to find
> two code locations:
> -          the beginning of the stub
> -          the IC load instruction.
> On x86 and sparc, the IC load instruction is the first instruction of the stub,
> thus both locations have the same address.
> On PPC, the IC load instruction is not the first instruction in the stub, thus
> we must add an offset to the relocation to access it.
>  
> As the manipulation of  CompiledStaticCalls is in shared code, we would have
> to introduce platform dependencies there.
>  
> This change moves the platform dependent code from CompiledStaticCall
> to a new file compiledIC_.cpp.  It also moves the code issuing the
> stub from the ad file to this new file into the class CompiledStaticCall.
> This removes redundancies between x86_64.ad and x86_32.ad.  Also,
> ?extern? declarations in compile.cpp can be replaced by properly typed
> Calls to methods in CompiledStaticCall.
>  
> Dean Long ran this change through JPRT with status OK (thanks!).
>  
> Please review and push this change.
> http://cr.openjdk.java.net/~goetz/webrevs/8003853-3/
>  
> Best regards,
>   Goetz Lindenmaier

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

From roland.westrelin at oracle.com  Tue Apr 23 11:07:26 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 23 Apr 2013 20:07:26 +0200
Subject: RFR(S): 8011771: runThese crashed with EAV
In-Reply-To: <20036ADA-3C3E-4D2C-891D-176C7539CC9C@oracle.com>
References: <9CCE54C2-8792-4D87-8784-7AB6BC33A244@oracle.com>
	<20036ADA-3C3E-4D2C-891D-176C7539CC9C@oracle.com>
Message-ID: 

> Looks good.  -- Chris

Thanks for the review.

Roland.

From christian.thalinger at oracle.com  Tue Apr 23 12:06:29 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 23 Apr 2013 12:06:29 -0700
Subject: RFR (M): 8003853: specify offset of IC load in java_to_interp stub
In-Reply-To: 
References: <4295855A5C1DE049A61835A1887419CC0CFB4FFC@DEWDFEMB12A.global.corp.sap>
	
Message-ID: <50541FF8-BD83-4A06-A0D9-0E3C853ED224@oracle.com>


On Apr 23, 2013, at 11:00 AM, Christian Thalinger  wrote:

> The change looks good.  I have some minor comments though:
> src/share/vm/code/compiledIC.hpp:
> 
> +  static uint to_interp_stub_size();
> +  static uint reloc_to_interp_stub();
> +            stub_size  += CompiledStaticCall::to_interp_stub_size();
> +            reloc_size += CompiledStaticCall::reloc_to_interp_stub();
> stub_size and reloc_size are ints.  We should change the return type from uint to int.
> 
> src/cpu/x86/vm/compiledIC_x86.cpp:
>  108 uint CompiledStaticCall::to_interp_stub_size() {
>  109   return 10              // movl; jmp
>  110          LP64_ONLY(+5);  // movq (1+1+8); jmp (1+4)
>  111 }
> In expectancy of future changes we should do:
>  108 uint CompiledStaticCall::to_interp_stub_size() {
>  109   return NOT_LP64(10)    // movl; jmp
>  110          LP64_ONLY(15);  // movq (1+1+8); jmp (1+4)
>  111 }
> And one question unrelated to this change (because it was there before):
> 
> src/cpu/sparc/vm/compiledIC_sparc.cpp:
>  126 // Relocation entries for call stub, compiled java to interpreter.
>  127 uint CompiledStaticCall::reloc_to_interp_stub() {
>  128   return 10;  // 4 in emit_java_to_interp + 1 in Java_Static_Call
>  129 }
> Why does it say 5 relocations but returns 10?
> 
> Did someone try a Zero build?

Presumably not because Zero builds are broken right now.  I just filed:

8013067: Zero builds are broken after 8010862

-- Chris

> 
> -- Chris
> 
> On Apr 23, 2013, at 1:09 AM, "Lindenmaier, Goetz"  wrote:
> 
>> Hi all,
>>  
>> In the java_to_interp stub of CompiledStaticCalls one relocation is used to find
>> two code locations:
>> -          the beginning of the stub
>> -          the IC load instruction.
>> On x86 and sparc, the IC load instruction is the first instruction of the stub,
>> thus both locations have the same address.
>> On PPC, the IC load instruction is not the first instruction in the stub, thus
>> we must add an offset to the relocation to access it.
>>  
>> As the manipulation of  CompiledStaticCalls is in shared code, we would have
>> to introduce platform dependencies there.
>>  
>> This change moves the platform dependent code from CompiledStaticCall
>> to a new file compiledIC_.cpp.  It also moves the code issuing the
>> stub from the ad file to this new file into the class CompiledStaticCall.
>> This removes redundancies between x86_64.ad and x86_32.ad.  Also,
>> ?extern? declarations in compile.cpp can be replaced by properly typed
>> Calls to methods in CompiledStaticCall.
>>  
>> Dean Long ran this change through JPRT with status OK (thanks!).
>>  
>> Please review and push this change.
>> http://cr.openjdk.java.net/~goetz/webrevs/8003853-3/
>>  
>> Best regards,
>>   Goetz Lindenmaier
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130423/096678b7/attachment.html 

From dean.long at oracle.com  Tue Apr 23 13:39:10 2013
From: dean.long at oracle.com (Dean Long)
Date: Tue, 23 Apr 2013 13:39:10 -0700
Subject: RFR (M): 8003853: specify offset of IC load in java_to_interp stub
In-Reply-To: 
References: <4295855A5C1DE049A61835A1887419CC0CFB4FFC@DEWDFEMB12A.global.corp.sap>
	
Message-ID: <5176F16E.7030209@oracle.com>

On 4/23/2013 11:00 AM, Christian Thalinger wrote:
> The change looks good.  I have some minor comments though:
>
>
>     src/share/vm/code/compiledIC.hpp:
>
> +  static uint to_interp_stub_size();
> +  static uint reloc_to_interp_stub();
> +            stub_size  += CompiledStaticCall::to_interp_stub_size();
> +            reloc_size += CompiledStaticCall::reloc_to_interp_stub();
> stub_size and reloc_size are ints.  We should change the return type 
> from uint to int.
>
> src/cpu/x86/vm/compiledIC_x86.cpp:
>   108 uint CompiledStaticCall::to_interp_stub_size() {
>   109   return 10              // movl; jmp
>   110          LP64_ONLY(+5);  // movq (1+1+8); jmp (1+4)
>   111 }
> In expectancy of future changes we should do:
>   108 uint CompiledStaticCall::to_interp_stub_size() {
>   109   return NOT_LP64(10)    // movl; jmp
>   110          LP64_ONLY(15);  // movq (1+1+8); jmp (1+4)
>   111 }
> And one question unrelated to this change (because it was there before):
>
> src/cpu/sparc/vm/compiledIC_sparc.cpp:
>   126 // Relocation entries for call stub, compiled java to interpreter.
>   127 uint CompiledStaticCall::reloc_to_interp_stub() {
>   128   return 10;  // 4 in emit_java_to_interp + 1 in Java_Static_Call
>   129 }
> Why does it say 5 relocations but returns 10?
>
Archeology reveals that it has been like that since the initial 
implementation in 1998.  Apparently it's better to over-estimate rather 
than under-estimate this value.

dl

> Did someone try a Zero build?
>
> -- Chris
>
> On Apr 23, 2013, at 1:09 AM, "Lindenmaier, Goetz" 
> > wrote:
>
>> Hi all,
>> In the java_to_interp stub of CompiledStaticCalls one relocation is 
>> used to find
>> two code locations:
>> -the beginning of the stub
>> -the IC load instruction.
>> On x86 and sparc, the IC load instruction is the first instruction of 
>> the stub,
>> thus both locations have the same address.
>> On PPC, the IC load instruction is not the first instruction in the 
>> stub, thus
>> we must add an offset to the relocation to access it.
>> As the manipulation of  CompiledStaticCalls is in shared code, we 
>> would have
>> to introduce platform dependencies there.
>> This change moves the platform dependent code from CompiledStaticCall
>> to a new file compiledIC_.cpp.  It also moves the code issuing the
>> stub from the ad file to this new file into the class CompiledStaticCall.
>> This removes redundancies between x86_64.ad and x86_32.ad.  Also,
>> ?extern? declarations in compile.cpp can be replaced by properly typed
>> Calls to methods in CompiledStaticCall.
>> Dean Long ran this change through JPRT with status OK (thanks!).
>> Please review and push this change.
>> http://cr.openjdk.java.net/~goetz/webrevs/8003853-3/ 
>> 
>> Best regards,
>>   Goetz Lindenmaier
>

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

From christian.thalinger at oracle.com  Tue Apr 23 14:12:04 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 23 Apr 2013 14:12:04 -0700
Subject: RFR (XS): 8010460: Interpreter on some platforms loads
	ConstMethod::_max_stack and misses extra stack slots for JSR 292
In-Reply-To: <5463992A-B3A0-4647-9176-90704DBE6262@oracle.com>
References: <6B922316-9630-4955-9A42-8FA52D5571F6@oracle.com>
	
	<4CA94106-1D2A-4DF2-814E-DF2F7A190B60@oracle.com>
	<8A8F768B-D0E2-46C1-AEC2-ED2FAA88EA09@oracle.com>
	
	
	
	
	<5463992A-B3A0-4647-9176-90704DBE6262@oracle.com>
Message-ID: 


On Apr 9, 2013, at 7:50 AM, Roland Westrelin  wrote:

> Here is a new webrev:
> 
> http://cr.openjdk.java.net/~roland/8010460/webrev.02/

src/share/vm/oops/method.hpp:

+  // How many extra stack entries for invokedynamic when it's enabled
+  static const extra_stack_entries_for_indy = 1;

Can we move this up to be next to:

+  static int extra_stack_entries() { return EnableInvokeDynamic ? extra_stack_entries_for_indy : 0; }

Perhaps we should call it extra_stack_entries_for_jsr292 since it's not only invokedynamic.

Otherwise this looks good.

-- Chris

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


From john.cuthbertson at oracle.com  Tue Apr 23 16:02:09 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Tue, 23 Apr 2013 16:02:09 -0700
Subject: RFR (S): 8012715: G1: Fix bug in graphKit.cpp accessing
	PtrQueue::_index
In-Reply-To: <5176C585.8020805@oracle.com>
References: <7C9B87B351A4BA4AA9EC95BB4181165668F433AD@DEWDFEMB13A.global.corp.sap>
	<5176C585.8020805@oracle.com>
Message-ID: <517712F1.3010101@oracle.com>

Hi Martin,

One more thing - do you guys test with C1/Tiered at all?

I decided to check the C1 barriers and it looks like there's an issue 
there as well.

On Sparc we're doing the right thing. On x86 (in the G1 post barrier), I 
see:

>         // storing region crossing non-NULL, card is clean.
>         // dirty card and log.
>
>         __ movb(Address(card_addr, 0), 0);
>
>         __ cmpl(queue_index, 0);
>         __ jcc(Assembler::equal, runtime);
>         __ subl(queue_index, wordSize);

And if we compare the same check for the pre-barrier:

>         // Can we store original value in the thread's buffer?
>
> #ifdef _LP64
>         __ movslq(tmp, queue_index);
>         __ cmpq(tmp, 0);
> #else
>         __ cmpl(queue_index, 0);
> #endif
>         __ jcc(Assembler::equal, runtime);
> #ifdef _LP64
>         __ subq(tmp, wordSize);
>         __ movl(queue_index, tmp);
>         __ addq(tmp, buffer);
> #else
>         __ subl(queue_index, wordSize);
>         __ movl(tmp, buffer);
>         __ addl(tmp, queue_index);
> #endif

I think both are wrong. In the pre-barrier we do a 32 bit move of the 
new index into the queue_index address. In the post barrier we use only 
32 bit arithmetic. As you said they're benign as long as the values fit 
in 32 bits but they should probably be fixed.

Do you want to fix the C1 barrier as part of your webrev or have me fix 
it in a separate CR?

Thanks,

JohnC

On 4/23/2013 10:31 AM, John Cuthbertson wrote:
> Hi Martin,
>
> Overall the changes look good to me. I kind of agree with Christian 
> though and I don't like the addition of T_X as an alias for a 
> BasicType. I would prefer something like:
>
>   __ if_then(marking, BoolTest::ne, zero); {
>     BasicType index_bt = TypeX_X->basic_type();
>     assert(sizeof(size_t) == type2aelembytes(index_bt), "Loading G1 
> PtrQueue::_index with wrong size.");
>     Node* index   = __ load(__ ctrl(), index_adr, TypeX_X, index_bt, 
> Compile::AliasIdxRaw);
>
> i.e. using the basic_type() routine in TypeLong or TypeInt.
>
> Minor nit:
> * Instead of __ ConX(0), can you define a zeroX and use that instead? 
> That will make:
>
>       // is the queue for this thread full?
>       __ if_then(index, BoolTest::ne, zeroX, likely); {
>
> look more consistent with:
>
>   // if (!marking)
>   __ if_then(marking, BoolTest::ne, zero); {
>
> Thanks,
>
> JohnC
>
> On 4/19/2013 5:02 AM, Doerr, Martin wrote:
>>
>> Hi all,
>>
>> we found a bug in the G1 barriers generated by the C2 compiler.
>>
>> In graphKit INT operations were generated to access PtrQueue::_index 
>> which
>>
>> has type size_t. This is 64 bit on 64-bit machines. No problems occur on
>>
>> little endian machines as long as the index fits into 32 bit, but on
>>
>> big endian machines the upper part is read, which is zero. This leads
>>
>> to unnecessary branches to the slow path into the runtime.
>>
>> The fix introduces X operations where INT was used:
>>
>> http://cr.openjdk.java.net/~goetz/webrevs/g1-size_t_bug/ 
>> 
>>
>> This also removes a cast node.
>>
>> We have also added a type T_X in globalDefinitions.hpp. Is there
>>
>> already a mechanism to express this?
>>
>> Please supply a bug id and review this change.
>>
>> Best regards,
>>
>> Martin
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130423/059b4eac/attachment.html 

From goetz.lindenmaier at sap.com  Wed Apr 24 01:47:14 2013
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 24 Apr 2013 08:47:14 +0000
Subject: RFR (M): 8003853: specify offset of IC load in java_to_interp stub
In-Reply-To: <50541FF8-BD83-4A06-A0D9-0E3C853ED224@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC0CFB4FFC@DEWDFEMB12A.global.corp.sap>
	
	<50541FF8-BD83-4A06-A0D9-0E3C853ED224@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC0CFB59E6@DEWDFEMB12A.global.corp.sap>

Hi,

Yes, your comments make the code look better.
I made a new webrev:
http://cr.openjdk.java.net/~goetz/webrevs/8003853-4/

I did not do a zero build.

Best regards,
  Goetz.


From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
Sent: Dienstag, 23. April 2013 21:06
To: Lindenmaier, Goetz
Cc: hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR (M): 8003853: specify offset of IC load in java_to_interp stub


On Apr 23, 2013, at 11:00 AM, Christian Thalinger > wrote:


The change looks good.  I have some minor comments though:
src/share/vm/code/compiledIC.hpp:

+  static uint to_interp_stub_size();

+  static uint reloc_to_interp_stub();

+            stub_size  += CompiledStaticCall::to_interp_stub_size();

+            reloc_size += CompiledStaticCall::reloc_to_interp_stub();
stub_size and reloc_size are ints.  We should change the return type from uint to int.

src/cpu/x86/vm/compiledIC_x86.cpp:

 108 uint CompiledStaticCall::to_interp_stub_size() {

 109   return 10              // movl; jmp

 110          LP64_ONLY(+5);  // movq (1+1+8); jmp (1+4)

 111 }
In expectancy of future changes we should do:

 108 uint CompiledStaticCall::to_interp_stub_size() {

 109   return NOT_LP64(10)    // movl; jmp

 110          LP64_ONLY(15);  // movq (1+1+8); jmp (1+4)

 111 }
And one question unrelated to this change (because it was there before):

src/cpu/sparc/vm/compiledIC_sparc.cpp:

 126 // Relocation entries for call stub, compiled java to interpreter.

 127 uint CompiledStaticCall::reloc_to_interp_stub() {

 128   return 10;  // 4 in emit_java_to_interp + 1 in Java_Static_Call

 129 }
Why does it say 5 relocations but returns 10?

Did someone try a Zero build?

Presumably not because Zero builds are broken right now.  I just filed:

8013067: Zero builds are broken after 8010862

-- Chris


-- Chris

On Apr 23, 2013, at 1:09 AM, "Lindenmaier, Goetz" > wrote:


Hi all,

In the java_to_interp stub of CompiledStaticCalls one relocation is used to find
two code locations:
-          the beginning of the stub
-          the IC load instruction.
On x86 and sparc, the IC load instruction is the first instruction of the stub,
thus both locations have the same address.
On PPC, the IC load instruction is not the first instruction in the stub, thus
we must add an offset to the relocation to access it.

As the manipulation of  CompiledStaticCalls is in shared code, we would have
to introduce platform dependencies there.

This change moves the platform dependent code from CompiledStaticCall
to a new file compiledIC_.cpp.  It also moves the code issuing the
stub from the ad file to this new file into the class CompiledStaticCall.
This removes redundancies between x86_64.ad and x86_32.ad.  Also,
'extern' declarations in compile.cpp can be replaced by properly typed
Calls to methods in CompiledStaticCall.

Dean Long ran this change through JPRT with status OK (thanks!).

Please review and push this change.
http://cr.openjdk.java.net/~goetz/webrevs/8003853-3/

Best regards,
  Goetz Lindenmaier


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

From martin.doerr at sap.com  Wed Apr 24 01:50:39 2013
From: martin.doerr at sap.com (Doerr, Martin)
Date: Wed, 24 Apr 2013 08:50:39 +0000
Subject: RFR (S): 8012715: G1: Fix bug in graphKit.cpp accessing
	PtrQueue::_index
In-Reply-To: <5176C585.8020805@oracle.com>
References: <7C9B87B351A4BA4AA9EC95BB4181165668F433AD@DEWDFEMB13A.global.corp.sap>
	<5176C585.8020805@oracle.com>
Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165668F4394E@DEWDFEMB13A.global.corp.sap>

Hi John,

thanks for your input. Here's the new webrev:
http://cr.openjdk.java.net/~goetz/webrevs/8012715/

"zero" and "zeroX" are only used once. Would it be better to remove these local variables and put "ConI" and "ConX" to where they are used?

You have also asked about C1. I had also checked SPARC which looks ok.  I agree with that it would be better to also fix C1 on x64_64.
However, we are not using C1, so I'd prefer if you could handle it in a separate CR.

Kind regards,
Martin


From: John Cuthbertson [mailto:john.cuthbertson at oracle.com]
Sent: Dienstag, 23. April 2013 19:32
To: Doerr, Martin
Cc: hotspot-compiler-dev at openjdk.java.net; Mikael Gerdin; Lindenmaier, Goetz
Subject: Re: RFR (S): 8012715: G1: Fix bug in graphKit.cpp accessing PtrQueue::_index

Hi Martin,

Overall the changes look good to me. I kind of agree with Christian though and I don't like the addition of T_X as an alias for a BasicType. I would prefer something like:

  __ if_then(marking, BoolTest::ne, zero); {
    BasicType index_bt = TypeX_X->basic_type();
    assert(sizeof(size_t) == type2aelembytes(index_bt), "Loading G1 PtrQueue::_index with wrong size.");
    Node* index   = __ load(__ ctrl(), index_adr, TypeX_X, index_bt, Compile::AliasIdxRaw);

i.e. using the basic_type() routine in TypeLong or TypeInt.

Minor nit:
* Instead of __ ConX(0), can you define a zeroX and use that instead? That will make:

      // is the queue for this thread full?
      __ if_then(index, BoolTest::ne, zeroX, likely); {

look more consistent with:

  // if (!marking)
  __ if_then(marking, BoolTest::ne, zero); {

Thanks,

JohnC
On 4/19/2013 5:02 AM, Doerr, Martin wrote:
Hi all,

we found a bug in the G1 barriers generated by the C2 compiler.

In graphKit INT operations were generated to access PtrQueue::_index which
has type size_t. This is 64 bit on 64-bit machines. No problems occur on
little endian machines as long as the index fits into 32 bit, but on
big endian machines the upper part is read, which is zero. This leads
to unnecessary branches to the slow path into the runtime.

The fix introduces X operations where INT was used:
http://cr.openjdk.java.net/~goetz/webrevs/g1-size_t_bug/

This also removes a cast node.

We have also added a type T_X in globalDefinitions.hpp. Is there
already a mechanism to express this?

Please supply a bug id and review this change.

Best regards,
Martin


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

From roland.westrelin at oracle.com  Wed Apr 24 01:55:38 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Wed, 24 Apr 2013 10:55: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>
	
	
	
	
	<5463992A-B3A0-4647-9176-90704DBE6262@oracle.com>
	
Message-ID: <87ehe0e29h.fsf@oracle.com>


> Can we move this up to be next to:
>
> +  static int extra_stack_entries() { return EnableInvokeDynamic ? extra_stack_entries_for_indy : 0; }
>
> Perhaps we should call it extra_stack_entries_for_jsr292 since it's not only invokedynamic.
>
> Otherwise this looks good.

Thanks for re-reviewing this. I'll do the change you suggest.

Roland.

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

Hi,

I'm not a reviewer, but the cpp interpreter stuff looks fine for me.

You should be able to build the cpp interpreter by doing a Zero build
as described here:

http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2013-April/010314.html
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2013-April/010315.html

Regards,
Volker


On Tue, Apr 9, 2013 at 4:50 PM, Roland Westrelin
 wrote:
> 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 albert.noll at oracle.com  Wed Apr 24 02:18:56 2013
From: albert.noll at oracle.com (Albert Noll)
Date: Wed, 24 Apr 2013 11:18:56 +0200
Subject: hg: hsx/hotspot-comp/hotspot: 8010332: remove unused method
	ciMethod::uses_monitors
Message-ID: <5177A380.6070002@oracle.com>

Hi all,

please review the patch:


Problem:
unused method with misleading name

Fix:
removed unused method

Testing:
JPRT 'compiler'

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

jbs: https://jbs.oracle.com/bugs/browse/JDK-8010332 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130424/432e4ef5/attachment.html 

From roland.westrelin at oracle.com  Wed Apr 24 02:35:14 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Wed, 24 Apr 2013 11:35:14 +0200
Subject: hg: hsx/hotspot-comp/hotspot: 8010332: remove unused method
	ciMethod::uses_monitors
In-Reply-To: <5177A380.6070002@oracle.com>
References: <5177A380.6070002@oracle.com>
Message-ID: <87bo94e0fh.fsf@oracle.com>


It looks good.

Roland.

From roland.westrelin at oracle.com  Wed Apr 24 03:24:09 2013
From: roland.westrelin at oracle.com (roland.westrelin at oracle.com)
Date: Wed, 24 Apr 2013 10:24:09 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 8011771: runThese crashed with EAV
Message-ID: <20130424102417.9409E4856D@hg.openjdk.java.net>

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

8011771: runThese crashed with EAV
Summary: Array bound check elimination's in block motion doesn't always reset its data structures from one step to the other.
Reviewed-by: kvn, twisti

! src/share/vm/c1/c1_RangeCheckElimination.cpp


From albert.noll at oracle.com  Wed Apr 24 03:57:59 2013
From: albert.noll at oracle.com (Albert Noll)
Date: Wed, 24 Apr 2013 12:57:59 +0200
Subject: RFR (S): 8012157: removed unused code in
	SharedRuntime::handle_wrong_method
Message-ID: <5177BAB7.70905@oracle.com>

Hi all,

please review the patch:


Problem:
unused code in SharedRuntime::handle_wrong_method

Fix:
removed unused code

Testing:
JPRT 'compiler'

webrev:  https://jbs.oracle.com/bugs/browse/JDK-8012157
jbs: http://cr.openjdk.java.net/~roland/8012157/webrev.00/

Thanks,
Albert

From albert.noll at oracle.com  Wed Apr 24 04:21:27 2013
From: albert.noll at oracle.com (Albert Noll)
Date: Wed, 24 Apr 2013 13:21:27 +0200
Subject: RFR (S): 8012157: removed unused code in
	SharedRuntime::handle_wrong_method
In-Reply-To: <5177BAB7.70905@oracle.com>
References: <5177BAB7.70905@oracle.com>
Message-ID: <5177C037.9030805@oracle.com>

Hi,

I just realized that webrev and jbs are mixed up
Here is the webrev: http://cr.openjdk.java.net/~roland/8012157/webrev.00/

Best,
Albert

On 04/24/2013 12:57 PM, Albert Noll wrote:
> Hi all,
>
> please review the patch:
>
>
> Problem:
> unused code in SharedRuntime::handle_wrong_method
>
> Fix:
> removed unused code
>
> Testing:
> JPRT 'compiler'
>
> webrev:  https://jbs.oracle.com/bugs/browse/JDK-8012157
> jbs: http://cr.openjdk.java.net/~roland/8012157/webrev.00/
>
> Thanks,
> Albert


From roland.westrelin at oracle.com  Wed Apr 24 04:40:26 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Wed, 24 Apr 2013 13:40:26 +0200
Subject: RFR (S): 8012157: removed unused code in
	SharedRuntime::handle_wrong_method
In-Reply-To: <5177C037.9030805@oracle.com>
References: <5177BAB7.70905@oracle.com> <5177C037.9030805@oracle.com>
Message-ID: <251EE1F7-2FA5-4157-A509-86CB6AA6C3D5@oracle.com>

It looks good.

Roland.

From rickard.backman at oracle.com  Wed Apr 24 04:42:39 2013
From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=)
Date: Wed, 24 Apr 2013 13:42:39 +0200
Subject: RFR (S): 8012157: removed unused code in
	SharedRuntime::handle_wrong_method
In-Reply-To: <5177C037.9030805@oracle.com>
References: <5177BAB7.70905@oracle.com> <5177C037.9030805@oracle.com>
Message-ID: <0D43E2D7-B1C7-4865-AD07-EF7D28C8DDA7@oracle.com>

Albert,

the change looks good.

/R

On Apr 24, 2013, at 1:21 PM, Albert Noll wrote:

> Hi,
> 
> I just realized that webrev and jbs are mixed up
> Here is the webrev: http://cr.openjdk.java.net/~roland/8012157/webrev.00/
> 
> Best,
> Albert
> 
> On 04/24/2013 12:57 PM, Albert Noll wrote:
>> Hi all,
>> 
>> please review the patch:
>> 
>> 
>> Problem:
>> unused code in SharedRuntime::handle_wrong_method
>> 
>> Fix:
>> removed unused code
>> 
>> Testing:
>> JPRT 'compiler'
>> 
>> webrev:  https://jbs.oracle.com/bugs/browse/JDK-8012157
>> jbs: http://cr.openjdk.java.net/~roland/8012157/webrev.00/
>> 
>> Thanks,
>> Albert
> 


From roland.westrelin at oracle.com  Wed Apr 24 04:47:03 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Wed, 24 Apr 2013 13:47:03 +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>
	
	
	
	
	<5463992A-B3A0-4647-9176-90704DBE6262@oracle.com>
	
Message-ID: <8E7A2BAD-1584-4916-990F-EF933CAB664B@oracle.com>

> You should be able to build the cpp interpreter by doing a Zero build
> as described here:
> 
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2013-April/010314.html
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2013-April/010315.html

It doesn't build anymore following 8010862. Anyway, with simple changes I was able to build it (but it wouldn't run). Thanks.

Roland.

From nils.eliasson at oracle.com  Wed Apr 24 07:06:54 2013
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Wed, 24 Apr 2013 16:06:54 +0200
Subject: RFR (S/M): 8012547: Reclamation of flushed methods can be slow
In-Reply-To: <516FF08A.2080808@oracle.com>
References: <516FF08A.2080808@oracle.com>
Message-ID: <5177E6FE.5010503@oracle.com>

Hi again,

Further testing revealed that not all issues was fully identified. 
Flushing could still cause compiles to halt even though compilations was 
on, and turning off compilations when the code cache was really full 
made the sweeper run much less often, prolonging the problem.

Change log:
* Fix the comment Christian mentioned, and some other comments too.
* find_and_remove_saved_code renamed to reanimate_saved_code to 
distinguish it from remove_saved_code that actually removes it.
* dont bail out on need_flushing() in compile_method - that causes us to 
stop compiling as soon as we hit CodeCacheFlushingMinimumFreeSpace - and 
that wasn't the idea.
* New product flag CodeCacheFlushingFraction (defaults to 2)
* _was_full removed. Was a redundant way to say that we stopped 
compilations.
* _last_was_full renamed to _last_full_flush_time, to emphasize that it 
is the time when we hit the hard limit CodeCacheMinimumSpace and 
compilations are stopped
* _was_full_traversal renamed to _last_flush_traversal_id. 'full' means 
the hard CodeCacheMinimumFreeSpace limit in all other variable names. 
* introduced _dead_compile_ids that hold a count for the number of 
compile ID that have been reclaimed. Gives a more accurate way to flush 
the cache.
* Simplified scan_stacks
   - restore flush token when min interval has passed
   - start compilations again if flushing is no longer needed
* Speed up sweeper when compilations is turned off. Sweeping is slowed 
down when compiler threads are sleeping on the CodeCache lock, and we 
want to speed up the reclaim process so that we can turn on compiler again.
* Let sweeper make disconnected methods non_entrant even if we don't 
need flushing any more. Makes us less likely to hit a new flush.
* Refactored NMethodSweeper::handle_full_code_cache
   - flushed and full flushes now uses the same token to synchronize - 
otherwise we might get two back-to-back flushes. And that doesn't help 
anyone.
   - remove time check - flush_token is restored in scan_stacks where 
the time is already checked.
* set _resweep flag when flushing.

The code is much easier to read now and the behavior should be less 
surprising.

http://cr.openjdk.java.net/~neliasso/8012547/webrev.03/ 


Thanks,
Nils Eliasson


On 2013-04-18 15:09, Nils Eliasson wrote:
> 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 unnecessary long time 
> sometimes causing unnecessary new flushes.
>
> Also some refactoring
> - remove state variable _do_sweep that was unnecessary. It marked if a 
> sweep was active or not, but just a duplicate way of checking if any 
> methods are being sweept (nmethodsweeper::current != NULL).
> - rename _rescan to _resweep. When _resweep is set there will be 
> another sweep started when the current ends. That sweep will start 
> with a scan, but it is not only a scan.
> - rename _advise_to_sweep to _flush_token. Is CASed by the first 
> thread that wants to flush and reset by scan_stacks when the flush is 
> finished and a proper time has passed.
>
> http://cr.openjdk.java.net/~neliasso/8012547/ 
> 
> https://jbs.oracle.com/bugs/browse/JDK-8012547
>
> Thanks,
> Nils E.


From nils.eliasson at oracle.com  Wed Apr 24 07:16:25 2013
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Wed, 24 Apr 2013 16:16:25 +0200
Subject: RFR (S/M): 8012547: Reclamation of flushed methods can be slow
In-Reply-To: <516FF08A.2080808@oracle.com>
References: <516FF08A.2080808@oracle.com>
Message-ID: <5177E939.1050706@oracle.com>

This is the correct webrev for the RFR I sent a moment ago:

http://cr.openjdk.java.net/~neliasso/8012547/webrev.04/ 


//Nils

On 2013-04-18 15:09, Nils Eliasson wrote:
> 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 unnecessary long time 
> sometimes causing unnecessary new flushes.
>
> Also some refactoring
> - remove state variable _do_sweep that was unnecessary. It marked if a 
> sweep was active or not, but just a duplicate way of checking if any 
> methods are being sweept (nmethodsweeper::current != NULL).
> - rename _rescan to _resweep. When _resweep is set there will be 
> another sweep started when the current ends. That sweep will start 
> with a scan, but it is not only a scan.
> - rename _advise_to_sweep to _flush_token. Is CASed by the first 
> thread that wants to flush and reset by scan_stacks when the flush is 
> finished and a proper time has passed.
>
> http://cr.openjdk.java.net/~neliasso/8012547/ 
> 
> https://jbs.oracle.com/bugs/browse/JDK-8012547
>
> Thanks,
> Nils E.


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

The fix is actually not correct. I had a test failure in jprt because max_stack can be 0xffff and adding the extra entry overflows the _max_stack short in ConstMethod. Keeping the change as it is would require making _max_stack a int which would add 4 bytes to every ConstMethod (going from 8 x u2 fields to 7 x u2 fields + a int field).

Roland.

From volker.simonis at gmail.com  Wed Apr 24 08:39:52 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 24 Apr 2013 17:39:52 +0200
Subject: RFR (XS): 8010460: Interpreter on some platforms loads
	ConstMethod::_max_stack and misses extra stack slots for JSR 292
In-Reply-To: <14BCC090-670B-47C1-BA7B-073529B66649@oracle.com>
References: <6B922316-9630-4955-9A42-8FA52D5571F6@oracle.com>
	
	<4CA94106-1D2A-4DF2-814E-DF2F7A190B60@oracle.com>
	<8A8F768B-D0E2-46C1-AEC2-ED2FAA88EA09@oracle.com>
	
	
	
	
	<5463992A-B3A0-4647-9176-90704DBE6262@oracle.com>
	
	<8E7A2BAD-1584-4916-990F-EF933CAB664B@oracle.com>
	<14BCC090-670B-47C1-BA7B-073529B66649@oracle.com>
Message-ID: 

What a pity :(

I havn't thoroughly reviewd this, but maybe you could make ConstMethod
'extra_stack_entries_for_indy' aware as well, to avoid the extra
bytes?

On Wed, Apr 24, 2013 at 4:44 PM, Roland Westrelin
 wrote:
> The fix is actually not correct. I had a test failure in jprt because max_stack can be 0xffff and adding the extra entry overflows the _max_stack short in ConstMethod. Keeping the change as it is would require making _max_stack a int which would add 4 bytes to every ConstMethod (going from 8 x u2 fields to 7 x u2 fields + a int field).
>
> Roland.

From vladimir.kozlov at oracle.com  Wed Apr 24 08:45:04 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 24 Apr 2013 08:45:04 -0700
Subject: RFR (S): 8012157: removed unused code in
	SharedRuntime::handle_wrong_method
In-Reply-To: <5177C037.9030805@oracle.com>
References: <5177BAB7.70905@oracle.com> <5177C037.9030805@oracle.com>
Message-ID: <5177FE00.60600@oracle.com>

Good.

Vladimir

On 4/24/13 4:21 AM, Albert Noll wrote:
> Hi,
>
> I just realized that webrev and jbs are mixed up
> Here is the webrev: http://cr.openjdk.java.net/~roland/8012157/webrev.00/
>
> Best,
> Albert
>
> On 04/24/2013 12:57 PM, Albert Noll wrote:
>> Hi all,
>>
>> please review the patch:
>>
>>
>> Problem:
>> unused code in SharedRuntime::handle_wrong_method
>>
>> Fix:
>> removed unused code
>>
>> Testing:
>> JPRT 'compiler'
>>
>> webrev:  https://jbs.oracle.com/bugs/browse/JDK-8012157
>> jbs: http://cr.openjdk.java.net/~roland/8012157/webrev.00/
>>
>> Thanks,
>> Albert
>

From roland.westrelin at oracle.com  Wed Apr 24 08:46:39 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Wed, 24 Apr 2013 17:46:39 +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>
	
	
	
	
	<5463992A-B3A0-4647-9176-90704DBE6262@oracle.com>
	
	<8E7A2BAD-1584-4916-990F-EF933CAB664B@oracle.com>
	<14BCC090-670B-47C1-BA7B-073529B66649@oracle.com>
	
Message-ID: <4416924D-4DC7-42F1-ADF9-ABD7F31CB6A9@oracle.com>

> I havn't thoroughly reviewd this, but maybe you could make ConstMethod
> 'extra_stack_entries_for_indy' aware as well, to avoid the extra
> bytes?


Thanks for the suggestion but I don't see how to make it work.
The _max_stack constant is directly loaded from the interpreter on some platforms. With the previous code, every places where _max_stack is loaded in the interpreter require some assembly code to add the extra stack slot (painful and error prone). With this change, the load of _max_stack would be sufficient because it includes the extra slot except for the corner case I mention.

Roland.

From christian.thalinger at oracle.com  Wed Apr 24 12:16:31 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 24 Apr 2013 12:16:31 -0700
Subject: RFR (M): 8003853: specify offset of IC load in java_to_interp stub
In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFB59E6@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC0CFB4FFC@DEWDFEMB12A.global.corp.sap>
	
	<50541FF8-BD83-4A06-A0D9-0E3C853ED224@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB59E6@DEWDFEMB12A.global.corp.sap>
Message-ID: 

Looks good.  Dean, can you push the change?

-- Chris

On Apr 24, 2013, at 1:47 AM, "Lindenmaier, Goetz"  wrote:

> Hi,
>  
> Yes, your comments make the code look better.
> I made a new webrev:
> http://cr.openjdk.java.net/~goetz/webrevs/8003853-4/
>  
> I did not do a zero build.
>  
> Best regards,
>   Goetz.
>  
>  
> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
> Sent: Dienstag, 23. April 2013 21:06
> To: Lindenmaier, Goetz
> Cc: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR (M): 8003853: specify offset of IC load in java_to_interp stub
>  
>  
> On Apr 23, 2013, at 11:00 AM, Christian Thalinger  wrote:
> 
> 
> The change looks good.  I have some minor comments though:
> src/share/vm/code/compiledIC.hpp:
> 
> +  static uint to_interp_stub_size();
> +  static uint reloc_to_interp_stub();
> +            stub_size  += CompiledStaticCall::to_interp_stub_size();
> +            reloc_size += CompiledStaticCall::reloc_to_interp_stub();
> stub_size and reloc_size are ints.  We should change the return type from uint to int.
>  
> src/cpu/x86/vm/compiledIC_x86.cpp:
>  108 uint CompiledStaticCall::to_interp_stub_size() {
>  109   return 10              // movl; jmp
>  110          LP64_ONLY(+5);  // movq (1+1+8); jmp (1+4)
>  111 }
> In expectancy of future changes we should do:
>  108 uint CompiledStaticCall::to_interp_stub_size() {
>  109   return NOT_LP64(10)    // movl; jmp
>  110          LP64_ONLY(15);  // movq (1+1+8); jmp (1+4)
>  111 }
> And one question unrelated to this change (because it was there before):
>  
> src/cpu/sparc/vm/compiledIC_sparc.cpp:
>  126 // Relocation entries for call stub, compiled java to interpreter.
>  127 uint CompiledStaticCall::reloc_to_interp_stub() {
>  128   return 10;  // 4 in emit_java_to_interp + 1 in Java_Static_Call
>  129 }
> Why does it say 5 relocations but returns 10?
>  
> Did someone try a Zero build?
>  
> Presumably not because Zero builds are broken right now.  I just filed:
>  
> 8013067: Zero builds are broken after 8010862
>  
> -- Chris
>  
>  
> -- Chris
>  
> On Apr 23, 2013, at 1:09 AM, "Lindenmaier, Goetz"  wrote:
> 
> 
> Hi all,
>  
> In the java_to_interp stub of CompiledStaticCalls one relocation is used to find
> two code locations:
> -          the beginning of the stub
> -          the IC load instruction.
> On x86 and sparc, the IC load instruction is the first instruction of the stub,
> thus both locations have the same address.
> On PPC, the IC load instruction is not the first instruction in the stub, thus
> we must add an offset to the relocation to access it.
>  
> As the manipulation of  CompiledStaticCalls is in shared code, we would have
> to introduce platform dependencies there.
>  
> This change moves the platform dependent code from CompiledStaticCall
> to a new file compiledIC_.cpp.  It also moves the code issuing the
> stub from the ad file to this new file into the class CompiledStaticCall.
> This removes redundancies between x86_64.ad and x86_32.ad.  Also,
> ?extern? declarations in compile.cpp can be replaced by properly typed
> Calls to methods in CompiledStaticCall.
>  
> Dean Long ran this change through JPRT with status OK (thanks!).
>  
> Please review and push this change.
> http://cr.openjdk.java.net/~goetz/webrevs/8003853-3/
>  
> Best regards,
>   Goetz Lindenmaier
>  

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

From christian.thalinger at oracle.com  Wed Apr 24 12:21:52 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 24 Apr 2013 12:21:52 -0700
Subject: hg: hsx/hotspot-comp/hotspot: 8010332: remove unused method
	ciMethod::uses_monitors
In-Reply-To: <5177A380.6070002@oracle.com>
References: <5177A380.6070002@oracle.com>
Message-ID: <8A84EA7E-4C35-493F-B0B9-C657A188AAC5@oracle.com>

On Apr 24, 2013, at 2:18 AM, Albert Noll  wrote:

> Hi all,
> 
> please review the patch:
> 
> 
> Problem:
> unused method with misleading name
> 
> Fix:
> removed unused method

The change looks good but are you sure you're not mixing up bugs?

-- Chris

> 
> Testing:
> JPRT 'compiler'
> 
> webrev:  http://cr.openjdk.java.net/~roland/8010332/webrev.00/
> jbs: https://jbs.oracle.com/bugs/browse/JDK-8010332

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

From vladimir.kozlov at oracle.com  Wed Apr 24 13:33:30 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 24 Apr 2013 13:33:30 -0700
Subject: RFR (S/M): 8012547: Reclamation of flushed methods can be slow
In-Reply-To: <5177E6FE.5010503@oracle.com>
References: <516FF08A.2080808@oracle.com> <5177E6FE.5010503@oracle.com>
Message-ID: <5178419A.7080209@oracle.com>

Nils,

Yes, in general it is better.

http://cr.openjdk.java.net/~neliasso/8012547/webrev.04/

On 4/24/13 7:06 AM, Nils Eliasson wrote:
> Hi again,
>
> Further testing revealed that not all issues was fully identified.
> Flushing could still cause compiles to halt even though compilations was
> on, and turning off compilations when the code cache was really full
> made the sweeper run much less often, prolonging the problem.
>
> Change log:
> * Fix the comment Christian mentioned, and some other comments too.
> * find_and_remove_saved_code renamed to reanimate_saved_code to
> distinguish it from remove_saved_code that actually removes it.

Please, add comments to those CodeCache methods to describe what they do.

> * dont bail out on need_flushing() in compile_method - that causes us to
> stop compiling as soon as we hit CodeCacheFlushingMinimumFreeSpace - and
> that wasn't the idea.

Then you should not check UseCodeCacheFlushing flag and the comment 
should be updated.

> * New product flag CodeCacheFlushingFraction (defaults to 2)
> * _was_full removed. Was a redundant way to say that we stopped
> compilations.
> * _last_was_full renamed to _last_full_flush_time, to emphasize that it
> is the time when we hit the hard limit CodeCacheMinimumSpace and
> compilations are stopped
> * _was_full_traversal renamed to _last_flush_traversal_id. 'full' means
> the hard CodeCacheMinimumFreeSpace limit in all other variable names. 
> * introduced _dead_compile_ids that hold a count for the number of
> compile ID that have been reclaimed. Gives a more accurate way to flush
> the cache.

Remove space in "jint       _flush_token;" to align it. Also align comments.

> * Simplified scan_stacks
>    - restore flush token when min interval has passed
>    - start compilations again if flushing is no longer needed
> * Speed up sweeper when compilations is turned off. Sweeping is slowed
> down when compiler threads are sleeping on the CodeCache lock, and we
> want to speed up the reclaim process so that we can turn on compiler again.
> * Let sweeper make disconnected methods non_entrant even if we don't
> need flushing any more. Makes us less likely to hit a new flush.

You removed compilation enabling code in 
speculative_disconnect_nmethods() so we need to wait next safepoint to 
enable it (in scan_stacks()). Should we do enabling compilation during 
sweep may be in an other place when we know that some space is reclaimed 
to avoid waiting safepoint?

> * Refactored NMethodSweeper::handle_full_code_cache
>    - flushed and full flushes now uses the same token to synchronize -
> otherwise we might get two back-to-back flushes. And that doesn't help
> anyone.
>    - remove time check - flush_token is restored in scan_stacks where
> the time is already checked.
> * set _resweep flag when flushing.
>
> The code is much easier to read now and the behavior should be less
> surprising.

Is that '/* */' leftover from your debugging?:

238   if (PrintMethodFlushing /*&& Verbose*/) {

Thanks,
Vladimir

>
> http://cr.openjdk.java.net/~neliasso/8012547/webrev.03/
> 
>
> Thanks,
> Nils Eliasson
>
>
> On 2013-04-18 15:09, Nils Eliasson wrote:
>> 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 unnecessary long time
>> sometimes causing unnecessary new flushes.
>>
>> Also some refactoring
>> - remove state variable _do_sweep that was unnecessary. It marked if a
>> sweep was active or not, but just a duplicate way of checking if any
>> methods are being sweept (nmethodsweeper::current != NULL).
>> - rename _rescan to _resweep. When _resweep is set there will be
>> another sweep started when the current ends. That sweep will start
>> with a scan, but it is not only a scan.
>> - rename _advise_to_sweep to _flush_token. Is CASed by the first
>> thread that wants to flush and reset by scan_stacks when the flush is
>> finished and a proper time has passed.
>>
>> http://cr.openjdk.java.net/~neliasso/8012547/
>> 
>> https://jbs.oracle.com/bugs/browse/JDK-8012547
>>
>> Thanks,
>> Nils E.
>

From john.cuthbertson at oracle.com  Wed Apr 24 14:24:23 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Wed, 24 Apr 2013 14:24:23 -0700
Subject: RFR (S): 8012715: G1: Fix bug in graphKit.cpp accessing
	PtrQueue::_index
In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165668F4394E@DEWDFEMB13A.global.corp.sap>
References: <7C9B87B351A4BA4AA9EC95BB4181165668F433AD@DEWDFEMB13A.global.corp.sap>
	<5176C585.8020805@oracle.com>
	<7C9B87B351A4BA4AA9EC95BB4181165668F4394E@DEWDFEMB13A.global.corp.sap>
Message-ID: <51784D87.10401@oracle.com>

Hi Martin

Thanks for accepting my suggestions. The changes look good to me. I'll 
start the process of pushing them.

As for C1, I'll submit the new CR and have a patch out shortly.

Many thanks for finding this.

JohnC

On 4/24/2013 1:50 AM, Doerr, Martin wrote:
>
> Hi John,
>
> thanks for your input. Here's the new webrev:
>
> http://cr.openjdk.java.net/~goetz/webrevs/8012715/ 
> 
>
> "zero" and "zeroX" are only used once. Would it be better to remove 
> these local variables and put "ConI" and "ConX" to where they are used?
>
> You have also asked about C1. I had also checked SPARC which looks ok. 
>  I agree with that it would be better to also fix C1 on x64_64.
>
> However, we are not using C1, so I'd prefer if you could handle it in 
> a separate CR.
>
> Kind regards,
>
> Martin
>
> *From:*John Cuthbertson [mailto:john.cuthbertson at oracle.com]
> *Sent:* Dienstag, 23. April 2013 19:32
> *To:* Doerr, Martin
> *Cc:* hotspot-compiler-dev at openjdk.java.net; Mikael Gerdin; 
> Lindenmaier, Goetz
> *Subject:* Re: RFR (S): 8012715: G1: Fix bug in graphKit.cpp accessing 
> PtrQueue::_index
>
> Hi Martin,
>
> Overall the changes look good to me. I kind of agree with Christian 
> though and I don't like the addition of T_X as an alias for a 
> BasicType. I would prefer something like:
>
>   __ if_then(marking, BoolTest::ne, zero); {
>     BasicType index_bt = TypeX_X->basic_type();
>     assert(sizeof(size_t) == type2aelembytes(index_bt), "Loading G1 
> PtrQueue::_index with wrong size.");
>     Node* index   = __ load(__ ctrl(), index_adr, TypeX_X, index_bt, 
> Compile::AliasIdxRaw);
>
> i.e. using the basic_type() routine in TypeLong or TypeInt.
>
> Minor nit:
> * Instead of __ ConX(0), can you define a zeroX and use that instead? 
> That will make:
>
>       // is the queue for this thread full?
>       __ if_then(index, BoolTest::ne, zeroX, likely); {
>
> look more consistent with:
>
>   // if (!marking)
>   __ if_then(marking, BoolTest::ne, zero); {
>
> Thanks,
>
> JohnC
>
> On 4/19/2013 5:02 AM, Doerr, Martin wrote:
>
>     Hi all,
>
>     we found a bug in the G1 barriers generated by the C2 compiler.
>
>     In graphKit INT operations were generated to access
>     PtrQueue::_index which
>
>     has type size_t. This is 64 bit on 64-bit machines. No problems
>     occur on
>
>     little endian machines as long as the index fits into 32 bit, but on
>
>     big endian machines the upper part is read, which is zero. This leads
>
>     to unnecessary branches to the slow path into the runtime.
>
>     The fix introduces X operations where INT was used:
>
>     http://cr.openjdk.java.net/~goetz/webrevs/g1-size_t_bug/
>     
>
>     This also removes a cast node.
>
>     We have also added a type T_X in globalDefinitions.hpp. Is there
>
>     already a mechanism to express this?
>
>     Please supply a bug id and review this change.
>
>     Best regards,
>
>     Martin
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130424/9378359d/attachment.html 

From john.cuthbertson at oracle.com  Wed Apr 24 15:16:29 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Wed, 24 Apr 2013 15:16:29 -0700
Subject: RFR (S): 8012715: G1: Fix bug in graphKit.cpp accessing
	PtrQueue::_index
In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165668F4394E@DEWDFEMB13A.global.corp.sap>
References: <7C9B87B351A4BA4AA9EC95BB4181165668F433AD@DEWDFEMB13A.global.corp.sap>
	<5176C585.8020805@oracle.com>
	<7C9B87B351A4BA4AA9EC95BB4181165668F4394E@DEWDFEMB13A.global.corp.sap>
Message-ID: <517859BD.4080605@oracle.com>

Hi Martin,

I've submitted "JDK-8013171 G1: C1 x64_64 barriers use 32 bit accesses 
to 64-bit PtrQueue::_index" to track the C1 barrier change. It should be 
visible in a day or so.

Cheers,

JohnC

On 4/24/2013 1:50 AM, Doerr, Martin wrote:
>
> Hi John,
>
> thanks for your input. Here's the new webrev:
>
> http://cr.openjdk.java.net/~goetz/webrevs/8012715/ 
> 
>
> "zero" and "zeroX" are only used once. Would it be better to remove 
> these local variables and put "ConI" and "ConX" to where they are used?
>
> You have also asked about C1. I had also checked SPARC which looks ok. 
>  I agree with that it would be better to also fix C1 on x64_64.
>
> However, we are not using C1, so I'd prefer if you could handle it in 
> a separate CR.
>
> Kind regards,
>
> Martin
>
> *From:*John Cuthbertson [mailto:john.cuthbertson at oracle.com]
> *Sent:* Dienstag, 23. April 2013 19:32
> *To:* Doerr, Martin
> *Cc:* hotspot-compiler-dev at openjdk.java.net; Mikael Gerdin; 
> Lindenmaier, Goetz
> *Subject:* Re: RFR (S): 8012715: G1: Fix bug in graphKit.cpp accessing 
> PtrQueue::_index
>
> Hi Martin,
>
> Overall the changes look good to me. I kind of agree with Christian 
> though and I don't like the addition of T_X as an alias for a 
> BasicType. I would prefer something like:
>
>   __ if_then(marking, BoolTest::ne, zero); {
>     BasicType index_bt = TypeX_X->basic_type();
>     assert(sizeof(size_t) == type2aelembytes(index_bt), "Loading G1 
> PtrQueue::_index with wrong size.");
>     Node* index   = __ load(__ ctrl(), index_adr, TypeX_X, index_bt, 
> Compile::AliasIdxRaw);
>
> i.e. using the basic_type() routine in TypeLong or TypeInt.
>
> Minor nit:
> * Instead of __ ConX(0), can you define a zeroX and use that instead? 
> That will make:
>
>       // is the queue for this thread full?
>       __ if_then(index, BoolTest::ne, zeroX, likely); {
>
> look more consistent with:
>
>   // if (!marking)
>   __ if_then(marking, BoolTest::ne, zero); {
>
> Thanks,
>
> JohnC
>
> On 4/19/2013 5:02 AM, Doerr, Martin wrote:
>
>     Hi all,
>
>     we found a bug in the G1 barriers generated by the C2 compiler.
>
>     In graphKit INT operations were generated to access
>     PtrQueue::_index which
>
>     has type size_t. This is 64 bit on 64-bit machines. No problems
>     occur on
>
>     little endian machines as long as the index fits into 32 bit, but on
>
>     big endian machines the upper part is read, which is zero. This leads
>
>     to unnecessary branches to the slow path into the runtime.
>
>     The fix introduces X operations where INT was used:
>
>     http://cr.openjdk.java.net/~goetz/webrevs/g1-size_t_bug/
>     
>
>     This also removes a cast node.
>
>     We have also added a type T_X in globalDefinitions.hpp. Is there
>
>     already a mechanism to express this?
>
>     Please supply a bug id and review this change.
>
>     Best regards,
>
>     Martin
>

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

From iggy.veresov at gmail.com  Wed Apr 24 16:38:32 2013
From: iggy.veresov at gmail.com (Igor Veresov)
Date: Wed, 24 Apr 2013 16:38:32 -0700
Subject: RFR (S): 8012715: G1: Fix bug in graphKit.cpp accessing
	PtrQueue::_index
In-Reply-To: <517712F1.3010101@oracle.com>
References: <7C9B87B351A4BA4AA9EC95BB4181165668F433AD@DEWDFEMB13A.global.corp.sap>
	<5176C585.8020805@oracle.com> <517712F1.3010101@oracle.com>
Message-ID: <50D5150A-B25B-4C1B-B836-BE9D2C433AF9@gmail.com>

But that works correctly though. x86 is little endian. 

igor

On Apr 23, 2013, at 4:02 PM, John Cuthbertson  wrote:

> Hi Martin,
> 
> One more thing - do you guys test with C1/Tiered at all?
> 
> I decided to check the C1 barriers and it looks like there's an issue there as well.
> 
> On Sparc we're doing the right thing. On x86 (in the G1 post barrier), I see:
> 
>>         // storing region crossing non-NULL, card is clean.
>>         // dirty card and log.
>> 
>>         __ movb(Address(card_addr, 0), 0);
>> 
>>         __ cmpl(queue_index, 0);
>>         __ jcc(Assembler::equal, runtime);
>>         __ subl(queue_index, wordSize);
> 
> And if we compare the same check for the pre-barrier:
> 
>>         // Can we store original value in the thread's buffer?
>> 
>> #ifdef _LP64
>>         __ movslq(tmp, queue_index);
>>         __ cmpq(tmp, 0);
>> #else
>>         __ cmpl(queue_index, 0);
>> #endif
>>         __ jcc(Assembler::equal, runtime);
>> #ifdef _LP64
>>         __ subq(tmp, wordSize);
>>         __ movl(queue_index, tmp);
>>         __ addq(tmp, buffer);
>> #else
>>         __ subl(queue_index, wordSize);
>>         __ movl(tmp, buffer);
>>         __ addl(tmp, queue_index);
>> #endif
> 
> I think both are wrong. In the pre-barrier we do a 32 bit move of the new index into the queue_index address. In the post barrier we use only 32 bit arithmetic. As you said they're benign as long as the values fit in 32 bits but they should probably be fixed.
> 
> Do you want to fix the C1 barrier as part of your webrev or have me fix it in a separate CR?
> 
> Thanks,
> 
> JohnC
> 
> On 4/23/2013 10:31 AM, John Cuthbertson wrote:
>> Hi Martin,
>> 
>> Overall the changes look good to me. I kind of agree with Christian though and I don't like the addition of T_X as an alias for a BasicType. I would prefer something like:
>> 
>>   __ if_then(marking, BoolTest::ne, zero); {
>>     BasicType index_bt = TypeX_X->basic_type();
>>     assert(sizeof(size_t) == type2aelembytes(index_bt), "Loading G1 PtrQueue::_index with wrong size.");
>>     Node* index   = __ load(__ ctrl(), index_adr, TypeX_X, index_bt, Compile::AliasIdxRaw);
>> 
>> i.e. using the basic_type() routine in TypeLong or TypeInt.
>> 
>> Minor nit:
>> * Instead of __ ConX(0), can you define a zeroX and use that instead? That will make:
>> 
>>       // is the queue for this thread full?
>>       __ if_then(index, BoolTest::ne, zeroX, likely); {
>> 
>> look more consistent with:
>> 
>>   // if (!marking)
>>   __ if_then(marking, BoolTest::ne, zero); {
>> 
>> Thanks,
>> 
>> JohnC
>> 
>> On 4/19/2013 5:02 AM, Doerr, Martin wrote:
>>> Hi all,
>>>  
>>> we found a bug in the G1 barriers generated by the C2 compiler.
>>>  
>>> In graphKit INT operations were generated to access PtrQueue::_index which
>>> has type size_t. This is 64 bit on 64-bit machines. No problems occur on
>>> little endian machines as long as the index fits into 32 bit, but on
>>> big endian machines the upper part is read, which is zero. This leads
>>> to unnecessary branches to the slow path into the runtime.
>>>  
>>> The fix introduces X operations where INT was used:
>>> http://cr.openjdk.java.net/~goetz/webrevs/g1-size_t_bug/
>>>  
>>> This also removes a cast node.
>>>  
>>> We have also added a type T_X in globalDefinitions.hpp. Is there
>>> already a mechanism to express this?
>>>  
>>> Please supply a bug id and review this change.
>>>  
>>> Best regards,
>>> Martin
>>>  
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130424/021c5959/attachment.html 

From john.cuthbertson at oracle.com  Wed Apr 24 17:26:44 2013
From: john.cuthbertson at oracle.com (John Cuthbertson)
Date: Wed, 24 Apr 2013 17:26:44 -0700
Subject: RFR (S): 8012715: G1: Fix bug in graphKit.cpp accessing
	PtrQueue::_index
In-Reply-To: <50D5150A-B25B-4C1B-B836-BE9D2C433AF9@gmail.com>
References: <7C9B87B351A4BA4AA9EC95BB4181165668F433AD@DEWDFEMB13A.global.corp.sap>
	<5176C585.8020805@oracle.com> <517712F1.3010101@oracle.com>
	<50D5150A-B25B-4C1B-B836-BE9D2C433AF9@gmail.com>
Message-ID: <51787844.8080604@oracle.com>

Hi Igor,

It does work correctly. That's why the other CR is a P4. ;) But it makes 
sense to clean it up though.

JohnC

On 4/24/2013 4:38 PM, Igor Veresov wrote:
> But that works correctly though. x86 is little endian.
>
> igor
>
> On Apr 23, 2013, at 4:02 PM, John Cuthbertson 
> > wrote:
>
>> Hi Martin,
>>
>> One more thing - do you guys test with C1/Tiered at all?
>>
>> I decided to check the C1 barriers and it looks like there's an issue 
>> there as well.
>>
>> On Sparc we're doing the right thing. On x86 (in the G1 post 
>> barrier), I see:
>>
>>>         // storing region crossing non-NULL, card is clean.
>>>         // dirty card and log.
>>>
>>>         __ movb(Address(card_addr, 0), 0);
>>>
>>>         __ cmpl(queue_index, 0);
>>>         __ jcc(Assembler::equal, runtime);
>>>         __ subl(queue_index, wordSize);
>>
>> And if we compare the same check for the pre-barrier:
>>
>>>         // Can we store original value in the thread's buffer?
>>>
>>> #ifdef _LP64
>>>         __ movslq(tmp, queue_index);
>>>         __ cmpq(tmp, 0);
>>> #else
>>>         __ cmpl(queue_index, 0);
>>> #endif
>>>         __ jcc(Assembler::equal, runtime);
>>> #ifdef _LP64
>>>         __ subq(tmp, wordSize);
>>>         __ movl(queue_index, tmp);
>>>         __ addq(tmp, buffer);
>>> #else
>>>         __ subl(queue_index, wordSize);
>>>         __ movl(tmp, buffer);
>>>         __ addl(tmp, queue_index);
>>> #endif
>>
>> I think both are wrong. In the pre-barrier we do a 32 bit move of the 
>> new index into the queue_index address. In the post barrier we use 
>> only 32 bit arithmetic. As you said they're benign as long as the 
>> values fit in 32 bits but they should probably be fixed.
>>
>> Do you want to fix the C1 barrier as part of your webrev or have me 
>> fix it in a separate CR?
>>
>> Thanks,
>>
>> JohnC
>>
>> On 4/23/2013 10:31 AM, John Cuthbertson wrote:
>>> Hi Martin,
>>>
>>> Overall the changes look good to me. I kind of agree with Christian 
>>> though and I don't like the addition of T_X as an alias for a 
>>> BasicType. I would prefer something like:
>>>
>>>   __ if_then(marking, BoolTest::ne, zero); {
>>>     BasicType index_bt = TypeX_X->basic_type();
>>>     assert(sizeof(size_t) == type2aelembytes(index_bt), "Loading G1 
>>> PtrQueue::_index with wrong size.");
>>>     Node* index   = __ load(__ ctrl(), index_adr, TypeX_X, index_bt, 
>>> Compile::AliasIdxRaw);
>>>
>>> i.e. using the basic_type() routine in TypeLong or TypeInt.
>>>
>>> Minor nit:
>>> * Instead of __ ConX(0), can you define a zeroX and use that 
>>> instead? That will make:
>>>
>>>       // is the queue for this thread full?
>>>       __ if_then(index, BoolTest::ne, zeroX, likely); {
>>>
>>> look more consistent with:
>>>
>>>   // if (!marking)
>>>   __ if_then(marking, BoolTest::ne, zero); {
>>>
>>> Thanks,
>>>
>>> JohnC
>>>
>>> On 4/19/2013 5:02 AM, Doerr, Martin wrote:
>>>>
>>>> Hi all,
>>>>
>>>> we found a bug in the G1 barriers generated by the C2 compiler.
>>>>
>>>> In graphKit INT operations were generated to access 
>>>> PtrQueue::_index which
>>>>
>>>> has type size_t. This is 64 bit on 64-bit machines. No problems 
>>>> occur on
>>>>
>>>> little endian machines as long as the index fits into 32 bit, but on
>>>>
>>>> big endian machines the upper part is read, which is zero. This leads
>>>>
>>>> to unnecessary branches to the slow path into the runtime.
>>>>
>>>> The fix introduces X operations where INT was used:
>>>>
>>>> http://cr.openjdk.java.net/~goetz/webrevs/g1-size_t_bug/ 
>>>> 
>>>>
>>>> This also removes a cast node.
>>>>
>>>> We have also added a type T_X in globalDefinitions.hpp. Is there
>>>>
>>>> already a mechanism to express this?
>>>>
>>>> Please supply a bug id and review this change.
>>>>
>>>> Best regards,
>>>>
>>>> Martin
>>>>
>>>
>>
>

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

From christian.thalinger at oracle.com  Wed Apr 24 19:37:32 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 24 Apr 2013 19:37:32 -0700
Subject: RFR (S/M): 8012547: Reclamation of flushed methods can be slow
In-Reply-To: <5177E939.1050706@oracle.com>
References: <516FF08A.2080808@oracle.com> <5177E939.1050706@oracle.com>
Message-ID: <9EA2E0DE-E82E-4A85-8838-C383A2D15D6A@oracle.com>


On Apr 24, 2013, at 7:16 AM, Nils Eliasson  wrote:

> This is the correct webrev for the RFR I sent a moment ago:
> 
> http://cr.openjdk.java.net/~neliasso/8012547/webrev.04/ 

src/share/vm/runtime/sweeper.cpp:

+          (_traversals > _last_flush_traversal_id + 2) && ((uint)nm->compile_id() < _highest_marked)) {

Can't we change _highest_marked to int?  I see that CompileBroker::get_compilation_id() returns an uint.  We should decide if compile ids are int or uint.  I vote for int.

I don't see _dead_compile_ids being ever set.

-- Chris

> 
> //Nils
> 
> On 2013-04-18 15:09, Nils Eliasson wrote:
>> 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 unnecessary long time sometimes causing unnecessary new flushes.
>> 
>> Also some refactoring
>> - remove state variable _do_sweep that was unnecessary. It marked if a sweep was active or not, but just a duplicate way of checking if any methods are being sweept (nmethodsweeper::current != NULL).
>> - rename _rescan to _resweep. When _resweep is set there will be another sweep started when the current ends. That sweep will start with a scan, but it is not only a scan.
>> - rename _advise_to_sweep to _flush_token. Is CASed by the first thread that wants to flush and reset by scan_stacks when the flush is finished and a proper time has passed.
>> 
>> http://cr.openjdk.java.net/~neliasso/8012547/ 
>> https://jbs.oracle.com/bugs/browse/JDK-8012547
>> 
>> Thanks,
>> Nils E.
> 


From jiangli.zhou at oracle.com  Wed Apr 24 22:54:32 2013
From: jiangli.zhou at oracle.com (jiangli.zhou at oracle.com)
Date: Thu, 25 Apr 2013 05:54:32 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 8013041: guarantee(this->is8bit(imm8))
	failed: Short forward jump exceeds 8-bit offset.
Message-ID: <20130425055436.F0DA7485B9@hg.openjdk.java.net>

Changeset: 47766e2d2527
Author:    jiangli
Date:      2013-04-24 18:20 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/47766e2d2527

8013041: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset.
Summary: Change jmpb() to jmp().
Reviewed-by: coleenp, rdurbin, dcubed

! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp


From albert.noll at oracle.com  Thu Apr 25 01:54:37 2013
From: albert.noll at oracle.com (Albert Noll)
Date: Thu, 25 Apr 2013 10:54:37 +0200
Subject: hg: hsx/hotspot-comp/hotspot: 8010332: remove unused method
	ciMethod::uses_monitors
In-Reply-To: <8A84EA7E-4C35-493F-B0B9-C657A188AAC5@oracle.com>
References: <5177A380.6070002@oracle.com>
	<8A84EA7E-4C35-493F-B0B9-C657A188AAC5@oracle.com>
Message-ID: <5178EF4D.6060907@oracle.com>

On 04/24/2013 09:21 PM, Christian Thalinger wrote:
> On Apr 24, 2013, at 2:18 AM, Albert Noll  > wrote:
>
>> Hi all,
>>
>> please review the patch:
>>
>>
>> Problem:
>> unused method with misleading name
>>
>> Fix:
>> removed unused method
>
> The change looks good but are you sure you're not mixing up bugs?
>
> -- Chris
>
Hi, thanks Chris. Yes, the link points to the wrong bug. Here is the 
correct link.

https://jbs.oracle.com/bugs/browse/JDK-8010332

Sorry for the confusion,
Albert
>>
>> Testing:
>> JPRT 'compiler'
>>
>> webrev: http://cr.openjdk.java.net/~roland/8010332/webrev.00/ 
>> 
>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8010332 
>> 
>

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

From nils.eliasson at oracle.com  Thu Apr 25 07:05:06 2013
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Thu, 25 Apr 2013 16:05:06 +0200
Subject: RFR (S/M): 8012547: Reclamation of flushed methods can be slow
In-Reply-To: <5178419A.7080209@oracle.com>
References: <516FF08A.2080808@oracle.com> <5177E6FE.5010503@oracle.com>
	<5178419A.7080209@oracle.com>
Message-ID: <51793812.1020803@oracle.com>


On 2013-04-24 22:33, Vladimir Kozlov wrote:
> Nils,
>
> Yes, in general it is better.
>
> http://cr.openjdk.java.net/~neliasso/8012547/webrev.04/
>
> On 4/24/13 7:06 AM, Nils Eliasson wrote:
>> Hi again,
>>
>> Further testing revealed that not all issues was fully identified.
>> Flushing could still cause compiles to halt even though compilations was
>> on, and turning off compilations when the code cache was really full
>> made the sweeper run much less often, prolonging the problem.
>>
>> Change log:
>> * Fix the comment Christian mentioned, and some other comments too.
>> * find_and_remove_saved_code renamed to reanimate_saved_code to
>> distinguish it from remove_saved_code that actually removes it.
>
> Please, add comments to those CodeCache methods to describe what they do.

ok - fixed.

>> * dont bail out on need_flushing() in compile_method - that causes us to
>> stop compiling as soon as we hit CodeCacheFlushingMinimumFreeSpace - and
>> that wasn't the idea.
>
> Then you should not check UseCodeCacheFlushing flag and the comment 
> should be updated.

ok, I removed the flag and the capacity check. When we can hit it - 
compilation should already be turned off. And if it isn't it will be in 
a moment.

>
>> * New product flag CodeCacheFlushingFraction (defaults to 2)
>> * _was_full removed. Was a redundant way to say that we stopped
>> compilations.
>> * _last_was_full renamed to _last_full_flush_time, to emphasize that it
>> is the time when we hit the hard limit CodeCacheMinimumSpace and
>> compilations are stopped
>> * _was_full_traversal renamed to _last_flush_traversal_id. 'full' means
>> the hard CodeCacheMinimumFreeSpace limit in all other variable names. 
>> * introduced _dead_compile_ids that hold a count for the number of
>> compile ID that have been reclaimed. Gives a more accurate way to flush
>> the cache.
>
> Remove space in "jint       _flush_token;" to align it. Also align 
> comments.
Fixed
>
>> * Simplified scan_stacks
>>    - restore flush token when min interval has passed
>>    - start compilations again if flushing is no longer needed
>> * Speed up sweeper when compilations is turned off. Sweeping is slowed
>> down when compiler threads are sleeping on the CodeCache lock, and we
>> want to speed up the reclaim process so that we can turn on compiler 
>> again.
>> * Let sweeper make disconnected methods non_entrant even if we don't
>> need flushing any more. Makes us less likely to hit a new flush.
>
> You removed compilation enabling code in 
> speculative_disconnect_nmethods() so we need to wait next safepoint to 
> enable it (in scan_stacks()). Should we do enabling compilation during 
> sweep may be in an other place when we know that some space is 
> reclaimed to avoid waiting safepoint?

Yes, my though was that !CodeCache::needs_flushing() will never be true 
since this code is only called when we need flushing. And the only place 
where code cache is actually freed is in scan_stacks when nmethods are 
flushed. So it should be enough to check for turning on the compiler as 
the last thing there.

>
>> * Refactored NMethodSweeper::handle_full_code_cache
>>    - flushed and full flushes now uses the same token to synchronize -
>> otherwise we might get two back-to-back flushes. And that doesn't help
>> anyone.
>>    - remove time check - flush_token is restored in scan_stacks where
>> the time is already checked.
>> * set _resweep flag when flushing.
>>
>> The code is much easier to read now and the behavior should be less
>> surprising.
>
> Is that '/* */' leftover from your debugging?:
>
> 238   if (PrintMethodFlushing /*&& Verbose*/) {
>
Yes, I forgot to qrefresh my patch before doing the webrev.

> Thanks,
> Vladimir

New webrev with your and Christians feedback here:

http://cr.openjdk.java.net/~neliasso/8012547/webrev.07 


Thanks for all your help!
//Nils
>
>>
>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.03/
>> 
>>
>> Thanks,
>> Nils Eliasson
>>
>>
>> On 2013-04-18 15:09, Nils Eliasson wrote:
>>> 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 unnecessary long time
>>> sometimes causing unnecessary new flushes.
>>>
>>> Also some refactoring
>>> - remove state variable _do_sweep that was unnecessary. It marked if a
>>> sweep was active or not, but just a duplicate way of checking if any
>>> methods are being sweept (nmethodsweeper::current != NULL).
>>> - rename _rescan to _resweep. When _resweep is set there will be
>>> another sweep started when the current ends. That sweep will start
>>> with a scan, but it is not only a scan.
>>> - rename _advise_to_sweep to _flush_token. Is CASed by the first
>>> thread that wants to flush and reset by scan_stacks when the flush is
>>> finished and a proper time has passed.
>>>
>>> http://cr.openjdk.java.net/~neliasso/8012547/
>>> 
>>> https://jbs.oracle.com/bugs/browse/JDK-8012547
>>>
>>> Thanks,
>>> Nils E.
>>


From nils.eliasson at oracle.com  Thu Apr 25 07:05:31 2013
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Thu, 25 Apr 2013 16:05:31 +0200
Subject: RFR (S/M): 8012547: Reclamation of flushed methods can be slow
In-Reply-To: <9EA2E0DE-E82E-4A85-8838-C383A2D15D6A@oracle.com>
References: <516FF08A.2080808@oracle.com> <5177E939.1050706@oracle.com>
	<9EA2E0DE-E82E-4A85-8838-C383A2D15D6A@oracle.com>
Message-ID: <5179382B.5070403@oracle.com>



On 2013-04-25 04:37, Christian Thalinger wrote:
> On Apr 24, 2013, at 7:16 AM, Nils Eliasson  wrote:
>
>> This is the correct webrev for the RFR I sent a moment ago:
>>
>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.04/ 
> src/share/vm/runtime/sweeper.cpp:
>
> +          (_traversals > _last_flush_traversal_id + 2) && ((uint)nm->compile_id() < _highest_marked)) {
>
> Can't we change _highest_marked to int?  I see that CompileBroker::get_compilation_id() returns an uint.  We should decide if compile ids are int or uint.  I vote for int.
Yes. They can only be positive, and 0 is used blobs without ID. But int 
is the type used in other places so I will change to that and make it a 
little bit more consistent.

>
> I don't see _dead_compile_ids being ever set.

It isn't :P TortoiseHG reverts changes on qrefresh when it thinks the 
patch is public. Without notice.

Fixed.

New webrev including your and Vladimirs suggestions:
http://cr.openjdk.java.net/~neliasso/8012547/webrev.07 


Thanks!
//Nils

>
> -- Chris
>
>> //Nils
>>
>> On 2013-04-18 15:09, Nils Eliasson wrote:
>>> 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 unnecessary long time sometimes causing unnecessary new flushes.
>>>
>>> Also some refactoring
>>> - remove state variable _do_sweep that was unnecessary. It marked if a sweep was active or not, but just a duplicate way of checking if any methods are being sweept (nmethodsweeper::current != NULL).
>>> - rename _rescan to _resweep. When _resweep is set there will be another sweep started when the current ends. That sweep will start with a scan, but it is not only a scan.
>>> - rename _advise_to_sweep to _flush_token. Is CASed by the first thread that wants to flush and reset by scan_stacks when the flush is finished and a proper time has passed.
>>>
>>> http://cr.openjdk.java.net/~neliasso/8012547/ 
>>> https://jbs.oracle.com/bugs/browse/JDK-8012547
>>>
>>> Thanks,
>>> Nils E.


From vladimir.x.ivanov at oracle.com  Thu Apr 25 07:50:44 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 25 Apr 2013 18:50:44 +0400
Subject: RFR (S): 8012260: ciReplay: Include PID into the name of replay
	data file
In-Reply-To: 
References: <516DE649.9020105@oracle.com> <516E3191.4020401@oracle.com>
	<516EBD8A.9090009@oracle.com> <516EC599.5000401@oracle.com>
	<516EC7E2.40401@oracle.com> <516ECE0E.8010006@oracle.com>
	<517151E0.8080909@oracle.com> <5171611B.7000403@oracle.com>
	<517178F5.9030604@oracle.com>
	
	<5171C261.1060207@oracle.com>
	
Message-ID: <517942C4.1060609@oracle.com>

Chris,

You were right. Here's updated version:
http://cr.openjdk.java.net/~vlivanov/8012260/webrev.03/

Best regards,
Vladimir Ivanov

On 4/20/13 8:03 AM, Christian Thalinger wrote:
>
> On Apr 19, 2013, at 3:17 PM, Vladimir Ivanov  wrote:
>
>> Thank you for review, Chris!
>>
>>> src/os/windows/vm/os_windows.cpp:
>>>
>>> +   if (buflen > INT_MAX)  n = INT_MAX;
>>>
>>> Why do we have this check on Windows?
>> Since _getcwd requires int on Windows, this is a consequence of size_t -> int conversion.
>
> Got it.
>
>>
>>> src/share/vm/utilities/ostream.hpp:
>>>
>>> !   fileStream(FILE* file, bool need_close=false) { _file = file; _need_close = need_close; }
>>>
>>> Please put spaces before and after "=".
>> Sure, will do.
>>
>>> +        if (pos > 0 &&
>>> +            Arguments::copy_expand_pid(default_pattern, strlen(default_pattern),
>>> +                                       &buf[pos], buflen-pos)) {
>>> +          fd = open(buf, O_RDWR | O_CREAT | O_TRUNC, 0666);
>>> +        }
>>>
>>> Could you factor this code into a method?  It's duplicated three times.
>> Yeah, I don't like it either :-) But I don't think that a function call will help here. Maybe factoring parameters may help, but I'm not sure. What do you prefer?
>
> Putting Arguments::copy_expand_pid and open calls into a method sounds like a win to me.
>
> -- Chris
>
>>
>> Best regards,
>> Vladimir Ivanov
>>
>>> Otherwise this looks good.
>>>
>>> -- Chris
>>>
>>> On Apr 19, 2013, at 10:03 AM, Vladimir Ivanov  wrote:
>>>
>>>> I need one more "official" review. Any volunteers? :-)
>>>>
>>>> Thanks!
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>> On 4/19/13 7:22 PM, Vladimir Kozlov wrote:
>>>>> Looks good.
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 4/19/13 7:17 AM, Vladimir Ivanov wrote:
>>>>>> Updated fix:
>>>>>> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.02/
>>>>>>
>>>>>> Did some additional cleanup: changed get_current_directory to accept
>>>>>> size_t instead of int as a buffer size.
>>>>>>
>>>>>> Best regards,
>>>>>> Vladimir Ivanov
>>>>>>
>>>>>> On 4/17/13 8:30 PM, Vladimir Kozlov wrote:
>>>>>>> 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 christian.thalinger at oracle.com  Thu Apr 25 09:59:17 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 25 Apr 2013 09:59:17 -0700
Subject: RFR (S/M): 8012547: Reclamation of flushed methods can be slow
In-Reply-To: <5179382B.5070403@oracle.com>
References: <516FF08A.2080808@oracle.com> <5177E939.1050706@oracle.com>
	<9EA2E0DE-E82E-4A85-8838-C383A2D15D6A@oracle.com>
	<5179382B.5070403@oracle.com>
Message-ID: <43374FFE-AFA5-41BA-B4D6-5813A7C56DD3@oracle.com>

Since someone has to start with this:  could you please change the method comments you've added to Doxygen-style comments?

-nmethod* CodeCache::find_and_remove_saved_code(Method* m) {
+// Remove and return nmethod from the saved code list in order to reanimate it.
+nmethod* CodeCache::reanimate_saved_code(Method* m) {

to:

/**
 * Remove and return nmethod from the saved code list in order to reanimate it.
 */
nmethod* CodeCache::reanimate_saved_code(Method* m) {

Otherwise this looks good.

-- Chris

On Apr 25, 2013, at 7:05 AM, Nils Eliasson  wrote:

> 
> 
> On 2013-04-25 04:37, Christian Thalinger wrote:
>> On Apr 24, 2013, at 7:16 AM, Nils Eliasson  wrote:
>> 
>>> This is the correct webrev for the RFR I sent a moment ago:
>>> 
>>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.04/ 
>> src/share/vm/runtime/sweeper.cpp:
>> 
>> +          (_traversals > _last_flush_traversal_id + 2) && ((uint)nm->compile_id() < _highest_marked)) {
>> 
>> Can't we change _highest_marked to int?  I see that CompileBroker::get_compilation_id() returns an uint.  We should decide if compile ids are int or uint.  I vote for int.
> Yes. They can only be positive, and 0 is used blobs without ID. But int is the type used in other places so I will change to that and make it a little bit more consistent.
> 
>> 
>> I don't see _dead_compile_ids being ever set.
> 
> It isn't :P TortoiseHG reverts changes on qrefresh when it thinks the patch is public. Without notice.
> 
> Fixed.
> 
> New webrev including your and Vladimirs suggestions:
> http://cr.openjdk.java.net/~neliasso/8012547/webrev.07 
> 
> Thanks!
> //Nils
> 
>> 
>> -- Chris
>> 
>>> //Nils
>>> 
>>> On 2013-04-18 15:09, Nils Eliasson wrote:
>>>> 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 unnecessary long time sometimes causing unnecessary new flushes.
>>>> 
>>>> Also some refactoring
>>>> - remove state variable _do_sweep that was unnecessary. It marked if a sweep was active or not, but just a duplicate way of checking if any methods are being sweept (nmethodsweeper::current != NULL).
>>>> - rename _rescan to _resweep. When _resweep is set there will be another sweep started when the current ends. That sweep will start with a scan, but it is not only a scan.
>>>> - rename _advise_to_sweep to _flush_token. Is CASed by the first thread that wants to flush and reset by scan_stacks when the flush is finished and a proper time has passed.
>>>> 
>>>> http://cr.openjdk.java.net/~neliasso/8012547/ 
>>>> https://jbs.oracle.com/bugs/browse/JDK-8012547
>>>> 
>>>> Thanks,
>>>> Nils E.
> 


From christian.thalinger at oracle.com  Thu Apr 25 10:04:14 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 25 Apr 2013 10:04:14 -0700
Subject: RFR (XXS): 8010332: remove unused method ciMethod::uses_monitors
In-Reply-To: <5178EF4D.6060907@oracle.com>
References: <5177A380.6070002@oracle.com>
	<8A84EA7E-4C35-493F-B0B9-C657A188AAC5@oracle.com>
	<5178EF4D.6060907@oracle.com>
Message-ID: 

[I fixed the subject line.]

On Apr 25, 2013, at 1:54 AM, Albert Noll  wrote:

> On 04/24/2013 09:21 PM, Christian Thalinger wrote:
>> On Apr 24, 2013, at 2:18 AM, Albert Noll  wrote:
>> 
>>> Hi all,
>>> 
>>> please review the patch:
>>> 
>>> 
>>> Problem:
>>> unused method with misleading name
>>> 
>>> Fix:
>>> removed unused method
>> 
>> The change looks good but are you sure you're not mixing up bugs?
>> 
>> -- Chris
>> 
> Hi, thanks Chris. Yes, the link points to the wrong bug. Here is the correct link.
> 
> https://jbs.oracle.com/bugs/browse/JDK-8010332

And the correct link to the webrev:

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

(I hate URLs where the target is actually different than the name; it's hard to spot.)

The change looks good though.

-- Chris

> 
> Sorry for the confusion,
> Albert
>>> 
>>> Testing:
>>> JPRT 'compiler'
>>> 
>>> webrev:  http://cr.openjdk.java.net/~roland/8010332/webrev.00/
>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8010332
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130425/91fb6c9e/attachment.html 

From christian.thalinger at oracle.com  Thu Apr 25 10:08:28 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 25 Apr 2013 10:08:28 -0700
Subject: RFR (S): 8012260: ciReplay: Include PID into the name of replay
	data file
In-Reply-To: <517942C4.1060609@oracle.com>
References: <516DE649.9020105@oracle.com> <516E3191.4020401@oracle.com>
	<516EBD8A.9090009@oracle.com> <516EC599.5000401@oracle.com>
	<516EC7E2.40401@oracle.com> <516ECE0E.8010006@oracle.com>
	<517151E0.8080909@oracle.com> <5171611B.7000403@oracle.com>
	<517178F5.9030604@oracle.com>
	
	<5171C261.1060207@oracle.com>
	
	<517942C4.1060609@oracle.com>
Message-ID: 


On Apr 25, 2013, at 7:50 AM, Vladimir Ivanov  wrote:

> Chris,
> 
> You were right. Here's updated version:
> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.03/

Much better.  Thank you.  Perhaps you also want to change your method comments to Doxygen-style ones?

-- Chris

> 
> Best regards,
> Vladimir Ivanov
> 
> On 4/20/13 8:03 AM, Christian Thalinger wrote:
>> 
>> On Apr 19, 2013, at 3:17 PM, Vladimir Ivanov  wrote:
>> 
>>> Thank you for review, Chris!
>>> 
>>>> src/os/windows/vm/os_windows.cpp:
>>>> 
>>>> +   if (buflen > INT_MAX)  n = INT_MAX;
>>>> 
>>>> Why do we have this check on Windows?
>>> Since _getcwd requires int on Windows, this is a consequence of size_t -> int conversion.
>> 
>> Got it.
>> 
>>> 
>>>> src/share/vm/utilities/ostream.hpp:
>>>> 
>>>> !   fileStream(FILE* file, bool need_close=false) { _file = file; _need_close = need_close; }
>>>> 
>>>> Please put spaces before and after "=".
>>> Sure, will do.
>>> 
>>>> +        if (pos > 0 &&
>>>> +            Arguments::copy_expand_pid(default_pattern, strlen(default_pattern),
>>>> +                                       &buf[pos], buflen-pos)) {
>>>> +          fd = open(buf, O_RDWR | O_CREAT | O_TRUNC, 0666);
>>>> +        }
>>>> 
>>>> Could you factor this code into a method?  It's duplicated three times.
>>> Yeah, I don't like it either :-) But I don't think that a function call will help here. Maybe factoring parameters may help, but I'm not sure. What do you prefer?
>> 
>> Putting Arguments::copy_expand_pid and open calls into a method sounds like a win to me.
>> 
>> -- Chris
>> 
>>> 
>>> Best regards,
>>> Vladimir Ivanov
>>> 
>>>> Otherwise this looks good.
>>>> 
>>>> -- Chris
>>>> 
>>>> On Apr 19, 2013, at 10:03 AM, Vladimir Ivanov  wrote:
>>>> 
>>>>> I need one more "official" review. Any volunteers? :-)
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>> 
>>>>> On 4/19/13 7:22 PM, Vladimir Kozlov wrote:
>>>>>> Looks good.
>>>>>> 
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>> 
>>>>>> On 4/19/13 7:17 AM, Vladimir Ivanov wrote:
>>>>>>> Updated fix:
>>>>>>> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.02/
>>>>>>> 
>>>>>>> Did some additional cleanup: changed get_current_directory to accept
>>>>>>> size_t instead of int as a buffer size.
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> Vladimir Ivanov
>>>>>>> 
>>>>>>> On 4/17/13 8:30 PM, Vladimir Kozlov wrote:
>>>>>>>> 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 vladimir.x.ivanov at oracle.com  Thu Apr 25 10:45:56 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 25 Apr 2013 21:45:56 +0400
Subject: RFR (S): 8012260: ciReplay: Include PID into the name of replay
	data file
In-Reply-To: 
References: <516DE649.9020105@oracle.com> <516E3191.4020401@oracle.com>
	<516EBD8A.9090009@oracle.com> <516EC599.5000401@oracle.com>
	<516EC7E2.40401@oracle.com> <516ECE0E.8010006@oracle.com>
	<517151E0.8080909@oracle.com> <5171611B.7000403@oracle.com>
	<517178F5.9030604@oracle.com>
	
	<5171C261.1060207@oracle.com>
	
	<517942C4.1060609@oracle.com>
	
Message-ID: <51796BD4.7050502@oracle.com>

Chris,

Thanks for review!
Sure, I've updated [1] with your suggestion.

Best regards,
Vladimir Ivanov

[1] http://cr.openjdk.java.net/~vlivanov/8012260/webrev.03/

On 4/25/13 9:08 PM, Christian Thalinger wrote:
>
> On Apr 25, 2013, at 7:50 AM, Vladimir Ivanov  wrote:
>
>> Chris,
>>
>> You were right. Here's updated version:
>> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.03/
>
> Much better.  Thank you.  Perhaps you also want to change your method comments to Doxygen-style ones?
>
> -- Chris
>
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 4/20/13 8:03 AM, Christian Thalinger wrote:
>>>
>>> On Apr 19, 2013, at 3:17 PM, Vladimir Ivanov  wrote:
>>>
>>>> Thank you for review, Chris!
>>>>
>>>>> src/os/windows/vm/os_windows.cpp:
>>>>>
>>>>> +   if (buflen > INT_MAX)  n = INT_MAX;
>>>>>
>>>>> Why do we have this check on Windows?
>>>> Since _getcwd requires int on Windows, this is a consequence of size_t -> int conversion.
>>>
>>> Got it.
>>>
>>>>
>>>>> src/share/vm/utilities/ostream.hpp:
>>>>>
>>>>> !   fileStream(FILE* file, bool need_close=false) { _file = file; _need_close = need_close; }
>>>>>
>>>>> Please put spaces before and after "=".
>>>> Sure, will do.
>>>>
>>>>> +        if (pos > 0 &&
>>>>> +            Arguments::copy_expand_pid(default_pattern, strlen(default_pattern),
>>>>> +                                       &buf[pos], buflen-pos)) {
>>>>> +          fd = open(buf, O_RDWR | O_CREAT | O_TRUNC, 0666);
>>>>> +        }
>>>>>
>>>>> Could you factor this code into a method?  It's duplicated three times.
>>>> Yeah, I don't like it either :-) But I don't think that a function call will help here. Maybe factoring parameters may help, but I'm not sure. What do you prefer?
>>>
>>> Putting Arguments::copy_expand_pid and open calls into a method sounds like a win to me.
>>>
>>> -- Chris
>>>
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>>> Otherwise this looks good.
>>>>>
>>>>> -- Chris
>>>>>
>>>>> On Apr 19, 2013, at 10:03 AM, Vladimir Ivanov  wrote:
>>>>>
>>>>>> I need one more "official" review. Any volunteers? :-)
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Best regards,
>>>>>> Vladimir Ivanov
>>>>>>
>>>>>> On 4/19/13 7:22 PM, Vladimir Kozlov wrote:
>>>>>>> Looks good.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 4/19/13 7:17 AM, Vladimir Ivanov wrote:
>>>>>>>> Updated fix:
>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.02/
>>>>>>>>
>>>>>>>> Did some additional cleanup: changed get_current_directory to accept
>>>>>>>> size_t instead of int as a buffer size.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Vladimir Ivanov
>>>>>>>>
>>>>>>>> On 4/17/13 8:30 PM, Vladimir Kozlov wrote:
>>>>>>>>> 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 vladimir.kozlov at oracle.com  Thu Apr 25 11:03:52 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 25 Apr 2013 11:03:52 -0700
Subject: RFR (S): 8012260: ciReplay: Include PID into the name of replay
	data file
In-Reply-To: <517942C4.1060609@oracle.com>
References: <516DE649.9020105@oracle.com> <516E3191.4020401@oracle.com>
	<516EBD8A.9090009@oracle.com> <516EC599.5000401@oracle.com>
	<516EC7E2.40401@oracle.com> <516ECE0E.8010006@oracle.com>
	<517151E0.8080909@oracle.com> <5171611B.7000403@oracle.com>
	<517178F5.9030604@oracle.com>
	
	<5171C261.1060207@oracle.com>
	
	<517942C4.1060609@oracle.com>
Message-ID: <51797008.1080007@oracle.com>

Looks good.

Vladimir K

On 4/25/13 7:50 AM, Vladimir Ivanov wrote:
> Chris,
>
> You were right. Here's updated version:
> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.03/
>
> Best regards,
> Vladimir Ivanov
>
> On 4/20/13 8:03 AM, Christian Thalinger wrote:
>>
>> On Apr 19, 2013, at 3:17 PM, Vladimir Ivanov
>>  wrote:
>>
>>> Thank you for review, Chris!
>>>
>>>> src/os/windows/vm/os_windows.cpp:
>>>>
>>>> +   if (buflen > INT_MAX)  n = INT_MAX;
>>>>
>>>> Why do we have this check on Windows?
>>> Since _getcwd requires int on Windows, this is a consequence of
>>> size_t -> int conversion.
>>
>> Got it.
>>
>>>
>>>> src/share/vm/utilities/ostream.hpp:
>>>>
>>>> !   fileStream(FILE* file, bool need_close=false) { _file = file;
>>>> _need_close = need_close; }
>>>>
>>>> Please put spaces before and after "=".
>>> Sure, will do.
>>>
>>>> +        if (pos > 0 &&
>>>> +            Arguments::copy_expand_pid(default_pattern,
>>>> strlen(default_pattern),
>>>> +                                       &buf[pos], buflen-pos)) {
>>>> +          fd = open(buf, O_RDWR | O_CREAT | O_TRUNC, 0666);
>>>> +        }
>>>>
>>>> Could you factor this code into a method?  It's duplicated three times.
>>> Yeah, I don't like it either :-) But I don't think that a function
>>> call will help here. Maybe factoring parameters may help, but I'm not
>>> sure. What do you prefer?
>>
>> Putting Arguments::copy_expand_pid and open calls into a method sounds
>> like a win to me.
>>
>> -- Chris
>>
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>>> Otherwise this looks good.
>>>>
>>>> -- Chris
>>>>
>>>> On Apr 19, 2013, at 10:03 AM, Vladimir Ivanov
>>>>  wrote:
>>>>
>>>>> I need one more "official" review. Any volunteers? :-)
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>>
>>>>> On 4/19/13 7:22 PM, Vladimir Kozlov wrote:
>>>>>> Looks good.
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 4/19/13 7:17 AM, Vladimir Ivanov wrote:
>>>>>>> Updated fix:
>>>>>>> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.02/
>>>>>>>
>>>>>>> Did some additional cleanup: changed get_current_directory to accept
>>>>>>> size_t instead of int as a buffer size.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Vladimir Ivanov
>>>>>>>
>>>>>>> On 4/17/13 8:30 PM, Vladimir Kozlov wrote:
>>>>>>>> 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 vladimir.x.ivanov at oracle.com  Thu Apr 25 11:19:20 2013
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 25 Apr 2013 22:19:20 +0400
Subject: RFR (S): 8012260: ciReplay: Include PID into the name of replay
	data file
In-Reply-To: <51797008.1080007@oracle.com>
References: <516DE649.9020105@oracle.com> <516E3191.4020401@oracle.com>
	<516EBD8A.9090009@oracle.com> <516EC599.5000401@oracle.com>
	<516EC7E2.40401@oracle.com> <516ECE0E.8010006@oracle.com>
	<517151E0.8080909@oracle.com> <5171611B.7000403@oracle.com>
	<517178F5.9030604@oracle.com>
	
	<5171C261.1060207@oracle.com>
	
	<517942C4.1060609@oracle.com> <51797008.1080007@oracle.com>
Message-ID: <517973A8.8040709@oracle.com>

Thank you, Vladimir.

Best regards,
Vladimir Ivanov

On 4/25/13 10:03 PM, Vladimir Kozlov wrote:
> Looks good.
>
> Vladimir K
>
> On 4/25/13 7:50 AM, Vladimir Ivanov wrote:
>> Chris,
>>
>> You were right. Here's updated version:
>> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.03/
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 4/20/13 8:03 AM, Christian Thalinger wrote:
>>>
>>> On Apr 19, 2013, at 3:17 PM, Vladimir Ivanov
>>>  wrote:
>>>
>>>> Thank you for review, Chris!
>>>>
>>>>> src/os/windows/vm/os_windows.cpp:
>>>>>
>>>>> +   if (buflen > INT_MAX)  n = INT_MAX;
>>>>>
>>>>> Why do we have this check on Windows?
>>>> Since _getcwd requires int on Windows, this is a consequence of
>>>> size_t -> int conversion.
>>>
>>> Got it.
>>>
>>>>
>>>>> src/share/vm/utilities/ostream.hpp:
>>>>>
>>>>> !   fileStream(FILE* file, bool need_close=false) { _file = file;
>>>>> _need_close = need_close; }
>>>>>
>>>>> Please put spaces before and after "=".
>>>> Sure, will do.
>>>>
>>>>> +        if (pos > 0 &&
>>>>> +            Arguments::copy_expand_pid(default_pattern,
>>>>> strlen(default_pattern),
>>>>> +                                       &buf[pos], buflen-pos)) {
>>>>> +          fd = open(buf, O_RDWR | O_CREAT | O_TRUNC, 0666);
>>>>> +        }
>>>>>
>>>>> Could you factor this code into a method?  It's duplicated three
>>>>> times.
>>>> Yeah, I don't like it either :-) But I don't think that a function
>>>> call will help here. Maybe factoring parameters may help, but I'm not
>>>> sure. What do you prefer?
>>>
>>> Putting Arguments::copy_expand_pid and open calls into a method sounds
>>> like a win to me.
>>>
>>> -- Chris
>>>
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>>> Otherwise this looks good.
>>>>>
>>>>> -- Chris
>>>>>
>>>>> On Apr 19, 2013, at 10:03 AM, Vladimir Ivanov
>>>>>  wrote:
>>>>>
>>>>>> I need one more "official" review. Any volunteers? :-)
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Best regards,
>>>>>> Vladimir Ivanov
>>>>>>
>>>>>> On 4/19/13 7:22 PM, Vladimir Kozlov wrote:
>>>>>>> Looks good.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 4/19/13 7:17 AM, Vladimir Ivanov wrote:
>>>>>>>> Updated fix:
>>>>>>>> http://cr.openjdk.java.net/~vlivanov/8012260/webrev.02/
>>>>>>>>
>>>>>>>> Did some additional cleanup: changed get_current_directory to
>>>>>>>> accept
>>>>>>>> size_t instead of int as a buffer size.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Vladimir Ivanov
>>>>>>>>
>>>>>>>> On 4/17/13 8:30 PM, Vladimir Kozlov wrote:
>>>>>>>>> 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 vladimir.kozlov at oracle.com  Thu Apr 25 11:20:21 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 25 Apr 2013 11:20:21 -0700
Subject: RFR (S/M): 8012547: Reclamation of flushed methods can be slow
In-Reply-To: <51793812.1020803@oracle.com>
References: <516FF08A.2080808@oracle.com> <5177E6FE.5010503@oracle.com>
	<5178419A.7080209@oracle.com> <51793812.1020803@oracle.com>
Message-ID: <517973E5.10101@oracle.com>

 >>> * Let sweeper make disconnected methods non_entrant even if we don't
 >>> need flushing any more. Makes us less likely to hit a new flush.
 >>
 >> You removed compilation enabling code in
 >> speculative_disconnect_nmethods() so we need to wait next safepoint to
 >> enable it (in scan_stacks()). Should we do enabling compilation during
 >> sweep may be in an other place when we know that some space is
 >> reclaimed to avoid waiting safepoint?
 >
 > Yes, my though was that !CodeCache::needs_flushing() will never be true
 > since this code is only called when we need flushing. And the only place
 > where code cache is actually freed is in scan_stacks when nmethods are
 > flushed. So it should be enough to check for turning on the compiler as
 > the last thing there.

It is not true, it is opposite. scan_stack() only marks nmethods. 
nmethod::flash() (which frees space) is called only from 
NMethodSweeper::sweep_code_cache().

Thanks,
Vladimir

On 4/25/13 7:05 AM, Nils Eliasson wrote:
>
> On 2013-04-24 22:33, Vladimir Kozlov wrote:
>> Nils,
>>
>> Yes, in general it is better.
>>
>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.04/
>>
>> On 4/24/13 7:06 AM, Nils Eliasson wrote:
>>> Hi again,
>>>
>>> Further testing revealed that not all issues was fully identified.
>>> Flushing could still cause compiles to halt even though compilations was
>>> on, and turning off compilations when the code cache was really full
>>> made the sweeper run much less often, prolonging the problem.
>>>
>>> Change log:
>>> * Fix the comment Christian mentioned, and some other comments too.
>>> * find_and_remove_saved_code renamed to reanimate_saved_code to
>>> distinguish it from remove_saved_code that actually removes it.
>>
>> Please, add comments to those CodeCache methods to describe what they do.
>
> ok - fixed.
>
>>> * dont bail out on need_flushing() in compile_method - that causes us to
>>> stop compiling as soon as we hit CodeCacheFlushingMinimumFreeSpace - and
>>> that wasn't the idea.
>>
>> Then you should not check UseCodeCacheFlushing flag and the comment
>> should be updated.
>
> ok, I removed the flag and the capacity check. When we can hit it -
> compilation should already be turned off. And if it isn't it will be in
> a moment.
>
>>
>>> * New product flag CodeCacheFlushingFraction (defaults to 2)
>>> * _was_full removed. Was a redundant way to say that we stopped
>>> compilations.
>>> * _last_was_full renamed to _last_full_flush_time, to emphasize that it
>>> is the time when we hit the hard limit CodeCacheMinimumSpace and
>>> compilations are stopped
>>> * _was_full_traversal renamed to _last_flush_traversal_id. 'full' means
>>> the hard CodeCacheMinimumFreeSpace limit in all other variable names. 
>>> * introduced _dead_compile_ids that hold a count for the number of
>>> compile ID that have been reclaimed. Gives a more accurate way to flush
>>> the cache.
>>
>> Remove space in "jint       _flush_token;" to align it. Also align
>> comments.
> Fixed
>>
>>> * Simplified scan_stacks
>>>    - restore flush token when min interval has passed
>>>    - start compilations again if flushing is no longer needed
>>> * Speed up sweeper when compilations is turned off. Sweeping is slowed
>>> down when compiler threads are sleeping on the CodeCache lock, and we
>>> want to speed up the reclaim process so that we can turn on compiler
>>> again.
>>> * Let sweeper make disconnected methods non_entrant even if we don't
>>> need flushing any more. Makes us less likely to hit a new flush.
>>
>> You removed compilation enabling code in
>> speculative_disconnect_nmethods() so we need to wait next safepoint to
>> enable it (in scan_stacks()). Should we do enabling compilation during
>> sweep may be in an other place when we know that some space is
>> reclaimed to avoid waiting safepoint?
>
> Yes, my though was that !CodeCache::needs_flushing() will never be true
> since this code is only called when we need flushing. And the only place
> where code cache is actually freed is in scan_stacks when nmethods are
> flushed. So it should be enough to check for turning on the compiler as
> the last thing there.
>
>>
>>> * Refactored NMethodSweeper::handle_full_code_cache
>>>    - flushed and full flushes now uses the same token to synchronize -
>>> otherwise we might get two back-to-back flushes. And that doesn't help
>>> anyone.
>>>    - remove time check - flush_token is restored in scan_stacks where
>>> the time is already checked.
>>> * set _resweep flag when flushing.
>>>
>>> The code is much easier to read now and the behavior should be less
>>> surprising.
>>
>> Is that '/* */' leftover from your debugging?:
>>
>> 238   if (PrintMethodFlushing /*&& Verbose*/) {
>>
> Yes, I forgot to qrefresh my patch before doing the webrev.
>
>> Thanks,
>> Vladimir
>
> New webrev with your and Christians feedback here:
>
> http://cr.openjdk.java.net/~neliasso/8012547/webrev.07
> 
>
> Thanks for all your help!
> //Nils
>>
>>>
>>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.03/
>>> 
>>>
>>> Thanks,
>>> Nils Eliasson
>>>
>>>
>>> On 2013-04-18 15:09, Nils Eliasson wrote:
>>>> 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 unnecessary long time
>>>> sometimes causing unnecessary new flushes.
>>>>
>>>> Also some refactoring
>>>> - remove state variable _do_sweep that was unnecessary. It marked if a
>>>> sweep was active or not, but just a duplicate way of checking if any
>>>> methods are being sweept (nmethodsweeper::current != NULL).
>>>> - rename _rescan to _resweep. When _resweep is set there will be
>>>> another sweep started when the current ends. That sweep will start
>>>> with a scan, but it is not only a scan.
>>>> - rename _advise_to_sweep to _flush_token. Is CASed by the first
>>>> thread that wants to flush and reset by scan_stacks when the flush is
>>>> finished and a proper time has passed.
>>>>
>>>> http://cr.openjdk.java.net/~neliasso/8012547/
>>>> 
>>>> https://jbs.oracle.com/bugs/browse/JDK-8012547
>>>>
>>>> Thanks,
>>>> Nils E.
>>>
>

From vladimir.x.ivanov at oracle.com  Thu Apr 25 23:16:01 2013
From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com)
Date: Fri, 26 Apr 2013 06:16:01 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 3 new changesets
Message-ID: <20130426061608.19575485FC@hg.openjdk.java.net>

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

8012260: ciReplay: Include PID into the name of replay data file
Reviewed-by: kvn, twisti

! 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/ci/ciEnv.cpp
! src/share/vm/ci/ciEnv.hpp
! src/share/vm/ci/ciReplay.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/os.hpp
! src/share/vm/utilities/ostream.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: dc7db03f5aa2
Author:    iignatyev
Date:      2013-04-25 11:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dc7db03f5aa2

8012337: Change Whitebox implementation to make absence of method in Whitebox.class not fatal
Reviewed-by: kvn, vlivanov

! src/share/vm/prims/whitebox.cpp
+ test/sanity/WhiteBox.java

Changeset: 7b23cb975cf2
Author:    iignatyev
Date:      2013-04-25 11:09 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7b23cb975cf2

8011675: adding compilation level to replay data
Reviewed-by: kvn, vlivanov

- agent/doc/c2replay.html
+ agent/doc/cireplay.html
! agent/doc/clhsdb.html
! agent/src/share/classes/sun/jvm/hotspot/ci/ciEnv.java
! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java
! agent/src/share/classes/sun/jvm/hotspot/compiler/CompileTask.java
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciReplay.cpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/vmStructs.cpp
+ test/compiler/ciReplay/TestSA.sh
+ test/compiler/ciReplay/TestVM.sh
+ test/compiler/ciReplay/TestVM_no_comp_level.sh
+ test/compiler/ciReplay/common.sh


From john.coomes at oracle.com  Fri Apr 26 02:35:22 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Apr 2013 09:35:22 +0000
Subject: hg: hsx/hotspot-comp/jaxp: 4 new changesets
Message-ID: <20130426093535.7DDC348610@hg.openjdk.java.net>

Changeset: 10db50a26b39
Author:    joehw
Date:      2013-02-18 11:33 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/10db50a26b39

6657673: Issues with JAXP
Reviewed-by: alanb, lancea, ahgross, mullan

! src/com/sun/org/apache/bcel/internal/classfile/JavaClass.java
! src/com/sun/org/apache/bcel/internal/util/Class2HTML.java
! src/com/sun/org/apache/bcel/internal/util/ClassPath.java
! src/com/sun/org/apache/bcel/internal/util/JavaWrapper.java
+ src/com/sun/org/apache/bcel/internal/util/SecuritySupport.java
! src/com/sun/org/apache/xalan/internal/res/XSLMessages.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_fr.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_it.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_pt_BR.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java
! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_TW.java
! src/com/sun/org/apache/xalan/internal/utils/ObjectFactory.java
! src/com/sun/org/apache/xalan/internal/utils/SecuritySupport.java
! src/com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java
! src/com/sun/org/apache/xalan/internal/xslt/Process.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMsg.java
! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/Util.java
! src/com/sun/org/apache/xalan/internal/xsltc/dom/NodeSortRecord.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java
! src/com/sun/org/apache/xalan/internal/xsltc/runtime/output/WriterOutputBuffer.java
! src/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java
! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java
! src/com/sun/org/apache/xerces/internal/dom/DOMMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java
! src/com/sun/org/apache/xerces/internal/impl/dv/DatatypeException.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_de.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_es.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_fr.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_it.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_ja.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_ko.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_pt_BR.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_sv.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_zh_CN.java
! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_zh_TW.java
! src/com/sun/org/apache/xerces/internal/impl/xpath/regex/RegexParser.java
! src/com/sun/org/apache/xerces/internal/impl/xs/XSMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/jaxp/validation/JAXPValidationMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/util/DatatypeMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/util/SAXMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/util/SecurityManager.java
! src/com/sun/org/apache/xerces/internal/utils/ObjectFactory.java
! src/com/sun/org/apache/xerces/internal/utils/SecuritySupport.java
! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeMessageFormatter.java
! src/com/sun/org/apache/xerces/internal/xpointer/XPointerMessageFormatter.java
! src/com/sun/org/apache/xml/internal/dtm/DTMManager.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ca.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_cs.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_de.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_es.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_fr.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_it.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ja.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ko.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_pt_BR.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_sk.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_sv.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_tr.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_CN.java
! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_TW.java
! src/com/sun/org/apache/xml/internal/res/XMLMessages.java
! src/com/sun/org/apache/xml/internal/resolver/Catalog.java
! src/com/sun/org/apache/xml/internal/resolver/CatalogManager.java
! src/com/sun/org/apache/xml/internal/resolver/Resolver.java
! src/com/sun/org/apache/xml/internal/serialize/SerializerFactory.java
! src/com/sun/org/apache/xml/internal/serializer/Encodings.java
! src/com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java
! src/com/sun/org/apache/xml/internal/serializer/ToStream.java
! src/com/sun/org/apache/xml/internal/serializer/TreeWalker.java
! src/com/sun/org/apache/xml/internal/serializer/utils/Messages.java
! src/com/sun/org/apache/xml/internal/utils/TreeWalker.java
! src/com/sun/org/apache/xml/internal/utils/res/XResourceBundle.java
! src/com/sun/org/apache/xpath/internal/functions/FuncSystemProperty.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_de.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_es.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_fr.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_it.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ja.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ko.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_pt_BR.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_sv.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_zh_CN.java
! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_zh_TW.java
! src/com/sun/org/apache/xpath/internal/res/XPATHMessages.java
! src/com/sun/xml/internal/stream/XMLEntityStorage.java
! src/com/sun/xml/internal/stream/writers/WriterUtility.java
! src/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java
! src/javax/xml/datatype/FactoryFinder.java
! src/javax/xml/parsers/FactoryFinder.java
! src/javax/xml/stream/FactoryFinder.java
! src/javax/xml/transform/FactoryFinder.java
! src/javax/xml/validation/SchemaFactoryFinder.java
! src/javax/xml/xpath/XPathFactoryFinder.java
! src/org/w3c/dom/bootstrap/DOMImplementationRegistry.java
! src/org/xml/sax/helpers/NewInstance.java
! src/org/xml/sax/helpers/ParserAdapter.java
! src/org/xml/sax/helpers/ParserFactory.java
+ src/org/xml/sax/helpers/SecuritySupport.java
! src/org/xml/sax/helpers/XMLReaderFactory.java

Changeset: 3f9817b8b0e0
Author:    chegar
Date:      2013-04-12 10:20 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/3f9817b8b0e0

Merge


Changeset: eddbc8ad2435
Author:    lana
Date:      2013-04-23 09:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/eddbc8ad2435

Merge


Changeset: 7122f7bb0fcc
Author:    katleman
Date:      2013-04-25 09:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/7122f7bb0fcc

Added tag jdk8-b87 for changeset eddbc8ad2435

! .hgtags


From john.coomes at oracle.com  Fri Apr 26 02:34:55 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Apr 2013 09:34:55 +0000
Subject: hg: hsx/hotspot-comp: 6 new changesets
Message-ID: <20130426093455.A15E34860E@hg.openjdk.java.net>

Changeset: 7da551071fe8
Author:    lana
Date:      2013-04-11 19:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/7da551071fe8

Merge

! common/makefiles/Main.gmk

Changeset: b95c5c8ee60a
Author:    jgish
Date:      2013-04-16 13:25 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/b95c5c8ee60a

8011347: JKD-8009824 has broken webrev with some ksh versions
Reviewed-by: mduigou

! make/scripts/webrev.ksh

Changeset: 2600c8d8b619
Author:    lana
Date:      2013-04-17 10:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/2600c8d8b619

Merge


Changeset: 238b28991d66
Author:    lana
Date:      2013-04-17 21:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/238b28991d66

Merge


Changeset: b9415faa7066
Author:    lana
Date:      2013-04-23 09:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/b9415faa7066

Merge


Changeset: c29b583938b1
Author:    katleman
Date:      2013-04-25 09:23 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/rev/c29b583938b1

Added tag jdk8-b87 for changeset b9415faa7066

! .hgtags


From john.coomes at oracle.com  Fri Apr 26 02:35:06 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Apr 2013 09:35:06 +0000
Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b87 for changeset
	f1709874d55a
Message-ID: <20130426093509.9BF294860F@hg.openjdk.java.net>

Changeset: 4e3a881ebb1e
Author:    katleman
Date:      2013-04-25 09:23 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/4e3a881ebb1e

Added tag jdk8-b87 for changeset f1709874d55a

! .hgtags


From john.coomes at oracle.com  Fri Apr 26 02:35:48 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Apr 2013 09:35:48 +0000
Subject: hg: hsx/hotspot-comp/jaxws: 5 new changesets
Message-ID: <20130426093603.1574C48611@hg.openjdk.java.net>

Changeset: 28886cb008bb
Author:    lana
Date:      2013-04-11 19:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/28886cb008bb

Merge


Changeset: ebbd87e3a8b2
Author:    lana
Date:      2013-04-17 10:13 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/ebbd87e3a8b2

Merge


Changeset: 9d251e1ec1eb
Author:    lana
Date:      2013-04-23 09:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/9d251e1ec1eb

Merge


Changeset: 72e03566f0a6
Author:    katleman
Date:      2013-04-23 18:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/72e03566f0a6

8012643: JDK8 b86 source with GPL header errors
Reviewed-by: dholmes, alanb

! src/share/jaxws_classes/com/oracle/webservices/internal/api/EnvelopeStyle.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/EnvelopeStyleFeature.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/Databinding.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/DatabindingFactory.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/DatabindingMode.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/DatabindingModeFeature.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/ExternalMetadataFeature.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/JavaCallInfo.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/WSDLGenerator.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding/WSDLResolver.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/message/BaseDistributedPropertySet.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/message/BasePropertySet.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/message/ContentType.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/message/DistributedPropertySet.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/message/MessageContext.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/message/MessageContextFactory.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/message/PropertySet.java
! src/share/jaxws_classes/com/oracle/webservices/internal/api/message/ReadOnlyPropertyException.java
! src/share/jaxws_classes/com/oracle/webservices/internal/impl/encoding/StreamDecoderImpl.java
! src/share/jaxws_classes/com/oracle/webservices/internal/impl/internalspi/encoding/StreamDecoder.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/ExistingAnnotationsType.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/JavaMethod.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/JavaParam.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/JavaWsdlMappingType.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/ObjectFactory.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/SoapBindingParameterStyle.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/SoapBindingStyle.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/SoapBindingUse.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/Util.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/WebParamMode.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlAction.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlAddressing.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlBindingType.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlFaultAction.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlHandlerChain.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlMTOM.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlOneway.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlRequestWrapper.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlResponseWrapper.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlSOAPBinding.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlServiceMode.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebEndpoint.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebFault.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebMethod.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebParam.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebResult.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebService.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebServiceClient.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebServiceProvider.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/XmlWebServiceRef.java
! src/share/jaxws_classes/com/oracle/xmlns/internal/webservices/jaxws_databinding/package-info.java

Changeset: 24fa5452e5d4
Author:    katleman
Date:      2013-04-25 09:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/24fa5452e5d4

Added tag jdk8-b87 for changeset 72e03566f0a6

! .hgtags


From john.coomes at oracle.com  Fri Apr 26 02:38:29 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Apr 2013 09:38:29 +0000
Subject: hg: hsx/hotspot-comp/jdk: 101 new changesets
Message-ID: <20130426100714.9624848612@hg.openjdk.java.net>

Changeset: b59b1f5a98dd
Author:    bae
Date:      2013-04-15 16:57 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b59b1f5a98dd

8005930: [lcms] ColorConvertOp: Alpha channel is not transferred from source to destination.
Reviewed-by: prr

! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
+ test/sun/java2d/cmm/ColorConvertOp/AlphaTest.java

Changeset: 03ee8c648624
Author:    bae
Date:      2013-04-15 18:10 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/03ee8c648624

8011622: Use lcms as the default color management module in jdk8
Reviewed-by: prr, vadim

! make/sun/cmm/Makefile
! make/sun/cmm/kcms/Makefile
! make/sun/cmm/lcms/Makefile
! makefiles/CompileNativeLibraries.gmk
! makefiles/CopyIntoClasses.gmk
+ src/share/classes/sun/java2d/cmm/CMMServiceProvider.java
! src/share/classes/sun/java2d/cmm/CMSManager.java
! src/share/classes/sun/java2d/cmm/lcms/LCMS.java
+ src/share/classes/sun/java2d/cmm/lcms/LcmsServiceProvider.java
+ src/share/classes/sun/java2d/cmm/lcms/META-INF/services/sun.java2d.cmm.CMMServiceProvider
- src/share/classes/sun/java2d/cmm/lcms/META-INF/services/sun.java2d.cmm.PCMM

Changeset: 271d5bf7d61f
Author:    lana
Date:      2013-04-17 12:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/271d5bf7d61f

Merge

! makefiles/CompileNativeLibraries.gmk
! makefiles/CopyIntoClasses.gmk

Changeset: 0799af4553b5
Author:    lana
Date:      2013-04-17 21:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0799af4553b5

Merge

- src/share/classes/sun/java2d/cmm/lcms/META-INF/services/sun.java2d.cmm.PCMM

Changeset: d241f117ff46
Author:    malenkov
Date:      2013-04-11 19:12 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d241f117ff46

4683761: Incomplete Introspection on nonpublic classes lead to IllegalAccessExceptions
Reviewed-by: alexsch

! src/share/classes/java/beans/Introspector.java
+ test/java/beans/Introspector/Test4683761.java

Changeset: be89273ceb9c
Author:    pchelko
Date:      2013-04-12 14:09 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/be89273ceb9c

8010009: [macosx] Unable type into online word games on MacOSX
Reviewed-by: anthony, dcherepanov

! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java
+ test/java/awt/event/KeyEvent/KeyReleasedInAppletTest/KeyReleasedInAppletTest.html
+ test/java/awt/event/KeyEvent/KeyReleasedInAppletTest/KeyReleasedInAppletTest.java
+ test/java/awt/event/KeyEvent/KeyReleasedInAppletTest/TestApplet.java

Changeset: 4490ef60ecd3
Author:    anthony
Date:      2013-04-12 14:33 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4490ef60ecd3

8010297: Missing isLoggable() checks in logging code
Summary: Add isLoggable() checks
Reviewed-by: anthony, mchung, serb
Contributed-by: Laurent Bourges 

! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java
! src/share/classes/java/awt/DefaultKeyboardFocusManager.java
! src/share/classes/java/awt/EventDispatchThread.java
! src/share/classes/java/awt/KeyboardFocusManager.java
! src/share/classes/java/awt/WaitDispatchSupport.java
! src/share/classes/javax/swing/BufferStrategyPaintManager.java
! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java
! src/share/classes/sun/awt/AWTAutoShutdown.java
! src/share/classes/sun/awt/DebugSettings.java
! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java
! src/share/classes/sun/awt/SunToolkit.java
! src/share/classes/sun/awt/im/InputContext.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java
! src/share/classes/sun/net/www/protocol/http/Negotiator.java
! src/solaris/classes/sun/awt/X11/XAWTXSettings.java
! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java
! src/solaris/classes/sun/awt/X11/XBaseWindow.java
! src/solaris/classes/sun/awt/X11/XComponentPeer.java
! src/solaris/classes/sun/awt/X11/XContentWindow.java
! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java
! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java
! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java
! src/solaris/classes/sun/awt/X11/XEmbedHelper.java
! src/solaris/classes/sun/awt/X11/XEmbedServerTester.java
! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java
! src/solaris/classes/sun/awt/X11/XFramePeer.java
! src/solaris/classes/sun/awt/X11/XIconWindow.java
! src/solaris/classes/sun/awt/X11/XInputMethod.java
! src/solaris/classes/sun/awt/X11/XListPeer.java
! src/solaris/classes/sun/awt/X11/XMSelection.java
! src/solaris/classes/sun/awt/X11/XMenuBarPeer.java
! src/solaris/classes/sun/awt/X11/XMenuPeer.java
! src/solaris/classes/sun/awt/X11/XNETProtocol.java
! src/solaris/classes/sun/awt/X11/XPopupMenuPeer.java
! src/solaris/classes/sun/awt/X11/XProtocol.java
! src/solaris/classes/sun/awt/X11/XScrollbar.java
! src/solaris/classes/sun/awt/X11/XScrollbarPeer.java
! src/solaris/classes/sun/awt/X11/XSystemTrayPeer.java
! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java
! src/solaris/classes/sun/awt/X11/XToolkit.java
! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java
! src/solaris/classes/sun/awt/X11/XWINProtocol.java
! src/solaris/classes/sun/awt/X11/XWM.java
! src/solaris/classes/sun/awt/X11/XWindow.java
! src/solaris/classes/sun/awt/X11/XWindowPeer.java
! src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java
! src/solaris/classes/sun/awt/X11InputMethod.java
! src/windows/classes/sun/awt/windows/WComponentPeer.java

Changeset: 39ce1056694d
Author:    serb
Date:      2013-04-12 15:28 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/39ce1056694d

8000629: [macosx] Blurry rendering with Java 7 on Retina display
Reviewed-by: anthony, prr, flar

! src/macosx/classes/sun/awt/CGraphicsDevice.java
! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java
! src/macosx/classes/sun/java2d/opengl/CGLLayer.java
! src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java
! src/macosx/classes/sun/lwawt/LWComponentPeer.java
! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/CGraphicsDevice.m
! src/macosx/native/sun/java2d/opengl/CGLLayer.m
! src/share/classes/sun/awt/image/SurfaceManager.java
! src/share/classes/sun/java2d/SunGraphics2D.java
! src/share/classes/sun/java2d/SurfaceData.java
! src/share/classes/sun/java2d/pipe/BufferedContext.java
! src/share/classes/sun/java2d/pipe/DrawImage.java
! src/share/classes/sun/java2d/pipe/Region.java
+ test/java/awt/Graphics2D/FillTexturePaint/FillTexturePaint.java
+ test/java/awt/Graphics2D/FlipDrawImage/FlipDrawImage.java
+ test/java/awt/Graphics2D/TransformSetGet/TransformSetGet.java
+ test/java/awt/image/DrawImage/IncorrectBounds.java
+ test/java/awt/image/DrawImage/IncorrectOffset.java

Changeset: ffd45b1a9c11
Author:    serb
Date:      2013-04-12 20:39 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ffd45b1a9c11

8004866: [macosx] HiDPI support in Aqua L&F
Reviewed-by: swingler, alexsch

! src/macosx/classes/com/apple/laf/AquaPainter.java
! src/macosx/classes/com/apple/laf/ImageCache.java
! src/macosx/native/com/apple/laf/JRSUIController.m

Changeset: dcdf8cd4b09e
Author:    ant
Date:      2013-04-15 13:02 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/dcdf8cd4b09e

7147075: JTextField doesn't get focus or loses focus forever
Reviewed-by: anthony

! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java

Changeset: 8fbe247ad2d8
Author:    lana
Date:      2013-04-17 11:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8fbe247ad2d8

Merge

! src/share/classes/sun/java2d/SunGraphics2D.java
! src/share/classes/sun/java2d/pipe/BufferedContext.java
! src/solaris/classes/sun/awt/X11/XComponentPeer.java

Changeset: bb098a221d85
Author:    lana
Date:      2013-04-17 21:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bb098a221d85

Merge


Changeset: 863da64214e8
Author:    mduigou
Date:      2013-04-10 14:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/863da64214e8

8010948: Add conversion functional interfaces
Reviewed-by: mduigou, dholmes
Contributed-by: Brian Goetz 

+ src/share/classes/java/util/function/DoubleToIntFunction.java
+ src/share/classes/java/util/function/DoubleToLongFunction.java
+ src/share/classes/java/util/function/IntToDoubleFunction.java
+ src/share/classes/java/util/function/IntToLongFunction.java
+ src/share/classes/java/util/function/LongToDoubleFunction.java
+ src/share/classes/java/util/function/LongToIntFunction.java

Changeset: b0458dd21ba6
Author:    darcy
Date:      2013-04-10 16:38 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b0458dd21ba6

8011930: Long.parseLong(String, int) has inaccurate limit on radix for using 'L'
Reviewed-by: smarks

! src/share/classes/java/lang/Long.java

Changeset: 6f8e1428f7c3
Author:    weijun
Date:      2013-04-11 10:58 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6f8e1428f7c3

8005460: [findbugs] Probably returned array should be cloned
Reviewed-by: xuelei

! src/share/classes/sun/security/krb5/PrincipalName.java
+ test/sun/security/krb5/name/Immutable.java

Changeset: 0ab22e58d151
Author:    weijun
Date:      2013-04-11 11:09 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0ab22e58d151

8011867: Accept unknown PKCS #9 attributes
Reviewed-by: vinnie

! src/share/classes/sun/security/pkcs/PKCS9Attribute.java
+ test/sun/security/pkcs/pkcs9/UnknownAttribute.java

Changeset: 1c3fff140324
Author:    weijun
Date:      2013-04-11 11:10 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1c3fff140324

8011745: Unknown CertificateChoices
Reviewed-by: vinnie

! src/share/classes/sun/security/pkcs/PKCS7.java

Changeset: 006a7a576fe9
Author:    peytoia
Date:      2013-04-11 12:22 +0900
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/006a7a576fe9

8009638: Wrong comment for PL in LocaleISOData, 1989 forward Poland is Republic of Poland
Reviewed-by: okutsu

! src/share/classes/java/util/LocaleISOData.java

Changeset: e62a707a77d8
Author:    lana
Date:      2013-04-11 19:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e62a707a77d8

Merge


Changeset: f4d50e8cc9e2
Author:    sherman
Date:      2013-04-12 07:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f4d50e8cc9e2

8011172: JSR 310 DateTime API Updates II
Summary: Integration of JSR310 Date/Time API update
Reviewed-by: alanb, naoto, dholmes
Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, masayoshi.okutsu at oracle.com

! make/java/java/Makefile
! make/java/text/base/FILES_java.gmk
! make/java/util/FILES_java.gmk
! make/sun/text/FILES_java.gmk
! make/sun/tzdb/Makefile
! make/tools/src/build/tools/cldrconverter/AbstractLDMLHandler.java
! make/tools/src/build/tools/cldrconverter/Bundle.java
! make/tools/src/build/tools/cldrconverter/CLDRConverter.java
! make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java
! make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java
! makefiles/CopyFiles.gmk
! makefiles/CreateJars.gmk
! makefiles/GendataTZDB.gmk
! makefiles/profile-includes.txt
! src/share/classes/java/time/DayOfWeek.java
! src/share/classes/java/time/Duration.java
! src/share/classes/java/time/Instant.java
! src/share/classes/java/time/LocalDate.java
! src/share/classes/java/time/LocalDateTime.java
! src/share/classes/java/time/LocalTime.java
! src/share/classes/java/time/Month.java
! src/share/classes/java/time/MonthDay.java
! src/share/classes/java/time/OffsetDateTime.java
! src/share/classes/java/time/OffsetTime.java
! src/share/classes/java/time/Period.java
! src/share/classes/java/time/Year.java
! src/share/classes/java/time/YearMonth.java
! src/share/classes/java/time/ZoneId.java
! src/share/classes/java/time/ZoneOffset.java
! src/share/classes/java/time/ZoneRegion.java
! src/share/classes/java/time/ZonedDateTime.java
! src/share/classes/java/time/chrono/ChronoDateImpl.java
! src/share/classes/java/time/chrono/ChronoLocalDate.java
! src/share/classes/java/time/chrono/ChronoLocalDateTime.java
! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java
! src/share/classes/java/time/chrono/ChronoZonedDateTime.java
! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java
! src/share/classes/java/time/chrono/Chronology.java
! src/share/classes/java/time/chrono/Era.java
! src/share/classes/java/time/chrono/HijrahChronology.java
! src/share/classes/java/time/chrono/HijrahDate.java
- src/share/classes/java/time/chrono/HijrahDeviationReader.java
! src/share/classes/java/time/chrono/HijrahEra.java
! src/share/classes/java/time/chrono/IsoChronology.java
! src/share/classes/java/time/chrono/IsoEra.java
! src/share/classes/java/time/chrono/JapaneseChronology.java
! src/share/classes/java/time/chrono/JapaneseDate.java
! src/share/classes/java/time/chrono/JapaneseEra.java
! src/share/classes/java/time/chrono/MinguoChronology.java
! src/share/classes/java/time/chrono/MinguoDate.java
! src/share/classes/java/time/chrono/MinguoEra.java
! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java
! src/share/classes/java/time/chrono/ThaiBuddhistDate.java
! src/share/classes/java/time/chrono/ThaiBuddhistEra.java
- src/share/classes/java/time/format/DateTimeBuilder.java
- src/share/classes/java/time/format/DateTimeFormatStyleProvider.java
! src/share/classes/java/time/format/DateTimeFormatter.java
! src/share/classes/java/time/format/DateTimeFormatterBuilder.java
! src/share/classes/java/time/format/DateTimeParseContext.java
! src/share/classes/java/time/format/DateTimePrintContext.java
! src/share/classes/java/time/format/DateTimeTextProvider.java
+ src/share/classes/java/time/format/Parsed.java
+ src/share/classes/java/time/format/ResolverStyle.java
! src/share/classes/java/time/format/TextStyle.java
- src/share/classes/java/time/temporal/Adjusters.java
! src/share/classes/java/time/temporal/ChronoField.java
! src/share/classes/java/time/temporal/ChronoUnit.java
! src/share/classes/java/time/temporal/IsoFields.java
! src/share/classes/java/time/temporal/JulianFields.java
- src/share/classes/java/time/temporal/Queries.java
! src/share/classes/java/time/temporal/Temporal.java
! src/share/classes/java/time/temporal/TemporalAccessor.java
! src/share/classes/java/time/temporal/TemporalAdjuster.java
+ src/share/classes/java/time/temporal/TemporalAdjusters.java
! src/share/classes/java/time/temporal/TemporalAmount.java
! src/share/classes/java/time/temporal/TemporalField.java
+ src/share/classes/java/time/temporal/TemporalQueries.java
! src/share/classes/java/time/temporal/TemporalQuery.java
! src/share/classes/java/time/temporal/TemporalUnit.java
+ src/share/classes/java/time/temporal/UnsupportedTemporalTypeException.java
! src/share/classes/java/time/temporal/ValueRange.java
! src/share/classes/java/time/temporal/WeekFields.java
! src/share/classes/java/time/temporal/package-info.java
! src/share/classes/java/time/zone/TzdbZoneRulesProvider.java
! src/share/classes/java/time/zone/ZoneOffsetTransition.java
! src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java
! src/share/classes/java/time/zone/ZoneRulesProvider.java
! src/share/classes/java/util/Formatter.java
! src/share/classes/java/util/GregorianCalendar.java
! src/share/classes/java/util/TimeZone.java
! src/share/classes/sun/text/resources/FormatData.java
+ src/share/classes/sun/text/resources/JavaTimeSupplementary.java
! src/share/classes/sun/text/resources/ar/FormatData_ar.java
! src/share/classes/sun/text/resources/ar/FormatData_ar_JO.java
! src/share/classes/sun/text/resources/ar/FormatData_ar_LB.java
! src/share/classes/sun/text/resources/ar/FormatData_ar_SY.java
+ src/share/classes/sun/text/resources/ar/JavaTimeSupplementary_ar.java
! src/share/classes/sun/text/resources/be/FormatData_be.java
! src/share/classes/sun/text/resources/be/FormatData_be_BY.java
+ src/share/classes/sun/text/resources/be/JavaTimeSupplementary_be.java
! src/share/classes/sun/text/resources/bg/FormatData_bg.java
! src/share/classes/sun/text/resources/bg/FormatData_bg_BG.java
+ src/share/classes/sun/text/resources/bg/JavaTimeSupplementary_bg.java
! src/share/classes/sun/text/resources/ca/FormatData_ca.java
! src/share/classes/sun/text/resources/ca/FormatData_ca_ES.java
+ src/share/classes/sun/text/resources/ca/JavaTimeSupplementary_ca.java
! src/share/classes/sun/text/resources/cs/FormatData_cs.java
! src/share/classes/sun/text/resources/cs/FormatData_cs_CZ.java
+ src/share/classes/sun/text/resources/cs/JavaTimeSupplementary_cs.java
! src/share/classes/sun/text/resources/da/FormatData_da.java
! src/share/classes/sun/text/resources/da/FormatData_da_DK.java
+ src/share/classes/sun/text/resources/da/JavaTimeSupplementary_da.java
! src/share/classes/sun/text/resources/de/FormatData_de.java
! src/share/classes/sun/text/resources/de/FormatData_de_AT.java
! src/share/classes/sun/text/resources/de/FormatData_de_CH.java
! src/share/classes/sun/text/resources/de/FormatData_de_DE.java
! src/share/classes/sun/text/resources/de/FormatData_de_LU.java
+ src/share/classes/sun/text/resources/de/JavaTimeSupplementary_de.java
! src/share/classes/sun/text/resources/el/FormatData_el.java
! src/share/classes/sun/text/resources/el/FormatData_el_CY.java
! src/share/classes/sun/text/resources/el/FormatData_el_GR.java
+ src/share/classes/sun/text/resources/el/JavaTimeSupplementary_el.java
! src/share/classes/sun/text/resources/en/FormatData_en.java
! src/share/classes/sun/text/resources/en/FormatData_en_AU.java
! src/share/classes/sun/text/resources/en/FormatData_en_CA.java
! src/share/classes/sun/text/resources/en/FormatData_en_GB.java
! src/share/classes/sun/text/resources/en/FormatData_en_IE.java
! src/share/classes/sun/text/resources/en/FormatData_en_IN.java
! src/share/classes/sun/text/resources/en/FormatData_en_MT.java
! src/share/classes/sun/text/resources/en/FormatData_en_NZ.java
! src/share/classes/sun/text/resources/en/FormatData_en_PH.java
! src/share/classes/sun/text/resources/en/FormatData_en_SG.java
! src/share/classes/sun/text/resources/en/FormatData_en_US.java
! src/share/classes/sun/text/resources/en/FormatData_en_ZA.java
+ src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en.java
+ src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en_GB.java
+ src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en_SG.java
! src/share/classes/sun/text/resources/es/FormatData_es.java
! src/share/classes/sun/text/resources/es/FormatData_es_AR.java
! src/share/classes/sun/text/resources/es/FormatData_es_BO.java
! src/share/classes/sun/text/resources/es/FormatData_es_CL.java
! src/share/classes/sun/text/resources/es/FormatData_es_CO.java
! src/share/classes/sun/text/resources/es/FormatData_es_CR.java
! src/share/classes/sun/text/resources/es/FormatData_es_DO.java
! src/share/classes/sun/text/resources/es/FormatData_es_EC.java
! src/share/classes/sun/text/resources/es/FormatData_es_ES.java
! src/share/classes/sun/text/resources/es/FormatData_es_GT.java
! src/share/classes/sun/text/resources/es/FormatData_es_HN.java
! src/share/classes/sun/text/resources/es/FormatData_es_MX.java
! src/share/classes/sun/text/resources/es/FormatData_es_NI.java
! src/share/classes/sun/text/resources/es/FormatData_es_PA.java
! src/share/classes/sun/text/resources/es/FormatData_es_PE.java
! src/share/classes/sun/text/resources/es/FormatData_es_PR.java
! src/share/classes/sun/text/resources/es/FormatData_es_PY.java
! src/share/classes/sun/text/resources/es/FormatData_es_SV.java
! src/share/classes/sun/text/resources/es/FormatData_es_US.java
! src/share/classes/sun/text/resources/es/FormatData_es_UY.java
! src/share/classes/sun/text/resources/es/FormatData_es_VE.java
+ src/share/classes/sun/text/resources/es/JavaTimeSupplementary_es.java
! src/share/classes/sun/text/resources/et/FormatData_et.java
! src/share/classes/sun/text/resources/et/FormatData_et_EE.java
+ src/share/classes/sun/text/resources/et/JavaTimeSupplementary_et.java
! src/share/classes/sun/text/resources/fi/FormatData_fi.java
! src/share/classes/sun/text/resources/fi/FormatData_fi_FI.java
+ src/share/classes/sun/text/resources/fi/JavaTimeSupplementary_fi.java
! src/share/classes/sun/text/resources/fr/FormatData_fr.java
! src/share/classes/sun/text/resources/fr/FormatData_fr_BE.java
! src/share/classes/sun/text/resources/fr/FormatData_fr_CA.java
! src/share/classes/sun/text/resources/fr/FormatData_fr_CH.java
! src/share/classes/sun/text/resources/fr/FormatData_fr_FR.java
+ src/share/classes/sun/text/resources/fr/JavaTimeSupplementary_fr.java
! src/share/classes/sun/text/resources/ga/FormatData_ga.java
! src/share/classes/sun/text/resources/ga/FormatData_ga_IE.java
+ src/share/classes/sun/text/resources/ga/JavaTimeSupplementary_ga.java
! src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java
+ src/share/classes/sun/text/resources/hi/JavaTimeSupplementary_hi_IN.java
! src/share/classes/sun/text/resources/hr/FormatData_hr.java
! src/share/classes/sun/text/resources/hr/FormatData_hr_HR.java
+ src/share/classes/sun/text/resources/hr/JavaTimeSupplementary_hr.java
! src/share/classes/sun/text/resources/hu/FormatData_hu.java
! src/share/classes/sun/text/resources/hu/FormatData_hu_HU.java
+ src/share/classes/sun/text/resources/hu/JavaTimeSupplementary_hu.java
! src/share/classes/sun/text/resources/in/FormatData_in.java
! src/share/classes/sun/text/resources/in/FormatData_in_ID.java
! src/share/classes/sun/text/resources/is/FormatData_is.java
! src/share/classes/sun/text/resources/is/FormatData_is_IS.java
+ src/share/classes/sun/text/resources/is/JavaTimeSupplementary_is.java
! src/share/classes/sun/text/resources/it/FormatData_it.java
! src/share/classes/sun/text/resources/it/FormatData_it_CH.java
! src/share/classes/sun/text/resources/it/FormatData_it_IT.java
+ src/share/classes/sun/text/resources/it/JavaTimeSupplementary_it.java
! src/share/classes/sun/text/resources/iw/FormatData_iw.java
! src/share/classes/sun/text/resources/iw/FormatData_iw_IL.java
+ src/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw.java
+ src/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw_IL.java
! src/share/classes/sun/text/resources/ja/FormatData_ja.java
! src/share/classes/sun/text/resources/ja/FormatData_ja_JP.java
+ src/share/classes/sun/text/resources/ja/JavaTimeSupplementary_ja.java
! src/share/classes/sun/text/resources/ko/FormatData_ko.java
! src/share/classes/sun/text/resources/ko/FormatData_ko_KR.java
+ src/share/classes/sun/text/resources/ko/JavaTimeSupplementary_ko.java
! src/share/classes/sun/text/resources/lt/FormatData_lt.java
! src/share/classes/sun/text/resources/lt/FormatData_lt_LT.java
+ src/share/classes/sun/text/resources/lt/JavaTimeSupplementary_lt.java
! src/share/classes/sun/text/resources/lv/FormatData_lv.java
! src/share/classes/sun/text/resources/lv/FormatData_lv_LV.java
+ src/share/classes/sun/text/resources/lv/JavaTimeSupplementary_lv.java
! src/share/classes/sun/text/resources/mk/FormatData_mk.java
! src/share/classes/sun/text/resources/mk/FormatData_mk_MK.java
+ src/share/classes/sun/text/resources/mk/JavaTimeSupplementary_mk.java
! src/share/classes/sun/text/resources/ms/FormatData_ms.java
! src/share/classes/sun/text/resources/ms/FormatData_ms_MY.java
+ src/share/classes/sun/text/resources/ms/JavaTimeSupplementary_ms.java
! src/share/classes/sun/text/resources/mt/FormatData_mt.java
! src/share/classes/sun/text/resources/mt/FormatData_mt_MT.java
+ src/share/classes/sun/text/resources/mt/JavaTimeSupplementary_mt.java
! src/share/classes/sun/text/resources/nl/FormatData_nl.java
! src/share/classes/sun/text/resources/nl/FormatData_nl_BE.java
! src/share/classes/sun/text/resources/nl/FormatData_nl_NL.java
+ src/share/classes/sun/text/resources/nl/JavaTimeSupplementary_nl.java
! src/share/classes/sun/text/resources/no/FormatData_no.java
! src/share/classes/sun/text/resources/no/FormatData_no_NO.java
! src/share/classes/sun/text/resources/no/FormatData_no_NO_NY.java
+ src/share/classes/sun/text/resources/no/JavaTimeSupplementary_no.java
! src/share/classes/sun/text/resources/pl/FormatData_pl.java
! src/share/classes/sun/text/resources/pl/FormatData_pl_PL.java
+ src/share/classes/sun/text/resources/pl/JavaTimeSupplementary_pl.java
! src/share/classes/sun/text/resources/pt/FormatData_pt.java
! src/share/classes/sun/text/resources/pt/FormatData_pt_BR.java
! src/share/classes/sun/text/resources/pt/FormatData_pt_PT.java
+ src/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt.java
+ src/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt_PT.java
! src/share/classes/sun/text/resources/ro/FormatData_ro.java
! src/share/classes/sun/text/resources/ro/FormatData_ro_RO.java
+ src/share/classes/sun/text/resources/ro/JavaTimeSupplementary_ro.java
! src/share/classes/sun/text/resources/ru/FormatData_ru.java
! src/share/classes/sun/text/resources/ru/FormatData_ru_RU.java
+ src/share/classes/sun/text/resources/ru/JavaTimeSupplementary_ru.java
! src/share/classes/sun/text/resources/sk/FormatData_sk.java
! src/share/classes/sun/text/resources/sk/FormatData_sk_SK.java
+ src/share/classes/sun/text/resources/sk/JavaTimeSupplementary_sk.java
! src/share/classes/sun/text/resources/sl/FormatData_sl.java
! src/share/classes/sun/text/resources/sl/FormatData_sl_SI.java
+ src/share/classes/sun/text/resources/sl/JavaTimeSupplementary_sl.java
! src/share/classes/sun/text/resources/sq/FormatData_sq.java
! src/share/classes/sun/text/resources/sq/FormatData_sq_AL.java
+ src/share/classes/sun/text/resources/sq/JavaTimeSupplementary_sq.java
! src/share/classes/sun/text/resources/sr/FormatData_sr.java
! src/share/classes/sun/text/resources/sr/FormatData_sr_BA.java
! src/share/classes/sun/text/resources/sr/FormatData_sr_CS.java
! src/share/classes/sun/text/resources/sr/FormatData_sr_Latn.java
! src/share/classes/sun/text/resources/sr/FormatData_sr_Latn_ME.java
! src/share/classes/sun/text/resources/sr/FormatData_sr_ME.java
! src/share/classes/sun/text/resources/sr/FormatData_sr_RS.java
+ src/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr.java
+ src/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr_Latn.java
! src/share/classes/sun/text/resources/sv/FormatData_sv.java
! src/share/classes/sun/text/resources/sv/FormatData_sv_SE.java
+ src/share/classes/sun/text/resources/sv/JavaTimeSupplementary_sv.java
! src/share/classes/sun/text/resources/th/FormatData_th.java
! src/share/classes/sun/text/resources/th/FormatData_th_TH.java
+ src/share/classes/sun/text/resources/th/JavaTimeSupplementary_th.java
! src/share/classes/sun/text/resources/tr/FormatData_tr.java
! src/share/classes/sun/text/resources/tr/FormatData_tr_TR.java
+ src/share/classes/sun/text/resources/tr/JavaTimeSupplementary_tr.java
! src/share/classes/sun/text/resources/uk/FormatData_uk.java
! src/share/classes/sun/text/resources/uk/FormatData_uk_UA.java
+ src/share/classes/sun/text/resources/uk/JavaTimeSupplementary_uk.java
! src/share/classes/sun/text/resources/vi/FormatData_vi.java
! src/share/classes/sun/text/resources/vi/FormatData_vi_VN.java
+ src/share/classes/sun/text/resources/vi/JavaTimeSupplementary_vi.java
! src/share/classes/sun/text/resources/zh/FormatData_zh.java
! src/share/classes/sun/text/resources/zh/FormatData_zh_CN.java
! src/share/classes/sun/text/resources/zh/FormatData_zh_HK.java
! src/share/classes/sun/text/resources/zh/FormatData_zh_SG.java
! src/share/classes/sun/text/resources/zh/FormatData_zh_TW.java
+ src/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh.java
+ src/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh_TW.java
! src/share/classes/sun/util/calendar/ZoneInfo.java
! src/share/classes/sun/util/calendar/ZoneInfoFile.java
! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java
! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/LocaleResources.java
! src/share/classes/sun/util/resources/LocaleData.java
! src/share/classes/sun/util/resources/OpenListResourceBundle.java
+ src/share/classes/sun/util/resources/ParallelListResourceBundle.java
! src/share/lib/calendars.properties
+ src/share/lib/hijrah-config-umalqura.properties
! test/java/time/tck/java/time/AbstractDateTimeTest.java
! test/java/time/tck/java/time/TCKClock.java
! test/java/time/tck/java/time/TCKDayOfWeek.java
! test/java/time/tck/java/time/TCKDuration.java
! test/java/time/tck/java/time/TCKInstant.java
! test/java/time/tck/java/time/TCKLocalDate.java
! test/java/time/tck/java/time/TCKLocalDateTime.java
! test/java/time/tck/java/time/TCKLocalTime.java
! test/java/time/tck/java/time/TCKMonth.java
! test/java/time/tck/java/time/TCKMonthDay.java
! test/java/time/tck/java/time/TCKOffsetDateTime.java
! test/java/time/tck/java/time/TCKOffsetTime.java
! test/java/time/tck/java/time/TCKPeriod.java
! test/java/time/tck/java/time/TCKYear.java
! test/java/time/tck/java/time/TCKYearMonth.java
! test/java/time/tck/java/time/TCKZoneId.java
! test/java/time/tck/java/time/TCKZoneOffset.java
! test/java/time/tck/java/time/TCKZonedDateTime.java
- test/java/time/tck/java/time/TestChronology.java
! test/java/time/tck/java/time/TestIsoChronology.java
! test/java/time/tck/java/time/chrono/CopticChronology.java
! test/java/time/tck/java/time/chrono/CopticDate.java
! test/java/time/tck/java/time/chrono/CopticEra.java
+ test/java/time/tck/java/time/chrono/TCKChronoLocalDate.java
+ test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java
+ test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java
! test/java/time/tck/java/time/chrono/TCKChronology.java
+ test/java/time/tck/java/time/chrono/TCKChronologySerialization.java
+ test/java/time/tck/java/time/chrono/TCKHijrahChronology.java
+ test/java/time/tck/java/time/chrono/TCKHijrahEra.java
+ test/java/time/tck/java/time/chrono/TCKIsoChronology.java
+ test/java/time/tck/java/time/chrono/TCKIsoEra.java
+ test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java
+ test/java/time/tck/java/time/chrono/TCKJapaneseEra.java
+ test/java/time/tck/java/time/chrono/TCKMinguoChronology.java
+ test/java/time/tck/java/time/chrono/TCKMinguoEra.java
! test/java/time/tck/java/time/chrono/TCKTestServiceLoader.java
+ test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java
+ test/java/time/tck/java/time/chrono/TCKThaiBuddhistEra.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/chrono/TestHijrahChronology.java
- test/java/time/tck/java/time/chrono/TestJapaneseChronology.java
- test/java/time/tck/java/time/chrono/TestMinguoChronology.java
- test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java
! test/java/time/tck/java/time/format/TCKChronoPrinterParser.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatter.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java
! test/java/time/tck/java/time/format/TCKDateTimeFormatters.java
+ test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java
! test/java/time/tck/java/time/format/TCKDateTimeTextPrinting.java
! test/java/time/tck/java/time/format/TCKLocalizedFieldParser.java
! test/java/time/tck/java/time/format/TCKLocalizedFieldPrinter.java
! test/java/time/tck/java/time/format/TCKLocalizedPrinterParser.java
! test/java/time/tck/java/time/format/TCKOffsetPrinterParser.java
+ test/java/time/tck/java/time/format/TCKTextStyle.java
! test/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java
- test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java
! test/java/time/tck/java/time/temporal/TCKIsoFields.java
! test/java/time/tck/java/time/temporal/TCKJulianFields.java
+ test/java/time/tck/java/time/temporal/TCKTemporalAdjusters.java
! test/java/time/tck/java/time/temporal/TCKWeekFields.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDate.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java
! test/java/time/tck/java/time/zone/TCKFixedZoneRules.java
! test/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java
! test/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java
! test/java/time/tck/java/time/zone/TCKZoneRules.java
! test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java
! test/java/time/test/java/time/MockSimplePeriod.java
! test/java/time/test/java/time/TestClock_System.java
! test/java/time/test/java/time/TestDuration.java
! test/java/time/test/java/time/TestLocalDate.java
! test/java/time/test/java/time/TestLocalDateTime.java
! test/java/time/test/java/time/TestLocalTime.java
! test/java/time/test/java/time/TestMonthDay.java
! test/java/time/test/java/time/TestOffsetDateTime.java
! test/java/time/test/java/time/TestOffsetDateTime_instants.java
! test/java/time/test/java/time/TestPeriod.java
! test/java/time/test/java/time/TestZoneId.java
+ test/java/time/test/java/time/chrono/TestChronoLocalDate.java
+ test/java/time/test/java/time/chrono/TestChronologyPerf.java
! test/java/time/test/java/time/chrono/TestExampleCode.java
! test/java/time/test/java/time/chrono/TestIsoChronoImpl.java
+ test/java/time/test/java/time/chrono/TestJapaneseChronoImpl.java
! test/java/time/test/java/time/chrono/TestServiceLoader.java
+ test/java/time/test/java/time/chrono/TestThaiBuddhistChronoImpl.java
+ test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java
! test/java/time/test/java/time/format/AbstractTestPrinterParser.java
! test/java/time/test/java/time/format/MockIOExceptionAppendable.java
! test/java/time/test/java/time/format/TestCharLiteralParser.java
! test/java/time/test/java/time/format/TestCharLiteralPrinter.java
! test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java
! test/java/time/test/java/time/format/TestDateTimeFormatter.java
! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java
! test/java/time/test/java/time/format/TestDateTimeTextProvider.java
! test/java/time/test/java/time/format/TestFractionPrinterParser.java
! test/java/time/test/java/time/format/TestNonIsoFormatter.java
! test/java/time/test/java/time/format/TestNumberParser.java
! test/java/time/test/java/time/format/TestPadPrinterDecorator.java
! test/java/time/test/java/time/format/TestReducedParser.java
! test/java/time/test/java/time/format/TestReducedPrinter.java
! test/java/time/test/java/time/format/TestSettingsParser.java
! test/java/time/test/java/time/format/TestStringLiteralParser.java
! test/java/time/test/java/time/format/TestStringLiteralPrinter.java
! test/java/time/test/java/time/format/TestTextParser.java
! test/java/time/test/java/time/format/TestTextPrinter.java
! test/java/time/test/java/time/format/TestZoneOffsetParser.java
! test/java/time/test/java/time/format/TestZoneOffsetPrinter.java
! test/java/time/test/java/time/format/TestZoneTextPrinterParser.java
! test/java/time/test/java/time/format/ZoneName.java
! test/java/time/test/java/time/temporal/MockFieldValue.java
+ test/java/time/test/java/time/temporal/TestChronoField.java
! test/java/time/test/java/time/temporal/TestChronoUnit.java
- test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java
! test/java/time/test/java/time/temporal/TestDateTimeBuilderCombinations.java
! test/java/time/test/java/time/temporal/TestDateTimeValueRange.java
- test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java
- test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java
! test/java/time/test/java/time/zone/TestFixedZoneRules.java
! test/java/time/test/java/util/TestFormatter.java
! test/java/util/Calendar/Bug8007038.java
! test/java/util/Calendar/CldrFormatNamesTest.java
! test/java/util/Calendar/JavatimeTest.java
! test/sun/text/resources/LocaleData
! test/sun/util/calendar/zi/TestZoneInfo310.java

Changeset: 035a61c9f981
Author:    sherman
Date:      2013-04-12 09:51 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/035a61c9f981

8012123: hijrah-config-umalqura.properties is missing from makefiles/profile-includes.txt
Summary: added the hijrah-config-umalqura.properties into the list
Reviewed-by: alanb

! makefiles/profile-includes.txt

Changeset: e2cd40d7567c
Author:    rfield
Date:      2013-04-12 10:02 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e2cd40d7567c

8011805: Update sun.tools.java class file reading/writing support to include the new constant pool entries
Reviewed-by: mduigou, alanb

! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/share/classes/sun/tools/java/BinaryConstantPool.java
! src/share/classes/sun/tools/java/RuntimeConstants.java
+ test/sun/tools/java/CFCTest.java

Changeset: 2e3cc7f599ca
Author:    mduigou
Date:      2013-04-10 12:43 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2e3cc7f599ca

8011200: (coll) Optimize empty HashMap and ArrayList
Reviewed-by: mduigou, alanb, bchristi, martin
Contributed-by: Sergey Linetskiy , John Rose , Mike Duigou 

! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/HashMap.java
+ test/java/util/Map/BasicSerialization.java

Changeset: 6c935c5ac7ff
Author:    sherman
Date:      2013-04-12 12:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6c935c5ac7ff

8011647: Add java.time.Instant methods to java.nio.file.attribute.FileTime
Summary: added the toInstant()/from(Instant) to FileTime
Reviewed-by: alanb

! src/share/classes/java/nio/file/attribute/FileTime.java
! test/java/nio/file/attribute/FileTime/Basic.java

Changeset: 729ca1ef7c75
Author:    sherman
Date:      2013-04-12 12:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/729ca1ef7c75

8002390: (zipfs) Problems moving files between zip file systems
Summary: fixed the corner cases in zipfs
Reviewed-by: sherman
Contributed-by: mark.sheppard at oracle.com

! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java
! test/demo/zipfs/ZipFSTester.java
! test/demo/zipfs/basic.sh

Changeset: d8cae0195fe9
Author:    henryjen
Date:      2013-04-12 12:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d8cae0195fe9

8010279: java.util.Stream.min/max((Comparator)null) is not consistent in throwing (unspecified) NPE
Reviewed-by: alanb, mduigou

! src/share/classes/java/util/Comparators.java
+ test/java/util/Comparators/BasicTest.java
- test/java/util/ComparatorsTest.java

Changeset: 06dfdfa8c3e6
Author:    rfield
Date:      2013-04-12 20:23 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/06dfdfa8c3e6

8012028: Metafactory-generated lambda classes should be final
8008941: isSynthetic() returns false for lambda instances
Reviewed-by: mduigou

! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
+ test/java/lang/invoke/lambda/LambdaClassFinal.java
+ test/java/lang/invoke/lambda/LambdaClassSynthetic.java

Changeset: 0111bab8dc35
Author:    jzavgren
Date:      2013-04-11 12:33 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0111bab8dc35

8008118: (process) Possible null pointer dereference in jdk/src/solaris/native/java/lang/UNIXProcess_md.c
Summary: Modified the path processing code so that it detects and handles out of memory errors.
Reviewed-by: chegar, martin, christos, alanb, msheppar
Contributed-by: john.zavgren at oracle.com

! make/java/java/mapfile-vers
! makefiles/mapfiles/libjava/mapfile-vers
! src/solaris/classes/java/lang/UNIXProcess.java.bsd
! src/solaris/classes/java/lang/UNIXProcess.java.linux
! src/solaris/classes/java/lang/UNIXProcess.java.solaris
! src/solaris/native/java/lang/ProcessEnvironment_md.c
! src/solaris/native/java/lang/UNIXProcess_md.c

Changeset: 5c406a747192
Author:    chegar
Date:      2013-04-14 19:17 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5c406a747192

8011799: CompletableFuture/Basic.java fails intermittently
Reviewed-by: martin, alanb

! test/java/util/concurrent/CompletableFuture/Basic.java

Changeset: 4ed143ddbb8a
Author:    martin
Date:      2013-04-15 14:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4ed143ddbb8a

8008509: 6588413 changed JNIEXPORT visibility for GCC on HSX, jdk's jni_md.h needs similar change
Summary: Define JNIEXPORT to use "default" visibility where possible.
Reviewed-by: coleenp, ddehaven, dcubed, anthony

! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h
! src/share/npt/npt.h
! src/solaris/javavm/export/jni_md.h
! src/solaris/native/sun/awt/awt_LoadLibrary.c

Changeset: baaa706d7677
Author:    darcy
Date:      2013-04-15 18:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/baaa706d7677

8011800: Add java.util.Objects.requireNonNull(T, Supplier)
Reviewed-by: alanb, dholmes, mduigou

! src/share/classes/java/util/Objects.java
! test/java/util/Objects/BasicObjectsTest.java

Changeset: 61cfbe08ce5d
Author:    chegar
Date:      2013-04-16 12:23 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/61cfbe08ce5d

8012343: Objects.requireNonNull(Object,Supplier) breaks genstubs build
Reviewed-by: alanb

! src/share/classes/java/util/Objects.java
! test/java/util/Objects/BasicObjectsTest.java

Changeset: e2a0e37b152c
Author:    chegar
Date:      2013-04-16 12:51 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e2a0e37b152c

8012237: CompletableFuture/Basic.java still fails intermittently
Reviewed-by: martin

! test/java/util/concurrent/CompletableFuture/Basic.java

Changeset: 6135c60e77e5
Author:    chegar
Date:      2013-04-16 13:26 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6135c60e77e5

8012244: java/net/Socket/asyncClose/Race.java fails intermittently on Windows
Reviewed-by: alanb, dsamersoff

! src/windows/classes/java/net/DualStackPlainSocketImpl.java
! src/windows/native/java/net/SocketInputStream.c
! test/java/net/Socket/asyncClose/Race.java

Changeset: e4e9f6455f3c
Author:    mduigou
Date:      2013-04-16 11:17 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e4e9f6455f3c

8004518: Add in-place operations to Map
8010122: Add defaults for ConcurrentMap operations to Map
Reviewed-by: darcy, briangoetz, mduigou, dholmes, ulfzibis
Contributed-by: Doug Lea 
, Henry Jen , Akhil Arora , Peter Levart , Mike Duigou 

! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/Hashtable.java
! src/share/classes/java/util/Map.java
! src/share/classes/java/util/concurrent/ConcurrentMap.java
+ test/java/util/Map/Defaults.java

Changeset: c5ead5aa2e13
Author:    bae
Date:      2013-02-07 19:15 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c5ead5aa2e13

8007014: Improve image handling
Reviewed-by: prr, mschoene, jgodinez

! src/share/classes/sun/awt/image/ByteComponentRaster.java
! src/share/classes/sun/awt/image/BytePackedRaster.java
! src/share/classes/sun/awt/image/IntegerComponentRaster.java
! src/share/classes/sun/awt/image/IntegerInterleavedRaster.java
! src/share/classes/sun/awt/image/ShortComponentRaster.java
! src/share/native/sun/awt/image/awt_parseImage.c
! src/share/native/sun/awt/medialib/awt_ImagingLib.c
! src/share/native/sun/awt/medialib/mlib_ImageCreate.c
! src/share/native/sun/awt/medialib/safe_alloc.h
+ src/share/native/sun/awt/medialib/safe_math.h

Changeset: c95973aac928
Author:    malenkov
Date:      2013-02-08 17:32 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c95973aac928

7200507: Refactor Introspector internals
Reviewed-by: ahgross, art

! src/share/classes/java/beans/ThreadGroupContext.java
+ src/share/classes/java/beans/WeakIdentityMap.java

Changeset: 210fb90ee33a
Author:    michaelm
Date:      2013-02-13 10:40 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/210fb90ee33a

8000724: Improve networking serialization
Summary: delegate InetAddress fields to a holder object
Reviewed-by: alanb, chegar

! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java
! src/share/classes/java/net/Inet4Address.java
! src/share/classes/java/net/Inet4AddressImpl.java
! src/share/classes/java/net/Inet6Address.java
! src/share/classes/java/net/Inet6AddressImpl.java
! src/share/classes/java/net/InetAddress.java
! src/share/classes/java/net/InetSocketAddress.java
! src/share/native/java/net/InetAddress.c
! src/share/native/java/net/net_util.c
! src/share/native/java/net/net_util.h
! src/solaris/native/java/net/Inet4AddressImpl.c
! src/solaris/native/java/net/Inet6AddressImpl.c
! src/solaris/native/java/net/NetworkInterface.c
! src/solaris/native/java/net/PlainDatagramSocketImpl.c
! src/solaris/native/java/net/net_util_md.c
! src/windows/classes/java/net/TwoStacksPlainDatagramSocketImpl.java
! src/windows/native/java/net/Inet4AddressImpl.c
! src/windows/native/java/net/Inet6AddressImpl.c
! src/windows/native/java/net/NetworkInterface.c
! src/windows/native/java/net/NetworkInterface.h
! src/windows/native/java/net/NetworkInterface_winXP.c
! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c
! src/windows/native/java/net/TwoStacksPlainSocketImpl.c
! src/windows/native/java/net/net_util_md.c

Changeset: 5ffba58b541f
Author:    valeriep
Date:      2013-02-26 11:12 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5ffba58b541f

8000897: VM crash in CompileBroker
Summary: Fixed to use the corresponding digest length when generating output.
Reviewed-by: mullan

! src/share/classes/sun/security/provider/SHA2.java

Changeset: 96890625ebdf
Author:    smarks
Date:      2013-02-27 14:17 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/96890625ebdf

8001040: Rework RMI model
Reviewed-by: alanb, ahgross, coffeys, dmocek

! src/share/classes/sun/rmi/server/MarshalInputStream.java
! test/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
! test/java/rmi/registry/readTest/readTest.sh
! test/java/rmi/server/RMIClassLoader/downloadArrayClass/DownloadArrayClass.java
! test/java/rmi/server/RMIClassLoader/downloadArrayClass/security.policy
! test/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
+ test/java/rmi/server/RMIClassLoader/useCodebaseOnlyDefault/UseCodebaseOnlyDefault.java
! test/java/rmi/testlibrary/RMID.java

Changeset: f12921c0b15b
Author:    dfuchs
Date:      2013-03-14 13:10 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f12921c0b15b

8001322: Refactor deserialization
Reviewed-by: mchung, skoivu, smarks

! src/share/classes/java/io/ObjectInputStream.java

Changeset: bae4a15265d3
Author:    dmocek
Date:      2013-02-05 16:38 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bae4a15265d3

8001329: Augment RMI logging
Reviewed-by: smarks, hawtin, alanb

! src/share/classes/java/rmi/server/LogStream.java

Changeset: c876e9321616
Author:    chegar
Date:      2012-12-20 13:40 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c876e9321616

8003335: Better handling of Finalizer thread
Reviewed-by: alanb, ahgross

! src/share/classes/java/lang/ref/Finalizer.java

Changeset: 0c5c54303c92
Author:    serb
Date:      2013-02-15 13:49 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0c5c54303c92

8004261: Improve input validation
Reviewed-by: art, mschoene, amenkov

! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java
! src/share/classes/com/sun/media/sound/FastShortMessage.java
! src/share/classes/com/sun/media/sound/FastSysexMessage.java
! src/share/classes/com/sun/media/sound/MidiOutDevice.java
! src/share/classes/com/sun/media/sound/RealTimeSequencer.java

Changeset: 3d155555f809
Author:    uta
Date:      2013-02-22 17:49 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3d155555f809

8005942: (process) Improved Runtime.exec
Reviewed-by: alanb, ahgross

! src/share/classes/java/lang/ProcessBuilder.java
! src/windows/classes/java/lang/ProcessImpl.java

Changeset: cf01f2847551
Author:    dsamersoff
Date:      2013-03-05 00:02 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cf01f2847551

8006435: Improvements in JMX
Summary: Improvements in JMX
Reviewed-by: dfuchs, skoivu, alanb, mchung

! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java

Changeset: 4effe291c08b
Author:    prr
Date:      2013-02-08 09:15 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4effe291c08b

8006795: Improve font warning messages
Reviewed-by: bae, jgodinez

! src/share/classes/sun/font/CMap.java

Changeset: 9b4bee66fa24
Author:    bae
Date:      2013-02-19 11:47 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9b4bee66fa24

8007617: Better validation of images
Reviewed-by: prr, mschoene, jgodinez

! src/share/classes/sun/awt/image/ImageRepresentation.java
! src/share/native/sun/awt/image/awt_ImageRep.c

Changeset: 620a08212c79
Author:    bae
Date:      2013-02-26 00:41 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/620a08212c79

8007667: Better image reading
Reviewed-by: prr, jgodinez, mschoene

! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java
! src/share/native/sun/awt/image/jpeg/imageioJPEG.c

Changeset: 2deab0b85b82
Author:    bae
Date:      2013-02-26 01:41 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2deab0b85b82

8007918: Better image writing
Reviewed-by: mschoene, prr, jgodinez

! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java
! src/share/native/sun/awt/image/jpeg/imageioJPEG.c

Changeset: f7b331b8661f
Author:    chegar
Date:      2013-03-03 10:07 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f7b331b8661f

8009063: Improve reliability of ConcurrentHashMap
Reviewed-by: alanb, ahgross

! src/share/classes/java/util/concurrent/ConcurrentHashMap.java

Changeset: 5c2c8fb0b885
Author:    dfuchs
Date:      2013-03-14 18:41 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5c2c8fb0b885

8009305: Improve AWT data transfer
Reviewed-by: art, skoivu, smarks, ant

! src/share/classes/sun/awt/datatransfer/TransferableProxy.java

Changeset: af881cbec91e
Author:    uta
Date:      2013-03-08 13:35 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/af881cbec91e

8009463: Regression test test\java\lang\Runtime\exec\ArgWithSpaceAndFinalBackslash.java failing.
Reviewed-by: alanb, ahgross

! src/windows/classes/java/lang/ProcessImpl.java

Changeset: 633fd0b99a8d
Author:    valeriep
Date:      2013-03-11 20:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/633fd0b99a8d

8009610: Blacklist certificate used with malware.
Summary: updated the black list and the reg test with the new cert.
Reviewed-by: weijun

! src/share/classes/sun/security/util/UntrustedCertificates.java

Changeset: 37296d45a11e
Author:    lancea
Date:      2013-03-18 13:30 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/37296d45a11e

8009814: Better driver management
Reviewed-by: alanb, skoivu

! src/share/classes/java/sql/DriverManager.java

Changeset: fa919c17da9f
Author:    smarks
Date:      2013-03-18 18:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fa919c17da9f

8009857: Problem with plugin
Reviewed-by: jdn, mchung

! src/share/classes/sun/reflect/misc/MethodUtil.java

Changeset: 4267ae18e13a
Author:    prr
Date:      2013-02-15 13:07 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4267ae18e13a

8008249: Sync ICU into JDK
Reviewed-by: bae, jgodinez

! make/sun/font/FILES_c.gmk
! src/share/native/sun/font/layout/ContextualGlyphInsertion.h
+ src/share/native/sun/font/layout/ContextualGlyphInsertionProc2.cpp
+ src/share/native/sun/font/layout/ContextualGlyphInsertionProc2.h
+ src/share/native/sun/font/layout/ContextualGlyphSubstProc2.cpp
+ src/share/native/sun/font/layout/ContextualGlyphSubstProc2.h
! src/share/native/sun/font/layout/ContextualGlyphSubstitution.h
+ src/share/native/sun/font/layout/GXLayoutEngine2.cpp
+ src/share/native/sun/font/layout/GXLayoutEngine2.h
! src/share/native/sun/font/layout/IndicClassTables.cpp
! src/share/native/sun/font/layout/IndicRearrangement.h
+ src/share/native/sun/font/layout/IndicRearrangementProcessor2.cpp
+ src/share/native/sun/font/layout/IndicRearrangementProcessor2.h
! src/share/native/sun/font/layout/IndicReordering.cpp
! src/share/native/sun/font/layout/IndicReordering.h
! src/share/native/sun/font/layout/LEFontInstance.h
! src/share/native/sun/font/layout/LEGlyphFilter.h
! src/share/native/sun/font/layout/LEInsertionList.h
! src/share/native/sun/font/layout/LEScripts.h
! src/share/native/sun/font/layout/LETypes.h
! src/share/native/sun/font/layout/LayoutEngine.cpp
! src/share/native/sun/font/layout/LayoutEngine.h
+ src/share/native/sun/font/layout/LigatureSubstProc2.cpp
+ src/share/native/sun/font/layout/LigatureSubstProc2.h
! src/share/native/sun/font/layout/LigatureSubstitution.h
! src/share/native/sun/font/layout/LookupProcessor.cpp
! src/share/native/sun/font/layout/MPreFixups.cpp
! src/share/native/sun/font/layout/MorphStateTables.h
! src/share/native/sun/font/layout/MorphTables.h
+ src/share/native/sun/font/layout/MorphTables2.cpp
! src/share/native/sun/font/layout/NonContextualGlyphSubst.h
+ src/share/native/sun/font/layout/NonContextualGlyphSubstProc2.cpp
+ src/share/native/sun/font/layout/NonContextualGlyphSubstProc2.h
! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp
! src/share/native/sun/font/layout/ScriptAndLanguageTags.cpp
! src/share/native/sun/font/layout/ScriptAndLanguageTags.h
+ src/share/native/sun/font/layout/SegmentArrayProcessor2.cpp
+ src/share/native/sun/font/layout/SegmentArrayProcessor2.h
+ src/share/native/sun/font/layout/SegmentSingleProcessor2.cpp
+ src/share/native/sun/font/layout/SegmentSingleProcessor2.h
+ src/share/native/sun/font/layout/SimpleArrayProcessor2.cpp
+ src/share/native/sun/font/layout/SimpleArrayProcessor2.h
+ src/share/native/sun/font/layout/SingleTableProcessor2.cpp
+ src/share/native/sun/font/layout/SingleTableProcessor2.h
+ src/share/native/sun/font/layout/StateTableProcessor2.cpp
+ src/share/native/sun/font/layout/StateTableProcessor2.h
! src/share/native/sun/font/layout/StateTables.h
+ src/share/native/sun/font/layout/SubtableProcessor2.cpp
+ src/share/native/sun/font/layout/SubtableProcessor2.h
+ src/share/native/sun/font/layout/TrimmedArrayProcessor2.cpp
+ src/share/native/sun/font/layout/TrimmedArrayProcessor2.h

Changeset: 43f2d3d715c5
Author:    prr
Date:      2013-02-26 10:07 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/43f2d3d715c5

8004986: Better handling of glyph table
8004987: Improve font layout
8004994: Improve checking of glyph table
Reviewed-by: srl, jgodinez

! src/share/native/sun/font/layout/ArabicLayoutEngine.cpp
! src/share/native/sun/font/layout/ContextualGlyphSubstProc2.cpp
! src/share/native/sun/font/layout/LETypes.h
! src/share/native/sun/font/layout/LayoutEngine.cpp
! src/share/native/sun/font/layout/LigatureSubstProc.cpp
! src/share/native/sun/font/layout/LigatureSubstProc2.cpp
! src/share/native/sun/font/layout/LookupProcessor.cpp
! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp
! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h
! src/share/native/sun/font/layout/StateTableProcessor.cpp
! src/share/native/sun/font/layout/StateTableProcessor2.cpp
! src/share/native/sun/font/layout/StateTables.h

Changeset: 32778f4f945f
Author:    prr
Date:      2013-03-07 10:02 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/32778f4f945f

8001031: Better font processing
Reviewed-by: srl, vadim

! src/share/native/sun/font/FontInstanceAdapter.cpp
! src/share/native/sun/font/FontInstanceAdapter.h
! src/share/native/sun/font/fontscalerdefs.h
! src/share/native/sun/font/layout/AlternateSubstSubtables.cpp
! src/share/native/sun/font/layout/AlternateSubstSubtables.h
! src/share/native/sun/font/layout/ArabicLayoutEngine.cpp
! src/share/native/sun/font/layout/ArabicLayoutEngine.h
! src/share/native/sun/font/layout/ArabicShaping.cpp
! src/share/native/sun/font/layout/ArabicShaping.h
! src/share/native/sun/font/layout/AttachmentPosnSubtables.h
! src/share/native/sun/font/layout/CanonData.cpp
! src/share/native/sun/font/layout/CanonShaping.cpp
! src/share/native/sun/font/layout/CanonShaping.h
! src/share/native/sun/font/layout/ClassDefinitionTables.cpp
! src/share/native/sun/font/layout/ClassDefinitionTables.h
! src/share/native/sun/font/layout/ContextualGlyphInsertionProc2.cpp
! src/share/native/sun/font/layout/ContextualGlyphInsertionProc2.h
! src/share/native/sun/font/layout/ContextualGlyphSubstProc.cpp
! src/share/native/sun/font/layout/ContextualGlyphSubstProc.h
! src/share/native/sun/font/layout/ContextualGlyphSubstProc2.cpp
! src/share/native/sun/font/layout/ContextualGlyphSubstProc2.h
! src/share/native/sun/font/layout/ContextualSubstSubtables.cpp
! src/share/native/sun/font/layout/ContextualSubstSubtables.h
! src/share/native/sun/font/layout/CoverageTables.h
! src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp
! src/share/native/sun/font/layout/CursiveAttachmentSubtables.h
! src/share/native/sun/font/layout/DeviceTables.h
! src/share/native/sun/font/layout/ExtensionSubtables.cpp
! src/share/native/sun/font/layout/Features.cpp
! src/share/native/sun/font/layout/GDEFMarkFilter.cpp
! src/share/native/sun/font/layout/GDEFMarkFilter.h
! src/share/native/sun/font/layout/GXLayoutEngine.cpp
! src/share/native/sun/font/layout/GXLayoutEngine.h
! src/share/native/sun/font/layout/GXLayoutEngine2.cpp
! src/share/native/sun/font/layout/GXLayoutEngine2.h
! src/share/native/sun/font/layout/GlyphDefinitionTables.cpp
! src/share/native/sun/font/layout/GlyphDefinitionTables.h
! src/share/native/sun/font/layout/GlyphIterator.cpp
! src/share/native/sun/font/layout/GlyphIterator.h
! src/share/native/sun/font/layout/GlyphLookupTables.cpp
! src/share/native/sun/font/layout/GlyphLookupTables.h
! src/share/native/sun/font/layout/GlyphPositioningTables.cpp
! src/share/native/sun/font/layout/GlyphPositioningTables.h
! src/share/native/sun/font/layout/GlyphPosnLookupProc.cpp
! src/share/native/sun/font/layout/GlyphPosnLookupProc.h
! src/share/native/sun/font/layout/GlyphSubstLookupProc.cpp
! src/share/native/sun/font/layout/GlyphSubstLookupProc.h
! src/share/native/sun/font/layout/GlyphSubstitutionTables.cpp
! src/share/native/sun/font/layout/GlyphSubstitutionTables.h
! src/share/native/sun/font/layout/HanLayoutEngine.cpp
! src/share/native/sun/font/layout/HanLayoutEngine.h
! src/share/native/sun/font/layout/HangulLayoutEngine.cpp
! src/share/native/sun/font/layout/HangulLayoutEngine.h
! src/share/native/sun/font/layout/ICUFeatures.h
! src/share/native/sun/font/layout/IndicLayoutEngine.cpp
! src/share/native/sun/font/layout/IndicLayoutEngine.h
! src/share/native/sun/font/layout/IndicRearrangementProcessor.cpp
! src/share/native/sun/font/layout/IndicRearrangementProcessor.h
! src/share/native/sun/font/layout/IndicRearrangementProcessor2.cpp
! src/share/native/sun/font/layout/IndicRearrangementProcessor2.h
! src/share/native/sun/font/layout/IndicReordering.cpp
! src/share/native/sun/font/layout/KernTable.cpp
! src/share/native/sun/font/layout/KernTable.h
! src/share/native/sun/font/layout/KhmerLayoutEngine.cpp
! src/share/native/sun/font/layout/KhmerLayoutEngine.h
! src/share/native/sun/font/layout/LEScripts.h
+ src/share/native/sun/font/layout/LETableReference.h
! src/share/native/sun/font/layout/LETypes.h
! src/share/native/sun/font/layout/LayoutEngine.cpp
! src/share/native/sun/font/layout/LayoutEngine.h
! src/share/native/sun/font/layout/LigatureSubstProc.cpp
! src/share/native/sun/font/layout/LigatureSubstProc.h
! src/share/native/sun/font/layout/LigatureSubstProc2.cpp
! src/share/native/sun/font/layout/LigatureSubstProc2.h
! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp
! src/share/native/sun/font/layout/LigatureSubstSubtables.h
! src/share/native/sun/font/layout/LookupProcessor.cpp
! src/share/native/sun/font/layout/LookupProcessor.h
! src/share/native/sun/font/layout/LookupTables.cpp
! src/share/native/sun/font/layout/LookupTables.h
! src/share/native/sun/font/layout/Lookups.cpp
! src/share/native/sun/font/layout/Lookups.h
! src/share/native/sun/font/layout/MarkArrays.h
! src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp
! src/share/native/sun/font/layout/MarkToBasePosnSubtables.h
! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.cpp
! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.h
! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.cpp
! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.h
! src/share/native/sun/font/layout/MorphTables.cpp
! src/share/native/sun/font/layout/MorphTables.h
! src/share/native/sun/font/layout/MorphTables2.cpp
! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp
! src/share/native/sun/font/layout/MultipleSubstSubtables.h
! src/share/native/sun/font/layout/NonContextualGlyphSubstProc.cpp
! src/share/native/sun/font/layout/NonContextualGlyphSubstProc.h
! src/share/native/sun/font/layout/NonContextualGlyphSubstProc2.cpp
! src/share/native/sun/font/layout/NonContextualGlyphSubstProc2.h
! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp
! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h
! src/share/native/sun/font/layout/OpenTypeTables.h
! src/share/native/sun/font/layout/OpenTypeUtilities.cpp
! src/share/native/sun/font/layout/OpenTypeUtilities.h
! src/share/native/sun/font/layout/PairPositioningSubtables.cpp
! src/share/native/sun/font/layout/PairPositioningSubtables.h
! src/share/native/sun/font/layout/ScriptAndLanguage.cpp
! src/share/native/sun/font/layout/ScriptAndLanguage.h
! src/share/native/sun/font/layout/SegmentArrayProcessor.cpp
! src/share/native/sun/font/layout/SegmentArrayProcessor.h
! src/share/native/sun/font/layout/SegmentArrayProcessor2.cpp
! src/share/native/sun/font/layout/SegmentArrayProcessor2.h
! src/share/native/sun/font/layout/SegmentSingleProcessor.cpp
! src/share/native/sun/font/layout/SegmentSingleProcessor.h
! src/share/native/sun/font/layout/SegmentSingleProcessor2.cpp
! src/share/native/sun/font/layout/SegmentSingleProcessor2.h
! src/share/native/sun/font/layout/ShapingTypeData.cpp
! src/share/native/sun/font/layout/SimpleArrayProcessor.cpp
! src/share/native/sun/font/layout/SimpleArrayProcessor.h
! src/share/native/sun/font/layout/SimpleArrayProcessor2.cpp
! src/share/native/sun/font/layout/SimpleArrayProcessor2.h
! src/share/native/sun/font/layout/SinglePositioningSubtables.cpp
! src/share/native/sun/font/layout/SinglePositioningSubtables.h
! src/share/native/sun/font/layout/SingleSubstitutionSubtables.cpp
! src/share/native/sun/font/layout/SingleSubstitutionSubtables.h
! src/share/native/sun/font/layout/SingleTableProcessor.cpp
! src/share/native/sun/font/layout/SingleTableProcessor.h
! src/share/native/sun/font/layout/SingleTableProcessor2.cpp
! src/share/native/sun/font/layout/SingleTableProcessor2.h
! src/share/native/sun/font/layout/StateTableProcessor.cpp
! src/share/native/sun/font/layout/StateTableProcessor.h
! src/share/native/sun/font/layout/StateTableProcessor2.cpp
! src/share/native/sun/font/layout/StateTableProcessor2.h
! src/share/native/sun/font/layout/StateTables.h
! src/share/native/sun/font/layout/SubtableProcessor.cpp
! src/share/native/sun/font/layout/SubtableProcessor.h
! src/share/native/sun/font/layout/SubtableProcessor2.cpp
! src/share/native/sun/font/layout/SubtableProcessor2.h
! src/share/native/sun/font/layout/ThaiLayoutEngine.cpp
! src/share/native/sun/font/layout/TibetanLayoutEngine.cpp
! src/share/native/sun/font/layout/TibetanLayoutEngine.h
! src/share/native/sun/font/layout/TrimmedArrayProcessor.cpp
! src/share/native/sun/font/layout/TrimmedArrayProcessor.h
! src/share/native/sun/font/layout/TrimmedArrayProcessor2.cpp
! src/share/native/sun/font/layout/TrimmedArrayProcessor2.h
! src/share/native/sun/font/layout/ValueRecords.h
! src/share/native/sun/font/sunFont.c

Changeset: 7b03efca912f
Author:    malenkov
Date:      2013-02-05 20:07 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7b03efca912f

8006790: Improve checking for windows
Reviewed-by: art, mschoene

! src/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/macosx/classes/sun/lwawt/macosx/CFileDialog.java
! src/macosx/classes/sun/lwawt/macosx/CPrinterDialogPeer.java
! src/share/classes/java/awt/Window.java
! src/share/classes/java/awt/peer/WindowPeer.java
! src/share/classes/sun/awt/EmbeddedFrame.java
! src/solaris/classes/sun/awt/X11/XWindowPeer.java
! src/windows/classes/sun/awt/windows/WFileDialogPeer.java
! src/windows/classes/sun/awt/windows/WPrintDialogPeer.java
! src/windows/classes/sun/awt/windows/WWindowPeer.java

Changeset: 4ea6d44a20a0
Author:    mullan
Date:      2013-03-27 10:37 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4ea6d44a20a0

8003445: Adjust JAX-WS to focus on API
Reviewed-by: vinnie, ahgross, mgrebac

! 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
! test/Makefile

Changeset: c921d68edf08
Author:    joehw
Date:      2013-02-18 13:02 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c921d68edf08

6657673: Issues with JAXP
Reviewed-by: alanb, lancea, ahgross, mullan

! 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
! test/Makefile

Changeset: 6a09e4648cfb
Author:    mkos
Date:      2013-03-07 07:19 -0500
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6a09e4648cfb

8005432: Update access to JAX-WS
Summary: newly restricted the whole package com.sun.xml.internal; fix reviewed also by Alexander Fomin
Reviewed-by: mullan, skoivu

! 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: 12ca12303c33
Author:    raginip
Date:      2013-03-27 21:32 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/12ca12303c33

8007406: Improve accessibility of AccessBridge
Reviewed-by: skoivu, mullan, ptbrunet

! src/share/lib/security/java.security-windows

Changeset: 269b7955a885
Author:    chegar
Date:      2013-03-28 09:50 +0000
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/269b7955a885

8010944: Incorrectly separated package list in java.security-windows
Reviewed-by: mullan

! src/share/lib/security/java.security-windows

Changeset: 7c663f528ff6
Author:    vlivanov
Date:      2013-03-01 04:45 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7c663f528ff6

8008140: Better method handle resolution
Reviewed-by: jrose, twisti, jdn

! src/share/classes/java/lang/invoke/MethodHandles.java

Changeset: 0fb15205acb6
Author:    bae
Date:      2013-02-19 12:06 +0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0fb15205acb6

8007675: Improve color conversion
Reviewed-by: prr, mschoene, jgodinez

! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java

Changeset: b057eaf53935
Author:    chegar
Date:      2013-04-04 17:34 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b057eaf53935

Merge

! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java

Changeset: 5f46a666e06d
Author:    chegar
Date:      2013-04-13 20:16 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5f46a666e06d

Merge

! src/share/classes/sun/awt/EmbeddedFrame.java
! 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
! src/windows/classes/java/lang/ProcessImpl.java
! test/Makefile

Changeset: 84df34924f67
Author:    chegar
Date:      2013-04-13 21:51 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/84df34924f67

Merge

- src/share/classes/java/time/chrono/HijrahDeviationReader.java
- src/share/classes/java/time/format/DateTimeBuilder.java
- src/share/classes/java/time/format/DateTimeFormatStyleProvider.java
- src/share/classes/java/time/temporal/Adjusters.java
- src/share/classes/java/time/temporal/Queries.java
- test/java/time/tck/java/time/TestChronology.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/chrono/TestHijrahChronology.java
- test/java/time/tck/java/time/chrono/TestJapaneseChronology.java
- test/java/time/tck/java/time/chrono/TestMinguoChronology.java
- test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java
- test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDate.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java
- test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java
- test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java
- test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java
- test/java/util/ComparatorsTest.java

Changeset: 9246b0fee2f2
Author:    chegar
Date:      2013-04-16 13:30 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9246b0fee2f2

Merge


Changeset: 10fd3b4a77ae
Author:    chegar
Date:      2013-04-16 21:04 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/10fd3b4a77ae

Merge


Changeset: a3cc4b8e217a
Author:    weijun
Date:      2013-04-17 10:15 +0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a3cc4b8e217a

8011124: Make KerberosTime immutable
Reviewed-by: xuelei

! src/share/classes/sun/security/krb5/KrbApReq.java
! src/share/classes/sun/security/krb5/KrbAppMessage.java
! src/share/classes/sun/security/krb5/KrbCred.java
! src/share/classes/sun/security/krb5/KrbTgsReq.java
! src/share/classes/sun/security/krb5/internal/KerberosTime.java
! src/share/classes/sun/security/krb5/internal/KrbCredInfo.java
! src/share/classes/sun/security/krb5/internal/LastReqEntry.java
! src/share/classes/sun/security/krb5/internal/PAEncTSEnc.java
! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java
! test/sun/security/krb5/MicroTime.java

Changeset: da6addef956e
Author:    mchung
Date:      2013-04-16 21:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/da6addef956e

8010117: Annotate jdk caller sensitive methods with @sun.reflect.CallerSensitive
Reviewed-by: jrose, alanb, twisti

! make/java/java/FILES_c.gmk
! make/java/java/mapfile-vers
! make/java/java/reorder-i586
! make/java/java/reorder-sparc
! make/java/java/reorder-sparcv9
! makefiles/mapfiles/libjava/mapfile-vers
! makefiles/mapfiles/libjava/reorder-sparc
! makefiles/mapfiles/libjava/reorder-sparcv9
! makefiles/mapfiles/libjava/reorder-x86
! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/ClassLoader.java
! src/share/classes/java/lang/Package.java
! src/share/classes/java/lang/Runtime.java
! src/share/classes/java/lang/SecurityManager.java
! src/share/classes/java/lang/System.java
! src/share/classes/java/lang/Thread.java
! src/share/classes/java/lang/invoke/BoundMethodHandle.java
! src/share/classes/java/lang/invoke/MemberName.java
! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/java/lang/invoke/MethodHandleNatives.java
! src/share/classes/java/lang/invoke/MethodHandleProxies.java
! src/share/classes/java/lang/invoke/MethodHandles.java
! src/share/classes/java/lang/reflect/Constructor.java
! src/share/classes/java/lang/reflect/Field.java
! src/share/classes/java/lang/reflect/Method.java
! src/share/classes/java/lang/reflect/Proxy.java
! src/share/classes/java/security/AccessController.java
! src/share/classes/java/sql/DriverManager.java
! src/share/classes/java/util/ResourceBundle.java
! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java
! src/share/classes/java/util/logging/Logger.java
! src/share/classes/javax/script/ScriptEngineManager.java
! src/share/classes/sun/misc/Unsafe.java
+ src/share/classes/sun/reflect/CallerSensitive.java
! src/share/classes/sun/reflect/Reflection.java
! src/share/javavm/export/jvm.h
! src/share/native/java/lang/ClassLoader.c
- src/share/native/java/lang/ResourceBundle.c
! src/share/native/java/lang/SecurityManager.c
! src/share/native/sun/reflect/Reflection.c
! test/Makefile
+ test/sun/reflect/CallerSensitive/CallerSensitiveFinder.java
+ test/sun/reflect/CallerSensitive/MethodFinder.java
+ test/sun/reflect/CallerSensitive/MissingCallerSensitive.java
+ test/sun/reflect/Reflection/GetCallerClass.java
+ test/sun/reflect/Reflection/GetCallerClassTest.java
+ test/sun/reflect/Reflection/GetCallerClassTest.sh

Changeset: 414384c3b3eb
Author:    yhuang
Date:      2013-04-16 22:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/414384c3b3eb

8011977: ISO 4217 Amendment Number 155
Reviewed-by: naoto

! src/share/classes/java/util/CurrencyData.properties
! test/java/util/Currency/tablea1.txt

Changeset: 779ba708fee3
Author:    yhuang
Date:      2013-04-17 01:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/779ba708fee3

Merge

- src/share/native/java/lang/ResourceBundle.c

Changeset: 473ed4b94306
Author:    vinnie
Date:      2013-04-11 17:57 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/473ed4b94306

7171982: Cipher getParameters() throws RuntimeException: Cannot find SunJCE provider
Reviewed-by: vinnie, wetmore
Contributed-by: Tony Scarpino 

! src/share/classes/com/sun/crypto/provider/CipherCore.java
! src/share/classes/com/sun/crypto/provider/CipherWithWrappingSpi.java
! src/share/classes/com/sun/crypto/provider/ConstructKeys.java
! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java
! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java
! src/share/classes/com/sun/crypto/provider/KeyProtector.java
! src/share/classes/com/sun/crypto/provider/PBECipherCore.java
! src/share/classes/com/sun/crypto/provider/PBES1Core.java
! src/share/classes/com/sun/crypto/provider/PBES2Core.java
! src/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java
! src/share/classes/com/sun/crypto/provider/RSACipher.java
! src/share/classes/com/sun/crypto/provider/SealedObjectForKeyProtector.java
! src/share/classes/com/sun/crypto/provider/SunJCE.java
+ test/com/sun/crypto/provider/Cipher/UTIL/SunJCEGetInstance.java

Changeset: a6ca7cd399b2
Author:    vinnie
Date:      2013-04-11 18:00 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a6ca7cd399b2

8001596: Incorrect condition check in PBKDF2KeyImpl.JAVA
Reviewed-by: wetmore
Contributed-by: Tony Scarpino 

! src/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
+ test/com/sun/crypto/provider/Cipher/PBE/NegativeLength.java

Changeset: 747a09471fd9
Author:    erikj
Date:      2013-04-11 14:47 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/747a09471fd9

8011812: JDK-8011278 breaks the old build
Reviewed-by: tbell, wetmore

! make/sun/splashscreen/Makefile

Changeset: 793e0072bfd6
Author:    wetmore
Date:      2013-04-11 17:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/793e0072bfd6

8012056: SunJCEInstance needs to run in it's own vm
Reviewed-by: wetmore
Contributed-by: anthony.scarpino at oracle.com

! test/com/sun/crypto/provider/Cipher/UTIL/SunJCEGetInstance.java

Changeset: d8d037a7569e
Author:    xuelei
Date:      2013-04-11 18:57 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d8d037a7569e

8011680: Re-integrate AEAD implementation of JSSE
Summary: It is a re-merge of JDK-7030966.
Reviewed-by: wetmore

! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java
! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java
! src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java
! src/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java
+ src/share/classes/sun/security/ssl/Authenticator.java
! src/share/classes/sun/security/ssl/CipherBox.java
! src/share/classes/sun/security/ssl/CipherSuite.java
! src/share/classes/sun/security/ssl/EngineInputRecord.java
! src/share/classes/sun/security/ssl/EngineOutputRecord.java
! src/share/classes/sun/security/ssl/EngineWriter.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/ssl/InputRecord.java
! src/share/classes/sun/security/ssl/JsseJce.java
! src/share/classes/sun/security/ssl/MAC.java
! src/share/classes/sun/security/ssl/OutputRecord.java
! src/share/classes/sun/security/ssl/Record.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java
! test/sun/security/ec/TestEC.java
! test/sun/security/pkcs11/fips/CipherTest.java
! test/sun/security/pkcs11/sslecc/CipherTest.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java
+ test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java
! test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java
! test/sun/security/ssl/sanity/interop/CipherTest.java
! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java

Changeset: ea7976ed9bc6
Author:    wetmore
Date:      2013-04-11 19:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ea7976ed9bc6

Merge


Changeset: 0f93bd5cc8d7
Author:    wetmore
Date:      2013-04-11 21:03 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0f93bd5cc8d7

6425477: Better support for generation of high entropy random numbers
Reviewed-by: xuelei, weijun, mullan

! src/share/classes/java/security/SecureRandom.java
! src/share/classes/sun/security/pkcs11/P11SecureRandom.java
! src/share/classes/sun/security/provider/SecureRandom.java
! src/share/classes/sun/security/provider/SeedGenerator.java
! src/share/classes/sun/security/provider/SunEntries.java
! 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
! src/solaris/classes/sun/security/provider/NativePRNG.java
! src/solaris/classes/sun/security/provider/NativeSeedGenerator.java
! src/windows/classes/sun/security/mscapi/PRNG.java
! src/windows/classes/sun/security/provider/NativePRNG.java
! src/windows/classes/sun/security/provider/NativeSeedGenerator.java
+ test/sun/security/provider/SecureRandom/StrongSecureRandom.java
+ test/sun/security/provider/SecureRandom/StrongSeedReader.java

Changeset: 5435f112e5ea
Author:    vinnie
Date:      2013-04-12 10:42 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5435f112e5ea

Merge

- src/share/classes/java/time/chrono/HijrahDeviationReader.java
- src/share/classes/java/time/format/DateTimeBuilder.java
- src/share/classes/java/time/format/DateTimeFormatStyleProvider.java
- src/share/classes/java/time/temporal/Adjusters.java
- src/share/classes/java/time/temporal/Queries.java
- test/java/time/tck/java/time/TestChronology.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/chrono/TestHijrahChronology.java
- test/java/time/tck/java/time/chrono/TestJapaneseChronology.java
- test/java/time/tck/java/time/chrono/TestMinguoChronology.java
- test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java
- test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDate.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java
- test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java
- test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java
- test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java

Changeset: 6f80a6584fb9
Author:    vinnie
Date:      2013-04-16 01:44 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6f80a6584fb9

Merge

- test/java/util/ComparatorsTest.java

Changeset: 29cbb4617c92
Author:    vinnie
Date:      2013-04-16 05:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/29cbb4617c92

Merge


Changeset: 13e18d3ac414
Author:    vinnie
Date:      2013-04-16 05:32 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/13e18d3ac414

Merge


Changeset: f90b7503019f
Author:    vinnie
Date:      2013-04-17 02:53 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f90b7503019f

Merge

! 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
- src/share/native/java/lang/ResourceBundle.c

Changeset: 7ded74ffea36
Author:    alanb
Date:      2013-04-17 16:11 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7ded74ffea36

8012019: (fc) Thread.interrupt triggers hang in FileChannelImpl.pread (win)
Reviewed-by: chegar

! src/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/share/classes/sun/nio/ch/FileChannelImpl.java
! src/share/classes/sun/nio/ch/IOUtil.java
! src/share/classes/sun/nio/ch/NativeDispatcher.java
! src/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java
! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java
! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java
! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java
! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java
+ test/java/nio/channels/FileChannel/InterruptDeadlock.java

Changeset: d9f9040554d6
Author:    mduigou
Date:      2013-04-17 11:39 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d9f9040554d6

8010953: Add primitive summary statistics utils
Reviewed-by: mduigou, dholmes, chegar, darcy
Contributed-by: Brian Goetz 

+ src/share/classes/java/util/DoubleSummaryStatistics.java
+ src/share/classes/java/util/IntSummaryStatistics.java
+ src/share/classes/java/util/LongSummaryStatistics.java

Changeset: 73e3b474125e
Author:    mchung
Date:      2013-04-17 12:04 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/73e3b474125e

8004260: dynamic proxy class should have the same Java language access as the proxy interfaces
Reviewed-by: alanb, jrose, jdn

! src/share/classes/java/lang/reflect/Proxy.java
! src/share/classes/java/lang/reflect/ReflectPermission.java
! src/share/classes/sun/misc/ProxyGenerator.java
! src/share/classes/sun/reflect/annotation/AnnotationParser.java
! src/share/classes/sun/rmi/server/Util.java
! src/share/classes/sun/tracing/ProviderSkeleton.java
+ test/java/lang/reflect/Proxy/nonPublicProxy/NonPublicProxyClass.java
+ test/java/lang/reflect/Proxy/nonPublicProxy/SimpleProxy.java
+ test/java/lang/reflect/Proxy/nonPublicProxy/p/Bar.java
+ test/java/lang/reflect/Proxy/nonPublicProxy/p/Foo.java
! test/java/rmi/server/RMIClassLoader/loadProxyClasses/security.policy

Changeset: 7f9f69729934
Author:    coleenp
Date:      2013-04-17 12:50 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7f9f69729934

8009531: Crash when redefining class with annotated method
Summary: Add code to annotated methods and command line flags to the tests to verify bug above
Reviewed-by: acorn, sspitsyn, dcubed, dholmes, alanb

! test/java/lang/instrument/RedefineMethodWithAnnotations.sh
! test/java/lang/instrument/RedefineMethodWithAnnotationsTarget.java
! test/java/lang/instrument/RedefineMethodWithAnnotationsTarget_2.java

Changeset: 36f9e357b84b
Author:    coleenp
Date:      2013-04-17 15:06 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/36f9e357b84b

Merge


Changeset: a954e407680c
Author:    lana
Date:      2013-04-17 10:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a954e407680c

Merge


Changeset: 17dcb75682b7
Author:    lana
Date:      2013-04-17 12:14 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/17dcb75682b7

Merge


Changeset: 131686bea632
Author:    lana
Date:      2013-04-17 12:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/131686bea632

Merge


Changeset: 674880648db4
Author:    briangoetz
Date:      2013-04-16 13:51 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/674880648db4

8010096: Initial java.util.Spliterator putback
Reviewed-by: mduigou, alanb, chegar, darcy
Contributed-by: Paul Sandoz , Brian Goetz , Doug Lea 


! src/share/classes/com/sun/tools/jdi/EventSetImpl.java
! src/share/classes/java/lang/Iterable.java
! src/share/classes/java/util/Arrays.java
! src/share/classes/java/util/Collection.java
! src/share/classes/java/util/Iterator.java
! src/share/classes/java/util/List.java
+ src/share/classes/java/util/PrimitiveIterator.java
! src/share/classes/java/util/Set.java
! src/share/classes/java/util/SortedSet.java
+ src/share/classes/java/util/Spliterator.java
+ src/share/classes/java/util/Spliterators.java
+ src/share/classes/java/util/Tripwire.java
+ test/java/util/Spliterator/SpliteratorLateBindingFailFastTest.java
+ test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java

Changeset: 4b8e606f8afb
Author:    lana
Date:      2013-04-17 21:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4b8e606f8afb

Merge

! src/macosx/classes/sun/lwawt/LWWindowPeer.java
- src/share/classes/java/time/chrono/HijrahDeviationReader.java
- src/share/classes/java/time/format/DateTimeBuilder.java
- src/share/classes/java/time/format/DateTimeFormatStyleProvider.java
- src/share/classes/java/time/temporal/Adjusters.java
- src/share/classes/java/time/temporal/Queries.java
! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
- src/share/native/java/lang/ResourceBundle.c
! src/solaris/classes/sun/awt/X11/XWindowPeer.java
- test/java/time/tck/java/time/TestChronology.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDate.java
- test/java/time/tck/java/time/chrono/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/chrono/TestHijrahChronology.java
- test/java/time/tck/java/time/chrono/TestJapaneseChronology.java
- test/java/time/tck/java/time/chrono/TestMinguoChronology.java
- test/java/time/tck/java/time/chrono/TestThaiBuddhistChronology.java
- test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDate.java
- test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java
- test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java
- test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java
- test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java
- test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java
- test/java/util/ComparatorsTest.java

Changeset: 10ad4a4330bc
Author:    lana
Date:      2013-04-23 09:28 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/10ad4a4330bc

Merge


Changeset: d5228e624826
Author:    katleman
Date:      2013-04-23 18:25 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d5228e624826

8012643: JDK8 b86 source with GPL header errors
Reviewed-by: dholmes, alanb

! test/java/lang/Runtime/exec/WinCommand.java
! test/java/lang/reflect/Method/DefaultMethodModeling.java

Changeset: 53be90fb39d6
Author:    katleman
Date:      2013-04-25 09:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/53be90fb39d6

Added tag jdk8-b87 for changeset d5228e624826

! .hgtags


From john.coomes at oracle.com  Fri Apr 26 03:13:31 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Apr 2013 10:13:31 +0000
Subject: hg: hsx/hotspot-comp/langtools: 17 new changesets
Message-ID: <20130426101425.C705B48613@hg.openjdk.java.net>

Changeset: eb134c8e931d
Author:    bpatel
Date:      2013-04-09 14:18 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/eb134c8e931d

8005091: javadoc should be able to return the receiver type
Reviewed-by: jjg

! src/share/classes/com/sun/javadoc/ExecutableMemberDoc.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java
! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java
+ test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/ClassExtends.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/ClassParameters.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/Fields.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/MethodReturnType.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/MethodTypeParameters.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/Parameters.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/Receivers.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/Throws.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/TypeParameters.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/Varargs.java
+ test/com/sun/javadoc/testTypeAnnotations/typeannos/Wildcards.java

Changeset: a4be2c2fe0a1
Author:    vromero
Date:      2013-04-10 12:31 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a4be2c2fe0a1

8011432: javac, compiler regression iterable + captured type
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/comp/Lower.java
! test/tools/javac/T5053846/MethodRefDupInConstantPoolTest.java

Changeset: d13af7751456
Author:    lana
Date:      2013-04-11 19:15 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/d13af7751456

Merge


Changeset: 137994c189e5
Author:    jfranck
Date:      2013-04-12 12:05 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/137994c189e5

7015104: use new subtype of TypeSymbol for type parameters
Reviewed-by: jjg, mcimadamore

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! test/tools/javac/scope/7017664/CompoundScopeTest.java
! test/tools/javac/types/TypeHarness.java

Changeset: 76537856a54e
Author:    vromero
Date:      2013-04-13 12:25 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/76537856a54e

8010659: Javac Crashes while building OpenJFX
Reviewed-by: jjg
Contributed-by: maurizio.cimadamore at oracle.com

+ src/share/classes/com/sun/tools/javac/comp/CompileStates.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
+ test/tools/javac/T8010659/CompilerCrashWhenMixingBinariesAndSourcesTest.java
! test/tools/javac/annotations/typeAnnotations/TypeProcOnly.java
! test/tools/javac/annotations/typeAnnotations/packageanno/PackageProcessor.java

Changeset: f10cffab99b4
Author:    bpatel
Date:      2013-04-13 18:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f10cffab99b4

8009686: Generated javadoc documentation should be able to display type annotation on an array
Reviewed-by: jjg

! src/share/classes/com/sun/javadoc/ExecutableMemberDoc.java
! src/share/classes/com/sun/javadoc/Type.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkOutputImpl.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkOutput.java
! src/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java
! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java
! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java
! src/share/classes/com/sun/tools/javadoc/PrimitiveType.java
! src/share/classes/com/sun/tools/javadoc/TypeMaker.java
! test/com/sun/javadoc/testTypeAnnotations/TestTypeAnnotations.java
! test/com/sun/javadoc/testTypeAnnotations/typeannos/Fields.java

Changeset: b26f36a7ae3b
Author:    mcimadamore
Date:      2013-04-15 14:11 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/b26f36a7ae3b

8011383: Symbol.getModifiers omits ACC_ABSTRACT from interface with default methods
Summary: Fixup for default method modifiers erroneously applies to class-level modifiers
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symbol.java
+ test/tools/javac/defaultMethods/DefaultMethodFlags.java

Changeset: c430f1cde21c
Author:    mcimadamore
Date:      2013-04-15 14:12 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/c430f1cde21c

8011377: Javac crashes when multiple lambdas are defined in an array
Summary: Wrong attribution environment used by DeferredAttr
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Flow.java
+ test/tools/javac/lambda/TargetType71.java

Changeset: 083c6b199e2f
Author:    mcimadamore
Date:      2013-04-15 14:15 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/083c6b199e2f

8011376: Spurious checked exception errors in nested method call
Summary: Fallback attribution logic doesn't work properly when lambda throws checked exceptions
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/tools/javac/lambda/TargetType72.java

Changeset: 6dacab087652
Author:    mcimadamore
Date:      2013-04-15 14:16 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/6dacab087652

8011028: lang/INFR/infr001/infr00101md/infr00101md.java fails to compile after switch to JDK8-b82
Summary: Fix bug in Types.removeWildcards
Reviewed-by: jjg

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

Changeset: c2315af9cc28
Author:    mcimadamore
Date:      2013-04-15 14:17 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/c2315af9cc28

8011392: Missing checkcast when casting to intersection type
Summary: javac should emit a checkcast for each additional target type specified in an intersection type cast
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
+ test/tools/javac/lambda/Intersection03.java

Changeset: 950e8ac120f0
Author:    mcimadamore
Date:      2013-04-15 14:18 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/950e8ac120f0

8010923: Avoid redundant speculative attribution
Summary: Add optimization to avoid speculative attribution for certain argument expressions
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java

Changeset: 49d32c84dfea
Author:    vromero
Date:      2013-04-17 11:11 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/49d32c84dfea

8011181: javac, empty UTF8 entry generated for inner class
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
+ test/tools/javac/T8011181/EmptyUTF8ForInnerClassNameTest.java

Changeset: 94870c08391c
Author:    lana
Date:      2013-04-17 10:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/94870c08391c

Merge


Changeset: cad4fc23f691
Author:    lana
Date:      2013-04-17 21:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/cad4fc23f691

Merge


Changeset: 1329f9c38d93
Author:    lana
Date:      2013-04-23 09:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/1329f9c38d93

Merge


Changeset: a1e10f3adc47
Author:    katleman
Date:      2013-04-25 09:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a1e10f3adc47

Added tag jdk8-b87 for changeset 1329f9c38d93

! .hgtags


From john.coomes at oracle.com  Fri Apr 26 03:14:37 2013
From: john.coomes at oracle.com (john.coomes at oracle.com)
Date: Fri, 26 Apr 2013 10:14:37 +0000
Subject: hg: hsx/hotspot-comp/nashorn: 15 new changesets
Message-ID: <20130426101449.34C4548614@hg.openjdk.java.net>

Changeset: 480b90430d29
Author:    lana
Date:      2013-04-11 19:16 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/480b90430d29

Merge


Changeset: 635a93b61d34
Author:    hannesw
Date:      2013-04-10 14:00 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/635a93b61d34

8011714: Regexp decimal escape handling still not correct
Reviewed-by: lagergren, attila

! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/script/basic/JDK-8011714.js
+ test/script/basic/JDK-8011714.js.EXPECTED

Changeset: b4ea8678bf15
Author:    hannesw
Date:      2013-04-10 14:05 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/b4ea8678bf15

8011749: Bugs with empty character class handling
Reviewed-by: lagergren, attila

! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/script/basic/JDK-8011749.js
+ test/script/basic/JDK-8011749.js.EXPECTED

Changeset: 8ae9ed1ac1e2
Author:    hannesw
Date:      2013-04-10 14:08 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/8ae9ed1ac1e2

8011756: Wrong characters supported in RegExp \c escape
Reviewed-by: lagergren, attila

! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/script/basic/JDK-8011756.js
+ test/script/basic/JDK-8011756.js.EXPECTED

Changeset: 571e06d5d23c
Author:    sundar
Date:      2013-04-11 13:20 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/571e06d5d23c

8011960: [2,1].sort(null) should throw TypeError
Reviewed-by: hannesw, lagergren

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

Changeset: 256bb030ce0a
Author:    sundar
Date:      2013-04-11 15:04 +0530
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/256bb030ce0a

8011974: Comparator function returning negative and positive Infinity does not work as expected with Array.prototype.sort
Reviewed-by: hannesw, lagergren

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

Changeset: a3fc89d33072
Author:    hannesw
Date:      2013-04-11 12:16 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/a3fc89d33072

8011980: Allow NUL character in character class
Reviewed-by: sundar, lagergren

! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/script/basic/JDK-8011980.js
+ test/script/basic/JDK-8011980.js.EXPECTED

Changeset: ed4293ceec0e
Author:    hannesw
Date:      2013-04-12 16:31 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/ed4293ceec0e

8011884: Regexp literals are compiled twice
Reviewed-by: lagergren, sundar

! src/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java
! src/jdk/nashorn/internal/runtime/regexp/joni/Regex.java
! src/jdk/nashorn/internal/runtime/regexp/joni/ast/QuantifierNode.java

Changeset: 36e36a2d4312
Author:    hannesw
Date:      2013-04-12 16:32 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/36e36a2d4312

8011885: Switch to Joni as default Regexp engine
Reviewed-by: lagergren, sundar

! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java

Changeset: e70e6b38826b
Author:    jlaskey
Date:      2013-04-15 08:39 -0300
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/e70e6b38826b

Merge


Changeset: 222a72df2f42
Author:    mchung
Date:      2013-04-16 22:11 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/222a72df2f42

8010117: Annotate jdk caller sensitive methods with @sun.reflect.CallerSensitive
Reviewed-by: jrose, alanb, twisti, sundar

! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java
! src/jdk/nashorn/internal/runtime/Context.java

Changeset: 44d8612e29b0
Author:    lana
Date:      2013-04-17 10:31 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/44d8612e29b0

Merge


Changeset: cba329ce5efe
Author:    lana
Date:      2013-04-17 21:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/cba329ce5efe

Merge


Changeset: 774aeaa89bc1
Author:    lana
Date:      2013-04-23 09:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/774aeaa89bc1

Merge


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

Added tag jdk8-b87 for changeset 774aeaa89bc1

! .hgtags


From nils.eliasson at oracle.com  Fri Apr 26 04:23:36 2013
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Fri, 26 Apr 2013 13:23:36 +0200
Subject: RFR (S): 8012157: removed unused code in
	SharedRuntime::handle_wrong_method
In-Reply-To: <5177C037.9030805@oracle.com>
References: <5177BAB7.70905@oracle.com> <5177C037.9030805@oracle.com>
Message-ID: <517A63B8.1080008@oracle.com>

I am sponsoring this change.

//Nils

On 2013-04-24 13:21, Albert Noll wrote:
> Hi,
>
> I just realized that webrev and jbs are mixed up
> Here is the webrev: http://cr.openjdk.java.net/~roland/8012157/webrev.00/
>
> Best,
> Albert
>
> On 04/24/2013 12:57 PM, Albert Noll wrote:
>> Hi all,
>>
>> please review the patch:
>>
>>
>> Problem:
>> unused code in SharedRuntime::handle_wrong_method
>>
>> Fix:
>> removed unused code
>>
>> Testing:
>> JPRT 'compiler'
>>
>> webrev:  https://jbs.oracle.com/bugs/browse/JDK-8012157
>> jbs: http://cr.openjdk.java.net/~roland/8012157/webrev.00/
>>
>> Thanks,
>> Albert
>


From nils.eliasson at oracle.com  Fri Apr 26 04:24:23 2013
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Fri, 26 Apr 2013 13:24:23 +0200
Subject: hg: hsx/hotspot-comp/hotspot: 8010332: remove unused method
	ciMethod::uses_monitors
In-Reply-To: <5178EF4D.6060907@oracle.com>
References: <5177A380.6070002@oracle.com>
	<8A84EA7E-4C35-493F-B0B9-C657A188AAC5@oracle.com>
	<5178EF4D.6060907@oracle.com>
Message-ID: <517A63E7.1020606@oracle.com>

I am sponsoring this change.

//Nils

On 2013-04-25 10:54, Albert Noll wrote:
> On 04/24/2013 09:21 PM, Christian Thalinger wrote:
>> On Apr 24, 2013, at 2:18 AM, Albert Noll > > wrote:
>>
>>> Hi all,
>>>
>>> please review the patch:
>>>
>>>
>>> Problem:
>>> unused method with misleading name
>>>
>>> Fix:
>>> removed unused method
>>
>> The change looks good but are you sure you're not mixing up bugs?
>>
>> -- Chris
>>
> Hi, thanks Chris. Yes, the link points to the wrong bug. Here is the 
> correct link.
>
> https://jbs.oracle.com/bugs/browse/JDK-8010332
>
> Sorry for the confusion,
> Albert
>>>
>>> Testing:
>>> JPRT 'compiler'
>>>
>>> webrev: http://cr.openjdk.java.net/~roland/8010332/webrev.00/ 
>>> 
>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-8010332 
>>> 
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130426/566bf65c/attachment.html 

From nils.eliasson at oracle.com  Fri Apr 26 08:15:34 2013
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Fri, 26 Apr 2013 17:15:34 +0200
Subject: RFR (S/M): 8012547: Reclamation of flushed methods can be slow
In-Reply-To: <517973E5.10101@oracle.com>
References: <516FF08A.2080808@oracle.com> <5177E6FE.5010503@oracle.com>
	<5178419A.7080209@oracle.com> <51793812.1020803@oracle.com>
	<517973E5.10101@oracle.com>
Message-ID: <517A9A16.5000407@oracle.com>


On 2013-04-25 20:20, Vladimir Kozlov wrote:
> >>> * Let sweeper make disconnected methods non_entrant even if we don't
> >>> need flushing any more. Makes us less likely to hit a new flush.
> >>
> >> You removed compilation enabling code in
> >> speculative_disconnect_nmethods() so we need to wait next safepoint to
> >> enable it (in scan_stacks()). Should we do enabling compilation during
> >> sweep may be in an other place when we know that some space is
> >> reclaimed to avoid waiting safepoint?
> >
> > Yes, my though was that !CodeCache::needs_flushing() will never be true
> > since this code is only called when we need flushing. And the only 
> place
> > where code cache is actually freed is in scan_stacks when nmethods are
> > flushed. So it should be enough to check for turning on the compiler as
> > the last thing there.
>
> It is not true, it is opposite. scan_stack() only marks nmethods. 
> nmethod::flash() (which frees space) is called only from 
> NMethodSweeper::sweep_code_cache().

You are right. Confusing myself here. But the rest of my argument still 
stands - flushing is only called when need_flushing() is true, and the 
possibility of it being false a moment later in disconnect methods is 
very low.  But I added a check in the end of the sweep_code_cache that 
can turn the compiler on again.

Also changed the flush_target calculation in 
speculative_disconnect_nmethods slightly. Now it doesn't count natives 
and osrs which might prevent some potentially bad behavior in long 
running applications with lots of osrs. (With CodeCacheFlushFraction=8 
or so, and more than 12.5% osrs, the flushing would stop make progress 
in the very long run)

Latest webrev:

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


Thanks!
//Nils

>
> Thanks,
> Vladimir
>
> On 4/25/13 7:05 AM, Nils Eliasson wrote:
>>
>> On 2013-04-24 22:33, Vladimir Kozlov wrote:
>>> Nils,
>>>
>>> Yes, in general it is better.
>>>
>>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.04/
>>>
>>> On 4/24/13 7:06 AM, Nils Eliasson wrote:
>>>> Hi again,
>>>>
>>>> Further testing revealed that not all issues was fully identified.
>>>> Flushing could still cause compiles to halt even though 
>>>> compilations was
>>>> on, and turning off compilations when the code cache was really full
>>>> made the sweeper run much less often, prolonging the problem.
>>>>
>>>> Change log:
>>>> * Fix the comment Christian mentioned, and some other comments too.
>>>> * find_and_remove_saved_code renamed to reanimate_saved_code to
>>>> distinguish it from remove_saved_code that actually removes it.
>>>
>>> Please, add comments to those CodeCache methods to describe what 
>>> they do.
>>
>> ok - fixed.
>>
>>>> * dont bail out on need_flushing() in compile_method - that causes 
>>>> us to
>>>> stop compiling as soon as we hit CodeCacheFlushingMinimumFreeSpace 
>>>> - and
>>>> that wasn't the idea.
>>>
>>> Then you should not check UseCodeCacheFlushing flag and the comment
>>> should be updated.
>>
>> ok, I removed the flag and the capacity check. When we can hit it -
>> compilation should already be turned off. And if it isn't it will be in
>> a moment.
>>
>>>
>>>> * New product flag CodeCacheFlushingFraction (defaults to 2)
>>>> * _was_full removed. Was a redundant way to say that we stopped
>>>> compilations.
>>>> * _last_was_full renamed to _last_full_flush_time, to emphasize 
>>>> that it
>>>> is the time when we hit the hard limit CodeCacheMinimumSpace and
>>>> compilations are stopped
>>>> * _was_full_traversal renamed to _last_flush_traversal_id. 'full' 
>>>> means
>>>> the hard CodeCacheMinimumFreeSpace limit in all other variable 
>>>> names. 
>>>> * introduced _dead_compile_ids that hold a count for the number of
>>>> compile ID that have been reclaimed. Gives a more accurate way to 
>>>> flush
>>>> the cache.
>>>
>>> Remove space in "jint       _flush_token;" to align it. Also align
>>> comments.
>> Fixed
>>>
>>>> * Simplified scan_stacks
>>>>    - restore flush token when min interval has passed
>>>>    - start compilations again if flushing is no longer needed
>>>> * Speed up sweeper when compilations is turned off. Sweeping is slowed
>>>> down when compiler threads are sleeping on the CodeCache lock, and we
>>>> want to speed up the reclaim process so that we can turn on compiler
>>>> again.
>>>> * Let sweeper make disconnected methods non_entrant even if we don't
>>>> need flushing any more. Makes us less likely to hit a new flush.
>>>
>>> You removed compilation enabling code in
>>> speculative_disconnect_nmethods() so we need to wait next safepoint to
>>> enable it (in scan_stacks()). Should we do enabling compilation during
>>> sweep may be in an other place when we know that some space is
>>> reclaimed to avoid waiting safepoint?
>>
>> Yes, my though was that !CodeCache::needs_flushing() will never be true
>> since this code is only called when we need flushing. And the only place
>> where code cache is actually freed is in scan_stacks when nmethods are
>> flushed. So it should be enough to check for turning on the compiler as
>> the last thing there.
>>
>>>
>>>> * Refactored NMethodSweeper::handle_full_code_cache
>>>>    - flushed and full flushes now uses the same token to synchronize -
>>>> otherwise we might get two back-to-back flushes. And that doesn't help
>>>> anyone.
>>>>    - remove time check - flush_token is restored in scan_stacks where
>>>> the time is already checked.
>>>> * set _resweep flag when flushing.
>>>>
>>>> The code is much easier to read now and the behavior should be less
>>>> surprising.
>>>
>>> Is that '/* */' leftover from your debugging?:
>>>
>>> 238   if (PrintMethodFlushing /*&& Verbose*/) {
>>>
>> Yes, I forgot to qrefresh my patch before doing the webrev.
>>
>>> Thanks,
>>> Vladimir
>>
>> New webrev with your and Christians feedback here:
>>
>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.07
>> 
>>
>> Thanks for all your help!
>> //Nils
>>>
>>>>
>>>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.03/
>>>> 
>>>>
>>>> Thanks,
>>>> Nils Eliasson
>>>>
>>>>
>>>> On 2013-04-18 15:09, Nils Eliasson wrote:
>>>>> 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 unnecessary long time
>>>>> sometimes causing unnecessary new flushes.
>>>>>
>>>>> Also some refactoring
>>>>> - remove state variable _do_sweep that was unnecessary. It marked 
>>>>> if a
>>>>> sweep was active or not, but just a duplicate way of checking if any
>>>>> methods are being sweept (nmethodsweeper::current != NULL).
>>>>> - rename _rescan to _resweep. When _resweep is set there will be
>>>>> another sweep started when the current ends. That sweep will start
>>>>> with a scan, but it is not only a scan.
>>>>> - rename _advise_to_sweep to _flush_token. Is CASed by the first
>>>>> thread that wants to flush and reset by scan_stacks when the flush is
>>>>> finished and a proper time has passed.
>>>>>
>>>>> http://cr.openjdk.java.net/~neliasso/8012547/
>>>>> 
>>>>> https://jbs.oracle.com/bugs/browse/JDK-8012547
>>>>>
>>>>> Thanks,
>>>>> Nils E.
>>>>
>>


From nils.eliasson at oracle.com  Fri Apr 26 08:17:36 2013
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Fri, 26 Apr 2013 17:17:36 +0200
Subject: RFR (S/M): 8012547: Reclamation of flushed methods can be slow
In-Reply-To: <43374FFE-AFA5-41BA-B4D6-5813A7C56DD3@oracle.com>
References: <516FF08A.2080808@oracle.com> <5177E939.1050706@oracle.com>
	<9EA2E0DE-E82E-4A85-8838-C383A2D15D6A@oracle.com>
	<5179382B.5070403@oracle.com>
	<43374FFE-AFA5-41BA-B4D6-5813A7C56DD3@oracle.com>
Message-ID: <517A9A90.8040409@oracle.com>

On 2013-04-25 18:59, Christian Thalinger wrote:
> Since someone has to start with this:  could you please change the method comments you've added to Doxygen-style comments?
>
> -nmethod* CodeCache::find_and_remove_saved_code(Method* m) {
> +// Remove and return nmethod from the saved code list in order to reanimate it.
> +nmethod* CodeCache::reanimate_saved_code(Method* m) {
>
> to:
>
> /**
>   * Remove and return nmethod from the saved code list in order to reanimate it.
>   */
> nmethod* CodeCache::reanimate_saved_code(Method* m) {
>
> Otherwise this looks good.
>
> -- Chris

ok, added that.

New webrev including Kozlovs comments to:

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


Thanks!
//Nils

>
> On Apr 25, 2013, at 7:05 AM, Nils Eliasson  wrote:
>
>>
>> On 2013-04-25 04:37, Christian Thalinger wrote:
>>> On Apr 24, 2013, at 7:16 AM, Nils Eliasson  wrote:
>>>
>>>> This is the correct webrev for the RFR I sent a moment ago:
>>>>
>>>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.04/ 
>>> src/share/vm/runtime/sweeper.cpp:
>>>
>>> +          (_traversals > _last_flush_traversal_id + 2) && ((uint)nm->compile_id() < _highest_marked)) {
>>>
>>> Can't we change _highest_marked to int?  I see that CompileBroker::get_compilation_id() returns an uint.  We should decide if compile ids are int or uint.  I vote for int.
>> Yes. They can only be positive, and 0 is used blobs without ID. But int is the type used in other places so I will change to that and make it a little bit more consistent.
>>
>>> I don't see _dead_compile_ids being ever set.
>> It isn't :P TortoiseHG reverts changes on qrefresh when it thinks the patch is public. Without notice.
>>
>> Fixed.
>>
>> New webrev including your and Vladimirs suggestions:
>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.07 
>>
>> Thanks!
>> //Nils
>>
>>> -- Chris
>>>
>>>> //Nils
>>>>
>>>> On 2013-04-18 15:09, Nils Eliasson wrote:
>>>>> 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 unnecessary long time sometimes causing unnecessary new flushes.
>>>>>
>>>>> Also some refactoring
>>>>> - remove state variable _do_sweep that was unnecessary. It marked if a sweep was active or not, but just a duplicate way of checking if any methods are being sweept (nmethodsweeper::current != NULL).
>>>>> - rename _rescan to _resweep. When _resweep is set there will be another sweep started when the current ends. That sweep will start with a scan, but it is not only a scan.
>>>>> - rename _advise_to_sweep to _flush_token. Is CASed by the first thread that wants to flush and reset by scan_stacks when the flush is finished and a proper time has passed.
>>>>>
>>>>> http://cr.openjdk.java.net/~neliasso/8012547/ 
>>>>> https://jbs.oracle.com/bugs/browse/JDK-8012547
>>>>>
>>>>> Thanks,
>>>>> Nils E.


From nils.eliasson at oracle.com  Fri Apr 26 08:30:02 2013
From: nils.eliasson at oracle.com (nils.eliasson at oracle.com)
Date: Fri, 26 Apr 2013 15:30:02 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets
Message-ID: <20130426153008.327AB48637@hg.openjdk.java.net>

Changeset: 247342108a11
Author:    neliasso
Date:      2013-04-23 13:48 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/247342108a11

8010332: removed unused method: ciMethod::uses_monitors
Reviewed-by: twisti, roland
Contributed-by: albert.noll at oracle.com

! src/share/vm/ci/ciMethod.hpp

Changeset: a5c95fcf7cb7
Author:    neliasso
Date:      2013-04-23 18:06 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a5c95fcf7cb7

8012157: removed unused code in SharedRuntime::handle_wrong_method
Reviewed-by: kvn, roland, rbackman
Contributed-by: albert.noll at oracle.com

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


From vladimir.kozlov at oracle.com  Fri Apr 26 08:34:05 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 26 Apr 2013 08:34:05 -0700
Subject: RFR (S/M): 8012547: Reclamation of flushed methods can be slow
In-Reply-To: <517A9A16.5000407@oracle.com>
References: <516FF08A.2080808@oracle.com> <5177E6FE.5010503@oracle.com>
	<5178419A.7080209@oracle.com> <51793812.1020803@oracle.com>
	<517973E5.10101@oracle.com> <517A9A16.5000407@oracle.com>
Message-ID: <517A9E6D.1010703@oracle.com>

Nils,

You should use CompileBroker::run_compilation instead of 'true':

319     CompileBroker::set_should_compile_new_jobs(true);

Otherwise it looks good.

Thanks,
Vladimir

On 4/26/13 8:15 AM, Nils Eliasson wrote:
>
> On 2013-04-25 20:20, Vladimir Kozlov wrote:
>> >>> * Let sweeper make disconnected methods non_entrant even if we don't
>> >>> need flushing any more. Makes us less likely to hit a new flush.
>> >>
>> >> You removed compilation enabling code in
>> >> speculative_disconnect_nmethods() so we need to wait next safepoint to
>> >> enable it (in scan_stacks()). Should we do enabling compilation during
>> >> sweep may be in an other place when we know that some space is
>> >> reclaimed to avoid waiting safepoint?
>> >
>> > Yes, my though was that !CodeCache::needs_flushing() will never be true
>> > since this code is only called when we need flushing. And the only
>> place
>> > where code cache is actually freed is in scan_stacks when nmethods are
>> > flushed. So it should be enough to check for turning on the compiler as
>> > the last thing there.
>>
>> It is not true, it is opposite. scan_stack() only marks nmethods.
>> nmethod::flash() (which frees space) is called only from
>> NMethodSweeper::sweep_code_cache().
>
> You are right. Confusing myself here. But the rest of my argument still
> stands - flushing is only called when need_flushing() is true, and the
> possibility of it being false a moment later in disconnect methods is
> very low.  But I added a check in the end of the sweep_code_cache that
> can turn the compiler on again.
>
> Also changed the flush_target calculation in
> speculative_disconnect_nmethods slightly. Now it doesn't count natives
> and osrs which might prevent some potentially bad behavior in long
> running applications with lots of osrs. (With CodeCacheFlushFraction=8
> or so, and more than 12.5% osrs, the flushing would stop make progress
> in the very long run)
>
> Latest webrev:
>
> http://cr.openjdk.java.net/~neliasso/8012547/webrev.08/
> 
>
> Thanks!
> //Nils
>
>>
>> Thanks,
>> Vladimir
>>
>> On 4/25/13 7:05 AM, Nils Eliasson wrote:
>>>
>>> On 2013-04-24 22:33, Vladimir Kozlov wrote:
>>>> Nils,
>>>>
>>>> Yes, in general it is better.
>>>>
>>>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.04/
>>>>
>>>> On 4/24/13 7:06 AM, Nils Eliasson wrote:
>>>>> Hi again,
>>>>>
>>>>> Further testing revealed that not all issues was fully identified.
>>>>> Flushing could still cause compiles to halt even though
>>>>> compilations was
>>>>> on, and turning off compilations when the code cache was really full
>>>>> made the sweeper run much less often, prolonging the problem.
>>>>>
>>>>> Change log:
>>>>> * Fix the comment Christian mentioned, and some other comments too.
>>>>> * find_and_remove_saved_code renamed to reanimate_saved_code to
>>>>> distinguish it from remove_saved_code that actually removes it.
>>>>
>>>> Please, add comments to those CodeCache methods to describe what
>>>> they do.
>>>
>>> ok - fixed.
>>>
>>>>> * dont bail out on need_flushing() in compile_method - that causes
>>>>> us to
>>>>> stop compiling as soon as we hit CodeCacheFlushingMinimumFreeSpace
>>>>> - and
>>>>> that wasn't the idea.
>>>>
>>>> Then you should not check UseCodeCacheFlushing flag and the comment
>>>> should be updated.
>>>
>>> ok, I removed the flag and the capacity check. When we can hit it -
>>> compilation should already be turned off. And if it isn't it will be in
>>> a moment.
>>>
>>>>
>>>>> * New product flag CodeCacheFlushingFraction (defaults to 2)
>>>>> * _was_full removed. Was a redundant way to say that we stopped
>>>>> compilations.
>>>>> * _last_was_full renamed to _last_full_flush_time, to emphasize
>>>>> that it
>>>>> is the time when we hit the hard limit CodeCacheMinimumSpace and
>>>>> compilations are stopped
>>>>> * _was_full_traversal renamed to _last_flush_traversal_id. 'full'
>>>>> means
>>>>> the hard CodeCacheMinimumFreeSpace limit in all other variable
>>>>> names. 
>>>>> * introduced _dead_compile_ids that hold a count for the number of
>>>>> compile ID that have been reclaimed. Gives a more accurate way to
>>>>> flush
>>>>> the cache.
>>>>
>>>> Remove space in "jint       _flush_token;" to align it. Also align
>>>> comments.
>>> Fixed
>>>>
>>>>> * Simplified scan_stacks
>>>>>    - restore flush token when min interval has passed
>>>>>    - start compilations again if flushing is no longer needed
>>>>> * Speed up sweeper when compilations is turned off. Sweeping is slowed
>>>>> down when compiler threads are sleeping on the CodeCache lock, and we
>>>>> want to speed up the reclaim process so that we can turn on compiler
>>>>> again.
>>>>> * Let sweeper make disconnected methods non_entrant even if we don't
>>>>> need flushing any more. Makes us less likely to hit a new flush.
>>>>
>>>> You removed compilation enabling code in
>>>> speculative_disconnect_nmethods() so we need to wait next safepoint to
>>>> enable it (in scan_stacks()). Should we do enabling compilation during
>>>> sweep may be in an other place when we know that some space is
>>>> reclaimed to avoid waiting safepoint?
>>>
>>> Yes, my though was that !CodeCache::needs_flushing() will never be true
>>> since this code is only called when we need flushing. And the only place
>>> where code cache is actually freed is in scan_stacks when nmethods are
>>> flushed. So it should be enough to check for turning on the compiler as
>>> the last thing there.
>>>
>>>>
>>>>> * Refactored NMethodSweeper::handle_full_code_cache
>>>>>    - flushed and full flushes now uses the same token to synchronize -
>>>>> otherwise we might get two back-to-back flushes. And that doesn't help
>>>>> anyone.
>>>>>    - remove time check - flush_token is restored in scan_stacks where
>>>>> the time is already checked.
>>>>> * set _resweep flag when flushing.
>>>>>
>>>>> The code is much easier to read now and the behavior should be less
>>>>> surprising.
>>>>
>>>> Is that '/* */' leftover from your debugging?:
>>>>
>>>> 238   if (PrintMethodFlushing /*&& Verbose*/) {
>>>>
>>> Yes, I forgot to qrefresh my patch before doing the webrev.
>>>
>>>> Thanks,
>>>> Vladimir
>>>
>>> New webrev with your and Christians feedback here:
>>>
>>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.07
>>> 
>>>
>>> Thanks for all your help!
>>> //Nils
>>>>
>>>>>
>>>>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.03/
>>>>> 
>>>>>
>>>>> Thanks,
>>>>> Nils Eliasson
>>>>>
>>>>>
>>>>> On 2013-04-18 15:09, Nils Eliasson wrote:
>>>>>> 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 unnecessary long time
>>>>>> sometimes causing unnecessary new flushes.
>>>>>>
>>>>>> Also some refactoring
>>>>>> - remove state variable _do_sweep that was unnecessary. It marked
>>>>>> if a
>>>>>> sweep was active or not, but just a duplicate way of checking if any
>>>>>> methods are being sweept (nmethodsweeper::current != NULL).
>>>>>> - rename _rescan to _resweep. When _resweep is set there will be
>>>>>> another sweep started when the current ends. That sweep will start
>>>>>> with a scan, but it is not only a scan.
>>>>>> - rename _advise_to_sweep to _flush_token. Is CASed by the first
>>>>>> thread that wants to flush and reset by scan_stacks when the flush is
>>>>>> finished and a proper time has passed.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~neliasso/8012547/
>>>>>> 
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8012547
>>>>>>
>>>>>> Thanks,
>>>>>> Nils E.
>>>>>
>>>
>

From vladimir.x.ivanov at oracle.com  Fri Apr 26 11:46:31 2013
From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com)
Date: Fri, 26 Apr 2013 18:46:31 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets
Message-ID: <20130426184636.A0F3E48644@hg.openjdk.java.net>

Changeset: d1c9384eecb4
Author:    iignatyev
Date:      2013-04-26 07:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d1c9384eecb4

8012322: Tiered: CompilationPolicy::can_be_compiled(CompLevel_all) mistakenly return false
Reviewed-by: kvn, vlivanov

! src/share/vm/classfile/classLoader.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! test/compiler/whitebox/CompilerWhiteBoxTest.java
! test/compiler/whitebox/MakeMethodNotCompilableTest.java

Changeset: 93b8272814cf
Author:    vlivanov
Date:      2013-04-26 08:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/93b8272814cf

Merge



From christian.thalinger at oracle.com  Fri Apr 26 12:08:24 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 26 Apr 2013 12:08:24 -0700
Subject: RFR (S/M): 8012547: Reclamation of flushed methods can be slow
In-Reply-To: <517A9A90.8040409@oracle.com>
References: <516FF08A.2080808@oracle.com> <5177E939.1050706@oracle.com>
	<9EA2E0DE-E82E-4A85-8838-C383A2D15D6A@oracle.com>
	<5179382B.5070403@oracle.com>
	<43374FFE-AFA5-41BA-B4D6-5813A7C56DD3@oracle.com>
	<517A9A90.8040409@oracle.com>
Message-ID: 


On Apr 26, 2013, at 8:17 AM, Nils Eliasson  wrote:

> On 2013-04-25 18:59, Christian Thalinger wrote:
>> Since someone has to start with this:  could you please change the method comments you've added to Doxygen-style comments?
>> 
>> -nmethod* CodeCache::find_and_remove_saved_code(Method* m) {
>> +// Remove and return nmethod from the saved code list in order to reanimate it.
>> +nmethod* CodeCache::reanimate_saved_code(Method* m) {
>> 
>> to:
>> 
>> /**
>>  * Remove and return nmethod from the saved code list in order to reanimate it.
>>  */
>> nmethod* CodeCache::reanimate_saved_code(Method* m) {
>> 
>> Otherwise this looks good.
>> 
>> -- Chris
> 
> ok, added that.

Thanks.  There are typos, though:

+ * Remove nmethod from the save code list in order to discard it permanentely

Should be "saved code" and "permanently".

-- Chris

> 
> New webrev including Kozlovs comments to:
> 
> http://cr.openjdk.java.net/~neliasso/8012547/webrev.08/ 
> 
> Thanks!
> //Nils
> 
>> 
>> On Apr 25, 2013, at 7:05 AM, Nils Eliasson  wrote:
>> 
>>> 
>>> On 2013-04-25 04:37, Christian Thalinger wrote:
>>>> On Apr 24, 2013, at 7:16 AM, Nils Eliasson  wrote:
>>>> 
>>>>> This is the correct webrev for the RFR I sent a moment ago:
>>>>> 
>>>>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.04/ 
>>>> src/share/vm/runtime/sweeper.cpp:
>>>> 
>>>> +          (_traversals > _last_flush_traversal_id + 2) && ((uint)nm->compile_id() < _highest_marked)) {
>>>> 
>>>> Can't we change _highest_marked to int?  I see that CompileBroker::get_compilation_id() returns an uint.  We should decide if compile ids are int or uint.  I vote for int.
>>> Yes. They can only be positive, and 0 is used blobs without ID. But int is the type used in other places so I will change to that and make it a little bit more consistent.
>>> 
>>>> I don't see _dead_compile_ids being ever set.
>>> It isn't :P TortoiseHG reverts changes on qrefresh when it thinks the patch is public. Without notice.
>>> 
>>> Fixed.
>>> 
>>> New webrev including your and Vladimirs suggestions:
>>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.07 
>>> 
>>> Thanks!
>>> //Nils
>>> 
>>>> -- Chris
>>>> 
>>>>> //Nils
>>>>> 
>>>>> On 2013-04-18 15:09, Nils Eliasson wrote:
>>>>>> 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 unnecessary long time sometimes causing unnecessary new flushes.
>>>>>> 
>>>>>> Also some refactoring
>>>>>> - remove state variable _do_sweep that was unnecessary. It marked if a sweep was active or not, but just a duplicate way of checking if any methods are being sweept (nmethodsweeper::current != NULL).
>>>>>> - rename _rescan to _resweep. When _resweep is set there will be another sweep started when the current ends. That sweep will start with a scan, but it is not only a scan.
>>>>>> - rename _advise_to_sweep to _flush_token. Is CASed by the first thread that wants to flush and reset by scan_stacks when the flush is finished and a proper time has passed.
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~neliasso/8012547/ 
>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8012547
>>>>>> 
>>>>>> Thanks,
>>>>>> Nils E.
> 


From bharadwaj.yadavalli at oracle.com  Fri Apr 26 14:21:43 2013
From: bharadwaj.yadavalli at oracle.com (bharadwaj.yadavalli at oracle.com)
Date: Fri, 26 Apr 2013 21:21:43 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 25 new changesets
Message-ID: <20130426212231.35D1C4864E@hg.openjdk.java.net>

Changeset: 63e31ce40bdb
Author:    hseigel
Date:      2013-04-17 08:20 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/63e31ce40bdb

8009928: PSR:PERF Increase default string table size
Summary: Increase default string table size to 60013 for 64-bit platforms.
Reviewed-by: coleenp, dholmes

! src/share/vm/runtime/arguments.cpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: b80cc96882f7
Author:    zgu
Date:      2013-04-18 10:04 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b80cc96882f7

8012464: NMT: classes should not derive from _ValueObj, use VALUE_OBJ_CLASS_SPEC instead
Summary: NMT value objects should use VALUE_OBJ_CLASS_SPEC instead of deriving from _ValueObj
Reviewed-by: coleenp, hseigel, dholmes

! src/share/vm/services/memBaseline.hpp
! src/share/vm/services/memPtr.hpp
! src/share/vm/services/memSnapshot.hpp
! src/share/vm/services/memTrackWorker.hpp

Changeset: 41ed397cc0cd
Author:    bharadwaj
Date:      2013-04-18 08:05 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/41ed397cc0cd

8006267: InterfaceMethod_ref should allow invokestatic and invokespecial
Summary: Lambda changes; spec 0.6.2 - Allow static invokestatic and invokespecial calls to InterfaceMethod_ref
Reviewed-by: dholmes, acorn

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/genericSignatures.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/prims/methodHandles.cpp

Changeset: 7815eaceaa8c
Author:    bharadwaj
Date:      2013-04-18 14:03 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7815eaceaa8c

Merge


Changeset: 6f817ce50129
Author:    minqi
Date:      2013-04-19 11:08 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6f817ce50129

8010992: Remove calls to global ::operator new[] and new
Summary: disable use of global operator new and new[] which could cause unexpected exception and escape from NMT tracking.
Reviewed-by: coleenp, dholmes, zgu
Contributed-by: yumin.qi at oracle.com

! src/os/windows/vm/os_windows.cpp
! src/share/vm/classfile/altHashing.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/memory/cardTableModRefBS.hpp
! src/share/vm/memory/cardTableRS.cpp
! src/share/vm/memory/cardTableRS.hpp
! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/opto/idealGraphPrinter.hpp
! src/share/vm/runtime/handles.hpp
! src/share/vm/runtime/reflectionUtils.hpp
! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/events.hpp
! src/share/vm/utilities/quickSort.cpp
! src/share/vm/utilities/workgroup.cpp
! src/share/vm/utilities/workgroup.hpp

Changeset: 17c51f84773a
Author:    dcubed
Date:      2013-04-19 13:48 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/17c51f84773a

Merge


Changeset: 5b6512efcdc4
Author:    dcubed
Date:      2013-04-19 16:51 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5b6512efcdc4

Merge

- make/bsd/makefiles/jvmg.make
- make/bsd/makefiles/profiled.make
- make/linux/makefiles/jvmg.make
- make/linux/makefiles/profiled.make
- make/solaris/makefiles/jvmg.make
- make/solaris/makefiles/profiled.make
- 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/os/windows/vm/os_windows.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 6337ca4dcad8
Author:    sspitsyn
Date:      2013-04-20 04:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6337ca4dcad8

8008511: JSR 292: MemberName vmtarget refs to methods must be updated at class redefinition
Summary: Lazily create and maintain the MemberNameTable to be able to update MemberName's
Reviewed-by: coleenp, jrose, dholmes
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/mutexLocker.hpp

Changeset: a527ddd44e07
Author:    mgronlun
Date:      2013-04-20 19:02 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a527ddd44e07

6729929: I18N - Taking Heap Dump failed if project path contains multibyte characters
Reviewed-by: dholmes, rbackman
Contributed-by: peter.allwin at oracle.com

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

Changeset: 5a9fa2ba85f0
Author:    dcubed
Date:      2013-04-21 20:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5a9fa2ba85f0

8012907: anti-delta fix for 8010992
Summary: anti-delta fix for 8010992 until 8012902 can be fixed
Reviewed-by: acorn, minqi, rdurbin

! src/os/windows/vm/os_windows.cpp
! src/share/vm/classfile/altHashing.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/memory/cardTableModRefBS.hpp
! src/share/vm/memory/cardTableRS.cpp
! src/share/vm/memory/cardTableRS.hpp
! src/share/vm/memory/collectorPolicy.cpp
! src/share/vm/opto/idealGraphPrinter.hpp
! src/share/vm/runtime/handles.hpp
! src/share/vm/runtime/reflectionUtils.hpp
! src/share/vm/runtime/synchronizer.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/events.hpp
! src/share/vm/utilities/quickSort.cpp
! src/share/vm/utilities/workgroup.cpp
! src/share/vm/utilities/workgroup.hpp

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

Merge

! src/os/windows/vm/os_windows.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: ce6d7e43501c
Author:    bharadwaj
Date:      2013-04-23 08:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ce6d7e43501c

8012961: Do not restrict static interface methods to be private
Summary: Lambda changes; spec 0.6.2 - remove the restriction that was added as part of recent changes made to support upcoming changes to compilation of lambda methods.
Reviewed-by: dholmes, acorn

! src/share/vm/prims/methodHandles.cpp

Changeset: 1ea6a35dcbe5
Author:    jiangli
Date:      2013-04-23 12:32 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1ea6a35dcbe5

8012927: 'assert(nbits == 32 || (-(1 << nbits-1) <= x && x < ( 1 << nbits-1))) failed: value out of range' in interpreter initialization.
Summary: Change br_null_short() to br_null().
Reviewed-by: coleenp, hseigel

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

Changeset: e8a7a5995e65
Author:    bharadwaj
Date:      2013-04-25 13:10 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e8a7a5995e65

Merge


Changeset: 3d641132f83b
Author:    twisti
Date:      2013-02-26 16:16 -0800
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3d641132f83b

8004336: Better handling of method handle intrinsic frames
Reviewed-by: kvn, jrose, ahgross

! src/share/vm/opto/library_call.cpp

Changeset: 124ca22437b1
Author:    chegar
Date:      2013-04-12 10:14 +0100
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/124ca22437b1

Merge

! src/share/vm/opto/library_call.cpp

Changeset: 6c560f9ebb3e
Author:    lana
Date:      2013-04-17 10:12 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6c560f9ebb3e

Merge

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

Changeset: db9c527a1fd8
Author:    lana
Date:      2013-04-17 21:33 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/db9c527a1fd8

Merge


Changeset: d4c266784660
Author:    lana
Date:      2013-04-23 09:27 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d4c266784660

Merge


Changeset: d080f5168deb
Author:    katleman
Date:      2013-04-25 09:24 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d080f5168deb

Added tag jdk8-b87 for changeset d4c266784660

! .hgtags

Changeset: c4af77d20454
Author:    amurillo
Date:      2013-04-26 00:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c4af77d20454

Merge

! .hgtags
- make/bsd/makefiles/jvmg.make
- make/bsd/makefiles/profiled.make
- make/linux/makefiles/jvmg.make
- make/linux/makefiles/profiled.make
- make/solaris/makefiles/jvmg.make
- make/solaris/makefiles/profiled.make
- 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

Changeset: 8482058e74bc
Author:    amurillo
Date:      2013-04-26 00:29 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8482058e74bc

Added tag hs25-b30 for changeset c4af77d20454

! .hgtags

Changeset: 57ac6a688ae6
Author:    amurillo
Date:      2013-04-26 00:40 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/57ac6a688ae6

8013227: new hotspot build - hs25-b31
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 0b55a78c6be5
Author:    bharadwaj
Date:      2013-04-26 10:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0b55a78c6be5

Merge

- agent/doc/c2replay.html
! src/os/windows/vm/os_windows.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: fd49109d0d88
Author:    bharadwaj
Date:      2013-04-26 14:50 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fd49109d0d88

Merge



From jiangli.zhou at oracle.com  Mon Apr 29 03:29:19 2013
From: jiangli.zhou at oracle.com (jiangli.zhou at oracle.com)
Date: Mon, 29 Apr 2013 10:29:19 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets
Message-ID: <20130429102932.5AB7848683@hg.openjdk.java.net>

Changeset: 487d442ef257
Author:    jiangli
Date:      2013-04-26 16:21 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/487d442ef257

8013036: vm/runtime/simpleThresholdPolicy.cpp: assert(mcs != NULL).
Summary: Change the assert to if check as MethodCounters could be NULL under TieredCompilation.
Reviewed-by: kvn, twisti

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

Changeset: 62b683108582
Author:    jiangli
Date:      2013-04-26 14:41 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/62b683108582

Merge



From nils.eliasson at oracle.com  Mon Apr 29 04:15:46 2013
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Mon, 29 Apr 2013 13:15:46 +0200
Subject: RFR (S/M): 8012547: Reclamation of flushed methods can be slow
In-Reply-To: <517A9E6D.1010703@oracle.com>
References: <516FF08A.2080808@oracle.com> <5177E6FE.5010503@oracle.com>
	<5178419A.7080209@oracle.com> <51793812.1020803@oracle.com>
	<517973E5.10101@oracle.com> <517A9A16.5000407@oracle.com>
	<517A9E6D.1010703@oracle.com>
Message-ID: <517E5662.5090607@oracle.com>

Right, fixed.

//N

On 2013-04-26 17:34, Vladimir Kozlov wrote:
> Nils,
>
> You should use CompileBroker::run_compilation instead of 'true':
>
> 319     CompileBroker::set_should_compile_new_jobs(true);
>
> Otherwise it looks good.
>
> Thanks,
> Vladimir
>
> On 4/26/13 8:15 AM, Nils Eliasson wrote:
>>
>> On 2013-04-25 20:20, Vladimir Kozlov wrote:
>>> >>> * Let sweeper make disconnected methods non_entrant even if we 
>>> don't
>>> >>> need flushing any more. Makes us less likely to hit a new flush.
>>> >>
>>> >> You removed compilation enabling code in
>>> >> speculative_disconnect_nmethods() so we need to wait next 
>>> safepoint to
>>> >> enable it (in scan_stacks()). Should we do enabling compilation 
>>> during
>>> >> sweep may be in an other place when we know that some space is
>>> >> reclaimed to avoid waiting safepoint?
>>> >
>>> > Yes, my though was that !CodeCache::needs_flushing() will never be 
>>> true
>>> > since this code is only called when we need flushing. And the only
>>> place
>>> > where code cache is actually freed is in scan_stacks when nmethods 
>>> are
>>> > flushed. So it should be enough to check for turning on the 
>>> compiler as
>>> > the last thing there.
>>>
>>> It is not true, it is opposite. scan_stack() only marks nmethods.
>>> nmethod::flash() (which frees space) is called only from
>>> NMethodSweeper::sweep_code_cache().
>>
>> You are right. Confusing myself here. But the rest of my argument still
>> stands - flushing is only called when need_flushing() is true, and the
>> possibility of it being false a moment later in disconnect methods is
>> very low.  But I added a check in the end of the sweep_code_cache that
>> can turn the compiler on again.
>>
>> Also changed the flush_target calculation in
>> speculative_disconnect_nmethods slightly. Now it doesn't count natives
>> and osrs which might prevent some potentially bad behavior in long
>> running applications with lots of osrs. (With CodeCacheFlushFraction=8
>> or so, and more than 12.5% osrs, the flushing would stop make progress
>> in the very long run)
>>
>> Latest webrev:
>>
>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.08/
>> 
>>
>> Thanks!
>> //Nils
>>
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 4/25/13 7:05 AM, Nils Eliasson wrote:
>>>>
>>>> On 2013-04-24 22:33, Vladimir Kozlov wrote:
>>>>> Nils,
>>>>>
>>>>> Yes, in general it is better.
>>>>>
>>>>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.04/
>>>>>
>>>>> On 4/24/13 7:06 AM, Nils Eliasson wrote:
>>>>>> Hi again,
>>>>>>
>>>>>> Further testing revealed that not all issues was fully identified.
>>>>>> Flushing could still cause compiles to halt even though
>>>>>> compilations was
>>>>>> on, and turning off compilations when the code cache was really full
>>>>>> made the sweeper run much less often, prolonging the problem.
>>>>>>
>>>>>> Change log:
>>>>>> * Fix the comment Christian mentioned, and some other comments too.
>>>>>> * find_and_remove_saved_code renamed to reanimate_saved_code to
>>>>>> distinguish it from remove_saved_code that actually removes it.
>>>>>
>>>>> Please, add comments to those CodeCache methods to describe what
>>>>> they do.
>>>>
>>>> ok - fixed.
>>>>
>>>>>> * dont bail out on need_flushing() in compile_method - that causes
>>>>>> us to
>>>>>> stop compiling as soon as we hit CodeCacheFlushingMinimumFreeSpace
>>>>>> - and
>>>>>> that wasn't the idea.
>>>>>
>>>>> Then you should not check UseCodeCacheFlushing flag and the comment
>>>>> should be updated.
>>>>
>>>> ok, I removed the flag and the capacity check. When we can hit it -
>>>> compilation should already be turned off. And if it isn't it will 
>>>> be in
>>>> a moment.
>>>>
>>>>>
>>>>>> * New product flag CodeCacheFlushingFraction (defaults to 2)
>>>>>> * _was_full removed. Was a redundant way to say that we stopped
>>>>>> compilations.
>>>>>> * _last_was_full renamed to _last_full_flush_time, to emphasize
>>>>>> that it
>>>>>> is the time when we hit the hard limit CodeCacheMinimumSpace and
>>>>>> compilations are stopped
>>>>>> * _was_full_traversal renamed to _last_flush_traversal_id. 'full'
>>>>>> means
>>>>>> the hard CodeCacheMinimumFreeSpace limit in all other variable
>>>>>> names. 
>>>>>> * introduced _dead_compile_ids that hold a count for the number of
>>>>>> compile ID that have been reclaimed. Gives a more accurate way to
>>>>>> flush
>>>>>> the cache.
>>>>>
>>>>> Remove space in "jint       _flush_token;" to align it. Also align
>>>>> comments.
>>>> Fixed
>>>>>
>>>>>> * Simplified scan_stacks
>>>>>>    - restore flush token when min interval has passed
>>>>>>    - start compilations again if flushing is no longer needed
>>>>>> * Speed up sweeper when compilations is turned off. Sweeping is 
>>>>>> slowed
>>>>>> down when compiler threads are sleeping on the CodeCache lock, 
>>>>>> and we
>>>>>> want to speed up the reclaim process so that we can turn on compiler
>>>>>> again.
>>>>>> * Let sweeper make disconnected methods non_entrant even if we don't
>>>>>> need flushing any more. Makes us less likely to hit a new flush.
>>>>>
>>>>> You removed compilation enabling code in
>>>>> speculative_disconnect_nmethods() so we need to wait next 
>>>>> safepoint to
>>>>> enable it (in scan_stacks()). Should we do enabling compilation 
>>>>> during
>>>>> sweep may be in an other place when we know that some space is
>>>>> reclaimed to avoid waiting safepoint?
>>>>
>>>> Yes, my though was that !CodeCache::needs_flushing() will never be 
>>>> true
>>>> since this code is only called when we need flushing. And the only 
>>>> place
>>>> where code cache is actually freed is in scan_stacks when nmethods are
>>>> flushed. So it should be enough to check for turning on the 
>>>> compiler as
>>>> the last thing there.
>>>>
>>>>>
>>>>>> * Refactored NMethodSweeper::handle_full_code_cache
>>>>>>    - flushed and full flushes now uses the same token to 
>>>>>> synchronize -
>>>>>> otherwise we might get two back-to-back flushes. And that doesn't 
>>>>>> help
>>>>>> anyone.
>>>>>>    - remove time check - flush_token is restored in scan_stacks 
>>>>>> where
>>>>>> the time is already checked.
>>>>>> * set _resweep flag when flushing.
>>>>>>
>>>>>> The code is much easier to read now and the behavior should be less
>>>>>> surprising.
>>>>>
>>>>> Is that '/* */' leftover from your debugging?:
>>>>>
>>>>> 238   if (PrintMethodFlushing /*&& Verbose*/) {
>>>>>
>>>> Yes, I forgot to qrefresh my patch before doing the webrev.
>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>
>>>> New webrev with your and Christians feedback here:
>>>>
>>>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.07
>>>> 
>>>>
>>>> Thanks for all your help!
>>>> //Nils
>>>>>
>>>>>>
>>>>>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.03/
>>>>>> 
>>>>>>
>>>>>> Thanks,
>>>>>> Nils Eliasson
>>>>>>
>>>>>>
>>>>>> On 2013-04-18 15:09, Nils Eliasson wrote:
>>>>>>> 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 unnecessary long time
>>>>>>> sometimes causing unnecessary new flushes.
>>>>>>>
>>>>>>> Also some refactoring
>>>>>>> - remove state variable _do_sweep that was unnecessary. It marked
>>>>>>> if a
>>>>>>> sweep was active or not, but just a duplicate way of checking if 
>>>>>>> any
>>>>>>> methods are being sweept (nmethodsweeper::current != NULL).
>>>>>>> - rename _rescan to _resweep. When _resweep is set there will be
>>>>>>> another sweep started when the current ends. That sweep will start
>>>>>>> with a scan, but it is not only a scan.
>>>>>>> - rename _advise_to_sweep to _flush_token. Is CASed by the first
>>>>>>> thread that wants to flush and reset by scan_stacks when the 
>>>>>>> flush is
>>>>>>> finished and a proper time has passed.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~neliasso/8012547/
>>>>>>> 
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8012547
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Nils E.
>>>>>>
>>>>
>>


From nils.eliasson at oracle.com  Mon Apr 29 04:18:23 2013
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Mon, 29 Apr 2013 13:18:23 +0200
Subject: RFR (S/M): 8012547: Reclamation of flushed methods can be slow
In-Reply-To: 
References: <516FF08A.2080808@oracle.com> <5177E939.1050706@oracle.com>
	<9EA2E0DE-E82E-4A85-8838-C383A2D15D6A@oracle.com>
	<5179382B.5070403@oracle.com>
	<43374FFE-AFA5-41BA-B4D6-5813A7C56DD3@oracle.com>
	<517A9A90.8040409@oracle.com>
	
Message-ID: <517E56FF.9080607@oracle.com>

Thanks, fixed.

//N

On 2013-04-26 21:08, Christian Thalinger wrote:
> On Apr 26, 2013, at 8:17 AM, Nils Eliasson  wrote:
>
>> On 2013-04-25 18:59, Christian Thalinger wrote:
>>> Since someone has to start with this:  could you please change the method comments you've added to Doxygen-style comments?
>>>
>>> -nmethod* CodeCache::find_and_remove_saved_code(Method* m) {
>>> +// Remove and return nmethod from the saved code list in order to reanimate it.
>>> +nmethod* CodeCache::reanimate_saved_code(Method* m) {
>>>
>>> to:
>>>
>>> /**
>>>   * Remove and return nmethod from the saved code list in order to reanimate it.
>>>   */
>>> nmethod* CodeCache::reanimate_saved_code(Method* m) {
>>>
>>> Otherwise this looks good.
>>>
>>> -- Chris
>> ok, added that.
> Thanks.  There are typos, though:
>
> + * Remove nmethod from the save code list in order to discard it permanentely
>
> Should be "saved code" and "permanently".
>
> -- Chris
>
>> New webrev including Kozlovs comments to:
>>
>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.08/ 
>>
>> Thanks!
>> //Nils
>>
>>> On Apr 25, 2013, at 7:05 AM, Nils Eliasson  wrote:
>>>
>>>> On 2013-04-25 04:37, Christian Thalinger wrote:
>>>>> On Apr 24, 2013, at 7:16 AM, Nils Eliasson  wrote:
>>>>>
>>>>>> This is the correct webrev for the RFR I sent a moment ago:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.04/ 
>>>>> src/share/vm/runtime/sweeper.cpp:
>>>>>
>>>>> +          (_traversals > _last_flush_traversal_id + 2) && ((uint)nm->compile_id() < _highest_marked)) {
>>>>>
>>>>> Can't we change _highest_marked to int?  I see that CompileBroker::get_compilation_id() returns an uint.  We should decide if compile ids are int or uint.  I vote for int.
>>>> Yes. They can only be positive, and 0 is used blobs without ID. But int is the type used in other places so I will change to that and make it a little bit more consistent.
>>>>
>>>>> I don't see _dead_compile_ids being ever set.
>>>> It isn't :P TortoiseHG reverts changes on qrefresh when it thinks the patch is public. Without notice.
>>>>
>>>> Fixed.
>>>>
>>>> New webrev including your and Vladimirs suggestions:
>>>> http://cr.openjdk.java.net/~neliasso/8012547/webrev.07 
>>>>
>>>> Thanks!
>>>> //Nils
>>>>
>>>>> -- Chris
>>>>>
>>>>>> //Nils
>>>>>>
>>>>>> On 2013-04-18 15:09, Nils Eliasson wrote:
>>>>>>> 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 unnecessary long time sometimes causing unnecessary new flushes.
>>>>>>>
>>>>>>> Also some refactoring
>>>>>>> - remove state variable _do_sweep that was unnecessary. It marked if a sweep was active or not, but just a duplicate way of checking if any methods are being sweept (nmethodsweeper::current != NULL).
>>>>>>> - rename _rescan to _resweep. When _resweep is set there will be another sweep started when the current ends. That sweep will start with a scan, but it is not only a scan.
>>>>>>> - rename _advise_to_sweep to _flush_token. Is CASed by the first thread that wants to flush and reset by scan_stacks when the flush is finished and a proper time has passed.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~neliasso/8012547/ 
>>>>>>> https://jbs.oracle.com/bugs/browse/JDK-8012547
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Nils E.


From albert.noll at oracle.com  Mon Apr 29 05:23:24 2013
From: albert.noll at oracle.com (Albert Noll)
Date: Mon, 29 Apr 2013 14:23:24 +0200
Subject: RFR (XXS): 8006105: [parfait] Possible null pointer dereference at
	hotspot/src/share/vm/c1/c1_LIRGenerator.cpp
Message-ID: <517E663C.1070805@oracle.com>

Hi all,

please review the following patch:

webrev: http://cr.openjdk.java.net/~adlertz/JDK-8006105/webrev00/
jbs: https://jbs.oracle.com/bugs/browse/JDK-8006105

Problem: Function 'LIRItem::get_jobject_constant() const' may return 
constant 'NULL' at line 264, called at line 2232
Fix: added null check

Testing:
JPRT "compiler"

Many thanks in advance,
Albert

From albert.noll at oracle.com  Mon Apr 29 06:33:27 2013
From: albert.noll at oracle.com (Albert Noll)
Date: Mon, 29 Apr 2013 15:33:27 +0200
Subject: RFR: (XS): 8006107: [parfait] Possible null pointer dereference at
	hotspot/src/share/vm/compiler/compileBroker.cpp
Message-ID: <517E76A7.5040605@oracle.com>

Hi all,

please review the patch:
webrev: http://cr.openjdk.java.net/~adlertz/JDK-8006107/webrev00/
jbs: https://jbs.oracle.com/bugs/browse/JDK-8006107

Problem: The parfait bugs reported in JDK-8006107 
 are duplicated by 
JDK-8008663 . No fix 
required
Code cleanup: removed unused parameter (compiler) of 
DTRACE_METHOD_COMPILE* makro

Testing:
JPRT "compiler"

Many thanks in advance,
Albert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130429/3009708c/attachment.html 

From nils.eliasson at oracle.com  Mon Apr 29 08:37:28 2013
From: nils.eliasson at oracle.com (nils.eliasson at oracle.com)
Date: Mon, 29 Apr 2013 15:37:28 +0000
Subject: hg: hsx/hotspot-comp/hotspot: 8012547: Code cache flushing can get
	stuck reclaming of memory
Message-ID: <20130429153730.7B10348693@hg.openjdk.java.net>

Changeset: 0cfa93c2fcc4
Author:    neliasso
Date:      2013-04-29 13:20 +0200
URL:       http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0cfa93c2fcc4

8012547: Code cache flushing can get stuck reclaming of memory
Summary: Keep sweeping regardless of if we are flushing
Reviewed-by: kvn, twisti

! src/share/vm/code/codeCache.cpp
! src/share/vm/code/codeCache.hpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/sweeper.cpp
! src/share/vm/runtime/sweeper.hpp


From roland.westrelin at oracle.com  Mon Apr 29 08:43:07 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 29 Apr 2013 17:43:07 +0200
Subject: RFR (XXS): 8006105: [parfait] Possible null pointer dereference
	at hotspot/src/share/vm/c1/c1_LIRGenerator.cpp
In-Reply-To: <517E663C.1070805@oracle.com>
References: <517E663C.1070805@oracle.com>
Message-ID: <9A7A544B-047B-4D3F-91C4-E8C5DADB4DB8@oracle.com>

Hi Albert,

It doesn't look like a correct fix to me. src_con == NULL shouldn't be possible here AFAICT. It would mean that src is not of type object which shouldn't happen so by making this change we're actually allowing a broken return value to go unnoticed.
This said, I'm not sure what code change would prevent parfait from complaining while keeping the code correct.

Roland.

From roland.westrelin at oracle.com  Mon Apr 29 08:47:06 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 29 Apr 2013 17:47:06 +0200
Subject: RFR: (XS): 8006107: [parfait] Possible null pointer dereference
	at hotspot/src/share/vm/compiler/compileBroker.cpp
In-Reply-To: <517E76A7.5040605@oracle.com>
References: <517E76A7.5040605@oracle.com>
Message-ID: <204DB2BF-F84B-457F-A2D2-2964FE561A10@oracle.com>

Hi Albert,

> Code cleanup: removed unused parameter (compiler) of DTRACE_METHOD_COMPILE* makro

That looks good to me.
I think it would be best to close 8006107 as duplicate of 8008663 and file your own bug for this code clean up.

Roland.

From albert.noll at oracle.com  Mon Apr 29 09:39:15 2013
From: albert.noll at oracle.com (Albert Noll)
Date: Mon, 29 Apr 2013 09:39:15 -0700 (PDT)
Subject: RFR (XXS): 8006105: [parfait] Possible null pointer dereference
	at hotspot/src/share/vm/c1/c1_LIRGenerator.cpp
Message-ID: <19b6611a-eee2-4500-bbac-1456529e1c4d@default>

Hi Roland,
thank you very much for the feedback. 
How about using guarantee(...) to ensure that src_con != NULL? 

Best,
Albert

----- Original Message -----
From: roland.westrelin at oracle.com
To: albert.noll at oracle.com
Cc: hotspot-compiler-dev at openjdk.java.net
Sent: Monday, April 29, 2013 5:43:09 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: RFR (XXS): 8006105: [parfait] Possible null pointer dereference at hotspot/src/share/vm/c1/c1_LIRGenerator.cpp

Hi Albert,

It doesn't look like a correct fix to me. src_con == NULL shouldn't be possible here AFAICT. It would mean that src is not of type object which shouldn't happen so by making this change we're actually allowing a broken return value to go unnoticed.
This said, I'm not sure what code change would prevent parfait from complaining while keeping the code correct.

Roland.

From morris.meyer at oracle.com  Mon Apr 29 10:36:16 2013
From: morris.meyer at oracle.com (Morris Meyer)
Date: Mon, 29 Apr 2013 13:36:16 -0400
Subject: RFR (XXS): 8006105: [parfait] Possible null pointer dereference
	at hotspot/src/share/vm/c1/c1_LIRGenerator.cpp
In-Reply-To: <19b6611a-eee2-4500-bbac-1456529e1c4d@default>
References: <19b6611a-eee2-4500-bbac-1456529e1c4d@default>
Message-ID: <517EAF90.9030204@oracle.com>

Albert,

In many of the other parfait issues I closed recently - I used 
guarantee() to assert pointers.

         --mm

On 4/29/13 12:39 PM, Albert Noll wrote:
> Hi Roland,
> thank you very much for the feedback.
> How about using guarantee(...) to ensure that src_con != NULL?
>
> Best,
> Albert
>
> ----- Original Message -----
> From: roland.westrelin at oracle.com
> To: albert.noll at oracle.com
> Cc: hotspot-compiler-dev at openjdk.java.net
> Sent: Monday, April 29, 2013 5:43:09 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
> Subject: Re: RFR (XXS): 8006105: [parfait] Possible null pointer dereference at hotspot/src/share/vm/c1/c1_LIRGenerator.cpp
>
> Hi Albert,
>
> It doesn't look like a correct fix to me. src_con == NULL shouldn't be possible here AFAICT. It would mean that src is not of type object which shouldn't happen so by making this change we're actually allowing a broken return value to go unnoticed.
> This said, I'm not sure what code change would prevent parfait from complaining while keeping the code correct.
>
> Roland.


From vladimir.kozlov at oracle.com  Mon Apr 29 11:14:21 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 29 Apr 2013 11:14:21 -0700
Subject: RFR: (XS): 8006107: [parfait] Possible null pointer dereference
	at hotspot/src/share/vm/compiler/compileBroker.cpp
In-Reply-To: <204DB2BF-F84B-457F-A2D2-2964FE561A10@oracle.com>
References: <517E76A7.5040605@oracle.com>
	<204DB2BF-F84B-457F-A2D2-2964FE561A10@oracle.com>
Message-ID: <517EB87D.9050504@oracle.com>

On 4/29/13 8:47 AM, Roland Westrelin wrote:
> Hi Albert,
>
>> Code cleanup: removed unused parameter (compiler) of DTRACE_METHOD_COMPILE* makro
>
> That looks good to me.
> I think it would be best to close 8006107 as duplicate of 8008663 and file your own bug for this code clean up.

Agree. Albert, please, do as Roland suggested.

Vladimir

>
> Roland.
>

From roland.westrelin at oracle.com  Mon Apr 29 11:22:56 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 29 Apr 2013 20:22:56 +0200
Subject: RFR (XXS): 8006105: [parfait] Possible null pointer dereference
	at hotspot/src/share/vm/c1/c1_LIRGenerator.cpp
In-Reply-To: <19b6611a-eee2-4500-bbac-1456529e1c4d@default>
References: <19b6611a-eee2-4500-bbac-1456529e1c4d@default>
Message-ID: 


> How about using guarantee(...) to ensure that src_con != NULL? 

An assert is really the only thing that would make sense here.

Roland.

From christian.thalinger at oracle.com  Mon Apr 29 17:36:48 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 29 Apr 2013 17:36:48 -0700
Subject: RFR (S): 7196277: JSR 292: Two jck/runtime tests crash on
	java.lang.invoke.MethodHandle.invokeExact
Message-ID: 

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

7196277: JSR 292: Two jck/runtime tests crash on java.lang.invoke.MethodHandle.invokeExact
Reviewed-by:

The problem is the logic in InterpreterGenerator::generate_native_entry: it checks for an oop return value and tries to unbox it before pending exceptions are thrown. 

If throw_unsupported_operation_exception (which is a void method!) is called for a native method that has an oop return type the native entry tries to unbox the value in the return register. Which happens to be okay for debug builds but for product builds contains a random value and that crashes the VM.

The fix is to not install a native entry point to eventually throw the exception when being called but throw the UnsupportedOperationException in NativeLookup::lookup.

This patch also hardens throw_unsatisfied_link_error to find a similar issue more easily in the future.

src/share/vm/prims/nativeLookup.cpp
src/share/vm/runtime/sharedRuntime.cpp


From vladimir.kozlov at oracle.com  Mon Apr 29 20:18:21 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 29 Apr 2013 20:18:21 -0700
Subject: RFR (S): 7196277: JSR 292: Two jck/runtime tests crash on
	java.lang.invoke.MethodHandle.invokeExact
In-Reply-To: 
References: 
Message-ID: <517F37FD.9040701@oracle.com>

Looks good to me.
CC to runtime group since you changed throw_unsatisfied_link_error().

Thanks,
Vladimir

On 4/29/13 5:36 PM, Christian Thalinger wrote:
> http://cr.openjdk.java.net/~twisti/7196277
>
> 7196277: JSR 292: Two jck/runtime tests crash on java.lang.invoke.MethodHandle.invokeExact
> Reviewed-by:
>
> The problem is the logic in InterpreterGenerator::generate_native_entry: it checks for an oop return value and tries to unbox it before pending exceptions are thrown.
>
> If throw_unsupported_operation_exception (which is a void method!) is called for a native method that has an oop return type the native entry tries to unbox the value in the return register. Which happens to be okay for debug builds but for product builds contains a random value and that crashes the VM.
>
> The fix is to not install a native entry point to eventually throw the exception when being called but throw the UnsupportedOperationException in NativeLookup::lookup.
>
> This patch also hardens throw_unsatisfied_link_error to find a similar issue more easily in the future.
>
> src/share/vm/prims/nativeLookup.cpp
> src/share/vm/runtime/sharedRuntime.cpp
>

From christian.thalinger at oracle.com  Mon Apr 29 19:26:22 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 29 Apr 2013 19:26:22 -0700
Subject: RFR (S): 7196277: JSR 292: Two jck/runtime tests crash on
	java.lang.invoke.MethodHandle.invokeExact
In-Reply-To: 
References: 
Message-ID: <4FA6AF66-817B-4DC1-9CF2-85DF23199B72@oracle.com>

Withdrawn.  There might be a better way to do it.  -- Chris

On Apr 29, 2013, at 5:36 PM, Christian Thalinger  wrote:

> http://cr.openjdk.java.net/~twisti/7196277
> 
> 7196277: JSR 292: Two jck/runtime tests crash on java.lang.invoke.MethodHandle.invokeExact
> Reviewed-by:
> 
> The problem is the logic in InterpreterGenerator::generate_native_entry: it checks for an oop return value and tries to unbox it before pending exceptions are thrown. 
> 
> If throw_unsupported_operation_exception (which is a void method!) is called for a native method that has an oop return type the native entry tries to unbox the value in the return register. Which happens to be okay for debug builds but for product builds contains a random value and that crashes the VM.
> 
> The fix is to not install a native entry point to eventually throw the exception when being called but throw the UnsupportedOperationException in NativeLookup::lookup.
> 
> This patch also hardens throw_unsatisfied_link_error to find a similar issue more easily in the future.
> 
> src/share/vm/prims/nativeLookup.cpp
> src/share/vm/runtime/sharedRuntime.cpp
> 


From goetz.lindenmaier at sap.com  Tue Apr 30 01:10:27 2013
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 30 Apr 2013 08:10:27 +0000
Subject: RFR (M): 8003853: specify offset of IC load in java_to_interp stub
In-Reply-To: 
References: <4295855A5C1DE049A61835A1887419CC0CFB4FFC@DEWDFEMB12A.global.corp.sap>
	
	<50541FF8-BD83-4A06-A0D9-0E3C853ED224@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB59E6@DEWDFEMB12A.global.corp.sap>
	
Message-ID: <4295855A5C1DE049A61835A1887419CC0CFBFC56@DEWDFEMB12A.global.corp.sap>

Hi,

Does the change pass your tests?
When will it appear in a repo? I assume it will go to hotspot-comp, right?
Or do I have to look somewhere else.

Best regards,
  Goetz.

From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
Sent: Mittwoch, 24. April 2013 21:17
To: Lindenmaier, Goetz
Cc: hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR (M): 8003853: specify offset of IC load in java_to_interp stub

Looks good.  Dean, can you push the change?

-- Chris

On Apr 24, 2013, at 1:47 AM, "Lindenmaier, Goetz" > wrote:


Hi,

Yes, your comments make the code look better.
I made a new webrev:
http://cr.openjdk.java.net/~goetz/webrevs/8003853-4/

I did not do a zero build.

Best regards,
  Goetz.


From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
Sent: Dienstag, 23. April 2013 21:06
To: Lindenmaier, Goetz
Cc: hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR (M): 8003853: specify offset of IC load in java_to_interp stub


On Apr 23, 2013, at 11:00 AM, Christian Thalinger > wrote:



The change looks good.  I have some minor comments though:
src/share/vm/code/compiledIC.hpp:

+  static uint to_interp_stub_size();

+  static uint reloc_to_interp_stub();

+            stub_size  += CompiledStaticCall::to_interp_stub_size();

+            reloc_size += CompiledStaticCall::reloc_to_interp_stub();
stub_size and reloc_size are ints.  We should change the return type from uint to int.

src/cpu/x86/vm/compiledIC_x86.cpp:

 108 uint CompiledStaticCall::to_interp_stub_size() {

 109   return 10              // movl; jmp

 110          LP64_ONLY(+5);  // movq (1+1+8); jmp (1+4)

 111 }
In expectancy of future changes we should do:

 108 uint CompiledStaticCall::to_interp_stub_size() {

 109   return NOT_LP64(10)    // movl; jmp

 110          LP64_ONLY(15);  // movq (1+1+8); jmp (1+4)

 111 }
And one question unrelated to this change (because it was there before):

src/cpu/sparc/vm/compiledIC_sparc.cpp:

 126 // Relocation entries for call stub, compiled java to interpreter.

 127 uint CompiledStaticCall::reloc_to_interp_stub() {

 128   return 10;  // 4 in emit_java_to_interp + 1 in Java_Static_Call

 129 }
Why does it say 5 relocations but returns 10?

Did someone try a Zero build?

Presumably not because Zero builds are broken right now.  I just filed:

8013067: Zero builds are broken after 8010862

-- Chris


-- Chris

On Apr 23, 2013, at 1:09 AM, "Lindenmaier, Goetz" > wrote:



Hi all,

In the java_to_interp stub of CompiledStaticCalls one relocation is used to find
two code locations:
-          the beginning of the stub
-          the IC load instruction.
On x86 and sparc, the IC load instruction is the first instruction of the stub,
thus both locations have the same address.
On PPC, the IC load instruction is not the first instruction in the stub, thus
we must add an offset to the relocation to access it.

As the manipulation of  CompiledStaticCalls is in shared code, we would have
to introduce platform dependencies there.

This change moves the platform dependent code from CompiledStaticCall
to a new file compiledIC_.cpp.  It also moves the code issuing the
stub from the ad file to this new file into the class CompiledStaticCall.
This removes redundancies between x86_64.ad and x86_32.ad.  Also,
'extern' declarations in compile.cpp can be replaced by properly typed
Calls to methods in CompiledStaticCall.

Dean Long ran this change through JPRT with status OK (thanks!).

Please review and push this change.
http://cr.openjdk.java.net/~goetz/webrevs/8003853-3/

Best regards,
  Goetz Lindenmaier


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

From albert.noll at oracle.com  Tue Apr 30 06:00:56 2013
From: albert.noll at oracle.com (Albert Noll)
Date: Tue, 30 Apr 2013 15:00:56 +0200
Subject: RFR (XS): JDK-8013532: Remove unused parameter "compiler" from
	DTRACE_METHOD_COMPILE* macros
Message-ID: <517FC088.1070408@oracle.com>

Thanks for the reviews,
Albert


webrev: http://cr.openjdk.java.net/~roland/8013532/webrev.00/
jbs: https://jbs.oracle.com/bugs/browse/JDK-8013532

Problem: Unused parameter in (DTRACE_METHOD_COMPILE*) in compileBroker.cpp
Fix: Removed unused parameter

Test:
jtreg testset compiler



From roland.westrelin at oracle.com  Tue Apr 30 06:15:33 2013
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 30 Apr 2013 15:15:33 +0200
Subject: RFR (XS): JDK-8013532: Remove unused parameter "compiler" from
	DTRACE_METHOD_COMPILE* macros
In-Reply-To: <517FC088.1070408@oracle.com>
References: <517FC088.1070408@oracle.com>
Message-ID: <8456D857-B3AA-41BF-9450-BB058A833B2B@oracle.com>

It looks good.

Roland.

From dean.long at oracle.com  Tue Apr 30 08:10:51 2013
From: dean.long at oracle.com (Dean Long)
Date: Tue, 30 Apr 2013 08:10:51 -0700
Subject: RFR (M): 8003853: specify offset of IC load in java_to_interp stub
In-Reply-To: <4295855A5C1DE049A61835A1887419CC0CFBFC56@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC0CFB4FFC@DEWDFEMB12A.global.corp.sap>
	
	<50541FF8-BD83-4A06-A0D9-0E3C853ED224@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB59E6@DEWDFEMB12A.global.corp.sap>
	
	<4295855A5C1DE049A61835A1887419CC0CFBFC56@DEWDFEMB12A.global.corp.sap>
Message-ID: <517FDEFB.8060200@oracle.com>

It's in hotspot-emb now.

dl

On 4/30/2013 1:10 AM, Lindenmaier, Goetz wrote:
>
> Hi,
>
> Does the change pass your tests?
>
> When will it appear in a repo? I assume it will go to hotspot-comp, right?
>
> Or do I have to look somewhere else.
>
> Best regards,
>
>   Goetz.
>
> *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com]
> *Sent:* Mittwoch, 24. April 2013 21:17
> *To:* Lindenmaier, Goetz
> *Cc:* hotspot-compiler-dev at openjdk.java.net
> *Subject:* Re: RFR (M): 8003853: specify offset of IC load in 
> java_to_interp stub
>
> Looks good.  Dean, can you push the change?
>
> -- Chris
>
> On Apr 24, 2013, at 1:47 AM, "Lindenmaier, Goetz" 
> > wrote:
>
>
>
> Hi,
>
> Yes, your comments make the code look better.
>
> I made a new webrev:
>
> http://cr.openjdk.java.net/~goetz/webrevs/8003853-4/ 
> 
>
> I did not do a zero build.
>
> Best regards,
>
> Goetz.
>
> *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com 
> ]
> *Sent:*Dienstag, 23. April 2013 21:06
> *To:*Lindenmaier, Goetz
> *Cc:*hotspot-compiler-dev at openjdk.java.net 
> 
> *Subject:*Re: RFR (M): 8003853: specify offset of IC load in 
> java_to_interp stub
>
> On Apr 23, 2013, at 11:00 AM, Christian Thalinger 
>  > wrote:
>
>
>
>
> The change looks good.  I have some minor comments though:
>
>
>     src/share/vm/code/compiledIC.hpp:
>
> +  static uint to_interp_stub_size();
> +  static uint reloc_to_interp_stub();
> +            stub_size  += CompiledStaticCall::to_interp_stub_size();
> +            reloc_size += CompiledStaticCall::reloc_to_interp_stub();
>
> stub_size and reloc_size are ints.  We should change the return type 
> from uint to int.
>
> src/cpu/x86/vm/compiledIC_x86.cpp:
>
>   108 uint CompiledStaticCall::to_interp_stub_size() {
>   109   return 10              // movl; jmp
>   110          LP64_ONLY(+5);  // movq (1+1+8); jmp (1+4)
>   111 }
>
> In expectancy of future changes we should do:
>
>   108 uint CompiledStaticCall::to_interp_stub_size() {
>   109   return NOT_LP64(10)    // movl; jmp
>   110          LP64_ONLY(15);  // movq (1+1+8); jmp (1+4)
>   111 }
>
> And one question unrelated to this change (because it was there before):
>
> src/cpu/sparc/vm/compiledIC_sparc.cpp:
>
>   126 // Relocation entries for call stub, compiled java to interpreter.
>   127 uint CompiledStaticCall::reloc_to_interp_stub() {
>   128   return 10;  // 4 in emit_java_to_interp + 1 in Java_Static_Call
>   129 }
>
> Why does it say 5 relocations but returns 10?
>
> Did someone try a Zero build?
>
> Presumably not because Zero builds are broken right now.  I just filed:
>
> 8013067: Zero builds are broken after 8010862
>
> -- Chris
>
>     -- Chris
>
>     On Apr 23, 2013, at 1:09 AM, "Lindenmaier, Goetz"
>     > wrote:
>
>
>
>
>     Hi all,
>
>     In the java_to_interp stub of CompiledStaticCalls one relocation
>     is used to find
>
>     two code locations:
>
>     -the beginning of the stub
>
>     -the IC load instruction.
>
>     On x86 and sparc, the IC load instruction is the first instruction
>     of the stub,
>
>     thus both locations have the same address.
>
>     On PPC, the IC load instruction is not the first instruction in
>     the stub, thus
>
>     we must add an offset to the relocation to access it.
>
>     As the manipulation of  CompiledStaticCalls is in shared code, we
>     would have
>
>     to introduce platform dependencies there.
>
>     This change moves the platform dependent code from CompiledStaticCall
>
>     to a new file compiledIC_.cpp.  It also moves the code
>     issuing the
>
>     stub from the ad file to this new file into the class
>     CompiledStaticCall.
>
>     This removes redundancies between x86_64.ad and x86_32.ad.  Also,
>
>     'extern' declarations in compile.cpp can be replaced by properly typed
>
>     Calls to methods in CompiledStaticCall.
>
>     Dean Long ran this change through JPRT with status OK (thanks!).
>
>     Please review and push this change.
>
>     http://cr.openjdk.java.net/~goetz/webrevs/8003853-3/
>     
>
>     Best regards,
>
>       Goetz Lindenmaier
>

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

From goetz.lindenmaier at sap.com  Tue Apr 30 08:14:54 2013
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 30 Apr 2013 15:14:54 +0000
Subject: RFR (M): 8003853: specify offset of IC load in java_to_interp stub
In-Reply-To: <517FDEFB.8060200@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC0CFB4FFC@DEWDFEMB12A.global.corp.sap>
	
	<50541FF8-BD83-4A06-A0D9-0E3C853ED224@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB59E6@DEWDFEMB12A.global.corp.sap>
	
	<4295855A5C1DE049A61835A1887419CC0CFBFC56@DEWDFEMB12A.global.corp.sap>
	<517FDEFB.8060200@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC0CFC0DCE@DEWDFEMB12A.global.corp.sap>

I found it, very nice!

Thanks a lot for all your help,
  Goetz.


From: Dean Long [mailto:dean.long at oracle.com]
Sent: Dienstag, 30. April 2013 17:11
To: Lindenmaier, Goetz
Cc: Christian Thalinger; hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR (M): 8003853: specify offset of IC load in java_to_interp stub

It's in hotspot-emb now.

dl
On 4/30/2013 1:10 AM, Lindenmaier, Goetz wrote:
Hi,

Does the change pass your tests?
When will it appear in a repo? I assume it will go to hotspot-comp, right?
Or do I have to look somewhere else.

Best regards,
  Goetz.

From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
Sent: Mittwoch, 24. April 2013 21:17
To: Lindenmaier, Goetz
Cc: hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR (M): 8003853: specify offset of IC load in java_to_interp stub

Looks good.  Dean, can you push the change?

-- Chris

On Apr 24, 2013, at 1:47 AM, "Lindenmaier, Goetz" > wrote:



Hi,

Yes, your comments make the code look better.
I made a new webrev:
http://cr.openjdk.java.net/~goetz/webrevs/8003853-4/

I did not do a zero build.

Best regards,
  Goetz.


From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
Sent: Dienstag, 23. April 2013 21:06
To: Lindenmaier, Goetz
Cc: hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR (M): 8003853: specify offset of IC load in java_to_interp stub


On Apr 23, 2013, at 11:00 AM, Christian Thalinger > wrote:




The change looks good.  I have some minor comments though:
src/share/vm/code/compiledIC.hpp:

+  static uint to_interp_stub_size();

+  static uint reloc_to_interp_stub();

+            stub_size  += CompiledStaticCall::to_interp_stub_size();

+            reloc_size += CompiledStaticCall::reloc_to_interp_stub();
stub_size and reloc_size are ints.  We should change the return type from uint to int.

src/cpu/x86/vm/compiledIC_x86.cpp:

 108 uint CompiledStaticCall::to_interp_stub_size() {

 109   return 10              // movl; jmp

 110          LP64_ONLY(+5);  // movq (1+1+8); jmp (1+4)

 111 }
In expectancy of future changes we should do:

 108 uint CompiledStaticCall::to_interp_stub_size() {

 109   return NOT_LP64(10)    // movl; jmp

 110          LP64_ONLY(15);  // movq (1+1+8); jmp (1+4)

 111 }
And one question unrelated to this change (because it was there before):

src/cpu/sparc/vm/compiledIC_sparc.cpp:

 126 // Relocation entries for call stub, compiled java to interpreter.

 127 uint CompiledStaticCall::reloc_to_interp_stub() {

 128   return 10;  // 4 in emit_java_to_interp + 1 in Java_Static_Call

 129 }
Why does it say 5 relocations but returns 10?

Did someone try a Zero build?

Presumably not because Zero builds are broken right now.  I just filed:

8013067: Zero builds are broken after 8010862

-- Chris


-- Chris

On Apr 23, 2013, at 1:09 AM, "Lindenmaier, Goetz" > wrote:




Hi all,

In the java_to_interp stub of CompiledStaticCalls one relocation is used to find
two code locations:
-          the beginning of the stub
-          the IC load instruction.
On x86 and sparc, the IC load instruction is the first instruction of the stub,
thus both locations have the same address.
On PPC, the IC load instruction is not the first instruction in the stub, thus
we must add an offset to the relocation to access it.

As the manipulation of  CompiledStaticCalls is in shared code, we would have
to introduce platform dependencies there.

This change moves the platform dependent code from CompiledStaticCall
to a new file compiledIC_.cpp.  It also moves the code issuing the
stub from the ad file to this new file into the class CompiledStaticCall.
This removes redundancies between x86_64.ad and x86_32.ad.  Also,
'extern' declarations in compile.cpp can be replaced by properly typed
Calls to methods in CompiledStaticCall.

Dean Long ran this change through JPRT with status OK (thanks!).

Please review and push this change.
http://cr.openjdk.java.net/~goetz/webrevs/8003853-3/

Best regards,
  Goetz Lindenmaier



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

From vladimir.kozlov at oracle.com  Tue Apr 30 08:17:36 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 30 Apr 2013 08:17:36 -0700
Subject: RFR (XS): JDK-8013532: Remove unused parameter "compiler" from
	DTRACE_METHOD_COMPILE* macros
In-Reply-To: <517FC088.1070408@oracle.com>
References: <517FC088.1070408@oracle.com>
Message-ID: <517FE090.9040602@oracle.com>

Good.

Thanks,
Vladimir

On 4/30/13 6:00 AM, Albert Noll wrote:
> Thanks for the reviews,
> Albert
>
>
> webrev: http://cr.openjdk.java.net/~roland/8013532/webrev.00/
> jbs: https://jbs.oracle.com/bugs/browse/JDK-8013532
>
> Problem: Unused parameter in (DTRACE_METHOD_COMPILE*) in compileBroker.cpp
> Fix: Removed unused parameter
>
> Test:
> jtreg testset compiler
>
>

From nils.eliasson at oracle.com  Tue Apr 30 08:27:19 2013
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Tue, 30 Apr 2013 17:27:19 +0200
Subject: RFR(M): 8008287: Code cache statistic variables for event tracing
	needs atomicity
Message-ID: <517FE2D7.5050900@oracle.com>

Hi,

I have fixed some atomicity issues for the sweeper tracing and did some 
refactoring at the same time, removing duplicate counters.

I guess people might have opinions on this, but I have chosen to only 
use the perf_counters when available instead of  always having a normal 
counter and an additional perf_counter in specific scenarios.

Also changed the type of the traversal counter (and the stack_traversal 
marker in nmethod). It should be good for 126 years of sweeping once a 
second anyway (and we don't complete full sweeps that often.)

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


Thanks,
Nils Eliasson



From christian.thalinger at oracle.com  Tue Apr 30 14:06:09 2013
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 30 Apr 2013 14:06:09 -0700
Subject: RFR (M): 8003853: specify offset of IC load in java_to_interp stub
In-Reply-To: <517FDEFB.8060200@oracle.com>
References: <4295855A5C1DE049A61835A1887419CC0CFB4FFC@DEWDFEMB12A.global.corp.sap>
	
	<50541FF8-BD83-4A06-A0D9-0E3C853ED224@oracle.com>
	<4295855A5C1DE049A61835A1887419CC0CFB59E6@DEWDFEMB12A.global.corp.sap>
	
	<4295855A5C1DE049A61835A1887419CC0CFBFC56@DEWDFEMB12A.global.corp.sap>
	<517FDEFB.8060200@oracle.com>
Message-ID: <170C3096-4E19-4CA0-AB20-A68AD86AF363@oracle.com>

Thank you.  -- Chris

On Apr 30, 2013, at 8:10 AM, Dean Long  wrote:

> It's in hotspot-emb now.
> 
> dl
> 
> On 4/30/2013 1:10 AM, Lindenmaier, Goetz wrote:
>> Hi,
>>  
>> Does the change pass your tests?
>> When will it appear in a repo? I assume it will go to hotspot-comp, right?
>> Or do I have to look somewhere else.
>>  
>> Best regards,
>>   Goetz.
>>  
>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>> Sent: Mittwoch, 24. April 2013 21:17
>> To: Lindenmaier, Goetz
>> Cc: hotspot-compiler-dev at openjdk.java.net
>> Subject: Re: RFR (M): 8003853: specify offset of IC load in java_to_interp stub
>>  
>> Looks good.  Dean, can you push the change?
>>  
>> -- Chris
>>  
>> On Apr 24, 2013, at 1:47 AM, "Lindenmaier, Goetz"  wrote:
>> 
>> 
>> Hi,
>>  
>> Yes, your comments make the code look better.
>> I made a new webrev:
>> http://cr.openjdk.java.net/~goetz/webrevs/8003853-4/
>>  
>> I did not do a zero build.
>>  
>> Best regards,
>>   Goetz.
>>  
>>  
>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] 
>> Sent: Dienstag, 23. April 2013 21:06
>> To: Lindenmaier, Goetz
>> Cc: hotspot-compiler-dev at openjdk.java.net
>> Subject: Re: RFR (M): 8003853: specify offset of IC load in java_to_interp stub
>>  
>>  
>> On Apr 23, 2013, at 11:00 AM, Christian Thalinger  wrote:
>> 
>> 
>> 
>> The change looks good.  I have some minor comments though:
>> src/share/vm/code/compiledIC.hpp:
>> 
>> +  static uint to_interp_stub_size();
>> +  static uint reloc_to_interp_stub();
>> +            stub_size  += CompiledStaticCall::to_interp_stub_size();
>> +            reloc_size += CompiledStaticCall::reloc_to_interp_stub();
>> stub_size and reloc_size are ints.  We should change the return type from uint to int.
>>  
>> src/cpu/x86/vm/compiledIC_x86.cpp:
>>  108 uint CompiledStaticCall::to_interp_stub_size() {
>>  109   return 10              // movl; jmp
>>  110          LP64_ONLY(+5);  // movq (1+1+8); jmp (1+4)
>>  111 }
>> In expectancy of future changes we should do:
>>  108 uint CompiledStaticCall::to_interp_stub_size() {
>>  109   return NOT_LP64(10)    // movl; jmp
>>  110          LP64_ONLY(15);  // movq (1+1+8); jmp (1+4)
>>  111 }
>> And one question unrelated to this change (because it was there before):
>>  
>> src/cpu/sparc/vm/compiledIC_sparc.cpp:
>>  126 // Relocation entries for call stub, compiled java to interpreter.
>>  127 uint CompiledStaticCall::reloc_to_interp_stub() {
>>  128   return 10;  // 4 in emit_java_to_interp + 1 in Java_Static_Call
>>  129 }
>> Why does it say 5 relocations but returns 10?
>>  
>> Did someone try a Zero build?
>>  
>> Presumably not because Zero builds are broken right now.  I just filed:
>>  
>> 8013067: Zero builds are broken after 8010862
>>  
>> -- Chris
>>  
>>  
>> -- Chris
>>  
>> On Apr 23, 2013, at 1:09 AM, "Lindenmaier, Goetz"  wrote:
>> 
>> 
>> 
>> Hi all,
>>  
>> In the java_to_interp stub of CompiledStaticCalls one relocation is used to find
>> two code locations:
>> -          the beginning of the stub
>> -          the IC load instruction.
>> On x86 and sparc, the IC load instruction is the first instruction of the stub,
>> thus both locations have the same address.
>> On PPC, the IC load instruction is not the first instruction in the stub, thus
>> we must add an offset to the relocation to access it.
>>  
>> As the manipulation of  CompiledStaticCalls is in shared code, we would have
>> to introduce platform dependencies there.
>>  
>> This change moves the platform dependent code from CompiledStaticCall
>> to a new file compiledIC_.cpp.  It also moves the code issuing the
>> stub from the ad file to this new file into the class CompiledStaticCall.
>> This removes redundancies between x86_64.ad and x86_32.ad.  Also,
>> ?extern? declarations in compile.cpp can be replaced by properly typed
>> Calls to methods in CompiledStaticCall.
>>  
>> Dean Long ran this change through JPRT with status OK (thanks!).
>>  
>> Please review and push this change.
>> http://cr.openjdk.java.net/~goetz/webrevs/8003853-3/
>>  
>> Best regards,
>>   Goetz Lindenmaier
>>  
>>  
> 

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

From vladimir.kozlov at oracle.com  Tue Apr 30 19:46:45 2013
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 30 Apr 2013 19:46:45 -0700
Subject: RFR (XL): 6934604: enable parts of EliminateAutoBox by default
In-Reply-To: <515DC564.9000807@oracle.com>
References: <515DC564.9000807@oracle.com>
Message-ID: <51808215.7020305@oracle.com>

http://cr.openjdk.java.net/~kvn/6934604.v2/webrev/

Resurrected autobox elimination code and enabled it by default.
Added new experimental C2 flag in preparation for 8012974.

After static fields were moved to JavaMirror the existing autobox 
elimination code (LoadNode::eliminate_autobox()) stopped working because 
graph was changed. Fixed it for loading from Boxing cache array, moved 
spit through Phi code from eliminate_autobox() to 
LoadNode::split_through_phi(). Also use incremental inlining to delay 
inlining of valueOf() methods to get value from argument. Mark such 
method as Macro nodes and treat them the same way as Allocations. Added 
value load from constant boxing objects. Eliminated MemBarRelease for 
non-escaping allocations (such membar generated when final fields are 
initialized in constructor).

Did not get any significant performance improvements because very few 
places have opportunity for current optimization (when all objects do 
not escape).

Additional changes:
Added ability to recompile method without EliminateAutoBox if 
compilation with it failed.

Added assert live_nodes < MaxNodeLimit into Node costructor.

Added timer for incremental inlining.

Fixed TypeAryPtr::narrow_size_type() to return correct type for 
arr[MAXINT] (currently it returns incorrect arr[0]).

Moved the check in assert to condition in loopPredicate.cpp because I 
hit the problem during CTW testing.

Fixed tiered compilation process dependence on the order of -Xcomp 
-XX:+TieredCompilation flags.

Added regression tests.

Tested with jprt, ctw, nashorn.

Thanks,
Vladimir