RFR: Make Zero build and run with JDK8

[Roman Kennke]

Hi David,

> Disclaimer: I am not a compiler/interpreter expert :)
> 
> Can you explain the need for the changes to the shared code regarding 
> MethodHandles and general jsr292 stuff. Are there bugs in the existing 
> interpreter, or do these changes only affect the interpreter as used by 
> Zero (cpp interpreter vs template interpreter?)

Sure. First, most changes affect only the zero (cpp) interpreter indeed.
Let me explain the changes by file, for the files not ending in _zero:

bytecodeInterpreter.cpp:
- Added invokehandle instruction handler.
- Modified invokedynamic instruction handler for the changed constant
pool cache entry (method now in f1).
- Some modifications to follow changed APIs: e.g. stuff like cache->f1()
-> f1_as_klass()

bytecodeInterpreter.hpp:
- Removed call_method_handle interpreter command, is no longer needed.

cppInterpreter.cpp
- Added native method-entry for math_pow and math_exp. Those have been
added elsewhere but cppInterpreter has been forgotten.

interpreter.cpp
- Changed assert because _entry_table is no longer initialized with AME
for the method handle entries (see discussion with Christian in same
thread).

vmStructs.cpp:

- Don't do declare_constant(frame::entry_frame_call_wrapper_offset) for
ZERO.

macros.hpp:

- Added macros ZERO_ONLY and SHARK_ONLY, used in, e.g. vmStructs.cpp

Overall, I don't think any of this is really 'shared' (or is
cppInterpreter/bytecodeInterpreter used anywhere else other than zero?)

Kind regards,
Roman

> 
> Thanks,
> David
> 
> On 12/10/2012 12:55 AM, Roman Kennke wrote:
> > Hello,
> >
> > In the recent weeks I worked on the Zero interpreter, to get it to build
> > and run with JDK8, and in particular with the latest changes that came
> > from mlvm (meth-lazy). The following webrev applies to hsx/hotspot-main:
> >
> > http://cr.openjdk.java.net/~rkennke/zerojdk8/webrev.00/
> >
> > A few notes on the patch:
> > - Some makefile changes have been necessary to get it to build at all.
> > - A bunch of stub functions needed to be added to make the compiler
> > happy, they should not be called though.
> > - Most of the changes are related to JSR292 stuff, in particular the
> > added invokehandle handler, and the changes to invokedynamic resulting
> > from how the constant pool entry has changed (e.g. method is now in f1).
> > - A lot of code relating to JSR292 could be removed because most of the
> > logic has been moved to the (Java) lambda forms.
> > - A few native methods have been added (MH.invokeBasic(),
> > MH.linkToVirtual(), MH.linkToStatic() MH.linkToSpecial()).
> >
> > With those changes it's possible to build the Zero-JDK with itself, and
> > run the JSR292 related jtreg testcases. I did not (yet) attempt to run a
> > TCK or such, this would have to wait until all this gets backported to
> > JDK7 anyway, and I wanted to get some feedback on the changes first.
> >
> > So what do you think?
> >
> > And what are the next steps to (hopefully) get those changes committed?
> > I guess I need a bug-ID and formal review ?
> >
> > And in case this is not the correct mailing list, please fwd to and/or
> > CC the correct list.
> >
> > Thanks and kind regards,
> > Roman
> >
> >