A question on HotSpot's compilation triggering

Krystal Mok rednaxelafx at gmail.com
Mon Mar 15 18:41:15 PDT 2010

@Paul Hohensee
@David Holmes

Thank you both so much for taking the time to answer my question. It really
helped. HotSpot is such a beast that it's so hard to be certain about
details in a comprehensive way. Counting on you guys for further details.
Thanks again!

Kris Mok

On Tue, Mar 16, 2010 at 7:41 AM, David Holmes <David.Holmes at oracle.com>wrote:

> Paul Hohensee said the following on 03/16/10 08:57:
>  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.
> Just to clarify, even the deprecated suspend/stop use polling based
> mechanisms these days. A thread is only suspended, or throws an
> async-exception, when it is safe to do so with regard to its execution in
> the VM.
> The only place we use signals to mimic suspend/resume type functionality is
> profiling the VMThread by the FlatProfiler.
> Cheers,
> David Holmes
>  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20100316/c7a21bb2/attachment.html 

More information about the hotspot-runtime-dev mailing list