> Currently, jdi only check and process class unloading event when it detects a > new GC cycle. > > After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting > class events can overlap with GC finish event, that results, sometimes, it > only captures partial or even empty unloaded class list. The pending list > usually can be flushed out at next GC cycle. But for the classes unloaded > during the last GC cycle, the class unloading events may lost forever. > > This patch checks and processes class unloading events unconditionally, > suggested by @kbarrett, the last pending unloaded class list can be flushed > by other events, such as `VM_DEATH`. > > It also performs `commonRef_compact()` only when there are classes unloaded. > > New test failed about 20% without patch, none with patch. > > **Update** > There are significant changes from early patch. > > The new approach: > No longer removing dead objects and post events on VM thread. I believe it > was implemented this way to workaround the following issues: > - JDI event handler uses JVMTI raw monitor, it requires thread in > `_in_native` state > - The thread can not hold lock, which is needed to protect `JvmtiTagMap` > while walking, when transition to `_in_native` state > > The new solution breaks up into two steps: > - Collect all dead object tags with lock > - Transition to `_in_native` state and post object free events in one batch > > This way, JDI event handler can process object free events upon arrivals > without delay. > > **Update 2** > There is a comment for ` JvmtiTagMap::check_hashmap()` that states > `ObjectFree` events are posted before heap walks. > > // This checks for posting and rehashing before operations that > // this tagmap table. The calls from a JavaThread only rehash, posting is > // only done before heap walks. > void JvmtiTagMap::check_hashmap(bool post_events) { > > Now, the events are actually posted after heap walks, but I don't think it > makes any material material difference. > Even the events are posted earlier in old code, but they are only processed > after next GC cycle.
Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 27 additional commits since the last revision: - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event - Moved TestClassUnloadEvents.java to new location - Fix test - Use Shenandoah GC for debuggee for deterministic - debug test - Adding log for debugging test failure on Windows - Removed HiddenClass test from Problem.txt and cleanup test - Renamed eventHandler_synthesizeUnloadEvent - v5 - Improve naming and cleanup - ... and 17 more: https://git.openjdk.org/jdk/compare/7f52920e...a07b3737 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9168/files - new: https://git.openjdk.org/jdk/pull/9168/files/e0338c4b..a07b3737 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=09-10 Stats: 25949 lines in 301 files changed: 23407 ins; 1791 del; 751 mod Patch: https://git.openjdk.org/jdk/pull/9168.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9168/head:pull/9168 PR: https://git.openjdk.org/jdk/pull/9168
