RFR: 8146705: Improve JVMCI support for blocking compilation
Christian Thalinger
christian.thalinger at oracle.com
Mon Jan 11 21:08:19 UTC 2016
> On Jan 11, 2016, at 10:15 AM, Doug Simon <doug.simon at oracle.com> wrote:
>
>
>> On 11 Jan 2016, at 20:57, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>
>> It’s #ifdef vs. #if:
>>
>> +#ifdef INCLUDE_JVMCI
>
> No, I think it’s the other way around (i.e. #if instead of #ifdef) judging by the rest of the code guarded by this macro.
Sorry, that’s what I meant; it should be #if.
>
> -Doug
>
>>
>> I’ll fix it.
>>
>>> On Jan 11, 2016, at 9:55 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>>
>>> …or not:
>>>
>>> /scratch/jprt/T/P1/192954.cthaling/s/hotspot/src/share/vm/runtime/advancedThresholdPolicy.cpp: In member function 'virtual CompileTask* AdvancedThresholdPolicy::select_task(CompileQueue*)':
>>> /scratch/jprt/T/P1/192954.cthaling/s/hotspot/src/share/vm/runtime/advancedThresholdPolicy.cpp:201:9: error: 'UseJVMCICompiler' was not declared in this scope
>>> if (UseJVMCICompiler && task->is_blocking()) {
>>> ^
>>> /scratch/jprt/T/P1/192954.cthaling/s/hotspot/src/share/vm/runtime/advancedThresholdPolicy.cpp:202:11: error: 'max_blocking_task' was not declared in this scope
>>> if (max_blocking_task == NULL || compare_methods(method, max_blocking_task->method())) {
>>> ^
>>>
>>>
>>>> On Jan 11, 2016, at 8:35 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>>>
>>>>>
>>>>> On Jan 11, 2016, at 7:30 AM, Doug Simon <doug.simon at oracle.com> wrote:
>>>>>
>>>>>>
>>>>>> On 11 Jan 2016, at 18:23, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>>>>>
>>>>>>
>>>>>>> On Jan 11, 2016, at 3:18 AM, Doug Simon <doug.simon at oracle.com> wrote:
>>>>>>>
>>>>>>> The CompileBroker currently uses a simple timeout of 1 second when waiting for a blocking JVMCI compilation to complete. This approach is too simple. JVMCI compiler threads themselves flood the compilation queues with compilation requests; such compilations cannot be blocking (the JVMCI compiler can easily cause the system to deadlock). This flooding means that application submitted tasks often timeout before the tasks even start compiling.
>>>>>>> Once a JVMCI thread starts compiling a task, there is still the risk of it deadlocking. The current timeout mechanism needs to be augmented with a test of the compiler thread's state. As long as it's not blocked for too long, we know the compiler is making progress and will eventually complete.
>>>>>>>
>>>>>>> This review is for changes that address the above issues as follows:
>>>>>>>
>>>>>>> 1. Non-blocking tasks are selected before blocking tasks from the compilation queue.
>>>>>>
>>>>>> Aren’t blocking tasks selected before non-blocking tasks?
>>>>>
>>>>> Yes, exactly the opposite of what I said ;-) I’ve fixed the bug description and thankfully got the implementation the right way round.
>>>>
>>>> Then it looks good :-)
>>>>
>>>>>
>>>>> -Doug
>>>
>>
>
More information about the hotspot-compiler-dev
mailing list