[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-compiler-dev
Subject:    [9] RFR(S): 8159129: TestStringIntrinsicRangeChecks fails w/ No exception thrown for compressByte/in
From:       Tobias Hartmann <tobias.hartmann () oracle ! com>
Date:       2016-06-29 10:57:10
Message-ID: 5773A986.4090106 () oracle ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]