Enable JSR292 support in Shark

[Roman Kennke]

Hi John,



> > 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.
> 

I see. I sortof learned that. The hard way  ;-)

> 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.)

Cool, somehow I managed to not find these docs when I implemented the
interpreter part of this a while back and figured out everything by
taking apart the assembly stuff in the template interpreter. (I believe,
the Zero impl does make for nice documentation now though, the code came
out surprisingly straightforward. If you're interested, it's all in
methodHandles_zero.cpp).

> > 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."

Uhh, ok, so I need to change some more code (mainly asserts) to
is_final() && is_static() or such ;-)

> 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.

I will look at it again, and see what exactly happened.

> > 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.

Ok this makes sense.

> 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.

Thanks a lot for your explanations, it's really helpful. I would like to
(potentially) contribute to the HSI wiki, if you want to give me
access :-)

Cheers,
Roman