JEPs proposed to target JDK 9 (2015/7/16)

[Vitaly Davidovich]

Right, there will be places where programmer knows more than the JIT.  This
is expressable with Unsafe today, and will not be quite so with
varhandles.  The overall context here is removal of Unsafe, so we're going
from something possible today to something that heavily relies on JIT.  It
seems like a bit of Sufficiently Smart Compiler territory ...

Having JIT gather all array lengths and look at most restrictive is good,
but still incurs the arguably biggest cost of this whole thing: memory
accesses that may not otherwise be needed.  This also would work best in a
loop context where this check could be amortized over the iterations, but
sometimes you just have islands of code that do this type of thing and not
all bunched in one tight loop that the JIT can easily work with.

Most languages with safety checks typically have unsafe constructs/regions
- Unsafe serves a bit of that role on the JVM, and I'm uncertain that
removing that escape hatch is a good thing when there's no replacement that
works at least as well.

sent from my phone
On Jul 16, 2015 9:38 PM, "John Rose" <john.r.rose at oracle.com> wrote:

> On Jul 16, 2015, at 5:32 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> >
> > Varhandles JEP talks about replacing Unsafe array accesses and trying to
> be
> > smarter about range check elimination to match performance of check-less
> > accesses using Unsafe today.  One use case that will suffer is parallel
> > arrays of equal length.  The programmer knows they're all the same length
> > (e.g. arrays are final fields allocated in ctor), and a handwritten check
> > for one suffices for the others; the accesses can then be safely done
> using
> > Unsafe with no range checks.  With varhandles, the JIT is not going to be
> > able to see this relationship between them and will issue range checks on
> > all accesses.
> >
> > Has such a use case been discussed/thought about?
>
> There are *always* going to be places where the programmer will
> be able to prove that x==y (or x<=y) for some distinct expressions
> x,y, yet the JIT will not be able to do this.
>
> Here, x is a.length and y is b.length, and I suppose you want one
> range check to serve for both limits.
>
> With Unsafe you can say in effect "trust me they are the same".
> With VH's you won't be able to.  So there will be places where we
> will have to add new optimizations or repurpose old ones.
>
> In this case, existing range check optimizations may be applicable.
> The current optimizations are able to collect several array lengths
> and determine which is the most restrictive, with respect to a given
> loop body.  That might cover your case also, and many similar ones.
>
> — John