C1 and @Stable array elements

[Paul Sandoz]

> On 19 Nov 2015, at 18:30, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
> Paul,
> 
> It is definitely doable, but my estimate is that it could require extensive changes.
> 

Drat.


> The first question I'd like to ask you is what use cases do you have in mind?
> 

VarHandles related work. I am exploring support for invoke-semantics [1].

One implementation approach is to perform a quick check against erased method types and then perform casts using the parameters types obtained from the array held by the expected method type (that parameter type array would be modified to be @Stable). That’s a nice self-contained approach, It all works fine in C2 :-)

Otherwise, i will need to push the casts down to the actual VH implementations which is possible but less appealing because it spreads stuff out. So it’s not a blocker, more a really convenient nice to have.


> What I'm trying to understand is what level of optimization you are looking for.
> 

Supporting one dimensional arrays would be sufficient.


> (1) With field loads it is simple
>  getfield T.f // class T { @Stable int f; }
> 
> all information is local, so it can be constant folded during bytecode parsing.
> 
> (2) For arrays it becomes slightly harder:
>  getfield T.arr:[I // class T { @Stable int[] arr; }
>  iconst_0
>  ailed
> 
> The value produced by getfield should be annotated as "stable", so when aaload is parsed there is a way to find out the array on stack is "stable”.
> 

AFAICT, i think it’s possible to find out, just by virtue of 1) already being supported, and from that C1 treats the array length as a constant, but i have no idea to combine the array, length and index with a bounds check and then an array access to produce a constant.

Thanks,
Paul.

[1] http://cr.openjdk.java.net/~psandoz/jdk9/varhandles/vh-invoke-semantics/webrev/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java.sdiff.html <http://cr.openjdk.java.net/~psandoz/jdk9/varhandles/vh-invoke-semantics/webrev/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java.sdiff.html>

> (3) And for arrays of arrays it becomes complex:
> getfield T.arr:[[[I // class T { @Stable int[][][] arr; }
> iconst_0
> aaload    // => int[][]
> iconst_0
> aaload    // => int[]
> iconst_0
> iaload    // => int
> 
> The compiler has to track not only "stable" bit, but also array dimension to be able to constant fold the very last load.
> 
> And then we have to add control flow into consideration. Ends up pretty complex, isn't it? :-)
> 
> Best regards,
> Vladimir Ivanov
> 
> PS: I deliberately tried to be pessimistic in my estimates since I don't have extensive experience in C1 code base.
> 
> On 11/19/15 7:22 PM, Paul Sandoz wrote:
>> Hi,
>> 
>> Currently C1 does not support constant folding of array elements of an array held by a @Stable field.
>> 
>> How easy or hard would it be for C1 to support such constant folding?
>> 
>> Naively and intuitively, since C1 appears to constant fold an array length (i.e. it knows the array itself is stable or static final), it would in theory seem possible to extend that logic for array elements, such that if the referenced element value is not the default value, produce a constant holding the element value.
>> 
>> Paul.
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151119/cbd55b7f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151119/cbd55b7f/signature-0001.asc>