RFR: Make Zero build and run with JDK8

[Roman Kennke]

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?

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