[9] RFR(S): 8159129: TestStringIntrinsicRangeChecks fails w/ No exception thrown for compressByte/inflateByte
Tobias Hartmann
tobias.hartmann at oracle.com
Mon Jul 4 06:02:43 UTC 2016
Hi,
could I please get a review?
Thanks,
Tobias
On 29.06.2016 12:57, Tobias Hartmann wrote:
> Hi,
>
> please review the following patch:
>
> https://bugs.openjdk.java.net/browse/JDK-8159129
> http://cr.openjdk.java.net/~thartmann/8159129/webrev.00/
>
> The test fails because the inflate/compress String intrinsic sometimes does not throw an exception if the src or dst offset are out of bounds. The problem is that we convert the char offsets to byte offsets only after the range check. We should do this before. To avoid such errors, we should try to move the range checks from the intrinsics into the Java code (I'll investigate this with JDK-8156534).
>
> I also slightly adapted the test to trigger this problem more often. Before, the intrinsic was not always used because the compile threshold wasn't reached or we issued too many compilations and the test finished before the compiled method was available.
>
> I noticed that in Compile::too_many_traps() we "// Assume PerBytecodeTrapLimit==0, for a more conservative heuristic." and therefore stop using the intrinsic if too many traps occurred even though PerBytecodeTrapLimit was not yet reached. Shouldn't we check something like "md->trap_count(reason) > PerBytecodeTrapLimit"?
>
> Tested with JPRT and RBT (running).
>
> Thanks,
> Tobias
>
More information about the hotspot-compiler-dev
mailing list