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

[David Holmes]

On 26/03/2015 10:04 AM, Coleen Phillimore wrote:
>
> 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.

Sorry Coleen I thought this was deal to with 8075533, I hadn't realized 
8075533 broke the objectMonitor code and this was a follow up.

What a mess. :(

Thanks,
David



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