RFR: Make Zero build and run with JDK8

[David Holmes]

On 12/10/2012 7:09 PM, Roman Kennke wrote:
> 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:

Thanks for clarifying. I wasn't sure if the bytecodeInterpreter files 
were "cpp interpreter" specific. I'll pass this back to the compiler 
experts now :)

David

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