RFE: 8023597: Optimize G1 barriers code for unsafe load_store

[Tony Printezis]

Martin,

On 8/26/13 4:52 AM, Doerr, Martin wrote:
>
> Regardless of the type issue, I guess we should not generate any pre-barrier code when C2 can
> determine that oldval is a null reference.

This is totally correct, the pre-barrier can be elided if the pre-value 
is null (no point in enqueueing null!).

Additionally, the pre-barrier can also be elided for writes in the young 
gen. IIRC, there is (or at least used to be!) some code in C2 to elide 
card table writes for objects in the young gen (a fast path allocation 
is guaranteed to allocate the object in the young gen and the object 
cannot move until the next safepoint). So, if it's not done already, you 
could take advantage of the same mechanism to also elide pre-barriers 
(and post-barriers of course).

Tony


> Regards,
> Martin
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Samstag, 24. August 2013 02:36
> To: Doerr, Martin
> Cc: hotspot compiler; hotspot-gc-dev at openjdk.java.net
> Subject: Re: RFE: 8023597: Optimize G1 barriers code for unsafe load_store
>
> On 8/23/13 9:09 AM, Doerr, Martin wrote:
>> Hi,
>>
>> I did some more tests with our proposed webrev
>> http://cr.openjdk.java.net/~goetz/webrevs/opto_g1_barr/
>> and it happened that the assertion
>> "assert(pre_val->bottom_type()->basic_type() == T_OBJECT, "or we
>> shouldn't be here");"
>> was firing when running jvm2008 derby on linuxx86_64.
>>
>> What happened is that the C2 was inserting a barrier of kind=LibraryCallKit::LS_cmpxchg,
>> but oldval was a ConP node with bottom_type()->basic_type() = T_ADDRESS.
> What is ConP (oldval->dump())? I am worried that compareAndSwapObject()
> is used not for object.
>
> Thanks,
> Vladimir
>
>> I believe there's nothing logically wrong with the change.
>> Should the assertion be modified or should we filter out cases in which oldval
>> does not contain a valid Oop?
>>
>> I guess some advice from C2 and G1 experts is needed.
>>
>> Best regards,
>> Martin

-- 
Tony Printezis | Staff Software Engineer | Twitter

@TonyPrintezis
tprintezis at twitter.com