Request for reviews (L): 6893081: method handle & invokedynamic code needs additional cleanup (post 6815692, 6858164)

Tom Rodriguez Thomas.Rodriguez at Sun.COM
Mon Dec 14 17:08:57 PST 2009

> - Should method handle creation trigger the initialization of the destination class, or should the trigger be deferred until (if ever) the MH is called?  Basically, an MH is a new kind of early linkage, but linkage in the JVM does not trigger initialization; the first call does.  So maybe the long is wrong here.  (Will file a bug and fix later!)
> - Should the call to the compile broker be repeated just after the initialization barrier?  I'm thinking this might be overkill.  If the target method is not compiled, the interpreter entry will cause it to be compiled.  I'm not understanding the reason the compile broker is called from LinkResolver; it seems like a mere -Xcomp hack.

It's the heart of -Xcomp which is essentially a hack.  Part of what confused me in looking at the code is  that is_not_initialized() != !is_initialized() which wasn't obvious.

  bool is_initialized() const              { return _init_state == fully_initialized; }
  bool is_not_initialized() const          { return _init_state <  being_initialized; }

The difference is in how they treat the execution of code during initialization and it's at the heart of my original question.  I was concerned that it would rule out compiling some things that we currently compile in Xcomp mode.  I agree that your original change would have exactly the effect you wanted and no more so I'm ok with it, though a comment on it would be nice.  is_not_initialized could probably be renamed too if you could come up with a better name.  I note that many of the existing uses are !is_not_initialized() suggesting that the sense is wrong.  Having not built into a name is usually a bad idea.


> Let me know what you think...
> -- John

More information about the hotspot-compiler-dev mailing list