RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor

[Coleen Phillimore]

>> My goal at the moment was to see how well Zero works.  I don't know how
>> well supported this variant is.
> I'd be very interested to hear on how you determine how well Zero works.
> Use the TCK? Some other metric? As for jtreg tests, many of them fail
> trivially because they assume there is server and client JVMs only (e.g.
> tools/launcher/VersionCheck.java in JDK).

I ran the JCK9 tests with one timeout, which is sort of expected since 
Zero is interpreted only without Shark.

The hotspot runtime jtreg tests do poorly because CompressedOops aren't 
supported.  I don't know why they aren't supported.  When I took out the 
code to disable CompressedOops, more tests passed.

Zero doesn't support CDS because metaspaceShared_zero.cpp needs some 
generated code that isn't done with Zero.
>
> With that being said, Zero should be in better shape now than it was a
> while ago. Back then, it wouldn't even compile in latest upstream
> trees...

Yes, I heard that it works fairly well in jdk8 so getting it to work for 
jdk9 was just accounting for new changes.
>
> Depending on available cycles I'll try to help as much as I can. The
> best metric we have currently for Zero is its ability to build itself.
> I've never managed to go through all failing jtreg tests and determine
> exactly what's wrong (test or JVM failure).
>
>> It seems to be missing a lot.
> Right. A good starting point is making people aware that it exists so
> that no new compilation errors get introduced. You've been doing a great
> job at this. Thanks! My goal is to make Zero better over time, since
> it's been lacking basic maintainership for a while in upstream OpenJDK.
>
> Aside: Zero is using the C++ interpreter which AFAIK, isn't used much
> anywhere else. Most (all?) JIT ports use the template interpreter these
> days.

Most ports use the template interpreter because it's significantly 
faster, but the Zero interpreter by not having any generated native code 
makes getting a new port running faster.  It also may be nice to 
prototype new bytecodes in C++ rather than as macro assembler. And it's 
sort of cool.

Yes, Zero uses interpreter/bytecodeInterpreter.cpp which is written in 
C++.   What we call the C++ interpreter is something else that also uses 
bytecodeInterpreter.cpp.

https://bugs.openjdk.java.net/browse/JDK-8074457

Keeping Zero compiling and running is not part of our normal testing, so 
most of the contributions are coming from outside Oracle for this.

Coleen
>
> Thanks,
> Severin
>
>> Thanks,
>> Coleen
>>
>>> Changes look fine to me.
>>>
>>> Cheers,
>>> Severin
>>>
>>>> Thanks,
>>>> Coleen
>>>
>
>