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
