On Tue, 3 Nov 2020 16:12:21 GMT, Kim Barrett <kbarr...@openjdk.org> wrote:
>> Coleen Phillimore has updated the pull request with a new target base due to >> a merge or a rebase. The pull request now contains five commits: >> >> - Merge branch 'master' into jvmti-table >> - Merge branch 'master' into jvmti-table >> - More review comments from Stefan and ErikO >> - Code review comments from StefanK. >> - 8212879: Make JVMTI TagMap table not hash on oop address > > src/hotspot/share/prims/jvmtiTagMap.cpp line 2979: > >> 2977: >> 2978: // Concurrent GC needs to call this in relocation pause, so after the >> objects are moved >> 2979: // and have their new addresses, the table can be rehashed. > > I think the comment is confusing and wrong. The requirement is that the > collector must call this before exposing moved objects to the mutator, and > must provide the to-space invariant. (This whole design would not work with > the old Shenandoah barriers without additional work. I don't know if tagmaps > ever worked at all for them? Maybe they added calls to Access<>::resolve > (since happily deceased) to deal with that?) I also think there are a bunch > of missing calls; piggybacking on the num-dead callback isn't correct (see > later comment about that). So the design is that when the oops have new addresses, we set a flag in the table to rehash it. Not sure why this is wrong and why wouldn't it work for shenandoah? @zhengyu123 ? When we call WeakHandle.peek()/resolve() after the call, the new/moved oop address should be returned. Why wouldn't this be the case? ------------- PR: https://git.openjdk.java.net/jdk/pull/967
