http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009090.html

This patch enables JSR292 support in Shark. It's cheating though: for
everything related to JSR292 it basically reverts to the interpreter
(Zero.. which does implement JSR292).

http://cr.openjdk.java.net/~rkennke/shark-jsr292/webrev.00/

More specifically, it refuses to compile all methods that have an or
invokedynamic, invokehandle instruction or which do call out to one of
the 4 MH/varargs intrinsics or which are themselves a compiled
lambda-form. It also does not compile a native wrapper for those
intrinsics, because we need to call the interpreter entry points. Native
wrappers would throw UnsatisfiedLinkError because there is no
corresponding native method available.

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.

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.

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

Some opinions on the above would be greatly appreciated.

(That's the last patch in this series for now.)

Best regards,
Roman