[Exp] First prototype of new acmp bytecode (original) (raw)

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.

Thanks, Tobias

More information about the valhalla-dev mailing list