RFR: Eliminate extra forwarding pointer per object

[Aleksey Shipilev]

On 5/8/19 4:28 PM, Roman Kennke wrote:
> 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.

-Aleksey