[Exp] First prototype of new acmp bytecode

Tobias Hartmann tobias.hartmann at oracle.com
Wed Feb 21 15:58:35 UTC 2018

Hi John,

update on this:

On 16.02.2018 14:13, Tobias Hartmann wrote:
> Yes, the result is indeed a RawPtr but I think the "real" problem is the following:
> If the oop is perturbed at runtime, the GC does not need to know about it. We can just treat it as a
> RawPtr and make sure that it's never treated as a valid oop at a safepoint after optimizations. The
> following cmp will return false no matter if the GC moved the object or not.
> However, if the oop is *not* perturbed at runtime and live at a safepoint, the GC needs to be aware
> of it because a subsequent cmp needs to use the updated oop in case the GC moves the object. That
> said, the GC may need to update the (not) perturbed oop.

After thinking about it more, it came to me that we could just treat perturbation as:
Node* perturbed = AddP(oop, oop, is_value_bit)

Like for field accesses, the resulting pointer will then be treated as "derived oop" at safepoints
which ensures that the GC will update the base oop in case the object moves and also
re-compute/update the (potentially) perturbed oop.

I've quickly prototyped this. Here's an example of a perturbed oop in R11 being live over a call to
Test::myMethod and being treated as [8]=Derived_oop_[0] in the oop map. It's then re-used in the cmp
at line 103:

03b   	movl    R11, [RDX + #8 (8-bit)]	# compressed klass ptr
03f   	movq    R10, R11	# ptr -> long
042   	andq    R10, #1	# long
046   	movq    R11, RDX	# spill
049   	addq    R11, R10	# ptr
04c   	cmpq    R11, RCX	# ptr
04f   	jne,us  B5  P=0,519876 C=23319,000000
05b   	movq    [rsp + #8], R11	# spill
060   	movq    [rsp + #0], RDX	# spill
      	nop 	# 3 bytes pad for loops and calls
067   	call,static  Test::myMethod
        # Test::testEq01_1 @ bci:14  L[0]=RBP L[1]=rsp + #0 L[2]=_
        # OopMap{rbp=Oop [0]=Oop [8]=Derived_oop_[0] off=108}
103   	cmpq    R11, R10	# ptr

I still have to sort out some issues (escape analysis isn't happy) but a new webrev will come soon.


More information about the valhalla-dev mailing list