On Mon, 2 Aug 2021 14:24:54 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? > >> 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
