A question on HotSpot's compilation triggering

[Paul Hohensee]

Sorry to have taken so long to get back to you.  The place to ask this 
question is
on hotspot-compiler-dev at openjdk.java.net and/or 
hotpot-runtime-dev at openjdk.java.net,
but I'll do my best to answer here.  Hopefully the experts will correct 
me if I'm wrong. :)

Short answer to first question, you're right, OSR compiles are done 
asynchronously and I'll
have to change the slide.  I have no idea why I had the idea they were 
synchronous.
Detail below.

Second question answer is yes, I believe that with the introduction of 
lazy deopt in 5.0,
all deopts, including OSR, are synchronous.

Third question answer is that there are no other thread suspension 
mechanisms in
Hotspot except polling, _except_ for the implementation of Thread::stop, 
Thread::suspend
and Thread::resume, all of which are deprecated.  Hotspot doesn't use 
uncooperative
thread suspension for the same reason these methods are deprecated, 
namely the
possibility of deadlock.  Also, solaris and linux have problems with 
delivering
spurious signals, untimely signals (the target thread may not run for a 
long time
after it's signaled), and even never-delivered signals.

frequency_counter_overflow_inner() cranks up an asynch compile as you 
describe,
but then immediately calls lookup_osr_nmethod_for(), which returns NULL 
if the
OSR compile isn't finished yet, which causes 
frequency_counter_overflow_inner()
to return NULL after resetting the back branch overflow counter to a 
smaller value.
via reset_counter_for_back_branch_event().  If you go all the way back 
to the
interpreter's call to frequency_counter_overflow in, e.g., 
interp_masm_sparc.cpp,
you see that if the interpreter gets NULL back, it just keeps going in 
the interpreter
with the newly reduced backbranch counter threshold.  Hopefully by the 
time the
counter overflows again, the compilation will be done.

Regards,

Paul

Krystal Mok wrote:
> Hello Paul,
>
> This is Kris Mok. I read the slides for your presentation in 
> Princeton, here: 
> http://www.cs.princeton.edu/picasso/mats/HotspotOverview.pdf
>
> I'd like to ask a few questions:
> On page 8 of the slides, it says OSR is synchronous, but I seem to 
> find that compilations triggered by backedge counter overflow isn't 
> always synchronous -- it's controlled by BackgroundCompilation flag in 
> CompileBroker. I found in interpterRuntime.cpp, in 
> method InterpreterRuntime::frequency_counter_overflow(), the call that 
> triggers OSR compilation is:
>   CompilationPolicy::policy()->method_back_branch_event(method, 
> branch_bci, bci, CHECK_NULL);
> and then all the way into CompileBroker::is_compile_blocking(), which 
> just returns !BackgroundCompilation. If BackgroundCompilation is true 
> (which is so by default) than the compilation would go asynchronous, 
> returning null to the interpreter, and carry on interpreting until the 
> next time there's a chance to switch to compiled code.
> Did I miss anything? Is OSR actually synchronous when triggered by 
> backedge overflow? And is OSR synchronous in deoptimization?
>
> Another question would be: are there any other thread suspension 
> mechanisms used in HotSpot other than polling? Does it ever do thread 
> hijacking or hard suspension or the like?
>
> Thank you in advance. Hopefully this email isn't too much of a 
> trouble. ^_^
>
> Sincerely,
> Kris Mok