On Thu, 5 Nov 2020 14:36:44 GMT, Erik Österlund wrote:
>> Ok, so there were many test failures with other approaches. Having GC
>> trigger the posting was the most reliable way to post the events when the
>> tests (and presumably the jvmti customers) expected the events to be posted.
>> We c
On Wed, 4 Nov 2020 13:22:57 GMT, Coleen Phillimore wrote:
>> For the GCs that call the num_dead notification in a pause it is much worse
>> than what we had. As I pointed out elsewhere, it used to be that tagmap
>> processing was all-in-one, as a single serial subtask taken by the first
>> thr
On Wed, 4 Nov 2020 13:32:07 GMT, Coleen Phillimore wrote:
>> I know of nothing that leads to "presumably during GC" being a requirement.
>> Having all pending events of some type occur before that type of event is
>> disabled seems like a reasonable requirement, but just means that event
>> di
On Tue, 3 Nov 2020 21:14:04 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/prims/jvmtiTagMap.cpp line 3018:
>>
>>> 3016: }
>>> 3017: // Later GC code will relocate the oops, so defer rehashing
>>> until then.
>>> 3018: tag_map->_needs_rehashing = true;
>>
>> This is
On Wed, 4 Nov 2020 10:05:29 GMT, Kim Barrett wrote:
>> The comment is trying to describe the situation like:
>> 1. mark-end pause (WeakHandle.peek() returns NULL because object A is
>> unmarked)
>> 2. safepoint for heap walk
>>2a. Need to post ObjectFree event for object A before the heap wa
On Wed, 4 Nov 2020 09:27:39 GMT, Kim Barrett wrote:
>> I didn't say it "doesn't work for shenandoah", I said it wouldn't have
>> worked with the old shenandoah barriers without additional work, like adding
>> calls to resolve. I understand the design intent of notifying the table
>> managemen
On Tue, 3 Nov 2020 21:40:39 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/prims/jvmtiTagMap.cpp line 127:
>>
>>> 125: // The table cleaning, posting and rehashing can race for
>>> 126: // concurrent GCs. So fix it here once we have a lock or are
>>> 127: // at a safepoint.
>>
>> I th
On Wed, 4 Nov 2020 07:52:12 GMT, Kim Barrett wrote:
>> 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
>> th
On Tue, 3 Nov 2020 21:31:35 GMT, Coleen Phillimore wrote:
>> 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 rehashe
On Tue, 3 Nov 2020 21:12:49 GMT, Albert Mingkun Yang 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-
On Tue, 3 Nov 2020 21:41:55 GMT, Coleen Phillimore wrote:
> > @coleenp - please make sure you hear from someone on the Serviceability team
> > for this PR...
>
> I've asked @sspitsyn to review this.
Yes, I'm reviewing this. Still need another pass.
-
PR: https://git.openjdk.java.n
On Mon, 2 Nov 2020 13:19:08 GMT, Coleen Phillimore 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-ta
On Tue, 3 Nov 2020 16:17:58 GMT, Kim Barrett 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
>>
On Tue, 3 Nov 2020 16:12:21 GMT, Kim Barrett 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
>>
On Tue, 3 Nov 2020 14:50:36 GMT, Kim Barrett 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
>>
On Mon, 2 Nov 2020 13:19:08 GMT, Coleen Phillimore 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-ta
On Tue, 3 Nov 2020 14:53:12 GMT, Coleen Phillimore wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so that GC has to walk the
>> ta
On Tue, 3 Nov 2020 14:47:35 GMT, Kim Barrett 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
>>
On Tue, 3 Nov 2020 14:53:12 GMT, Coleen Phillimore wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so that GC has to walk the
>> ta
> This change turns the HashTable that JVMTI uses for object tagging into a
> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
> rehashing. Instead of pointing directly to oops so that GC has to walk the
> table to follow oops and then to rehash the table, this table poin
20 matches
Mail list logo
