Request for reviews (S): 7044725: -XX:-UnrollLimitCheck -Xcomp : Exception: String index out of range: 29488 (original) (raw)

Vladimir Kozlov vladimir.kozlov at oracle.com
Mon May 16 10:10:56 PDT 2011

After thinking more about pre_limit guard in do_range_check() "min(pre_limit, orig_limit)" I decided to always generate it to be safe. The offset and scale in RC condition could have such values that X=(low_limit-offset)/scale will be outside of loop iterations range: max(pre_limit, X) could be > orig_limit. This change does not invalidate previous testing but I redo it again.

Thanks, Vladimir

Vladimir Kozlov wrote:

http://cr.openjdk.java.net/~kvn/7044725/webrev

Fixed 7044725: -XX:-UnrollLimitCheck -Xcomp : Exception: String index out of range: 29488 The main problem in new RCE code was in case when stride and scale have different sign. In that case new mainloop limit was calculated as min(oldmainlimit, X) where X=(minint+1 - (offset+1))/scale. With offset 0 and scale == -1, X value is minint since minint/-1 = minint. So the new main loop limit is minint. New unrolling code correctly handles such case by skipping main loop. Old code did ((limit -init)/stride) with stride == 1 and init == 1 (value after increment in preloop). So new limit for unrolled loop become (minint-1) == maxint. I solve this by replacing positive (offset+1) with 0 and avoiding underflow in X calculation. It is the same approach as one used in current code for prelimit in case scale and stride have the same sign. An other problem with new code is it does not generate the adjusted pre-loop limit when RangeLimitCheck is off. RCE old code did it before. I also factor out common code, replaced (stride*scale) with logical expressions to avoid overflow and I removed obsolete code which generates additional guard for prelimit since it was added before adjustlimit() starts handle such case. Tested with/without UnrollLimitCheck CTW, JPRT, nsk.stress, 5091921 tests.

More information about the hotspot-compiler-dev mailing list