ciTypeFlow, osrs and jsr/ret
John.Rose at Sun.COM
Wed Aug 26 18:26:55 PDT 2009
On Aug 25, 2009, at 1:53 PM, Tom Rodriguez wrote:
> My question is which version of the block should ciTypeFlow consider
> to be the canonical one suitable for use by the parser? It seems
> like there's a conflict between the cloning for jsr/ret and
> producing a canonical version suitable for the entry point.
Yes, that's a conflict. The higher_equal assert seems to be saying "I
expect to be running an OSR entry point state that has a return
address set to 537 in local 21, but you are telling me that any old
raw pointer might be in that local 21might contain any old address."
That latter assertion is reasonable for an OSR entry point, since the
interpreter state applies equally to all legal values of local 21, but
the compiled state (apparently) applies only to the value 537. It's
OSR-ing into a finally block, perhaps.
I'm probably missing a bit here, but it seems to me that the block-
splitting performed by ciTypeFlow is going to produce a bunch of
splits for a give bytecoded block, but none of those splits is going
to be suitable as an OSR entry point. Instead, there needs to be some
sort of decision tree at the OSR entry point to pick which block is
going to be used, based on the contents of the locals.
I have a vague recollection that we refuse to create OSR entry points
for some cases like this. Maybe the bug is we're trying to do
something that's impossible (without the as-yet-uncreated decision
tree mentioned above).
More information about the hotspot-compiler-dev