RFR(M): 8223051: support loops with long (64b) trip counts

[Roland Westrelin]

> Sorry, I don't get it. Normally JVM state associated with a call is a 
> state right after the call returns. Do you mean there are cases when 
> call has reexecute bit set and hence it has JVM state before the call 
> associated with it?

JVM state at a call can't be state after the call because it would need
to capture the return value which can't be an incoming edge to the call,
right?

> Anyway, it's trivial to convert between 2 states (before and after) and 
> we already do that in some places (e.g., late inline prepares JVM state 
> for the parser based on the state associated with CallStaticJava node).

Sure it's feasible to build state after the call. I was concerned that
the runtime would hardwire somewhere that state at the call is always
state before the call. That would lead to nasty, rare and hard to debug
failures. It felt a lot simpler and robuster to leave SafePoint nodes in
the graph. We could have the patch go through a performance run and see
if that change makes any difference if there's concern about it.

Roland.