[9] RFR (M): VM should constant fold Unsafe.get*() loads from final fields

[Paul Sandoz]

Hi Vladimir,

I like the test, you have almost hand rolled your own specializer :-)

A minor point. Since you have created a ClassWriter with "ClassWriter.COMPUTE_MAXS | ClassWriter.COMPUTE_FRAMES" can you remove the "mv.visitMax(0, 0)" calls?


I was a little confused by the code that checked the expected result against the actual result.

I am guessing the white box methods return -1 if the value is not a constant and 1 if it is. (Perhaps that can be documented, if even those methods may eventually reside somewhere else.) Whereas, Generator.expected returns 0 or 1.

 118         if (direct != unsafe || // difference between testDirect & testUnsafe
 119             (unsafe != -1 && expected != unsafe)) // differs from expected, but ignore "unknown"(-1) result
 120         {
 121             throw new AssertionError(String.format("%s: e=%d; d=%d; u=%d", t.name(), expected, direct, unsafe));
 122         }

I don't quite understand why  "unknown"(-1)  can be ignored.

Can that be changed to the following if Generator.expected returned the same values as the WB methods?

  if (direct != unsafe || unsafe != expected) { ... }

?

Paul.

On Jun 17, 2015, at 6:38 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> http://cr.openjdk.java.net/~vlivanov/8078629/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8078629
> 
> Direct(getfield/getstatic) read operations are faster than unsafe reads from constant Java fields, since VM doesn't constant fold unsafe loads. Though VM tries hard to recover field metadata from its offset, it doesn't optimize unsafe ones even if it has all necessary info in its hands.
> 
> The fix is to align the behavior and share relevant code between C2 parser and intrinsic expansion logic.
> 
> For testing purposes, I extended whitebox API to check whether a value is a compile-time constant. The whitebox test enumerates all combinations of a field and ensures that the behavior is consistent between bytecode and unsafe reads.
> 
> Testing: focused whitebox tests, hotspot/test/compiler, jdk/test/java/lang/invoke, octane (for performance measurements)
> 
> Thanks!
> 
> Best regards,
> Vladimir Ivanov

-------------- 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/20150618/ad729cf3/signature.asc>