review (M) for 6892658: C2 should optimize some stringbuilder patterns
Vladimir Kozlov
Vladimir.Kozlov at Sun.COM
Wed Nov 11 10:36:13 PST 2009
Tom Rodriguez wrote:
>
>> Also _begin instead of other->_begin
>> in result->set_allocation(other->_begin)
>
> _begin is must be the earliest JVMState of the pattern and other->_begin has to be earlier than _begin otherwise the couldn't be merged so I can't just swap them around.
>
Then I don't get how you optimize next code:
SB.append((new SB()).append(s).toString()).toString()
and I don't see any checks that other->_begin dominates _begin.
>
>> There are several places where you do next check,
>> may be you can factor it in a separate function:
>>
>> method->holder() == C->env()->StringBuilder_klass() ||
>> method->holder() == C->env()->StringBuffer_klass()
>
> I'm not sure factoring it out would be better.
OK.
>
>> May be also verify has_stringbuilder() in PhaseStringOpts().
>
> Why?
OK, I see that caller code of PhaseStringOpts() has has_stringbuilder()
>> Also this coalesce code will not work if "other" is used by
>> several sc/arguments since you removed it from the list after
>> first match and merge. For example:
>>
>> String s0 = new SB().append(1)...toString();
>> String s1 = new SB().append(s0).append(s0).toString();
>>
>> I would keep it and always replace "c" with merged
>> (you need to modify StringConcat::merge() as I pointed above).
>> The "o" will be removed automatically if there are no other uses.
>
> I don't want to support that. I don't think that's an interesting pattern. It would also require rewriting the management of the control and trap lists and I don't want to get into that.
>
OK.
Vladimir
>> I will look on copy_string() and related methods tomorrow.
>
> Thanks.
>
> tom
>
>> Vladimir
>
More information about the hotspot-compiler-dev
mailing list