for (re-)review (M): 6814659: separable cleanups and subroutines for 6655638
Vladimir Kozlov
Vladimir.Kozlov at Sun.COM
Thu Mar 12 17:19:03 PDT 2009
About next:
> 3. 6812831 factor general subclass check (for 6655638)
> http://cr.openjdk.java.net/~jrose/6813212/webrev.01/ (not yet integrated)
Assembler code on x86 and sparc looks good for me.
General question: why we do next check in enc_PartialSubtypeCheck()
// Compare super with sub directly, since super is not in its own SSA.
// The compiler used to emit this test, but we fold it in here,
// to allow platform-specific tweaking on sparc.
__ cmpptr(Rrax, Rrsi);
__ jcc(Assembler::equal, hit);
and in Sparc::partial_subtype_check()
// Compare super with sub directly, since super is not in its own SSA.
// The compiler used to emit this test, but we fold it in here,
// to increase overall code density, with no real loss of speed.
{ Label L;
__ cmp(O1, O2);
__ brx(Assembler::notEqual, false, Assembler::pt, L);
__ delayed()->nop();
__ retl();
__ delayed()->addcc(G0,0,O0); // set Z flags, zero result
__ bind(L);
}
When in GraphKit::gen_subtype_check we have the check contrary to the above
comments:
// Check for self. Very rare to get here, but its taken 1/3 the time.
// No performance impact (too rare) but allows sharing of secondary arrays
// which has some footprint reduction.
Node *cmp3 = _gvn.transform( new (C, 3) CmpPNode( subklass, superklass ) );
Node *bol3 = _gvn.transform( new (C, 2) BoolNode( cmp3, BoolTest::eq ) );
IfNode *iff3 = create_and_xform_if( control(), bol3, PROB_LIKELY(0.36f), COUNT_UNKNOWN );
r_ok_subtype->init_req(2, _gvn.transform( new (C, 1) IfTrueNode ( iff3 ) ) );
set_control( _gvn.transform( new (C, 1) IfFalseNode( iff3 ) ) );
Next, why we keep generate_partial_subtype_check stub?
The only place which calls it is sparc.ad:
enc_class enc_PartialSubtypeCheck() %{
MacroAssembler _masm(&cbuf);
__ call(StubRoutines::Sparc::partial_subtype_check(), relocInfo::runtime_call_type);
__ delayed()->nop();
%}
Is there a reason to keep the call instead of using your new
macroassembler methods?
assembler_x86.cpp check_klass_subtype_slow_path()
Move next assert:
+ assert(secondary_supers_addr.base() != rax, "put sub_klass in another reg");
(why not assert(sub_klass != rax, "put sub_klass in another reg") ?)
before this code:
+ if (super_klass != rax || UseCompressedOops) {
+ if (!IS_A_TEMP(rax)) { push(rax); pushed_rax = true; }
+ mov(rax, super_klass);
+ }
Also sub_klass != rcx since rcx is destroyed by debug counter code.
You changed encode_heap_oop(rax) to encode_heap_oop_not_null(rax).
Can you give guaranty that super_klass value is not NULL for all cases?
x86_64.ad, x86_32.ad
You can remove the label 'cmiss' from enc_PartialSubtypeCheck.
Thanks,
Vladimir
John Rose wrote:
> In order to reduce the size of my forthcoming method handles changeset,
> I have (at Vladimir's suggestion) pulled out chunks of independent
> changes this week. The four chunks amount to about 40% of the changes,
> and are more easily tested and reviewed in isolation.
>
> The fourth chunk 6814659 is the most miscellaneous. It is a bunch of
> changes that were necessary either for debugging method handles, or for
> supporting them. They can all be considered independently.
>
> Here are the changes:
> http://cr.openjdk.java.net/~jrose/6814659/webrev.00/
>
> Not much review is necessary here, because these changes have already
> been reviewed as part of the larger changeset.
>
> The current draft of the big change is here:
> http://cr.openjdk.java.net/~jrose/6655638/webrev.00/
>
> -- John
>
> P.S. For the record, here is the sequence:
>
> 1. 6812678: macro assembler needs delayed binding of a few constants
> (for 6655638)
> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/56aae7be60d4
>
> 2. 6812831: factor duplicated assembly code for megamorphic
> invokeinterface (for 6655638)
> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9adddb8c0fc8
>
> 3. 6812831 factor general subclass check (for 6655638)
> http://cr.openjdk.java.net/~jrose/6813212/webrev.01/ (not yet integrated)
>
> 4. 6814659: separable cleanups and subroutines for 6655638
> http://cr.openjdk.java.net/~jrose/6814659/webrev.00/ (not yet integrated)
>
> 5. 6655638: dynamic languages need method handles
> http://cr.openjdk.java.net/~jrose/6655638/webrev.00/ (not yet integrated)
>
> And here are the patch file sizes (from my mq patch queue):
>
> 1178 5493 48571 asm-6812678.patch
> 979 5029 40958 ilookup-6812831.patch
> 1611 7834 70518 subtype-6813212.patch
> 1147 4962 48089 minor-6814659.patch
> 7274 33505 311948 meth.patch
> 12189 56823 520084 total
>
More information about the hotspot-compiler-dev
mailing list