Enable JSR292 support in Shark

[John Rose]

On Dec 6, 2012, at 1:02 PM, Roman Kennke wrote:

> There's one little change in AbstractCompiler: I added a method
> can_compile_method() in order to give me a way to intercept compilation
> for the intrinsics (which are native methods and can not be trapped like
> Java methods). If you know of a better way to achieve this (ideally
> without touching non-Shark code) please let me know.

That seems reasonable, for now, as long as you never call those intrinsics from compiled code, ever.

The new intrinsics are tricky, because they are not allowed to fall back to the normal c2i/i2c adapter paths.  The reason for this is they are sensitive to details of argument packing and ordering, which c2i/i2c transitions disrupt.  Therefore, if one of those intrinsics is ever called from compiled code, it must not go through a c2i transition, but must be handled by a bespoke compiled adapter.  Apparently your change respects this invariant, by refusing to compile the affected call sites.

See:
  https://wikis.oracle.com/display/HotSpotInternals/Linker+methods+for+direct+method+handles

(BTW, I think the community would be grateful if you would add to these pages or adjust them as you "discover" poorly documented parts of the system.  Say the word and I'll give you edit access to the wiki.)

> There's another odd thing that I noticed: ciField->is_constant() doesn't
> (at least not always?) also mean that the field is static. Is this
> correct? The docs for is_constant() seem to imply otherwise.

We are interpreting ciField.is_constant to mean "this field, viewed as a variable, does not change in the future".  In other words, it behaves like we expect a final field to behave, with no allowance for trickery from java.lang.reflect.Field.set.  It does not mean "this field represents a value which is syntactically a constant as defined by the JLS" or "...which has a ConstantValue attribute."

We plan to update this documentation in this patch:
  http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/anno-stable-8001107.patch

> (Infact, I noticed this oddity when attempting to compile the lambda
> forms. I believe I have seen other odd things like calling a non-static
> method with an invokestatic instruction, which tripped an assert.

That should not happen.

> Is it
> possible that those compiled lambda forms do odd (invalid?) stuff like
> that and only get away with it because of some sort of non-strictness in
> the intepreters/compilers?

There is non-strictness in the binding of invokedynamic or invokehandle to target methods.  Specifically, the method bound to an invokedynamic, or the method entered (via a MH) from an invokehandle, can be either static or non-static, as long as its basic type signature matches the call site.  (And by "basic", I mean that references are detuned to Object and subwords like boolean are detuned to int.)  If the method is non-static, it is treated (for such calls) exactly as if it were a static method with a prepended receiver argument.  Also, if the call site features an "appendix" argument, it is treated as if it accepted a trailing reference parameter.

For more details see:
  https://wikis.oracle.com/display/HotSpotInternals/Method+handles+and+invokedynamic

> Maybe I did not look close enough though,
> because I then decided to simply not compile those lambda forms at
> all.. ;-) I guess I will get back to that later when I implement this
> stuff in Shark for real.)

That's reasonable, I think, since those guys call the linker intrinsics which will give you problems (with c2i/i2c as noted above).

> Some opinions on the above would be greatly appreciated.

HTH.  And, seriously, consider being a HSI wiki contributor.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121206/579fe9d5/attachment-0001.html