> The JvmtiTagMap can be deleted while it is posting. The JvmtiEnv is still on > the list but the env is "disposed" of and the tag_map is deleted to save > memory until the JvmtiEnv can be reclaimed at a safepoint and taken off the > list. > > There's a check JvmtiEnvBase::check_for_periodic_clean_up() that determines > whether the JvmtiEnv can be taken off the list and that check looks for > whether threads are in the middle of JvmtiEnvIterator which sets > Thread::jvmti_env_iteration_count. So this part is safe for the JvmtiTagMap > changes. > > The fix is to clear the JvmtiTagMapTable of the entries inside the table lock > to save memory but leave JvmtiTagMap intact so that we can load a valid > pointer when iterating through JvmtiEnvIterator. We could also not do this > at all and let the JvmtiTagMap destructor delete the table when the JvmtiEnv > is also deleted, but we don't know what customer situation led to this code > in the first place.
Coleen Phillimore 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 three additional commits since the last revision: - Merge branch 'master' into more-jvmti-table - Rename JvmtiTagMap::clear() and fix JvmtiTagMapTable::clear() to null out deleted entries. - 8257140: Crash in JvmtiTagMap::flush_object_free_events() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1539/files - new: https://git.openjdk.java.net/jdk/pull/1539/files/9aaa0c88..a035ec89 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1539&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1539&range=00-01 Stats: 24816 lines in 603 files changed: 13248 ins; 3971 del; 7597 mod Patch: https://git.openjdk.java.net/jdk/pull/1539.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1539/head:pull/1539 PR: https://git.openjdk.java.net/jdk/pull/1539
