On Thu, 29 Jul 2021 23:03:46 GMT, Coleen Phillimore <cole...@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? ------------- PR: https://git.openjdk.java.net/jdk/pull/4874
