RFR: Make Zero build and run with JDK8

[Christian Thalinger]

On Oct 11, 2012, at 1:51 PM, Roman Kennke <rkennke at redhat.com> wrote:

> Hi Christian,
> 
> Thanks for the fast reply!
> 
>>>> 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/
>> 
>> src/share/vm/asm/codeBuffer.cpp:
>> 
>> -  if (dest->blob() == NULL) {
>> +  if (dest->blob() == NULL && dest_filled != 0x0) {
>> 
>> Do we really need this when you have this:
> 
> The above is needed, because the loop above it that initializes
> dest_filled is never executed. However, I will change the test to
> dest_filled != NULL :-)
> 
>> static void pd_fill_to_bytes(void* to, size_t count, jubyte value) {
>> 
>> -  memset(to, value, count);
>> +  if ( count > 0 ) memset(to, value, count);
>> 
>> }
> 
> Turns out that this is 1. not related to the other change above and 2.
> not needed. I'll remove it.
> 
>> src/share/vm/interpreter/interpreter.cpp:
>> 
>> -  assert(_entry_table[kind] == _entry_table[abstract], "previous value must be AME entry");
>> +  assert(_entry_table[kind] == NULL || _entry_table[kind] == _entry_table[abstract], "previous value must be AME entry or NULL");
>> 
>> Why did you need that change?
> 
> Apparently, before the whole table was initialized, and the methodhandle
> related entries left as abstract. Now the methodhandle entries are
> simply left to NULL. I suppose we could change the assert to 
> 
> assert(_entry_table[kind] == NULL, "previous value must be NULL");
> 
> Alternatively, we could fix the code that puts the other entries to also
> set the methodhandle entries to AME and go back to the original assert.
> What do you think?

TemplateInterpreterGenerator::generate_all sets all MH entries to AME:

  // method handle entry kinds are generated later in MethodHandlesAdapterGenerator::generate:                                                                  
  for (int i = Interpreter::method_handle_invoke_FIRST; i <= Interpreter::method_handle_invoke_LAST; i++) {                                                      
    Interpreter::MethodKind kind = (Interpreter::MethodKind) i;                                                                                                  
    Interpreter::_entry_table[kind] = Interpreter::_entry_table[Interpreter::abstract];                                                                          
  }                                                                                                                                                              

You need similar code in Zero.

-- Chris

> 
> Roman
> 
>> -- Chris
>> 
>>>> 
>>>> 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.
>>> 
>>> You may want to run something like JRuby as well.
>>> 
>>>> 
>>>> 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 ?
>>> 
>>> Yes, you do.  Here is the bug:
>>> 
>>> 8000780: make Zero build and run with JDK8
>>> 
>>> I'm reviewing the changes right now...
>>> 
>>> -- Chris
>>> 
>>>> 
>>>> And in case this is not the correct mailing list, please fwd to and/or
>>>> CC the correct list.
>>>> 
>>>> Thanks and kind regards,
>>>> Roman
>>>> 
>>>> 
>>> 
>> 
> 
>