Failing typeflow responsibility assertions

Gary Benson gbenson at
Thu May 22 02:17:25 PDT 2008

John Rose wrote:
> On May 20, 2008, at 12:44 AM, Gary Benson wrote:
> > So does the ciTypeFlow pass actually load the unloaded classes for
> > you?
> No, the JIT tries pretty hard not to load classes.  IIRC, the only
> exception to this rule is the call to load_signature_classes in
> compileBroker.cpp.

So the 'assert(will_link, "typeflow responsibility")' bits aren't
being hit because the typeflow pass bails out?  (ie env()->failing()
returns true?)  Will the compile broker retry the compilation later?

> JIT compilation should be transparent to Java execution, but loading
> classes causes class loader code to execute.  If the JIT causes
> bytecode execution, then the JIT can cause application state
> changes, which explores new application states unnecessarily.  This
> can expose JIT-entangled bugs in the application.  You want this in
> stress testing, but not in the field.
> The JVM spec. allows class loading--not initialization--for any
> reason, but it's better (for system reproducibility) if the JIT has
> no detectable effect on app. state except speedups.

That makes sense :)



More information about the hotspot-compiler-dev mailing list