On Wed, 29 May 2024 07:42:01 GMT, Johan Sjölen <jsjo...@openjdk.org> wrote:

>> In `JvmtiUtil::single_threaded_resource_area()`, we create a resource area 
>> that is supposed to work even if the current thread is not attached yet and 
>> there is no associated Thread or the Thread has no valid ResourceArea.
>> 
>> It contains a workaround:
>> 
>> 
>>     // lazily create the single threaded resource area
>>     // pick a size which is not a standard since the pools don't exist yet
>>     _single_threaded_resource_area = new (mtInternal) 
>> ResourceArea(Chunk::non_pool_size);
>> 
>> 
>> It specifies a non-standard chunk size to circumvent the chunk-pool-based 
>> allocation in the RA constructor, ensuring that only malloc is used. This is 
>> because in the old days the ChunkPools had been allocated from C-Heap and 
>> there was a time window when no chunk pools were live yet.
>> 
>> This is quirky and a bit ugly. It is also unnecessary since 
>> [JDK-8272112](https://bugs.openjdk.org/browse/JDK-8272112) (since JDK 18). 
>> We now create chunk pools as global objects, so they are live as soon as the 
>> libjvm C++ initialization ran. We can remove this workaround and the comment.
>> 
>> ---
>> 
>> Tests: GHAs.
>> I also manually called this function, and allocated from the resulting 
>> ResourceArea, at the very beginning of CreateJavaVM. I made sure that both 
>> allocations and follow-up-chunk-allocation worked even this early in VM life.
>
> Today, the ChunkPools are allocated before main through static 
> initialization. That means that the ChunkPools exists when main starts 
> executing, so this is safe.

Thanks @jdksjolen and @sspitsyn !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19425#issuecomment-2141338912

Reply via email to