RFR: JDK-8256844: Make NMT late-initializable [v2]
Thomas Stuefe
stuefe at openjdk.java.net
Wed Aug 4 12:21:37 UTC 2021
On Mon, 2 Aug 2021 14:24:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>>> This is an interesting and it seems a better way to solve this problem. Where were you all those years ago?? I hope @zhengyu123 has a chance to review it.
>>
>> Thank you! I was here, but we were not yet doing much upstream :) To be fair, this problem got quite involved and did cost me some cycles and false starts. I fully understand that the first solution uses the environment variable approach.
>>
>> I spend some time investigating different ideas with this one; at first I did not use a hash-table but a static pre-allocated buffer from which I fed early allocations. But the code got too complex, and Kim's suggestion with the side table turned out just to be a lot simpler.
>>
>>> Also interesting is that we were wondering how we could return malloc'd memory on JVM creation failure, and this might partially help with that larger problem.
>>
>> Yes, this would be trivial now, to return that memory. Though I am afraid it would be a small part only. But NMT may be instrumental in releasing all memory, since it knows everything. Only, its not always enabled.
>>
>> Is that a real-life problem? Are there cases where the launcher would want to live on if the JVM failed to load?
>
>> Is that a real-life problem? Are there cases where the launcher would want to live on if the JVM failed to load?
>
> There are a lot of other reasons why the launcher couldn't live on if the JVM fails to load. This was only one of them. We used to think about this problem once but don't really think it's solveable.
Thanks @coleenp and @zhengyu123 !
-------------
PR: https://git.openjdk.java.net/jdk/pull/4874
More information about the core-libs-dev
mailing list