RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles

Andrew Dinn adinn at redhat.com
Mon Feb 15 14:13:56 UTC 2016


Hi Aleksey,

On 15/02/16 13:49, Aleksey Shipilev wrote:
> Yes, open AArch64 is included there. But now I realize new Unsafe
> tests have not been run there, let me manhandle our infra into
> doing that. If that is easy for you, can you check if AArch64 works
> with this patch in your scenarios?

It would be very good to run your Unsafe tests. However, they may
still succeed but minus the desired optimizations. So, I'll apply the
patch to my tree and check the generated code by eyeball.

Can you detail any special magic to perform to run your tests? or is
there a grimoire I can consult?

> The changes are supposed to generate the same code for old Unsafe 
> methods -- the refactoring shuffles the compiler code around, but
> the sequence of accesses/barriers should stay the same. Eyeballing
> x86_64 assembly indeed shows it is the same, but I haven't looked
> beyond x86.

Ok, good. That was what I thought had been implemented last time I
studied a posted change set.

> So Roland's patch and those super-(awe|grue)some ARM64 .ad
> matchers should be unaffected. If they are affected, then I screwed
> up somewhere during refactoring. I'll wait for Roland's patch to
> land before pushing these Unsafe changes anyway, and beef up on
> testing.

That's probably the better way to do it. Roland's change led to a
significant lowering of the grue to awe ratio (/his/ awe allowed me to
remove much of /my/ grue).

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul
Argiry (US)


More information about the jdk9-dev mailing list