RFR: JDK-8207169: X86: Modularize cmpxchg-oop assembler for C1 and C2

Roland Westrelin rwestrel at redhat.com
Wed Aug 29 14:24:06 UTC 2018


> It was suggested to me (off-list) to simply put this stuff under if
> (UseShenandoahGC). I don't have a very strong preference about this. I'm
> leaning towards having a (somewhat) proper GC interface for it, if only
> because of the symmetry with the runtime GC interface that also has a
> cmpxchg hook, and because, cmpxchg(-oop) is, in-fact, a heap-access and
> should thus go through the GC interface.
>
> So, how do others feel about this? Better to put this under
> Shenandoah-specific paths? Make it a proper GC/BarrierSet-interface? I
> also very much welcome suggestions for improving the suggested interface.

FWIW, I made that off-list comment. My objection is that:

  666     if (BarrierSet::barrier_set()->barrier_set_assembler()->handle_cmpxchg_oop()) {
  667       tmp1 = new_register(T_OBJECT);
  668       tmp2 = new_register(T_OBJECT);
  669     }

is shenandoah specific. I suppose you could have an API entry point that
would return some opaque object. That object for shenandoah would record
2 extra registers. Then in the backend, you would pass that opaque
object to BarrierSetAssembler::cmpxchg_oop_c1() and the shenandoah
implementation would get its 2 extra registers.

The problem is that with c2:

 7471 instruct compareAndSwapP_BS(rRegI res,
 7472                             memory mem_ptr,
 7473                             rRegP tmp1, rRegP tmp2,
 7474                             rax_RegP oldval, rRegP newval,
 7475                             rFlagsReg cr)
 7476 %{

is also shenandoah specific for the same reason (it needs 2 extra
registers). And I don't see a way to properly abstract that.

So it seems to me, that code is not properly abstracted, there's no
reasonable way to properly abstract it, and it's actually shenandoah
specific code in disguise so it's better to have it be explicitly
shenandoah specific.

Roland.



More information about the hotspot-gc-dev mailing list