On Thu, 21 Jul 2022 19:25:25 GMT, Zhengyu Gu <z...@openjdk.org> wrote:
>> 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: > > Don't freeing objects and posting events from JvmtiEnv::GetObjectsWithTags() Marked as reviewed by sspitsyn (Reviewer). My mach5 debug test results looks good. Without extra flags: nsk.jvmti: https://mach5.us.oracle.com/mdash/jobs/sspitsyn-jdk20-nsk-jvmti-20220721-2323-34749955 nsk.jdi: https://mach5.us.oracle.com/mdash/jobs/sspitsyn-jdk20-nsk-jdi-20220721-2349-34750723 nsk.jdb: https://mach5.us.oracle.com/mdash/jobs/sspitsyn-jdk20-nsk-jdb-20220721-2350-34750749 jdk_jdi: https://mach5.us.oracle.com/mdash/jobs/sspitsyn-jdk20-jdk-jdi-20220721-2351-34750797 With flags `-XX:+UseZGC -XX:ZFragmentationLimit=0.1` : nsk.jvmti: https://mach5.us.oracle.com/mdash/jobs/sspitsyn-jdk20-zgc-nsk-jvmtii-20220721-2358-34750947 nsk.jdi: https://mach5.us.oracle.com/mdash/jobs/sspitsyn-jdk20-zgc-nsk-jdi-20220721-2359-34750968 With flags `-XX:+UseZGC -XX:ZCollectionInterval=0.1` : nsk.jvmti: https://mach5.us.oracle.com/mdash/jobs/sspitsyn-jdk20-zgc-nsk-jvmtii-20220722-0621-34758939 nsk.jdi: https://mach5.us.oracle.com/mdash/jobs/sspitsyn-jdk20-zgc-nsk-jdi-20220722-0623-34758978 Some test runs on Window got `HARNESS ERROR`. I'm not sure how to reproduce the issues Coleen observed when fixed the [JDK-8255987](https://bugs.openjdk.org/browse/JDK-8255987) . Approved the fix. ------------- PR: https://git.openjdk.org/jdk/pull/9168
