RFE: 8023597: Optimize G1 barriers code for unsafe load_store

[Doerr, Martin]

Hi Vladimir,

I was also surprised about the oldval with type T_ADDRESS instead of T_OBJECT.
Here's some gdb output:

(gdb) call oldval->dump()
 25     ConP    ===  0  [[ 26  40  181  254  221  265  273  221  290  295  297  603  351  412  480  535  637  652  654 ]]  #NULL
(gdb) call oldval->bottom_type()->basic_type()
$4 = T_ADDRESS
 (gdb) call C->_method->print_name(tty)
virtual jobject java.util.concurrent.ConcurrentHashMap.internalPut(jobject, jobject, jboolean)

Not sure if the type is an error.

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.

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