From Patrick.Metzler at gmx.net Mon Oct 1 05:05:16 2012 From: Patrick.Metzler at gmx.net (Patrick Metzler) Date: Mon, 01 Oct 2012 14:05:16 +0200 Subject: Branch removal In-Reply-To: <5065E5F5.4080806@oracle.com> References: <50598580.7070302@gmx.net> <505B8E6A.6020907@oracle.com> <505C1DE1.2000405@gmx.net> <506409E0.8040700@gmx.net> <506474A9.9080202@oracle.com> <506481C1.20006@gmx.net> <5064908E.4000809@oracle.com> <50649CA0.2040602@gmx.net> <5064A35B.4030506@oracle.com> <5064AAFF.7010600@gmx.net> <5064B50A.2020908@oracle.com> <5064B9C0.7050903@gmx.net> <5065938A.50706@gmx.net> <5065E5F5.4080806@oracle.com> Message-ID: <506986FC.5080009@gmx.net> Hi, thank you for the hint, Vladimir. > Add flags -XX:+PrintCompilation -XX:+PrintInlining (and may be > -XX:-TieredCompilation to look only on C2 compilations). Could be one of > inlined method has loop. The graph could be also complicated if it is > OSR compilation (there is % next to compilation number in > PrintCompilation output). I did not observe any OSR compilation. But it turned out that in the original version: > for (E e : arrayList) { > aSwap = a.getCopy(); > aSwap.do(); > if (e.condition()) > a = aSwap; > } the 'if' statement does not get a CFG diamond after parsing both with and without -XX:CompileOnly="that method". Also in the modified version > aSwap = a.getCopy(); > for (E e : arrayList) { > aSwap.do(); > if (e.condition()) > a = aSwap; > aSwap = a.getCopy(); > } the 'if' statement does not get a CFG diamond if inlined (and it does if executed with -XX:CompileOnly). I think I will disable inlining with -XX:-Inline for my experiments. If I have the time, I will try to remove the branching even if it is not a CFG diamond. I would try to eliminate the 'if' statement branching by setting the condition to a constant value (and igvn.optimize() will remove the dead branch). Then, I would insert the CMove with that condition before the use of the local variable, i.e. CallStaticJava for aSwap.do(). Best regards, Patrick From stefan.karlsson at oracle.com Mon Oct 1 05:08:52 2012 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 01 Oct 2012 14:08:52 +0200 Subject: Review request (XS): 8000228: Missing call to cr() when printing entry_point in nmethod, in os::print_location Message-ID: <506987D4.4050602@oracle.com> http://cr.openjdk.java.net/~stefank/8000228/webrev/ StefanK From roland.westrelin at oracle.com Mon Oct 1 05:20:59 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 1 Oct 2012 14:20:59 +0200 Subject: Request for reviews (M): 7201026: add vector for shift count In-Reply-To: <50625FC2.1050900@oracle.com> References: <50625FC2.1050900@oracle.com> Message-ID: > http://cr.openjdk.java.net/~kvn/7201026/webrev It looks good. Why do we need a different node type for left and right shifts? Wouldn't a single one be sufficient? Roland. From roland.westrelin at oracle.com Mon Oct 1 05:28:49 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 1 Oct 2012 14:28:49 +0200 Subject: RFR (L): 7173584: Implement arraycopy as a macro node In-Reply-To: <50661F17.8030304@oracle.com> References: <9CAF8242-736B-4B8B-8926-3451DA87AF70@oracle.com> <5064AF8B.1090509@oracle.com> <335A7D52-EE29-451A-8E21-1DF5E578406A@oracle.com> <50661F17.8030304@oracle.com> Message-ID: <54D825C4-1D9E-4897-80D6-53CBEB502A20@oracle.com> > Thank you for the case. I did go through the code and this change looks fine. Thanks, Vladimir. Roland. From bengt.rutisson at oracle.com Mon Oct 1 05:42:54 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 01 Oct 2012 14:42:54 +0200 Subject: Review request (XS): 8000228: Missing call to cr() when printing entry_point in nmethod, in os::print_location In-Reply-To: <506987D4.4050602@oracle.com> References: <506987D4.4050602@oracle.com> Message-ID: <50698FCE.2020009@oracle.com> On 2012-10-01 14:08, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8000228/webrev/ > > StefanK Looks good. Bengt From dean.long at oracle.com Mon Oct 1 09:28:10 2012 From: dean.long at oracle.com (Dean Long) Date: Mon, 01 Oct 2012 09:28:10 -0700 Subject: Request for reviews (M): 7201026: add vector for shift count In-Reply-To: References: <50625FC2.1050900@oracle.com> Message-ID: <5069C49A.80303@oracle.com> On 10/1/2012 5:20 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~kvn/7201026/webrev > It looks good. > Why do we need a different node type for left and right shifts? Wouldn't a single one be sufficient? > > Roland. For ARM, right-shift values need to be negative :-) dl From roland.westrelin at oracle.com Mon Oct 1 09:42:47 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 1 Oct 2012 18:42:47 +0200 Subject: RFR (L): 7173584: Implement arraycopy as a macro node In-Reply-To: <5064AF8B.1090509@oracle.com> References: <9CAF8242-736B-4B8B-8926-3451DA87AF70@oracle.com> <5064AF8B.1090509@oracle.com> Message-ID: <317A0474-32A8-4C0C-8668-FA2682B4E815@oracle.com> > Also instead of duplicating gen_subtype_check() in macroArrayCopy.cpp can you modify the original one to work for you (by passing additional flag)? This (on top of previous webrev - I've done only minimal testing)? http://cr.openjdk.java.net/~roland/7173584/webrev.02/ Or do we want gvn_transform/gvn_transform_ctrl to be virtual methods of PhaseGVN/PhaseIterGVN? Roland. From vladimir.kozlov at oracle.com Mon Oct 1 11:41:33 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 01 Oct 2012 11:41:33 -0700 Subject: RFR (L): 7173584: Implement arraycopy as a macro node In-Reply-To: <317A0474-32A8-4C0C-8668-FA2682B4E815@oracle.com> References: <9CAF8242-736B-4B8B-8926-3451DA87AF70@oracle.com> <5064AF8B.1090509@oracle.com> <317A0474-32A8-4C0C-8668-FA2682B4E815@oracle.com> Message-ID: <5069E3DD.6090401@oracle.com> I don't think you need suffix "_any_phase" in the name gen_subtype_check_any_phase(). Just add comment that it is also used in phase Macro. Generally speaking GraphKit class is wrong place for it. May be it should be in base class Phase but keep the code in graphKit.cpp file. You don't need special gvn_transform(). It is already done since Macro phase sets gvn._delay_transform flag to true and: Node *PhaseIterGVN::transform( Node *n ) { if (_delay_transform) { // Register the node but don't optimize for now register_new_node_with_optimizer(n); return n; } gvn_transform_ctrl() should remain to be record_for_igvn() but virtual as you suggested. It would be also nice to factor out IfNode creation into separate method (it used 5 times): + Node* cmp = gvn_transform(new(C, 3) CmpPNode(subklass, superklass), gvn); + Node* bol = gvn_transform(new(C, 2) BoolNode(cmp, BoolTest::eq), gvn); + IfNode* iff = new (C, 2) IfNode(*ctrl, bol, PROB_STATIC_FREQUENT, COUNT_UNKNOWN); + gvn_transform(iff, gvn); + if (!bol->is_Con()) gvn_transform_ctrl(iff, gvn); Next optimization belongs to ConvI2LNode::Value(). May be we should not widen type in ConvI2LNode::Ideal() and Value() if input is singleton (constant). + Node *chk_off_X = LP64_ONLY(NULL) NOT_LP64(chk_off); +#ifdef _LP64 + jint chk_off_con = gvn->find_int_con(chk_off, Type::OffsetBot); + if (chk_off_con != Type::OffsetBot) { + chk_off_X = gvn->longcon((jlong) chk_off_con); + } else { + chk_off_X = gvn_transform(new (C, 2) ConvI2LNode(chk_off), gvn); + } +#endif Thanks, Vladimir Roland Westrelin wrote: >> Also instead of duplicating gen_subtype_check() in macroArrayCopy.cpp can you modify the original one to work for you (by passing additional flag)? > > This (on top of previous webrev - I've done only minimal testing)? > http://cr.openjdk.java.net/~roland/7173584/webrev.02/ > > Or do we want gvn_transform/gvn_transform_ctrl to be virtual methods of PhaseGVN/PhaseIterGVN? > > Roland. From christian.thalinger at oracle.com Mon Oct 1 13:49:43 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 1 Oct 2012 13:49:43 -0700 Subject: Request for reviews (M): 7201026: add vector for shift count In-Reply-To: References: <50625FC2.1050900@oracle.com> Message-ID: <8487D302-1FD1-4145-80BA-579356645FAD@oracle.com> On Oct 1, 2012, at 5:20 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~kvn/7201026/webrev > > It looks good. > Why do we need a different node type for left and right shifts? Wouldn't a single one be sufficient? Where is the multiple-match-rules-per-instruct RFE? -- Chris > > Roland. From christian.thalinger at oracle.com Mon Oct 1 13:52:35 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 1 Oct 2012 13:52:35 -0700 Subject: Request for reviews (M): 7201026: add vector for shift count In-Reply-To: <50625FC2.1050900@oracle.com> References: <50625FC2.1050900@oracle.com> Message-ID: <5B1B93A2-C0E0-4885-A3A4-1C6CDC68F3C6@oracle.com> On Sep 25, 2012, at 6:52 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7201026/webrev > > Add generation of vectors for scalar shift count (same for all shift vector's elements). src/cpu/sparc/vm/sparc.ad: + const int Matcher::vector_shift_count_ideal_reg(int size) { + fatal("vector shift is not supported"); + return Op_RegD; + } It's just a nit but I think we should return -1 here. Someone in the future might be confused. src/share/vm/opto/vectornode.cpp: + ShouldNotReachHere(); Replace with default case and fatal? Otherwise this looks good. -- Chris > > Fixed Test7200264.sh test for RShiftVI case. > > Thanks, > Vladimir From christian.thalinger at oracle.com Mon Oct 1 14:05:27 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 1 Oct 2012 14:05:27 -0700 Subject: RFR (L): 7054512: Compress class pointers after perm gen removal In-Reply-To: <95A84D5B-D743-4CFF-9A59-930A064ADEE3@oracle.com> References: <6980759A-600A-440C-9B4F-BC72D08CFD29@oracle.com> <95A84D5B-D743-4CFF-9A59-930A064ADEE3@oracle.com> Message-ID: <32E23698-5A2E-4650-96D9-1AF8F2699A9D@oracle.com> On Sep 24, 2012, at 12:37 PM, Christian Thalinger wrote: > > On Sep 20, 2012, at 9:25 AM, Roland Westrelin wrote: > >> compilers and SA support for compressed klass pointers. >> >> http://cr.openjdk.java.net/~roland/7054512/webrev.00/ > > src/cpu/sparc/vm/sparc.ad: > > +instruct encodeKlass_not_null(iRegN dst, iRegP src) %{ > + format %{ "encode_heap_oop_not_null $src, $dst" %} > > +instruct decodeKlass_not_null(iRegP dst, iRegN src) %{ > + format %{ "decode_heap_oop_not_null $src, $dst" %} > > Copy-paste typo: oop should be klass. > > src/cpu/x86/vm/x86_64.ad: > > +instruct storeImmNKlass(memory mem, immNKlass src) > ... > + ins_encode %{ > + address con = (address)$src$$constant; > + __ set_narrow_klass($mem$$Address, (Klass*)$src$$constant); > + %} > > con is unused. > > I haven't reviewed all files yet but I'm working on it... The rest looks good. There are some places where the indent is now off and I'd like to get them fixed but it's really up to you. -- Chris > > -- Chris > >> >> Roland. > From christian.thalinger at oracle.com Mon Oct 1 14:45:26 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 1 Oct 2012 14:45:26 -0700 Subject: RFR (M): 7200949: JSR 292: rubybench/bench/time/bench_base64.rb fails with jruby.jar not on boot class path In-Reply-To: <50662AB5.5060507@oracle.com> References: <959EED70-8E45-494E-827F-FC3520F23D93@oracle.com> <01D3593F-FA5E-47BF-B884-FA2EA97D1A11@oracle.com> <99DB5CF1-1AFE-4B95-BC5F-5604084F9E3E@oracle.com> <50662AB5.5060507@oracle.com> Message-ID: <984FD5AB-576B-4DB6-BD27-479EC613E2C4@oracle.com> I submitted a job for the push and it failed because I forgot to add the one new file to the changeset: http://cr.openjdk.java.net/~twisti/7200949/src/share/vm/ci/ciMethodType.hpp.html -- Chris On Sep 28, 2012, at 3:54 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > Christian Thalinger wrote: >> On Sep 27, 2012, at 5:24 PM, John Rose wrote: >>> On Sep 27, 2012, at 4:34 PM, Christian Thalinger wrote: >>> >>>> http://cr.openjdk.java.net/~twisti/7200949 >>>> >>>> 7200949: JSR 292: rubybench/bench/time/bench_base64.rb fails with jruby.jar not on boot class path >>>> Reviewed-by: >>> It looks good. >>> >>> (Having all the references to the jli.MethodType objects makes me wonder if we should have a JVM-internal analog MethodType, to represent resolved signatures. I suppose what we have is reasonably economical.) >>> >>> I'm not fully comfortable with the handshake between Rewriter and CPCache (last diff hunk in cpCache.cpp). Ideally, if you were to redefine _indy_appendix_offset=1 and _indy_method_type_offset=0 it would either Just Work (tm) or throw an assert. It's not clear that this is the case here. >> The problem is the interpreter: it uses f1 to read the appendix. So the appendix has to be at offset 0 and other data after that. >> I can either: >> a) add the offset to the index in the interpreter (then it's fool-proof) or >> b) add an assert to TemplateTable::prepare_invoke: >> + assert(ConstantPoolCacheEntry::_indy_resolved_references_appendix_offset == 0, "index points to 0"); >> I did the latter, made rewriter and cpCache change more generic and updated the webrev. >> -- Chris >>> Maybe this code would help in rewriter.cpp: >>> >>> int ref_index = appendix_index - _indy_appendix_offset; >>> assert(ref_index == method_type_index - _indy_method_type_offset, "consistent offsets"); >>> ... use ref_index in sequel ... >>> >>> And something similar in cpCache.cpp, using a neutral ref_index value. >>> >>> ? John From vladimir.kozlov at oracle.com Mon Oct 1 14:46:54 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 01 Oct 2012 14:46:54 -0700 Subject: RFR (M): 7200949: JSR 292: rubybench/bench/time/bench_base64.rb fails with jruby.jar not on boot class path In-Reply-To: <984FD5AB-576B-4DB6-BD27-479EC613E2C4@oracle.com> References: <959EED70-8E45-494E-827F-FC3520F23D93@oracle.com> <01D3593F-FA5E-47BF-B884-FA2EA97D1A11@oracle.com> <99DB5CF1-1AFE-4B95-BC5F-5604084F9E3E@oracle.com> <50662AB5.5060507@oracle.com> <984FD5AB-576B-4DB6-BD27-479EC613E2C4@oracle.com> Message-ID: <506A0F4E.8020506@oracle.com> But it was in webrev, so it should added (hg add) already. Vladimir Christian Thalinger wrote: > I submitted a job for the push and it failed because I forgot to add the one new file to the changeset: > > http://cr.openjdk.java.net/~twisti/7200949/src/share/vm/ci/ciMethodType.hpp.html > > -- Chris > > On Sep 28, 2012, at 3:54 PM, Vladimir Kozlov wrote: > >> Looks good. >> >> Vladimir >> >> Christian Thalinger wrote: >>> On Sep 27, 2012, at 5:24 PM, John Rose wrote: >>>> On Sep 27, 2012, at 4:34 PM, Christian Thalinger wrote: >>>> >>>>> http://cr.openjdk.java.net/~twisti/7200949 >>>>> >>>>> 7200949: JSR 292: rubybench/bench/time/bench_base64.rb fails with jruby.jar not on boot class path >>>>> Reviewed-by: >>>> It looks good. >>>> >>>> (Having all the references to the jli.MethodType objects makes me wonder if we should have a JVM-internal analog MethodType, to represent resolved signatures. I suppose what we have is reasonably economical.) >>>> >>>> I'm not fully comfortable with the handshake between Rewriter and CPCache (last diff hunk in cpCache.cpp). Ideally, if you were to redefine _indy_appendix_offset=1 and _indy_method_type_offset=0 it would either Just Work (tm) or throw an assert. It's not clear that this is the case here. >>> The problem is the interpreter: it uses f1 to read the appendix. So the appendix has to be at offset 0 and other data after that. >>> I can either: >>> a) add the offset to the index in the interpreter (then it's fool-proof) or >>> b) add an assert to TemplateTable::prepare_invoke: >>> + assert(ConstantPoolCacheEntry::_indy_resolved_references_appendix_offset == 0, "index points to 0"); >>> I did the latter, made rewriter and cpCache change more generic and updated the webrev. >>> -- Chris >>>> Maybe this code would help in rewriter.cpp: >>>> >>>> int ref_index = appendix_index - _indy_appendix_offset; >>>> assert(ref_index == method_type_index - _indy_method_type_offset, "consistent offsets"); >>>> ... use ref_index in sequel ... >>>> >>>> And something similar in cpCache.cpp, using a neutral ref_index value. >>>> >>>> ? John > From christian.thalinger at oracle.com Mon Oct 1 14:51:25 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 1 Oct 2012 14:51:25 -0700 Subject: RFR (M): 7200949: JSR 292: rubybench/bench/time/bench_base64.rb fails with jruby.jar not on boot class path In-Reply-To: <506A0F4E.8020506@oracle.com> References: <959EED70-8E45-494E-827F-FC3520F23D93@oracle.com> <01D3593F-FA5E-47BF-B884-FA2EA97D1A11@oracle.com> <99DB5CF1-1AFE-4B95-BC5F-5604084F9E3E@oracle.com> <50662AB5.5060507@oracle.com> <984FD5AB-576B-4DB6-BD27-479EC613E2C4@oracle.com> <506A0F4E.8020506@oracle.com> Message-ID: On Oct 1, 2012, at 2:46 PM, Vladimir Kozlov wrote: > But it was in webrev, so it should added (hg add) already. It was? Weird. Anyway, I'm pushing then :-) -- Chris > > Vladimir > > Christian Thalinger wrote: >> I submitted a job for the push and it failed because I forgot to add the one new file to the changeset: >> http://cr.openjdk.java.net/~twisti/7200949/src/share/vm/ci/ciMethodType.hpp.html >> -- Chris >> On Sep 28, 2012, at 3:54 PM, Vladimir Kozlov wrote: >>> Looks good. >>> >>> Vladimir >>> >>> Christian Thalinger wrote: >>>> On Sep 27, 2012, at 5:24 PM, John Rose wrote: >>>>> On Sep 27, 2012, at 4:34 PM, Christian Thalinger wrote: >>>>> >>>>>> http://cr.openjdk.java.net/~twisti/7200949 >>>>>> >>>>>> 7200949: JSR 292: rubybench/bench/time/bench_base64.rb fails with jruby.jar not on boot class path >>>>>> Reviewed-by: >>>>> It looks good. >>>>> >>>>> (Having all the references to the jli.MethodType objects makes me wonder if we should have a JVM-internal analog MethodType, to represent resolved signatures. I suppose what we have is reasonably economical.) >>>>> >>>>> I'm not fully comfortable with the handshake between Rewriter and CPCache (last diff hunk in cpCache.cpp). Ideally, if you were to redefine _indy_appendix_offset=1 and _indy_method_type_offset=0 it would either Just Work (tm) or throw an assert. It's not clear that this is the case here. >>>> The problem is the interpreter: it uses f1 to read the appendix. So the appendix has to be at offset 0 and other data after that. >>>> I can either: >>>> a) add the offset to the index in the interpreter (then it's fool-proof) or >>>> b) add an assert to TemplateTable::prepare_invoke: >>>> + assert(ConstantPoolCacheEntry::_indy_resolved_references_appendix_offset == 0, "index points to 0"); >>>> I did the latter, made rewriter and cpCache change more generic and updated the webrev. >>>> -- Chris >>>>> Maybe this code would help in rewriter.cpp: >>>>> >>>>> int ref_index = appendix_index - _indy_appendix_offset; >>>>> assert(ref_index == method_type_index - _indy_method_type_offset, "consistent offsets"); >>>>> ... use ref_index in sequel ... >>>>> >>>>> And something similar in cpCache.cpp, using a neutral ref_index value. >>>>> >>>>> ? John From vladimir.kozlov at oracle.com Mon Oct 1 15:13:07 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 01 Oct 2012 15:13:07 -0700 Subject: Request for reviews (M): 7201026: add vector for shift count In-Reply-To: <8487D302-1FD1-4145-80BA-579356645FAD@oracle.com> References: <50625FC2.1050900@oracle.com> <8487D302-1FD1-4145-80BA-579356645FAD@oracle.com> Message-ID: <506A1573.1030301@oracle.com> We already have it, adlparse.cpp: else if (!strcmp(ident, "match")) { // Allow one instruction have several match rules. It looks like I added it 6 years ago :) https://jbs.oracle.com/bugs/browse/JDK-6460965 I tried with this changes and it works :O I will update webrev and resend it after some testing. Thanks, Vladimir Christian Thalinger wrote: > On Oct 1, 2012, at 5:20 AM, Roland Westrelin wrote: > >>> http://cr.openjdk.java.net/~kvn/7201026/webrev >> It looks good. >> Why do we need a different node type for left and right shifts? Wouldn't a single one be sufficient? > > Where is the multiple-match-rules-per-instruct RFE? -- Chris > >> Roland. > From vladimir.kozlov at oracle.com Mon Oct 1 16:28:04 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 01 Oct 2012 16:28:04 -0700 Subject: Request for reviews (M): 7201026: add vector for shift count In-Reply-To: <5B1B93A2-C0E0-4885-A3A4-1C6CDC68F3C6@oracle.com> References: <50625FC2.1050900@oracle.com> <5B1B93A2-C0E0-4885-A3A4-1C6CDC68F3C6@oracle.com> Message-ID: <506A2704.9060503@oracle.com> I updated webrev with suggested changes: http://cr.openjdk.java.net/~kvn/7201026/webrev.01 Thanks, Vladimir Christian Thalinger wrote: > On Sep 25, 2012, at 6:52 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7201026/webrev >> >> Add generation of vectors for scalar shift count (same for all shift vector's elements). > > src/cpu/sparc/vm/sparc.ad: > > + const int Matcher::vector_shift_count_ideal_reg(int size) { > + fatal("vector shift is not supported"); > + return Op_RegD; > + } > > It's just a nit but I think we should return -1 here. Someone in the future might be confused. > > src/share/vm/opto/vectornode.cpp: > > + ShouldNotReachHere(); > > Replace with default case and fatal? > > Otherwise this looks good. > > -- Chris > >> Fixed Test7200264.sh test for RShiftVI case. >> >> Thanks, >> Vladimir > From christian.thalinger at oracle.com Mon Oct 1 16:43:21 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Mon, 01 Oct 2012 23:43:21 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7200949: JSR 292: rubybench/bench/time/bench_base64.rb fails with jruby.jar not on boot class path Message-ID: <20121001234326.2C50747154@hg.openjdk.java.net> Changeset: f6b0eb4e44cf Author: twisti Date: 2012-10-01 14:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f6b0eb4e44cf 7200949: JSR 292: rubybench/bench/time/bench_base64.rb fails with jruby.jar not on boot class path Reviewed-by: jrose, kvn ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciClassList.hpp + src/share/vm/ci/ciMethodType.hpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp From vladimir.kozlov at oracle.com Tue Oct 2 07:07:08 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 2 Oct 2012 07:07:08 -0700 Subject: RFR (L): 7173584: Implement arraycopy as a macro node In-Reply-To: <5069E3DD.6090401@oracle.com> References: <9CAF8242-736B-4B8B-8926-3451DA87AF70@oracle.com> <5064AF8B.1090509@oracle.com> <317A0474-32A8-4C0C-8668-FA2682B4E815@oracle.com> <5069E3DD.6090401@oracle.com> Message-ID: <0F7A2E01-C399-46D3-A6D4-5361F6C0F8B5@oracle.com> Roland, Leave your ConvI2L code as it is. It is ugly but touching ConI2LNode::Ideal() and Value() methods is a little dangerous. We better do it as separate change. Thanks, Vladimir On Oct 1, 2012, at 11:41 AM, Vladimir Kozlov wrote: > I don't think you need suffix "_any_phase" in the name gen_subtype_check_any_phase(). Just add comment that it is also used in phase Macro. Generally speaking GraphKit class is wrong place for it. May be it should be in base class Phase but keep the code in graphKit.cpp file. > > You don't need special gvn_transform(). It is already done since Macro phase sets gvn._delay_transform flag to true and: > > Node *PhaseIterGVN::transform( Node *n ) { > if (_delay_transform) { > // Register the node but don't optimize for now > register_new_node_with_optimizer(n); > return n; > } > > gvn_transform_ctrl() should remain to be record_for_igvn() but virtual as you suggested. > > It would be also nice to factor out IfNode creation into separate method (it used 5 times): > > + Node* cmp = gvn_transform(new(C, 3) CmpPNode(subklass, superklass), gvn); > + Node* bol = gvn_transform(new(C, 2) BoolNode(cmp, BoolTest::eq), gvn); > + IfNode* iff = new (C, 2) IfNode(*ctrl, bol, PROB_STATIC_FREQUENT, COUNT_UNKNOWN); > + gvn_transform(iff, gvn); > + if (!bol->is_Con()) gvn_transform_ctrl(iff, gvn); > > > Next optimization belongs to ConvI2LNode::Value(). May be we should not widen type in ConvI2LNode::Ideal() and Value() if input is singleton (constant). > > + Node *chk_off_X = LP64_ONLY(NULL) NOT_LP64(chk_off); > +#ifdef _LP64 > + jint chk_off_con = gvn->find_int_con(chk_off, Type::OffsetBot); > + if (chk_off_con != Type::OffsetBot) { > + chk_off_X = gvn->longcon((jlong) chk_off_con); > + } else { > + chk_off_X = gvn_transform(new (C, 2) ConvI2LNode(chk_off), gvn); > + } > +#endif > > Thanks, > Vladimir > > > Roland Westrelin wrote: >>> Also instead of duplicating gen_subtype_check() in macroArrayCopy.cpp can you modify the original one to work for you (by passing additional flag)? >> This (on top of previous webrev - I've done only minimal testing)? >> http://cr.openjdk.java.net/~roland/7173584/webrev.02/ >> Or do we want gvn_transform/gvn_transform_ctrl to be virtual methods of PhaseGVN/PhaseIterGVN? >> Roland. From christian.thalinger at oracle.com Tue Oct 2 09:58:44 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 2 Oct 2012 09:58:44 -0700 Subject: Request for reviews (M): 7201026: add vector for shift count In-Reply-To: <506A1573.1030301@oracle.com> References: <50625FC2.1050900@oracle.com> <8487D302-1FD1-4145-80BA-579356645FAD@oracle.com> <506A1573.1030301@oracle.com> Message-ID: <3F680114-5D04-4192-9E29-F154A7792B47@oracle.com> On Oct 1, 2012, at 3:13 PM, Vladimir Kozlov wrote: > We already have it, adlparse.cpp: > > else if (!strcmp(ident, "match")) { > // Allow one instruction have several match rules. > > It looks like I added it 6 years ago :) :-D -- Chris > > https://jbs.oracle.com/bugs/browse/JDK-6460965 > > I tried with this changes and it works :O > > I will update webrev and resend it after some testing. > > Thanks, > Vladimir > > Christian Thalinger wrote: >> On Oct 1, 2012, at 5:20 AM, Roland Westrelin wrote: >>>> http://cr.openjdk.java.net/~kvn/7201026/webrev >>> It looks good. >>> Why do we need a different node type for left and right shifts? Wouldn't a single one be sufficient? >> Where is the multiple-match-rules-per-instruct RFE? -- Chris >>> Roland. From christian.thalinger at oracle.com Tue Oct 2 10:01:34 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 2 Oct 2012 10:01:34 -0700 Subject: Request for reviews (M): 7201026: add vector for shift count In-Reply-To: <506A2704.9060503@oracle.com> References: <50625FC2.1050900@oracle.com> <5B1B93A2-C0E0-4885-A3A4-1C6CDC68F3C6@oracle.com> <506A2704.9060503@oracle.com> Message-ID: <9E7A44A2-2EC5-41E5-868E-5E5C6FA78BDF@oracle.com> On Oct 1, 2012, at 4:28 PM, Vladimir Kozlov wrote: > I updated webrev with suggested changes: > > http://cr.openjdk.java.net/~kvn/7201026/webrev.01 Looks better. Great we re-discovered the multiple-match-rules. It's funny that you added it but we never used it. -- Chris > > Thanks, > Vladimir > > Christian Thalinger wrote: >> On Sep 25, 2012, at 6:52 PM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/7201026/webrev >>> >>> Add generation of vectors for scalar shift count (same for all shift vector's elements). >> src/cpu/sparc/vm/sparc.ad: >> + const int Matcher::vector_shift_count_ideal_reg(int size) { >> + fatal("vector shift is not supported"); >> + return Op_RegD; >> + } >> It's just a nit but I think we should return -1 here. Someone in the future might be confused. >> src/share/vm/opto/vectornode.cpp: >> + ShouldNotReachHere(); >> Replace with default case and fatal? >> Otherwise this looks good. >> -- Chris >>> Fixed Test7200264.sh test for RShiftVI case. >>> >>> Thanks, >>> Vladimir From vladimir.kozlov at oracle.com Tue Oct 2 10:18:27 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Oct 2012 10:18:27 -0700 Subject: Request for reviews (S): 7199742: A lot of C2 OSR compilations of the same method's bci In-Reply-To: <0C262CFD-6F93-46EA-AB54-32E8BD88CDE7@oracle.com> References: <505A7F61.4000801@oracle.com> <3A2DB7F0-75F0-4AB4-8B7C-F1B89038027C@oracle.com> <505B2CCD.4040008@oracle.com> <0C262CFD-6F93-46EA-AB54-32E8BD88CDE7@oracle.com> Message-ID: <506B21E3.80809@oracle.com> I would like to push it as it is. We can look on how to verify ciTypeFlow later if we hit a problem again. Thanks, Vladimir Christian Thalinger wrote: > On Sep 20, 2012, at 7:48 AM, Vladimir Kozlov wrote: > >> On 9/19/12 11:19 PM, John Rose wrote: >>> On Sep 19, 2012, at 7:28 PM, Vladimir Kozlov wrote: >>> >>>> http://cr.openjdk.java.net/~kvn/7199742/webrev >>>> >>>> CI type flow analysis clone the head of OSR loop and as result the type of locals is incorrect in osr_start block in ciTypeFlow info. C2 generates runtime checks for locals and uncommon_trap to verify that OSR information is correct during execution. The code hit the uncommon trap, method is deoptimized, C2 does the same osr compilation again. And this repeats until PerMethodRecompilationCutoff/2 (200) is reached. >>>> >>>> Don't clone the head of OSR loop. >>> This is a reasonable fix. >>> >>> Here's the part I'm missing: How do we ensure that we find the problem if something similar happens again? By "similar" I mean a serious inaccuracy in the ciTypeFlow type model. >>> >>> Perhaps we could add an assert which would detect the problem (e.g., null type at OSR entry point) and raise an error. Ideally, if you were to comment out your fix but put in the assert, it would fire immediately on your test case. >> You need some kind of duplicated type flow analysis for that. It is not simple null or not null, the local may stay null if it is not updated in a loop but after it. > > It would be nice to have some extra machinery that verifies the type model but is it worth the effort? How many bugs did we have in the past? The only thing I'm worried is that bugs like this one might go by unnoticed because it just triggers some weird compilations (and possibly a slowdown). > > -- Chris > >> Vladimir >> >>> ? John >>> >>> > From john.r.rose at oracle.com Tue Oct 2 10:30:07 2012 From: john.r.rose at oracle.com (John Rose) Date: Tue, 2 Oct 2012 10:30:07 -0700 Subject: Request for reviews (S): 7199742: A lot of C2 OSR compilations of the same method's bci In-Reply-To: <506B21E3.80809@oracle.com> References: <505A7F61.4000801@oracle.com> <3A2DB7F0-75F0-4AB4-8B7C-F1B89038027C@oracle.com> <505B2CCD.4040008@oracle.com> <0C262CFD-6F93-46EA-AB54-32E8BD88CDE7@oracle.com> <506B21E3.80809@oracle.com> Message-ID: On Oct 2, 2012, at 10:18 AM, Vladimir Kozlov wrote: > I would like to push it as it is. We can look on how to verify ciTypeFlow later if we hit a problem again. Yes, go ahead and push it as it is. I wish it could be an error (instead of an uncommon trap) for the data-dependent preconditions to be false on entry to an OSR method. But as we talked about at lunch, and as the code in load_interpreter_state and check_interpreter_type points out, there are sometimes reasonable circumstances when an OSR method will encounter a type that TypeFlow does not expect. The basic reason is that TypeFlow deletes paths which the interpreter can later add. Comment from parse1: // The unexpected type happens because a new edge is active // in the CFG, which typeflow had previously ignored. // E.g., Object x = coldAtFirst() && notReached()? "str": new Integer(123). // This x will be typed as Integer if notReached is not yet linked. Idea: Consider using a more distinctive DeoptReason for this case. We have Reason_unreached; maybe use Reason_constraint instead. Thanks, ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121002/a476e0ed/attachment.html From vladimir.kozlov at oracle.com Tue Oct 2 10:42:43 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Oct 2012 10:42:43 -0700 Subject: Request for reviews (M): 7201026: add vector for shift count In-Reply-To: <9E7A44A2-2EC5-41E5-868E-5E5C6FA78BDF@oracle.com> References: <50625FC2.1050900@oracle.com> <5B1B93A2-C0E0-4885-A3A4-1C6CDC68F3C6@oracle.com> <506A2704.9060503@oracle.com> <9E7A44A2-2EC5-41E5-868E-5E5C6FA78BDF@oracle.com> Message-ID: <506B2793.6030502@oracle.com> Thanks, Christian I think the problem (at least for vectors) with usage of multiple-match-rules is it can't be used if mach nodes have different predicates. Thanks, Vladimir Christian Thalinger wrote: > On Oct 1, 2012, at 4:28 PM, Vladimir Kozlov wrote: > >> I updated webrev with suggested changes: >> >> http://cr.openjdk.java.net/~kvn/7201026/webrev.01 > > Looks better. Great we re-discovered the multiple-match-rules. It's funny that you added it but we never used it. > > -- Chris > >> Thanks, >> Vladimir >> >> Christian Thalinger wrote: >>> On Sep 25, 2012, at 6:52 PM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/7201026/webrev >>>> >>>> Add generation of vectors for scalar shift count (same for all shift vector's elements). >>> src/cpu/sparc/vm/sparc.ad: >>> + const int Matcher::vector_shift_count_ideal_reg(int size) { >>> + fatal("vector shift is not supported"); >>> + return Op_RegD; >>> + } >>> It's just a nit but I think we should return -1 here. Someone in the future might be confused. >>> src/share/vm/opto/vectornode.cpp: >>> + ShouldNotReachHere(); >>> Replace with default case and fatal? >>> Otherwise this looks good. >>> -- Chris >>>> Fixed Test7200264.sh test for RShiftVI case. >>>> >>>> Thanks, >>>> Vladimir > From vladimir.kozlov at oracle.com Tue Oct 2 10:46:19 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Oct 2012 10:46:19 -0700 Subject: Request for reviews (S): 7199742: A lot of C2 OSR compilations of the same method's bci In-Reply-To: References: <505A7F61.4000801@oracle.com> <3A2DB7F0-75F0-4AB4-8B7C-F1B89038027C@oracle.com> <505B2CCD.4040008@oracle.com> <0C262CFD-6F93-46EA-AB54-32E8BD88CDE7@oracle.com> <506B21E3.80809@oracle.com> Message-ID: <506B286B.8050303@oracle.com> Thank you, John I will look on Reason_constraint. Current usage of Reason_unreached for runtime verification of OSR input types is confusing. I agree, that Reason_constraint is more suited for this. Thanks, Vladimir John Rose wrote: > On Oct 2, 2012, at 10:18 AM, Vladimir Kozlov wrote: > >> I would like to push it as it is. We can look on how to verify >> ciTypeFlow later if we hit a problem again. > > Yes, go ahead and push it as it is. > > I wish it could be an error (instead of an uncommon trap) for the > data-dependent preconditions to be false on entry to an OSR method. But > as we talked about at lunch, and as the code in load_interpreter_state > and check_interpreter_type points out, there are sometimes reasonable > circumstances when an OSR method will encounter a type that TypeFlow > does not expect. The basic reason is that TypeFlow deletes paths which > the interpreter can later add. Comment from parse1: > // The unexpected type happens because a new edge is active > // in the CFG, which typeflow had previously ignored. > // E.g., Object x = coldAtFirst() && notReached()? "str": new > Integer(123). > // This x will be typed as Integer if notReached is not yet linked. > > Idea: Consider using a more distinctive DeoptReason for this case. We > have Reason_unreached; maybe use Reason_constraint instead. > > Thanks, > > ? John From vladimir.kozlov at oracle.com Tue Oct 2 14:45:45 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 02 Oct 2012 21:45:45 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7201026: add vector for shift count Message-ID: <20121002214549.7DC7E4716B@hg.openjdk.java.net> Changeset: 859c45fb8cea Author: kvn Date: 2012-10-02 12:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/859c45fb8cea 7201026: add vector for shift count Summary: Add generation of vectors for scalar shift count. Reviewed-by: roland, twisti, dlong ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp ! test/compiler/7200264/Test7200264.sh From vladimir.kozlov at oracle.com Tue Oct 2 16:52:10 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 02 Oct 2012 23:52:10 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7199742: A lot of C2 OSR compilations of the same method's bci Message-ID: <20121002235220.A41B44716C@hg.openjdk.java.net> Changeset: f13867c41f73 Author: kvn Date: 2012-10-02 14:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f13867c41f73 7199742: A lot of C2 OSR compilations of the same method's bci Summary: Don't clone head of OSR loop. Reviewed-by: jrose, twisti ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/opto/parse1.cpp + test/compiler/7199742/Test7199742.java From roland.westrelin at oracle.com Wed Oct 3 08:33:28 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 3 Oct 2012 17:33:28 +0200 Subject: RFR (L): 7054512: Compress class pointers after perm gen removal In-Reply-To: <32E23698-5A2E-4650-96D9-1AF8F2699A9D@oracle.com> References: <6980759A-600A-440C-9B4F-BC72D08CFD29@oracle.com> <95A84D5B-D743-4CFF-9A59-930A064ADEE3@oracle.com> <32E23698-5A2E-4650-96D9-1AF8F2699A9D@oracle.com> Message-ID: <44446827-39E2-46D0-B510-73C3F11A528D@oracle.com> Chris, Thanks for the review and the suggestions. > There are some places where the indent is now off and I'd like to get them fixed but it's really up to you. Is this why you are referring to? case T_ARRAY: return new (C) ConPNode( t->is_aryptr() ); case T_ADDRESS: return new (C) ConPNode( t->is_ptr() ); case T_NARROWOOP: return new (C) ConNNode( t->is_narrowoop() ); + case T_NARROWKLASS: return new (C) ConNKlassNode( t->is_narrowklass() ); case T_METADATA: return new (C) ConPNode( t->is_ptr() ); I would personally try to restrict the changeset to the lines that contribute to the feature. Is there an agreed coding "policy" for this? Roland. From christian.thalinger at oracle.com Wed Oct 3 11:06:05 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 3 Oct 2012 11:06:05 -0700 Subject: RFR (L): 7054512: Compress class pointers after perm gen removal In-Reply-To: <44446827-39E2-46D0-B510-73C3F11A528D@oracle.com> References: <6980759A-600A-440C-9B4F-BC72D08CFD29@oracle.com> <95A84D5B-D743-4CFF-9A59-930A064ADEE3@oracle.com> <32E23698-5A2E-4650-96D9-1AF8F2699A9D@oracle.com> <44446827-39E2-46D0-B510-73C3F11A528D@oracle.com> Message-ID: <1FC76AB5-E1FD-41D4-B5AB-781CF10237C4@oracle.com> On Oct 3, 2012, at 8:33 AM, Roland Westrelin wrote: > Chris, > > Thanks for the review and the suggestions. > >> There are some places where the indent is now off and I'd like to get them fixed but it's really up to you. > > Is this why you are referring to? > > case T_ARRAY: return new (C) ConPNode( t->is_aryptr() ); > case T_ADDRESS: return new (C) ConPNode( t->is_ptr() ); > case T_NARROWOOP: return new (C) ConNNode( t->is_narrowoop() ); > + case T_NARROWKLASS: return new (C) ConNKlassNode( t->is_narrowklass() ); > case T_METADATA: return new (C) ConPNode( t->is_ptr() ); Yeah, or this: http://cr.openjdk.java.net/~roland/7054512/webrev.00/src/share/vm/runtime/vmStructs.cpp.udiff.html > > I would personally try to restrict the changeset to the lines that contribute to the feature. Is there an agreed coding "policy" for this? I don't think so. People have different preferences. But when I see code that is tidily arranged I usually keep that. As I said, it's up to you. -- Chris > > Roland. From john.r.rose at oracle.com Wed Oct 3 18:02:38 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 3 Oct 2012 18:02:38 -0700 Subject: RFR (L): 7054512: Compress class pointers after perm gen removal In-Reply-To: <1FC76AB5-E1FD-41D4-B5AB-781CF10237C4@oracle.com> References: <6980759A-600A-440C-9B4F-BC72D08CFD29@oracle.com> <95A84D5B-D743-4CFF-9A59-930A064ADEE3@oracle.com> <32E23698-5A2E-4650-96D9-1AF8F2699A9D@oracle.com> <44446827-39E2-46D0-B510-73C3F11A528D@oracle.com> <1FC76AB5-E1FD-41D4-B5AB-781CF10237C4@oracle.com> Message-ID: <374CD0AA-2A92-4DBD-812E-347F5121F5BB@oracle.com> On Oct 3, 2012, at 11:06 AM, Christian Thalinger wrote: >> I would personally try to restrict the changeset to the lines that contribute to the feature. Is there an agreed coding "policy" for this? > > I don't think so. People have different preferences. But when I see code that is tidily arranged I usually keep that. As I said, it's up to you. Personally, I prefer to include simple cleanups in my changesets, if they are near to the essential changes. Cleanup changes can make integration more expensive, when they interfere with other people's unrelated changes. The opposing cost is of making cleanups so disproportionately inconvenient that they (in practice) never happen; the result will be a software base that looks like compost. On balance, we need to feel free to tidy up small messes as we come across them. And to use social pressure and good sense (before formal process) to regulate the flow of such changes. (That means things like, "please give me a heads-up the next time you do something like that". I see that hand...) I believe we do not want to be in the habit of filing bugs of the form "adjust indentation in the foo method". A few "adjust indentation" bugs are perfectly rational, if they batch up lots of similar problems. But realistically speaking, many cleanups will happen on the fly, and will either accompany the main change, or never be done. BTW, I am advocating (mainly) a "Lumper" point of view here, since that is my personal bent. http://en.wikipedia.org/wiki/Lumpers_and_splitters A "Splitter" will be more uncomfortable with a miscellaneous changeset, since it does more than Just One Thing. But even if you are a Splitter, you will probably admit that some tasks are too small to merit their own bug, which makes us both Lumpers; perhaps we would differ about the correct grouping algorithm for making the best Lumps. That takes me back to my original point: A practical changeset may include small changes in addition to its nominal change, if those changes are (somehow) reasonably close to the main change. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121003/337aed15/attachment.html From nils.eliasson at oracle.com Thu Oct 4 01:52:39 2012 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 04 Oct 2012 10:52:39 +0200 Subject: Request for reviews (XS): 8000102 - Resolve include conflicts Message-ID: <506D4E57.8050208@oracle.com> Removing include of c1/c1_runtime.hpp and opto/runtime.hpp from all os-files. http://cr.openjdk.java.net/~neliasso/8000102/webrev.02/ Thanks, Nils From vladimir.kozlov at oracle.com Thu Oct 4 07:47:18 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 04 Oct 2012 07:47:18 -0700 Subject: Request for reviews (XS): 8000102 - Resolve include conflicts In-Reply-To: <506D4E57.8050208@oracle.com> References: <506D4E57.8050208@oracle.com> Message-ID: <506DA176.1070503@oracle.com> Looks good. Vladimir Nils Eliasson wrote: > Removing include of c1/c1_runtime.hpp and opto/runtime.hpp from all > os-files. > > http://cr.openjdk.java.net/~neliasso/8000102/webrev.02/ > > > Thanks, > Nils From vladimir.x.ivanov at oracle.com Thu Oct 4 15:04:04 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 05 Oct 2012 02:04:04 +0400 Subject: RFR (S): 8000232: NPG: SIGSEGV in Dependencies::DepStream::check_klass_dependency on solaris-x64 Message-ID: <506E07D4.2070405@oracle.com> http://cr.openjdk.java.net/~vlivanov/8000232/webrev.00 22 lines changed: 10 ins; 4 del; 8 mod Context type of a dependency is encoded as NULL only when it is explicit and the context is "default" (see Dependencies::ctxk_encoded_as_null). Decoding takes place only in Dependencies::DepStream::context_type(), however the value is used in other places. The problem is that no decoding is performed when dependencies are logged using Dependencies::write_dependency_to, but only non-NULL values are expected in the code. The bug existed before NPG, it simply didn't cause a crash. Fixed by moving decoding into Dependencies::DepStream::argument, so no caller could see encoded context value (NULL) anymore. It also improves TraceDependencies & LogCompilation output: dependency context is always correctly displayed. Also, did some cleanup. Testing: failing test, JPRT w/ logging turned on & off, CTW on solaris_x64. Best regards, Vladimir Ivanov From christian.thalinger at oracle.com Thu Oct 4 15:48:44 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 4 Oct 2012 15:48:44 -0700 Subject: RFR (S): 8000232: NPG: SIGSEGV in Dependencies::DepStream::check_klass_dependency on solaris-x64 In-Reply-To: <506E07D4.2070405@oracle.com> References: <506E07D4.2070405@oracle.com> Message-ID: On Oct 4, 2012, at 3:04 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8000232/webrev.00 > 22 lines changed: 10 ins; 4 del; 8 mod > > Context type of a dependency is encoded as NULL only when it is explicit and the context is "default" (see Dependencies::ctxk_encoded_as_null). Decoding takes place only in Dependencies::DepStream::context_type(), however the value is used in other places. > > The problem is that no decoding is performed when dependencies are logged using Dependencies::write_dependency_to, but only non-NULL values are expected in the code. The bug existed before NPG, it simply didn't cause a crash. > > Fixed by moving decoding into Dependencies::DepStream::argument, so no caller could see encoded context value (NULL) anymore. Is this assert still valid then? assert(result == NULL || result->is_klass() || result->is_method(), "must be"); -- Chris > > It also improves TraceDependencies & LogCompilation output: dependency context is always correctly displayed. > > Also, did some cleanup. > > Testing: failing test, JPRT w/ logging turned on & off, CTW on solaris_x64. > > Best regards, > Vladimir Ivanov From christian.thalinger at oracle.com Thu Oct 4 15:51:09 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 4 Oct 2012 15:51:09 -0700 Subject: RFR (S): 8000263: JSR 292: signature types may appear to be unloaded Message-ID: <0B96CD2D-5DAB-4989-8672-CD1E569B9BC6@oracle.com> http://cr.openjdk.java.net/~twisti/8000263 8000263: JSR 292: signature types may appear to be unloaded Reviewed-by: The problem is in the intrinsification code for Unsafe.getObject. Usually field accesses with get/putfield resolve the field when parsing the bytecode. ciBytecodeStream::get_field calls ciField::will_link which puts class loader constraints for the signature types in place. In LibraryCallKit::inline_unsafe_access we create a ciField object for the field we are accessing but with the ciField's type left uninitialized. When calling ciField::type we try to look up the field type lazily which fails because we never resolved the field and put class loader constraints in place. There are two ways to fix it. The first one is two return java/lang/Object as field type if the computed type is unloaded. The second fix is to turn on LinkWellKnowClasses by default. LinkWellKnownClasses only works if the field type is java/lang/Object, for user types we need to other fix. The change also renames the WK_KLASSES_DO macro argument template with do_klass because template is a reserved keyword in C++. src/share/vm/classfile/systemDictionary.cpp src/share/vm/classfile/systemDictionary.hpp src/share/vm/opto/library_call.cpp src/share/vm/runtime/globals.hpp From vladimir.kozlov at oracle.com Thu Oct 4 16:06:54 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 04 Oct 2012 16:06:54 -0700 Subject: RFR (S): 8000263: JSR 292: signature types may appear to be unloaded In-Reply-To: <0B96CD2D-5DAB-4989-8672-CD1E569B9BC6@oracle.com> References: <0B96CD2D-5DAB-4989-8672-CD1E569B9BC6@oracle.com> Message-ID: <506E168E.7090800@oracle.com> Good. Thanks, Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8000263 > > 8000263: JSR 292: signature types may appear to be unloaded > Reviewed-by: > > The problem is in the intrinsification code for Unsafe.getObject. > Usually field accesses with get/putfield resolve the field when > parsing the bytecode. ciBytecodeStream::get_field calls > ciField::will_link which puts class loader constraints for the > signature types in place. In LibraryCallKit::inline_unsafe_access we > create a ciField object for the field we are accessing but with the > ciField's type left uninitialized. When calling ciField::type we try > to look up the field type lazily which fails because we never resolved > the field and put class loader constraints in place. > > There are two ways to fix it. The first one is two return > java/lang/Object as field type if the computed type is unloaded. The > second fix is to turn on LinkWellKnowClasses by default. > LinkWellKnownClasses only works if the field type is java/lang/Object, > for user types we need to other fix. > > The change also renames the WK_KLASSES_DO macro argument template with > do_klass because template is a reserved keyword in C++. > > src/share/vm/classfile/systemDictionary.cpp > src/share/vm/classfile/systemDictionary.hpp > src/share/vm/opto/library_call.cpp > src/share/vm/runtime/globals.hpp > From vladimir.x.ivanov at oracle.com Thu Oct 4 16:22:04 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 05 Oct 2012 03:22:04 +0400 Subject: RFR (S): 8000232: NPG: SIGSEGV in Dependencies::DepStream::check_klass_dependency on solaris-x64 In-Reply-To: References: <506E07D4.2070405@oracle.com> Message-ID: <506E1A1C.50209@oracle.com> Christian, It's technically possible to store NULL in a dependency, but currently most of the callers expect non-null values to be returned. Since Dependencies::DepStream::argument is a generic function to work with DepStream, which supports storing NULLs, I was reluctant to require non-null value. Best regards, Vladimir Ivanov On 10/5/12 2:48 AM, Christian Thalinger wrote: > > On Oct 4, 2012, at 3:04 PM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8000232/webrev.00 >> 22 lines changed: 10 ins; 4 del; 8 mod >> >> Context type of a dependency is encoded as NULL only when it is explicit and the context is "default" (see Dependencies::ctxk_encoded_as_null). Decoding takes place only in Dependencies::DepStream::context_type(), however the value is used in other places. >> >> The problem is that no decoding is performed when dependencies are logged using Dependencies::write_dependency_to, but only non-NULL values are expected in the code. The bug existed before NPG, it simply didn't cause a crash. >> >> Fixed by moving decoding into Dependencies::DepStream::argument, so no caller could see encoded context value (NULL) anymore. > > Is this assert still valid then? > > assert(result == NULL || result->is_klass() || result->is_method(), "must be"); > > -- Chris > >> >> It also improves TraceDependencies & LogCompilation output: dependency context is always correctly displayed. >> >> Also, did some cleanup. >> >> Testing: failing test, JPRT w/ logging turned on & off, CTW on solaris_x64. >> >> Best regards, >> Vladimir Ivanov > From christian.thalinger at oracle.com Thu Oct 4 16:39:12 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 4 Oct 2012 16:39:12 -0700 Subject: RFR (S): 8000232: NPG: SIGSEGV in Dependencies::DepStream::check_klass_dependency on solaris-x64 In-Reply-To: <506E1A1C.50209@oracle.com> References: <506E07D4.2070405@oracle.com> <506E1A1C.50209@oracle.com> Message-ID: <64EC4512-2DAE-49F4-A001-64609F006A3E@oracle.com> On Oct 4, 2012, at 4:22 PM, Vladimir Ivanov wrote: > Christian, > > It's technically possible to store NULL in a dependency, but currently most of the callers expect non-null values to be returned. > > Since Dependencies::DepStream::argument is a generic function to work with DepStream, which supports storing NULLs, I was reluctant to require non-null value. Right. The change looks good. -- Chris > > Best regards, > Vladimir Ivanov > > On 10/5/12 2:48 AM, Christian Thalinger wrote: >> >> On Oct 4, 2012, at 3:04 PM, Vladimir Ivanov wrote: >> >>> http://cr.openjdk.java.net/~vlivanov/8000232/webrev.00 >>> 22 lines changed: 10 ins; 4 del; 8 mod >>> >>> Context type of a dependency is encoded as NULL only when it is explicit and the context is "default" (see Dependencies::ctxk_encoded_as_null). Decoding takes place only in Dependencies::DepStream::context_type(), however the value is used in other places. >>> >>> The problem is that no decoding is performed when dependencies are logged using Dependencies::write_dependency_to, but only non-NULL values are expected in the code. The bug existed before NPG, it simply didn't cause a crash. >>> >>> Fixed by moving decoding into Dependencies::DepStream::argument, so no caller could see encoded context value (NULL) anymore. >> >> Is this assert still valid then? >> >> assert(result == NULL || result->is_klass() || result->is_method(), "must be"); >> >> -- Chris >> >>> >>> It also improves TraceDependencies & LogCompilation output: dependency context is always correctly displayed. >>> >>> Also, did some cleanup. >>> >>> Testing: failing test, JPRT w/ logging turned on & off, CTW on solaris_x64. >>> >>> Best regards, >>> Vladimir Ivanov >> From vladimir.x.ivanov at oracle.com Thu Oct 4 16:38:35 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 05 Oct 2012 03:38:35 +0400 Subject: RFR (S): 8000232: NPG: SIGSEGV in Dependencies::DepStream::check_klass_dependency on solaris-x64 In-Reply-To: <64EC4512-2DAE-49F4-A001-64609F006A3E@oracle.com> References: <506E07D4.2070405@oracle.com> <506E1A1C.50209@oracle.com> <64EC4512-2DAE-49F4-A001-64609F006A3E@oracle.com> Message-ID: <506E1DFB.20606@oracle.com> Thank you. Best regards, Vladimir Ivanov On 10/5/12 3:39 AM, Christian Thalinger wrote: > > On Oct 4, 2012, at 4:22 PM, Vladimir Ivanov wrote: > >> Christian, >> >> It's technically possible to store NULL in a dependency, but currently most of the callers expect non-null values to be returned. >> >> Since Dependencies::DepStream::argument is a generic function to work with DepStream, which supports storing NULLs, I was reluctant to require non-null value. > > Right. The change looks good. -- Chris > >> >> Best regards, >> Vladimir Ivanov >> >> On 10/5/12 2:48 AM, Christian Thalinger wrote: >>> >>> On Oct 4, 2012, at 3:04 PM, Vladimir Ivanov wrote: >>> >>>> http://cr.openjdk.java.net/~vlivanov/8000232/webrev.00 >>>> 22 lines changed: 10 ins; 4 del; 8 mod >>>> >>>> Context type of a dependency is encoded as NULL only when it is explicit and the context is "default" (see Dependencies::ctxk_encoded_as_null). Decoding takes place only in Dependencies::DepStream::context_type(), however the value is used in other places. >>>> >>>> The problem is that no decoding is performed when dependencies are logged using Dependencies::write_dependency_to, but only non-NULL values are expected in the code. The bug existed before NPG, it simply didn't cause a crash. >>>> >>>> Fixed by moving decoding into Dependencies::DepStream::argument, so no caller could see encoded context value (NULL) anymore. >>> >>> Is this assert still valid then? >>> >>> assert(result == NULL || result->is_klass() || result->is_method(), "must be"); >>> >>> -- Chris >>> >>>> >>>> It also improves TraceDependencies & LogCompilation output: dependency context is always correctly displayed. >>>> >>>> Also, did some cleanup. >>>> >>>> Testing: failing test, JPRT w/ logging turned on & off, CTW on solaris_x64. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>> > From john.r.rose at oracle.com Thu Oct 4 17:12:54 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 4 Oct 2012 17:12:54 -0700 Subject: RFR (S): 8000263: JSR 292: signature types may appear to be unloaded In-Reply-To: <0B96CD2D-5DAB-4989-8672-CD1E569B9BC6@oracle.com> References: <0B96CD2D-5DAB-4989-8672-CD1E569B9BC6@oracle.com> Message-ID: <5C220538-D589-4FA2-92EE-0A357F04777C@oracle.com> On Oct 4, 2012, at 3:51 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8000263 > > 8000263: JSR 292: signature types may appear to be unloaded Good work. I very much like the 'is_public' assertion in 'check_wk_pre_link_klasses'. I mechanically checked that the whitespace change in systemDictionary.hpp is mixed with no other effects, besides changing some occurrences of Pre or Pre_JSR292 to Pre_Link or Pre? Consider changing Opt to Pre for LambdaForm, if you agree that is a reasonable cleanup. That type is no longer optional. I think the following code would be simpler and more directly correct in 'sharpen_unsafe_type': if (sharpened_klass != NULL && !sharpened_klass->is_loaded()) return NULL; Issue: Are intrinsics still properly recognized, even though 'find_well_known_klass' is restricted? The function vmIntrinsics::method_for bothers me still. Maybe add a FIXME comment pointing out that it doesn't work for all intrinsics. Or, add a boolean parameter: Klass* SystemDictionary::find_well_known_klass(Symbol* class_name, bool link_all = false) { ... if (option == Pre_Link || link_all) ... } Or, find a way to get rid of vmIntrinsics::method_for, since it is not used much. Thanks, ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121004/2d9f31d6/attachment-0001.html From john.r.rose at oracle.com Thu Oct 4 17:35:44 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 4 Oct 2012 17:35:44 -0700 Subject: RFR (S): 8000263: JSR 292: signature types may appear to be unloaded In-Reply-To: <5C220538-D589-4FA2-92EE-0A357F04777C@oracle.com> References: <0B96CD2D-5DAB-4989-8672-CD1E569B9BC6@oracle.com> <5C220538-D589-4FA2-92EE-0A357F04777C@oracle.com> Message-ID: <1FA67503-8DCF-4418-86CB-2769544CEF88@oracle.com> On Oct 4, 2012, at 5:12 PM, John Rose wrote: > I mechanically checked ...? Oops; that started as a question and ended as a statement. Please disregard the "?". From vladimir.kozlov at oracle.com Thu Oct 4 17:50:25 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 05 Oct 2012 00:50:25 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8000102: Resolve include conflicts Message-ID: <20121005005030.6EEDF471B9@hg.openjdk.java.net> Changeset: bf2edd3c9b0f Author: neliasso Date: 2012-10-04 06:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bf2edd3c9b0f 8000102: Resolve include conflicts Summary: Removing include of c1/c1_runtime.hpp and opto/runtime.hpp from all os-files. Reviewed-by: kvn Contributed-by: nils.eliasson at oracle.com ! 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/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp From vladimir.kozlov at oracle.com Thu Oct 4 18:15:48 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 04 Oct 2012 18:15:48 -0700 Subject: RFR (S): 8000232: NPG: SIGSEGV in Dependencies::DepStream::check_klass_dependency on solaris-x64 In-Reply-To: <506E07D4.2070405@oracle.com> References: <506E07D4.2070405@oracle.com> Message-ID: <506E34C4.2010100@oracle.com> Could you add != NULL check to the second assert since argument_oop() can return NULL (based on the assert inside)? 707 assert(k->is_klass(), "type check"); Thanks, Vladimir On 10/4/12 3:04 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8000232/webrev.00 > 22 lines changed: 10 ins; 4 del; 8 mod > > Context type of a dependency is encoded as NULL only when it is explicit and the context is "default" (see > Dependencies::ctxk_encoded_as_null). Decoding takes place only in Dependencies::DepStream::context_type(), however the > value is used in other places. > > The problem is that no decoding is performed when dependencies are logged using Dependencies::write_dependency_to, but > only non-NULL values are expected in the code. The bug existed before NPG, it simply didn't cause a crash. > > Fixed by moving decoding into Dependencies::DepStream::argument, so no caller could see encoded context value (NULL) > anymore. > > It also improves TraceDependencies & LogCompilation output: dependency context is always correctly displayed. > > Also, did some cleanup. > > Testing: failing test, JPRT w/ logging turned on & off, CTW on solaris_x64. > > Best regards, > Vladimir Ivanov From roland.westrelin at oracle.com Fri Oct 5 02:05:31 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 5 Oct 2012 11:05:31 +0200 Subject: RFR (L): 7054512: Compress class pointers after perm gen removal In-Reply-To: <374CD0AA-2A92-4DBD-812E-347F5121F5BB@oracle.com> References: <6980759A-600A-440C-9B4F-BC72D08CFD29@oracle.com> <95A84D5B-D743-4CFF-9A59-930A064ADEE3@oracle.com> <32E23698-5A2E-4650-96D9-1AF8F2699A9D@oracle.com> <44446827-39E2-46D0-B510-73C3F11A528D@oracle.com> <1FC76AB5-E1FD-41D4-B5AB-781CF10237C4@oracle.com> <374CD0AA-2A92-4DBD-812E-347F5121F5BB@oracle.com> Message-ID: >>> I would personally try to restrict the changeset to the lines that contribute to the feature. Is there an agreed coding "policy" for this? >> >> I don't think so. People have different preferences. But when I see code that is tidily arranged I usually keep that. As I said, it's up to you. > > Personally, I prefer to include simple cleanups in my changesets, if they are near to the essential changes. I've done a pass over the changes and fixed the formatting. Roland. From vladimir.x.ivanov at oracle.com Fri Oct 5 06:52:45 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 05 Oct 2012 17:52:45 +0400 Subject: RFR (S): 8000232: NPG: SIGSEGV in Dependencies::DepStream::check_klass_dependency on solaris-x64 In-Reply-To: <506E34C4.2010100@oracle.com> References: <506E07D4.2070405@oracle.com> <506E34C4.2010100@oracle.com> Message-ID: <506EE62D.9010400@oracle.com> Agree. Updated the webrev. Best regards, Vladimir Ivanov On 10/05/12 05:15, Vladimir Kozlov wrote: > Could you add != NULL check to the second assert since argument_oop() > can return NULL (based on the assert inside)? > > 707 assert(k->is_klass(), "type check"); > > Thanks, > Vladimir > > On 10/4/12 3:04 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8000232/webrev.00 >> 22 lines changed: 10 ins; 4 del; 8 mod >> >> Context type of a dependency is encoded as NULL only when it is >> explicit and the context is "default" (see >> Dependencies::ctxk_encoded_as_null). Decoding takes place only in >> Dependencies::DepStream::context_type(), however the >> value is used in other places. >> >> The problem is that no decoding is performed when dependencies are >> logged using Dependencies::write_dependency_to, but >> only non-NULL values are expected in the code. The bug existed before >> NPG, it simply didn't cause a crash. >> >> Fixed by moving decoding into Dependencies::DepStream::argument, so no >> caller could see encoded context value (NULL) >> anymore. >> >> It also improves TraceDependencies & LogCompilation output: dependency >> context is always correctly displayed. >> >> Also, did some cleanup. >> >> Testing: failing test, JPRT w/ logging turned on & off, CTW on >> solaris_x64. >> >> Best regards, >> Vladimir Ivanov From vladimir.kozlov at oracle.com Fri Oct 5 07:45:03 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 5 Oct 2012 07:45:03 -0700 Subject: RFR (S): 8000232: NPG: SIGSEGV in Dependencies::DepStream::check_klass_dependency on solaris-x64 In-Reply-To: <506EE62D.9010400@oracle.com> References: <506E07D4.2070405@oracle.com> <506E34C4.2010100@oracle.com> <506EE62D.9010400@oracle.com> Message-ID: Good. Vladimir On Oct 5, 2012, at 6:52 AM, Vladimir Ivanov wrote: > Agree. Updated the webrev. > > Best regards, > Vladimir Ivanov > > On 10/05/12 05:15, Vladimir Kozlov wrote: >> Could you add != NULL check to the second assert since argument_oop() >> can return NULL (based on the assert inside)? >> >> 707 assert(k->is_klass(), "type check"); >> >> Thanks, >> Vladimir >> >> On 10/4/12 3:04 PM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8000232/webrev.00 >>> 22 lines changed: 10 ins; 4 del; 8 mod >>> >>> Context type of a dependency is encoded as NULL only when it is >>> explicit and the context is "default" (see >>> Dependencies::ctxk_encoded_as_null). Decoding takes place only in >>> Dependencies::DepStream::context_type(), however the >>> value is used in other places. >>> >>> The problem is that no decoding is performed when dependencies are >>> logged using Dependencies::write_dependency_to, but >>> only non-NULL values are expected in the code. The bug existed before >>> NPG, it simply didn't cause a crash. >>> >>> Fixed by moving decoding into Dependencies::DepStream::argument, so no >>> caller could see encoded context value (NULL) >>> anymore. >>> >>> It also improves TraceDependencies & LogCompilation output: dependency >>> context is always correctly displayed. >>> >>> Also, did some cleanup. >>> >>> Testing: failing test, JPRT w/ logging turned on & off, CTW on >>> solaris_x64. >>> >>> Best regards, >>> Vladimir Ivanov From vladimir.x.ivanov at oracle.com Fri Oct 5 08:11:52 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 05 Oct 2012 19:11:52 +0400 Subject: RFR (S): 8000232: NPG: SIGSEGV in Dependencies::DepStream::check_klass_dependency on solaris-x64 In-Reply-To: References: <506E07D4.2070405@oracle.com> <506E34C4.2010100@oracle.com> <506EE62D.9010400@oracle.com> Message-ID: <506EF8B8.1080409@oracle.com> Thank you. Best regards, Vladimir Ivanov On 10/05/12 18:45, Vladimir Kozlov wrote: > Good. > > Vladimir > > On Oct 5, 2012, at 6:52 AM, Vladimir Ivanov wrote: > >> Agree. Updated the webrev. >> >> Best regards, >> Vladimir Ivanov >> >> On 10/05/12 05:15, Vladimir Kozlov wrote: >>> Could you add != NULL check to the second assert since argument_oop() >>> can return NULL (based on the assert inside)? >>> >>> 707 assert(k->is_klass(), "type check"); >>> >>> Thanks, >>> Vladimir >>> >>> On 10/4/12 3:04 PM, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8000232/webrev.00 >>>> 22 lines changed: 10 ins; 4 del; 8 mod >>>> >>>> Context type of a dependency is encoded as NULL only when it is >>>> explicit and the context is "default" (see >>>> Dependencies::ctxk_encoded_as_null). Decoding takes place only in >>>> Dependencies::DepStream::context_type(), however the >>>> value is used in other places. >>>> >>>> The problem is that no decoding is performed when dependencies are >>>> logged using Dependencies::write_dependency_to, but >>>> only non-NULL values are expected in the code. The bug existed before >>>> NPG, it simply didn't cause a crash. >>>> >>>> Fixed by moving decoding into Dependencies::DepStream::argument, so no >>>> caller could see encoded context value (NULL) >>>> anymore. >>>> >>>> It also improves TraceDependencies & LogCompilation output: dependency >>>> context is always correctly displayed. >>>> >>>> Also, did some cleanup. >>>> >>>> Testing: failing test, JPRT w/ logging turned on & off, CTW on >>>> solaris_x64. >>>> >>>> Best regards, >>>> Vladimir Ivanov > From christian.thalinger at oracle.com Fri Oct 5 09:15:38 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 5 Oct 2012 09:15:38 -0700 Subject: RFR (S): 8000263: JSR 292: signature types may appear to be unloaded In-Reply-To: <5C220538-D589-4FA2-92EE-0A357F04777C@oracle.com> References: <0B96CD2D-5DAB-4989-8672-CD1E569B9BC6@oracle.com> <5C220538-D589-4FA2-92EE-0A357F04777C@oracle.com> Message-ID: On Oct 4, 2012, at 5:12 PM, John Rose wrote: > On Oct 4, 2012, at 3:51 PM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/8000263 >> >> 8000263: JSR 292: signature types may appear to be unloaded > > Good work. I very much like the 'is_public' assertion in 'check_wk_pre_link_klasses'. > > I mechanically checked that the whitespace change in systemDictionary.hpp is mixed with no other effects, > besides changing some occurrences of Pre or Pre_JSR292 to Pre_Link or Pre? > > Consider changing Opt to Pre for LambdaForm, if you agree that is a reasonable cleanup. That type is no longer optional. I tried that but running Queens fails then because we are still using 7 as JDK. > > I think the following code would be simpler and more directly correct in 'sharpen_unsafe_type': > if (sharpened_klass != NULL && !sharpened_klass->is_loaded()) > return NULL; Hmm. Returning null is okay here? Have to take a look again. > > Issue: Are intrinsics still properly recognized, even though 'find_well_known_klass' is restricted? Why wouldn't they? But I will check that. > > The function vmIntrinsics::method_for bothers me still. > Maybe add a FIXME comment pointing out that it doesn't work for all intrinsics. Or, add a boolean parameter: > > Klass* SystemDictionary::find_well_known_klass(Symbol* class_name, bool link_all = false) { > ... if (option == Pre_Link || link_all) ... > } > > Or, find a way to get rid of vmIntrinsics::method_for, since it is not used much. Ah, forgot about it. I will remove it and send a new webrev. -- Chris > > Thanks, > ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121005/78d02d00/attachment-0001.html From christian.thalinger at oracle.com Fri Oct 5 12:04:46 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 5 Oct 2012 12:04:46 -0700 Subject: RFR (S): 8000263: JSR 292: signature types may appear to be unloaded In-Reply-To: References: <0B96CD2D-5DAB-4989-8672-CD1E569B9BC6@oracle.com> <5C220538-D589-4FA2-92EE-0A357F04777C@oracle.com> Message-ID: <4F834AAB-88CF-49E2-BF9B-6D4C7B2560A1@oracle.com> On Oct 5, 2012, at 9:15 AM, Christian Thalinger wrote: > > On Oct 4, 2012, at 5:12 PM, John Rose wrote: > >> On Oct 4, 2012, at 3:51 PM, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/8000263 >>> >>> 8000263: JSR 292: signature types may appear to be unloaded >> >> Good work. I very much like the 'is_public' assertion in 'check_wk_pre_link_klasses'. >> >> I mechanically checked that the whitespace change in systemDictionary.hpp is mixed with no other effects, >> besides changing some occurrences of Pre or Pre_JSR292 to Pre_Link or Pre? >> >> Consider changing Opt to Pre for LambdaForm, if you agree that is a reasonable cleanup. That type is no longer optional. > > I tried that but running Queens fails then because we are still using 7 as JDK. > >> >> I think the following code would be simpler and more directly correct in 'sharpen_unsafe_type': >> if (sharpened_klass != NULL && !sharpened_klass->is_loaded()) >> return NULL; > > Hmm. Returning null is okay here? Have to take a look again. Yes it is. Changed. > >> >> Issue: Are intrinsics still properly recognized, even though 'find_well_known_klass' is restricted? > > Why wouldn't they? But I will check that. Yes, it is okay. vmIntrinsics::find_id only uses vmSymbols::SID to match methods. And after that we rely on m->intrinsic_id(). > >> >> The function vmIntrinsics::method_for bothers me still. >> Maybe add a FIXME comment pointing out that it doesn't work for all intrinsics. Or, add a boolean parameter: >> >> Klass* SystemDictionary::find_well_known_klass(Symbol* class_name, bool link_all = false) { >> ... if (option == Pre_Link || link_all) ... >> } >> >> Or, find a way to get rid of vmIntrinsics::method_for, since it is not used much. > > Ah, forgot about it. I will remove it and send a new webrev. webrev is updated. While I was there I moved generic code out of the architecture dependent files and removed unneeded code. -- Chris > > -- Chris > >> >> Thanks, >> ? John From christos at zoulas.com Fri Oct 5 12:04:47 2012 From: christos at zoulas.com (Christos Zoulas) Date: Fri, 5 Oct 2012 15:04:47 -0400 Subject: StackTraceElement question Message-ID: <20121005190447.2365997124@rebar.astron.com> Hi, I don't know if this belongs to this list, but if it does not, please point me to where it does. I think that it would be nice if StackTraceElement which currently contains: boolean equals(Object obj) String getClassName() String getFileName() int getLineNumber() String getMethodName() int hashCode() boolean isNativeMethod() String toString() It would be more useful for it to also contain: Class getClass() The reason I am asking, is because I have an application where I would like to find the enclosing class from where the exception is thrown not the superclass, but I cannot deduce that from the class name. If STE contained the above method, I could do: Class c = ste.getClass(); while (c.getEnclosingClass() != null) { c = c.getEnclosingClass(); } return c.getName(); to find the class I want, and getClassName() could be just a wrapper: String getClassName() { return getClass().getName(); } Is there any reason to store the name instead of the Class? Is it possible to fix this in a future version of the jdk? thanks christos From vladimir.kozlov at oracle.com Fri Oct 5 12:36:14 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 05 Oct 2012 12:36:14 -0700 Subject: RFR (S): 8000263: JSR 292: signature types may appear to be unloaded In-Reply-To: <4F834AAB-88CF-49E2-BF9B-6D4C7B2560A1@oracle.com> References: <0B96CD2D-5DAB-4989-8672-CD1E569B9BC6@oracle.com> <5C220538-D589-4FA2-92EE-0A357F04777C@oracle.com> <4F834AAB-88CF-49E2-BF9B-6D4C7B2560A1@oracle.com> Message-ID: <506F36AE.20209@oracle.com> Good. Vladimir Christian Thalinger wrote: > On Oct 5, 2012, at 9:15 AM, Christian Thalinger wrote: > >> On Oct 4, 2012, at 5:12 PM, John Rose wrote: >> >>> On Oct 4, 2012, at 3:51 PM, Christian Thalinger wrote: >>> >>>> http://cr.openjdk.java.net/~twisti/8000263 >>>> >>>> 8000263: JSR 292: signature types may appear to be unloaded >>> Good work. I very much like the 'is_public' assertion in 'check_wk_pre_link_klasses'. >>> >>> I mechanically checked that the whitespace change in systemDictionary.hpp is mixed with no other effects, >>> besides changing some occurrences of Pre or Pre_JSR292 to Pre_Link or Pre? >>> >>> Consider changing Opt to Pre for LambdaForm, if you agree that is a reasonable cleanup. That type is no longer optional. >> I tried that but running Queens fails then because we are still using 7 as JDK. >> >>> I think the following code would be simpler and more directly correct in 'sharpen_unsafe_type': >>> if (sharpened_klass != NULL && !sharpened_klass->is_loaded()) >>> return NULL; >> Hmm. Returning null is okay here? Have to take a look again. > > Yes it is. Changed. > >>> Issue: Are intrinsics still properly recognized, even though 'find_well_known_klass' is restricted? >> Why wouldn't they? But I will check that. > > Yes, it is okay. vmIntrinsics::find_id only uses vmSymbols::SID to match methods. And after that we rely on m->intrinsic_id(). > >>> The function vmIntrinsics::method_for bothers me still. >>> Maybe add a FIXME comment pointing out that it doesn't work for all intrinsics. Or, add a boolean parameter: >>> >>> Klass* SystemDictionary::find_well_known_klass(Symbol* class_name, bool link_all = false) { >>> ... if (option == Pre_Link || link_all) ... >>> } >>> >>> Or, find a way to get rid of vmIntrinsics::method_for, since it is not used much. >> Ah, forgot about it. I will remove it and send a new webrev. > > webrev is updated. While I was there I moved generic code out of the architecture dependent files and removed unneeded code. > > -- Chris > >> -- Chris >> >>> Thanks, >>> ? John > From alejandro.murillo at oracle.com Fri Oct 5 17:23:03 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 06 Oct 2012 00:23:03 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 17 new changesets Message-ID: <20121006002340.E4F76471DB@hg.openjdk.java.net> Changeset: 2dd08e86a2bf Author: katleman Date: 2012-09-27 11:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2dd08e86a2bf Added tag jdk8-b58 for changeset 6bb378c50828 ! .hgtags Changeset: 8a1a6b9b4f20 Author: katleman Date: 2012-10-03 15:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8a1a6b9b4f20 Merge ! .hgtags - agent/make/ClosureFinder.java - agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/Address.java - agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java - agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java - agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java - agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java - agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java - src/share/tools/ProjectCreator/DirectoryTree.java - src/share/tools/ProjectCreator/DirectoryTreeNode.java - src/share/tools/ProjectCreator/FileFormatException.java - src/share/tools/ProjectCreator/WinGammaPlatformVC6.java Changeset: a3fd4914ac81 Author: katleman Date: 2012-10-04 14:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a3fd4914ac81 Added tag jdk8-b59 for changeset 8a1a6b9b4f20 ! .hgtags Changeset: 988bf00cc564 Author: johnc Date: 2012-09-27 15:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/988bf00cc564 7200261: G1: Liveness counting inconsistencies during marking verification Summary: The clipping code in the routine that sets the bits for a range of cards, in the liveness accounting verification code was incorrect. It set all the bits in the card bitmap from the given starting index which would lead to spurious marking verification failures. Reviewed-by: brutisso, jwilhelm, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp Changeset: 5c8fbbfed964 Author: stefank Date: 2012-10-01 11:07 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5c8fbbfed964 Merge - agent/make/ClosureFinder.java - agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/Address.java - agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java - agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java - agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java - agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java - agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java - src/share/tools/ProjectCreator/DirectoryTree.java - src/share/tools/ProjectCreator/DirectoryTreeNode.java - src/share/tools/ProjectCreator/FileFormatException.java - src/share/tools/ProjectCreator/WinGammaPlatformVC6.java Changeset: 85f1cded9793 Author: stefank Date: 2012-09-28 15:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/85f1cded9793 8000230: Change os::print_location to be more descriptive when a location is pointing into an object Reviewed-by: mgerdin, twisti ! src/share/vm/runtime/os.cpp Changeset: 86af3dacab81 Author: stefank Date: 2012-10-01 13:29 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/86af3dacab81 8000227: [obj|type]ArrayKlass::oop_print_on prints one line to tty instead of the provided output stream Reviewed-by: brutisso, sla, jmasa, coleenp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.cpp Changeset: 87ac5c0a404d Author: stefank Date: 2012-10-01 13:29 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/87ac5c0a404d 8000228: Missing call to cr() when printing entry_point in nmethod, in os::print_location Reviewed-by: brutisso, neliasso ! src/share/vm/runtime/os.cpp Changeset: f81a7c0c618d Author: jmasa Date: 2012-10-03 08:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f81a7c0c618d 7199349: NPG: PS: Crash seen in jprt Reviewed-by: johnc ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp ! src/share/vm/runtime/globals.hpp Changeset: 22b8d3d181d9 Author: jwilhelm Date: 2012-10-03 20:31 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/22b8d3d181d9 8000351: Tenuring threshold should be unsigned Summary: Change the flags and variables related to tenuring threshold to be unsigned Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/shared/ageTable.cpp ! src/share/vm/gc_implementation/shared/ageTable.hpp ! src/share/vm/gc_implementation/shared/gcAdaptivePolicyCounters.hpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/oops/markOop.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 2e6857353b2c Author: johnc Date: 2012-10-04 10:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2e6857353b2c 8000311: G1: ParallelGCThreads==0 broken Summary: Divide by zero error, if ParallelGCThreads is 0, when adjusting the PLAB size. Reviewed-by: jmasa, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp ! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp Changeset: 097d78aaf2b5 Author: jmasa Date: 2012-10-04 10:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/097d78aaf2b5 7198873: NPG: VM Does not unload classes with UseConcMarkSweepGC Reviewed-by: johnc, mgerdin, jwilhelm ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp Changeset: ca70b919819f Author: jmasa Date: 2012-10-04 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ca70b919819f Merge Changeset: 685457683e86 Author: kvn Date: 2012-10-05 10:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/685457683e86 Merge Changeset: 1cc7a2a11d00 Author: amurillo Date: 2012-10-05 13:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1cc7a2a11d00 Merge Changeset: 3cfd05b2219a Author: amurillo Date: 2012-10-05 13:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3cfd05b2219a Added tag hs25-b04 for changeset 1cc7a2a11d00 ! .hgtags Changeset: 81e878c53615 Author: amurillo Date: 2012-10-05 13:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/81e878c53615 8000498: new hotspot build - hs25-b05 Reviewed-by: jcoomes ! make/hotspot_version From vladimir.kozlov at oracle.com Fri Oct 5 20:51:20 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 06 Oct 2012 03:51:20 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7177003: C1: LogCompilation support Message-ID: <20121006035124.D815E471E0@hg.openjdk.java.net> Changeset: c3e799c37717 Author: vlivanov Date: 2012-10-05 18:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c3e799c37717 7177003: C1: LogCompilation support Summary: add LogCompilation support in C1 - both client and tiered mode. Reviewed-by: twisti, kvn ! src/os/linux/vm/vmError_linux.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/compiler/compileLog.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/ostream.cpp From vladimir.kozlov at oracle.com Fri Oct 5 22:33:46 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 06 Oct 2012 05:33:46 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8000232: NPG: SIGSEGV in Dependencies::DepStream::check_klass_dependency on solaris-x64 Message-ID: <20121006053354.709C7471E3@hg.openjdk.java.net> Changeset: 9a9b6e05ffb4 Author: vlivanov Date: 2012-10-05 19:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9a9b6e05ffb4 8000232: NPG: SIGSEGV in Dependencies::DepStream::check_klass_dependency on solaris-x64 Summary: Move decoding into Dependencies::DepStream::argument, so no caller could see encoded context value (NULL) anymore. Reviewed-by: twisti, kvn ! src/share/vm/code/dependencies.cpp From vladimir.kozlov at oracle.com Sat Oct 6 00:13:15 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 06 Oct 2012 07:13:15 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8000485: Hotspot build fails in Solaris Studio IDE when building dtrace Message-ID: <20121006071320.6329D471E4@hg.openjdk.java.net> Changeset: 9024b6b53ec2 Author: vlivanov Date: 2012-10-05 19:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9024b6b53ec2 8000485: Hotspot build fails in Solaris Studio IDE when building dtrace Summary: Prepend '.' to the existing native library path Reviewed-by: kvn, sspitsyn ! make/bsd/makefiles/dtrace.make ! make/solaris/makefiles/dtrace.make From rednaxelafx at gmail.com Sat Oct 6 07:58:40 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Sat, 6 Oct 2012 22:58:40 +0800 Subject: StackTraceElement question In-Reply-To: <20121005190447.2365997124@rebar.astron.com> References: <20121005190447.2365997124@rebar.astron.com> Message-ID: Hi, I believe this discussion belongs to core-libs-dev list better. cc'd. - Kris On Sat, Oct 6, 2012 at 3:04 AM, Christos Zoulas wrote: > Hi, > > I don't know if this belongs to this list, but if it does not, > please point me to where it does. I think that it would be nice if > StackTraceElement which currently contains: > > boolean equals(Object obj) > String getClassName() > String getFileName() > int getLineNumber() > String getMethodName() > int hashCode() > boolean isNativeMethod() > String toString() > > It would be more useful for it to also contain: > > Class getClass() > > The reason I am asking, is because I have an application where I > would like to find the enclosing class from where the exception is > thrown not the superclass, but I cannot deduce that from the class > name. If STE contained the above method, I could do: > > Class c = ste.getClass(); > while (c.getEnclosingClass() != null) { > c = c.getEnclosingClass(); > } > return c.getName(); > > to find the class I want, and getClassName() could be just a wrapper: > > String getClassName() { > return getClass().getName(); > } > > Is there any reason to store the name instead of the Class? Is it > possible to fix this in a future version of the jdk? > > thanks > > christos > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121006/b24bf286/attachment.html From goetz.lindenmaier at sap.com Mon Oct 8 01:37:54 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 8 Oct 2012 10:37:54 +0200 Subject: RFR (S): Improve adlc usability Message-ID: <140FA3E3585AD840A3316D2853F974DC1BEE48CB19@DEWDFECCR03.wdf.sap.corp> Hi, We did a row of smaller changes to adlc to improve its usability, e.g. - Make adlc more stable, especially if parsing faulty .ad files. - In some cases raise syntax errors instead of asserting. - Write more comments into generated files and beautify format. - Make calls to node->format() more stable. - Clean up adlc code: warnings, dead code etc. Notice that all these changes shouldn't affect the generated code in any way! I collected all these and put them into this webrev: http://cr.openjdk.java.net/~goetz/webrevs/webrev-adlc_usability/ We would like to contribute this to the openJDK. Could somebody please review the change and push it if it seems useful to you? Thanks a lot, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121008/343f964a/attachment.html From vladimir.x.ivanov at oracle.com Mon Oct 8 10:33:54 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 08 Oct 2012 21:33:54 +0400 Subject: RFR (S): 8000313: C2 should use jlong for 64bit values Message-ID: <50730E82.5010203@oracle.com> http://cr.openjdk.java.net/~vlivanov/8000313/webrev.00/ 25 lines changed: 0 ins; 0 del; 25 mod This is a code cleanup. It replaces all occurrences of long with jlong in C2 code to guarantee that 64-bit value is always used (it's not the case for type long) and no overflow in subsequent arithmetic operations occurs. Testing: JPRT, full CTW on solaris_x64 Best regards, Vladimir Ivanov From vladimir.kozlov at oracle.com Mon Oct 8 10:50:55 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 08 Oct 2012 10:50:55 -0700 Subject: RFR (S): 8000313: C2 should use jlong for 64bit values In-Reply-To: <50730E82.5010203@oracle.com> References: <50730E82.5010203@oracle.com> Message-ID: <5073127F.6000603@oracle.com> Looks good. I will push it. Thanks, Vladimir Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8000313/webrev.00/ > 25 lines changed: 0 ins; 0 del; 25 mod > > This is a code cleanup. It replaces all occurrences of long with jlong > in C2 code to guarantee that 64-bit value is always used (it's not the > case for type long) and no overflow in subsequent arithmetic operations > occurs. > > Testing: JPRT, full CTW on solaris_x64 > > Best regards, > Vladimir Ivanov From azeem.jiva at oracle.com Mon Oct 8 11:07:02 2012 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Mon, 08 Oct 2012 13:07:02 -0500 Subject: RFR (S): 8000313: C2 should use jlong for 64bit values In-Reply-To: <50730E82.5010203@oracle.com> References: <50730E82.5010203@oracle.com> Message-ID: <50731646.2020209@oracle.com> Looks good. Did you run on 64bit SPARC as well? On 10/08/2012 12:33 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8000313/webrev.00/ > 25 lines changed: 0 ins; 0 del; 25 mod > > This is a code cleanup. It replaces all occurrences of long with jlong > in C2 code to guarantee that 64-bit value is always used (it's not the > case for type long) and no overflow in subsequent arithmetic operations > occurs. > > Testing: JPRT, full CTW on solaris_x64 > > Best regards, > Vladimir Ivanov -- Azeem Jiva @javawithjiva From vladimir.kozlov at oracle.com Mon Oct 8 11:37:17 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 08 Oct 2012 11:37:17 -0700 Subject: RFR (S): 8000313: C2 should use jlong for 64bit values In-Reply-To: <50731646.2020209@oracle.com> References: <50730E82.5010203@oracle.com> <50731646.2020209@oracle.com> Message-ID: <50731D5D.70306@oracle.com> It will be run in JPRT on all platforms. Vladimir Azeem Jiva wrote: > Looks good. Did you run on 64bit SPARC as well? > > > On 10/08/2012 12:33 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8000313/webrev.00/ >> 25 lines changed: 0 ins; 0 del; 25 mod >> >> This is a code cleanup. It replaces all occurrences of long with jlong >> in C2 code to guarantee that 64-bit value is always used (it's not the >> case for type long) and no overflow in subsequent arithmetic operations >> occurs. >> >> Testing: JPRT, full CTW on solaris_x64 >> >> Best regards, >> Vladimir Ivanov > From roland.westrelin at oracle.com Mon Oct 8 11:56:22 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 8 Oct 2012 20:56:22 +0200 Subject: RFR (L): 7054512: Compress class pointers after perm gen removal In-Reply-To: References: <6980759A-600A-440C-9B4F-BC72D08CFD29@oracle.com> <95A84D5B-D743-4CFF-9A59-930A064ADEE3@oracle.com> <32E23698-5A2E-4650-96D9-1AF8F2699A9D@oracle.com> <44446827-39E2-46D0-B510-73C3F11A528D@oracle.com> <1FC76AB5-E1FD-41D4-B5AB-781CF10237C4@oracle.com> <374CD0AA-2A92-4DBD-812E-347F5121F5BB@oracle.com> Message-ID: For the record, here's an updated webrev with Christian's suggested clean up and formatting fixes. http://cr.openjdk.java.net/~roland/7054512/webrev.01/ Roland. From vladimir.x.ivanov at oracle.com Mon Oct 8 13:06:58 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 09 Oct 2012 00:06:58 +0400 Subject: RFR (S): 8000313: C2 should use jlong for 64bit values In-Reply-To: <50731646.2020209@oracle.com> References: <50730E82.5010203@oracle.com> <50731646.2020209@oracle.com> Message-ID: <50733262.5010705@oracle.com> Azeem, Thanks for the review. As Vladimir K. already noted, JPRT does some amount of testing on all platforms. Regarding CTW, I decided to run it on a single 64-bit platform, because the changes are in shared code. Best regards, Vladimir Ivanov On 10/8/12 10:07 PM, Azeem Jiva wrote: > Looks good. Did you run on 64bit SPARC as well? > > > On 10/08/2012 12:33 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8000313/webrev.00/ >> 25 lines changed: 0 ins; 0 del; 25 mod >> >> This is a code cleanup. It replaces all occurrences of long with jlong >> in C2 code to guarantee that 64-bit value is always used (it's not the >> case for type long) and no overflow in subsequent arithmetic operations >> occurs. >> >> Testing: JPRT, full CTW on solaris_x64 >> >> Best regards, >> Vladimir Ivanov > From azeem.jiva at oracle.com Mon Oct 8 13:13:07 2012 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Mon, 08 Oct 2012 15:13:07 -0500 Subject: RFR (S): 8000313: C2 should use jlong for 64bit values In-Reply-To: <50733262.5010705@oracle.com> References: <50730E82.5010203@oracle.com> <50731646.2020209@oracle.com> <50733262.5010705@oracle.com> Message-ID: <507333D3.5030401@oracle.com> OK sounds good. On 10/08/2012 03:06 PM, Vladimir Ivanov wrote: > Azeem, > > Thanks for the review. > > As Vladimir K. already noted, JPRT does some amount of testing on all > platforms. Regarding CTW, I decided to run it on a single 64-bit > platform, because the changes are in shared code. > > Best regards, > Vladimir Ivanov > > On 10/8/12 10:07 PM, Azeem Jiva wrote: >> Looks good. Did you run on 64bit SPARC as well? >> >> >> On 10/08/2012 12:33 PM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8000313/webrev.00/ >>> 25 lines changed: 0 ins; 0 del; 25 mod >>> >>> This is a code cleanup. It replaces all occurrences of long with jlong >>> in C2 code to guarantee that 64-bit value is always used (it's not the >>> case for type long) and no overflow in subsequent arithmetic operations >>> occurs. >>> >>> Testing: JPRT, full CTW on solaris_x64 >>> >>> Best regards, >>> Vladimir Ivanov >> -- Azeem Jiva @javawithjiva From vladimir.kozlov at oracle.com Mon Oct 8 14:52:02 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Mon, 08 Oct 2012 21:52:02 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8000313: C2 should use jlong for 64bit values Message-ID: <20121008215206.922904722C@hg.openjdk.java.net> Changeset: 377508648226 Author: vlivanov Date: 2012-10-08 13:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/377508648226 8000313: C2 should use jlong for 64bit values Summary: Replace all occurrences of long with jlong in C2 code. Reviewed-by: kvn, twisti ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/phaseX.hpp From yumin.qi at oracle.com Mon Oct 8 16:27:04 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 08 Oct 2012 16:27:04 -0700 Subject: RFR: 8000412: Clean SA code on ia64 Message-ID: <50736148.5060002@oracle.com> Hi, All Can I have your codereview for 8000412 : Clean SA code on ia64 Summary: Clean up IA64 code in SA since SA does no t support this cpu architecture. Reviewed-by: Contributed-by: yumin.qi at oracle.com,staffan.larsen at oracle.com http://cr.openjdk.java.net/~minqi/8000412/ Thanks Yumin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121008/824a7336/attachment.html From vladimir.kozlov at oracle.com Mon Oct 8 18:38:24 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 08 Oct 2012 18:38:24 -0700 Subject: RFR (S): Improve adlc usability In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BEE48CB19@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC1BEE48CB19@DEWDFECCR03.wdf.sap.corp> Message-ID: <50738010.6020200@oracle.com> Hi Goetz, I would not call it small with 450 lines changed :) I filed RFE 8000592: Improve adlc usability Review: It is not our codding style to have NULL on left side of compare. You have it in several files changes. src/share/vm/adlc/archDesc.cpp Could you move opForm.dump() under your new check?: if (!result_class) opForm.dump(); - assert( result_class, "Resulting register class was not defined for operand"); + if (NULL == result_class) { src/share/vm/adlc/formssel.cpp: I don't think next code will work with num_opnds() == 0. Move num_opnds() check before the loop: +const char *InstructForm::unique_opnd_ident(int idx) { + uint i; + for (i = 1; (num_opnds() >= 0) && (i < (uint)num_opnds()); ++i) { + if (unique_opnds_idx(i) == idx) { + break; + } + } + return (_components.at(i)) ? _components.at(i)->_name : ""; +} src/share/vm/adlc/formssel.cpp: Why do you need separate static method use_def_effect_name()? It is called only from one place. src/share/vm/adlc/formssel.cpp: I don't get why you need special constant_offset_unchecked() for format output. We dump format (PrintOptoAssembly) after code is generated so all constants offsets should be defined. What asserts you have "in debug output"? src/share/vm/adlc/main.cpp: You missed -v description: printf(" v specify adGlobals output file name\n"); src/share/vm/adlc/output_h.cpp We can't accept comment with "// SAPJVM ..." Don't do assignment inside condition: 134 for ( _register->reset_RegDefs(); (reg_def = _register->iter_RegDefs()) != NULL; ) { And I got next build failures with your changes: src/share/vm/adlc/output_h.cpp(86) : warning C4018: '<' : signed/unsigned mismatch "src/share/vm/adlc/output_h.cpp", line 135: Error: Conversion of 64 bit type value to "int" causes truncation. "src/share/vm/adlc/output_h.cpp", line 145: Error: Conversion of 64 bit type value to "int" causes truncation. 2 Error(s) detected. Regards, Vladimir Lindenmaier, Goetz wrote: > Hi, > > > > We did a row of smaller changes to adlc to improve its usability, e.g. > > - Make adlc more stable, especially if parsing faulty .ad files. > > - In some cases raise syntax errors instead of asserting. > > - Write more comments into generated files and beautify format. > > - Make calls to node->format() more stable. > > - Clean up adlc code: warnings, dead code etc. > > > > Notice that all these changes shouldn't affect the generated code in any > way! > > > > I collected all these and put them into this webrev: > > http://cr.openjdk.java.net/~goetz/webrevs/webrev-adlc_usability/ > > > > We would like to contribute this to the openJDK. Could somebody > > please review the change and push it if it seems useful to you? > > > > Thanks a lot, > > Goetz. > > > From christian.thalinger at oracle.com Mon Oct 8 20:18:31 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 09 Oct 2012 03:18:31 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8000263: JSR 292: signature types may appear to be unloaded Message-ID: <20121009031838.BB43047232@hg.openjdk.java.net> Changeset: 65d07d9ee446 Author: twisti Date: 2012-10-08 17:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/65d07d9ee446 8000263: JSR 292: signature types may appear to be unloaded Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/globals.hpp From rickard.backman at oracle.com Mon Oct 8 23:00:03 2012 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Tue, 9 Oct 2012 08:00:03 +0200 Subject: RFR: 8000412: Clean SA code on ia64 In-Reply-To: <50736148.5060002@oracle.com> References: <50736148.5060002@oracle.com> Message-ID: <3E061272-FEBC-4C21-906A-53E6BC99E484@oracle.com> Looks good, ship it. /R On Oct 9, 2012, at 1:27 AM, Yumin Qi wrote: > Hi, All > > Can I have your codereview for > > 8000412 > : Clean SA code on ia64 > Summary: Clean up IA64 code in SA since SA does no t support this cpu architecture. > > Reviewed-by: > Contributed-by: > yumin.qi at oracle.com,staffan.larsen at oracle.com > > > > http://cr.openjdk.java.net/~minqi/8000412/ > > > Thanks > Yumin > > From vitalyd at gmail.com Tue Oct 9 06:10:05 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 9 Oct 2012 09:10:05 -0400 Subject: Assembler_x86.cpp char buffer deallocation In-Reply-To: References: Message-ID: Hi guys, I noticed that assembler_x86.cpp has a few places where a char[] is new()'d up to hold an error message when verifying an oop. This buffer is passed to the stub routine, but I can't find where this buffer is then deleted/deallocated. Am I missing something? Apologies of this is a silly question. :) Thanks Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121009/c28add41/attachment.html From roland.westrelin at oracle.com Tue Oct 9 06:23:10 2012 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Tue, 09 Oct 2012 13:23:10 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7054512: Compress class pointers after perm gen removal Message-ID: <20121009132318.17AF847244@hg.openjdk.java.net> Changeset: 8e47bac5643a Author: roland Date: 2012-10-09 10:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8e47bac5643a 7054512: Compress class pointers after perm gen removal Summary: support of compress class pointers in the compilers. Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/debugger/Address.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/Debugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/DebuggerBase.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/JVMDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/dummy/DummyAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerServer.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Array.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Instance.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MetadataField.java + agent/src/share/classes/sun/jvm/hotspot/oops/NarrowKlassField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java ! agent/src/share/classes/sun/jvm/hotspot/oops/java_lang_Class.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/RobustOopDeterminator.java ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os/bsd/dtrace/generateJvmOffsets.cpp ! src/os/bsd/dtrace/jhelper.d ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/jhelper.d ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/instanceOop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.cpp ! src/share/vm/utilities/globalDefinitions.hpp From volker.simonis at gmail.com Tue Oct 9 06:47:20 2012 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 9 Oct 2012 15:47:20 +0200 Subject: Assembler_x86.cpp char buffer deallocation In-Reply-To: References: Message-ID: Hi Vitaly, it looks not very professional indeed, however it is only in debug code or in code protected by development parameters (-XX:+VerifyOops) so it will not cause any trouble in the production VM. Nevertheless it should be cleaned up when somebody touches that file. Regards, Volker On Tue, Oct 9, 2012 at 3:10 PM, Vitaly Davidovich wrote: > Hi guys, > > I noticed that assembler_x86.cpp has a few places where a char[] is new()'d > up to hold an error message when verifying an oop. This buffer is passed to > the stub routine, but I can't find where this buffer is then > deleted/deallocated. Am I missing something? Apologies of this is a silly > question. :) > > Thanks > > Sent from my phone From vitalyd at gmail.com Tue Oct 9 06:50:46 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 9 Oct 2012 09:50:46 -0400 Subject: Assembler_x86.cpp char buffer deallocation In-Reply-To: References: Message-ID: Hi Volker, Yes sorry, I should've stated that I did see that it was guarded by VerifyOops and I was just browsing the code - this is by no means some production issue that I have. Was just curious if I missed something. Thanks Sent from my phone On Oct 9, 2012 9:47 AM, "Volker Simonis" wrote: > Hi Vitaly, > > it looks not very professional indeed, however it is only in debug > code or in code protected by development parameters (-XX:+VerifyOops) > so it will not cause any trouble in the production VM. Nevertheless it > should be cleaned up when somebody touches that file. > > Regards, > Volker > > On Tue, Oct 9, 2012 at 3:10 PM, Vitaly Davidovich > wrote: > > Hi guys, > > > > I noticed that assembler_x86.cpp has a few places where a char[] is > new()'d > > up to hold an error message when verifying an oop. This buffer is > passed to > > the stub routine, but I can't find where this buffer is then > > deleted/deallocated. Am I missing something? Apologies of this is a > silly > > question. :) > > > > Thanks > > > > Sent from my phone > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121009/e5a91de6/attachment.html From yumin.qi at oracle.com Tue Oct 9 08:40:36 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Tue, 09 Oct 2012 08:40:36 -0700 Subject: RFR: 8000412: Clean SA code on ia64 In-Reply-To: <3E061272-FEBC-4C21-906A-53E6BC99E484@oracle.com> References: <50736148.5060002@oracle.com> <3E061272-FEBC-4C21-906A-53E6BC99E484@oracle.com> Message-ID: <50744574.3010802@oracle.com> Thanks, Richard Yumin On 10/8/2012 11:00 PM, Rickard B?ckman wrote: > Looks good, ship it. > > /R > > On Oct 9, 2012, at 1:27 AM, Yumin Qi wrote: > >> Hi, All >> >> Can I have your codereview for >> >> 8000412 >> : Clean SA code on ia64 >> Summary: Clean up IA64 code in SA since SA does no t support this cpu architecture. >> >> Reviewed-by: >> Contributed-by: >> yumin.qi at oracle.com,staffan.larsen at oracle.com >> >> >> >> http://cr.openjdk.java.net/~minqi/8000412/ >> >> >> Thanks >> Yumin >> >> From vladimir.kozlov at oracle.com Tue Oct 9 10:08:21 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 09 Oct 2012 10:08:21 -0700 Subject: Assembler_x86.cpp char buffer deallocation In-Reply-To: References: Message-ID: <50745A05.1070806@oracle.com> Vitaly, It is common mistake to mix code generation time and runtime execution of the generated code. We need this buffer with a message during runtime execution so we can deallocate it during code generation. Regards, Vladimir Vitaly Davidovich wrote: > Hi Volker, > > Yes sorry, I should've stated that I did see that it was guarded by > VerifyOops and I was just browsing the code - this is by no means some > production issue that I have. Was just curious if I missed something. > > Thanks > > Sent from my phone > > On Oct 9, 2012 9:47 AM, "Volker Simonis" > wrote: > > Hi Vitaly, > > it looks not very professional indeed, however it is only in debug > code or in code protected by development parameters (-XX:+VerifyOops) > so it will not cause any trouble in the production VM. Nevertheless it > should be cleaned up when somebody touches that file. > > Regards, > Volker > > On Tue, Oct 9, 2012 at 3:10 PM, Vitaly Davidovich > wrote: > > Hi guys, > > > > I noticed that assembler_x86.cpp has a few places where a char[] > is new()'d > > up to hold an error message when verifying an oop. This buffer > is passed to > > the stub routine, but I can't find where this buffer is then > > deleted/deallocated. Am I missing something? Apologies of this > is a silly > > question. :) > > > > Thanks > > > > Sent from my phone > From goetz.lindenmaier at sap.com Tue Oct 9 10:12:15 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 Oct 2012 19:12:15 +0200 Subject: FW: RFR (S): Improve adlc usability References: <140FA3E3585AD840A3316D2853F974DC1BEE48CB19@DEWDFECCR03.wdf.sap.corp> <50738010.6020200@oracle.com> Message-ID: <140FA3E3585AD840A3316D2853F974DC1BEEB7ECF9@DEWDFECCR03.wdf.sap.corp> Hi Vladimir, thanks for the fast review! I'll try to learn for my next changes from this. I'm not always sure what coding style to use, whether to keep the diffs small or streamline them with the surrounding code etc. I also can't tell all the reasons for design decisions in our code, as some changes are rather old or were done by colleagues that left our team. I fixed what you proposed and just removed what you questioned. About constant_offset_unchecked(): We dump debug info in more phases than your jit does, also calling format() there. Actually, in our jit, you can call format() before register allocation. Then it displays node numbers instead of registers. Therefore we made the format() function much more stable. Anyways, constant_offset() has side effects which should not be triggered by debug output. I understand the offset is set before the function is called, but then we can output it directly, too. I remove the function from the change nevertheless. It's also the only place that requires changes to /opto/ and thus fits not that good into this change. You find the new webrev here: http://cr.openjdk.java.net/~goetz/webrevs/8000592/ On which platform did you get the build error? Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Dienstag, 9. Oktober 2012 03:38 To: Lindenmaier, Goetz Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (S): Improve adlc usability Hi Goetz, I would not call it small with 450 lines changed :) I filed RFE 8000592: Improve adlc usability Review: It is not our codding style to have NULL on left side of compare. You have it in several files changes. src/share/vm/adlc/archDesc.cpp Could you move opForm.dump() under your new check?: if (!result_class) opForm.dump(); - assert( result_class, "Resulting register class was not defined for operand"); + if (NULL == result_class) { src/share/vm/adlc/formssel.cpp: I don't think next code will work with num_opnds() == 0. Move num_opnds() check before the loop: +const char *InstructForm::unique_opnd_ident(int idx) { + uint i; + for (i = 1; (num_opnds() >= 0) && (i < (uint)num_opnds()); ++i) { + if (unique_opnds_idx(i) == idx) { + break; + } + } + return (_components.at(i)) ? _components.at(i)->_name : ""; +} src/share/vm/adlc/formssel.cpp: Why do you need separate static method use_def_effect_name()? It is called only from one place. src/share/vm/adlc/formssel.cpp: I don't get why you need special constant_offset_unchecked() for format output. We dump format (PrintOptoAssembly) after code is generated so all constants offsets should be defined. What asserts you have "in debug output"? src/share/vm/adlc/main.cpp: You missed -v description: printf(" v specify adGlobals output file name\n"); src/share/vm/adlc/output_h.cpp We can't accept comment with "// SAPJVM ..." Don't do assignment inside condition: 134 for ( _register->reset_RegDefs(); (reg_def = _register->iter_RegDefs()) != NULL; ) { And I got next build failures with your changes: src/share/vm/adlc/output_h.cpp(86) : warning C4018: '<' : signed/unsigned mismatch "src/share/vm/adlc/output_h.cpp", line 135: Error: Conversion of 64 bit type value to "int" causes truncation. "src/share/vm/adlc/output_h.cpp", line 145: Error: Conversion of 64 bit type value to "int" causes truncation. 2 Error(s) detected. Regards, Vladimir Lindenmaier, Goetz wrote: > Hi, > > > > We did a row of smaller changes to adlc to improve its usability, e.g. > > - Make adlc more stable, especially if parsing faulty .ad files. > > - In some cases raise syntax errors instead of asserting. > > - Write more comments into generated files and beautify format. > > - Make calls to node->format() more stable. > > - Clean up adlc code: warnings, dead code etc. > > > > Notice that all these changes shouldn't affect the generated code in any > way! > > > > I collected all these and put them into this webrev: > > http://cr.openjdk.java.net/~goetz/webrevs/webrev-adlc_usability/ > > > > We would like to contribute this to the openJDK. Could somebody > > please review the change and push it if it seems useful to you? > > > > Thanks a lot, > > Goetz. > > > From vitalyd at gmail.com Tue Oct 9 10:19:51 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 9 Oct 2012 13:19:51 -0400 Subject: Assembler_x86.cpp char buffer deallocation In-Reply-To: <50745A05.1070806@oracle.com> References: <50745A05.1070806@oracle.com> Message-ID: Hi Vladimir, Right, so I did see that this buffer's address is taken and passed to the stub generator that creates the verify_oop code. What I couldn't find was where this buffer was deallocated after the verify_oop procedure was finished. Since this is allocated via new(), how would you deallocate it from generated code since presumably new() can be using a custom allocator underneath? I realize this is debug code so probably doesn't matter in practical terms. I'm a bit unclear on whether you're saying this code is correct or not. :) Thanks Sent from my phone On Oct 9, 2012 1:09 PM, "Vladimir Kozlov" wrote: > Vitaly, > > It is common mistake to mix code generation time and runtime execution of > the generated code. We need this buffer with a message during runtime > execution so we can deallocate it during code generation. > > Regards, > Vladimir > > Vitaly Davidovich wrote: > >> Hi Volker, >> >> Yes sorry, I should've stated that I did see that it was guarded by >> VerifyOops and I was just browsing the code - this is by no means some >> production issue that I have. Was just curious if I missed something. >> >> Thanks >> >> Sent from my phone >> >> On Oct 9, 2012 9:47 AM, "Volker Simonis" > volker.simonis at gmail.**com >> wrote: >> >> Hi Vitaly, >> >> it looks not very professional indeed, however it is only in debug >> code or in code protected by development parameters (-XX:+VerifyOops) >> so it will not cause any trouble in the production VM. Nevertheless it >> should be cleaned up when somebody touches that file. >> >> Regards, >> Volker >> >> On Tue, Oct 9, 2012 at 3:10 PM, Vitaly Davidovich > > wrote: >> > Hi guys, >> > >> > I noticed that assembler_x86.cpp has a few places where a char[] >> is new()'d >> > up to hold an error message when verifying an oop. This buffer >> is passed to >> > the stub routine, but I can't find where this buffer is then >> > deleted/deallocated. Am I missing something? Apologies of this >> is a silly >> > question. :) >> > >> > Thanks >> > >> > Sent from my phone >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121009/e10563b9/attachment.html From vladimir.kozlov at oracle.com Tue Oct 9 10:57:23 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 09 Oct 2012 10:57:23 -0700 Subject: Assembler_x86.cpp char buffer deallocation In-Reply-To: References: <50745A05.1070806@oracle.com> Message-ID: <50746583.6030500@oracle.com> The code is correct. The allocate is normal C++ allocate which use malloc so the buffer is in C heap. Again, verify_oop() method is called during assembler code generation (for example, during JIT compiled code generation). Later when the compiled code is executed it references this message so it can print it when oop check in the stub fails. Think about this as equivalent to C++ code: printf("Message"). "Message" string is kept in .data section whole time of program execution, it is not deallocated. Vladimir Vitaly Davidovich wrote: > Hi Vladimir, > > Right, so I did see that this buffer's address is taken and passed to > the stub generator that creates the verify_oop code. What I couldn't > find was where this buffer was deallocated after the verify_oop > procedure was finished. Since this is allocated via new(), how would > you deallocate it from generated code since presumably new() can be > using a custom allocator underneath? I realize this is debug code so > probably doesn't matter in practical terms. > > I'm a bit unclear on whether you're saying this code is correct or not. :) > > Thanks > > Sent from my phone > > On Oct 9, 2012 1:09 PM, "Vladimir Kozlov" > wrote: > > Vitaly, > > It is common mistake to mix code generation time and runtime > execution of the generated code. We need this buffer with a message > during runtime execution so we can deallocate it during code generation. > > Regards, > Vladimir > > Vitaly Davidovich wrote: > > Hi Volker, > > Yes sorry, I should've stated that I did see that it was guarded > by VerifyOops and I was just browsing the code - this is by no > means some production issue that I have. Was just curious if I > missed something. > > Thanks > > Sent from my phone > > On Oct 9, 2012 9:47 AM, "Volker Simonis" > > >> wrote: > > Hi Vitaly, > > it looks not very professional indeed, however it is only in > debug > code or in code protected by development parameters > (-XX:+VerifyOops) > so it will not cause any trouble in the production VM. > Nevertheless it > should be cleaned up when somebody touches that file. > > Regards, > Volker > > On Tue, Oct 9, 2012 at 3:10 PM, Vitaly Davidovich > > >> wrote: > > Hi guys, > > > > I noticed that assembler_x86.cpp has a few places where a > char[] > is new()'d > > up to hold an error message when verifying an oop. This > buffer > is passed to > > the stub routine, but I can't find where this buffer is then > > deleted/deallocated. Am I missing something? Apologies > of this > is a silly > > question. :) > > > > Thanks > > > > Sent from my phone > From vitalyd at gmail.com Tue Oct 9 11:14:20 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 9 Oct 2012 14:14:20 -0400 Subject: Assembler_x86.cpp char buffer deallocation In-Reply-To: <50746583.6030500@oracle.com> References: <50745A05.1070806@oracle.com> <50746583.6030500@oracle.com> Message-ID: Ah that makes sense now - thanks! What tripped me up was that I indeed thought this was a runtime call, whereas I realize that this generates code that sticks around and needs to reference this string. Speaking of which, is this technique used for non-debug code? If so, what happens if such code is unloaded and this string was only used by that one unloaded blob? Is it somehow deallocated as well? Thanks Sent from my phone On Oct 9, 2012 1:58 PM, "Vladimir Kozlov" wrote: > The code is correct. The allocate is normal C++ allocate which use malloc > so the buffer is in C heap. > > Again, verify_oop() method is called during assembler code generation (for > example, during JIT compiled code generation). Later when the compiled code > is executed it references this message so it can print it when oop check in > the stub fails. > > Think about this as equivalent to C++ code: printf("Message"). "Message" > string is kept in .data section whole time of program execution, it is not > deallocated. > > Vladimir > > Vitaly Davidovich wrote: > >> Hi Vladimir, >> >> Right, so I did see that this buffer's address is taken and passed to the >> stub generator that creates the verify_oop code. What I couldn't find was >> where this buffer was deallocated after the verify_oop procedure was >> finished. Since this is allocated via new(), how would you deallocate it >> from generated code since presumably new() can be using a custom allocator >> underneath? I realize this is debug code so probably doesn't matter in >> practical terms. >> >> I'm a bit unclear on whether you're saying this code is correct or not. :) >> >> Thanks >> >> Sent from my phone >> >> On Oct 9, 2012 1:09 PM, "Vladimir Kozlov" > vladimir.kozlov@**oracle.com >> wrote: >> >> Vitaly, >> >> It is common mistake to mix code generation time and runtime >> execution of the generated code. We need this buffer with a message >> during runtime execution so we can deallocate it during code >> generation. >> >> Regards, >> Vladimir >> >> Vitaly Davidovich wrote: >> >> Hi Volker, >> >> Yes sorry, I should've stated that I did see that it was guarded >> by VerifyOops and I was just browsing the code - this is by no >> means some production issue that I have. Was just curious if I >> missed something. >> >> Thanks >> >> Sent from my phone >> >> On Oct 9, 2012 9:47 AM, "Volker Simonis" >> >> > >> > >>> >> wrote: >> >> Hi Vitaly, >> >> it looks not very professional indeed, however it is only in >> debug >> code or in code protected by development parameters >> (-XX:+VerifyOops) >> so it will not cause any trouble in the production VM. >> Nevertheless it >> should be cleaned up when somebody touches that file. >> >> Regards, >> Volker >> >> On Tue, Oct 9, 2012 at 3:10 PM, Vitaly Davidovich >> >> >> wrote: >> > Hi guys, >> > >> > I noticed that assembler_x86.cpp has a few places where a >> char[] >> is new()'d >> > up to hold an error message when verifying an oop. This >> buffer >> is passed to >> > the stub routine, but I can't find where this buffer is >> then >> > deleted/deallocated. Am I missing something? Apologies >> of this >> is a silly >> > question. :) >> > >> > Thanks >> > >> > Sent from my phone >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121009/6d54fa99/attachment.html From vladimir.x.ivanov at oracle.com Tue Oct 9 11:16:01 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 09 Oct 2012 22:16:01 +0400 Subject: RFR (S): 7199654: Remove LoadUI2LNode Message-ID: <507469E1.8010407@oracle.com> http://cr.openjdk.java.net/~vlivanov/7199654/webrev.00/ 40 lines changed: 0 ins; 33 del; 7 mod Removed LoadUI2L node from Ideal. Replaced it with an equivalent predicate in AD files. Verified for a simple testcase that generated code isn't changed. Testing: manual, JPRT, CTW (full testlist on solaris_x64), VM testbase (linux_x64). Best regards, Vladimir Ivanov From vladimir.kozlov at oracle.com Tue Oct 9 11:30:17 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 09 Oct 2012 11:30:17 -0700 Subject: Assembler_x86.cpp char buffer deallocation In-Reply-To: References: <50745A05.1070806@oracle.com> <50746583.6030500@oracle.com> Message-ID: <50746D39.10603@oracle.com> Vitaly Davidovich wrote: > Ah that makes sense now - thanks! What tripped me up was that I indeed > thought this was a runtime call, whereas I realize that this generates > code that sticks around and needs to reference this string. > > Speaking of which, is this technique used for non-debug code? If so, I think it is only the place where we do this. In other cases (for embedded constants) we use _const CodeSection which is part of compiled code and will be freed when code is deoptimized. > what happens if such code is unloaded and this string was only used by > that one unloaded blob? Is it somehow deallocated as well? No deallocation in such case. It is a small memory leak when VerifyOops is switched on (it is off by default) in debug VM. Vladimir > > Thanks > > Sent from my phone > > On Oct 9, 2012 1:58 PM, "Vladimir Kozlov" > wrote: > > The code is correct. The allocate is normal C++ allocate which use > malloc so the buffer is in C heap. > > Again, verify_oop() method is called during assembler code > generation (for example, during JIT compiled code generation). Later > when the compiled code is executed it references this message so it > can print it when oop check in the stub fails. > > Think about this as equivalent to C++ code: printf("Message"). > "Message" string is kept in .data section whole time of program > execution, it is not deallocated. > > Vladimir > > Vitaly Davidovich wrote: > > Hi Vladimir, > > Right, so I did see that this buffer's address is taken and > passed to the stub generator that creates the verify_oop code. > What I couldn't find was where this buffer was deallocated > after the verify_oop procedure was finished. Since this is > allocated via new(), how would you deallocate it from generated > code since presumably new() can be using a custom allocator > underneath? I realize this is debug code so probably doesn't > matter in practical terms. > > I'm a bit unclear on whether you're saying this code is correct > or not. :) > > Thanks > > Sent from my phone > > On Oct 9, 2012 1:09 PM, "Vladimir Kozlov" > > >> wrote: > > Vitaly, > > It is common mistake to mix code generation time and runtime > execution of the generated code. We need this buffer with a > message > during runtime execution so we can deallocate it during code > generation. > > Regards, > Vladimir > > Vitaly Davidovich wrote: > > Hi Volker, > > Yes sorry, I should've stated that I did see that it was > guarded > by VerifyOops and I was just browsing the code - this is > by no > means some production issue that I have. Was just > curious if I > missed something. > > Thanks > > Sent from my phone > > On Oct 9, 2012 9:47 AM, "Volker Simonis" > > > > ____com > >>> wrote: > > Hi Vitaly, > > it looks not very professional indeed, however it is > only in > debug > code or in code protected by development parameters > (-XX:+VerifyOops) > so it will not cause any trouble in the production VM. > Nevertheless it > should be cleaned up when somebody touches that file. > > Regards, > Volker > > On Tue, Oct 9, 2012 at 3:10 PM, Vitaly Davidovich > > > > > >>> wrote: > > Hi guys, > > > > I noticed that assembler_x86.cpp has a few places > where a > char[] > is new()'d > > up to hold an error message when verifying an > oop. This > buffer > is passed to > > the stub routine, but I can't find where this > buffer is then > > deleted/deallocated. Am I missing something? > Apologies > of this > is a silly > > question. :) > > > > Thanks > > > > Sent from my phone > From vladimir.kozlov at oracle.com Tue Oct 9 11:59:10 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 09 Oct 2012 11:59:10 -0700 Subject: RFR (S): 7199654: Remove LoadUI2LNode In-Reply-To: <507469E1.8010407@oracle.com> References: <507469E1.8010407@oracle.com> Message-ID: <507473FE.8020300@oracle.com> Looks good. Vladimir Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/7199654/webrev.00/ > 40 lines changed: 0 ins; 33 del; 7 mod > > Removed LoadUI2L node from Ideal. Replaced it with an equivalent > predicate in AD files. Verified for a simple testcase that generated > code isn't changed. > > Testing: manual, JPRT, CTW (full testlist on solaris_x64), VM testbase > (linux_x64). > > Best regards, > Vladimir Ivanov From vitalyd at gmail.com Tue Oct 9 13:06:35 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 9 Oct 2012 16:06:35 -0400 Subject: Assembler_x86.cpp char buffer deallocation In-Reply-To: <50746D39.10603@oracle.com> References: <50745A05.1070806@oracle.com> <50746583.6030500@oracle.com> <50746D39.10603@oracle.com> Message-ID: Got it, thanks for taking the time to explain it. Cheers, Vitaly Sent from my phone On Oct 9, 2012 2:31 PM, "Vladimir Kozlov" wrote: > Vitaly Davidovich wrote: > >> Ah that makes sense now - thanks! What tripped me up was that I indeed >> thought this was a runtime call, whereas I realize that this generates code >> that sticks around and needs to reference this string. >> >> Speaking of which, is this technique used for non-debug code? If so, >> > > I think it is only the place where we do this. In other cases (for > embedded constants) we use _const CodeSection which is part of compiled > code and will be freed when code is deoptimized. > > what happens if such code is unloaded and this string was only used by >> that one unloaded blob? Is it somehow deallocated as well? >> > > No deallocation in such case. It is a small memory leak when VerifyOops is > switched on (it is off by default) in debug VM. > > Vladimir > > >> Thanks >> >> Sent from my phone >> >> On Oct 9, 2012 1:58 PM, "Vladimir Kozlov" > vladimir.kozlov@**oracle.com >> wrote: >> >> The code is correct. The allocate is normal C++ allocate which use >> malloc so the buffer is in C heap. >> >> Again, verify_oop() method is called during assembler code >> generation (for example, during JIT compiled code generation). Later >> when the compiled code is executed it references this message so it >> can print it when oop check in the stub fails. >> >> Think about this as equivalent to C++ code: printf("Message"). >> "Message" string is kept in .data section whole time of program >> execution, it is not deallocated. >> >> Vladimir >> >> Vitaly Davidovich wrote: >> >> Hi Vladimir, >> >> Right, so I did see that this buffer's address is taken and >> passed to the stub generator that creates the verify_oop code. >> What I couldn't find was where this buffer was deallocated >> after the verify_oop procedure was finished. Since this is >> allocated via new(), how would you deallocate it from generated >> code since presumably new() can be using a custom allocator >> underneath? I realize this is debug code so probably doesn't >> matter in practical terms. >> >> I'm a bit unclear on whether you're saying this code is correct >> or not. :) >> >> Thanks >> >> Sent from my phone >> >> On Oct 9, 2012 1:09 PM, "Vladimir Kozlov" >> >> > >> >> >>> >> wrote: >> >> Vitaly, >> >> It is common mistake to mix code generation time and runtime >> execution of the generated code. We need this buffer with a >> message >> during runtime execution so we can deallocate it during code >> generation. >> >> Regards, >> Vladimir >> >> Vitaly Davidovich wrote: >> >> Hi Volker, >> >> Yes sorry, I should've stated that I did see that it was >> guarded >> by VerifyOops and I was just browsing the code - this is >> by no >> means some production issue that I have. Was just >> curious if I >> missed something. >> >> Thanks >> >> Sent from my phone >> >> On Oct 9, 2012 9:47 AM, "Volker Simonis" >> > > >> > >> >> > **____com >> > >>>> >> wrote: >> >> Hi Vitaly, >> >> it looks not very professional indeed, however it is >> only in >> debug >> code or in code protected by development parameters >> (-XX:+VerifyOops) >> so it will not cause any trouble in the production VM. >> Nevertheless it >> should be cleaned up when somebody touches that file. >> >> Regards, >> Volker >> >> On Tue, Oct 9, 2012 at 3:10 PM, Vitaly Davidovich >> >> > >> >> >>> wrote: >> > Hi guys, >> > >> > I noticed that assembler_x86.cpp has a few places >> where a >> char[] >> is new()'d >> > up to hold an error message when verifying an >> oop. This >> buffer >> is passed to >> > the stub routine, but I can't find where this >> buffer is then >> > deleted/deallocated. Am I missing something? >> Apologies >> of this >> is a silly >> > question. :) >> > >> > Thanks >> > >> > Sent from my phone >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121009/9fffd445/attachment.html From vladimir.kozlov at oracle.com Tue Oct 9 14:46:41 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 09 Oct 2012 21:46:41 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7199654: Remove LoadUI2LNode Message-ID: <20121009214646.7FF8047259@hg.openjdk.java.net> Changeset: f6badecb7ea7 Author: vlivanov Date: 2012-10-09 12:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f6badecb7ea7 7199654: Remove LoadUI2LNode Summary: Removed LoadUI2L node from Ideal nodes, use match rule in .ad files instead. Reviewed-by: kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/superword.cpp From vladimir.kozlov at oracle.com Tue Oct 9 15:09:48 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 09 Oct 2012 15:09:48 -0700 Subject: FW: RFR (S): Improve adlc usability In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BEEB7ECF9@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC1BEE48CB19@DEWDFECCR03.wdf.sap.corp> <50738010.6020200@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BEEB7ECF9@DEWDFECCR03.wdf.sap.corp> Message-ID: <5074A0AC.3080307@oracle.com> Hi Goetz, This change works better. I will push it after testing. Thank you for explaining your problem with constant_offset() during format output. May be we should add a flag to check in this method and just return some default value when it is called before code generation. The failures I saw before was on Solaris when building 64-bit VM. And on Windows (sign vs unsign compare). Thanks, Vladimir Lindenmaier, Goetz wrote: > Hi Vladimir, > > thanks for the fast review! I'll try to learn for my next changes > from this. I'm not always sure what coding style > to use, whether to keep the diffs small or streamline them with > the surrounding code etc. I also can't tell all the reasons for > design decisions in our code, as some changes are rather old > or were done by colleagues that left our team. > > I fixed what you proposed and just removed what you > questioned. > > About constant_offset_unchecked(): We dump debug info > in more phases than your jit does, also calling format() there. > Actually, in our jit, you can call format() before register allocation. > Then it displays node numbers instead of registers. Therefore > we made the format() function much more stable. > Anyways, constant_offset() has side effects which should > not be triggered by debug output. I understand the offset > is set before the function is called, but then we can output it > directly, too. > I remove the function from the change nevertheless. It's also > the only place that requires changes to /opto/ and thus fits not > that good into this change. > > You find the new webrev here: > http://cr.openjdk.java.net/~goetz/webrevs/8000592/ > > On which platform did you get the build error? > > Best regards, > Goetz. > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Dienstag, 9. Oktober 2012 03:38 > To: Lindenmaier, Goetz > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR (S): Improve adlc usability > > Hi Goetz, > > I would not call it small with 450 lines changed :) > > I filed RFE 8000592: Improve adlc usability > > Review: > > It is not our codding style to have NULL on left side of compare. You have it in > several files changes. > > > src/share/vm/adlc/archDesc.cpp > Could you move opForm.dump() under your new check?: > > if (!result_class) opForm.dump(); > - assert( result_class, "Resulting register class was not defined for operand"); > + if (NULL == result_class) { > > > src/share/vm/adlc/formssel.cpp: > I don't think next code will work with num_opnds() == 0. Move num_opnds() check > before the loop: > > +const char *InstructForm::unique_opnd_ident(int idx) { > + uint i; > + for (i = 1; (num_opnds() >= 0) && (i < (uint)num_opnds()); ++i) { > + if (unique_opnds_idx(i) == idx) { > + break; > + } > + } > + return (_components.at(i)) ? _components.at(i)->_name : ""; > +} > > src/share/vm/adlc/formssel.cpp: > Why do you need separate static method use_def_effect_name()? It is called only > from one place. > > src/share/vm/adlc/formssel.cpp: > I don't get why you need special constant_offset_unchecked() for format output. > We dump format (PrintOptoAssembly) after code is generated so all constants > offsets should be defined. What asserts you have "in debug output"? > > > src/share/vm/adlc/main.cpp: > You missed -v description: > > printf(" v specify adGlobals output file name\n"); > > > src/share/vm/adlc/output_h.cpp > We can't accept comment with "// SAPJVM ..." > > Don't do assignment inside condition: > > 134 for ( _register->reset_RegDefs(); (reg_def = > _register->iter_RegDefs()) != NULL; ) { > > And I got next build failures with your changes: > > src/share/vm/adlc/output_h.cpp(86) : warning C4018: '<' : signed/unsigned mismatch > > "src/share/vm/adlc/output_h.cpp", line 135: Error: Conversion of 64 bit type > value to "int" causes truncation. > "src/share/vm/adlc/output_h.cpp", line 145: Error: Conversion of 64 bit type > value to "int" causes truncation. > 2 Error(s) detected. > > > Regards, > Vladimir > > Lindenmaier, Goetz wrote: >> Hi, >> >> >> >> We did a row of smaller changes to adlc to improve its usability, e.g. >> >> - Make adlc more stable, especially if parsing faulty .ad files. >> >> - In some cases raise syntax errors instead of asserting. >> >> - Write more comments into generated files and beautify format. >> >> - Make calls to node->format() more stable. >> >> - Clean up adlc code: warnings, dead code etc. >> >> >> >> Notice that all these changes shouldn't affect the generated code in any >> way! >> >> >> >> I collected all these and put them into this webrev: >> >> http://cr.openjdk.java.net/~goetz/webrevs/webrev-adlc_usability/ >> >> >> >> We would like to contribute this to the openJDK. Could somebody >> >> please review the change and push it if it seems useful to you? >> >> >> >> Thanks a lot, >> >> Goetz. >> >> >> From headius at headius.com Tue Oct 9 17:27:46 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 9 Oct 2012 14:27:46 -1000 Subject: Bug report: failing to call overridden method Message-ID: I reported this to Christian, but thought I'd toss it here in case someone else runs into it. It appears that C1 (tier 1) is failing to compile a indy + MH virtual target into a proper overridden call. In other words, it doesn't honor the override, and calls the direct target. Details are toward the end in this JRuby bug: http://jira.codehaus.org/browse/JRUBY-6920 It only fails in tier 1 with indy enabled. Does not fail with -Xint or -Tiered. Hopefully that's enough to go on :) - Charlie From vladimir.kozlov at oracle.com Tue Oct 9 17:58:32 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 10 Oct 2012 00:58:32 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8000592: Improve adlc usability Message-ID: <20121010005836.93C0047262@hg.openjdk.java.net> Changeset: d336b3173277 Author: kvn Date: 2012-10-09 16:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d336b3173277 8000592: Improve adlc usability Summary: several changes to adlc to improve its usability Reviewed-by: kvn Contributed-by: goetz.lindenmaier at sap.com ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/archDesc.hpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/main.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp From christian.thalinger at oracle.com Wed Oct 10 17:10:14 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 10 Oct 2012 17:10:14 -0700 Subject: RFR (M): 8000740: remove LinkWellKnownClasses Message-ID: <533EDED2-7E5A-4BA0-A23A-F7F19FD2EC7A@oracle.com> http://cr.openjdk.java.net/~twisti/8000740/ 8000740: remove LinkWellKnownClasses Reviewed-by: With 8000263 LinkWellKnownClasses was turned on by default to see if it works. Nightly testing showed that various JDI and JVMTI tests fail with LinkWellKnownClasses turned on, e.g.: jdk/test/com/sun/jdi/NewInstanceTest.java To avoid future problems we remove the code altogether. Additionally I resurrected some 292 code that is required when building with JDK 6. src/share/vm/classfile/classFileParser.cpp src/share/vm/classfile/classFileParser.hpp src/share/vm/classfile/systemDictionary.cpp src/share/vm/classfile/systemDictionary.hpp src/share/vm/prims/methodHandles.cpp src/share/vm/runtime/globals.hpp From vladimir.kozlov at oracle.com Wed Oct 10 19:09:42 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Oct 2012 19:09:42 -0700 Subject: RFR (M): 8000740: remove LinkWellKnownClasses In-Reply-To: <533EDED2-7E5A-4BA0-A23A-F7F19FD2EC7A@oracle.com> References: <533EDED2-7E5A-4BA0-A23A-F7F19FD2EC7A@oracle.com> Message-ID: <50762A66.3050602@oracle.com> Looks good. Vladimir On 10/10/12 5:10 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8000740/ > > 8000740: remove LinkWellKnownClasses > Reviewed-by: > > With 8000263 LinkWellKnownClasses was turned on by default to see if > it works. Nightly testing showed that various JDI and JVMTI tests fail > with LinkWellKnownClasses turned on, e.g.: > > jdk/test/com/sun/jdi/NewInstanceTest.java > > To avoid future problems we remove the code altogether. > > Additionally I resurrected some 292 code that is required when > building with JDK 6. > > src/share/vm/classfile/classFileParser.cpp > src/share/vm/classfile/classFileParser.hpp > src/share/vm/classfile/systemDictionary.cpp > src/share/vm/classfile/systemDictionary.hpp > src/share/vm/prims/methodHandles.cpp > src/share/vm/runtime/globals.hpp > From roland.westrelin at oracle.com Thu Oct 11 07:14:44 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 11 Oct 2012 16:14:44 +0200 Subject: RFR (XS): compiler/6912517 crashes on 64bit sparc with compressed oops off Message-ID: <35EA2327-E87A-4B50-8E2A-1290B01D888F@oracle.com> Small bug introduced by compressed klass pointer support: http://cr.openjdk.java.net/~roland/8000753/webrev.00/ Roland. From roland.westrelin at oracle.com Thu Oct 11 07:50:31 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 11 Oct 2012 16:50:31 +0200 Subject: RFR (XS) 8000753: compiler/6912517 crashes on 64bit sparc with compressed oops off In-Reply-To: <35EA2327-E87A-4B50-8E2A-1290B01D888F@oracle.com> References: <35EA2327-E87A-4B50-8E2A-1290B01D888F@oracle.com> Message-ID: <832F9944-3F87-4019-96B5-CC4ECFB7987B@oracle.com> (resent with bug number in subject) Small bug introduced by compressed klass pointer support: http://cr.openjdk.java.net/~roland/8000753/webrev.00/ Roland. From vladimir.kozlov at oracle.com Thu Oct 11 08:42:15 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Oct 2012 08:42:15 -0700 Subject: RFR (XS) 8000753: compiler/6912517 crashes on 64bit sparc with compressed oops off In-Reply-To: <832F9944-3F87-4019-96B5-CC4ECFB7987B@oracle.com> References: <35EA2327-E87A-4B50-8E2A-1290B01D888F@oracle.com> <832F9944-3F87-4019-96B5-CC4ECFB7987B@oracle.com> Message-ID: UseCompressedKlassPointers is constant 'false' in 32bit VM so ShouldNotReachHere() branch will not be executed and useless. How about this code: #ifdef _LP64 if (offset -- ? && UseCompressedKlassPointers) { ? } else #endif { Vladimir On Oct 11, 2012, at 7:50 AM, Roland Westrelin wrote: > (resent with bug number in subject) > > Small bug introduced by compressed klass pointer support: > > http://cr.openjdk.java.net/~roland/8000753/webrev.00/ > > Roland. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121011/38c0426d/attachment.html From roland.westrelin at oracle.com Thu Oct 11 08:44:14 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 11 Oct 2012 17:44:14 +0200 Subject: RFR (XS) 8000753: compiler/6912517 crashes on 64bit sparc with compressed oops off In-Reply-To: References: <35EA2327-E87A-4B50-8E2A-1290B01D888F@oracle.com> <832F9944-3F87-4019-96B5-CC4ECFB7987B@oracle.com> Message-ID: > UseCompressedKlassPointers is constant 'false' in 32bit VM so ShouldNotReachHere() branch will not be executed and useless. How about this code: > #ifdef _LP64 > if (offset -- ? && UseCompressedKlassPointers) { > ? > } else > #endif > { Ok. Should I push it? Roland. From vladimir.kozlov at oracle.com Thu Oct 11 09:11:35 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Oct 2012 09:11:35 -0700 Subject: RFR (XS) 8000753: compiler/6912517 crashes on 64bit sparc with compressed oops off In-Reply-To: References: <35EA2327-E87A-4B50-8E2A-1290B01D888F@oracle.com> <832F9944-3F87-4019-96B5-CC4ECFB7987B@oracle.com> Message-ID: <022A7E8D-6A95-48C5-A799-0CDD8957344A@oracle.com> Go ahead. Thanks, Vladimir On Oct 11, 2012, at 8:44 AM, Roland Westrelin wrote: >> UseCompressedKlassPointers is constant 'false' in 32bit VM so ShouldNotReachHere() branch will not be executed and useless. How about this code: >> #ifdef _LP64 >> if (offset -- ? && UseCompressedKlassPointers) { >> ? >> } else >> #endif >> { > > Ok. Should I push it? > > Roland. From roland.westrelin at oracle.com Thu Oct 11 09:16:50 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 11 Oct 2012 18:16:50 +0200 Subject: RFR (XS) 8000753: compiler/6912517 crashes on 64bit sparc with compressed oops off In-Reply-To: <022A7E8D-6A95-48C5-A799-0CDD8957344A@oracle.com> References: <35EA2327-E87A-4B50-8E2A-1290B01D888F@oracle.com> <832F9944-3F87-4019-96B5-CC4ECFB7987B@oracle.com> <022A7E8D-6A95-48C5-A799-0CDD8957344A@oracle.com> Message-ID: Thanks for the review. Roland. From christian.thalinger at oracle.com Thu Oct 11 11:09:20 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 11 Oct 2012 11:09:20 -0700 Subject: RFR (M): 8000740: remove LinkWellKnownClasses In-Reply-To: <50762A66.3050602@oracle.com> References: <533EDED2-7E5A-4BA0-A23A-F7F19FD2EC7A@oracle.com> <50762A66.3050602@oracle.com> Message-ID: <6760C372-6A95-4F61-9661-9447D42F3C2D@oracle.com> Thank you, Vladimir. -- Chris On Oct 10, 2012, at 7:09 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > On 10/10/12 5:10 PM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/8000740/ >> >> 8000740: remove LinkWellKnownClasses >> Reviewed-by: >> >> With 8000263 LinkWellKnownClasses was turned on by default to see if >> it works. Nightly testing showed that various JDI and JVMTI tests fail >> with LinkWellKnownClasses turned on, e.g.: >> >> jdk/test/com/sun/jdi/NewInstanceTest.java >> >> To avoid future problems we remove the code altogether. >> >> Additionally I resurrected some 292 code that is required when >> building with JDK 6. >> >> src/share/vm/classfile/classFileParser.cpp >> src/share/vm/classfile/classFileParser.hpp >> src/share/vm/classfile/systemDictionary.cpp >> src/share/vm/classfile/systemDictionary.hpp >> src/share/vm/prims/methodHandles.cpp >> src/share/vm/runtime/globals.hpp >> From roland.westrelin at oracle.com Thu Oct 11 11:54:47 2012 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Thu, 11 Oct 2012 18:54:47 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8000753: compiler/6912517 crashes on 64bit sparc with compressed oops off Message-ID: <20121011185454.E698B472C5@hg.openjdk.java.net> Changeset: 94e9408dbf50 Author: roland Date: 2012-10-11 18:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/94e9408dbf50 8000753: compiler/6912517 crashes on 64bit sparc with compressed oops off Summary: code generated by c1 for getClass intrinsic broken when klass field is loaded on 64bit with compressed klass off. Reviewed-by: kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp From john.r.rose at oracle.com Thu Oct 11 12:00:01 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 11 Oct 2012 12:00:01 -0700 Subject: RFR (M): 8000740: remove LinkWellKnownClasses In-Reply-To: <533EDED2-7E5A-4BA0-A23A-F7F19FD2EC7A@oracle.com> References: <533EDED2-7E5A-4BA0-A23A-F7F19FD2EC7A@oracle.com> Message-ID: The change in methodHandles.cpp is not under -XX:+LinkWellKnownClasses. As the comment says, it is intended to be an optional optimization for 292 users. The short-cut for Object (and maybe Class) is probably necessary for bootstrapping. I don't think there will be a regression there, but let's be watchful. Code removal is good... Reviewed. ? John On Oct 10, 2012, at 5:10 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8000740/ > > 8000740: remove LinkWellKnownClasses > Reviewed-by: > > With 8000263 LinkWellKnownClasses was turned on by default to see if > it works. Nightly testing showed that various JDI and JVMTI tests fail > with LinkWellKnownClasses turned on, e.g.: > > jdk/test/com/sun/jdi/NewInstanceTest.java > > To avoid future problems we remove the code altogether. > > Additionally I resurrected some 292 code that is required when > building with JDK 6. > > src/share/vm/classfile/classFileParser.cpp > src/share/vm/classfile/classFileParser.hpp > src/share/vm/classfile/systemDictionary.cpp > src/share/vm/classfile/systemDictionary.hpp > src/share/vm/prims/methodHandles.cpp > src/share/vm/runtime/globals.hpp > From john.coomes at oracle.com Thu Oct 11 13:08:19 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Oct 2012 20:08:19 +0000 Subject: hg: hsx/hotspot-comp: 4 new changesets Message-ID: <20121011200820.2B706472D1@hg.openjdk.java.net> Changeset: dae9821589cc Author: katleman Date: 2012-09-27 11:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/dae9821589cc Added tag jdk8-b58 for changeset 936702480487 ! .hgtags Changeset: b9d574659206 Author: katleman Date: 2012-10-04 14:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/b9d574659206 Added tag jdk8-b59 for changeset dae9821589cc ! .hgtags Changeset: 4b54d77a6831 Author: dholmes Date: 2012-10-09 02:08 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/4b54d77a6831 8000461: Top level build doesn't pass OPENJDK=true through to the hotspot build Summary: Add OPENJDK to the COMMON_BUILD_ARGUMENTS Reviewed-by: tbell ! make/Defs-internal.gmk Changeset: e07f499b9dcc Author: katleman Date: 2012-10-10 14:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/e07f499b9dcc Merge From john.coomes at oracle.com Thu Oct 11 13:08:23 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Oct 2012 20:08:23 +0000 Subject: hg: hsx/hotspot-comp/corba: 2 new changesets Message-ID: <20121011200826.5DABA472D2@hg.openjdk.java.net> Changeset: d54dc53e223e Author: katleman Date: 2012-09-27 11:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/d54dc53e223e Added tag jdk8-b58 for changeset 18462a19f7bd ! .hgtags Changeset: 207ef43ba69e Author: katleman Date: 2012-10-04 14:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/207ef43ba69e Added tag jdk8-b59 for changeset d54dc53e223e ! .hgtags From john.coomes at oracle.com Thu Oct 11 13:08:30 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Oct 2012 20:08:30 +0000 Subject: hg: hsx/hotspot-comp/jaxp: 2 new changesets Message-ID: <20121011200839.13884472D3@hg.openjdk.java.net> Changeset: af9e8b0f1900 Author: katleman Date: 2012-09-27 11:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/af9e8b0f1900 Added tag jdk8-b58 for changeset 1cb19abb3f7b ! .hgtags Changeset: 2d1dff5310da Author: katleman Date: 2012-10-04 14:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/2d1dff5310da Added tag jdk8-b59 for changeset af9e8b0f1900 ! .hgtags From john.coomes at oracle.com Thu Oct 11 13:08:43 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Oct 2012 20:08:43 +0000 Subject: hg: hsx/hotspot-comp/jaxws: 2 new changesets Message-ID: <20121011200849.29AD8472D4@hg.openjdk.java.net> Changeset: ae107401be11 Author: katleman Date: 2012-09-27 11:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/ae107401be11 Added tag jdk8-b58 for changeset cac4c3937063 ! .hgtags Changeset: 5c5a65ad5291 Author: katleman Date: 2012-10-04 14:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/5c5a65ad5291 Added tag jdk8-b59 for changeset ae107401be11 ! .hgtags From john.coomes at oracle.com Thu Oct 11 13:10:35 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Oct 2012 20:10:35 +0000 Subject: hg: hsx/hotspot-comp/jdk: 64 new changesets Message-ID: <20121011202818.AA48E472D6@hg.openjdk.java.net> Changeset: 8a64eeca4450 Author: jgodinez Date: 2012-09-10 10:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8a64eeca4450 7183516: [macosx]Can't print-out the defined fonts for PrintFont_2D and AntialiasTableTest. Reviewed-by: bae, prr ! src/macosx/native/sun/awt/CTextPipe.m Changeset: db828a233f20 Author: bae Date: 2012-09-11 13:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/db828a233f20 7181199: [macosx] Startup is much slower in headless mode for apps using Fonts Reviewed-by: jgodinez, prr ! src/macosx/classes/sun/font/CFontManager.java Changeset: bce9611f1e8f Author: lana Date: 2012-09-14 13:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bce9611f1e8f Merge ! src/macosx/native/sun/awt/CTextPipe.m Changeset: 0ecf1a700fca Author: bae Date: 2012-09-17 13:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0ecf1a700fca 7186799: Regression tests for ImageIO metadata fail on second run Reviewed-by: prr, bae Contributed-by: Vadim Pakhnushev ! test/javax/imageio/metadata/BooleanAttributes.java ! test/javax/imageio/metadata/DOML3Node.java + test/javax/imageio/metadata/GetChildNames.java + test/javax/imageio/metadata/GetObjectMinValue.java + test/javax/imageio/metadata/IIOMetadataFormat/MetadataFormatTest.java + test/javax/imageio/metadata/IIOMetadataFormat/MetadataFormatThreadTest.java + test/javax/imageio/metadata/IIOMetadataFormat/MetadataTest.java + test/javax/imageio/metadata/IIOMetadataFormat/UserPluginMetadataFormatTest.java + test/javax/imageio/metadata/IIOMetadataFormat/runMetadataFormatTest.sh + test/javax/imageio/metadata/IIOMetadataFormat/runMetadataFormatThreadTest.sh + test/javax/imageio/metadata/IIOMetadataFormatImplTest.java + test/javax/imageio/metadata/MetadataFormatPrinter.java + test/javax/imageio/metadata/ObjectArrayMaxLength.java + test/javax/imageio/metadata/RegisteredFormatsTest.java + test/javax/imageio/metadata/RemoveElement.java + test/javax/imageio/metadata/SetAttributeNode.java Changeset: 47442b1b01eb Author: kizune Date: 2012-09-06 14:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/47442b1b01eb 7175183: [macosx] Objective-C exception thrown when switching monitor configuration Reviewed-by: prr, serb ! src/share/classes/sun/awt/image/VolatileSurfaceManager.java Changeset: d14dc0ae1c2c Author: bagiras Date: 2012-09-06 17:57 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d14dc0ae1c2c 7153339: InternalError when drawLine with Xor and Antialiasing Reviewed-by: prr, flar ! src/windows/classes/sun/java2d/ScreenUpdateManager.java Changeset: b8a1ff892b33 Author: alexsch Date: 2012-09-07 13:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b8a1ff892b33 7194469: Pressing the Enter key results in an alert tone beep when focus is TextField Reviewed-by: bagiras, denis ! src/windows/native/sun/windows/awt_TextField.cpp Changeset: 04292c0c943b Author: malenkov Date: 2012-09-11 10:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/04292c0c943b 7193977: REGRESSION:Java 7's JavaBeans persistence ignoring the "transient" flag on properties Reviewed-by: rupashka ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test7193977.java Changeset: 3a2f5544dd00 Author: serb Date: 2012-09-12 21:16 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3a2f5544dd00 7124534: [macosx] Submenu title overlaps with Submenu indicator in JPopupMenu Reviewed-by: art + test/javax/swing/JMenuItem/6438430/bug6438430.java Changeset: aa35dc4d3f70 Author: bagiras Date: 2012-09-13 19:53 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/aa35dc4d3f70 7186109: Simplify lock machinery for PostEventQueue & EventQueue Reviewed-by: art, anthony, dholmes ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/sun/awt/SunToolkit.java + test/java/awt/EventQueue/PostEventOrderingTest/PostEventOrderingTest.java Changeset: 5b7ad5bedbd7 Author: bagiras Date: 2012-09-13 21:23 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5b7ad5bedbd7 7198318: SunToolkitSubclass.java should be removed Reviewed-by: serb - src/macosx/classes/sun/awt/SunToolkitSubclass.java Changeset: 5444be588d18 Author: alexsch Date: 2012-09-14 15:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5444be588d18 7197320: [macosx] Full Screen option missing when Window.documentModified Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 77fdcd3df205 Author: alexsch Date: 2012-09-14 15:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/77fdcd3df205 7196547: [macosx] Implement dead key detection for KeyEvent Reviewed-by: skovatch, kizune ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/macosx/native/sun/awt/AWTEvent.m + test/java/awt/event/KeyEvent/DeadKey/deadKeyMacOSX.java Changeset: 1785f8335f4d Author: VKARNAUK Date: 2012-09-14 19:51 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1785f8335f4d 6994562: Swing classes (both JTextArea and JTextField) don't support caret width tuning Reviewed-by: rupashka, art ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_DesktopProperties.h Changeset: b6ad3339f3f4 Author: lana Date: 2012-09-14 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b6ad3339f3f4 Merge Changeset: 1ed7fec79bee Author: leonidr Date: 2012-09-17 17:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1ed7fec79bee 7160951: ActionListener called twice for JMenuItem using ScreenMenuBar Reviewed-by: anthony, serb Contributed-by: Marco Dinacci ! src/macosx/native/sun/awt/AWTEvent.h ! src/macosx/native/sun/awt/AWTEvent.m ! src/macosx/native/sun/awt/CDragSource.m ! src/macosx/native/sun/awt/CMenuItem.m ! src/macosx/native/sun/awt/DnDUtilities.h ! src/macosx/native/sun/awt/DnDUtilities.m Changeset: 1d1254af05dd Author: kshefov Date: 2012-09-18 17:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1d1254af05dd 7190587: Open source and jtreg'ify JAWT regression test Reviewed-by: anthony, omajid + test/java/awt/JAWT/JAWT.sh + test/java/awt/JAWT/Makefile.cygwin + test/java/awt/JAWT/Makefile.unix + test/java/awt/JAWT/Makefile.win + test/java/awt/JAWT/MyCanvas.java + test/java/awt/JAWT/myfile.c + test/java/awt/JAWT/myfile.cpp Changeset: a96f5b1d03f9 Author: lana Date: 2012-09-19 12:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a96f5b1d03f9 Merge - src/macosx/classes/sun/awt/SunToolkitSubclass.java Changeset: 076d0dafea5f Author: mgerdin Date: 2012-09-06 14:07 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/076d0dafea5f 7195557: NPG: Unexpected number of memory pools Summary: Update management tests to work with a VM without a permanent generation memory pool Reviewed-by: rbackman, brutisso, sla, dholmes ! test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java ! test/java/lang/management/MemoryMXBean/MemoryTest.java Changeset: 8c6895afe204 Author: lancea Date: 2012-09-06 13:16 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8c6895afe204 7192302: Remove JDBCRowSetImpl dependency on java.beans Reviewed-by: alanb, mchung ! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java Changeset: 833f4630f3a1 Author: weijun Date: 2012-09-07 10:24 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/833f4630f3a1 7196677: diff compares same file to itself in PaddingTest regression test. Reviewed-by: xuelei ! test/com/sun/crypto/provider/Cipher/DES/PaddingTest.java Changeset: d5d24c08f0dc Author: chegar Date: 2012-09-07 14:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d5d24c08f0dc 7032247: java/net/InetAddress/GetLocalHostWithSM.java fails if hostname resolves to loopback address Summary: TESTBUG Reviewed-by: chegar, alanb Contributed-by: Eric Wang ! test/java/net/InetAddress/GetLocalHostWithSM.java Changeset: 3857114d8255 Author: chegar Date: 2012-09-07 15:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3857114d8255 6354758: rename old test HttpServer classes Reviewed-by: chegar, michaelm, khazra Contributed-by: John Zavgren ! test/java/net/Authenticator/B4678055.java ! test/java/net/Authenticator/B4722333.java ! test/java/net/Authenticator/B4759514.java ! test/java/net/Authenticator/B4769350.java ! test/java/net/Authenticator/B4921848.java ! test/java/net/Authenticator/B4933582.java ! test/java/net/Authenticator/B4962064.java ! test/java/net/CookieHandler/CookieManagerTest.java ! test/java/net/ProxySelector/LoopbackAddresses.java ! test/java/net/ProxySelector/ProxyTest.java ! test/java/net/URL/PerConnectionProxy.java ! test/java/net/URLConnection/B5052093.java ! test/sun/net/www/AuthHeaderTest.java ! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingWithProgressMonitorTest.java ! test/sun/net/www/http/KeepAliveCache/B5045306.java - test/sun/net/www/httptest/HttpServer.java ! test/sun/net/www/httptest/HttpTransaction.java + test/sun/net/www/httptest/TestHttpServer.java ! test/sun/net/www/protocol/http/B6296310.java ! test/sun/net/www/protocol/http/B6299712.java ! test/sun/net/www/protocol/http/RelativeRedirect.java ! test/sun/net/www/protocol/http/ResponseCacheStream.java ! test/sun/net/www/protocol/http/SetChunkedStreamingMode.java ! test/sun/security/ssl/sun/net/www/http/ChunkedOutputStream/Test.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java ! test/sun/security/ssl/sun/net/www/httpstest/HttpTransaction.java + test/sun/security/ssl/sun/net/www/httpstest/TestHttpsServer.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java Changeset: 7f081e14364e Author: mullan Date: 2012-09-07 12:49 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7f081e14364e 4647343: IDENT variable in sun.security.x509 classes not used Reviewed-by: mullan Contributed-by: jason.uh at oracle.com - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java ! src/share/classes/sun/security/x509/X509CertImpl.java ! src/share/classes/sun/security/x509/X509CertInfo.java Changeset: fffbb33df102 Author: coffeys Date: 2012-09-07 21:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fffbb33df102 7180362: RFE: Implement date cutover functionality for currency.properties file Reviewed-by: naoto ! src/share/classes/java/util/Currency.java ! test/java/util/Currency/PropertiesTest.java ! test/java/util/Currency/PropertiesTest.sh ! test/java/util/Currency/currency.properties Changeset: a51f86e2dce9 Author: mullan Date: 2012-09-10 08:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a51f86e2dce9 7195301: XML Signature DOM implementation should not use instanceof to determine type of Node Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/Init.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java ! src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RetrievalMethodResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IdResolver.java Changeset: a14d41fd6f51 Author: mullan Date: 2012-09-10 09:00 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a14d41fd6f51 Merge - make/sun/beans/Makefile - src/share/classes/sun/beans/editors/BooleanEditor.java - src/share/classes/sun/beans/editors/ByteEditor.java - src/share/classes/sun/beans/editors/ColorEditor.java - src/share/classes/sun/beans/editors/DoubleEditor.java - src/share/classes/sun/beans/editors/EnumEditor.java - src/share/classes/sun/beans/editors/FloatEditor.java - src/share/classes/sun/beans/editors/FontEditor.java - src/share/classes/sun/beans/editors/IntegerEditor.java - src/share/classes/sun/beans/editors/LongEditor.java - src/share/classes/sun/beans/editors/NumberEditor.java - src/share/classes/sun/beans/editors/ShortEditor.java - src/share/classes/sun/beans/editors/StringEditor.java - src/share/classes/sun/beans/infos/ComponentBeanInfo.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - src/solaris/classes/sun/awt/X11/XTextTransferHelper.java - test/javax/swing/JColorChooser/Test4380468.html - test/javax/swing/JColorChooser/Test4380468.java - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: 657f7cb0da7e Author: mullan Date: 2012-09-10 09:18 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/657f7cb0da7e Merge Changeset: 2598dad44449 Author: dsamersoff Date: 2012-09-11 19:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2598dad44449 7194597: Typeo in com.sun.management.VMOption.toString() Summary: VMOption.toString() returns "...(read-only)" if writable "...(read-write)" otherwise. Reviewed-by: alanb, mchung Contributed-by: dmytro_sheyko at hotmail.com ! src/share/classes/com/sun/management/VMOption.java Changeset: 1f7c783e4f13 Author: dxu Date: 2012-08-31 13:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1f7c783e4f13 7193406: Clean-up JDK Build Warnings in java.util, java.io Summary: Clean-up JDK Build Warnings in java.util, java.io Packages Reviewed-by: smarks, darcy, khazra, dholmes, forax, dl, andrew, aph, omajid, ulfzibis, christos, mduigou ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/util/ArrayDeque.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/ComparableTimSort.java ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/JumboEnumSet.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/java/util/PropertyResourceBundle.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/java/util/jar/Pack200.java ! src/share/classes/sun/util/PreHashedMap.java Changeset: 7a16cd3bd2d9 Author: mullan Date: 2012-09-12 15:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7a16cd3bd2d9 7196593: java.security.debug=help doesn't list certpath option Reviewed-by: mullan, wetmore, valeriep Contributed-by: jason.uh at oracle.com ! src/share/classes/sun/security/util/Debug.java Changeset: f8c1cf072ba6 Author: mullan Date: 2012-09-12 15:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f8c1cf072ba6 Merge Changeset: e095be3820ee Author: chegar Date: 2012-09-13 11:17 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e095be3820ee 7197203: sun/misc/URLClassPath/ClassnameCharTest.sh failed, compile error Reviewed-by: alanb ! test/sun/misc/URLClassPath/ClassnameCharTest.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh Changeset: e8a3807de977 Author: alanb Date: 2012-09-13 15:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e8a3807de977 7197637: (ch) sun.nio.ch.Default* cause providers for other platforms to be included in rt.jar Reviewed-by: mchung ! src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java ! src/solaris/classes/sun/nio/ch/DefaultSelectorProvider.java ! src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java Changeset: eae1384cff39 Author: mullan Date: 2012-09-14 10:13 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/eae1384cff39 7176627: CertPath/jep124/PreferCRL_SoftFail test fails (Could not determine revocation status) Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/CertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/OCSP.java ! src/share/classes/sun/security/provider/certpath/PKIX.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStoreHelper.java ! src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStoreHelper.java Changeset: 34bcbb110bb0 Author: mullan Date: 2012-09-14 10:14 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/34bcbb110bb0 Merge - make/sun/beans/Makefile - src/share/classes/sun/beans/editors/BooleanEditor.java - src/share/classes/sun/beans/editors/ByteEditor.java - src/share/classes/sun/beans/editors/ColorEditor.java - src/share/classes/sun/beans/editors/DoubleEditor.java - src/share/classes/sun/beans/editors/EnumEditor.java - src/share/classes/sun/beans/editors/FloatEditor.java - src/share/classes/sun/beans/editors/FontEditor.java - src/share/classes/sun/beans/editors/IntegerEditor.java - src/share/classes/sun/beans/editors/LongEditor.java - src/share/classes/sun/beans/editors/NumberEditor.java - src/share/classes/sun/beans/editors/ShortEditor.java - src/share/classes/sun/beans/editors/StringEditor.java - src/share/classes/sun/beans/infos/ComponentBeanInfo.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - src/solaris/classes/sun/awt/X11/XTextTransferHelper.java - test/javax/swing/JColorChooser/Test4380468.html - test/javax/swing/JColorChooser/Test4380468.java - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: c11cec5a9306 Author: mullan Date: 2012-09-14 10:30 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c11cec5a9306 Merge - test/sun/misc/URLClassPath/ClassnameCharTest.sh Changeset: 22d7a9f73a59 Author: mchung Date: 2012-09-14 09:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/22d7a9f73a59 7193302: Remove ConstructorProperties annotation from java.lang.management.LockInfo Reviewed-by: alanb, sla, egahlin ! src/share/classes/java/lang/management/LockInfo.java ! src/share/classes/java/lang/management/ThreadInfo.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java + src/share/classes/sun/management/LockInfoCompositeData.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/management/MonitorInfoCompositeData.java ! src/share/classes/sun/management/ThreadInfoCompositeData.java ! test/java/lang/management/ManagementFactory/ThreadMXBeanProxy.java Changeset: 356ff53c9b6d Author: lana Date: 2012-09-14 10:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/356ff53c9b6d Merge - test/java/lang/invoke/MaxTest.java Changeset: 92f3cda88d8e Author: mduigou Date: 2012-09-11 07:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/92f3cda88d8e 7189926: Reduce test size for default run. Add additional run enabling alternative hashing. Reviewed-by: alanb ! test/java/util/Map/Collisions.java Changeset: 17881ebf811c Author: mullan Date: 2012-09-16 13:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/17881ebf811c 7195409: CertPath/CertPathValidatorTest/KeyParamsInheritanceTest fails with NullPointerException Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/AlgorithmChecker.java ! src/share/classes/sun/security/provider/certpath/BasicChecker.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/ForwardState.java ! src/share/classes/sun/security/provider/certpath/PKIX.java ! src/share/classes/sun/security/provider/certpath/ReverseState.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java Changeset: 0c3b0a82c4fc Author: weijun Date: 2012-09-17 17:19 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0c3b0a82c4fc 7198205: CloseTest fails on mac Reviewed-by: alanb, chegar, michaelm ! test/ProblemList.txt ! test/java/net/URLClassLoader/closetest/CloseTest.java Changeset: 39e97f68fa8c Author: sla Date: 2012-09-17 11:27 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/39e97f68fa8c 7198846: Add javax/management/remote/mandatory/notif/DiffHBTest.java to ProblemList.txt Reviewed-by: alanb ! test/ProblemList.txt Changeset: f56f85040c58 Author: weijun Date: 2012-09-17 18:19 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f56f85040c58 7196855: autotest.sh fails on ubuntu because libsoftokn.so not found Reviewed-by: vinnie ! test/sun/security/tools/keytool/autotest.sh Changeset: 8a454e92aaf1 Author: sla Date: 2012-09-17 12:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8a454e92aaf1 7198849: Make javax/management/remote/mandatory/notif/ListenerScaleTest.java less timing sensitive Reviewed-by: alanb ! test/javax/management/remote/mandatory/notif/ListenerScaleTest.java Changeset: e20a2e6a92f7 Author: mduigou Date: 2012-09-17 11:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e20a2e6a92f7 7198988: re-order paramaters for Collision.java @run Reviewed-by: alanb ! test/java/util/Map/Collisions.java Changeset: 53ca38f76eaa Author: weijun Date: 2012-09-18 17:38 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/53ca38f76eaa 7198871: cleanup security tests in problem lists with no CR attached Reviewed-by: alanb ! test/ProblemList.txt Changeset: 95a93f039e5c Author: vinnie Date: 2012-09-18 11:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/95a93f039e5c 7198901: correct the field size check when decoding a point on ECC curve Reviewed-by: xuelei ! src/share/classes/sun/security/ec/ECParameters.java Changeset: bc5e7ec12717 Author: dxu Date: 2012-09-18 13:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bc5e7ec12717 7142919: TEST_BUG: java/nio/channels/AsyncCloseAndInterrupt.java failing intermittently [sol11] Reviewed-by: alanb ! test/ProblemList.txt ! test/java/nio/channels/AsyncCloseAndInterrupt.java Changeset: 88a4f699d233 Author: xuelei Date: 2012-09-18 06:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/88a4f699d233 7199066: Typo in method name Reviewed-by: mullan ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 0136fca60652 Author: naoto Date: 2012-09-18 10:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0136fca60652 7198984: Add java/text/Bidi/Bug6665028.java to ProblemList.txt Reviewed-by: alanb Contributed-by: yiming.wang at oracle.com ! test/ProblemList.txt Changeset: e7add6d98729 Author: mduigou Date: 2012-09-18 11:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e7add6d98729 7199249: TEST_BUG : Add /othervm to Collisions.java @run main with -D definitions Reviewed-by: alanb ! test/java/util/Map/Collisions.java Changeset: db381a2c0083 Author: alanb Date: 2012-09-18 21:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/db381a2c0083 7190273: Deprecate com.sun.security.auth.callback.DialogCallbackHandler Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java Changeset: e143d8f8e477 Author: dxu Date: 2012-09-18 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e143d8f8e477 7195933: There is incorrect link to "Info-ZIP Application Note 970311" in doc page of Package java.util.zip Summary: Correct a java doc link in java.util.zip package page Reviewed-by: chegar, lancea, sherman Contributed-by: dan.xu at oracle.com ! src/share/classes/java/util/zip/package.html Changeset: 045a0962b430 Author: mchung Date: 2012-09-18 15:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/045a0962b430 7198070: Eliminate static dependency from JMX to java.beans.ConstructorProperties Reviewed-by: alanb ! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java Changeset: 5d064862376d Author: jgish Date: 2012-09-19 08:52 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5d064862376d 4722265: (spec str) StringBuffer.ensureCapacity() should mention that capacity is mutable Summary: add usage note to AbstractStringBuilder ensureCapacity() Reviewed-by: mduigou, dholmes, chegar ! src/share/classes/java/lang/AbstractStringBuilder.java Changeset: 27182d84a244 Author: chegar Date: 2012-09-19 14:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/27182d84a244 7199500: Minor typo in AbstractStringBuilder.java header Reviewed-by: coffeys ! src/share/classes/java/lang/AbstractStringBuilder.java Changeset: 002717a1418f Author: lana Date: 2012-09-19 12:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/002717a1418f Merge - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: 3f876919cd58 Author: lana Date: 2012-09-24 21:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3f876919cd58 Merge - src/macosx/classes/sun/awt/SunToolkitSubclass.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: 4015dec20965 Author: amurillo Date: 2012-09-26 13:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4015dec20965 Merge - src/macosx/classes/sun/awt/SunToolkitSubclass.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java ! test/ProblemList.txt - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: c9568c94c4e7 Author: ohair Date: 2012-09-21 12:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c9568c94c4e7 7191703: jprt cannot build jdk on MacOSX. Reviewed-by: anthony ! make/common/shared/Defs.gmk ! make/java/jobjc/Makefile Changeset: d94613ac03d8 Author: katleman Date: 2012-09-26 22:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d94613ac03d8 Merge - src/macosx/classes/sun/awt/SunToolkitSubclass.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: abad1f417bd3 Author: katleman Date: 2012-09-27 11:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/abad1f417bd3 Added tag jdk8-b58 for changeset d94613ac03d8 ! .hgtags Changeset: cec8fa02f156 Author: katleman Date: 2012-10-04 14:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cec8fa02f156 Added tag jdk8-b59 for changeset abad1f417bd3 ! .hgtags From john.coomes at oracle.com Thu Oct 11 13:36:43 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 11 Oct 2012 20:36:43 +0000 Subject: hg: hsx/hotspot-comp/langtools: 12 new changesets Message-ID: <20121011203740.403DC472D8@hg.openjdk.java.net> Changeset: 489905e5018e Author: jjg Date: 2012-09-07 11:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/489905e5018e 7186925: JavapTask passes null to java.io.Writer Reviewed-by: jjh ! src/share/classes/com/sun/tools/javap/JavapTask.java + test/tools/javap/T7186925.java Changeset: 324b98626f58 Author: jjg Date: 2012-09-07 11:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/324b98626f58 7196774: javac cannot be built with JDK 6 after 7151010 Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Annotate.java Changeset: 1a7c11b22192 Author: jjg Date: 2012-09-07 11:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/1a7c11b22192 7196760: tree end positions incorrect after anno processing Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Log.java + test/tools/javac/api/EndPositions.java Changeset: fa85af323d97 Author: bpatel Date: 2012-09-08 22:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/fa85af323d97 7180906: Javadoc tool does not apply parameter -nosince Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java + test/com/sun/javadoc/testSinceTag/TestSinceTag.java + test/com/sun/javadoc/testSinceTag/pkg1/C1.java Changeset: b2064a216117 Author: bpatel Date: 2012-09-08 22:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/b2064a216117 Merge Changeset: 30c36e23f154 Author: jjg Date: 2012-09-13 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/30c36e23f154 7177970: fix issues in langtools doc comments Reviewed-by: mcimadamore ! src/share/classes/com/sun/javadoc/Doc.java ! src/share/classes/com/sun/javadoc/ExecutableMemberDoc.java ! src/share/classes/com/sun/javadoc/Tag.java ! src/share/classes/com/sun/source/tree/LambdaExpressionTree.java ! src/share/classes/com/sun/source/tree/LineMap.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.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/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/ByteCodes.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! 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/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Lexer.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/util/Bits.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javac/util/Name.java ! src/share/classes/com/sun/tools/javac/util/Position.java ! src/share/classes/com/sun/tools/javadoc/Comment.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/javax/lang/model/util/Elements.java ! src/share/classes/javax/tools/JavaCompiler.java Changeset: fabfd2710057 Author: ksrini Date: 2012-09-14 09:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/fabfd2710057 7192073: (javac) minor refactoring of tree maker to help IDEs Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java Changeset: 8c3c714eb7de Author: lana Date: 2012-09-14 10:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/8c3c714eb7de Merge Changeset: a433bd8f3ba9 Author: lana Date: 2012-09-14 13:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a433bd8f3ba9 Merge Changeset: 804a3fbc86e2 Author: lana Date: 2012-09-24 21:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/804a3fbc86e2 Merge Changeset: f299927fc316 Author: katleman Date: 2012-09-27 11:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f299927fc316 Added tag jdk8-b58 for changeset 804a3fbc86e2 ! .hgtags Changeset: 3d2b98ffcb53 Author: katleman Date: 2012-10-04 14:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/3d2b98ffcb53 Added tag jdk8-b59 for changeset f299927fc316 ! .hgtags From christian.thalinger at oracle.com Thu Oct 11 14:53:29 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 11 Oct 2012 14:53:29 -0700 Subject: RFR (M): 8000740: remove LinkWellKnownClasses In-Reply-To: References: <533EDED2-7E5A-4BA0-A23A-F7F19FD2EC7A@oracle.com> Message-ID: <6925930A-60AC-4CCE-938D-E20B60891296@oracle.com> On Oct 11, 2012, at 12:00 PM, John Rose wrote: > The change in methodHandles.cpp is not under -XX:+LinkWellKnownClasses. > As the comment says, it is intended to be an optional optimization for 292 users. > The short-cut for Object (and maybe Class) is probably necessary for bootstrapping. > I don't think there will be a regression there, but let's be watchful. I ran the JDK 292 tests and Nashorn stuff and it looked good. Thanks for the review. -- Chris > > Code removal is good... Reviewed. > > ? John > > On Oct 10, 2012, at 5:10 PM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/8000740/ >> >> 8000740: remove LinkWellKnownClasses >> Reviewed-by: >> >> With 8000263 LinkWellKnownClasses was turned on by default to see if >> it works. Nightly testing showed that various JDI and JVMTI tests fail >> with LinkWellKnownClasses turned on, e.g.: >> >> jdk/test/com/sun/jdi/NewInstanceTest.java >> >> To avoid future problems we remove the code altogether. >> >> Additionally I resurrected some 292 code that is required when >> building with JDK 6. >> >> src/share/vm/classfile/classFileParser.cpp >> src/share/vm/classfile/classFileParser.hpp >> src/share/vm/classfile/systemDictionary.cpp >> src/share/vm/classfile/systemDictionary.hpp >> src/share/vm/prims/methodHandles.cpp >> src/share/vm/runtime/globals.hpp >> > From christian.thalinger at oracle.com Thu Oct 11 16:35:42 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 11 Oct 2012 23:35:42 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8000740: remove LinkWellKnownClasses Message-ID: <20121011233547.2F304472FD@hg.openjdk.java.net> Changeset: 19eb999cb72c Author: twisti Date: 2012-10-11 14:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/19eb999cb72c 8000740: remove LinkWellKnownClasses Reviewed-by: kvn, jrose ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/globals.hpp From john.coomes at oracle.com Thu Oct 11 20:45:17 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 12 Oct 2012 03:45:17 +0000 Subject: hg: hsx/hotspot-comp: Added tag jdk8-b60 for changeset e07f499b9dcc Message-ID: <20121012034517.4FC9047308@hg.openjdk.java.net> Changeset: 20ff117b5090 Author: katleman Date: 2012-10-11 09:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/20ff117b5090 Added tag jdk8-b60 for changeset e07f499b9dcc ! .hgtags From john.coomes at oracle.com Thu Oct 11 20:45:20 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 12 Oct 2012 03:45:20 +0000 Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b60 for changeset 207ef43ba69e Message-ID: <20121012034523.18D2647309@hg.openjdk.java.net> Changeset: 41bb9e606efd Author: katleman Date: 2012-10-11 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/41bb9e606efd Added tag jdk8-b60 for changeset 207ef43ba69e ! .hgtags From john.coomes at oracle.com Thu Oct 11 20:45:28 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 12 Oct 2012 03:45:28 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b60 for changeset 2d1dff5310da Message-ID: <20121012034535.0D2E04730A@hg.openjdk.java.net> Changeset: 6b1db0b41d2f Author: katleman Date: 2012-10-11 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/6b1db0b41d2f Added tag jdk8-b60 for changeset 2d1dff5310da ! .hgtags From john.coomes at oracle.com Thu Oct 11 20:45:40 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 12 Oct 2012 03:45:40 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b60 for changeset 5c5a65ad5291 Message-ID: <20121012034545.7DE564730B@hg.openjdk.java.net> Changeset: 97e5e74e2a34 Author: katleman Date: 2012-10-11 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/97e5e74e2a34 Added tag jdk8-b60 for changeset 5c5a65ad5291 ! .hgtags From john.coomes at oracle.com Thu Oct 11 20:45:53 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 12 Oct 2012 03:45:53 +0000 Subject: hg: hsx/hotspot-comp/jdk: Added tag jdk8-b60 for changeset cec8fa02f156 Message-ID: <20121012034636.38FD54730C@hg.openjdk.java.net> Changeset: 869519bc17ce Author: katleman Date: 2012-10-11 09:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/869519bc17ce Added tag jdk8-b60 for changeset cec8fa02f156 ! .hgtags From john.coomes at oracle.com Thu Oct 11 20:49:09 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 12 Oct 2012 03:49:09 +0000 Subject: hg: hsx/hotspot-comp/langtools: Added tag jdk8-b60 for changeset 3d2b98ffcb53 Message-ID: <20121012034914.84FDB4730D@hg.openjdk.java.net> Changeset: 67f7408d935e Author: katleman Date: 2012-10-11 09:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/67f7408d935e Added tag jdk8-b60 for changeset 3d2b98ffcb53 ! .hgtags From christian.thalinger at oracle.com Fri Oct 12 11:42:34 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 12 Oct 2012 11:42:34 -0700 Subject: Bug report: failing to call overridden method In-Reply-To: References: Message-ID: <1C604ADB-4F2C-489C-A16F-0DFFBA31FF2E@oracle.com> On Oct 9, 2012, at 5:27 PM, Charles Oliver Nutter wrote: > I reported this to Christian, but thought I'd toss it here in case > someone else runs into it. > > It appears that C1 (tier 1) is failing to compile a indy + MH virtual > target into a proper overridden call. In other words, it doesn't honor > the override, and calls the direct target. > > Details are toward the end in this JRuby bug: > http://jira.codehaus.org/browse/JRUBY-6920 > > It only fails in tier 1 with indy enabled. Does not fail with -Xint or -Tiered. > > Hopefully that's enough to go on :) Indeed. Thanks for the deep analysis. I filed: 8000821: JSR 292: C1 fails to call virtual method (JRUBY-6920) -- Chris > > - Charlie > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From vladimir.x.ivanov at oracle.com Fri Oct 12 15:05:58 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 13 Oct 2012 02:05:58 +0400 Subject: -XX:CompileOnly command: how should it look like? Message-ID: <50789446.6080903@oracle.com> Hi, Are there any requirements on how -XX:CompileOnly command should look like? It's comma-separated list of class/method patterns, but pattern format differs from what is used in -XX:CompileCommand/XX:CompilerOracle. Moreover, code in CompilerOracle::parse_compile_only is broken. For example: $ java -XX:+PrintVMOptions -XX:CompileOnly=p1.c ... VM option '+PrintVMOptions' VM option 'CompileOnly=p1.c' CompileOnly: compileonly *p1*.c vs $ java -XX:+PrintVMOptions -XX:CompileOnly=p1.c,c1::m ... VM option '+PrintVMOptions' VM option 'CompileOnly=p1.c,c1::m' CompileOnly: compileonly p1/c*.* CompileOnly: compileonly *c1*.m I want to fix it, but also make it compliant with other compiler control options. What I want to understand is whether such change in format is safe. Best regards, Vladimir Ivanov From vladimir.kozlov at oracle.com Fri Oct 12 16:00:08 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Oct 2012 16:00:08 -0700 Subject: -XX:CompileOnly command: how should it look like? In-Reply-To: <50789446.6080903@oracle.com> References: <50789446.6080903@oracle.com> Message-ID: <5078A0F8.6020802@oracle.com> From what I remember originally we only accepted format ("," on command line to separate method and " " in .hotspot_compiler file): /c1/c2/c3,m Then Tom added next format to match PrintCompilation output: c1.c2.c3::m Vladimir Vladimir Ivanov wrote: > Hi, > > Are there any requirements on how -XX:CompileOnly command should look > like? It's comma-separated list of class/method patterns, but pattern > format differs from what is used in -XX:CompileCommand/XX:CompilerOracle. > > Moreover, code in CompilerOracle::parse_compile_only is broken. > > For example: > $ java -XX:+PrintVMOptions -XX:CompileOnly=p1.c ... > VM option '+PrintVMOptions' > VM option 'CompileOnly=p1.c' > CompileOnly: compileonly *p1*.c > > vs > > $ java -XX:+PrintVMOptions -XX:CompileOnly=p1.c,c1::m ... > VM option '+PrintVMOptions' > VM option 'CompileOnly=p1.c,c1::m' > CompileOnly: compileonly p1/c*.* > CompileOnly: compileonly *c1*.m > > I want to fix it, but also make it compliant with other compiler control > options. What I want to understand is whether such change in format is > safe. > > Best regards, > Vladimir Ivanov From john.r.rose at oracle.com Fri Oct 12 16:45:48 2012 From: john.r.rose at oracle.com (John Rose) Date: Fri, 12 Oct 2012 16:45:48 -0700 Subject: -XX:CompileOnly command: how should it look like? In-Reply-To: <5078A0F8.6020802@oracle.com> References: <50789446.6080903@oracle.com> <5078A0F8.6020802@oracle.com> Message-ID: <69EA2978-92BF-42D1-98A8-E615162534AB@oracle.com> On Oct 12, 2012, at 4:00 PM, Vladimir Kozlov wrote: > From what I remember originally we only accepted format ("," on command line to separate method and " " in .hotspot_compiler file): > > /c1/c2/c3,m > > Then Tom added next format to match PrintCompilation output: > > c1.c2.c3::m The original command form was three blank-separated fields, command classname methodname. We added ',' as an alias for ' ' (everywhere) to make it easy to pass CC options through various shells. The parser turns ',' to ' ', then separates into fields. We also added support for '::' as Vladimir said, to allow cut-and-paste of PrintC output names. Once again, the '::' turns into a field separator. The ',' does not mean "here is another part of a command", so CompileOnly=String.length,List.size is nonsense. Multiple commands are separated by newlines '\n'. This is most obvious in the .hotspot_compiler file, but is also true on the command line, because multiple accumulating string options are also glued together with newline '\n'. Thus, -XX:CompileCommand=foo -XX:CompileCommand=bar is the same as -XX:CompileCommand="foo${n}bar" where ${n} is a newline character. Here's the embedded comment from CompilerOracle::parse_from_line: // Allow '.' to separate the class name from the method name. // This is the preferred spelling of methods: // exclude java/lang/String.indexOf(I)I // Allow ',' for spaces (eases command line quoting). // exclude,java/lang/String.indexOf // For backward compatibility, allow space as separator also. // exclude java/lang/String indexOf // exclude,java/lang/String,indexOf // For easy cut-and-paste of method names, allow VM output format // as produced by Method::print_short_name: // exclude java.lang.String::indexOf (I admit it's kludgey stuff.) ? John From alejandro.murillo at oracle.com Fri Oct 12 18:14:44 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 13 Oct 2012 01:14:44 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 21 new changesets Message-ID: <20121013011524.9606847350@hg.openjdk.java.net> Changeset: 0cc77f9b31ad Author: katleman Date: 2012-10-11 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0cc77f9b31ad Added tag jdk8-b60 for changeset 3cfd05b2219a ! .hgtags Changeset: d8ce2825b193 Author: coleenp Date: 2012-09-29 06:40 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d8ce2825b193 8000213: NPG: Should have renamed arrayKlass and typeArrayKlass Summary: Capitalize these metadata types (and objArrayKlass) Reviewed-by: stefank, twisti, kvn ! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Metadata.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlass.java ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciArrayKlass.cpp ! src/share/vm/ci/ciArrayKlass.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciKlass.hpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObjArrayKlass.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciTypeArrayKlass.cpp ! src/share/vm/ci/ciTypeArrayKlass.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/specialized_oop_closures.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/objArrayKlass.inline.hpp ! src/share/vm/oops/objArrayOop.cpp ! src/share/vm/oops/objArrayOop.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp ! src/share/vm/oops/oop.psgc.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.hpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/shark/sharkRuntime.cpp Changeset: fab6fbf427d2 Author: kevinw Date: 2012-09-30 23:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fab6fbf427d2 7200145: runtime/7196045/Test7196045.java fails with No class provided for `main' Reviewed-by: dholmes, dsamersoff ! test/runtime/7196045/Test7196045.java Changeset: ba8fd2fe198b Author: coleenp Date: 2012-10-04 08:38 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ba8fd2fe198b 7198519: Broken build, hotspot-rt win USE_PRECOMPILED_HEADER=0 Summary: Uncommented out include for sys/stat.h and deleted include statements that were commented out. Reviewed-by: coleenp, acorn, dholmes Contributed-by: harold.seigel at oracle.com ! src/os/windows/vm/jvm_windows.h Changeset: bacdc1d5c21c Author: coleenp Date: 2012-10-04 08:43 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bacdc1d5c21c 6884973: java -XX:Atomics=2 crashes Summary: Remove buggy experimental option Reviewed-by: acorn, coleenp Contributed-by: harold.seigel at oracle.com ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 48087f745a86 Author: dholmes Date: 2012-10-04 19:52 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/48087f745a86 7199186: runtime/7194254/Test7194254.java fails - wrong test name on @run Reviewed-by: kvn, twisti ! test/runtime/7194254/Test7194254.java Changeset: f2eb2d4488db Author: dholmes Date: 2012-10-04 20:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f2eb2d4488db Merge Changeset: 75982791ddb6 Author: coleenp Date: 2012-10-08 09:18 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/75982791ddb6 7170638: Use DTRACE_PROBE[N] in JNI Set and SetStatic Field. Summary: Don't use HS_DTRACE_PROBE_CDECL_N and HS_DTRACE_PROBE_N directly. Reviewed-by: coleenp, kamg, dholmes, sspitsyn Contributed-by: Mark Wielaard ! make/bsd/makefiles/buildtree.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/dtrace.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/buildtree.make ! src/share/vm/prims/jni.cpp ! src/share/vm/utilities/dtrace.hpp Changeset: 7a40901e0d5c Author: minqi Date: 2012-10-08 16:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7a40901e0d5c 8000332: SA ClassDump throws exception after permgen removal Summary: In ClassWrite.writeFields(), fields count was mistakenly set to fields length which overflow the array index. Also removed a file which is leftover from 6879063 changeset. Reviewed-by: coleenp, sspitsyn Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/native/sadis.c Changeset: 0e8ca886e4e1 Author: minqi Date: 2012-10-08 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0e8ca886e4e1 Merge Changeset: 6e5a59a8e4a7 Author: rbackman Date: 2012-10-09 07:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6e5a59a8e4a7 Merge ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 26351ce8c4b0 Author: coleenp Date: 2012-10-09 02:42 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/26351ce8c4b0 8000622: Forgot to hg add and check in test for JDK-7170638 Summary: add the test Reviewed-by: coleenp, kamg Contributed-by: Mark Wielaard + test/serviceability/7170638/SDTProbesGNULinuxTest.sh Changeset: b9a9ed0f8eeb Author: mikael Date: 2012-10-09 10:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b9a9ed0f8eeb 7197424: update copyright year to match last edit in jdk8 hotspot repository Summary: Update copyright year to 2012 for relevant files Reviewed-by: dholmes, coleenp ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdCDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThreadContextFactory.java ! agent/src/share/classes/sun/jvm/hotspot/oops/BranchData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/CounterData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/JumpData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MultiBranchData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/VirtualCallData.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Bytes.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/BasicHashtable.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/BasicHashtableEntry.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableBucket.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableEntry.java ! make/bsd/Makefile ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/jvmg.make ! make/bsd/makefiles/launcher.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/rules.make ! make/bsd/makefiles/sparcWorks.make ! make/bsd/makefiles/top.make ! make/linux/makefiles/launcher.make ! make/linux/makefiles/ppc.make ! make/linux/makefiles/product.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/sparcWorks.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/jvmg.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/top.make ! make/windows/build.bat ! make/windows/build_vm_def.sh ! make/windows/get_msc_ver.sh ! make/windows/makefiles/adlc.make ! make/windows/makefiles/launcher.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sanity.make ! make/windows/makefiles/shared.make ! make/windows/makefiles/vm.make ! make/windows/projectfiles/common/Makefile ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp ! src/cpu/sparc/vm/c1_LinearScan_sparc.hpp ! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/templateTable_x86_32.hpp ! src/cpu/x86/vm/templateTable_x86_64.hpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/zero/vm/interpreterGenerator_zero.hpp ! src/cpu/zero/vm/methodHandles_zero.hpp ! src/os/bsd/vm/decoder_machO.cpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/decoder_linux.cpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/posix/launcher/java_md.c ! src/os/posix/launcher/launcher.script ! src/os/posix/vm/os_posix.cpp ! src/os/posix/vm/os_posix.hpp ! src/os/solaris/dtrace/hs_private.d ! src/os/solaris/vm/attachListener_solaris.cpp ! src/os/solaris/vm/decoder_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp ! src/os/windows/vm/os_windows.hpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.inline.hpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp ! src/os_cpu/linux_x86/vm/os_linux_x86.inline.hpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/solaris_x86/vm/solaris_x86_64.il ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.hpp ! src/os_cpu/windows_x86/vm/os_windows_x86.inline.hpp ! src/share/tools/ProjectCreator/ProjectCreator.java ! src/share/tools/ProjectCreator/Util.java ! src/share/tools/ProjectCreator/WinGammaPlatform.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/register.hpp ! src/share/vm/c1/c1_CFGPrinter.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueMap.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/c1/c1_ValueStack.cpp ! src/share/vm/c1/c1_ValueStack.hpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciTypeFlow.hpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/javaAssertions.hpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/code/vmreg.hpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/g1/survRateGroup.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.hpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psGenerationCounters.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.hpp ! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/gc_implementation/shared/collectorCounters.cpp ! src/share/vm/gc_implementation/shared/collectorCounters.hpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/gcPolicyCounters.hpp ! src/share/vm/gc_implementation/shared/gcStats.hpp ! src/share/vm/gc_implementation/shared/gcUtil.cpp ! src/share/vm/gc_implementation/shared/gcUtil.hpp ! src/share/vm/gc_implementation/shared/generationCounters.cpp ! src/share/vm/gc_implementation/shared/generationCounters.hpp ! src/share/vm/gc_implementation/shared/hSpaceCounters.cpp ! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp ! src/share/vm/gc_implementation/shared/spaceCounters.cpp ! src/share/vm/gc_implementation/shared/spaceCounters.hpp ! src/share/vm/gc_implementation/shared/spaceDecorator.hpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/libadt/set.cpp ! src/share/vm/libadt/vectset.cpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/freeList.hpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/space.inline.hpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/oops/objArrayOop.hpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/divnode.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/generateOptoStub.cpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/split_if.cpp ! src/share/vm/opto/subnode.hpp ! src/share/vm/prims/jniExport.hpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/prims/jvmtiExtensions.cpp ! src/share/vm/prims/jvmtiRawMonitor.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/prims/jvmtiUtil.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/dtraceJSDT.hpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/monitorChunk.cpp ! src/share/vm/runtime/monitorChunk.hpp ! src/share/vm/runtime/mutex.hpp ! src/share/vm/runtime/park.cpp ! src/share/vm/runtime/perfMemory.cpp ! src/share/vm/runtime/stubCodeGenerator.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/task.hpp ! src/share/vm/runtime/timer.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/g1MemoryPool.cpp ! src/share/vm/services/g1MemoryPool.hpp ! src/share/vm/services/lowMemoryDetector.hpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/trace/tracing.hpp ! src/share/vm/utilities/array.cpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder_elf.cpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp ! src/share/vm/utilities/elfStringTable.cpp ! src/share/vm/utilities/elfStringTable.hpp ! src/share/vm/utilities/elfSymbolTable.cpp ! src/share/vm/utilities/elfSymbolTable.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/growableArray.cpp ! src/share/vm/utilities/histogram.cpp ! src/share/vm/utilities/histogram.hpp ! src/share/vm/utilities/intHisto.cpp ! src/share/vm/utilities/intHisto.hpp ! src/share/vm/utilities/preserveException.cpp ! src/share/vm/utilities/stack.hpp ! src/share/vm/utilities/stack.inline.hpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/vmError.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! test/compiler/6859338/Test6859338.java ! test/compiler/7116216/StackOverflow.java Changeset: d804e148cff8 Author: kvn Date: 2012-10-12 09:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d804e148cff8 Merge ! make/bsd/makefiles/dtrace.make ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: fb19af007ffc Author: jprovino Date: 2012-10-10 14:35 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fb19af007ffc 7189254: Change makefiles for more flexibility to override defaults Summary: Change makefiles so that targets and parameters can be overridden by alternate makefiles. Reviewed-by: dholmes, coleenp ! make/Makefile ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/ia64.make + make/bsd/makefiles/minimal1.make ! make/bsd/makefiles/vm.make ! make/defs.make + make/excludeSrc.make ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/ia64.make + make/linux/makefiles/minimal1.make ! make/linux/makefiles/vm.make ! make/windows/makefiles/defs.make ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/metaspaceShared.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/forte.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/prims/jvmtiThreadState.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/classLoadingService.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/heapDumper.hpp ! src/share/vm/services/management.cpp ! src/share/vm/services/management.hpp ! src/share/vm/services/memReporter.hpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/services/runtimeService.cpp ! src/share/vm/services/runtimeService.hpp ! src/share/vm/utilities/macros.hpp Changeset: bbeecede56dd Author: jiangli Date: 2012-10-11 14:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bbeecede56dd 8000459: assert(java_lang_String::is_instance(entry)) failure with various mlvm tests. Summary: Remove unneeded assert. Reviewed-by: sspitsyn, coleenp ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 9855b7e559ae Author: collins Date: 2012-10-12 10:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9855b7e559ae Merge ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/vm.make ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/management.cpp Changeset: 5876f980ea19 Author: collins Date: 2012-10-12 11:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5876f980ea19 Merge ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: b261523fe66c Author: amurillo Date: 2012-10-12 13:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b261523fe66c Merge Changeset: 4547dc71db76 Author: amurillo Date: 2012-10-12 13:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4547dc71db76 Added tag hs25-b05 for changeset b261523fe66c ! .hgtags Changeset: 58fbf2da3c16 Author: amurillo Date: 2012-10-12 14:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/58fbf2da3c16 8000834: new hotspot build - hs25-b06 Reviewed-by: jcoomes ! make/hotspot_version From vladimir.x.ivanov at oracle.com Mon Oct 15 09:08:00 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 15 Oct 2012 20:08:00 +0400 Subject: -XX:CompileOnly command: how should it look like? In-Reply-To: <69EA2978-92BF-42D1-98A8-E615162534AB@oracle.com> References: <50789446.6080903@oracle.com> <5078A0F8.6020802@oracle.com> <69EA2978-92BF-42D1-98A8-E615162534AB@oracle.com> Message-ID: <507C34E0.4020305@oracle.com> Regarding CompileOnly flag, ',' does separate multiple compileonly directives (see compilerOracle.cpp:729-750). From usability perspective, when combined with wildcards it provies very concise and convenient syntax to control compilation for testing/development purposes. The only thing I'm missing is filtering by method signatures. I see 2 options to proceed now: a) just fix the bug I wrote about in the original letter (unless ',' works as a directive separator by accident :-)) b) in addition, extend CompileOnly format to allow same filtering granularity as in command file (CompilerOracle::parse_from_line). I'm in favor of (b), but would like to hear your opinion. Best regards, Vladimir Ivanov On 10/13/12 03:45, John Rose wrote: > On Oct 12, 2012, at 4:00 PM, Vladimir Kozlov wrote: > >> From what I remember originally we only accepted format ("," on command line to separate method and " " in .hotspot_compiler file): >> >> /c1/c2/c3,m >> >> Then Tom added next format to match PrintCompilation output: >> >> c1.c2.c3::m > > The original command form was three blank-separated fields, command classname methodname. > > We added ',' as an alias for ' ' (everywhere) to make it easy to pass CC options through various shells. The parser turns ',' to ' ', then separates into fields. > > We also added support for '::' as Vladimir said, to allow cut-and-paste of PrintC output names. Once again, the '::' turns into a field separator. > > The ',' does not mean "here is another part of a command", so CompileOnly=String.length,List.size is nonsense. > > Multiple commands are separated by newlines '\n'. This is most obvious in the .hotspot_compiler file, but is also true on the command line, because multiple accumulating string options are also glued together with newline '\n'. Thus, -XX:CompileCommand=foo -XX:CompileCommand=bar is the same as -XX:CompileCommand="foo${n}bar" where ${n} is a newline character. > > Here's the embedded comment from CompilerOracle::parse_from_line: > // Allow '.' to separate the class name from the method name. > // This is the preferred spelling of methods: > // exclude java/lang/String.indexOf(I)I > // Allow ',' for spaces (eases command line quoting). > // exclude,java/lang/String.indexOf > // For backward compatibility, allow space as separator also. > // exclude java/lang/String indexOf > // exclude,java/lang/String,indexOf > // For easy cut-and-paste of method names, allow VM output format > // as produced by Method::print_short_name: > // exclude java.lang.String::indexOf > > (I admit it's kludgey stuff.) > > ? John From adamh at basis.com Tue Oct 16 14:31:36 2012 From: adamh at basis.com (Adam Hawthorne) Date: Tue, 16 Oct 2012 17:31:36 -0400 Subject: Bug 7181756 Message-ID: Hi all, Apologies for a -use question on a -dev list, but I couldn't find the -use list ... A colleague of mine just ran into this bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181756 "Non-zero initial values in a byte array - regression in Java 7" This seems like a pretty serious issue; a subsequent search found four instances in our own source code that could potentially trigger the issue. Has it seen any attention? We did some testing and it appears it was introduced with hs23 in 7u4. A simple test (based on the sample in the bug) will reproduce: import java.util.*; class TestBug2 { public static void main(String[] argv) { TestBug2 bug = new TestBug2(); for (int i = 0; i < 10000000; ++i) { bug.testBug(i); } } private void testBug(int iter) { byte[] buf8 = new byte[8]; for (byte b : buf8) { if (b != 0) throw new Error(iter + ": " + b); } Arrays.fill(buf8, (byte) 0); } } // Output: // Exception in thread "main" java.lang.Error: 1346815: 50 // at TestBug2.testBug(TestBug2.java:15) // at TestBug2.main(TestBug2.java:7) // The above output is on Linux x64 java -version: java version "1.7.0_07" Java(TM) SE Runtime Environment (build 1.7.0_07-b10) Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode) Yes, I know this isn't a list to receive support, etc., I'm just surprised at its current priority of low. Thanks for your attention, Adam -- Adam Hawthorne Software Architect BASIS International Ltd. www.basis.com +1.505.938.6169 Phone +1.505.750.4128 Direct -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121016/823104b5/attachment.html From krystal.mo at oracle.com Tue Oct 16 14:39:09 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Wed, 17 Oct 2012 05:39:09 +0800 Subject: Bug 7181756 In-Reply-To: References: Message-ID: <507DD3FD.7020803@oracle.com> Hi Adam, I'm working on it and will send the fix out for review this week. Sorry for not reacting promptly enough for this issue. The latest CPU releases of JDK should have temporarily disabled the faulting optimizations already. Regards, Kris On 2012/10/17 5:31, Adam Hawthorne wrote: > Hi all, > > Apologies for a -use question on a -dev list, but I couldn't find the > -use list ... > > A colleague of mine just ran into this bug: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181756 > "Non-zero initial values in a byte array - regression in Java 7" > > This seems like a pretty serious issue; a subsequent search found four > instances in our own source code that could potentially trigger the > issue. Has it seen any attention? We did some testing and it appears > it was introduced with hs23 in 7u4. > > A simple test (based on the sample in the bug) will reproduce: > > > import java.util.*; > > class TestBug2 { > public static void main(String[] argv) { > TestBug2 bug = new TestBug2(); > for (int i = 0; i < 10000000; ++i) { > bug.testBug(i); > } > } > > private void testBug(int iter) { > byte[] buf8 = new byte[8]; > for (byte b : buf8) { > if (b != 0) > throw new Error(iter + ": " + b); > } > Arrays.fill(buf8, (byte) 0); > } > } > > // Output: > // Exception in thread "main" java.lang.Error: 1346815: 50 > // at TestBug2.testBug(TestBug2.java:15) > // at TestBug2.main(TestBug2.java:7) > // > > The above output is on Linux x64 > > java -version: > > java version "1.7.0_07" > Java(TM) SE Runtime Environment (build 1.7.0_07-b10) > Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode) > > > Yes, I know this isn't a list to receive support, etc., I'm just > surprised at its current priority of low. > > Thanks for your attention, > > Adam > > -- > Adam Hawthorne > Software Architect > BASIS International Ltd. > www.basis.com > +1.505.938.6169 Phone > +1.505.750.4128 Direct > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121017/15cd500b/attachment.html From adamh at basis.com Tue Oct 16 14:54:50 2012 From: adamh at basis.com (Adam Hawthorne) Date: Tue, 16 Oct 2012 17:54:50 -0400 Subject: Bug 7181756 In-Reply-To: <507DD3FD.7020803@oracle.com> References: <507DD3FD.7020803@oracle.com> Message-ID: Hi Kris, Thanks for the update - I hadn't noticed 7u9 was released until your response. Regards, Adam On Tue, Oct 16, 2012 at 5:39 PM, Krystal Mo wrote: > Hi Adam, > > I'm working on it and will send the fix out for review this week. Sorry > for not reacting promptly enough for this issue. > > The latest CPU releases of JDK should have temporarily disabled the > faulting optimizations already. > > Regards, > Kris > > > On 2012/10/17 5:31, Adam Hawthorne wrote: > > Hi all, > > Apologies for a -use question on a -dev list, but I couldn't find the > -use list ... > > A colleague of mine just ran into this bug: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181756 > "Non-zero initial values in a byte array - regression in Java 7" > > This seems like a pretty serious issue; a subsequent search found four > instances in our own source code that could potentially trigger the issue. > Has it seen any attention? We did some testing and it appears it was > introduced with hs23 in 7u4. > > A simple test (based on the sample in the bug) will reproduce: > > > import java.util.*; > > class TestBug2 { > public static void main(String[] argv) { > TestBug2 bug = new TestBug2(); > for (int i = 0; i < 10000000; ++i) { > bug.testBug(i); > } > } > > private void testBug(int iter) { > byte[] buf8 = new byte[8]; > for (byte b : buf8) { > if (b != 0) > throw new Error(iter + ": " + b); > } > Arrays.fill(buf8, (byte) 0); > } > } > > // Output: > // Exception in thread "main" java.lang.Error: 1346815: 50 > // at TestBug2.testBug(TestBug2.java:15) > // at TestBug2.main(TestBug2.java:7) > // > > The above output is on Linux x64 > > java -version: > > java version "1.7.0_07" > Java(TM) SE Runtime Environment (build 1.7.0_07-b10) > Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode) > > > Yes, I know this isn't a list to receive support, etc., I'm just > surprised at its current priority of low. > > Thanks for your attention, > > Adam > > -- > Adam Hawthorne > Software Architect > BASIS International Ltd. > www.basis.com > +1.505.938.6169 Phone > +1.505.750.4128 Direct > > -- Adam Hawthorne Software Architect BASIS International Ltd. www.basis.com +1.505.938.6169 Phone +1.505.750.4128 Direct -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121016/e8c5f1c0/attachment.html From krystal.mo at oracle.com Tue Oct 16 15:03:30 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Wed, 17 Oct 2012 06:03:30 +0800 Subject: Bug 7181756 In-Reply-To: <507DD3FD.7020803@oracle.com> References: <507DD3FD.7020803@oracle.com> Message-ID: <507DD9B2.2090500@oracle.com> Just ran your test case on JDK7u9 (which is just released this week) and by default settings the bug wouldn't reproduce anymore. As mentioned in last mail, the full fix will be sent out for review later this week. - Kris On 2012/10/17 5:39, Krystal Mo wrote: > Hi Adam, > > I'm working on it and will send the fix out for review this week. > Sorry for not reacting promptly enough for this issue. > > The latest CPU releases of JDK should have temporarily disabled the > faulting optimizations already. > > Regards, > Kris > > On 2012/10/17 5:31, Adam Hawthorne wrote: >> Hi all, >> >> Apologies for a -use question on a -dev list, but I couldn't find the >> -use list ... >> >> A colleague of mine just ran into this bug: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7181756 >> "Non-zero initial values in a byte array - regression in Java 7" >> >> This seems like a pretty serious issue; a subsequent search found >> four instances in our own source code that could potentially trigger >> the issue. Has it seen any attention? We did some testing and it >> appears it was introduced with hs23 in 7u4. >> >> A simple test (based on the sample in the bug) will reproduce: >> >> >> import java.util.*; >> >> class TestBug2 { >> public static void main(String[] argv) { >> TestBug2 bug = new TestBug2(); >> for (int i = 0; i < 10000000; ++i) { >> bug.testBug(i); >> } >> } >> >> private void testBug(int iter) { >> byte[] buf8 = new byte[8]; >> for (byte b : buf8) { >> if (b != 0) >> throw new Error(iter + ": " + b); >> } >> Arrays.fill(buf8, (byte) 0); >> } >> } >> >> // Output: >> // Exception in thread "main" java.lang.Error: 1346815: 50 >> // at TestBug2.testBug(TestBug2.java:15) >> // at TestBug2.main(TestBug2.java:7) >> // >> >> The above output is on Linux x64 >> >> java -version: >> >> java version "1.7.0_07" >> Java(TM) SE Runtime Environment (build 1.7.0_07-b10) >> Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode) >> >> >> Yes, I know this isn't a list to receive support, etc., I'm just >> surprised at its current priority of low. >> >> Thanks for your attention, >> >> Adam >> >> -- >> Adam Hawthorne >> Software Architect >> BASIS International Ltd. >> www.basis.com >> +1.505.938.6169 Phone >> +1.505.750.4128 Direct >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121017/18abc4b4/attachment-0001.html From nils.eliasson at oracle.com Wed Oct 17 06:23:54 2012 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 17 Oct 2012 15:23:54 +0200 Subject: Questions on exception control flow Message-ID: <507EB16A.4080606@oracle.com> In c2 when we have exceptions that is always or often taken, the exception code is spliced into the normal control flow. Where should I look to find that? //Nils From andreas.eriksson at oracle.com Wed Oct 17 07:08:32 2012 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Wed, 17 Oct 2012 16:08:32 +0200 Subject: Review request (S): 7176220: 'Full GC' events miss date stamp information occasionally In-Reply-To: <5072A984.2050606@oracle.com> References: <5072A984.2050606@oracle.com> Message-ID: <507EBBE0.2010004@oracle.com> Hi, Just wanted to make sure some eyes from the compiler team was on this. This review changes how date-stamps are printed in relation to TraceTime and PrintGCDateStamp, which is mostly used in GC logging. The problem is that it is also used for example in C1 with PhaseTraceTime. This means that for C1 the output will include date stamps when used with -XX:+PrintGCDateStamps and -XX:+Verbose together with -XX:+CITimeEach or -XX:+CITime This will make it consistent with -XX:+PrintGCTimeStamps, which already affect the output of C1. The webrev is available at http://cr.openjdk.java.net/~brutisso/7176220/webrev.00/ Regards, Andreas -------- Original Message -------- Subject: Re: Fwd: Re: Review request (S): 7176220: 'Full GC' events miss date stamp information occasionally Date: Mon, 08 Oct 2012 12:23:00 +0200 From: Andreas Eriksson To: John Cuthbertson CC: hotspot-dev at openjdk.java.net Hi John, If that TraceTime is changed to use PrintGC, then the logging becomes interleaved: 2012-10-08T12:16:42.121+0200: 0.171: [GC2012-10-08T12:16:42.121+0200: 0.171: [GC 2667K->1043K(9920K), 0.0040520 secs] , 0.0043620 secs]2012-10-08T12:16:42.127+0200: 0.177: [GC2012-10-08T12:16:42.128+0200: 0.177: [GC 3488K->1835K(9920K), 0.0234120 secs] That is probably the reason why it uses PrintGCDetails instead. Thanks, Andreas On 10/04/2012 07:28 PM, John Cuthbertson wrote: > Hi Andreas, > > This looks good to me except I have one question/comment: > > In genCollectedHeap.cpp, the old code was: > > 386 bool complete = full && (max_level == (n_gens()-1)); > 387 const char* gc_cause_prefix = complete ? "Full GC" : "GC"; > 388 gclog_or_tty->date_stamp(PrintGC && PrintGCDateStamps); > 389 TraceCPUTime tcpu(PrintGCDetails, true, gclog_or_tty); > 390 TraceTime t(GCCauseString(gc_cause_prefix, gc_cause()), > PrintGCDetails, false, gclog_or_tty); > > The new code is: > > 386 bool complete = full && (max_level == (n_gens()-1)); > 387 const char* gc_cause_prefix = complete ? "Full GC" : "GC"; > 388 TraceCPUTime tcpu(PrintGCDetails, true, gclog_or_tty); > 389 TraceTime t(GCCauseString(gc_cause_prefix, gc_cause()), > PrintGCDetails, false, gclog_or_tty); > > > In the old code, the date stamp was printed if PrintGC was enabled, > but the TraceTime::_doit field is set based upon the value of > PrintGCDetails. Looking at the other instantiations of the TraceTime > class, this seems inconsistent. I believe that the second parameter to > the TraceTime constructor should be PrintGC instead of PrintGCDetails. > > Regards, > > JohnC > > On 10/04/12 04:30, Andreas Eriksson wrote: >> Hi, >> >> Can I have some reviews for the following change please: >> http://cr.openjdk.java.net/~brutisso/7176220/webrev.00/ >> >> >> See forwarded mails for more info. >> >> Regards, >> Andreas >> >> >> -------- Original Message -------- >> Subject: Re: Review request (S): 7176220: 'Full GC' events miss >> date stamp information occasionally >> Date: Tue, 02 Oct 2012 14:45:07 +0200 >> From: Bengt Rutisson >> To: Andreas Eriksson >> CC: hotspot-gc-dev at openjdk.java.net >> >> >> >> >> >> Hi Andreas, >> >> I think this looks good. I like that we treat PrintGCDateStamps and >> PrintGCTimeStamps in a consistent way. >> >> One thing that kind of worries me is that the TraceTime class is used >> from other parts of the JVM than just the GC. This means that you now >> get date stamps on compiler events if you enable PrintGCDateStamps. I >> think this is probably fine since they already get time stamps if you >> enable PrintGCTimeStamps. See for example how PhaseTraceTime is used >> in C1. >> >> Maybe we should send this review out on hotspot-dev to make sure that >> all teams have a chance to comment on this? >> >> Thanks, >> Bengt >> >> On 2012-09-28 12:01, Andreas Eriksson wrote: >>> Hi, >>> >>> Can I have some reviews for the following change please: >>> http://cr.openjdk.java.net/~brutisso/7176220/webrev.00/ >>> >>> >>> This fixes GC logs from genCollectedHeap.cpp where sometimes it >>> would not print date-stamps. >>> The fix moves printing of date-stamps into TraceTime, where >>> time-stamps are already printed from. >>> >>> Bug with flags -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -verbose:gc >>> -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps: >>> 2012-09-28T11:41:38.687+0200: 0.205: [Full GC 8702K->1012K(9920K), >>> 0.0108630 secs] >>> 1.253: [Full GC 3326K->1012K(9920K), 0.0105750 secs] >>> 2.299: [Full GC 7932K->1012K(9920K), 0.0100470 secs] >>> 2012-09-28T11:41:41.813+0200: 3.331: [Full GC 8702K->1012K(9920K), >>> 0.0103210 secs] >>> >>> Another route that was investigated was to add the date-stamp call >>> directly in genCollectedHeap.cpp, but because of complex >>> interactions when a full GC was initiated from a non-full GC this >>> path was not taken. >>> >>> >>> This will slightly change the logging output when using >>> -XX:+PrintGCDetails. >>> Now date-stamps will also be printed inside other lines, as >>> time-stamps already are: >>> >>> Before: >>> 2012-09-28T11:29:16.815+0200: 0.177: [GC0.177: [ParNew: >>> 2710K->46K(3072K), 0.0053590 secs] 3480K->1835K(9920K), 0.0055500 >>> secs] [Times: user=0.01 sys=0.00, real=0.01 secs] >>> >>> After: >>> 2012-09-28T11:29:33.260+0200: 0.184: >>> [GC2012-09-28T11:29:33.261+0200: 0.184: [ParNew: 2642K->45K(3072K), >>> 0.0095770 secs] 3412K->1828K(9920K), 0.0097520 secs] [Times: >>> user=0.01 sys=0.00, real=0.01 secs] >>> >>> Thanks to Bengt Rutisson for helping with the change and webrev. >>> >>> Regards, >>> Andreas >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121017/ea812758/attachment.html From vladimir.kozlov at oracle.com Wed Oct 17 09:46:23 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Oct 2012 09:46:23 -0700 Subject: Questions on exception control flow In-Reply-To: <507EB16A.4080606@oracle.com> References: <507EB16A.4080606@oracle.com> Message-ID: <507EE0DF.7090506@oracle.com> Are you asking about this GraphKit::builtin_throw()? Vladimir Nils Eliasson wrote: > In c2 when we have exceptions that is always or often taken, the > exception code is spliced into the normal control flow. Where should I > look to find that? > > //Nils From vladimir.kozlov at oracle.com Wed Oct 17 10:02:01 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Oct 2012 10:02:01 -0700 Subject: Request for reviews (S): 8000623: tools/javac/Diagnostics/6769027/T6769027.java crashes in PSPromotionManager::copy_to_survivor_space Message-ID: <507EE489.2050701@oracle.com> http://cr.openjdk.java.net/~kvn/8000623/webrev We missed one place which loads java method's pointer (old MethodOop) from vtable when switched to NPG. The load is marked as oop load and as result method's pointer (which is in Metaspace now) ends up in oopmap. I did not find any more similar places. But I found incorrect switch code which I fixed. Note, diffs does not show indent change in compile.hpp: http://cr.openjdk.java.net/~kvn/8000623/webrev/src/share/vm/opto/compile.hpp.patch Thanks, Vladimir From nils.eliasson at oracle.com Wed Oct 17 10:24:05 2012 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 17 Oct 2012 19:24:05 +0200 Subject: Questions on exception control flow In-Reply-To: <507EE0DF.7090506@oracle.com> References: <507EB16A.4080606@oracle.com> <507EE0DF.7090506@oracle.com> Message-ID: <507EE9B5.4030107@oracle.com> Yes, thank you! //N Vladimir Kozlov skrev 2012-10-17 18:46: > Are you asking about this GraphKit::builtin_throw()? > > Vladimir > > Nils Eliasson wrote: >> In c2 when we have exceptions that is always or often taken, the >> exception code is spliced into the normal control flow. Where should >> I look to find that? >> >> //Nils From christian.thalinger at oracle.com Wed Oct 17 10:55:35 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 17 Oct 2012 10:55:35 -0700 Subject: Request for reviews (S): 8000623: tools/javac/Diagnostics/6769027/T6769027.java crashes in PSPromotionManager::copy_to_survivor_space In-Reply-To: <507EE489.2050701@oracle.com> References: <507EE489.2050701@oracle.com> Message-ID: Looks good. -- Chris On Oct 17, 2012, at 10:02 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8000623/webrev > > We missed one place which loads java method's pointer (old MethodOop) from vtable when switched to NPG. The load is marked as oop load and as result method's pointer (which is in Metaspace now) ends up in oopmap. > > I did not find any more similar places. But I found incorrect switch code which I fixed. > > Note, diffs does not show indent change in compile.hpp: > > http://cr.openjdk.java.net/~kvn/8000623/webrev/src/share/vm/opto/compile.hpp.patch > > Thanks, > Vladimir From roland.westrelin at oracle.com Wed Oct 17 11:08:49 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 17 Oct 2012 20:08:49 +0200 Subject: Request for reviews (S): 8000623: tools/javac/Diagnostics/6769027/T6769027.java crashes in PSPromotionManager::copy_to_survivor_space In-Reply-To: <507EE489.2050701@oracle.com> References: <507EE489.2050701@oracle.com> Message-ID: > http://cr.openjdk.java.net/~kvn/8000623/webrev > > We missed one place which loads java method's pointer (old MethodOop) from vtable when switched to NPG. The load is marked as oop load and as result method's pointer (which is in Metaspace now) ends up in oopmap. > > I did not find any more similar places. But I found incorrect switch code which I fixed. > > Note, diffs does not show indent change in compile.hpp: > > http://cr.openjdk.java.net/~kvn/8000623/webrev/src/share/vm/opto/compile.hpp.patch Why T_ADDRESS and not T_METADATA? Roland. From vladimir.kozlov at oracle.com Wed Oct 17 11:13:33 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Oct 2012 11:13:33 -0700 Subject: Request for reviews (S): 8000623: tools/javac/Diagnostics/6769027/T6769027.java crashes in PSPromotionManager::copy_to_survivor_space In-Reply-To: References: <507EE489.2050701@oracle.com> Message-ID: <507EF54D.4030602@oracle.com> Roland Westrelin wrote: >> http://cr.openjdk.java.net/~kvn/8000623/webrev >> >> We missed one place which loads java method's pointer (old MethodOop) from vtable when switched to NPG. The load is marked as oop load and as result method's pointer (which is in Metaspace now) ends up in oopmap. >> >> I did not find any more similar places. But I found incorrect switch code which I fixed. >> >> Note, diffs does not show indent change in compile.hpp: >> >> http://cr.openjdk.java.net/~kvn/8000623/webrev/src/share/vm/opto/compile.hpp.patch > > Why T_ADDRESS and not T_METADATA? LoadNode::make() does not accept T_METADATA and I don't want to add it for just this case. LoadNode::make() will generate the load node we need with passed T_ADDRESS. Vladimir > > Roland. From roland.westrelin at oracle.com Wed Oct 17 12:06:22 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 17 Oct 2012 21:06:22 +0200 Subject: Request for reviews (S): 8000623: tools/javac/Diagnostics/6769027/T6769027.java crashes in PSPromotionManager::copy_to_survivor_space In-Reply-To: <507EF54D.4030602@oracle.com> References: <507EE489.2050701@oracle.com> <507EF54D.4030602@oracle.com> Message-ID: <86FD31FB-A05D-433B-9654-DF43A24EED3F@oracle.com> >> Why T_ADDRESS and not T_METADATA? > > LoadNode::make() does not accept T_METADATA and I don't want to add it for just this case. LoadNode::make() will generate the load node we need with passed T_ADDRESS. Ok. It looks good to me. Roland. From vladimir.kozlov at oracle.com Wed Oct 17 12:06:31 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Oct 2012 12:06:31 -0700 Subject: Request for reviews (S): 8000623: tools/javac/Diagnostics/6769027/T6769027.java crashes in PSPromotionManager::copy_to_survivor_space In-Reply-To: <86FD31FB-A05D-433B-9654-DF43A24EED3F@oracle.com> References: <507EE489.2050701@oracle.com> <507EF54D.4030602@oracle.com> <86FD31FB-A05D-433B-9654-DF43A24EED3F@oracle.com> Message-ID: <507F01B7.20308@oracle.com> Thank you, Roland Vladimir Roland Westrelin wrote: >>> Why T_ADDRESS and not T_METADATA? >> LoadNode::make() does not accept T_METADATA and I don't want to add it for just this case. LoadNode::make() will generate the load node we need with passed T_ADDRESS. > > Ok. It looks good to me. > > Roland. From christian.thalinger at oracle.com Wed Oct 17 12:17:22 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 17 Oct 2012 12:17:22 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: <503BE193.6090807@oracle.com> References: <503BE193.6090807@oracle.com> Message-ID: This change broke the usage of previously built versions of hsdis. I filed a bug for it: 8000489: older builds of hsdis don't work anymore after 6879063 Yumin, I assigned the bug to you. Could you please take care of it? -- Chris On Aug 27, 2012, at 2:07 PM, Yumin Qi wrote: > Hi, all > > Can I have you code review of > 6879063: SA should use hsdis for disassembly > > http://cr.openjdk.java.net/~minqi/6879063 > > The SA has Java based disassemblers for x86 and sparc but amd64. Instead of porting to amd64 we should switch over to using hsdis for it like the JVM does. This requires a new entry point into hsdis, decode_instructions_virtual, which separates the address of the code being disassembled from the buffer containing the code. The existing uses of decode_instructions have been updated to use the new interface and SA Disassembler has Java native methods that call into hsdis and call back up to Java to perform the disassembly. Also changed makefile for hsdis build for both(i386/amd64). > > All the old disassembler logic was deleted since it's incompatible with the new disassembly interface. Also deleted are dbx based SA interface and few other dead files. > > Tested by dumping full assembly from core files. > > Reviewed-by: > Contributed-by: Tom R (never) > > Thanks > Yumin Qi > From yumin.qi at oracle.com Wed Oct 17 12:21:16 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 17 Oct 2012 12:21:16 -0700 Subject: RFR: 6879063: SA should use hsdis for disassembly In-Reply-To: References: <503BE193.6090807@oracle.com> Message-ID: <507F052C.9010402@oracle.com> Sure. Thanks Yumin On 10/17/2012 12:17 PM, Christian Thalinger wrote: > This change broke the usage of previously built versions of hsdis. I filed a bug for it: > > 8000489: older builds of hsdis don't work anymore after 6879063 > > Yumin, I assigned the bug to you. Could you please take care of it? > > -- Chris > > On Aug 27, 2012, at 2:07 PM, Yumin Qi wrote: > >> Hi, all >> >> Can I have you code review of >> 6879063: SA should use hsdis for disassembly >> >> http://cr.openjdk.java.net/~minqi/6879063 >> >> The SA has Java based disassemblers for x86 and sparc but amd64. Instead of porting to amd64 we should switch over to using hsdis for it like the JVM does. This requires a new entry point into hsdis, decode_instructions_virtual, which separates the address of the code being disassembled from the buffer containing the code. The existing uses of decode_instructions have been updated to use the new interface and SA Disassembler has Java native methods that call into hsdis and call back up to Java to perform the disassembly. Also changed makefile for hsdis build for both(i386/amd64). >> >> All the old disassembler logic was deleted since it's incompatible with the new disassembly interface. Also deleted are dbx based SA interface and few other dead files. >> >> Tested by dumping full assembly from core files. >> >> Reviewed-by: >> Contributed-by: Tom R (never) >> >> Thanks >> Yumin Qi >> From vladimir.kozlov at oracle.com Wed Oct 17 14:34:58 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Oct 2012 14:34:58 -0700 Subject: Review request (S): 7176220: 'Full GC' events miss date stamp information occasionally In-Reply-To: <507EBBE0.2010004@oracle.com> References: <5072A984.2050606@oracle.com> <507EBBE0.2010004@oracle.com> Message-ID: <507F2482.8090900@oracle.com> I don't like that these GC changes affect log information in compilers (for which we have own parsing tools). You can create subclass GCTraceTime for what you are doing to avoid such affects. Thanks, Vladimir Andreas Eriksson wrote: > Hi, > > Just wanted to make sure some eyes from the compiler team was on this. > > This review changes how date-stamps are printed in relation to TraceTime > and PrintGCDateStamp, which is mostly used in GC logging. > The problem is that it is also used for example in C1 with PhaseTraceTime. > This means that for C1 the output will include date stamps when used with > -XX:+PrintGCDateStamps and -XX:+Verbose together with -XX:+CITimeEach or > -XX:+CITime > > This will make it consistent with -XX:+PrintGCTimeStamps, which already > affect the output of C1. > > The webrev is available at > http://cr.openjdk.java.net/~brutisso/7176220/webrev.00/ > > Regards, > Andreas > > > -------- Original Message -------- > Subject: Re: Fwd: Re: Review request (S): 7176220: 'Full GC' events > miss date stamp information occasionally > Date: Mon, 08 Oct 2012 12:23:00 +0200 > From: Andreas Eriksson > To: John Cuthbertson > CC: hotspot-dev at openjdk.java.net > > > > Hi John, > > If that TraceTime is changed to use PrintGC, then the logging becomes > interleaved: > > 2012-10-08T12:16:42.121+0200: 0.171: [GC2012-10-08T12:16:42.121+0200: > 0.171: [GC 2667K->1043K(9920K), 0.0040520 secs] > , 0.0043620 secs]2012-10-08T12:16:42.127+0200: 0.177: > [GC2012-10-08T12:16:42.128+0200: 0.177: [GC 3488K->1835K(9920K), > 0.0234120 secs] > > That is probably the reason why it uses PrintGCDetails instead. > > Thanks, > Andreas > > On 10/04/2012 07:28 PM, John Cuthbertson wrote: >> Hi Andreas, >> >> This looks good to me except I have one question/comment: >> >> In genCollectedHeap.cpp, the old code was: >> >> 386 bool complete = full && (max_level == (n_gens()-1)); >> 387 const char* gc_cause_prefix = complete ? "Full GC" : "GC"; >> 388 gclog_or_tty->date_stamp(PrintGC && PrintGCDateStamps); >> 389 TraceCPUTime tcpu(PrintGCDetails, true, gclog_or_tty); >> 390 TraceTime t(GCCauseString(gc_cause_prefix, gc_cause()), >> PrintGCDetails, false, gclog_or_tty); >> >> The new code is: >> >> 386 bool complete = full && (max_level == (n_gens()-1)); >> 387 const char* gc_cause_prefix = complete ? "Full GC" : "GC"; >> 388 TraceCPUTime tcpu(PrintGCDetails, true, gclog_or_tty); >> 389 TraceTime t(GCCauseString(gc_cause_prefix, gc_cause()), >> PrintGCDetails, false, gclog_or_tty); >> >> >> In the old code, the date stamp was printed if PrintGC was enabled, >> but the TraceTime::_doit field is set based upon the value of >> PrintGCDetails. Looking at the other instantiations of the TraceTime >> class, this seems inconsistent. I believe that the second parameter to >> the TraceTime constructor should be PrintGC instead of PrintGCDetails. >> >> Regards, >> >> JohnC >> >> On 10/04/12 04:30, Andreas Eriksson wrote: >>> Hi, >>> >>> Can I have some reviews for the following change please: >>> http://cr.openjdk.java.net/~brutisso/7176220/webrev.00/ >>> >>> >>> See forwarded mails for more info. >>> >>> Regards, >>> Andreas >>> >>> >>> -------- Original Message -------- >>> Subject: Re: Review request (S): 7176220: 'Full GC' events miss >>> date stamp information occasionally >>> Date: Tue, 02 Oct 2012 14:45:07 +0200 >>> From: Bengt Rutisson >>> To: Andreas Eriksson >>> CC: hotspot-gc-dev at openjdk.java.net >>> >>> >>> >>> >>> >>> Hi Andreas, >>> >>> I think this looks good. I like that we treat PrintGCDateStamps and >>> PrintGCTimeStamps in a consistent way. >>> >>> One thing that kind of worries me is that the TraceTime class is used >>> from other parts of the JVM than just the GC. This means that you now >>> get date stamps on compiler events if you enable PrintGCDateStamps. I >>> think this is probably fine since they already get time stamps if you >>> enable PrintGCTimeStamps. See for example how PhaseTraceTime is used >>> in C1. >>> >>> Maybe we should send this review out on hotspot-dev to make sure that >>> all teams have a chance to comment on this? >>> >>> Thanks, >>> Bengt >>> >>> On 2012-09-28 12:01, Andreas Eriksson wrote: >>>> Hi, >>>> >>>> Can I have some reviews for the following change please: >>>> http://cr.openjdk.java.net/~brutisso/7176220/webrev.00/ >>>> >>>> >>>> This fixes GC logs from genCollectedHeap.cpp where sometimes it >>>> would not print date-stamps. >>>> The fix moves printing of date-stamps into TraceTime, where >>>> time-stamps are already printed from. >>>> >>>> Bug with flags -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -verbose:gc >>>> -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps: >>>> 2012-09-28T11:41:38.687+0200: 0.205: [Full GC 8702K->1012K(9920K), >>>> 0.0108630 secs] >>>> 1.253: [Full GC 3326K->1012K(9920K), 0.0105750 secs] >>>> 2.299: [Full GC 7932K->1012K(9920K), 0.0100470 secs] >>>> 2012-09-28T11:41:41.813+0200: 3.331: [Full GC 8702K->1012K(9920K), >>>> 0.0103210 secs] >>>> >>>> Another route that was investigated was to add the date-stamp call >>>> directly in genCollectedHeap.cpp, but because of complex >>>> interactions when a full GC was initiated from a non-full GC this >>>> path was not taken. >>>> >>>> >>>> This will slightly change the logging output when using >>>> -XX:+PrintGCDetails. >>>> Now date-stamps will also be printed inside other lines, as >>>> time-stamps already are: >>>> >>>> Before: >>>> 2012-09-28T11:29:16.815+0200: 0.177: [GC0.177: [ParNew: >>>> 2710K->46K(3072K), 0.0053590 secs] 3480K->1835K(9920K), 0.0055500 >>>> secs] [Times: user=0.01 sys=0.00, real=0.01 secs] >>>> >>>> After: >>>> 2012-09-28T11:29:33.260+0200: 0.184: >>>> [GC2012-09-28T11:29:33.261+0200: 0.184: [ParNew: 2642K->45K(3072K), >>>> 0.0095770 secs] 3412K->1828K(9920K), 0.0097520 secs] [Times: >>>> user=0.01 sys=0.00, real=0.01 secs] >>>> >>>> Thanks to Bengt Rutisson for helping with the change and webrev. >>>> >>>> Regards, >>>> Andreas >>> >>> >>> >>> >> > > > > From christian.thalinger at oracle.com Wed Oct 17 14:44:49 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 17 Oct 2012 14:44:49 -0700 Subject: RFR (S): 8000821: JSR 292: C1 fails to call virtual method (JRUBY-6920) Message-ID: <08D29A6E-37B0-4D07-892B-B65955AFFCED@oracle.com> http://cr.openjdk.java.net/~twisti/8000821 8000821: JSR 292: C1 fails to call virtual method (JRUBY-6920) Reviewed-by: GraphBuilder::try_method_handle_inline calls GraphBuilder::try_inline to inline the target of method handle calls. But try_inline doesn't do CHA; GraphBuilder::invoke does that. The easy fix for now without refactoring the whole logic in C1 (which is not trivial, I tried) is to only inline static and statically bindable methods for method handle calls. This shouldn't affect performance since most methods are statically bindable and C2 doesn't have this problem. src/share/vm/c1/c1_GraphBuilder.cpp From vladimir.kozlov at oracle.com Wed Oct 17 14:48:22 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Oct 2012 14:48:22 -0700 Subject: RFR (S): 8000821: JSR 292: C1 fails to call virtual method (JRUBY-6920) In-Reply-To: <08D29A6E-37B0-4D07-892B-B65955AFFCED@oracle.com> References: <08D29A6E-37B0-4D07-892B-B65955AFFCED@oracle.com> Message-ID: <507F27A6.5020901@oracle.com> Good. Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8000821 > > 8000821: JSR 292: C1 fails to call virtual method (JRUBY-6920) > Reviewed-by: > > GraphBuilder::try_method_handle_inline calls GraphBuilder::try_inline > to inline the target of method handle calls. But try_inline doesn't > do CHA; GraphBuilder::invoke does that. > > The easy fix for now without refactoring the whole logic in C1 (which > is not trivial, I tried) is to only inline static and statically > bindable methods for method handle calls. This shouldn't affect > performance since most methods are statically bindable and C2 doesn't > have this problem. > > src/share/vm/c1/c1_GraphBuilder.cpp > From vladimir.kozlov at oracle.com Wed Oct 17 14:49:53 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 17 Oct 2012 21:49:53 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8000623: tools/javac/Diagnostics/6769027/T6769027.java crashes in PSPromotionManager::copy_to_survivor_space Message-ID: <20121017214958.1196A473F7@hg.openjdk.java.net> Changeset: cfe522e6461c Author: kvn Date: 2012-10-17 12:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cfe522e6461c 8000623: tools/javac/Diagnostics/6769027/T6769027.java crashes in PSPromotionManager::copy_to_survivor_space Summary: Fix type of method pointer load from vtable. Reviewed-by: twisti, johnc, roland ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/library_call.cpp From christian.thalinger at oracle.com Wed Oct 17 14:55:55 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 17 Oct 2012 14:55:55 -0700 Subject: RFR (S): 8000821: JSR 292: C1 fails to call virtual method (JRUBY-6920) In-Reply-To: <507F27A6.5020901@oracle.com> References: <08D29A6E-37B0-4D07-892B-B65955AFFCED@oracle.com> <507F27A6.5020901@oracle.com> Message-ID: <1637BBE4-AC57-476B-9BB3-B6F34B492EA1@oracle.com> Thank you, Vladimir. -- Chris On Oct 17, 2012, at 2:48 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/8000821 >> 8000821: JSR 292: C1 fails to call virtual method (JRUBY-6920) >> Reviewed-by: >> GraphBuilder::try_method_handle_inline calls GraphBuilder::try_inline >> to inline the target of method handle calls. But try_inline doesn't >> do CHA; GraphBuilder::invoke does that. >> The easy fix for now without refactoring the whole logic in C1 (which >> is not trivial, I tried) is to only inline static and statically >> bindable methods for method handle calls. This shouldn't affect >> performance since most methods are statically bindable and C2 doesn't >> have this problem. >> src/share/vm/c1/c1_GraphBuilder.cpp From wjames8711 at gmail.com Thu Oct 18 01:48:04 2012 From: wjames8711 at gmail.com (james wang) Date: Thu, 18 Oct 2012 16:48:04 +0800 Subject: How-to implement intrinsic in JVM? Message-ID: Hi all, Is there any guideline about how to implement new intrinsic (line popcnt, reversebytes, etc.) in JVM? I found a patch about reversebytes( http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.01/), but didn't known the correct steps to accomplish it. Thanks! James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121018/8131706b/attachment.html From andreas.eriksson at oracle.com Thu Oct 18 08:29:55 2012 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Thu, 18 Oct 2012 17:29:55 +0200 Subject: Review request (S): 7176220: 'Full GC' events miss date stamp information occasionally In-Reply-To: <507F2482.8090900@oracle.com> References: <5072A984.2050606@oracle.com> <507EBBE0.2010004@oracle.com> <507F2482.8090900@oracle.com> Message-ID: <50802073.6050009@oracle.com> Hi Vladimir, Yes, that would probably be a better solution. I will take a look at moving PrintGCDateStamp and PrintGCTimeStamp to a GC-specific subclass. Thanks, Andreas On 2012-10-17 23:34, Vladimir Kozlov wrote: > I don't like that these GC changes affect log information in compilers > (for which we have own parsing tools). You can create subclass > GCTraceTime for what you are doing to avoid such affects. > > Thanks, > Vladimir > > Andreas Eriksson wrote: >> Hi, >> >> Just wanted to make sure some eyes from the compiler team was on this. >> >> This review changes how date-stamps are printed in relation to >> TraceTime and PrintGCDateStamp, which is mostly used in GC logging. >> The problem is that it is also used for example in C1 with >> PhaseTraceTime. >> This means that for C1 the output will include date stamps when used >> with >> -XX:+PrintGCDateStamps and -XX:+Verbose together with -XX:+CITimeEach >> or -XX:+CITime >> >> This will make it consistent with -XX:+PrintGCTimeStamps, which >> already affect the output of C1. >> >> The webrev is available at >> http://cr.openjdk.java.net/~brutisso/7176220/webrev.00/ >> >> Regards, >> Andreas >> >> >> -------- Original Message -------- >> Subject: Re: Fwd: Re: Review request (S): 7176220: 'Full GC' >> events miss date stamp information occasionally >> Date: Mon, 08 Oct 2012 12:23:00 +0200 >> From: Andreas Eriksson >> To: John Cuthbertson >> CC: hotspot-dev at openjdk.java.net >> >> >> >> Hi John, >> >> If that TraceTime is changed to use PrintGC, then the logging becomes >> interleaved: >> >> 2012-10-08T12:16:42.121+0200: 0.171: [GC2012-10-08T12:16:42.121+0200: >> 0.171: [GC 2667K->1043K(9920K), 0.0040520 secs] >> , 0.0043620 secs]2012-10-08T12:16:42.127+0200: 0.177: >> [GC2012-10-08T12:16:42.128+0200: 0.177: [GC 3488K->1835K(9920K), >> 0.0234120 secs] >> >> That is probably the reason why it uses PrintGCDetails instead. >> >> Thanks, >> Andreas >> >> On 10/04/2012 07:28 PM, John Cuthbertson wrote: >>> Hi Andreas, >>> >>> This looks good to me except I have one question/comment: >>> >>> In genCollectedHeap.cpp, the old code was: >>> >>> 386 bool complete = full && (max_level == (n_gens()-1)); >>> 387 const char* gc_cause_prefix = complete ? "Full GC" : "GC"; >>> 388 gclog_or_tty->date_stamp(PrintGC && PrintGCDateStamps); >>> 389 TraceCPUTime tcpu(PrintGCDetails, true, gclog_or_tty); >>> 390 TraceTime t(GCCauseString(gc_cause_prefix, gc_cause()), >>> PrintGCDetails, false, gclog_or_tty); >>> >>> The new code is: >>> >>> 386 bool complete = full && (max_level == (n_gens()-1)); >>> 387 const char* gc_cause_prefix = complete ? "Full GC" : "GC"; >>> 388 TraceCPUTime tcpu(PrintGCDetails, true, gclog_or_tty); >>> 389 TraceTime t(GCCauseString(gc_cause_prefix, gc_cause()), >>> PrintGCDetails, false, gclog_or_tty); >>> >>> >>> In the old code, the date stamp was printed if PrintGC was enabled, >>> but the TraceTime::_doit field is set based upon the value of >>> PrintGCDetails. Looking at the other instantiations of the TraceTime >>> class, this seems inconsistent. I believe that the second parameter >>> to the TraceTime constructor should be PrintGC instead of >>> PrintGCDetails. >>> >>> Regards, >>> >>> JohnC >>> >>> On 10/04/12 04:30, Andreas Eriksson wrote: >>>> Hi, >>>> >>>> Can I have some reviews for the following change please: >>>> http://cr.openjdk.java.net/~brutisso/7176220/webrev.00/ >>>> >>>> >>>> See forwarded mails for more info. >>>> >>>> Regards, >>>> Andreas >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: Re: Review request (S): 7176220: 'Full GC' events miss >>>> date stamp information occasionally >>>> Date: Tue, 02 Oct 2012 14:45:07 +0200 >>>> From: Bengt Rutisson >>>> To: Andreas Eriksson >>>> CC: hotspot-gc-dev at openjdk.java.net >>>> >>>> >>>> >>>> >>>> >>>> Hi Andreas, >>>> >>>> I think this looks good. I like that we treat PrintGCDateStamps and >>>> PrintGCTimeStamps in a consistent way. >>>> >>>> One thing that kind of worries me is that the TraceTime class is >>>> used from other parts of the JVM than just the GC. This means that >>>> you now get date stamps on compiler events if you enable >>>> PrintGCDateStamps. I think this is probably fine since they already >>>> get time stamps if you enable PrintGCTimeStamps. See for example >>>> how PhaseTraceTime is used in C1. >>>> >>>> Maybe we should send this review out on hotspot-dev to make sure >>>> that all teams have a chance to comment on this? >>>> >>>> Thanks, >>>> Bengt >>>> >>>> On 2012-09-28 12:01, Andreas Eriksson wrote: >>>>> Hi, >>>>> >>>>> Can I have some reviews for the following change please: >>>>> http://cr.openjdk.java.net/~brutisso/7176220/webrev.00/ >>>>> >>>>> >>>>> This fixes GC logs from genCollectedHeap.cpp where sometimes it >>>>> would not print date-stamps. >>>>> The fix moves printing of date-stamps into TraceTime, where >>>>> time-stamps are already printed from. >>>>> >>>>> Bug with flags -XX:+UseConcMarkSweepGC -XX:+UseParNewGC >>>>> -verbose:gc -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps: >>>>> 2012-09-28T11:41:38.687+0200: 0.205: [Full GC 8702K->1012K(9920K), >>>>> 0.0108630 secs] >>>>> 1.253: [Full GC 3326K->1012K(9920K), 0.0105750 secs] >>>>> 2.299: [Full GC 7932K->1012K(9920K), 0.0100470 secs] >>>>> 2012-09-28T11:41:41.813+0200: 3.331: [Full GC 8702K->1012K(9920K), >>>>> 0.0103210 secs] >>>>> >>>>> Another route that was investigated was to add the date-stamp call >>>>> directly in genCollectedHeap.cpp, but because of complex >>>>> interactions when a full GC was initiated from a non-full GC this >>>>> path was not taken. >>>>> >>>>> >>>>> This will slightly change the logging output when using >>>>> -XX:+PrintGCDetails. >>>>> Now date-stamps will also be printed inside other lines, as >>>>> time-stamps already are: >>>>> >>>>> Before: >>>>> 2012-09-28T11:29:16.815+0200: 0.177: [GC0.177: [ParNew: >>>>> 2710K->46K(3072K), 0.0053590 secs] 3480K->1835K(9920K), 0.0055500 >>>>> secs] [Times: user=0.01 sys=0.00, real=0.01 secs] >>>>> >>>>> After: >>>>> 2012-09-28T11:29:33.260+0200: 0.184: >>>>> [GC2012-09-28T11:29:33.261+0200: 0.184: [ParNew: >>>>> 2642K->45K(3072K), 0.0095770 secs] 3412K->1828K(9920K), 0.0097520 >>>>> secs] [Times: user=0.01 sys=0.00, real=0.01 secs] >>>>> >>>>> Thanks to Bengt Rutisson for helping with the change and webrev. >>>>> >>>>> Regards, >>>>> Andreas >>>> >>>> >>>> >>>> >>> >> >> >> >> From vladimir.kozlov at oracle.com Thu Oct 18 09:54:18 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 18 Oct 2012 16:54:18 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8001071: Add simple range check into VM implemenation of Unsafe access methods Message-ID: <20121018165424.362B547419@hg.openjdk.java.net> Changeset: e81a8af10cd9 Author: kvn Date: 2012-10-18 07:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e81a8af10cd9 8001071: Add simple range check into VM implemenation of Unsafe access methods Summary: Add simple check in debug version of VM. Reviewed-by: twisti, johnc ! src/share/vm/prims/unsafe.cpp From dean.long at oracle.com Thu Oct 18 20:14:25 2012 From: dean.long at oracle.com (Dean Long) Date: Thu, 18 Oct 2012 20:14:25 -0700 Subject: RFR (XS) 8001101: C2: more general vector rule subsetting Message-ID: <5080C591.6070608@oracle.com> http://cr.openjdk.java.net/~dlong/8001101/webrev.0 Allow which vector rules are supported to be decided at runtime. Also a small change to allow vector types in Type::_type_info[] to apply to more platforms. dl From vladimir.kozlov at oracle.com Thu Oct 18 20:37:26 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 18 Oct 2012 20:37:26 -0700 Subject: RFR (XS) 8001101: C2: more general vector rule subsetting In-Reply-To: <5080C591.6070608@oracle.com> References: <5080C591.6070608@oracle.com> Message-ID: <3EE88A80-8991-41F3-A8CE-04A4C8C667DA@oracle.com> Looks good. Thanks, Vladimir On Oct 18, 2012, at 8:14 PM, Dean Long wrote: > http://cr.openjdk.java.net/~dlong/8001101/webrev.0 > > Allow which vector rules are supported to be decided at runtime. Also a small change to allow > vector types in Type::_type_info[] to apply to more platforms. > > dl > From john.coomes at oracle.com Thu Oct 18 20:53:10 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 19 Oct 2012 03:53:10 +0000 Subject: hg: hsx/hotspot-comp: Added tag jdk8-b61 for changeset 20ff117b5090 Message-ID: <20121019035310.BBC0F47434@hg.openjdk.java.net> Changeset: 8343ccdd63f1 Author: katleman Date: 2012-10-18 11:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/8343ccdd63f1 Added tag jdk8-b61 for changeset 20ff117b5090 ! .hgtags From john.coomes at oracle.com Thu Oct 18 20:53:14 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 19 Oct 2012 03:53:14 +0000 Subject: hg: hsx/hotspot-comp/corba: 4 new changesets Message-ID: <20121019035318.DA57D47435@hg.openjdk.java.net> Changeset: 27d87f0031bf Author: alanb Date: 2012-10-05 15:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/27d87f0031bf 7195779: javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently, NPE in tie class Reviewed-by: alanb, coffeys Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/sun/rmi/rmic/iiop/StubGenerator.java Changeset: d9c1dab1515b Author: lana Date: 2012-10-08 15:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/d9c1dab1515b Merge Changeset: 0e08ba7648fb Author: lana Date: 2012-10-11 16:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/0e08ba7648fb Merge Changeset: 2394155f9f9e Author: katleman Date: 2012-10-18 11:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/2394155f9f9e Added tag jdk8-b61 for changeset 0e08ba7648fb ! .hgtags From john.coomes at oracle.com Thu Oct 18 20:53:22 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 19 Oct 2012 03:53:22 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b61 for changeset 6b1db0b41d2f Message-ID: <20121019035330.ECA6847436@hg.openjdk.java.net> Changeset: 5d0fa0108d02 Author: katleman Date: 2012-10-18 11:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/5d0fa0108d02 Added tag jdk8-b61 for changeset 6b1db0b41d2f ! .hgtags From john.coomes at oracle.com Thu Oct 18 20:53:35 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 19 Oct 2012 03:53:35 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b61 for changeset 97e5e74e2a34 Message-ID: <20121019035340.7A0F247437@hg.openjdk.java.net> Changeset: d265b9b4c0f5 Author: katleman Date: 2012-10-18 11:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/d265b9b4c0f5 Added tag jdk8-b61 for changeset 97e5e74e2a34 ! .hgtags From john.coomes at oracle.com Thu Oct 18 20:54:52 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 19 Oct 2012 03:54:52 +0000 Subject: hg: hsx/hotspot-comp/jdk: 51 new changesets Message-ID: <20121019040508.8C28A47438@hg.openjdk.java.net> Changeset: 4d8b411a2bc1 Author: jgodinez Date: 2012-09-25 09:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4d8b411a2bc1 7158350: [macosx] Strange results of SwingUIText printing Reviewed-by: bae, prr ! src/macosx/native/sun/awt/CTextPipe.m Changeset: 5aff878baaf6 Author: lana Date: 2012-09-28 11:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5aff878baaf6 Merge - make/common/Defs-embedded.gmk - make/common/Release-embedded.gmk - src/macosx/classes/sun/awt/SunToolkitSubclass.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: 8dd4cae72975 Author: ceisserer Date: 2012-10-01 13:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8dd4cae72975 7188093: closed/sun/java2d/pipe/ScaleQualityTest.java fails Reviewed-by: prr, flar ! src/solaris/classes/sun/java2d/xr/XRDrawImage.java Changeset: 89a1094e384f Author: bae Date: 2012-10-05 16:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/89a1094e384f 8000176: Need automated test for checking scale quality Reviewed-by: prr, bae Contributed-by: Vadim Pakhnushev + test/sun/java2d/pipe/InterpolationQualityTest.java Changeset: 2bc7669294cc Author: lana Date: 2012-10-08 15:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2bc7669294cc Merge Changeset: 9aa37a39cf39 Author: zhouyx Date: 2012-09-20 17:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9aa37a39cf39 7194184: JColorChooser swatch cannot accessed from keyboard Reviewed-by: rupashka, alexsch ! src/share/classes/javax/swing/colorchooser/DefaultSwatchChooserPanel.java + test/javax/swing/JColorChooser/Test7194184.java Changeset: 4f519691520c Author: vkarnauk Date: 2012-09-20 17:55 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4f519691520c 7123767: Wrong tooltip location in Multi-Monitor configurations Reviewed-by: rupashka ! src/share/classes/javax/swing/ToolTipManager.java + test/javax/swing/ToolTipManager/7123767/bug7123767.java Changeset: adddc599e551 Author: alexsch Date: 2012-09-21 13:48 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/adddc599e551 7199180: [macosx] Dead keys handling for input methods Reviewed-by: kizune, anthony ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/macosx/native/sun/awt/AWTEvent.m ! src/macosx/native/sun/awt/AWTView.m + test/java/awt/event/KeyEvent/DeadKey/DeadKeyMacOSXInputText.java Changeset: 88048b34405e Author: leonidr Date: 2012-09-24 15:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/88048b34405e 7124239: [macosx] sun.awt.SunToolkit.InfiniteLoop exception in realSync called from SwingTestHelper Reviewed-by: anthony ! src/macosx/native/sun/awt/LWCToolkit.m ! src/macosx/native/sun/osxapp/NSApplicationAWT.h ! src/macosx/native/sun/osxapp/NSApplicationAWT.m Changeset: d6cba7bfbb3d Author: leonidr Date: 2012-09-24 18:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d6cba7bfbb3d 7179349: [macosx] Java processes on Mac should not use default Apple icon Reviewed-by: anthony ! make/sun/osxapp/Makefile + make/sun/osxapp/ToBin.java ! src/macosx/native/sun/osxapp/NSApplicationAWT.m + src/macosx/native/sun/osxapp/resource/icons/JavaApp.icns Changeset: 39227bb92978 Author: serb Date: 2012-09-24 21:33 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/39227bb92978 7160627: [macosx] TextArea has wrong initial size 7124213: [macosx] pack() does ignore size of a component; doesn't on the other platforms Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/LWCanvasPeer.java ! src/macosx/classes/sun/lwawt/LWCheckboxPeer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWContainerPeer.java ! src/macosx/classes/sun/lwawt/LWLabelPeer.java ! src/macosx/classes/sun/lwawt/LWListPeer.java ! src/macosx/classes/sun/lwawt/LWPanelPeer.java ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java ! src/macosx/classes/sun/lwawt/LWToolkit.java + test/java/awt/ScrollPane/ScrollPanePreferredSize/ScrollPanePreferredSize.java + test/java/awt/TextArea/TextAreaTwicePack/TextAreaTwicePack.java Changeset: c8da47a4d441 Author: alexsch Date: 2012-09-26 18:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c8da47a4d441 7124515: [macosx] Test fail like 6366126 (ArrayIndexOutOfBoundException pressing ENTER after removing items) Reviewed-by: serb, anthony + test/java/awt/List/EmptyListEventTest/EmptyListEventTest.java Changeset: ad467dee852a Author: alexsch Date: 2012-09-28 14:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ad467dee852a 7197619: Using modifiers for the dead key detection on Windows Reviewed-by: bagiras, leonidr ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h Changeset: 4b8bb77fdda9 Author: lana Date: 2012-09-28 10:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4b8bb77fdda9 Merge - make/common/Defs-embedded.gmk - make/common/Release-embedded.gmk - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: 3ac112755bb5 Author: bagiras Date: 2012-10-03 21:01 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3ac112755bb5 7171412: awt Choice doesn't fire ItemStateChange when selecting item after select() call Reviewed-by: art, denis ! src/macosx/native/sun/awt/InitIDs.m ! src/share/classes/java/awt/Choice.java ! src/solaris/native/sun/awt/initIDs.c ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Choice.h + test/java/awt/Choice/ItemStateChangeTest/ItemStateChangeTest.java Changeset: 27ee94051373 Author: lana Date: 2012-10-08 15:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/27ee94051373 Merge Changeset: f5229879ea40 Author: chegar Date: 2012-09-20 09:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f5229879ea40 7193520: Removed references to Linux kernel version 2.2 Summary: Linux kernel version 2.2 isn't supported anymore. Reviewed-by: chegar, dsamersoff, alanb Contributed-by: John Zavgren ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! 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/PlainSocketImpl.c ! src/solaris/native/java/net/SocketInputStream.c ! src/solaris/native/java/net/bsd_close.c ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/java/net/net_util_md.h Changeset: 3ad5464e7a21 Author: ksrini Date: 2012-09-20 13:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3ad5464e7a21 7199614: (pack200) remove unused file Reviewed-by: alanb - src/share/test/pack200/pack.conf Changeset: 3cfb621d5e7e Author: alanb Date: 2012-09-21 15:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3cfb621d5e7e 7199551: (bf) CharBuffer.append(CharSequence) throws BufferOverflowException for read-only buffer Reviewed-by: iris, dxu, chegar ! src/share/classes/java/nio/X-Buffer.java.template ! test/java/nio/Buffer/Basic-X.java.template ! test/java/nio/Buffer/Basic.java ! test/java/nio/Buffer/BasicByte.java ! test/java/nio/Buffer/BasicChar.java ! test/java/nio/Buffer/BasicDouble.java ! test/java/nio/Buffer/BasicFloat.java ! test/java/nio/Buffer/BasicInt.java ! test/java/nio/Buffer/BasicLong.java ! test/java/nio/Buffer/BasicShort.java Changeset: f0aa997ad78b Author: valeriep Date: 2012-09-25 11:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f0aa997ad78b 7199941: test about AES/ECB mode fails Summary: Fixed the problem of field "blockMode" not having correct value for AES algorithms. Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11Cipher.java Changeset: 4fcbddfd97f0 Author: valeriep Date: 2012-09-25 11:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4fcbddfd97f0 7199939: DSA 576 and 640 bit keys fail when initializing for No precomputed parameters Summary: Fixed initialize(int, SecureRandom) call to not error out when no precomputed params available. Reviewed-by: vinnie ! src/share/classes/sun/security/provider/DSAKeyPairGenerator.java ! src/share/classes/sun/security/provider/DSAParameterGenerator.java ! src/share/classes/sun/security/provider/ParameterCache.java Changeset: a58585051c4b Author: xuelei Date: 2012-09-26 21:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a58585051c4b 7200295: CertificateRequest message is wrapping when using large numbers of Certs Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/HandshakeOutStream.java ! src/share/classes/sun/security/ssl/Record.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/CertRequestOverflow.java Changeset: 790b81b631ba Author: alanb Date: 2012-09-27 10:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/790b81b631ba 7200742: (se) Selector.select does not block when starting Coherence (sol) Reviewed-by: chegar ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java + test/java/nio/channels/Selector/ChangingInterests.java Changeset: 9e879c0288c2 Author: andrew Date: 2012-09-27 17:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9e879c0288c2 7201205: Add Makefile configuration option to build with unlimited crypto in OpenJDK. Summary: Allow OpenJDK to use the unlimited crypto policy. Reviewed-by: wetmore, ohair ! make/javax/crypto/Makefile Changeset: 11a5da68673c Author: robm Date: 2012-09-27 22:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/11a5da68673c 7199862: Make sure that a connection is still alive when retrieved from KeepAliveCache in certain cases Reviewed-by: chegar ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: b3c7a3138c5d Author: robm Date: 2012-09-28 04:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b3c7a3138c5d 7199219: Proxy-Connection headers set incorrectly when a HttpClient is retrieved from the Keep Alive Cache Reviewed-by: chegar ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: 7529cc41e637 Author: peytoia Date: 2012-09-28 14:14 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7529cc41e637 7069824: Support for BCP47 locale matching Reviewed-by: naoto, okutsu ! src/share/classes/java/util/Locale.java + src/share/classes/sun/util/locale/LocaleEquivalentMaps.java + src/share/classes/sun/util/locale/LocaleMatcher.java + test/java/util/Locale/Bug7069824.java + test/java/util/Locale/tools/EquivMapsGenerator.java + test/java/util/Locale/tools/language-subtag-registry.txt Changeset: 7e3ef09bb348 Author: weijun Date: 2012-09-28 17:15 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7e3ef09bb348 7200682: TEST_BUG: keytool/autotest.sh still has problems with libsoftokn.so Reviewed-by: alanb, smarks ! test/sun/security/tools/keytool/autotest.sh Changeset: b8e08f5d255a Author: dxu Date: 2012-09-28 11:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b8e08f5d255a 6950237: Test java/nio/file/Path/CopyAndMove.java does not work correctly when test dir in on VFAT Reviewed-by: alanb ! src/solaris/classes/sun/nio/fs/LinuxFileStore.java ! test/java/nio/file/Files/CopyAndMove.java Changeset: 77bf5cde2192 Author: lana Date: 2012-09-28 14:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/77bf5cde2192 Merge - make/common/Defs-embedded.gmk - make/common/Release-embedded.gmk - src/macosx/classes/sun/awt/SunToolkitSubclass.java Changeset: 0c1c4b185451 Author: dsamersoff Date: 2012-09-29 15:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0c1c4b185451 7186723: TEST_BUG: Race condition in sun/management/jmxremote/startstop/JMXStartStopTest.sh Summary: Make test self-terminating and independent to cygwin/mks kill behaviour Reviewed-by: sspitsyn, alanb ! test/ProblemList.txt ! test/sun/management/jmxremote/startstop/JMXStartStopDoSomething.java ! test/sun/management/jmxremote/startstop/JMXStartStopTest.java ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh ! test/sun/management/jmxremote/startstop/REMOTE_TESTING.txt Changeset: 39cbe256c3d1 Author: alanb Date: 2012-10-01 15:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/39cbe256c3d1 8000269: Cleanup javadoc warnings Reviewed-by: lancea, darcy, ulfzibis, iris, naoto, dholmes ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/io/PrintWriter.java ! src/share/classes/java/io/Reader.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/InheritableThreadLocal.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/ThreadGroup.java ! src/share/classes/java/lang/ThreadLocal.java ! src/share/classes/java/lang/management/ThreadInfo.java ! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/Inet4Address.java ! src/share/classes/java/net/SocketInputStream.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/java/net/SocksSocketImpl.java ! src/share/classes/java/net/URLConnection.java ! src/share/classes/java/nio/channels/Channels.java ! src/share/classes/java/nio/file/FileSystem.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java ! src/share/classes/java/nio/file/attribute/FileTime.java ! src/share/classes/java/security/AllPermission.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/CodeSource.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/cert/PKIXRevocationChecker.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/text/CollationElementIterator.java ! src/share/classes/java/text/DigitList.java ! src/share/classes/java/text/Format.java ! src/share/classes/java/text/RBCollationTables.java ! src/share/classes/java/text/RBTableBuilder.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/JapaneseImperialCalendar.java ! src/share/classes/java/util/JumboEnumSet.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/java/util/RegularEnumSet.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/prefs/XmlSupport.java ! src/share/classes/javax/crypto/CryptoAllPermission.java ! src/share/classes/javax/crypto/CryptoPermission.java ! src/share/classes/javax/crypto/CryptoPolicyParser.java ! src/share/classes/javax/crypto/NullCipherSpi.java ! src/share/classes/javax/management/loading/MLet.java ! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java ! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java ! src/share/classes/javax/naming/spi/NamingManager.java ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/javax/sql/ConnectionPoolDataSource.java ! src/share/classes/javax/sql/PooledConnection.java ! src/share/classes/javax/sql/rowset/spi/SyncProvider.java Changeset: 75080f572f84 Author: olagneau Date: 2012-10-02 10:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/75080f572f84 7050528: Improve performance of java.text.DecimalFormat.format() call stack Reviewed-by: darcy ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/NumberFormat.java + test/java/text/Format/DecimalFormat/FormatMicroBenchmark.java + test/java/text/Format/DecimalFormat/GoldenDoubleValues.java + test/java/text/Format/DecimalFormat/GoldenFormattedValues.java + test/java/text/Format/DecimalFormat/RoundingAndPropertyTest.java Changeset: 041c687c4f40 Author: psandoz Date: 2012-10-02 10:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/041c687c4f40 7197642: (sl) ServiceLoader.load(null) doesn't throw NPE Reviewed-by: alanb ! src/share/classes/java/util/ServiceLoader.java + test/java/util/ServiceLoader/NPE.java Changeset: 6750ab947255 Author: alanb Date: 2012-10-02 12:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6750ab947255 8000268: sun/security/provider/X509Factory/BigCRL.java failing on Linux 32-bit Reviewed-by: mullan ! test/sun/security/provider/X509Factory/BigCRL.java Changeset: 4744dc70e5d1 Author: peytoia Date: 2012-10-03 15:11 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4744dc70e5d1 7104012: AIOOBE from RuleBasedBreakIterator.lookupState for some suppl. chars Reviewed-by: okutsu ! src/share/classes/sun/text/SupplementaryCharacterData.java + test/java/text/BreakIterator/Bug7104012.java Changeset: 7fe88d457d85 Author: dxu Date: 2012-10-03 09:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7fe88d457d85 6910472: Typo in : java.io.ObjectOutputStream.reset() "refered" Reviewed-by: dholmes, alanb ! src/share/classes/java/io/ObjectOutputStream.java Changeset: 123db1c28d92 Author: peytoia Date: 2012-10-04 11:36 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/123db1c28d92 7196316: Wrong rounding mode in DecimalFormat after deserialization Reviewed-by: okutsu ! src/share/classes/java/text/DecimalFormat.java + test/java/text/Format/DecimalFormat/Bug7196316.java Changeset: 8692e14b8ea8 Author: peytoia Date: 2012-10-04 18:05 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8692e14b8ea8 7201151: Fix Contribution : Java cannot get Windows's IME name correctly Reviewed-by: okutsu ! src/windows/native/sun/windows/awt_InputMethod.cpp Changeset: 344f0acff085 Author: vinnie Date: 2012-02-14 11:18 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/344f0acff085 7133495: [macosx] KeyChain KeyStore implementation retrieves only one private key entry Reviewed-by: weijun ! src/macosx/native/apple/security/KeystoreImpl.m + test/sun/security/tools/keytool/ListKeychainStore.sh Changeset: 77af5b4ae4f0 Author: vinnie Date: 2012-10-04 11:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/77af5b4ae4f0 Merge Changeset: c6a0b13e6efa Author: naoto Date: 2012-10-04 10:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c6a0b13e6efa 7196799: CLDR adapter can not be invoked when region code is specified in Locale 7197573: java/util/Locale/LocaleProviders.sh failed. Reviewed-by: okutsu ! make/java/java/FILES_java.gmk ! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java + src/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh Changeset: bba370caafad Author: robm Date: 2012-10-04 19:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bba370caafad 7184932: Remove the temporary Selector usage in the NIO socket adapters Reviewed-by: alanb ! make/java/nio/mapfile-bsd ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/nio/ch/Util.java ! src/solaris/native/sun/nio/ch/Net.c ! src/windows/native/sun/nio/ch/Net.c + test/java/nio/channels/etc/AdaptorCloseAndInterrupt.java Changeset: cd4f181eb666 Author: naoto Date: 2012-10-04 21:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cd4f181eb666 7200119: Collator.getAvailableLocales() doesn't return Locale.US Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java + test/java/text/Collator/Bug7200119.java Changeset: 647424d6cf65 Author: naoto Date: 2012-10-04 21:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/647424d6cf65 Merge Changeset: 88a726a5b2dc Author: naoto Date: 2012-10-05 09:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/88a726a5b2dc 7198834: HOST Adapter: one extra empty space in the end of the pattern string Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/windows/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh Changeset: f65871e75fde Author: alanb Date: 2012-10-06 13:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f65871e75fde 8000354: (props) Properties.storeToXML/loadFromXML need to allow for alternative implementations Reviewed-by: mchung, forax ! make/java/java/FILES_java.gmk ! make/sun/util/Makefile ! src/share/classes/java/util/Properties.java + src/share/classes/sun/util/spi/XmlPropertiesProvider.java + src/share/classes/sun/util/xml/META-INF/services/sun.util.spi.XmlPropertiesProvider + src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java - src/share/classes/sun/util/xml/XMLUtils.java + test/java/util/Properties/CustomProvider.java + test/java/util/Properties/LoadAndStoreXML.java + test/java/util/Properties/MyXmlPropertiesProvider.java Changeset: 92f3a96f3c78 Author: weijun Date: 2012-10-08 10:42 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/92f3a96f3c78 7201053: Krb5LoginModule shows NPE when both useTicketCache and storeKey are set to true Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java + test/sun/security/krb5/auto/UseCacheAndStoreKey.java Changeset: d8581143e11d Author: lana Date: 2012-10-08 15:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d8581143e11d Merge - src/share/classes/sun/util/xml/XMLUtils.java - src/share/test/pack200/pack.conf Changeset: 61ddb3fd000a Author: lana Date: 2012-10-11 16:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/61ddb3fd000a Merge - src/share/classes/sun/util/xml/XMLUtils.java - src/share/test/pack200/pack.conf Changeset: 1ae6420126af Author: katleman Date: 2012-10-18 11:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1ae6420126af Added tag jdk8-b61 for changeset 61ddb3fd000a ! .hgtags From john.coomes at oracle.com Thu Oct 18 21:08:02 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 19 Oct 2012 04:08:02 +0000 Subject: hg: hsx/hotspot-comp/langtools: 22 new changesets Message-ID: <20121019040850.A020E47439@hg.openjdk.java.net> Changeset: 8987971bcb45 Author: jjg Date: 2012-09-24 14:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/8987971bcb45 7196462: JavacProcessingEnvironment should tolerate BasicJavacTask Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/processing/T7196462.java Changeset: 99983a4a593b Author: mcimadamore Date: 2012-09-25 11:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/99983a4a593b 7193913: Cleanup Resolve.findMethod Summary: Refactor method lookup logic in Resolve.findMethod Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java Changeset: 26d93df3905a Author: mcimadamore Date: 2012-09-25 11:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/26d93df3905a 7194586: Add back-end support for invokedynamic Summary: Add support for invokedynamic bytecode instruction; includes suppot for generation of all related classfile attributes Reviewed-by: jjg ! 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/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! 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 ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/util/Names.java + test/tools/javac/lambda/TestInvokeDynamic.java Changeset: 2eca84194807 Author: mcimadamore Date: 2012-09-25 11:55 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/2eca84194807 7175433: Inference cleanup: add helper class to handle inference variables Summary: Add class to handle inference variables instantiation and associated info Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/generics/inference/6638712/T6638712c.out + test/tools/javac/varargs/6313164/T7175433.java Changeset: ad2ca2a4ab5e Author: mcimadamore Date: 2012-09-25 11:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/ad2ca2a4ab5e 7177306: Regression: unchecked method call does not erase return type Summary: Spurious extra call to Attr.checkMethod when method call is unchecked Reviewed-by: jjg, dlsmith ! 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/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/6758789/T6758789b.out ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/IncompatibleEqUpperBounds.java ! test/tools/javac/generics/7015430/T7015430.out ! test/tools/javac/generics/7151802/T7151802.out + test/tools/javac/generics/inference/7177306/T7177306a.java + test/tools/javac/generics/inference/7177306/T7177306a.out + test/tools/javac/generics/inference/7177306/T7177306b.java + test/tools/javac/generics/inference/7177306/T7177306b.out + test/tools/javac/generics/inference/7177306/T7177306c.java + test/tools/javac/generics/inference/7177306/T7177306d.java + test/tools/javac/generics/inference/7177306/T7177306e.java + test/tools/javac/generics/inference/7177306/T7177306e.out Changeset: 0e5899f09dab Author: jjg Date: 2012-09-25 13:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/0e5899f09dab 7193657: provide internal ArrayUtils class to simplify common usage of arrays in javac Reviewed-by: mcimadamore, jjg Contributed-by: vicenterz at yahoo.es ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/javac/api/MultiTaskListener.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/file/Locations.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java + src/share/classes/com/sun/tools/javac/util/ArrayUtils.java ! src/share/classes/com/sun/tools/javac/util/Bits.java ! src/share/classes/com/sun/tools/javac/util/ByteBuffer.java ! src/share/classes/com/sun/tools/javac/util/SharedNameTable.java ! src/share/classes/com/sun/tools/javap/StackMapWriter.java Changeset: 99d23c0ef8ee Author: jjg Date: 2012-09-25 13:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/99d23c0ef8ee 7196464: upgrade JavaCompiler.shouldStopPolicy to accomodate policies in face of error and no error Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Changeset: db36841709e4 Author: mcimadamore Date: 2012-09-26 14:22 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/db36841709e4 7188968: New instance creation expression using diamond is checked twice Summary: Unify method and constructor check logic Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/6840059/T6840059.out ! test/tools/javac/6857948/T6857948.out ! test/tools/javac/diags/examples/KindnameConstructor.java ! test/tools/javac/generics/diamond/7002837/T7002837.java + test/tools/javac/generics/diamond/7002837/T7002837.out + test/tools/javac/generics/diamond/7188968/T7188968.java + test/tools/javac/generics/diamond/7188968/T7188968.out ! test/tools/javac/positions/T6264029.out Changeset: 1a65d6565b45 Author: mcimadamore Date: 2012-09-28 16:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/1a65d6565b45 8000233: Fix issues in recent push Summary: Forgot to incorporate review comments in pushed changesets Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/util/Names.java Changeset: f1e6b361a329 Author: mcimadamore Date: 2012-09-28 18:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f1e6b361a329 8000241: langtools doesn't build Summary: bad merge with langtools tip caused build glitch Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! test/tools/javac/lambda/TestInvokeDynamic.java Changeset: 73312ec2cf7c Author: jfranck Date: 2012-09-28 11:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/73312ec2cf7c 7199925: Separate compilation breaks check that elements have a default for the containing annotation Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties Changeset: e77841f2c74b Author: lana Date: 2012-09-28 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/e77841f2c74b Merge Changeset: 20e4a54b1629 Author: ksrini Date: 2012-09-29 09:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/20e4a54b1629 7198582: (java) Minor refactor of JavacParser Reviewed-by: jjg, ksrini Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java Changeset: 1408af4cd8b0 Author: mcimadamore Date: 2012-10-04 13:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/1408af4cd8b0 7177387: Add target-typing support in method context Summary: Add support for deferred types and speculative attribution Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Source.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/code/TypeTags.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/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/Check.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/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/conditional/Conditional.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/IncompatibleTypesInConditional.java + test/tools/javac/diags/examples/TypeConditional.java Changeset: 573ceb23beeb Author: mcimadamore Date: 2012-10-05 14:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/573ceb23beeb 7177385: Add attribution support for lambda expressions Summary: Add support for function descriptor lookup, functional interface inference and lambda expression type-checking Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Printer.java ! 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/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.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/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/6402516/TestLocalElements.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/CantAccessArgTypeInFunctionalDesc.java + test/tools/javac/diags/examples/CantAccessReturnTypeInFunctionalDesc.java + test/tools/javac/diags/examples/CantAccessThrownTypesInFunctionalDesc.java ! test/tools/javac/diags/examples/CantRefNonEffectivelyFinalVar.java ! test/tools/javac/diags/examples/CatchWithoutTry.java + test/tools/javac/diags/examples/CyclicInference.java + test/tools/javac/diags/examples/IncompatibleAbstracts.java + test/tools/javac/diags/examples/IncompatibleArgTypesInLambda.java + test/tools/javac/diags/examples/IncompatibleDescsInFunctionalIntf.java + test/tools/javac/diags/examples/IncompatibleRetTypeInLambda.java + test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java + test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java + test/tools/javac/diags/examples/MissingReturnValueFragment.java + test/tools/javac/diags/examples/NoAbstracts.java + test/tools/javac/diags/examples/NoSuitableFunctionalIntfInst.java + test/tools/javac/diags/examples/NotAFunctionalIntf.java + test/tools/javac/diags/examples/PotentialLambdaFound.java - test/tools/javac/diags/examples/TypeConditional.java + test/tools/javac/diags/examples/UnexpectedLambda.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/typeAnnotations/newlocations/BasicTest.out Changeset: d604fd09480b Author: bpatel Date: 2012-10-05 14:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/d604fd09480b 7132631: The help-doc.html generates an invalid link to constant-values.html Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties + test/com/sun/javadoc/testHelpFile/TestHelpFile.java Changeset: ef88ae455c88 Author: bpatel Date: 2012-10-05 14:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/ef88ae455c88 7068595: html files in class-use dir do not get loaded correctly when Frames link is clicked Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! test/com/sun/javadoc/testUseOption/TestUseOption.java Changeset: f4e45397722a Author: bpatel Date: 2012-10-05 14:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f4e45397722a 4696488: javadoc doesn't handle UNC paths for destination directory Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java + test/tools/javadoc/T4696488.java Changeset: d4b3cb1ece84 Author: mcimadamore Date: 2012-10-06 10:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/d4b3cb1ece84 7177386: Add attribution support for method references Summary: Add type-checking/lookup routines for method references Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! test/tools/javac/6758789/T6758789a.out ! test/tools/javac/6840059/T6840059.out ! test/tools/javac/7132880/T7132880.out ! test/tools/javac/Diagnostics/6722234/T6722234a_1.out ! test/tools/javac/Diagnostics/6722234/T6722234a_2.out ! test/tools/javac/Diagnostics/6722234/T6722234b_1.out ! test/tools/javac/Diagnostics/6722234/T6722234b_2.out ! test/tools/javac/Diagnostics/6722234/T6722234c.out ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/Diagnostics/6862608/T6862608b.out ! test/tools/javac/T6326754.out ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/CantAccessInnerClsConstr.java + test/tools/javac/diags/examples/CantApplySymbolFragment.java + test/tools/javac/diags/examples/CantApplySymbolsFragment.java + test/tools/javac/diags/examples/CantResolveLocationArgsFragment.java + test/tools/javac/diags/examples/CantResolveLocationArgsParamsFragment.java ! test/tools/javac/diags/examples/CyclicInference.java ! test/tools/javac/diags/examples/ExplicitParamsDoNotConformToBounds.java ! test/tools/javac/diags/examples/InaccessibleVarargsType/InaccessibleVarargsType.java ! test/tools/javac/diags/examples/IncompatibleEqUpperBounds.java + test/tools/javac/diags/examples/IncompatibleRetTypeInMref.java + test/tools/javac/diags/examples/IncompatibleThrownTypesInMref.java ! test/tools/javac/diags/examples/InferArgsLengthMismatch.java ! test/tools/javac/diags/examples/InferNoConformingAssignment.java ! test/tools/javac/diags/examples/InferVarargsArgumentMismatch.java ! test/tools/javac/diags/examples/InferredDoNotConformToEq.java ! test/tools/javac/diags/examples/InferredDoNotConformToUpper.java ! test/tools/javac/diags/examples/KindnameConstructor.java ! test/tools/javac/diags/examples/MethodReferencesNotSupported.java ! test/tools/javac/diags/examples/NoArgs.java + test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java ! test/tools/javac/diags/examples/NotApplicableMethodFound.java + test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessFragment.java + test/tools/javac/diags/examples/RefAmbiguousFragment.java + test/tools/javac/diags/examples/UnexpectedMref.java ! test/tools/javac/diags/examples/VarargsArgumentMismatch.java ! test/tools/javac/diags/examples/VerboseResolveMulti1.java ! test/tools/javac/diags/examples/WhereCaptured.java ! test/tools/javac/diags/examples/WhereCaptured1.java ! test/tools/javac/diags/examples/WhereTypeVar.java ! test/tools/javac/generics/7034511/T7034511a.out ! test/tools/javac/generics/7034511/T7034511b.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/6638712/T6638712a.out ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712d.out ! test/tools/javac/generics/inference/6838943/T6838943.out ! test/tools/javac/generics/inference/7086586/T7086586.out ! test/tools/javac/generics/inference/7177306/T7177306b.out ! test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/quid/T6999438.out ! test/tools/javac/varargs/6313164/T6313164.out Changeset: aa3ef5c09b1b Author: lana Date: 2012-10-08 15:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/aa3ef5c09b1b Merge Changeset: 26020b247ad3 Author: lana Date: 2012-10-11 17:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/26020b247ad3 Merge Changeset: b47bb81ba962 Author: katleman Date: 2012-10-18 11:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/b47bb81ba962 Added tag jdk8-b61 for changeset 26020b247ad3 ! .hgtags From dean.long at oracle.com Fri Oct 19 10:32:25 2012 From: dean.long at oracle.com (Dean Long) Date: Fri, 19 Oct 2012 10:32:25 -0700 Subject: RFR (XS) 8001101: C2: more general vector rule subsetting In-Reply-To: <3EE88A80-8991-41F3-A8CE-04A4C8C667DA@oracle.com> References: <5080C591.6070608@oracle.com> <3EE88A80-8991-41F3-A8CE-04A4C8C667DA@oracle.com> Message-ID: <50818EA9.3070401@oracle.com> Thanks, Validimir. Can I get one more review please? dl On 10/18/2012 08:37 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On Oct 18, 2012, at 8:14 PM, Dean Long wrote: > >> http://cr.openjdk.java.net/~dlong/8001101/webrev.0 >> >> Allow which vector rules are supported to be decided at runtime. Also a small change to allow >> vector types in Type::_type_info[] to apply to more platforms. >> >> dl >> From vladimir.kozlov at oracle.com Fri Oct 19 10:38:16 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 19 Oct 2012 10:38:16 -0700 Subject: RFR (XS) 8001101: C2: more general vector rule subsetting In-Reply-To: <50818EA9.3070401@oracle.com> References: <5080C591.6070608@oracle.com> <3EE88A80-8991-41F3-A8CE-04A4C8C667DA@oracle.com> <50818EA9.3070401@oracle.com> Message-ID: <50819008.50207@oracle.com> Dean, Since changes as very small one review is enough in our group. Also could you push this fix into hotspot-compiler/hotspot repository to get more test coverage before we push into main? Thanks, Vladimir Dean Long wrote: > Thanks, Validimir. > > Can I get one more review please? > > dl > > On 10/18/2012 08:37 PM, Vladimir Kozlov wrote: >> Looks good. >> >> Thanks, >> Vladimir >> >> On Oct 18, 2012, at 8:14 PM, Dean Long wrote: >> >>> http://cr.openjdk.java.net/~dlong/8001101/webrev.0 >>> >>> Allow which vector rules are supported to be decided at runtime. Also >>> a small change to allow >>> vector types in Type::_type_info[] to apply to more platforms. >>> >>> dl >>> > From christian.thalinger at oracle.com Fri Oct 19 11:09:00 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 19 Oct 2012 11:09:00 -0700 Subject: RFR (XS) 8001101: C2: more general vector rule subsetting In-Reply-To: <5080C591.6070608@oracle.com> References: <5080C591.6070608@oracle.com> Message-ID: Looks good. -- Chris On Oct 18, 2012, at 8:14 PM, Dean Long wrote: > http://cr.openjdk.java.net/~dlong/8001101/webrev.0 > > Allow which vector rules are supported to be decided at runtime. Also a small change to allow > vector types in Type::_type_info[] to apply to more platforms. > > dl > From dean.long at oracle.com Fri Oct 19 11:25:38 2012 From: dean.long at oracle.com (Dean Long) Date: Fri, 19 Oct 2012 11:25:38 -0700 Subject: RFR (XS) 8001101: C2: more general vector rule subsetting In-Reply-To: <50819008.50207@oracle.com> References: <5080C591.6070608@oracle.com> <3EE88A80-8991-41F3-A8CE-04A4C8C667DA@oracle.com> <50818EA9.3070401@oracle.com> <50819008.50207@oracle.com> Message-ID: <50819B22.9060207@oracle.com> On 10/19/2012 10:38 AM, Vladimir Kozlov wrote: > Dean, > > Since changes as very small one review is enough in our group. > OK. > Also could you push this fix into hotspot-compiler/hotspot repository > to get more test coverage before we push into main? > Sure. dl > Thanks, > Vladimir > > Dean Long wrote: >> Thanks, Validimir. >> >> Can I get one more review please? >> >> dl >> >> On 10/18/2012 08:37 PM, Vladimir Kozlov wrote: >>> Looks good. >>> >>> Thanks, >>> Vladimir >>> >>> On Oct 18, 2012, at 8:14 PM, Dean Long wrote: >>> >>>> http://cr.openjdk.java.net/~dlong/8001101/webrev.0 >>>> >>>> Allow which vector rules are supported to be decided at runtime. >>>> Also a small change to allow >>>> vector types in Type::_type_info[] to apply to more platforms. >>>> >>>> dl >>>> >> From vladimir.x.ivanov at oracle.com Fri Oct 19 11:39:08 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 19 Oct 2012 22:39:08 +0400 Subject: RFR (M): 8000805: JMM issue: short loads are non-atomic Message-ID: <50819E4C.4090206@oracle.com> http://cr.openjdk.java.net/~vlivanov/8000805/webrev.00/ 282 lines changed: 255 ins; 27 del; 0 mod Ideal transformations during parsing & IGVN may rematerialize loads in order to reify useful information (like signed/unsigned load). Such behavior breaks JMM - instead of a single atomic load, multiple loads are performed violating consistency of loaded data. The fix is to disable such transformations at all, but perform relevant optimizations during matching. It fixes only C2 part of problem. ?1 has similar deficiency, but it'll be addressed separately. Testing: failing test, test for new matching rules, JPRT, CTW (x86, x64 & sparc). Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Fri Oct 19 13:37:28 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 20 Oct 2012 00:37:28 +0400 Subject: RFR (M): 8000805: JMM issue: short loads are non-atomic In-Reply-To: <50819E4C.4090206@oracle.com> References: <50819E4C.4090206@oracle.com> Message-ID: <5081BA08.60808@oracle.com> Disregard my comment about C1. I vaguely remember I saw it fails and CR has a comment by Vladimir K. about C1 being also affected, but I'm not able to reproduce the problem anymore. Best regards, Vladimir Ivanov On 10/19/12 10:39 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8000805/webrev.00/ > 282 lines changed: 255 ins; 27 del; 0 mod > > Ideal transformations during parsing & IGVN may rematerialize loads in > order to reify useful information (like signed/unsigned load). Such > behavior breaks JMM - instead of a single atomic load, multiple loads > are performed violating consistency of loaded data. > > The fix is to disable such transformations at all, but perform relevant > optimizations during matching. > > It fixes only C2 part of problem. ?1 has similar deficiency, but it'll > be addressed separately. > > Testing: failing test, test for new matching rules, JPRT, CTW (x86, x64 > & sparc). > > Best regards, > Vladimir Ivanov From aleksey.shipilev at oracle.com Fri Oct 19 14:46:06 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 20 Oct 2012 01:46:06 +0400 Subject: RFR (M): 8000805: JMM issue: short loads are non-atomic In-Reply-To: <5081BA08.60808@oracle.com> References: <50819E4C.4090206@oracle.com> <5081BA08.60808@oracle.com> Message-ID: <5081CA1E.7010703@oracle.com> Please double-check. Reproduces perfectly with 32-bit build on my x86_64 Linux: $ ~/Install.32/jdk7u4/bin/java -client -version java version "1.7.0_04" Java(TM) SE Runtime Environment (build 1.7.0_04-b20) Java HotSpot(TM) Client VM (build 23.0-b21, mixed mode) $ ~/Install.32/jdk7u4/bin/java -client -jar target/concurrency-torture.jar -t ".*ShortAtomicity.*" Java Concurrency Torture Tests --------------------------------------------------------------------------------- Running in forked mode... Running net.shipilev.concurrent.torture.tests.primitiveAtomicity.ShortAtomicityTest Warmup ..... Observed state Occurrences Expectation Interpretation [0, 0] ( 878998) REQUIRED [-1, -1] ( 10025286) REQUIRED [-1, 0] ( 15596) FORBIDDEN Running net.shipilev.concurrent.torture.tests.primitiveAtomicity.VolatileShortAtomicityTest Warmup ..... Observed state Occurrences Expectation Interpretation [0, 0] ( 5322930) REQUIRED [-1, -1] ( 1774531) REQUIRED [-1, 0] ( 13709) FORBIDDEN -Aleksey. On 10/20/2012 12:37 AM, Vladimir Ivanov wrote: > Disregard my comment about C1. > > I vaguely remember I saw it fails and CR has a comment by Vladimir K. > about C1 being also affected, but I'm not able to reproduce the problem > anymore. > > Best regards, > Vladimir Ivanov > > On 10/19/12 10:39 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8000805/webrev.00/ >> 282 lines changed: 255 ins; 27 del; 0 mod >> >> Ideal transformations during parsing & IGVN may rematerialize loads in >> order to reify useful information (like signed/unsigned load). Such >> behavior breaks JMM - instead of a single atomic load, multiple loads >> are performed violating consistency of loaded data. >> >> The fix is to disable such transformations at all, but perform relevant >> optimizations during matching. >> >> It fixes only C2 part of problem. ?1 has similar deficiency, but it'll >> be addressed separately. >> >> Testing: failing test, test for new matching rules, JPRT, CTW (x86, x64 >> & sparc). >> >> Best regards, >> Vladimir Ivanov From vladimir.x.ivanov at oracle.com Fri Oct 19 15:09:45 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 20 Oct 2012 02:09:45 +0400 Subject: RFR (M): 8000805: JMM issue: short loads are non-atomic In-Reply-To: <5081CA1E.7010703@oracle.com> References: <50819E4C.4090206@oracle.com> <5081BA08.60808@oracle.com> <5081CA1E.7010703@oracle.com> Message-ID: <5081CFA9.7090708@oracle.com> Aleksey, Thanks for checking that. I'll look into the issue. Best regards, Vladimir Ivanov On 10/20/12 1:46 AM, Aleksey Shipilev wrote: > Please double-check. Reproduces perfectly with 32-bit build on my x86_64 > Linux: > > $ ~/Install.32/jdk7u4/bin/java -client -version > java version "1.7.0_04" > Java(TM) SE Runtime Environment (build 1.7.0_04-b20) > Java HotSpot(TM) Client VM (build 23.0-b21, mixed mode) > > $ ~/Install.32/jdk7u4/bin/java -client -jar > target/concurrency-torture.jar -t ".*ShortAtomicity.*" > Java Concurrency Torture Tests > --------------------------------------------------------------------------------- > Running in forked mode... > > Running > net.shipilev.concurrent.torture.tests.primitiveAtomicity.ShortAtomicityTest > Warmup ..... > Observed state Occurrences Expectation > Interpretation > [0, 0] ( 878998) REQUIRED > [-1, -1] ( 10025286) REQUIRED > [-1, 0] ( 15596) FORBIDDEN > > Running > net.shipilev.concurrent.torture.tests.primitiveAtomicity.VolatileShortAtomicityTest > Warmup ..... > Observed state Occurrences Expectation > Interpretation > [0, 0] ( 5322930) REQUIRED > [-1, -1] ( 1774531) REQUIRED > [-1, 0] ( 13709) FORBIDDEN > > > -Aleksey. > > > On 10/20/2012 12:37 AM, Vladimir Ivanov wrote: >> Disregard my comment about C1. >> >> I vaguely remember I saw it fails and CR has a comment by Vladimir K. >> about C1 being also affected, but I'm not able to reproduce the problem >> anymore. >> >> Best regards, >> Vladimir Ivanov >> >> On 10/19/12 10:39 PM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8000805/webrev.00/ >>> 282 lines changed: 255 ins; 27 del; 0 mod >>> >>> Ideal transformations during parsing & IGVN may rematerialize loads in >>> order to reify useful information (like signed/unsigned load). Such >>> behavior breaks JMM - instead of a single atomic load, multiple loads >>> are performed violating consistency of loaded data. >>> >>> The fix is to disable such transformations at all, but perform relevant >>> optimizations during matching. >>> >>> It fixes only C2 part of problem. ?1 has similar deficiency, but it'll >>> be addressed separately. >>> >>> Testing: failing test, test for new matching rules, JPRT, CTW (x86, x64 >>> & sparc). >>> >>> Best regards, >>> Vladimir Ivanov > From vitalyd at gmail.com Fri Oct 19 16:22:46 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 19 Oct 2012 19:22:46 -0400 Subject: RFR (M): 8000805: JMM issue: short loads are non-atomic In-Reply-To: <50819E4C.4090206@oracle.com> References: <50819E4C.4090206@oracle.com> Message-ID: Hi Vladimir, Just curious - in the ad files you didn't put ins_cost() for most of the new matches, is that intentional? Thanks Sent from my phone On Oct 19, 2012 2:40 PM, "Vladimir Ivanov" wrote: > http://cr.openjdk.java.net/~**vlivanov/8000805/webrev.00/ > 282 lines changed: 255 ins; 27 del; 0 mod > > Ideal transformations during parsing & IGVN may rematerialize loads in > order to reify useful information (like signed/unsigned load). Such > behavior breaks JMM - instead of a single atomic load, multiple loads are > performed violating consistency of loaded data. > > The fix is to disable such transformations at all, but perform relevant > optimizations during matching. > > It fixes only C2 part of problem. ?1 has similar deficiency, but it'll be > addressed separately. > > Testing: failing test, test for new matching rules, JPRT, CTW (x86, x64 & > sparc). > > Best regards, > Vladimir Ivanov > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121019/05a0b123/attachment.html From aleksey.shipilev at oracle.com Fri Oct 19 16:27:41 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 20 Oct 2012 03:27:41 +0400 Subject: RFR (M): 8000805: JMM issue: short loads are non-atomic In-Reply-To: <5081CFA9.7090708@oracle.com> References: <50819E4C.4090206@oracle.com> <5081BA08.60808@oracle.com> <5081CA1E.7010703@oracle.com> <5081CFA9.7090708@oracle.com> Message-ID: <5081E1ED.4050603@oracle.com> In fact, I've been hit by the infamous trouble that RuntimeMXBean had munched -client, and forked JVM was running in server mode nevertheless. Running with -f false works. Sorry for false alarm. -Aleksey. On 10/20/2012 02:09 AM, Vladimir Ivanov wrote: > Aleksey, > > Thanks for checking that. I'll look into the issue. > > Best regards, > Vladimir Ivanov > > On 10/20/12 1:46 AM, Aleksey Shipilev wrote: >> Please double-check. Reproduces perfectly with 32-bit build on my x86_64 >> Linux: >> >> $ ~/Install.32/jdk7u4/bin/java -client -version >> java version "1.7.0_04" >> Java(TM) SE Runtime Environment (build 1.7.0_04-b20) >> Java HotSpot(TM) Client VM (build 23.0-b21, mixed mode) >> >> $ ~/Install.32/jdk7u4/bin/java -client -jar >> target/concurrency-torture.jar -t ".*ShortAtomicity.*" >> Java Concurrency Torture Tests >> --------------------------------------------------------------------------------- >> >> Running in forked mode... >> >> Running >> net.shipilev.concurrent.torture.tests.primitiveAtomicity.ShortAtomicityTest >> >> Warmup ..... >> Observed state Occurrences Expectation >> Interpretation >> [0, 0] ( 878998) REQUIRED >> [-1, -1] ( 10025286) REQUIRED >> [-1, 0] ( 15596) FORBIDDEN >> >> Running >> net.shipilev.concurrent.torture.tests.primitiveAtomicity.VolatileShortAtomicityTest >> >> Warmup ..... >> Observed state Occurrences Expectation >> Interpretation >> [0, 0] ( 5322930) REQUIRED >> [-1, -1] ( 1774531) REQUIRED >> [-1, 0] ( 13709) FORBIDDEN >> >> >> -Aleksey. >> >> >> On 10/20/2012 12:37 AM, Vladimir Ivanov wrote: >>> Disregard my comment about C1. >>> >>> I vaguely remember I saw it fails and CR has a comment by Vladimir K. >>> about C1 being also affected, but I'm not able to reproduce the problem >>> anymore. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 10/19/12 10:39 PM, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8000805/webrev.00/ >>>> 282 lines changed: 255 ins; 27 del; 0 mod >>>> >>>> Ideal transformations during parsing & IGVN may rematerialize loads in >>>> order to reify useful information (like signed/unsigned load). Such >>>> behavior breaks JMM - instead of a single atomic load, multiple loads >>>> are performed violating consistency of loaded data. >>>> >>>> The fix is to disable such transformations at all, but perform relevant >>>> optimizations during matching. >>>> >>>> It fixes only C2 part of problem. ?1 has similar deficiency, but it'll >>>> be addressed separately. >>>> >>>> Testing: failing test, test for new matching rules, JPRT, CTW (x86, x64 >>>> & sparc). >>>> >>>> Best regards, >>>> Vladimir Ivanov >> From vladimir.x.ivanov at oracle.com Fri Oct 19 18:35:11 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 20 Oct 2012 05:35:11 +0400 Subject: RFR (M): 8000805: JMM issue: short loads are non-atomic In-Reply-To: References: <50819E4C.4090206@oracle.com> Message-ID: <5081FFCF.1000108@oracle.com> Vitaly, Yes, I tried to keep the style of corresponding LoadUS rules. Best regards, Vladimir Ivanov On 10/20/12 3:22 AM, Vitaly Davidovich wrote: > Hi Vladimir, > > Just curious - in the ad files you didn't put ins_cost() for most of the > new matches, is that intentional? > > Thanks > > Sent from my phone > > On Oct 19, 2012 2:40 PM, "Vladimir Ivanov" > wrote: > > http://cr.openjdk.java.net/~__vlivanov/8000805/webrev.00/ > > 282 lines changed: 255 ins; 27 del; 0 mod > > Ideal transformations during parsing & IGVN may rematerialize loads > in order to reify useful information (like signed/unsigned load). > Such behavior breaks JMM - instead of a single atomic load, multiple > loads are performed violating consistency of loaded data. > > The fix is to disable such transformations at all, but perform > relevant optimizations during matching. > > It fixes only C2 part of problem. ?1 has similar deficiency, but > it'll be addressed separately. > > Testing: failing test, test for new matching rules, JPRT, CTW (x86, > x64 & sparc). > > Best regards, > Vladimir Ivanov > From vladimir.kozlov at oracle.com Fri Oct 19 18:35:21 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 19 Oct 2012 18:35:21 -0700 Subject: RFR (M): 8000805: JMM issue: short loads are non-atomic In-Reply-To: <5081F9A2.1050802@oracle.com> References: <50819E4C.4090206@oracle.com> <5538BE79-5E69-4547-9A52-844B027852DE@oracle.com> <5081D38B.3030504@oracle.com> <5081DFAB.60008@oracle.com> <5081F9A2.1050802@oracle.com> Message-ID: <5081FFD9.2040201@oracle.com> Vladimir Ivanov wrote: > They correspond, but indirectly. > There are no "(AndI (LoadUS))" rules, but "(ConvI2L (AndI (LoadUS))" are > present. So, if LoadS -> LoadUS transformation doesn't occur, ConvI2L > rules can't be applied. I addresses this by adding missing cases. I see. But in this case you can simple add second (or more) match rule: // Load Unsigned Byte (8 bit UNsigned) with 8-bit mask into Long Register instruct loadUB2L_immI8(iRegL dst, memory mem, immI8 mask) %{ match(Set dst (ConvI2L (AndI (LoadUB mem) mask))); + match(Set dst (ConvI2L (AndI (LoadB mem) mask))); > > Oh, I see what you are suggesting now. Yes, it definitely looks better > than what I have now. > > What I was concerned about is slightly different. And I haven't > addressed it with the the current fix. > > Current solution doesn't cover the following cases: > long f(short[] sa) { > short s = sa[0]; > return (s & 0xF0) & (s & 0x0F); > } > Before the fix, it was transformed into 2 AndI nodes which share LoadUS. > Now it stays LoadS till the end. I don't understand what the problem you have here. The expression result is 0 in this case. > > And when I talked about filtering, I was thinking about the following case: > public void observe(Specimen s, byte[] result) { > short t = s.x; > result[0] = (byte) (t & 0xFF); > result[1] = (byte) (t & 0xF0); > } > > After parsing of this method, LoadS has 3 users: LShiftI, AndI, StoreB, > CallStaticJava. To convert it into LoadUS I need to look at LShiftI & > AndI, but skip StoreB & CallStaticJava. Where LShiftI comes from? Vladimir > > But do these cases matter? > > Best regards, > Vladimir Ivanov > > On 10/20/12 3:18 AM, Vladimir Kozlov wrote: >> Vladimir I., >> >> Mach nodes you added do not correspond to removed ideal code - ideal >> code did not have ConvI2L transformations. >> >> What John suggested is to add simple check: >> >> if ((load->outcnt() == 1) && (load->unique_out() == this)) >> >> to allow these transformations. I agree that such transformations could >> be done only after parser when the graph is complete. >> >> Why do you think you need to filter out nodes? >> >> Thanks, >> Vladimir K. >> >> Vladimir Ivanov wrote: >>> John, >>> >>> Thanks for review. >>> >>> I started with the approach you suggests, but decided that moving >>> these checks into AD files is a cleaner solution. The code looked more >>> cumbersome because of the following: >>> - can't perform such transformations during parsing >>> - need to filter out nodes, which aren't affected by switch >>> between signed/unsigned versions (like stores, calls, etc). >>> >>> If you are fine with these complications, I'll reimplement the fix w/o >>> touching AD files. >>> >>> I'll double-check loadS2L_immI13 rule. Just checked and it turns out >>> my test doesn't cover it. Thanks for catching this. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 10/20/12 1:32 AM, John Rose wrote: >>>> I have a couple of reservations about this change. I would hope that >>>> the AD file logic could be more factored. The simm13 operand looks >>>> wrong: can't it be negative? In any case, the opt should apply up to >>>> 0xFFFF. >>>> >>>> I think you can (& should) keep the memnode logic if you can prove >>>> that all occurrences of the signed ld can be subsumed by the unsigned >>>> ld. This can be detected by using out edges. >>>> >>>> -- John (on my iPhone) >>>> >>>> On Oct 19, 2012, at 11:39 AM, Vladimir Ivanov >>>> wrote: >>>> >>>>> http://cr.openjdk.java.net/~vlivanov/8000805/webrev.00/ >>>>> 282 lines changed: 255 ins; 27 del; 0 mod >>>>> >>>>> Ideal transformations during parsing & IGVN may rematerialize loads >>>>> in order to reify useful information (like signed/unsigned load). >>>>> Such behavior breaks JMM - instead of a single atomic load, multiple >>>>> loads are performed violating consistency of loaded data. >>>>> >>>>> The fix is to disable such transformations at all, but perform >>>>> relevant optimizations during matching. >>>>> >>>>> It fixes only C2 part of problem. ?1 has similar deficiency, but >>>>> it'll be addressed separately. >>>>> >>>>> Testing: failing test, test for new matching rules, JPRT, CTW (x86, >>>>> x64 & sparc). >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov From vladimir.x.ivanov at oracle.com Fri Oct 19 19:43:57 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 20 Oct 2012 06:43:57 +0400 Subject: RFR (M): 8000805: JMM issue: short loads are non-atomic In-Reply-To: <5081FFD9.2040201@oracle.com> References: <50819E4C.4090206@oracle.com> <5538BE79-5E69-4547-9A52-844B027852DE@oracle.com> <5081D38B.3030504@oracle.com> <5081DFAB.60008@oracle.com> <5081F9A2.1050802@oracle.com> <5081FFD9.2040201@oracle.com> Message-ID: <50820FED.6020902@oracle.com> Sorry for erratic examples. I just want to clarify importance of LoadS<->LoadUS conversion. With the proposed fix (or simple check on out edges), there are cases when conversion doesn't occur anymore. I'll remove AD changes anyway. Your solution looks much better. But I want do understand whether it's enough. >> They correspond, but indirectly. >> There are no "(AndI (LoadUS))" rules, but "(ConvI2L (AndI (LoadUS))" >> are present. So, if LoadS -> LoadUS transformation doesn't occur, >> ConvI2L rules can't be applied. I addresses this by adding missing cases. > > I see. But in this case you can simple add second (or more) match rule: > > // Load Unsigned Byte (8 bit UNsigned) with 8-bit mask into Long > Register > instruct loadUB2L_immI8(iRegL dst, memory mem, immI8 mask) %{ > match(Set dst (ConvI2L (AndI (LoadUB mem) mask))); > + match(Set dst (ConvI2L (AndI (LoadB mem) mask))); Thanks for the hint! I wasn't aware about that :-) That's exactly what I wanted to do. >> Oh, I see what you are suggesting now. Yes, it definitely looks better >> than what I have now. >> >> What I was concerned about is slightly different. And I haven't >> addressed it with the the current fix. >> >> Current solution doesn't cover the following cases: >> long f(short[] sa) { >> short s = sa[0]; >> return (s & 0xF0) & (s & 0x0F); >> } >> Before the fix, it was transformed into 2 AndI nodes which share LoadUS. >> Now it stays LoadS till the end. > I don't understand what the problem you have here. The expression result > is 0 in this case. Sorry, it was a typo - it should be "return (s & 0xF0) + (s & 0x0F);". My concern in this particular case is that an opportunity to transform LoadS into LoadUS is missed. Before the fix LoadS is successfully transformed into LoadUS. I see that "ConvI2L (AndI (LoadUS/LoadS))" rules aren't applicable here. What I want to understand is whether LoadS/LoadUS conversion is important or not. >> And when I talked about filtering, I was thinking about the following >> case: >> public void observe(Specimen s, byte[] result) { >> short t = s.x; >> result[0] = (byte) (t & 0xFF); >> result[1] = (byte) (t & 0xF0); >> } >> >> After parsing of this method, LoadS has 3 users: LShiftI, AndI, >> StoreB, CallStaticJava. To convert it into LoadUS I need to look at >> LShiftI & AndI, but skip StoreB & CallStaticJava. > Where LShiftI comes from? It comes from i2b bytecode. In this particular case, it's illegal to convert LoadS to LoadUS. But only LShiftI forbids such conversion. Best regards, Vladimir Ivanov > Vladimir > >> >> But do these cases matter? >> >> Best regards, >> Vladimir Ivanov >> >> On 10/20/12 3:18 AM, Vladimir Kozlov wrote: >>> Vladimir I., >>> >>> Mach nodes you added do not correspond to removed ideal code - ideal >>> code did not have ConvI2L transformations. >>> >>> What John suggested is to add simple check: >>> >>> if ((load->outcnt() == 1) && (load->unique_out() == this)) >>> >>> to allow these transformations. I agree that such transformations could >>> be done only after parser when the graph is complete. >>> >>> Why do you think you need to filter out nodes? >>> >>> Thanks, >>> Vladimir K. >>> >>> Vladimir Ivanov wrote: >>>> John, >>>> >>>> Thanks for review. >>>> >>>> I started with the approach you suggests, but decided that moving >>>> these checks into AD files is a cleaner solution. The code looked more >>>> cumbersome because of the following: >>>> - can't perform such transformations during parsing >>>> - need to filter out nodes, which aren't affected by switch >>>> between signed/unsigned versions (like stores, calls, etc). >>>> >>>> If you are fine with these complications, I'll reimplement the fix w/o >>>> touching AD files. >>>> >>>> I'll double-check loadS2L_immI13 rule. Just checked and it turns out >>>> my test doesn't cover it. Thanks for catching this. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 10/20/12 1:32 AM, John Rose wrote: >>>>> I have a couple of reservations about this change. I would hope that >>>>> the AD file logic could be more factored. The simm13 operand looks >>>>> wrong: can't it be negative? In any case, the opt should apply up to >>>>> 0xFFFF. >>>>> >>>>> I think you can (& should) keep the memnode logic if you can prove >>>>> that all occurrences of the signed ld can be subsumed by the unsigned >>>>> ld. This can be detected by using out edges. >>>>> >>>>> -- John (on my iPhone) >>>>> >>>>> On Oct 19, 2012, at 11:39 AM, Vladimir Ivanov >>>>> wrote: >>>>> >>>>>> http://cr.openjdk.java.net/~vlivanov/8000805/webrev.00/ >>>>>> 282 lines changed: 255 ins; 27 del; 0 mod >>>>>> >>>>>> Ideal transformations during parsing & IGVN may rematerialize loads >>>>>> in order to reify useful information (like signed/unsigned load). >>>>>> Such behavior breaks JMM - instead of a single atomic load, multiple >>>>>> loads are performed violating consistency of loaded data. >>>>>> >>>>>> The fix is to disable such transformations at all, but perform >>>>>> relevant optimizations during matching. >>>>>> >>>>>> It fixes only C2 part of problem. ?1 has similar deficiency, but >>>>>> it'll be addressed separately. >>>>>> >>>>>> Testing: failing test, test for new matching rules, JPRT, CTW (x86, >>>>>> x64 & sparc). >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov From vladimir.kozlov at oracle.com Fri Oct 19 21:08:07 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 20 Oct 2012 04:08:07 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8001101: C2: more general vector rule subsetting Message-ID: <20121020040811.E853A4746B@hg.openjdk.java.net> Changeset: aaeb9add1ab3 Author: dlong Date: 2012-10-19 14:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/aaeb9add1ab3 8001101: C2: more general vector rule subsetting Summary: Allow which vector rules are supported to be decided at runtime. Also a small change to allow vector types in Type::_type_info[] to apply to more platforms. Reviewed-by: kvn, twisti Contributed-by: dean.long at oracle.com ! src/share/vm/opto/type.cpp ! src/share/vm/opto/vectornode.cpp From vladimir.x.ivanov at oracle.com Mon Oct 22 08:09:24 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 22 Oct 2012 19:09:24 +0400 Subject: RFR (M): 8000805: JMM issue: short loads are non-atomic In-Reply-To: <50819E4C.4090206@oracle.com> References: <50819E4C.4090206@oracle.com> Message-ID: <508561A4.2020000@oracle.com> Updated version: http://cr.openjdk.java.net/~vlivanov/8000805/webrev.01/ Removed changes in AD files and perform transforms during IGVN phase when Load has a single user. Best regards, Vladimir Ivanov On 10/19/12 22:39, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8000805/webrev.00/ > 282 lines changed: 255 ins; 27 del; 0 mod > > Ideal transformations during parsing & IGVN may rematerialize loads in > order to reify useful information (like signed/unsigned load). Such > behavior breaks JMM - instead of a single atomic load, multiple loads > are performed violating consistency of loaded data. > > The fix is to disable such transformations at all, but perform relevant > optimizations during matching. > > It fixes only C2 part of problem. ?1 has similar deficiency, but it'll > be addressed separately. > > Testing: failing test, test for new matching rules, JPRT, CTW (x86, x64 > & sparc). > > Best regards, > Vladimir Ivanov From vladimir.kozlov at oracle.com Mon Oct 22 08:25:59 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 22 Oct 2012 08:25:59 -0700 Subject: RFR (M): 8000805: JMM issue: short loads are non-atomic In-Reply-To: <508561A4.2020000@oracle.com> References: <50819E4C.4090206@oracle.com> <508561A4.2020000@oracle.com> Message-ID: Vladimir I. Instead of checking phase->is_IterGVN() you should check can_reshape flag which is used exactly for such purpose. Thanks, Vladimir K. On Oct 22, 2012, at 8:09 AM, Vladimir Ivanov wrote: > Updated version: http://cr.openjdk.java.net/~vlivanov/8000805/webrev.01/ > > Removed changes in AD files and perform transforms during IGVN phase > when Load has a single user. > > Best regards, > Vladimir Ivanov > > On 10/19/12 22:39, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8000805/webrev.00/ >> 282 lines changed: 255 ins; 27 del; 0 mod >> >> Ideal transformations during parsing & IGVN may rematerialize loads in >> order to reify useful information (like signed/unsigned load). Such >> behavior breaks JMM - instead of a single atomic load, multiple loads >> are performed violating consistency of loaded data. >> >> The fix is to disable such transformations at all, but perform relevant >> optimizations during matching. >> >> It fixes only C2 part of problem. ?1 has similar deficiency, but it'll >> be addressed separately. >> >> Testing: failing test, test for new matching rules, JPRT, CTW (x86, x64 >> & sparc). >> >> Best regards, >> Vladimir Ivanov From vladimir.x.ivanov at oracle.com Mon Oct 22 08:53:14 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 22 Oct 2012 19:53:14 +0400 Subject: RFR (M): 8000805: JMM issue: short loads are non-atomic In-Reply-To: References: <50819E4C.4090206@oracle.com> <508561A4.2020000@oracle.com> Message-ID: <50856BEA.1020002@oracle.com> Thanks, fixed. Best regards, Vladimir Ivanov On 10/22/12 19:25, Vladimir Kozlov wrote: > Vladimir I. > > Instead of checking phase->is_IterGVN() you should check can_reshape flag which is used exactly for such purpose. > > Thanks, > Vladimir K. > > On Oct 22, 2012, at 8:09 AM, Vladimir Ivanov wrote: > >> Updated version: http://cr.openjdk.java.net/~vlivanov/8000805/webrev.01/ >> >> Removed changes in AD files and perform transforms during IGVN phase >> when Load has a single user. >> >> Best regards, >> Vladimir Ivanov >> >> On 10/19/12 22:39, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8000805/webrev.00/ >>> 282 lines changed: 255 ins; 27 del; 0 mod >>> >>> Ideal transformations during parsing & IGVN may rematerialize loads in >>> order to reify useful information (like signed/unsigned load). Such >>> behavior breaks JMM - instead of a single atomic load, multiple loads >>> are performed violating consistency of loaded data. >>> >>> The fix is to disable such transformations at all, but perform relevant >>> optimizations during matching. >>> >>> It fixes only C2 part of problem. ?1 has similar deficiency, but it'll >>> be addressed separately. >>> >>> Testing: failing test, test for new matching rules, JPRT, CTW (x86, x64 >>> & sparc). >>> >>> Best regards, >>> Vladimir Ivanov > From vladimir.kozlov at oracle.com Mon Oct 22 08:55:16 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 22 Oct 2012 08:55:16 -0700 Subject: RFR (M): 8000805: JMM issue: short loads are non-atomic In-Reply-To: <50856BEA.1020002@oracle.com> References: <50819E4C.4090206@oracle.com> <508561A4.2020000@oracle.com> <50856BEA.1020002@oracle.com> Message-ID: Good. Thanks, Vladimir On Oct 22, 2012, at 8:53 AM, Vladimir Ivanov wrote: > Thanks, fixed. > > Best regards, > Vladimir Ivanov > > On 10/22/12 19:25, Vladimir Kozlov wrote: >> Vladimir I. >> >> Instead of checking phase->is_IterGVN() you should check can_reshape flag which is used exactly for such purpose. >> >> Thanks, >> Vladimir K. >> >> On Oct 22, 2012, at 8:09 AM, Vladimir Ivanov wrote: >> >>> Updated version: http://cr.openjdk.java.net/~vlivanov/8000805/webrev.01/ >>> >>> Removed changes in AD files and perform transforms during IGVN phase >>> when Load has a single user. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 10/19/12 22:39, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8000805/webrev.00/ >>>> 282 lines changed: 255 ins; 27 del; 0 mod >>>> >>>> Ideal transformations during parsing & IGVN may rematerialize loads in >>>> order to reify useful information (like signed/unsigned load). Such >>>> behavior breaks JMM - instead of a single atomic load, multiple loads >>>> are performed violating consistency of loaded data. >>>> >>>> The fix is to disable such transformations at all, but perform relevant >>>> optimizations during matching. >>>> >>>> It fixes only C2 part of problem. ?1 has similar deficiency, but it'll >>>> be addressed separately. >>>> >>>> Testing: failing test, test for new matching rules, JPRT, CTW (x86, x64 >>>> & sparc). >>>> >>>> Best regards, >>>> Vladimir Ivanov >> From vladimir.x.ivanov at oracle.com Mon Oct 22 09:00:23 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 22 Oct 2012 20:00:23 +0400 Subject: RFR (M): 8000805: JMM issue: short loads are non-atomic In-Reply-To: References: <50819E4C.4090206@oracle.com> <508561A4.2020000@oracle.com> <50856BEA.1020002@oracle.com> Message-ID: <50856D97.7030604@oracle.com> Thank you, Vladimir. Best regards, Vladimir Ivanov On 10/22/12 19:55, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On Oct 22, 2012, at 8:53 AM, Vladimir Ivanov wrote: > >> Thanks, fixed. >> >> Best regards, >> Vladimir Ivanov >> >> On 10/22/12 19:25, Vladimir Kozlov wrote: >>> Vladimir I. >>> >>> Instead of checking phase->is_IterGVN() you should check can_reshape flag which is used exactly for such purpose. >>> >>> Thanks, >>> Vladimir K. >>> >>> On Oct 22, 2012, at 8:09 AM, Vladimir Ivanov wrote: >>> >>>> Updated version: http://cr.openjdk.java.net/~vlivanov/8000805/webrev.01/ >>>> >>>> Removed changes in AD files and perform transforms during IGVN phase >>>> when Load has a single user. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 10/19/12 22:39, Vladimir Ivanov wrote: >>>>> http://cr.openjdk.java.net/~vlivanov/8000805/webrev.00/ >>>>> 282 lines changed: 255 ins; 27 del; 0 mod >>>>> >>>>> Ideal transformations during parsing & IGVN may rematerialize loads in >>>>> order to reify useful information (like signed/unsigned load). Such >>>>> behavior breaks JMM - instead of a single atomic load, multiple loads >>>>> are performed violating consistency of loaded data. >>>>> >>>>> The fix is to disable such transformations at all, but perform relevant >>>>> optimizations during matching. >>>>> >>>>> It fixes only C2 part of problem. ?1 has similar deficiency, but it'll >>>>> be addressed separately. >>>>> >>>>> Testing: failing test, test for new matching rules, JPRT, CTW (x86, x64 >>>>> & sparc). >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>> > From christian.thalinger at oracle.com Mon Oct 22 09:24:46 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 22 Oct 2012 09:24:46 -0700 Subject: RFR (M): 8000805: JMM issue: short loads are non-atomic In-Reply-To: <50856BEA.1020002@oracle.com> References: <50819E4C.4090206@oracle.com> <508561A4.2020000@oracle.com> <50856BEA.1020002@oracle.com> Message-ID: Looks good. -- Chris On Oct 22, 2012, at 8:53 AM, Vladimir Ivanov wrote: > Thanks, fixed. > > Best regards, > Vladimir Ivanov > > On 10/22/12 19:25, Vladimir Kozlov wrote: >> Vladimir I. >> >> Instead of checking phase->is_IterGVN() you should check can_reshape flag which is used exactly for such purpose. >> >> Thanks, >> Vladimir K. >> >> On Oct 22, 2012, at 8:09 AM, Vladimir Ivanov wrote: >> >>> Updated version: http://cr.openjdk.java.net/~vlivanov/8000805/webrev.01/ >>> >>> Removed changes in AD files and perform transforms during IGVN phase >>> when Load has a single user. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 10/19/12 22:39, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8000805/webrev.00/ >>>> 282 lines changed: 255 ins; 27 del; 0 mod >>>> >>>> Ideal transformations during parsing & IGVN may rematerialize loads in >>>> order to reify useful information (like signed/unsigned load). Such >>>> behavior breaks JMM - instead of a single atomic load, multiple loads >>>> are performed violating consistency of loaded data. >>>> >>>> The fix is to disable such transformations at all, but perform relevant >>>> optimizations during matching. >>>> >>>> It fixes only C2 part of problem. ?1 has similar deficiency, but it'll >>>> be addressed separately. >>>> >>>> Testing: failing test, test for new matching rules, JPRT, CTW (x86, x64 >>>> & sparc). >>>> >>>> Best regards, >>>> Vladimir Ivanov >> From vladimir.x.ivanov at oracle.com Mon Oct 22 09:36:49 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 22 Oct 2012 20:36:49 +0400 Subject: RFR (M): 8000805: JMM issue: short loads are non-atomic In-Reply-To: References: <50819E4C.4090206@oracle.com> <508561A4.2020000@oracle.com> <50856BEA.1020002@oracle.com> Message-ID: <50857621.4090108@oracle.com> Thank you, Chris. Best regards, Vladimir Ivanov On 10/22/12 20:24, Christian Thalinger wrote: > Looks good. > > -- Chris > > On Oct 22, 2012, at 8:53 AM, Vladimir Ivanov wrote: > >> Thanks, fixed. >> >> Best regards, >> Vladimir Ivanov >> >> On 10/22/12 19:25, Vladimir Kozlov wrote: >>> Vladimir I. >>> >>> Instead of checking phase->is_IterGVN() you should check can_reshape flag which is used exactly for such purpose. >>> >>> Thanks, >>> Vladimir K. >>> >>> On Oct 22, 2012, at 8:09 AM, Vladimir Ivanov wrote: >>> >>>> Updated version: http://cr.openjdk.java.net/~vlivanov/8000805/webrev.01/ >>>> >>>> Removed changes in AD files and perform transforms during IGVN phase >>>> when Load has a single user. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 10/19/12 22:39, Vladimir Ivanov wrote: >>>>> http://cr.openjdk.java.net/~vlivanov/8000805/webrev.00/ >>>>> 282 lines changed: 255 ins; 27 del; 0 mod >>>>> >>>>> Ideal transformations during parsing & IGVN may rematerialize loads in >>>>> order to reify useful information (like signed/unsigned load). Such >>>>> behavior breaks JMM - instead of a single atomic load, multiple loads >>>>> are performed violating consistency of loaded data. >>>>> >>>>> The fix is to disable such transformations at all, but perform relevant >>>>> optimizations during matching. >>>>> >>>>> It fixes only C2 part of problem. ?1 has similar deficiency, but it'll >>>>> be addressed separately. >>>>> >>>>> Testing: failing test, test for new matching rules, JPRT, CTW (x86, x64 >>>>> & sparc). >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>> From john.r.rose at oracle.com Mon Oct 22 14:01:53 2012 From: john.r.rose at oracle.com (John Rose) Date: Mon, 22 Oct 2012 14:01:53 -0700 Subject: RFR (M): 8000805: JMM issue: short loads are non-atomic In-Reply-To: <508561A4.2020000@oracle.com> References: <50819E4C.4090206@oracle.com> <508561A4.2020000@oracle.com> Message-ID: That's much better, even though it's a little bit weaker. In the long term, we should think about adding bitwise liveness analysis into the system, instead of using pattern matching. If the live bits out of a LoadB are contained in 0xFF, then we can transform to LoadUB. Doing this would require a type system that can represent per-bit liveness, and an analysis phase that pushes such types backwards through the graph. That is a straightforward extension of our existing type system, augmenting the existing arithmetic range endpoints with corresponding bit masks. Might be a good pet project for someone. ? John On Oct 22, 2012, at 8:09 AM, Vladimir Ivanov wrote: > Updated version: http://cr.openjdk.java.net/~vlivanov/8000805/webrev.01/ > > Removed changes in AD files and perform transforms during IGVN phase > when Load has a single user. From christian.thalinger at oracle.com Mon Oct 22 14:38:12 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 22 Oct 2012 14:38:12 -0700 Subject: How-to implement intrinsic in JVM? In-Reply-To: References: Message-ID: <08E7755F-04C2-45C4-B0FC-354E19316D37@oracle.com> On Oct 18, 2012, at 1:48 AM, james wang wrote: > Hi all, > > Is there any guideline about how to implement new intrinsic (line popcnt, reversebytes, etc.) in JVM? I found a patch about reversebytes(http://cr.openjdk.java.net/~rasbold/reversebytes/webrev.01/), but didn't known the correct steps to accomplish it. There is the changeset that added popcnt support: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c771b7f43bbf Hope that helps. -- Chris > > Thanks! > James From vladimir.kozlov at oracle.com Mon Oct 22 16:11:28 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Mon, 22 Oct 2012 23:11:28 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8000805: JMM issue: short loads are non-atomic Message-ID: <20121022231133.32786474AC@hg.openjdk.java.net> Changeset: 67f4c477c9ab Author: vlivanov Date: 2012-10-22 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/67f4c477c9ab 8000805: JMM issue: short loads are non-atomic Summary: perform transforms during IGVN phase when Load has a single user. Reviewed-by: jrose, kvn, twisti ! src/share/vm/opto/mulnode.cpp + test/compiler/8000805/Test8000805.java From vladimir.kozlov at oracle.com Mon Oct 22 16:13:21 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 22 Oct 2012 16:13:21 -0700 Subject: Request for reviews (M): 8001183: incorrect results of char vectors right shift operaiton Message-ID: <5085D311.7020808@oracle.com> http://cr.openjdk.java.net/~kvn/8001183/webrev In java when small integer values are loaded they are converted to Int with sign extension for byte and short or with zero extension for boolean and char. Any following arithmetic operation may produce result which will not fit into value of the original type. Because of that right shift vector operations produce incorrect result when they operate on not just loaded data. Generate right shift vector operations only if the preceding operation is load. To get correct result of boolean and char vectors arithmetic right shift operation we should use unsigned right shift operation. Disable unsigned right shift for vectors with signed elements (byte, short) in shared code since they are not valid on all platforms. Added new regression tests prepared by Dean Long and me. Thanks, Vladimir From dean.long at oracle.com Mon Oct 22 17:57:07 2012 From: dean.long at oracle.com (Dean Long) Date: Mon, 22 Oct 2012 17:57:07 -0700 Subject: Request for reviews (M): 8001183: incorrect results of char vectors right shift operaiton In-Reply-To: <5085D311.7020808@oracle.com> References: <5085D311.7020808@oracle.com> Message-ID: <5085EB63.2060304@oracle.com> On 10/22/2012 04:13 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8001183/webrev > > In java when small integer values are loaded they are converted to Int > with sign extension for byte and short or with zero extension for > boolean and char. Any following arithmetic operation may produce > result which will not fit into value of the original type. Because of > that right shift vector operations produce incorrect result when they > operate on not just loaded data. > > Generate right shift vector operations only if the preceding operation > is load. > > To get correct result of boolean and char vectors arithmetic right > shift operation we should use unsigned right shift operation. > > Disable unsigned right shift for vectors with signed elements (byte, > short) in shared code since they are not valid on all platforms. > I suppose a port could choose to implement these if it really wanted to by widening to int32 in temporary vectors first, then narrowing again afterwards, but that's a lot of temporary vectors, so it's probably not worth it. But I'm curious: if we wanted to support it, then would it be possible to enable or disable it for each CPU using a predicate that checks the element type? dl > Added new regression tests prepared by Dean Long and me. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Mon Oct 22 18:30:49 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 22 Oct 2012 18:30:49 -0700 Subject: Request for reviews (M): 8001183: incorrect results of char vectors right shift operaiton In-Reply-To: <5085EB63.2060304@oracle.com> References: <5085D311.7020808@oracle.com> <5085EB63.2060304@oracle.com> Message-ID: <5F2A8CDA-5E75-4ADE-9124-A4A25FDA04C7@oracle.com> Unfortunately predicates only work during matching. We need to pass opcode of ideal node to Matcher::match_rule_supported(). Vladimir On Oct 22, 2012, at 5:57 PM, Dean Long wrote: > On 10/22/2012 04:13 PM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8001183/webrev >> >> In java when small integer values are loaded they are converted to Int with sign extension for byte and short or with zero extension for boolean and char. Any following arithmetic operation may produce result which will not fit into value of the original type. Because of that right shift vector operations produce incorrect result when they operate on not just loaded data. >> >> Generate right shift vector operations only if the preceding operation is load. >> >> To get correct result of boolean and char vectors arithmetic right shift operation we should use unsigned right shift operation. >> >> Disable unsigned right shift for vectors with signed elements (byte, short) in shared code since they are not valid on all platforms. >> > I suppose a port could choose to implement these if it really wanted to by widening to int32 in > temporary vectors first, then narrowing again afterwards, but that's a lot of temporary vectors, > so it's probably not worth it. But I'm curious: if we wanted to support it, then would it be possible to > enable or disable it for each CPU using a predicate that checks the element type? > > dl > >> Added new regression tests prepared by Dean Long and me. >> >> Thanks, >> Vladimir > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121022/5f530c30/attachment.html From christian.thalinger at oracle.com Mon Oct 22 19:38:19 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 23 Oct 2012 02:38:19 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8000821: JSR 292: C1 fails to call virtual method (JRUBY-6920) Message-ID: <20121023023824.E98AF474B8@hg.openjdk.java.net> Changeset: fd1d564dd460 Author: twisti Date: 2012-10-22 16:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fd1d564dd460 8000821: JSR 292: C1 fails to call virtual method (JRUBY-6920) Reviewed-by: kvn ! src/share/vm/c1/c1_GraphBuilder.cpp From dean.long at oracle.com Mon Oct 22 22:00:58 2012 From: dean.long at oracle.com (Dean Long) Date: Mon, 22 Oct 2012 22:00:58 -0700 Subject: Request for reviews (M): 8001183: incorrect results of char vectors right shift operaiton In-Reply-To: <5085D311.7020808@oracle.com> References: <5085D311.7020808@oracle.com> Message-ID: <5086248A.2040609@oracle.com> The @summary for the new TestShortVector.java mentions "char" not "short". What is this new short test checking for (I thought the bug was only with "char")? If there is a problem with shorts too, then wouldn't we need a test for bytes as well? dl On 10/22/2012 04:13 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8001183/webrev > > In java when small integer values are loaded they are converted to Int > with sign extension for byte and short or with zero extension for > boolean and char. Any following arithmetic operation may produce > result which will not fit into value of the original type. Because of > that right shift vector operations produce incorrect result when they > operate on not just loaded data. > > Generate right shift vector operations only if the preceding operation > is load. > > To get correct result of boolean and char vectors arithmetic right > shift operation we should use unsigned right shift operation. > > Disable unsigned right shift for vectors with signed elements (byte, > short) in shared code since they are not valid on all platforms. > > Added new regression tests prepared by Dean Long and me. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Mon Oct 22 22:47:20 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 22 Oct 2012 22:47:20 -0700 Subject: Request for reviews (M): 8001183: incorrect results of char vectors right shift operaiton In-Reply-To: <5086248A.2040609@oracle.com> References: <5085D311.7020808@oracle.com> <5086248A.2040609@oracle.com> Message-ID: <4C18D899-7727-415C-9E0E-28A361E1C309@oracle.com> Summary is copy of the bug's Synopsis. I added new shift subtests test_*_add() and test_*_and() into both test files. The show problem when there is arithmetic operation between load and right shift. I will tests for Byte and Boolean. Vladimir On Oct 22, 2012, at 10:00 PM, Dean Long wrote: > The @summary for the new TestShortVector.java mentions "char" not "short". > What is this new short test checking for (I thought the bug was only with "char")? > If there is a problem with shorts too, then wouldn't we need a test for bytes as > well? > > dl > > > On 10/22/2012 04:13 PM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8001183/webrev >> >> In java when small integer values are loaded they are converted to Int with sign extension for byte and short or with zero extension for boolean and char. Any following arithmetic operation may produce result which will not fit into value of the original type. Because of that right shift vector operations produce incorrect result when they operate on not just loaded data. >> >> Generate right shift vector operations only if the preceding operation is load. >> >> To get correct result of boolean and char vectors arithmetic right shift operation we should use unsigned right shift operation. >> >> Disable unsigned right shift for vectors with signed elements (byte, short) in shared code since they are not valid on all platforms. >> >> Added new regression tests prepared by Dean Long and me. >> >> Thanks, >> Vladimir > From vladimir.x.ivanov at oracle.com Tue Oct 23 06:45:20 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 23 Oct 2012 17:45:20 +0400 Subject: RFR (M): 8000805: JMM issue: short loads are non-atomic In-Reply-To: References: <50819E4C.4090206@oracle.com> <508561A4.2020000@oracle.com> Message-ID: <50869F70.2050307@oracle.com> John, Thanks for the review! I filed 8001336 [1] to track the enhancement you are suggesting. If anybody is interested to work on it, feel free to take it. Best regards, Vladimir Ivanov [1] https://jbs.oracle.com/bugs/browse/JDK-8001336 On 10/23/12 01:01, John Rose wrote: > That's much better, even though it's a little bit weaker. > > In the long term, we should think about adding bitwise liveness analysis into the system, instead of using pattern matching. If the live bits out of a LoadB are contained in 0xFF, then we can transform to LoadUB. > > Doing this would require a type system that can represent per-bit liveness, and an analysis phase that pushes such types backwards through the graph. That is a straightforward extension of our existing type system, augmenting the existing arithmetic range endpoints with corresponding bit masks. Might be a good pet project for someone. > > ? John > > On Oct 22, 2012, at 8:09 AM, Vladimir Ivanov wrote: > >> Updated version: http://cr.openjdk.java.net/~vlivanov/8000805/webrev.01/ >> >> Removed changes in AD files and perform transforms during IGVN phase >> when Load has a single user. > From vladimir.kozlov at oracle.com Tue Oct 23 15:24:56 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 23 Oct 2012 22:24:56 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8001183: incorrect results of char vectors right shift operaiton Message-ID: <20121023222501.4AD98474E0@hg.openjdk.java.net> Changeset: b2c669fd8114 Author: kvn Date: 2012-10-23 13:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b2c669fd8114 8001183: incorrect results of char vectors right shift operaiton Summary: do vector right shift operation for small int types only after loads Reviewed-by: jrose, dlong ! src/cpu/x86/vm/x86.ad ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! test/compiler/6340864/TestByteVect.java ! test/compiler/6340864/TestIntVect.java ! test/compiler/6340864/TestLongVect.java ! test/compiler/6340864/TestShortVect.java + test/compiler/8001183/TestCharVect.java From yumin.qi at oracle.com Tue Oct 23 17:04:24 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Tue, 23 Oct 2012 17:04:24 -0700 Subject: RFR: 6830717: replay of compilations would help with debugging In-Reply-To: <73AAAA90-0AFC-4F91-9BBF-A71BC3924735@oracle.com> References: <502039BE.6090108@oracle.com> <73AAAA90-0AFC-4F91-9BBF-A71BC3924735@oracle.com> Message-ID: <50873088.1080904@oracle.com> Hi, Chris and all After permgen removal integration, the previous webrev (see http://cr.openjdk.java.net/~minqi/6830717) need changes according to metadata changes. Thanks for your comments http://cr.openjdk.java.net/~minqi/6830717.01 Thanks Yumin On 8/13/2012 5:02 PM, Christian Thalinger wrote: > On Aug 6, 2012, at 2:40 PM, yumin.qi at oracle.com wrote: > >> Hi, >> >> Please give your comments of the changes about >> 6830717: replay of compilations would help with debugging. >> http://monaco.sfbay.sun.com/detail.jsf?cr=6830717 >> >> Sometime jvm crashes in the process of compilation or in compiled method. To reproduce the compilation process in debug JVM is helpful for quickly identifying root cause. >> To do recompilation, we collect data by using of SA (Serviceability Agent) to extract application and system class data from core file. Those information includes nmethod, methodOop, methodDataOop, instanceKlass and corresponding ci counterparts. >> With reconfiguring similar (not exactly same) compiling environment as in the core file, try to compile again the failed java methods. >> >> contributed by Tom R (never). webrev: >> >> http://cr.openjdk.java.net/~minqi/6830717/ > src/share/vm/ci/ciReplay.cpp: > > 603 if (strcmp(field_signature, "[B") == 0) { > 604 oop value = oopFactory::new_byteArray(length, CHECK); > 605 java_mirror->obj_field_put(fd.offset(), value); > 606 } else if (strcmp(field_signature, "[Z") == 0) { > 607 oop value = oopFactory::new_boolArray(length, CHECK); > 608 java_mirror->obj_field_put(fd.offset(), value); > 609 } else if (strcmp(field_signature, "[C") == 0) { > 610 oop value = oopFactory::new_charArray(length, CHECK); > 611 java_mirror->obj_field_put(fd.offset(), value); > 612 } else if (strcmp(field_signature, "[S") == 0) { > 613 oop value = oopFactory::new_shortArray(length, CHECK); > 614 java_mirror->obj_field_put(fd.offset(), value); > 615 } else if (strcmp(field_signature, "[F") == 0) { > 616 oop value = oopFactory::new_singleArray(length, CHECK); > 617 java_mirror->obj_field_put(fd.offset(), value); > 618 } else if (strcmp(field_signature, "[D") == 0) { > 619 oop value = oopFactory::new_doubleArray(length, CHECK); > 620 java_mirror->obj_field_put(fd.offset(), value); > 621 } else if (strcmp(field_signature, "[I") == 0) { > 622 oop value = oopFactory::new_intArray(length, CHECK); > 623 java_mirror->obj_field_put(fd.offset(), value); > 624 } else if (strcmp(field_signature, "[J") == 0) { > 625 oop value = oopFactory::new_longArray(length, CHECK); > 626 java_mirror->obj_field_put(fd.offset(), value); > 627 } else if (field_signature[0] == '['&& field_signature[1] == 'L') { > > Can't we switch on the second character? And move this call: > > 630 java_mirror->obj_field_put(fd.offset(), value); > > out of the switch? > > 637 if (strcmp(field_signature, "I") == 0) { > 638 int value = atoi(string_value); > 639 java_mirror->int_field_put(fd.offset(), value); > 640 } else if (strcmp(field_signature, "B") == 0) { > 641 int value = atoi(string_value); > 642 java_mirror->byte_field_put(fd.offset(), value); > 643 } else if (strcmp(field_signature, "C") == 0) { > 644 int value = atoi(string_value); > 645 java_mirror->char_field_put(fd.offset(), value); > 646 } else if (strcmp(field_signature, "S") == 0) { > 647 int value = atoi(string_value); > 648 java_mirror->short_field_put(fd.offset(), value); > 649 } else if (strcmp(field_signature, "Z") == 0) { > 650 int value = atol(string_value); > 651 java_mirror->bool_field_put(fd.offset(), value); > 652 } else if (strcmp(field_signature, "J") == 0) { > 653 jlong value; > 654 if (sscanf(string_value, INT64_FORMAT,&value) != 1) { > 655 fprintf(stderr, "Error parsing long: %s\n", string_value); > 656 return; > 657 } > 658 java_mirror->long_field_put(fd.offset(), value); > 659 } else if (strcmp(field_signature, "F") == 0) { > 660 float value = atof(string_value); > 661 java_mirror->float_field_put(fd.offset(), value); > 662 } else if (strcmp(field_signature, "D") == 0) { > 663 double value = atof(string_value); > 664 java_mirror->double_field_put(fd.offset(), value); > 665 } else if (strcmp(field_signature, "Ljava/lang/String;") == 0) { > 666 Handle value = java_lang_String::create_from_str(string_value, CHECK); > 667 java_mirror->obj_field_put(fd.offset(), value()); > 668 } else if (field_signature[0] == 'L') { > > Same here (not the put though)? > > Otherwise it looks good. > > -- Chris > >> Thanks >> Yumin From yumin.qi at oracle.com Wed Oct 24 10:01:14 2012 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Wed, 24 Oct 2012 10:01:14 -0700 Subject: RFR: 8000489: older builds of hsdis don't work anymore after 6879063 Message-ID: <50881EDA.8020100@oracle.com> Hi, all Can I have your codereview of 8000489: older builds of hsdis don't work anymore after 6879063 It caused old build broke the disassembler. Webrev: http://cr.openjdk.java.net/~minqi/8000489 Thanks Yumin From rednaxelafx at gmail.com Wed Oct 24 12:24:54 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 25 Oct 2012 03:24:54 +0800 Subject: RFR: 8000489: older builds of hsdis don't work anymore after 6879063 In-Reply-To: <50881EDA.8020100@oracle.com> References: <50881EDA.8020100@oracle.com> Message-ID: Hi Yumin, minor typos: s/instrurctions/instructions/ By the way, I tried to use a build of hsdis plugin after 6879063 in an earlier JDK build (e.g. JDK8b59) and it was working strangely. A rough look at the output looks like it's missing some newlines, I didn't go into the details. Could you please check if this fix makes the hsdis plugin work properly on earlier JDK builds as well? Thanks, Kris On Thu, Oct 25, 2012 at 1:01 AM, wrote: > Hi, all > > Can I have your codereview of 8000489: older builds of hsdis don't work > anymore after 6879063 > It caused old build broke the disassembler. > > Webrev: http://cr.openjdk.java.net/~**minqi/8000489 > > Thanks > Yumin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121025/68b779df/attachment.html From yumin.qi at oracle.com Wed Oct 24 14:15:35 2012 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Wed, 24 Oct 2012 14:15:35 -0700 Subject: RFR: 8000489: older builds of hsdis don't work anymore after 6879063 In-Reply-To: References: <50881EDA.8020100@oracle.com> Message-ID: <50885A77.5030800@oracle.com> Krystal, Thanks. Updated in same webrev. I checked b10, the output looks OK /Yumin On 10/24/2012 12:24 PM, Krystal Mok wrote: > Hi Yumin, > > minor typos: > s/instrurctions/instructions/ > > By the way, I tried to use a build of hsdis plugin after 6879063 in an > earlier JDK build (e.g. JDK8b59) and it was working strangely. A rough > look at the output looks like it's missing some newlines, I didn't go > into the details. Could you please check if this fix makes the hsdis > plugin work properly on earlier JDK builds as well? > > Thanks, > Kris > > On Thu, Oct 25, 2012 at 1:01 AM, > wrote: > > Hi, all > > Can I have your codereview of 8000489: older builds of hsdis > don't work anymore after 6879063 > It caused old build broke the disassembler. > > Webrev: http://cr.openjdk.java.net/~minqi/8000489 > > > Thanks > Yumin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121024/85f6844f/attachment.html From serguei.spitsyn at oracle.com Wed Oct 24 14:50:21 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 24 Oct 2012 14:50:21 -0700 Subject: RFR: 8000489: older builds of hsdis don't work anymore after 6879063 In-Reply-To: <50885A77.5030800@oracle.com> References: <50881EDA.8020100@oracle.com> <50885A77.5030800@oracle.com> Message-ID: <5088629D.70303@oracle.com> || Yumin, *src/share/tools/hsdis/hsdis.h: * A typo in the comment: 62 /* This is the compatability interface for older version of hotspot */ => 62 /* This is the compatibility interface for older versions of hotspot */ ||*|src|/share/tools/hsdis/hsdis-demo.c:* Would it make sense to change this to avoid using literal name? : 219 printf("Decoding from %p to %p...with decode_instructions_virtual\n", from, to); => 219 printf("Decoding from %p to %p...with %s\n", from, to,DECODE_INSTRUCTIONS_NAME); and 238 printf("Decoding from %p to %p...with old decode_instructions\n", from, to); => 238 printf("Decoding from %p to %p...with old %s\n", from, to,DECODE_INSTRUCTIONS); The (raw && xml) is a special case of the (raw) so that the 4 lines: 225 if (raw && xml) { 226 res = (*decode_instructions_v)(from, to, (unsigned char*)from, to - from, simple_handle_event, stdout, NULL, stdout, options); 227 } else if (raw) { 228 res = (*decode_instructions_v)(from, to, (unsigned char*)from, to - from, simple_handle_event, stdout, NULL, stdout, options); can be replaced with just 2 lines: 225 if (raw) { 226 res = (*decode_instructions_v)(from, to, (unsigned char*)from, to - from, simple_handle_event, stdout, NULL, stdout, options); Thanks, Serguei Thanks, Serguei On 10/24/12 2:15 PM, yumin.qi at oracle.com wrote: > Krystal, > > Thanks. Updated in same webrev. > I checked b10, the output looks OK > > /Yumin > > On 10/24/2012 12:24 PM, Krystal Mok wrote: >> Hi Yumin, >> >> minor typos: >> s/instrurctions/instructions/ >> >> By the way, I tried to use a build of hsdis plugin after 6879063 in >> an earlier JDK build (e.g. JDK8b59) and it was working strangely. A >> rough look at the output looks like it's missing some newlines, I >> didn't go into the details. Could you please check if this fix makes >> the hsdis plugin work properly on earlier JDK builds as well? >> >> Thanks, >> Kris >> >> On Thu, Oct 25, 2012 at 1:01 AM, > > wrote: >> >> Hi, all >> >> Can I have your codereview of 8000489: older builds of hsdis >> don't work anymore after 6879063 >> It caused old build broke the disassembler. >> >> Webrev: http://cr.openjdk.java.net/~minqi/8000489 >> >> >> Thanks >> Yumin >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121024/3ac82a1b/attachment.html From john.r.rose at oracle.com Wed Oct 24 15:27:16 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 24 Oct 2012 15:27:16 -0700 Subject: RFR: 8000489: older builds of hsdis don't work anymore after 6879063 In-Reply-To: <50881EDA.8020100@oracle.com> References: <50881EDA.8020100@oracle.com> Message-ID: On Oct 24, 2012, at 10:01 AM, Yumin.Qi at oracle.com wrote: > Hi, all > > Can I have your codereview of 8000489: older builds of hsdis don't work anymore after 6879063 > It caused old build broke the disassembler. > > Webrev: http://cr.openjdk.java.net/~minqi/8000489 Shouldn't there be a corresponding change to disassembler.cpp? I didn't see it in the webrev. ? John From vladimir.kozlov at oracle.com Wed Oct 24 17:51:22 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 25 Oct 2012 00:51:22 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7184394: add intrinsics to use AES instructions Message-ID: <20121025005124.51EE047528@hg.openjdk.java.net> Changeset: a3ecd773a7b9 Author: kvn Date: 2012-10-24 14:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a3ecd773a7b9 7184394: add intrinsics to use AES instructions Summary: Use new x86 AES instructions for AESCrypt. Reviewed-by: twisti, kvn, roland Contributed-by: tom.deneau at amd.com ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp + test/compiler/7184394/TestAESBase.java + test/compiler/7184394/TestAESDecode.java + test/compiler/7184394/TestAESEncode.java + test/compiler/7184394/TestAESMain.java From yumin.qi at oracle.com Wed Oct 24 21:19:06 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 24 Oct 2012 21:19:06 -0700 Subject: RFR: 8000489: older builds of hsdis don't work anymore after 6879063 In-Reply-To: <5088629D.70303@oracle.com> References: <50881EDA.8020100@oracle.com> <50885A77.5030800@oracle.com> <5088629D.70303@oracle.com> Message-ID: <5088BDBA.6060205@oracle.com> Thanks. Will update with that. Yumin On 10/24/2012 2:50 PM, serguei.spitsyn at oracle.com wrote: > > || Yumin, > > *src/share/tools/hsdis/hsdis.h: > * > > A typo in the comment: > > 62 /* This is the compatability interface for older version of hotspot */ > => > 62 /* This is the compatibility interface for older versions of hotspot */ > > ||*|src|/share/tools/hsdis/hsdis-demo.c:* > > Would it make sense to change this to avoid using literal name? : > > 219 printf("Decoding from %p to %p...with decode_instructions_virtual\n", from, to); > => > 219 printf("Decoding from %p to %p...with %s\n", from, to,DECODE_INSTRUCTIONS_NAME); > > and > > 238 printf("Decoding from %p to %p...with old decode_instructions\n", from, to); > => > 238 printf("Decoding from %p to %p...with old %s\n", from, to,DECODE_INSTRUCTIONS); > > The (raw&& xml) is a special case of the (raw) so that the 4 lines: > > 225 if (raw&& xml) { > 226 res = (*decode_instructions_v)(from, to, (unsigned char*)from, to - from, simple_handle_event, stdout, NULL, stdout, options); > 227 } else if (raw) { > 228 res = (*decode_instructions_v)(from, to, (unsigned char*)from, to - from, simple_handle_event, stdout, NULL, stdout, options); > can be replaced with just 2 lines: > 225 if (raw) { > 226 res = (*decode_instructions_v)(from, to, (unsigned char*)from, to - from, simple_handle_event, stdout, NULL, stdout, options); > > > Thanks, > Serguei > > > > > Thanks, > Serguei > > > On 10/24/12 2:15 PM, yumin.qi at oracle.com wrote: >> Krystal, >> >> Thanks. Updated in same webrev. >> I checked b10, the output looks OK >> >> /Yumin >> >> On 10/24/2012 12:24 PM, Krystal Mok wrote: >>> Hi Yumin, >>> >>> minor typos: >>> s/instrurctions/instructions/ >>> >>> By the way, I tried to use a build of hsdis plugin after 6879063 in >>> an earlier JDK build (e.g. JDK8b59) and it was working strangely. A >>> rough look at the output looks like it's missing some newlines, I >>> didn't go into the details. Could you please check if this fix makes >>> the hsdis plugin work properly on earlier JDK builds as well? >>> >>> Thanks, >>> Kris >>> >>> On Thu, Oct 25, 2012 at 1:01 AM, >> > wrote: >>> >>> Hi, all >>> >>> Can I have your codereview of 8000489: older builds of hsdis >>> don't work anymore after 6879063 >>> It caused old build broke the disassembler. >>> >>> Webrev: http://cr.openjdk.java.net/~minqi/8000489 >>> >>> >>> Thanks >>> Yumin >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121024/7625959e/attachment-0001.html From aleksey.shipilev at oracle.com Thu Oct 25 07:10:07 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 25 Oct 2012 18:10:07 +0400 Subject: hg: hsx/hotspot-comp/hotspot: 7184394: add intrinsics to use AES instructions In-Reply-To: <20121025005124.51EE047528@hg.openjdk.java.net> References: <20121025005124.51EE047528@hg.openjdk.java.net> Message-ID: <5089483F.4040300@oracle.com> Ugh! Interesting stuff, I did a few point runs with this changeset on my 2nd gen i5, doing AES/CBC/PKCS5Padding on encrypting 10K byte[]-s: (1 thread): -XX:-UseAES -XX:-UseAESIntrinsics: 6476.250 +- 27.245 ops/sec -XX:+UseAES -XX:-UseAESIntrinsics: 6430.232 +- 47.573 ops/sec -XX:+UseAES -XX:+UseAESIntrinsics: 34071.202 +- 128.339 ops/sec This sums up to ~350 Mb/sec throughput with intrinsics in single thread. (4 threads): -XX:-UseAES -XX:-UseAESIntrinsics: 9327.480 +- 691.092 ops/sec -XX:+UseAES -XX:-UseAESIntrinsics: 9455.669 +- 1155.928 ops/sec -XX:+UseAES -XX:+UseAESIntrinsics: 117949.368 +- 1213.273 ops/sec This adds up to whooping ~1.2 Gb/sec encryption throughput! It's puzzling however to see the lower scalability boost with baseline cases. The intrinsified version is ~4x faster, even though half of my hardware threads are hyperthreads. -Aleksey. On 10/25/2012 04:51 AM, vladimir.kozlov at oracle.com wrote: > Changeset: a3ecd773a7b9 > Author: kvn > Date: 2012-10-24 14:33 -0700 > URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a3ecd773a7b9 > > 7184394: add intrinsics to use AES instructions > Summary: Use new x86 AES instructions for AESCrypt. > Reviewed-by: twisti, kvn, roland > Contributed-by: tom.deneau at amd.com > > ! src/cpu/x86/vm/assembler_x86.cpp > ! src/cpu/x86/vm/assembler_x86.hpp > ! src/cpu/x86/vm/stubGenerator_x86_32.cpp > ! src/cpu/x86/vm/stubGenerator_x86_64.cpp > ! src/cpu/x86/vm/stubRoutines_x86_32.cpp > ! src/cpu/x86/vm/stubRoutines_x86_32.hpp > ! src/cpu/x86/vm/stubRoutines_x86_64.cpp > ! src/cpu/x86/vm/stubRoutines_x86_64.hpp > ! src/cpu/x86/vm/vm_version_x86.cpp > ! src/cpu/x86/vm/vm_version_x86.hpp > ! src/share/vm/classfile/vmSymbols.hpp > ! src/share/vm/oops/method.cpp > ! src/share/vm/opto/callGenerator.cpp > ! src/share/vm/opto/callGenerator.hpp > ! src/share/vm/opto/doCall.cpp > ! src/share/vm/opto/escape.cpp > ! src/share/vm/opto/library_call.cpp > ! src/share/vm/opto/runtime.cpp > ! src/share/vm/opto/runtime.hpp > ! src/share/vm/runtime/globals.hpp > ! src/share/vm/runtime/stubRoutines.cpp > ! src/share/vm/runtime/stubRoutines.hpp > + test/compiler/7184394/TestAESBase.java > + test/compiler/7184394/TestAESDecode.java > + test/compiler/7184394/TestAESEncode.java > + test/compiler/7184394/TestAESMain.java > From yumin.qi at oracle.com Thu Oct 25 13:16:09 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 25 Oct 2012 13:16:09 -0700 Subject: RFR: 8000489: older builds of hsdis don't work anymore after 6879063 In-Reply-To: References: <50881EDA.8020100@oracle.com> Message-ID: <50899E09.3050905@oracle.com> John, and all I updated the webrev. I also made changes to make 'nice new line" to be a argument of decode_instructions_virtual so it can be changed instead of hard coded as 'false'. To John's question, it doesn't require changes to disassembler.cpp: new version ---> decode_instructions_virtual old version ---> decode_instructions ---> decode_instructions_virtual tested with b01 (JDK8) with new hsdis-i386.so. same location: http://cr.openjdk.java.net/~minqi/8000489 Thanks Yumin On 10/24/2012 3:27 PM, John Rose wrote: > On Oct 24, 2012, at 10:01 AM, Yumin.Qi at oracle.com wrote: > >> Hi, all >> >> Can I have your codereview of 8000489: older builds of hsdis don't work anymore after 6879063 >> It caused old build broke the disassembler. >> >> Webrev: http://cr.openjdk.java.net/~minqi/8000489 > Shouldn't there be a corresponding change to disassembler.cpp? I didn't see it in the webrev. ? John From vladimir.kozlov at oracle.com Thu Oct 25 16:56:10 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 25 Oct 2012 16:56:10 -0700 Subject: Request for reviews (XS): 7163534: VM could crashes assert(false) failed: infinite EA connection graph build Message-ID: <5089D19A.3020707@oracle.com> http://cr.openjdk.java.net/~kvn/7163534/webrev I don't have time to investigate this problem now, but it affects our testing of HS24. So I disabled the assert by default (with new flag). In case of time or iterations limit reached C2 stops EA and continue compilation without EA as it does in product VM already. Thanks, Vladimir From christian.thalinger at oracle.com Thu Oct 25 17:31:19 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 25 Oct 2012 17:31:19 -0700 Subject: Request for reviews (XS): 7163534: VM could crashes assert(false) failed: infinite EA connection graph build In-Reply-To: <5089D19A.3020707@oracle.com> References: <5089D19A.3020707@oracle.com> Message-ID: <9D8B4B6B-68A3-4F6D-88F3-4561A32EFCE0@oracle.com> On Oct 25, 2012, at 4:56 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/7163534/webrev > > I don't have time to investigate this problem now, but it affects our testing of HS24. So I disabled the assert by default (with new flag). In case of time or iterations limit reached C2 stops EA and continue compilation without EA as it does in product VM already. That seems to be the sensible thing to do. Looks good. -- Chris > > Thanks, > Vladimir > From vladimir.kozlov at oracle.com Thu Oct 25 17:38:22 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 25 Oct 2012 17:38:22 -0700 Subject: Request for reviews (XS): 7163534: VM could crashes assert(false) failed: infinite EA connection graph build In-Reply-To: <9D8B4B6B-68A3-4F6D-88F3-4561A32EFCE0@oracle.com> References: <5089D19A.3020707@oracle.com> <9D8B4B6B-68A3-4F6D-88F3-4561A32EFCE0@oracle.com> Message-ID: <5089DB7E.90505@oracle.com> Thanks, Christian Vladimir Christian Thalinger wrote: > On Oct 25, 2012, at 4:56 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/7163534/webrev >> >> I don't have time to investigate this problem now, but it affects our testing of HS24. So I disabled the assert by default (with new flag). In case of time or iterations limit reached C2 stops EA and continue compilation without EA as it does in product VM already. > > That seems to be the sensible thing to do. Looks good. > > -- Chris > >> Thanks, >> Vladimir >> > From john.coomes at oracle.com Thu Oct 25 20:39:23 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 26 Oct 2012 03:39:23 +0000 Subject: hg: hsx/hotspot-comp: 3 new changesets Message-ID: <20121026033923.D0F7F47566@hg.openjdk.java.net> Changeset: c12e759ac4e8 Author: tbell Date: 2012-10-23 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/c12e759ac4e8 7152336: Enable builds on Windows with MinGW/MSYS Summary: Minimal makefile changes to enable building OpenJDK using MSYS on Windows7 Reviewed-by: ohair, tbell Contributed-by: volker.simonis at gmail.com ! README-builds.html + make/scripts/fixpath.pl ! make/scripts/vsvars.sh Changeset: 8a3fe0ae06a8 Author: katleman Date: 2012-10-24 13:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/8a3fe0ae06a8 Merge Changeset: 4e984be114bd Author: katleman Date: 2012-10-25 09:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/4e984be114bd Added tag jdk8-b62 for changeset 8a3fe0ae06a8 ! .hgtags From john.coomes at oracle.com Thu Oct 25 20:39:27 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 26 Oct 2012 03:39:27 +0000 Subject: hg: hsx/hotspot-comp/corba: 3 new changesets Message-ID: <20121026033932.D31AC47567@hg.openjdk.java.net> Changeset: 0a5931be9176 Author: tbell Date: 2012-10-23 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/0a5931be9176 7152336: Enable builds on Windows with MinGW/MSYS Summary: Minimal makefile changes to enable building OpenJDK using MSYS on Windows7 Reviewed-by: ohair, tbell Contributed-by: volker.simonis at gmail.com ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Platform.gmk Changeset: 08afb9c6f44f Author: katleman Date: 2012-10-24 13:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/08afb9c6f44f Merge Changeset: bbaef650c3d2 Author: katleman Date: 2012-10-25 09:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/bbaef650c3d2 Added tag jdk8-b62 for changeset 08afb9c6f44f ! .hgtags From john.coomes at oracle.com Thu Oct 25 20:39:37 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 26 Oct 2012 03:39:37 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b62 for changeset 5d0fa0108d02 Message-ID: <20121026033946.7B0DE47568@hg.openjdk.java.net> Changeset: a96e34e038f5 Author: katleman Date: 2012-10-25 09:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/a96e34e038f5 Added tag jdk8-b62 for changeset 5d0fa0108d02 ! .hgtags From john.coomes at oracle.com Thu Oct 25 20:39:53 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 26 Oct 2012 03:39:53 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b62 for changeset d265b9b4c0f5 Message-ID: <20121026033958.A777B47569@hg.openjdk.java.net> Changeset: c27ea8d489e8 Author: katleman Date: 2012-10-25 09:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/c27ea8d489e8 Added tag jdk8-b62 for changeset d265b9b4c0f5 ! .hgtags From john.coomes at oracle.com Thu Oct 25 20:40:09 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 26 Oct 2012 03:40:09 +0000 Subject: hg: hsx/hotspot-comp/jdk: 5 new changesets Message-ID: <20121026034147.BBCD14756A@hg.openjdk.java.net> Changeset: 61af38b8d4ff Author: twisti Date: 2012-10-19 17:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/61af38b8d4ff 8000989: smaller code changes to make future JSR 292 backports easier Reviewed-by: jrose ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! test/java/lang/invoke/BigArityTest.java ! test/java/lang/invoke/PrivateInvokeTest.java Changeset: 7a7e49acadec Author: kamg Date: 2012-10-22 20:12 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7a7e49acadec 8001225: Disable jdk regression test java/lang/System/Versions.java until jdk's classfile version code is updated Summary: Exclude java/lang/System/Versions.java test Reviewed-by: sspitsyn, coleenp ! test/ProblemList.txt Changeset: a0a2b186ae28 Author: tbell Date: 2012-10-23 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a0a2b186ae28 7152336: Enable builds on Windows with MinGW/MSYS Summary: Minimal makefile changes to enable building OpenJDK using MSYS on Windows7 Reviewed-by: ohair, tbell Contributed-by: volker.simonis at gmail.com ! make/com/sun/java/pack/Makefile ! make/common/Defs-windows.gmk ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/common/Release.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Platform.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/jdk_generic_profile.sh ! make/tools/freetypecheck/Makefile + make/tools/msys_build_scripts/dospath.sh + make/tools/msys_build_scripts/dospath.vbs Changeset: 50b8b17449d2 Author: katleman Date: 2012-10-24 13:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/50b8b17449d2 Merge Changeset: 65d2c6726487 Author: katleman Date: 2012-10-25 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/65d2c6726487 Added tag jdk8-b62 for changeset 50b8b17449d2 ! .hgtags From john.coomes at oracle.com Thu Oct 25 20:42:43 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 26 Oct 2012 03:42:43 +0000 Subject: hg: hsx/hotspot-comp/langtools: Added tag jdk8-b62 for changeset b47bb81ba962 Message-ID: <20121026034251.0BF174756B@hg.openjdk.java.net> Changeset: 16498acd21b5 Author: katleman Date: 2012-10-25 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/16498acd21b5 Added tag jdk8-b62 for changeset b47bb81ba962 ! .hgtags From vladimir.kozlov at oracle.com Fri Oct 26 09:06:16 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 26 Oct 2012 09:06:16 -0700 Subject: Request for reviews (XXS): 8001635: assert(in_bb(n)) failed: must be Message-ID: <508AB4F8.6090901@oracle.com> http://cr.openjdk.java.net/~kvn/8001635/webrev I forgot to add check that Load node is in processed loop block in the fix for 8001183. Thanks, Vladimir From christian.thalinger at oracle.com Fri Oct 26 10:22:11 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 26 Oct 2012 10:22:11 -0700 Subject: Request for reviews (XXS): 8001635: assert(in_bb(n)) failed: must be In-Reply-To: <508AB4F8.6090901@oracle.com> References: <508AB4F8.6090901@oracle.com> Message-ID: <5E11022E-C56F-4EEE-9CF0-E67F1E6959C9@oracle.com> Looks good. -- Chris On Oct 26, 2012, at 9:06 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8001635/webrev > > I forgot to add check that Load node is in processed loop block in the fix for 8001183. > > Thanks, > Vladimir > From vladimir.kozlov at oracle.com Fri Oct 26 10:19:31 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 26 Oct 2012 10:19:31 -0700 Subject: Request for reviews (XXS): 8001635: assert(in_bb(n)) failed: must be In-Reply-To: <5E11022E-C56F-4EEE-9CF0-E67F1E6959C9@oracle.com> References: <508AB4F8.6090901@oracle.com> <5E11022E-C56F-4EEE-9CF0-E67F1E6959C9@oracle.com> Message-ID: <508AC623.3070607@oracle.com> Thanks, Christian Vladimir Christian Thalinger wrote: > Looks good. -- Chris > > On Oct 26, 2012, at 9:06 AM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/8001635/webrev >> >> I forgot to add check that Load node is in processed loop block in the fix for 8001183. >> >> Thanks, >> Vladimir >> > From vladimir.kozlov at oracle.com Fri Oct 26 11:57:55 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 26 Oct 2012 18:57:55 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7163534: VM could crashes assert(false) failed: infinite EA connection graph build Message-ID: <20121026185757.93AFB47599@hg.openjdk.java.net> Changeset: 006174cfe979 Author: kvn Date: 2012-10-25 17:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/006174cfe979 7163534: VM could crashes assert(false) failed: infinite EA connection graph build Summary: In case of time or iterations limit reached C2 stops EA and continue compilation without EA as it does in product VM already. Reviewed-by: twisti ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/escape.cpp From vladimir.kozlov at oracle.com Fri Oct 26 14:02:23 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 26 Oct 2012 21:02:23 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8001635: assert(in_bb(n)) failed: must be Message-ID: <20121026210225.99C3B475A0@hg.openjdk.java.net> Changeset: 410afdc6a07c Author: kvn Date: 2012-10-26 11:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/410afdc6a07c 8001635: assert(in_bb(n)) failed: must be Summary: Added missed check that Load node is in processed loop block. Reviewed-by: twisti ! src/share/vm/opto/superword.cpp From alejandro.murillo at oracle.com Sat Oct 27 03:21:55 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 27 Oct 2012 10:21:55 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 31 new changesets Message-ID: <20121027102311.7CC1147625@hg.openjdk.java.net> Changeset: fcbdaeb69946 Author: katleman Date: 2012-10-18 11:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fcbdaeb69946 Added tag jdk8-b61 for changeset 4547dc71db76 ! .hgtags Changeset: 8a5ea0a9ccc4 Author: johnc Date: 2012-10-06 01:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8a5ea0a9ccc4 7127708: G1: change task num types from int to uint in concurrent mark Summary: Change the type of various task num fields, parameters etc to unsigned and rename them to be more consistent with the other collectors. Code changes were also reviewed by Vitaly Davidovich. Reviewed-by: johnc Contributed-by: Kaushik Srenevasan ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp Changeset: 04155d9c8c76 Author: johnc Date: 2012-10-08 09:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/04155d9c8c76 8000358: G1: metaspace information not printed in PrintHeapAtGC output nor in hs_err file Summary: Missing call to MetaspaceAux::print_on() in G1CollectedHeap::print_on(). Reviewed-by: azeemj, jmasa Contributed-by: Mikael Gerdin ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: dd2b66d09ccd Author: stefank Date: 2012-10-09 22:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dd2b66d09ccd 8000659: NPG: ClassCastExceptions are unexpectedly thrown when testing nashorn Summary: Treat the oops in invoke_method_table() as strong roots when ClassUnloading is enabled. Reviewed-by: kamg, coleenp ! src/share/vm/classfile/systemDictionary.cpp Changeset: 4202510ee0fe Author: johnc Date: 2012-10-15 10:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4202510ee0fe 8000831: Heap verification output incorrect/incomplete Summary: Restore non-silent output of heap verification. Reviewed-by: ysr, brutisso, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/utilities/debug.cpp Changeset: 633ba56cb013 Author: jmasa Date: 2012-10-17 13:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/633ba56cb013 Merge ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/memory/universe.hpp Changeset: bdb5f8c9978b Author: coleenp Date: 2012-10-10 17:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bdb5f8c9978b 7199068: NPG: SharedSkipVerify is meaningless Summary: Remove the SharedSkipVerify flag Reviewed-by: kamg, sspitsyn, coleenp Contributed-by: harold.seigel at oracle.com ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp Changeset: 48a75d2640a5 Author: kamg Date: 2012-10-11 14:27 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/48a75d2640a5 7054345: Support version 52.0 class file in HotSpot Summary: Accept classfiles with major version 52 Reviewed-by: coleenp, acorn ! src/share/vm/classfile/classFileParser.cpp Changeset: e0ea0e94c23c Author: kevinw Date: 2012-10-15 16:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e0ea0e94c23c 7195151: Multiplatform tescase for 6929067 Reviewed-by: kamg, kvn ! test/runtime/6929067/Test6929067.sh Changeset: e52361627b65 Author: coleenp Date: 2012-10-15 22:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e52361627b65 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/globals.hpp Changeset: 045cb62046a7 Author: rbackman Date: 2012-08-28 15:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/045cb62046a7 7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives Reviewed-by: dholmes, dcubed ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 7b5885dadbdc Author: nloodin Date: 2012-10-17 17:36 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7b5885dadbdc 8000617: It should be possible to allocate memory without the VM dying. Reviewed-by: coleenp, kamg ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/resourceArea.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: e8c79c2ba3f3 Author: coleenp Date: 2012-10-18 12:29 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e8c79c2ba3f3 Merge Changeset: d0337c31c8be Author: amurillo Date: 2012-10-19 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d0337c31c8be Merge Changeset: dccd40de8db1 Author: amurillo Date: 2012-10-19 11:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dccd40de8db1 Added tag hs25-b06 for changeset d0337c31c8be ! .hgtags Changeset: 556dd9e475c6 Author: katleman Date: 2012-10-25 09:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/556dd9e475c6 Added tag jdk8-b62 for changeset dccd40de8db1 ! .hgtags Changeset: d0e7716b179e Author: amurillo Date: 2012-10-19 11:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d0e7716b179e 8001176: new hotspot build - hs25-b07 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 85916677fc22 Author: coleenp Date: 2012-10-18 13:08 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/85916677fc22 7188233: UseVMInterruptibleIO flag deprecate for JDK8 Summary: The -XX:+UseVMInterruptibleIO flag is deprecated for JDK8. The flag will still enable Interruptible IO on Solaris, but users will get a warning. Reviewed-by: dholmes, acorn, alanb Contributed-by: harold.seigel at oracle.com ! src/share/vm/runtime/arguments.cpp Changeset: 8ebcedb7604d Author: coleenp Date: 2012-10-18 13:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8ebcedb7604d 7053130: hs_err file does not record specified CLASSPATH Summary: Added code to write the value of the java.class.path property to the hs_err file. Reviewed-by: kmo, dholmes, kvn Contributed-by: harold.seigel at oracle.com ! src/share/vm/runtime/arguments.cpp Changeset: c7957b458bf8 Author: minqi Date: 2012-10-19 08:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c7957b458bf8 8000818: SA constant pool need to reference to reference map after permgen removal Summary: After permgen removal, constant pool changed to put _ldc and _ldc_w (fast_ldc and fast_ldcw) index to reference map, no longer calculated via constant pool cache. Reviewed-by: coleenp, sspitsyn, dholmes Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java Changeset: 8eeffbc22f10 Author: minqi Date: 2012-10-19 08:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8eeffbc22f10 8001055: Bytes.swap should follow big endian Summary: This is a mistake change in 6879063 about Bytes.swap. Java byte code order always follows big endian, but in that change, assume they follow native platform order that is not right. Reviewed-by: coleenp, sspitsyn, dholmes Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/runtime/Bytes.java Changeset: 716c64bda5ba Author: zgu Date: 2012-10-19 21:40 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/716c64bda5ba 7199092: NMT: NMT needs to deal overlapped virtual memory ranges Summary: Enhanced virtual memory tracking to track committed regions as well as reserved regions, so NMT now can generate virtual memory map. Reviewed-by: acorn, coleenp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memBaseline.hpp ! src/share/vm/services/memPtr.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memReporter.cpp ! src/share/vm/services/memReporter.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: b988bff99b38 Author: zgu Date: 2012-10-19 18:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b988bff99b38 Merge Changeset: 80f44792c0c9 Author: coleenp Date: 2012-10-22 12:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/80f44792c0c9 Merge Changeset: 685df3c6f84b Author: jmasa Date: 2012-09-18 23:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/685df3c6f84b 7045397: NPG: Add freelists to class loader arenas. Reviewed-by: coleenp, stefank, jprovino, ohair ! make/excludeSrc.make + src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp + src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeBlockDictionary.hpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/freeList.hpp + src/share/vm/memory/metablock.hpp + src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 476718ea6759 Author: jmasa Date: 2012-10-25 12:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/476718ea6759 8001584: NPG: Incorrect assertion in BinaryTreeDictionary::get_chunk() Reviewed-by: johnc, tamao ! src/share/vm/memory/binaryTreeDictionary.hpp Changeset: b58313cf9afd Author: jcoomes Date: 2012-10-26 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b58313cf9afd Merge Changeset: 588f08ed16cf Author: kvn Date: 2012-10-26 12:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/588f08ed16cf Merge ! src/share/vm/runtime/globals.hpp Changeset: dc16fe422c53 Author: amurillo Date: 2012-10-26 14:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dc16fe422c53 Merge Changeset: 57c61f87a1fd Author: amurillo Date: 2012-10-26 14:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/57c61f87a1fd Added tag hs25-b07 for changeset dc16fe422c53 ! .hgtags Changeset: a516debe2cee Author: amurillo Date: 2012-10-26 14:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a516debe2cee 8001663: new hotspot build - hs25-b08 Reviewed-by: jcoomes ! make/hotspot_version From yumin.qi at oracle.com Mon Oct 29 09:19:12 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 29 Oct 2012 09:19:12 -0700 Subject: RFR: 8000489: older builds of hsdis don't work anymore after 6879063 In-Reply-To: <5088629D.70303@oracle.com> References: <50881EDA.8020100@oracle.com> <50885A77.5030800@oracle.com> <5088629D.70303@oracle.com> Message-ID: <508EAC80.2060000@oracle.com> Serguei and Krys If you are OK with the second version, I will do integration into hotspot_rt. http://cr.openjdk.java.net/~minqi/8000489 Thanks Yumin On 10/24/2012 2:50 PM, serguei.spitsyn at oracle.com wrote: > > || Yumin, > > *src/share/tools/hsdis/hsdis.h: > * > > A typo in the comment: > > 62 /* This is the compatability interface for older version of hotspot */ > => > 62 /* This is the compatibility interface for older versions of hotspot */ > > ||*|src|/share/tools/hsdis/hsdis-demo.c:* > > Would it make sense to change this to avoid using literal name? : > > 219 printf("Decoding from %p to %p...with decode_instructions_virtual\n", from, to); > => > 219 printf("Decoding from %p to %p...with %s\n", from, to,DECODE_INSTRUCTIONS_NAME); > > and > > 238 printf("Decoding from %p to %p...with old decode_instructions\n", from, to); > => > 238 printf("Decoding from %p to %p...with old %s\n", from, to,DECODE_INSTRUCTIONS); > > The (raw&& xml) is a special case of the (raw) so that the 4 lines: > > 225 if (raw&& xml) { > 226 res = (*decode_instructions_v)(from, to, (unsigned char*)from, to - from, simple_handle_event, stdout, NULL, stdout, options); > 227 } else if (raw) { > 228 res = (*decode_instructions_v)(from, to, (unsigned char*)from, to - from, simple_handle_event, stdout, NULL, stdout, options); > can be replaced with just 2 lines: > 225 if (raw) { > 226 res = (*decode_instructions_v)(from, to, (unsigned char*)from, to - from, simple_handle_event, stdout, NULL, stdout, options); > > > Thanks, > Serguei > > > > > Thanks, > Serguei > > > On 10/24/12 2:15 PM, yumin.qi at oracle.com wrote: >> Krystal, >> >> Thanks. Updated in same webrev. >> I checked b10, the output looks OK >> >> /Yumin >> >> On 10/24/2012 12:24 PM, Krystal Mok wrote: >>> Hi Yumin, >>> >>> minor typos: >>> s/instrurctions/instructions/ >>> >>> By the way, I tried to use a build of hsdis plugin after 6879063 in >>> an earlier JDK build (e.g. JDK8b59) and it was working strangely. A >>> rough look at the output looks like it's missing some newlines, I >>> didn't go into the details. Could you please check if this fix makes >>> the hsdis plugin work properly on earlier JDK builds as well? >>> >>> Thanks, >>> Kris >>> >>> On Thu, Oct 25, 2012 at 1:01 AM, >> > wrote: >>> >>> Hi, all >>> >>> Can I have your codereview of 8000489: older builds of hsdis >>> don't work anymore after 6879063 >>> It caused old build broke the disassembler. >>> >>> Webrev: http://cr.openjdk.java.net/~minqi/8000489 >>> >>> >>> Thanks >>> Yumin >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121029/96de60b4/attachment.html From serguei.spitsyn at oracle.com Mon Oct 29 09:36:43 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 29 Oct 2012 09:36:43 -0700 Subject: RFR: 8000489: older builds of hsdis don't work anymore after 6879063 In-Reply-To: <508EAC80.2060000@oracle.com> References: <50881EDA.8020100@oracle.com> <50885A77.5030800@oracle.com> <5088629D.70303@oracle.com> <508EAC80.2060000@oracle.com> Message-ID: <508EB09B.7080508@oracle.com> Looks good. Thanks, Serguei On 10/29/12 9:19 AM, Yumin Qi wrote: > Serguei and Krys > > If you are OK with the second version, I will do integration into > hotspot_rt. > http://cr.openjdk.java.net/~minqi/8000489 > > Thanks > Yumin > > On 10/24/2012 2:50 PM, serguei.spitsyn at oracle.com wrote: >> >> || Yumin, >> >> *src/share/tools/hsdis/hsdis.h: >> * >> >> A typo in the comment: >> >> 62 /* This is the compatability interface for older version of hotspot */ >> => >> 62 /* This is the compatibility interface for older versions of hotspot */ >> >> ||*|src|/share/tools/hsdis/hsdis-demo.c:* >> >> Would it make sense to change this to avoid using literal name? : >> >> 219 printf("Decoding from %p to %p...with decode_instructions_virtual\n", from, to); >> => >> 219 printf("Decoding from %p to %p...with %s\n", from, to,DECODE_INSTRUCTIONS_NAME); >> >> and >> >> 238 printf("Decoding from %p to %p...with old decode_instructions\n", from, to); >> => >> 238 printf("Decoding from %p to %p...with old %s\n", from, to,DECODE_INSTRUCTIONS); >> >> The (raw && xml) is a special case of the (raw) so that the 4 lines: >> >> 225 if (raw && xml) { >> 226 res = (*decode_instructions_v)(from, to, (unsigned char*)from, to - from, simple_handle_event, stdout, NULL, stdout, options); >> 227 } else if (raw) { >> 228 res = (*decode_instructions_v)(from, to, (unsigned char*)from, to - from, simple_handle_event, stdout, NULL, stdout, options); >> can be replaced with just 2 lines: >> 225 if (raw) { >> 226 res = (*decode_instructions_v)(from, to, (unsigned char*)from, to - from, simple_handle_event, stdout, NULL, stdout, options); >> >> >> Thanks, >> Serguei >> >> >> >> >> Thanks, >> Serguei >> >> >> On 10/24/12 2:15 PM, yumin.qi at oracle.com wrote: >>> Krystal, >>> >>> Thanks. Updated in same webrev. >>> I checked b10, the output looks OK >>> >>> /Yumin >>> >>> On 10/24/2012 12:24 PM, Krystal Mok wrote: >>>> Hi Yumin, >>>> >>>> minor typos: >>>> s/instrurctions/instructions/ >>>> >>>> By the way, I tried to use a build of hsdis plugin after 6879063 in >>>> an earlier JDK build (e.g. JDK8b59) and it was working strangely. A >>>> rough look at the output looks like it's missing some newlines, I >>>> didn't go into the details. Could you please check if this fix >>>> makes the hsdis plugin work properly on earlier JDK builds as well? >>>> >>>> Thanks, >>>> Kris >>>> >>>> On Thu, Oct 25, 2012 at 1:01 AM, >>> > wrote: >>>> >>>> Hi, all >>>> >>>> Can I have your codereview of 8000489: older builds of hsdis >>>> don't work anymore after 6879063 >>>> It caused old build broke the disassembler. >>>> >>>> Webrev: http://cr.openjdk.java.net/~minqi/8000489 >>>> >>>> >>>> Thanks >>>> Yumin >>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121029/13baef2c/attachment.html From john.r.rose at oracle.com Mon Oct 29 09:57:15 2012 From: john.r.rose at oracle.com (John Rose) Date: Mon, 29 Oct 2012 09:57:15 -0700 Subject: RFR: 8000489: older builds of hsdis don't work anymore after 6879063 In-Reply-To: <50899E09.3050905@oracle.com> References: <50881EDA.8020100@oracle.com> <50899E09.3050905@oracle.com> Message-ID: <5B1D00DA-989D-4747-8A78-37269D08C722@oracle.com> On Oct 25, 2012, at 1:16 PM, Yumin Qi wrote: > To John's question, it doesn't require changes to disassembler.cpp: > > new version ---> decode_instructions_virtual > old version ---> decode_instructions ---> decode_instructions_virtual > > tested with b01 (JDK8) with new hsdis-i386.so. I think we are aiming to make all four combinations work: {old JVM , new JVM} x { old hsdis , new hsdis }. For this to work, there must be "tolerance" in both the JVM and hsdis for old code. That's why I was looking for a change to disassembler.cpp, so that old hsdis modules will still work. In particular, the older builds of hsdis won't work properly unless the new JVM looks for the old hsdis entry point (if it fails to find the new hsdis entry point, of course). Basically, I am expecting that if the new JVM fails to find hsdis`decode_instructions_virtual, it will look for hsdis`decode_instructions instead, and will call that latter function with the (fewer) arguments that it expected. Am I missing something here? ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121029/82d7af3e/attachment-0001.html From yumin.qi at oracle.com Mon Oct 29 10:35:09 2012 From: yumin.qi at oracle.com (Yumin Qi) Date: Mon, 29 Oct 2012 10:35:09 -0700 Subject: RFR: 8000489: older builds of hsdis don't work anymore after 6879063 In-Reply-To: <5B1D00DA-989D-4747-8A78-37269D08C722@oracle.com> References: <50881EDA.8020100@oracle.com> <50899E09.3050905@oracle.com> <5B1D00DA-989D-4747-8A78-37269D08C722@oracle.com> Message-ID: <508EBE4D.9050903@oracle.com> John, I haven't considered new JVM work with old hsdis. Will change disassemble.cpp to check: first decode_instructions_virtual exists, use it. If not, next check if decode_instructions exists, then use it. As you expected, it will look like / new hsdis -> decode_instructions -> decode_instructions_virtual old VM \ old hsdis -> decode_instructions / new hsdis -> decode_instructions_virtual new VM \ old hsdis -> decode_instructions Thanks Yumin On 10/29/2012 9:57 AM, John Rose wrote: > On Oct 25, 2012, at 1:16 PM, Yumin Qi wrote: > >> To John's question, it doesn't require changes to disassembler.cpp: >> >> new version ---> decode_instructions_virtual >> old version ---> decode_instructions ---> decode_instructions_virtual >> >> tested with b01 (JDK8) with new hsdis-i386.so. > > I think we are aiming to make all four combinations work: {old JVM , > new JVM} x { old hsdis , new hsdis }. > > For this to work, there must be "tolerance" in both the JVM and hsdis > for old code. That's why I was looking for a change to > disassembler.cpp, so that old hsdis modules will still work. > > In particular, the older builds of hsdis won't work properly unless > the new JVM looks for the old hsdis entry point (if it fails to find > the new hsdis entry point, of course). > > Basically, I am expecting that if the new JVM fails to find > hsdis`decode_instructions_virtual, it will look for > hsdis`decode_instructions instead, and will call that latter function > with the (fewer) arguments that it expected. > > Am I missing something here? > > ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121029/ab018a2e/attachment.html From john.r.rose at oracle.com Mon Oct 29 10:47:34 2012 From: john.r.rose at oracle.com (John Rose) Date: Mon, 29 Oct 2012 10:47:34 -0700 Subject: RFR: 8000489: older builds of hsdis don't work anymore after 6879063 In-Reply-To: <508EBE4D.9050903@oracle.com> References: <50881EDA.8020100@oracle.com> <50899E09.3050905@oracle.com> <5B1D00DA-989D-4747-8A78-37269D08C722@oracle.com> <508EBE4D.9050903@oracle.com> Message-ID: On Oct 29, 2012, at 10:35 AM, Yumin Qi wrote: > I haven't considered new JVM work with old hsdis. Will change disassemble.cpp to check: Perfect! Thanks, ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121029/a232cb22/attachment.html From christian.thalinger at oracle.com Mon Oct 29 10:56:02 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 29 Oct 2012 10:56:02 -0700 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> Message-ID: <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> [This should be over at hotspot-comp-dev since it only touches C2 code. BCC'ing hotspot-dev.] On Oct 29, 2012, at 10:29 AM, Vladimir Kozlov wrote: > Bharadwaj, > > These changes look much better. Sorry, I suggested to add verify_live_node_count() method before but your current code don't need it, just use count_live_nodes_by_graph_walk(). An other note: without LogCompilation verification code should produce some info on tty. > > Thanks, > Vladimir > > On Oct 28, 2012, at 8:12 PM, Bharadwaj Yadavalli wrote: > >> I'd like to get a code review of the changes at http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_01/ >> >> These changes are made to keep an (almost) accurate running count of the reachable (live) flow graph nodes. This will result in a more realistic node count for various phases of C2 to decide on whether to proceed with optimizations or not. Prior to these changes, C2 bails out of compilation based on the number of nodes created which typically larger than the number of reachable (live) nodes. >> >> I observed no significant degradation in C2 compilation time of all classes in rt.jar time due to these changes. We still need to adjust MaxNodeLimit. Maybe some JRuby or Nashorn benchmarks can help in getting really big methods. src/share/vm/opto/compile.cpp: + _log->elem("node count before optimize compile_id='%d' unique='%d' live (tracked)='%d' live(graph_walk)='%d'", I think the log element name needs to have _'s so we can match it (if we want to): + _log->elem("node_count_before_optimize compile_id='%d' unique='%d' live (tracked)='%d' live(graph_walk)='%d'", -- Chris >> >> Thanks, >> >> Bharadwaj >> > From krystal.mo at oracle.com Mon Oct 29 10:55:15 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Tue, 30 Oct 2012 01:55:15 +0800 Subject: RFR: 8000489: older builds of hsdis don't work anymore after 6879063 In-Reply-To: <508EAC80.2060000@oracle.com> References: <50881EDA.8020100@oracle.com> <50885A77.5030800@oracle.com> <5088629D.70303@oracle.com> <508EAC80.2060000@oracle.com> Message-ID: <508EC303.4020709@oracle.com> Hi Yumin, I ran PrintInterpreter on JDK7u5, JDK7u9 and JDK8b59 on Ubuntu 12.04/AMD64 and it looked weird: the newline at the end of each disassembly block seems missing. Am I missing something? I'm sure the new build is fresh, just made a fresh clone from hsx/hotspot-rt and applied your patch to make the build. I've uploaded the output I'm seeing with old/new hsdis on JDK7u5 and JDK8b59 here for reference: https://gist.github.com/3975216 And, I agree with John that all 4 combinations should work. A nitpick: There seems to be inconsistent usage of booleans in this change, and in the original hsdis. Could you make it more consistent? Side note: Using the int type for the new_line argument is good to me. Using bool instead might cause some weird issues crossing the C and C++ boundary. hsdis.c: line 113 and 135: Lower-cased true/false is used here line 529, init_disassemble_info_from_bfd() Capitalized FALSE is used here P.S. Running "make all" used to work out-of-the-box for me on AMD64, but now I have to specify LP64=1 to make it work. Is this expected? Thanks, Kris On 10/30/2012 12:19 AM, Yumin Qi wrote: > Serguei and Krys > > If you are OK with the second version, I will do integration into > hotspot_rt. > http://cr.openjdk.java.net/~minqi/8000489 > > Thanks > Yumin > > On 10/24/2012 2:50 PM, serguei.spitsyn at oracle.com wrote: >> >> || Yumin, >> >> *src/share/tools/hsdis/hsdis.h: >> * >> >> A typo in the comment: >> >> 62 /* This is the compatability interface for older version of hotspot */ >> => >> 62 /* This is the compatibility interface for older versions of hotspot */ >> >> ||*|src|/share/tools/hsdis/hsdis-demo.c:* >> >> Would it make sense to change this to avoid using literal name? : >> >> 219 printf("Decoding from %p to %p...with decode_instructions_virtual\n", from, to); >> => >> 219 printf("Decoding from %p to %p...with %s\n", from, to,DECODE_INSTRUCTIONS_NAME); >> >> and >> >> 238 printf("Decoding from %p to %p...with old decode_instructions\n", from, to); >> => >> 238 printf("Decoding from %p to %p...with old %s\n", from, to,DECODE_INSTRUCTIONS); >> >> The (raw && xml) is a special case of the (raw) so that the 4 lines: >> >> 225 if (raw && xml) { >> 226 res = (*decode_instructions_v)(from, to, (unsigned char*)from, to - from, simple_handle_event, stdout, NULL, stdout, options); >> 227 } else if (raw) { >> 228 res = (*decode_instructions_v)(from, to, (unsigned char*)from, to - from, simple_handle_event, stdout, NULL, stdout, options); >> can be replaced with just 2 lines: >> 225 if (raw) { >> 226 res = (*decode_instructions_v)(from, to, (unsigned char*)from, to - from, simple_handle_event, stdout, NULL, stdout, options); >> >> >> Thanks, >> Serguei >> >> >> >> >> Thanks, >> Serguei >> >> >> On 10/24/12 2:15 PM, yumin.qi at oracle.com wrote: >>> Krystal, >>> >>> Thanks. Updated in same webrev. >>> I checked b10, the output looks OK >>> >>> /Yumin >>> >>> On 10/24/2012 12:24 PM, Krystal Mok wrote: >>>> Hi Yumin, >>>> >>>> minor typos: >>>> s/instrurctions/instructions/ >>>> >>>> By the way, I tried to use a build of hsdis plugin after 6879063 in >>>> an earlier JDK build (e.g. JDK8b59) and it was working strangely. A >>>> rough look at the output looks like it's missing some newlines, I >>>> didn't go into the details. Could you please check if this fix >>>> makes the hsdis plugin work properly on earlier JDK builds as well? >>>> >>>> Thanks, >>>> Kris >>>> >>>> On Thu, Oct 25, 2012 at 1:01 AM, >>> > wrote: >>>> >>>> Hi, all >>>> >>>> Can I have your codereview of 8000489: older builds of hsdis >>>> don't work anymore after 6879063 >>>> It caused old build broke the disassembler. >>>> >>>> Webrev: http://cr.openjdk.java.net/~minqi/8000489 >>>> >>>> >>>> Thanks >>>> Yumin >>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121030/8baf5cbf/attachment-0001.html From bharadwaj.yadavalli at oracle.com Mon Oct 29 12:08:53 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Mon, 29 Oct 2012 15:08:53 -0400 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> Message-ID: <508ED445.3090401@oracle.com> Thanks for your reviews, Vladimir and Christian. On Oct 29, 2012, at 10:29 AM, Vladimir Kozlov wrote: >> Bharadwaj, >> >> These changes look much better. Sorry, I suggested to add verify_live_node_count() method before but your current code don't need it, just use count_live_nodes_by_graph_walk(). OK. Made the necessary changes. >> An other note: without LogCompilation verification code should produce some info on tty. OK. We do not need to print the information about the number of unique nodes created, those that are live and those that are dead to the tty, correct? (Ref. around line 777 and line 816 in compile.cpp) That leaves us with the message when there is a mismatch between the live node count arrived at by flow-graph walk and that kept track of via deal_node_list. Would you suggest that I print out to tty indicating a mismatch? (Ref. around line 819 in compile.cpp) A mismatch may not always indicate that something is indeed wrong - given that some constant nodes that become unreachable (dead) can later become reachable, for example, due to final_graph_reshaping_walk(). Hence I do not count constant nodes that become unreachable as dead. So printing out a message on the tty might trigger false alarms. So, I chose to print a message in the log file only. Please let me know if you still think that I should print this info (the one around line 819 in compile.cpp) to tty. On 10/29/2012 1:56 PM, Christian Thalinger wrote: > We still need to adjust MaxNodeLimit. Maybe some JRuby or Nashorn benchmarks can help in getting really big methods. I agree. However, I felt that arriving at the MaxNodeLimit might need some experimentation with different applications whose method compilations result in creation of graphs with large number of nodes. I do not (yet) know how the current value was arrived at. It appears to me that leaving the current value unchanged in light of these proposed changes would not adversely affect normal applications. So, I thought we could check in these changes and later check in a change to MaxNodeLimit based on a detailed experimentation. What do you think? > src/share/vm/opto/compile.cpp: > > + _log->elem("node count before optimize compile_id='%d' unique='%d' live (tracked)='%d' live(graph_walk)='%d'", > > I think the log element name needs to have _'s so we can match it (if we want to): > > + _log->elem("node_count_before_optimize compile_id='%d' unique='%d' live (tracked)='%d' live(graph_walk)='%d'", OK. Changed. Thanks, Bharadwaj From john.r.rose at oracle.com Mon Oct 29 12:22:13 2012 From: john.r.rose at oracle.com (John Rose) Date: Mon, 29 Oct 2012 12:22:13 -0700 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> Message-ID: <75A7BD85-9AF3-4126-97E1-8298DB4277B6@oracle.com> On Oct 29, 2012, at 10:56 AM, Christian Thalinger wrote: > src/share/vm/opto/compile.cpp: > > + _log->elem("node count before optimize compile_id='%d' unique='%d' live (tracked)='%d' live(graph_walk)='%d'", Actually, that will emit invalid XML, even if the underscores are added: Not only are "count" and "before" bad attribute specifiers, but "live (tracked)='44'" is also. I suppose live(graph_walk)='22' is accidentally correct, but I wouldn't wish it on an XML parser. It might be worthwhile putting a debug-only validator of some sort to catch simple mistakes like this. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121029/a5c516a8/attachment.html From vladimir.kozlov at oracle.com Mon Oct 29 13:01:56 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 29 Oct 2012 13:01:56 -0700 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <508ED445.3090401@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> Message-ID: <508EE0B4.6010402@oracle.com> I forgot to tell that VerifyIdealNodeCount flag should be defined in c2_globals.hpp since it is C2 specific flag. Also how you handle Node::destruct() mathod which may allow to reuse _idx? The rest comments are inlined below. Bharadwaj Yadavalli wrote: > > Thanks for your reviews, Vladimir and Christian. > > On Oct 29, 2012, at 10:29 AM, Vladimir Kozlov > wrote: >>> Bharadwaj, >>> >>> These changes look much better. Sorry, I suggested to add >>> verify_live_node_count() method before but your current code don't >>> need it, just use count_live_nodes_by_graph_walk(). > > OK. Made the necessary changes. > >>> An other note: without LogCompilation verification code should >>> produce some info on tty. > > OK. We do not need to print the information about the number of unique > nodes created, those that are live and those that are dead to the tty, > correct? (Ref. around line 777 and line 816 in compile.cpp) It is useful information when you try to diagnose node limit bailouts. You can add new debug flag PrintIdealNodeCount to output this info to tty. > > That leaves us with the message when there is a mismatch between the > live node count arrived at by flow-graph walk and that kept track of via > deal_node_list. > > Would you suggest that I print out to tty indicating a mismatch? (Ref. > around line 819 in compile.cpp) A mismatch may not always indicate that > something is indeed wrong - given that some constant nodes that become > unreachable (dead) can later become reachable, for example, due to > final_graph_reshaping_walk(). Hence I do not count constant nodes that > become unreachable as dead. So printing out a message on the tty might > trigger false alarms. So, I chose to print a message in the log file only. -XX:+VerifyIdealNodeCount is our internal flag and we would expect these messages to be not accurate. > > Please let me know if you still think that I should print this info (the > one around line 819 in compile.cpp) to tty. Yes, also you need to dump nodes when output is tty instead of printing their idx: useful.at(i)->dump(); Thanks, Vladimir > > On 10/29/2012 1:56 PM, Christian Thalinger wrote: >> We still need to adjust MaxNodeLimit. Maybe some JRuby or Nashorn >> benchmarks can help in getting really big methods. > > I agree. However, I felt that arriving at the MaxNodeLimit might need > some experimentation with different applications whose method > compilations result in creation of graphs with large number of nodes. I > do not (yet) know how the current value was arrived at. It appears to me > that leaving the current value unchanged in light of these proposed > changes would not adversely affect normal applications. So, I thought we > could check in these changes and later check in a change to MaxNodeLimit > based on a detailed experimentation. What do you think? > >> src/share/vm/opto/compile.cpp: >> >> + _log->elem("node count before optimize compile_id='%d' >> unique='%d' live (tracked)='%d' live(graph_walk)='%d'", >> >> I think the log element name needs to have _'s so we can match it (if >> we want to): >> >> + _log->elem("node_count_before_optimize compile_id='%d' >> unique='%d' live (tracked)='%d' live(graph_walk)='%d'", > > OK. Changed. > > Thanks, > > Bharadwaj > From christian.thalinger at oracle.com Mon Oct 29 13:09:51 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Mon, 29 Oct 2012 20:09:51 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8000780: make Zero build and run with JDK8 Message-ID: <20121029200956.03CD547657@hg.openjdk.java.net> Changeset: a3e2f723f2a5 Author: twisti Date: 2012-10-29 11:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a3e2f723f2a5 8000780: make Zero build and run with JDK8 Reviewed-by: coleenp, dholmes, twisti Contributed-by: Roman Kennke ! make/Makefile ! src/cpu/zero/vm/cppInterpreterGenerator_zero.hpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/icBuffer_zero.cpp ! src/cpu/zero/vm/methodHandles_zero.cpp ! src/cpu/zero/vm/methodHandles_zero.hpp ! src/cpu/zero/vm/register_zero.hpp ! src/cpu/zero/vm/relocInfo_zero.cpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/cppInterpreter.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/macros.hpp From vladimir.kozlov at oracle.com Mon Oct 29 13:11:22 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 29 Oct 2012 13:11:22 -0700 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <508EE0B4.6010402@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508EE0B4.6010402@oracle.com> Message-ID: <508EE2EA.2070100@oracle.com> And use consistent codding style for "if ()" and "for ()" - space before () and no space inside (): "for (uint". Vladimir Vladimir Kozlov wrote: > I forgot to tell that VerifyIdealNodeCount flag should be defined in > c2_globals.hpp since it is C2 specific flag. > > Also how you handle Node::destruct() mathod which may allow to reuse _idx? > > The rest comments are inlined below. > > Bharadwaj Yadavalli wrote: >> >> Thanks for your reviews, Vladimir and Christian. >> >> On Oct 29, 2012, at 10:29 AM, Vladimir Kozlov >> wrote: >>>> Bharadwaj, >>>> >>>> These changes look much better. Sorry, I suggested to add >>>> verify_live_node_count() method before but your current code don't >>>> need it, just use count_live_nodes_by_graph_walk(). >> >> OK. Made the necessary changes. >> >>>> An other note: without LogCompilation verification code should >>>> produce some info on tty. >> >> OK. We do not need to print the information about the number of unique >> nodes created, those that are live and those that are dead to the tty, >> correct? (Ref. around line 777 and line 816 in compile.cpp) > > It is useful information when you try to diagnose node limit bailouts. > You can add new debug flag PrintIdealNodeCount to output this info to tty. > >> >> That leaves us with the message when there is a mismatch between the >> live node count arrived at by flow-graph walk and that kept track of >> via deal_node_list. >> >> Would you suggest that I print out to tty indicating a mismatch? (Ref. >> around line 819 in compile.cpp) A mismatch may not always indicate >> that something is indeed wrong - given that some constant nodes that >> become unreachable (dead) can later become reachable, for example, due >> to final_graph_reshaping_walk(). Hence I do not count constant nodes >> that become unreachable as dead. So printing out a message on the tty >> might trigger false alarms. So, I chose to print a message in the log >> file only. > > -XX:+VerifyIdealNodeCount is our internal flag and we would expect these > messages to be not accurate. > >> >> Please let me know if you still think that I should print this info >> (the one around line 819 in compile.cpp) to tty. > > Yes, also you need to dump nodes when output is tty instead of printing > their idx: > > useful.at(i)->dump(); > > Thanks, > Vladimir > >> >> On 10/29/2012 1:56 PM, Christian Thalinger wrote: >>> We still need to adjust MaxNodeLimit. Maybe some JRuby or Nashorn >>> benchmarks can help in getting really big methods. >> >> I agree. However, I felt that arriving at the MaxNodeLimit might need >> some experimentation with different applications whose method >> compilations result in creation of graphs with large number of nodes. >> I do not (yet) know how the current value was arrived at. It appears >> to me that leaving the current value unchanged in light of these >> proposed changes would not adversely affect normal applications. So, I >> thought we could check in these changes and later check in a change to >> MaxNodeLimit based on a detailed experimentation. What do you think? >> >>> src/share/vm/opto/compile.cpp: >>> >>> + _log->elem("node count before optimize compile_id='%d' >>> unique='%d' live (tracked)='%d' live(graph_walk)='%d'", >>> >>> I think the log element name needs to have _'s so we can match it (if >>> we want to): >>> >>> + _log->elem("node_count_before_optimize compile_id='%d' >>> unique='%d' live (tracked)='%d' live(graph_walk)='%d'", >> >> OK. Changed. >> >> Thanks, >> >> Bharadwaj >> From bharadwaj.yadavalli at oracle.com Mon Oct 29 14:06:58 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Mon, 29 Oct 2012 17:06:58 -0400 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <75A7BD85-9AF3-4126-97E1-8298DB4277B6@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <75A7BD85-9AF3-4126-97E1-8298DB4277B6@oracle.com> Message-ID: <508EEFF2.8080304@oracle.com> Thanks for pointing out the XML related issues, John. I made the necessary changes to my log output such that valid XML code is generated. I validated the resulting hotspot.log using xmllint. Bharadwaj On 10/29/2012 3:22 PM, John Rose wrote: > On Oct 29, 2012, at 10:56 AM, Christian Thalinger wrote: > >> src/share/vm/opto/compile.cpp: >> >> + _log->elem("node count before optimize compile_id='%d' >> unique='%d' live (tracked)='%d' live(graph_walk)='%d'", > > Actually, that will emit invalid XML, even if the underscores are added: > (tracked)='44' live(graph_walk)='22'/> > > Not only are "count" and "before" bad attribute specifiers, but "live > (tracked)='44'" is also. I suppose live(graph_walk)='22' is > accidentally correct, but I wouldn't wish it on an XML parser. > > It might be worthwhile putting a debug-only validator of some sort to > catch simple mistakes like this. > > ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121029/668475d7/attachment-0001.html From john.r.rose at oracle.com Mon Oct 29 14:38:54 2012 From: john.r.rose at oracle.com (John Rose) Date: Mon, 29 Oct 2012 14:38:54 -0700 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <508EEFF2.8080304@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <75A7BD85-9AF3-4126-97E1-8298DB4277B6@oracle.com> <508EEFF2.8080304@oracle.com> Message-ID: On Oct 29, 2012, at 2:06 PM, Bharadwaj Yadavalli wrote: > Thanks for pointing out the XML related issues, John. > > I made the necessary changes to my log output such that valid XML code is generated. I validated the resulting hotspot.log using xmllint. Thanks! ? John P.S. Adding a little syntax sanity checking to xtty and C->log (lightweight & partial!) would be a good starter task. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121029/6d9e6aee/attachment.html From vladimir.x.ivanov at oracle.com Tue Oct 30 07:48:50 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 30 Oct 2012 17:48:50 +0300 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <508ED445.3090401@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> Message-ID: <508FE8D2.3080803@oracle.com> Bharadwaj, Have you updated the webrev with latest changes? I don't see some of the previous comments being addressed. Regarding the currently published version, I think that logging part can be improved further. The general question is: do you intentionally print this info into XML compiler log? Why don't you use tty instead? All the messages will appear on console and will be duplicated in section in XML log anyway and you don't need to bother too much about the format. Regarding the code: src/share/vm/opto/compile.cpp + if (_log != NULL) { + _log->elem("node count before optimize compile_id='%d' unique='%d' live (tracked)='%d' live(graph_walk)='%d'", + compile_id(), unique(), live_nodes(), count_live_nodes_by_graph_walk()); + } + if (_log != NULL) { + _log->elem("node count after optimize compile_id='%d' unique='%d' live (tracked)='%d' live(graph_walk)='%d'", + compile_id(), unique(), live_nodes(), count_live_nodes_by_graph_walk()); + } Why do you introduce new element? There's a tag which already contains node count before and after each phase. You can enrich it with live node count. Also, LogCompilation is diagnostic VM option, so it can be used in production (by specifying -XX:+UnlockDiagnosticVMOptions), so I would refrain from calling count_live_nodes_by_graph_walk, since I consider it as an expensive operation. Here's the code for section: src/share/vm/opto/compile.cpp: 3016 Compile::TracePhase::TracePhase(const char* name, elapsedTimer* accumulator, bool dolog) 3017 : TraceTime(NULL, accumulator, false NOT_PRODUCT( || TimeCompiler ), false) 3018 { 3019 if (dolog) { 3020 C = Compile::current(); 3021 _log = C->log(); 3022 } else { 3023 C = NULL; 3024 _log = NULL; 3025 } 3026 if (_log != NULL) { 3027 _log->begin_head("phase name='%s' nodes='%d'", name, C->unique()); 3028 _log->stamp(); 3029 _log->end_head(); 3030 } 3031 } 3032 3033 Compile::TracePhase::~TracePhase() { 3034 if (_log != NULL) { 3035 _log->done("phase nodes='%d'", C->unique()); 3036 } 3037 } src/share/vm/opto/compile.cpp +#ifdef ASSERT + if (VerifyIdealNodeCount) { + if (! verify_live_node_count()) { + if (_log != NULL) { + _log->head("pre_opt dead node count mismatch"); + print_missing_nodes(); + _log->tail("pre_opt"); + } + } + } +#endif ... #ifdef ASSERT +void Compile::print_missing_nodes() { ... + if (_dead_node_list.test(i)) { + if (_log != NULL) { + _log->elem("node_liveness : compile_id='%d' node='%d' - in both live and dead!", + compile_id(), i); + } + } + } + else if (! _dead_node_list.test(i)) { + if (_log != NULL) { + _log->elem("node_liveness : compile_id='%d' node='%d' - neither in live nor dead!", + compile_id(), i); + } + } There's no need to print compile_id, since all output will be placed in corresponding compilation section (Comile::log() points to per-compiler thread log file). Also, it produces corrupted and redundant XML (':', '-' & '!' + attributes "neither", "in", "live", etc). You can add attribute "msg" or "message", but I would refactor the output of VerifyIdealNodeCount in the following way: ... And I would also make node_count_mismatch "optional" (print the tag only if there's any subnodes) by using CompileLog::set_context. Otherwise each method compilation will have this section in the log, even when there's no mismatched nodes and the section is empty. Best regards, Vladimir Ivanov On 10/29/12 22:08, Bharadwaj Yadavalli wrote: > > Thanks for your reviews, Vladimir and Christian. > > On Oct 29, 2012, at 10:29 AM, Vladimir Kozlov > wrote: >>> Bharadwaj, >>> >>> These changes look much better. Sorry, I suggested to add >>> verify_live_node_count() method before but your current code don't >>> need it, just use count_live_nodes_by_graph_walk(). > > OK. Made the necessary changes. > >>> An other note: without LogCompilation verification code should >>> produce some info on tty. > > OK. We do not need to print the information about the number of unique > nodes created, those that are live and those that are dead to the tty, > correct? (Ref. around line 777 and line 816 in compile.cpp) > > That leaves us with the message when there is a mismatch between the > live node count arrived at by flow-graph walk and that kept track of via > deal_node_list. > > Would you suggest that I print out to tty indicating a mismatch? (Ref. > around line 819 in compile.cpp) A mismatch may not always indicate that > something is indeed wrong - given that some constant nodes that become > unreachable (dead) can later become reachable, for example, due to > final_graph_reshaping_walk(). Hence I do not count constant nodes that > become unreachable as dead. So printing out a message on the tty might > trigger false alarms. So, I chose to print a message in the log file only. > > Please let me know if you still think that I should print this info (the > one around line 819 in compile.cpp) to tty. > > On 10/29/2012 1:56 PM, Christian Thalinger wrote: >> We still need to adjust MaxNodeLimit. Maybe some JRuby or Nashorn >> benchmarks can help in getting really big methods. > > I agree. However, I felt that arriving at the MaxNodeLimit might need > some experimentation with different applications whose method > compilations result in creation of graphs with large number of nodes. I > do not (yet) know how the current value was arrived at. It appears to me > that leaving the current value unchanged in light of these proposed > changes would not adversely affect normal applications. So, I thought we > could check in these changes and later check in a change to MaxNodeLimit > based on a detailed experimentation. What do you think? > >> src/share/vm/opto/compile.cpp: >> >> + _log->elem("node count before optimize compile_id='%d' >> unique='%d' live (tracked)='%d' live(graph_walk)='%d'", >> >> I think the log element name needs to have _'s so we can match it (if >> we want to): >> >> + _log->elem("node_count_before_optimize compile_id='%d' >> unique='%d' live (tracked)='%d' live(graph_walk)='%d'", > > OK. Changed. > > Thanks, > > Bharadwaj > From john.r.rose at oracle.com Tue Oct 30 13:27:11 2012 From: john.r.rose at oracle.com (John Rose) Date: Tue, 30 Oct 2012 13:27:11 -0700 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <508FE8D2.3080803@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> Message-ID: On Oct 30, 2012, at 7:48 AM, Vladimir Ivanov wrote: > Regarding the currently published version, I think that logging part can > be improved further. Those are good suggestions, Vladimir. > The general question is: do you intentionally print this info into XML > compiler log? Why don't you use tty instead? All the messages will > appear on console and will be duplicated in section in XML log > anyway and you don't need to bother too much about the format. Each compiler thread has a separate log section, divided in the s executed by that thread. The main log is global, and intended for globally serialized runtime events, such as deoptimizations or GCs or tty->print stuff. Meanwhile, the compiler (in one more more threads) runs asynchronously to all the Java application threads. So it gets a separate log. If an interesting event occurs within the time-sequence of a compiler task, it should be logged in that compiler thread's C->log. When the JVM exits, all the extra compiler logs are catted together onto the end of the main log's output file. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121030/37d5a20e/attachment.html From vladimir.x.ivanov at oracle.com Wed Oct 31 08:17:24 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 31 Oct 2012 18:17:24 +0300 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> Message-ID: <50914104.5020401@oracle.com> John, Thanks for the clarification. I agree that compiler's section is the best fit for such info. What I would like to see is clearer format and denser data representation, so it isn't burdensome to parse it by automatic tools (like LogCompilation). But I still have one unclear point. It's more methodological and relates to VM logging in general. Do we have a habit to look for warnings in compilation logs? :-) When a warning is issued during node count verification step, it doesn't occur on console. I would duplicate it both on console & in the log then. But, I rely on my own habits here - if I request such checks explicitly, I would like to easily see them. Best regards, Vladimir Ivanov On 10/30/12 11:27 PM, John Rose wrote: > On Oct 30, 2012, at 7:48 AM, Vladimir Ivanov wrote: > >> Regarding the currently published version, I think that logging part can >> be improved further. > > Those are good suggestions, Vladimir. > >> The general question is: do you intentionally print this info into XML >> compiler log? Why don't you use tty instead? All the messages will >> appear on console and will be duplicated in section in XML log >> anyway and you don't need to bother too much about the format. > > Each compiler thread has a separate log section, divided in the s > executed by that thread. > > The main log is global, and intended for globally serialized > runtime events, such as deoptimizations or GCs or tty->print stuff. > > Meanwhile, the compiler (in one more more threads) runs asynchronously > to all the Java application threads. So it gets a separate log. > > If an interesting event occurs within the time-sequence of a compiler > task, it should be logged in that compiler thread's C->log. > > When the JVM exits, all the extra compiler logs are catted together onto > the end of the main log's output file. > > ? John From vladimir.x.ivanov at oracle.com Wed Oct 31 08:49:00 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 31 Oct 2012 18:49:00 +0300 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <50914104.5020401@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> Message-ID: <5091486C.7030009@oracle.com> Small addition to the last paragraph: if the compiler log isn't available, it's still useful to get this type of warnings. Best regards, Vladimir Ivanov On 10/31/12 6:17 PM, Vladimir Ivanov wrote: > John, > > Thanks for the clarification. > > I agree that compiler's section is the best fit for such info. > What I would like to see is clearer format and denser data > representation, so it isn't burdensome to parse it by automatic tools > (like LogCompilation). > > But I still have one unclear point. It's more methodological and relates > to VM logging in general. Do we have a habit to look for warnings in > compilation logs? :-) > > When a warning is issued during node count verification step, it doesn't > occur on console. I would duplicate it both on console & in the log > then. But, I rely on my own habits here - if I request such checks > explicitly, I would like to easily see them. > > Best regards, > Vladimir Ivanov > > On 10/30/12 11:27 PM, John Rose wrote: >> On Oct 30, 2012, at 7:48 AM, Vladimir Ivanov wrote: >> >>> Regarding the currently published version, I think that logging part can >>> be improved further. >> >> Those are good suggestions, Vladimir. >> >>> The general question is: do you intentionally print this info into XML >>> compiler log? Why don't you use tty instead? All the messages will >>> appear on console and will be duplicated in section in XML log >>> anyway and you don't need to bother too much about the format. >> >> Each compiler thread has a separate log section, divided in the s >> executed by that thread. >> >> The main log is global, and intended for globally serialized >> runtime events, such as deoptimizations or GCs or tty->print stuff. >> >> Meanwhile, the compiler (in one more more threads) runs asynchronously >> to all the Java application threads. So it gets a separate log. >> >> If an interesting event occurs within the time-sequence of a compiler >> task, it should be logged in that compiler thread's C->log. >> >> When the JVM exits, all the extra compiler logs are catted together onto >> the end of the main log's output file. >> >> ? John From bharadwaj.yadavalli at oracle.com Wed Oct 31 09:36:12 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Wed, 31 Oct 2012 12:36:12 -0400 Subject: Visit all Ideal Nodes Message-ID: <5091537C.4090409@oracle.com> Is there a way to visit every node in the ideal graph at any given time during the C2 compilation process other than walking the graph starting at its root? I was wondering if maintaining a vector of pointers to all nodes created (or Node_Array) - in the Compiler object - is considered (or known to be) a performance drag. Thanks, Bharadwaj From vladimir.kozlov at oracle.com Wed Oct 31 10:25:52 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 31 Oct 2012 10:25:52 -0700 Subject: Visit all Ideal Nodes In-Reply-To: <5091537C.4090409@oracle.com> References: <5091537C.4090409@oracle.com> Message-ID: <50915F20.2080300@oracle.com> Bharadwaj Yadavalli wrote: > Is there a way to visit every node in the ideal graph at any given time > during the C2 compilation process other than walking the graph starting > at its root? No, only going through graph edges. > > I was wondering if maintaining a vector of pointers to all nodes created > (or Node_Array) - in the Compiler object - is considered (or known to > be) a performance drag. Yes, it is performance issue. Vladimir > > Thanks, > > Bharadwaj > From vladimir.kozlov at oracle.com Wed Oct 31 11:18:32 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 31 Oct 2012 11:18:32 -0700 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <50914104.5020401@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> Message-ID: <50916B78.7090207@oracle.com> Vladimir Ivanov wrote: > John, > > Thanks for the clarification. > > I agree that compiler's section is the best fit for such info. > What I would like to see is clearer format and denser data > representation, so it isn't burdensome to parse it by automatic tools > (like LogCompilation). > > But I still have one unclear point. It's more methodological and relates > to VM logging in general. Do we have a habit to look for warnings in > compilation logs? :-) It could be useful in general. LogCompilation is diagnostic flag and we use it with product VM to find what happened during compilations. I think, it is good to have warnings there if they help diagnose problems. On other hand IdealNodeCount verification warning is not useful in this sense if we will have total and alive nodes count in info as you suggested. What information you can get from the knowledge that alive nodes count is not accurate? Which we know will happen almost always. > > When a warning is issued during node count verification step, it doesn't > occur on console. I would duplicate it both on console & in the log > then. But, I rely on my own habits here - if I request such checks > explicitly, I would like to easily see them. I agree with that, I also suggested to add output to tty when VerifyIdealNodeCount flag is used to avoid additional step to look into log file. Thanks, Vladimir > > Best regards, > Vladimir Ivanov > > On 10/30/12 11:27 PM, John Rose wrote: >> On Oct 30, 2012, at 7:48 AM, Vladimir Ivanov wrote: >> >>> Regarding the currently published version, I think that logging part can >>> be improved further. >> >> Those are good suggestions, Vladimir. >> >>> The general question is: do you intentionally print this info into XML >>> compiler log? Why don't you use tty instead? All the messages will >>> appear on console and will be duplicated in section in XML log >>> anyway and you don't need to bother too much about the format. >> >> Each compiler thread has a separate log section, divided in the s >> executed by that thread. >> >> The main log is global, and intended for globally serialized >> runtime events, such as deoptimizations or GCs or tty->print stuff. >> >> Meanwhile, the compiler (in one more more threads) runs asynchronously >> to all the Java application threads. So it gets a separate log. >> >> If an interesting event occurs within the time-sequence of a compiler >> task, it should be logged in that compiler thread's C->log. >> >> When the JVM exits, all the extra compiler logs are catted together onto >> the end of the main log's output file. >> >> ? John