[foreign] RFR 8222765: Implement foreign memory access through VarHandle

[Maurizio Cimadamore]

And here's a javadoc link in case somebody wants to do a pass over the 
API (30% feedback please :-))

http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc_v1/

Maurizio

On 19/04/2019 14:25, Maurizio Cimadamore wrote:
> Hi,
> this patch implements the MemoryAddress/MemoryScope abstractions 
> described in the document I've sent recently [1]:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/8222765/
>
> This patch will go on new branch of Panama, called 
> "foreign-memaccess", so the patch is relative to the 'default' branch.
>
> Most of the classes added by this patch are the Layout classes we 
> already have in the existing 'foreign' branch.
>
> There are however a bunch of new classes: LayoutPath, MemoryAddress 
> and MemoryScope (and their respective implementations).
>
> In order to generate VarHandle with the right number of dimensions, we 
> use a template (so that we can automatically generate all variants of 
> VarHandle for all carriers). Then, we also need some bytecode 
> spinning, since a concrete VarHandle might have a number of components 
> indices which depend on the layout being accessed (more specifically, 
> for each traversed array, there's an extra long component).
>
> The spinning is done in the new AddressVarHandleGenerator class.
>
> I've added a smoke test for the various memory mode accesses; we 
> should of course add more tests e.g. to check that all scope options 
> are properly enforced (such as confinement).
>
> With this patch, performances of VH access is approx 15% slower than a 
> plain Unsafe call. The main issue is that the scope liveness check is 
> not hoisted outside of hot loops from hotspot (since the scope state 
> is a mutable field which could be changed by a different thread). Vlad 
> is working on the JIT optimization story for this; the idea is that 
> when access is confined, JIT will be able to trust the fact that it's 
> seeing all accesses to the scope it needs to and, provided the scope 
> never escapes the inlined method, the liveness check can be hoisted, 
> effectively bringing us on par with Unsafe.
>
> Cheers
> Maurizio
>
> [1] - http://cr.openjdk.java.net/~mcimadamore/panama/memaccess.html
>