RFR(XS): 8073796: assert(check_obj_alignment(result)) failed: address not aligned: ...

[Roland Westrelin]

Thanks for looking at this, Vladimir.

>> In the Arrays.copyOf intrinsic, when deoptimization happens between the array allocation and the array copy itself, a non initialized array can become visible to the GC (the array copy does the initialization). The array is not referenced for anywhere so this failure is specific to CMS. The fix consists in moving the allocation after the uncommon traps.
>> 
>> http://cr.openjdk.java.net/~roland/8073796/webrev.00/
> 
> Yes, array allocation and arraycopy should stay together.
> May be when we expand arraycopy node we should verify that there is nothing in between - something similar to tightly_coupled_allocation() we had before. Otherwise we need to clear array before arraycopy.

Can I consider this reviewed?

> I agree that 8064703 fix was not correct - we should not have any deoptimizations in between.

I filed https://bugs.openjdk.java.net/browse/JDK-8073866

Roland.

> 
> Thanks,
> Vladimir
> 
>> 
>> A follow up to this fix is the realization that the fix for the similar issue:
>> 
>> 8064703: crash running specjvm98's javac following 8060252
>> 
>> that makes deoptimization in arraycopy restart execution at the tightly coupled allocation is not robust enough. It leaves an uninitialized unreferenced array in the heap. That could break with CMS. As pointed to me by GC folks, VerifyGC or anything that walks the entire heap could break as well. So we need to either disabled the optimization that looks for tightly coupled allocations with CMS + VerifyGC etc. or find another way to fix the problem (do the zeroing right before the uncommon trap? In the deoptimization code? Move the guards before the allocation?)
>> 
>> Roland.
>>