Request for reviews (S): 6823453: DeoptimizeALot causes fastdebug server jvm to fail with assert(false,"unscheduable graph")

[Tom Rodriguez]

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?

tom

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.
>
> Thanks,
> Vladimir
>
>
> http://cr.openjdk.java.net/~kvn/6823453/webrev.01
>
> Fixed 6823453: DeoptimizeALot causes fastdebug server jvm to fail  
> with assert(false,"unscheduable graph")
>
> Problem:
> 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.
>
> Solution:
> Don't replace a value with TOP.
> Added regression test.
>
> Reviewed by:
>
> Fix verified (y/n): y, bug tests
>
> Other testing:
> JPRT
>