[foreign-memaccess] RFR 8234814: Eager layout size computation trips on unbound sequence layouts

[Maurizio Cimadamore]

Updated webrev:

cr.openjdk.java.net/~mcimadamore/panama/8234814_v2

Changes:

* simplified the code

* fixed issues in how size is computed in structs vs. unions (and added 
test)

* improved quality of impl, so that alignment prefix (e.g. 8%) is only 
printed when alignment differs from natural alignment (added test)

* added test to check that equals/hashCode always work, regardless of 
unbound sequences

* constants such as JAVA_INT should use native order (this is, after 
all, the layout of an int in the VM)

Cheers
Maurizio

On 26/11/2019 13:41, Maurizio Cimadamore wrote:
> This is a regression that was introduced by [1]; by making computation 
> of layout sizes for compound layouts more eager, we now trip up on 
> layouts which contain unbound sequence layouts.
>
> I've rewrite the code to be more friendly to unbound sequences - the 
> code now acknowledges that _any_ compound layout can potentially lack 
> a definite size (because it contains deeply nested unbound sequence 
> layouts).
>
> I've added a bunch of tests to verify that some edge cases work 
> correctly and that var handle can correctly be derived from layouts, 
> even in the presence of 'trailing' unbound sequence layouts (which is 
> the common case).
>
> As I was writing the patch I realized that we were not handling the 
> alignment of empty groups properly (now we return minimal alignment, 
> 1) - and I've also hit a jshell bug when printing the stack trace of 
> an out of bound access - which is caused by jshell not considering 
> that the file attached to a stack trace element can be null (in the 
> case of hidden stack trace elements such as the ones associated with 
> VarHandles). Jshell fix has been discussed with Jan.
>
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/panama/8234814/
>
>
> Cheers
> Maurizio
>
> [1] - https://bugs.openjdk.java.net/browse/JDK-8231402
>