[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