Bug ID: JDK-7004570 bad graph running pisces.Test

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 7
7Resolved

I was able to reproduce it running the classes with these arguments:

java -d64 -cp pisces.jar -XX:+PrintCompilation -Xbatch -XX:OnStackReplacePercentage=60 pisces.Test
I was working on the pisces rendering engine using eclipse and I
encountered a segfault. I was using the pisces/Test.java file
to test various parts of the rendering engine without having to rebuild
openjdk. In it, I create a Frame whose paint method creates a Path2D,
a Stroker and a Dasher. Then the path is fed to the Dasher (but it is not
drawn because this is unnecessary to make it crash), and eventually
Stroker.somethingTo is called, which is where the crash occurred. However,
it only happened when I accidentally left uncommented the rest of
main, which creates other Stroker and Dasher objects and feeds lots of
curves to them and measures how long this processing takes. Even then,
it only happens if one grabs the window and moves it on and off screen,
causing the paint method to be called. I tried putting a repaint() call
at the end of paint() so that I wouldn't have to do any manual work,
but that didn't work. It is reproducible using an awt.Robot, but not
as frequently as manually.

When I remove the Frame creation and leave just the performance measuring
part of main(), it doesn't crash. It also doesn't crash when I remove
the performance measuring part of main() and leave just the graphical
part of the program. I tried reproducing it using a debug build of hotspot,
but I couldn't. This all suggests that it's a concurrency issue, so I
wrote a new main that simply created a few threads where each thread
created Dasher and Stroker objects and fed curves to them, but this didn't
crash.

Another important thing is that I was only able to reproduce it when the
files in pisces.tar.gz were compiled using ecj - not javac.

I've seen over 30 hs_err_pis*.log files produced by this crash and every one
of them says:
C2: [2|3]% pisces.Stroker.somethingTo(I)V @ 710 (1190 bytes)

where line 710 corresponds to line 830 in Stroker.java, which is a call to
it.next() where "it" is an anonymous Iterator<float[]> object.

EVALUATION I actually diagnosed this is a little while back but I guess I never updated the bug report. It's our old fiend ConvI2L. Basically we unswitch his loop but happen to pick a test which is actually an impossible value. This causes one of the values leading out of the loop to be a negative constant which would cause the final loop index operation to throw an exception. The constant causes a ConvI2L that's constrained to be a positive int to collapse to top and the graph shape gets screwed and we die. We've been able to band aid over the ConvI2L so far but I don't see an obvious way to fix this one. The only 'fix' I can come up with is to have ConvI2L::Ideal detect when it's type constraint is no longer valid and replace itself with an unconstrained version. We'd probably need to modify Identity to not allow itself to be invalidated if the type of the input and it's type are disjoint. Basically this would all work if node didn't go away but I'm afraid that would cause other weird bugs.

18-03-2011