RFR: 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be [v3]

[Robbin Ehn]

On Tue, 1 Jun 2021 21:18:30 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Robbin Ehn 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 four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into handshakee
>>  - Small update
>>  - Merge branch 'master' into handshakee
>>  - Fix
>
> src/hotspot/share/utilities/filterQueue.inline.hpp line 127:
> 
>> 125:   do {
>> 126:     if (match_func(cur->_data)) {
>> 127:       match = cur;
> 
> Hmmm.... I was expecting a break after this match.
> Is there a reason to continue the loop?
> 
> But now I'm realizing that I'm confused since this is called `peek()`, but
> it's not really peeking at the head of the queue. It is searching the entire
> queue for a match.

It is a FIFO queue, which provides inserts at the end and retrieves at the front of the queue (push/pop/peek).
Push inserts at tail and pop/peek looks at head. (maybe these should be named differently to reflect this better, but that is another PR :) )

To provide lock-free inserts the queue only have a tail pointer.
This enabled us to do concurrent inserts with other inserts and/or another serialized operation, such as peek.
To get to the front of the queue we must always walk until the end.

This means peek is peeking at the head (with a filter).
Conceptually we generate a queue from that filter and from that virtual queue we peek at it's head.

Tail->A1->A2->A3->A4->A5
Filter = even
Virtual tail->A2->A4
Virtutal head = A4

To get to A4 we walk and apply the filter, the last match will be the head we are looking to peek at.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3973