> 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 incrementally with one additional commit since the last revision: Fix race ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9168/files - new: https://git.openjdk.org/jdk/pull/9168/files/92056334..6f14f452 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=14-15 Stats: 18 lines in 2 files changed: 14 ins; 0 del; 4 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
