Request for reviews (S): 6823453: DeoptimizeALot causes fastdebug server jvm to fail with assert(false,"unscheduable graph")
Thomas.Rodriguez at Sun.COM
Wed Apr 1 13:07:33 PDT 2009
Isn't this just delaying the problem? If you hide the negative value
behind something that won't get simplified until the full igvn pass
then you're back where you started, aren't you? Or is this something
that would only be a problem during parse?
The root of the problem is that the negative length effectively proves
that the control flow following the allocation is all dead since it
will throw an exception but our graph doesn't express this. The
allocation stays around and simply becomes a slow path call that will
throw the exception but any control flow that follows it is actually
dead but can't fold up. Maybe we need to hammer the fall through
projection of the AllocateArrayNode to be a HaltNode to indicate that
the fall through path is unreachable?
On Apr 1, 2009, at 11:57 AM, Vladimir Kozlov wrote:
> I added test case suggested by John.
> I also replaced the code in GraphKit::new_array
> with the _gvn.transform(ccast) call and the result's
> type check as John suggested. I think it is safe
> to not delay the transform() call since the TOP result
> will not be used.
> Fixed 6823453: DeoptimizeALot causes fastdebug server jvm to fail
> with assert(false,"unscheduable graph")
> The code in GraphKit::new_array replaces a negative value with
> TOP (CastII(-1)#0) for all uses if it is used as new array length.
> Incorrect ideal graph is generated as result.
> Don't replace a value with TOP.
> Added regression test.
> Reviewed by:
> Fix verified (y/n): y, bug tests
> Other testing:
More information about the hotspot-compiler-dev