[9] RFR(L) 8158168: SIGSEGV: CollectedHeap::fill_with_objects(HeapWord*, unsigned long, bool)+0xa8

[dean.long at oracle.com]

On 3/16/17 2:52 AM, Tobias Hartmann wrote:
>> As a safety net, I added asserts around the intrinsic calls, and a try/catch that so any out of bounds exception turns into an assert error as well.
> So the assert and try/catch are only necessary to catch invalid offsets passed to the C1 intrinsic, right? Interpreted code is safe and the C2 intrinsics have additional guards in debug builds.
>
>
> I'm fine with that but an alternative would be to also have such guards in the C1 intrinsic. For example, one could enable the normal bound checks and add a simple check to Runtime1::throw_range_check_exception() that fails if the throwing method is the C1 intrinsic. Like this, we could avoid the assert, try-catch and DEBUG_INTRINSICS code.
>

On 3/16/17 11:09 AM, Vladimir Ivanov wrote:

>
>> The changes to the JDK core classes are quite extensive. This will need
>> rigorous functional and performance testing and it is very late in the
>> release cycle to make these kinds of changes. But I'll leave that to the
>> core-libs folk to comment on.
>
> I have the same concern. Can we fix the immediate problem in 9 and 
> integrate verification logic in 10?
>

OK, Tobias is suggesting having verification logic only inside the 
intrinsics.  Are you suggesting removing that as well?

I'm OK with removing all the verification, but that won't reduce the 
library changes much.  I could undo the renaming to Trusted.getChar, but 
we would still have the bounds checks moved into StringUTF16.

dl

> Best regards,
> Vladimir Ivanov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20170316/d5619bd2/attachment.html>