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

[Coleen Phillimore]

On 3/25/15, 7:59 PM, David Holmes wrote:
> Hi Coleen,
>
> Why generate stubs that can't be used and then add zero-specific logic 
> to the shared CanUseSafeFetchN instead of not generating the stubs so 
> that CanUseSafeFetchN will return false anyway ??

Because there is platform independent code in objectMonitor.cpp that 
uses SafeFetchX (both).  I'd rather not burden the caller of this with 
testing CanUseSafeFetchX for each call.   This code existed before 
SafeFetch was implemented, so I'm restoring previous behavior for Zero.

We could file an RFE to either implement SafeFetch for Zero or rewrite 
this objectMonitor code to not need SafeFetch.  I didn't want to do 
either of these things with this patch.

Coleen

>
> Thanks,
> David
>
> On 26/03/2015 3:53 AM, Coleen Phillimore wrote:
>> Summary: Implement SafeFetchX unsafely and make CanUseSafeFetchX false
>> for Zero
>>
>> Also, this fixes a couple other minor issues.
>>
>> Ran jdk9 jck tests with one timeout.  hotspot/runtime jtreg tests don't
>> run because Zero doesn't support UseCompressedOops (not sure why) and
>> CDS (know why).
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8075967/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8075967
>>
>> Thanks,
>> Coleen