Bounds checks with unsafe array access

[Vitaly Davidovich]

Yeah, I don't know how one would do that practically.  Compiler would have
to somehow always know that whenever the array is set its len > 0.  One
crazy idea is to treat this like other speculation via deopt.  When jit
compiling a method with array access, check profiling info and see whether
len has been seen > 0 always thus far.  If so, compile that assumption in
and register a deopt if this ever changes.  This deopt would have to
piggyback on write barrier or something, but this adds extra complexity and
perf impact on writes.  Maybe for cases where the array is predominantly
read this could be a net win ...

Sent from my phone
On Sep 10, 2014 9:18 AM, "Paul Sandoz" <paul.sandoz at oracle.com> wrote:

> On Sep 10, 2014, at 2:41 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
> One thing that bothers me is that even fields marked final aren't really
> treated as such by compiler because it's paranoid of things like
> reflection.  If there was some way to reassure it that final fields aren't
> modified behind its back, then more type info can be captured at init time
> (e.g. array is not null and length is captured as a constant).
>
>
> In general i agree.
>
> However, in the particular cases i am looking at, an array field is
> unlikely to be final since it can be updated with a larger array (e.g. the
> node table in HashMap or the task queue in ForkJoinPool.WorkQueue), and
> it's about somehow conveying/expressing the constraint that the array
> length is always > 0.
>
> Paul.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140910/ae6faed9/attachment.html>