RFR: Eliminate extra forwarding pointer per object

[Roman Kennke]

Hi Aleksey,

>> New webrev:
>> http://cr.openjdk.java.net/~rkennke/eliminate-fwdptr/webrev.02/
> 
> I don't understand this part. Returning the oop makes the call ambiguous; this is why my example had
> "bool" as return value to communicate success. What oop does SF::try_update_forwardee return? It
> should be documented in the .hpp.
> 
> So I am trying to wrap my head around it:
> 
>    55 inline oop ShenandoahForwarding::try_update_forwardee(oop obj, oop update) {
>    56   markOop old_mark = obj->mark_raw();
>    57   if (old_mark->is_marked()) {
>    58     return (oop) old_mark->clear_lock_bits();
>    59   }
>    60
>    61   markOop new_mark = markOopDesc::encode_pointer_as_mark(update);
>    62   markOop prev_mark = obj->cas_set_mark_raw(new_mark, old_mark);
>    63   if (prev_mark == old_mark) {
>    64     return obj;
>    65   } else {
>    66     return (oop) prev_mark->clear_lock_bits();
>    67   }
>    68 }
> 
> Is it supposed to return to-space object on all paths? I say we return "update" on L64 then, and
> then here:
> 
>   275   oop result = ShenandoahForwarding::try_update_forwardee(p, copy_val);
>   276   if (oopDesc::equals_raw(result, p)) {  // !!!!
>   277     // Successfully evacuated. Our copy is now the public one!
>           ...
>   280   }  else {
>   281     // Failed to evacuate. We need to deal with the object that is left behind. Since this
>          ....
>   297   }
> 
> ...at L276 we check "equals_raw(result, copy_val)". This would make the code much more
> straight-forward, I think: we would check if we indeed installed our copy_val.
> 

Right. I tried to do what other CASes do and return the 
previous/expected value on success. But I agree that it's more intuitive 
to always return the successful forwardee and inverse the logic in 
evacuate_object().

http://cr.openjdk.java.net/~rkennke/eliminate-fwdptr/webrev.03/

Better?

Roman