[11] RFR(S): 8209670: CompilerThread releases code buffer in destructor is unsafe
Tobias Hartmann
tobias.hartmann at oracle.com
Tue Aug 21 07:11:30 UTC 2018
Thanks David!
Best regards,
Tobias
On 21.08.2018 09:08, David Holmes wrote:
> Hi Tobias,
>
> This looks good to me too.
>
> Thanks,
> David
>
>> Thanks Vladimir! Could I please get another review for this?
>>
>> Best regards,
>> Tobias
>>
>> On 20.08.2018 19:57, Vladimir Kozlov wrote:
>>> Looks good to me.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 8/20/18 4:06 AM, Tobias Hartmann wrote:
>>>> Hi,
>>>>
>>>> please review the following patch:
>>>> https://bugs.openjdk.java.net/browse/JDK-8209670
>>>>
>>>> Since JDK-8198756 [1], compiler threads can be added and removed at runtime. C1 compiler threads
>>>> use
>>>> a temporary code buffer that is allocated once the thread is created and needs to be freed if the
>>>> thread is removed to avoid a memory leak (see JDK-8205499 [2]). Freeing is currently done in the
>>>> thread destructor after the thread was removed from the thread list. This means that although we
>>>> are
>>>> holding the CodeCache_lock, freeing of the code blob might interfere with non-locking safepoint
>>>> code
>>>> that is concurrently walking the code cache.
>>>>
>>>> The fix is to free the temporary buffers at the two places where compiler threads are removed:
>>>> http://cr.openjdk.java.net/~thartmann/8209670/webrev.00/
>>>>
>>>> This should be safe because it partially restores the code to pre-JDK-8205499. Testing on
>>>> hs-tier1-3, jdk-tier1-3 and hs-precheckin-comp passed.
>>>>
>>>> An alternative would be to disable UseDynamicNumberOfCompilerThreads and do a proper fix in JDK 12:
>>>> http://cr.openjdk.java.net/~thartmann/8209670/webrev.01/
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8198756
>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8205499
>>>>
>
More information about the hotspot-compiler-dev
mailing list