[Exp] First prototype of new acmp bytecode (original) (raw)
John Rose john.r.rose at oracle.com
Wed Feb 21 21:04:58 UTC 2018
- Previous message (by thread): [Exp] First prototype of new acmp bytecode
- Next message (by thread): [Exp] First prototype of new acmp bytecode
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
That's very clever, I like it!
You might even be able to get rid of the special node type (arity=3), if the cases where CmpP sees a derived oop can be recognized as perturbations. I don't think we do CmpP on derived oops in any other circumstance (no C-style pointer/limit loops).
On Feb 21, 2018, at 7:58 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
... 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]=Derivedoop[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::testEq011 @ bci:14 L[0]=RBP L[1]=rsp + #0 L[2]= # OopMap{rbp=Oop [0]=Oop [8]=Derivedoop[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
- Previous message (by thread): [Exp] First prototype of new acmp bytecode
- Next message (by thread): [Exp] First prototype of new acmp bytecode
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]