[foreign-memaccess] RFR 8226421: Remove LayoutPath API

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Jun 19 22:34:09 UTC 2019


Hi,
now that we have combinators to create memory access handles, it seems 
like there is less need to have a very rich API to describe layout 
paths. But, we still want some higher level way to create var handles 
(or compute offsets) from a complex layout expression...

Chatting with Brian and John, an idea emerged - to use a simple grammar 
to describe a layout path.

For instance, if you have the usual array of struct we used in other 
examples:

[ 5 : [ x32 i32(value) ] ]

A path from the outermost sequence to the 'value' layout element can be 
described with the following string:

"[].value"

So, if we had a language to describe layout paths, we can replace the 
LayoutPath API with some methods which take a path expression as argument.

This is the patch:

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

I think the results are quite pleasing, and more compact than before. I 
also placed the VarHandle accessors where they belong - that is, an 
accessor taking a path expression in CompoundLayout. And then one that 
just takes a carrier in ValueLayout (as no selection is possible from a 
leaf).

I think this takes care of the last 'shaky' abstraction in the memory 
access API.

Impl-wise, the expression parser builds on some of the work we've done 
in the foreign branch - I've added a test which checks several 'bad' 
things that can happen during parsing.

I've also added a javadoc section on 'path expressions' - which shows 
the full grammar production for the path expression language.

One thing that I removed in the process was the ability to refer to 
struct components by index - in part because it felt a bit unjustified 
(for now, at least), in part because it also felt a bit shaky (w.r.t. 
unions).

Cheers
Maurizio




More information about the panama-dev mailing list