On Wed, 29 Oct 2025 04:20:53 GMT, David Holmes <[email protected]> wrote:
>> Erik Österlund has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 29 commits: >> >> - Merge branch 'master' into 8326035_JEP_object_streaming_v6 >> - Merge branch 'master' into 8326035_JEP_object_streaming_v6 >> - remove include >> - Interned string value word accounting >> - Dont load all objects when JVMTI CFLH is on >> - Remove duplicate string dedup disabling when dumping >> - Accept interned strings sharing value with another string >> - Merge branch 'master' into 8326035_JEP_object_streaming_v6 >> - Missing unlock diagnostic VM options, and remove unintended comment >> - Fix for minimal >> - ... and 19 more: https://git.openjdk.org/jdk/compare/c3c0a676...00c4f588 > > src/hotspot/share/utilities/exceptions.cpp line 559: > >> 557: Handle exception(_thread, _thread->pending_exception()); >> 558: _thread->clear_pending_exception(); // Needed to avoid infinite >> recursion >> 559: if (is_vm_created()) { > > Can you explain this change please. Sure. We can split the interval of time that create_vm is executing into two parts: before and after is_init_completed (where GC starts being allowed). Previously, throwing an exception during create_vm is caught and a pretty error message is shown before gracefully exiting. When using an exception mark, you get similar behaviour if an exception is caught in the first half (before GC is allowed), but a fatal crash after GC is allowed. This is an anomaly in the exception handling during initialization. For the most part, I suspect the distinction has not mattered a lot; we have a minimum heap size and during normal circumstances, we should not get OOME during create_vm if the minimum heap size was successfully committed when setting up the GC. However, with the AOT cache, we are allocating more objects during vm creation, and hence I had to take a stance on whether configuring a too small heap to run with the AOT cache should result in a fatal error or a graceful exit. Existing tests expect a graceful exit, and it makes sense to me that a fatal error does not seem warranted just because the heap configuration is obviously too small. Therefore, I ended up harmonising so the exception marks have more similar behaviour to exception handling on the main thread, resulting in a graceful exit if we have not even initialized the JVM yet at the point of an exception. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2472055380
