RFR: JDK-8203157: Object equals abstraction for BarrierSetAssembler
erik.osterlund at oracle.com
Mon Jun 4 12:38:33 UTC 2018
43 virtual void obj_equals(MacroAssembler* masm, DecoratorSet
44 Register obj1, Register obj2);
I don't think we need to pass in any decorators here. Perhaps one day
there will be some important semantic property to deal with, but today I
do not think there are any properties we care about, except possibly
AS_RAW, but that would never propagate into the BarrierSetAssembler anyway.
On that topic, I noticed that today we do the raw version of e.g.
load_heap_oop inside of the BarrierSetAssembler, and to use it you would
call load_heap_oop(AS_RAW). But the cmpoop stuff does it in a different
way (cmpoop_raw in the macro assembler). I think it would be ideal if we
could do it the same way, which would involve calling cmpoop with AS_RAW
to get a raw oop comparison, residing in BarrierSetAssembler, with the
usual hardwiring in the corresponding macro assembler function when it
So it would look something like this:
void cmpoop(Register src1, Address src2, DecoratorSet decorators =
What do you think?
On 2018-05-14 21:19, Roman Kennke wrote:
> Similar to what's done in the runtime already, GCs might need a say
> about object equality (e.g. Shenandoah GC). This adds the required
> abstraction to x86 and aarch64 assembler code.
> In x86 it ends up a bit ugly because of the existing variations of
> cmpoop() which take several combinations of Register, Address and
> jobject as argument, and even worse, varies between 64 and 32 bit builds.
> In aarch64, I added the MacroAssembler::cmpoop() indirection to make it
> more like the x86 implementation.
> Passes hotspot/tier1 tests for x86_64/x86_32/aarch64
> Can I please get a review?
> Thanks, Roman
More information about the hotspot-dev