On Sat, Aug 1, 2009 at 6:03 AM, Thomas E Enebo<[email protected]> wrote:
> I may even suggest taking it a step further and isolating the failure
> cases to a synthetic method (sans the invocation to the synthetic
> method). The smaller we generate sections of code the easier things
> will be for hotspot. I guess I am talking about actual JVM bytecode
> at this point and not IR...
Yeah, I've been thinking the same thing...so it's more like
if (class version guard succeeds) {
inlined or static call
} else {
deoptimized_method_from_line_5(current_state)
}
By shunting as much as possible into separate synthetic methods, we
give hotspot a nice, small target for its own optimization and leave
the deoptimized paths external to the fast path code. The only
question I have right now is how to do this without still bloating the
code way up and how to make sure the deopted version can pick up where
optimized version left off. I think it's doable, but it will be a
balancing act.
> Yeah, I agree. I always envisioned version guards had to be
> somewhere, but this all looks like we will actually be able to follow
> this logic in the future since it will be directly in the IR.
In the IR and reducible/coarsenable before ever reaching bytecode too.
So we can distil down the IR to as little guard work as possible
before even emitting it.
Exciting stuff :)
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
