RFR: 8151670: Unexpected concurrent refinement deactivation and reactivation
Mikael Gerdin
mikael.gerdin at oracle.com
Mon Mar 21 08:15:09 UTC 2016
Hi Kim,
On 2016-03-19 00:10, Kim Barrett wrote:
> Please review this change to the concurrent refinement threads to use
> SuspendibleThreadSet::yield, rather than deactivation, in response to
> an STS suspension request. This should mostly reduce the cost of
> coming out of a non-GC safepoint. See the CR for further discussion.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8151670
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8151670/webrev.00/
In
153 bool
DirtyCardQueueSet::apply_closure_to_buffer(CardTableEntryClosure* cl,
154 BufferNode* node,
155 bool consume,
156 uint worker_i) {
It seems like the old code set the index to the next unprocessed entry
when do_card_ptr returned false.
164 if (!cl->do_card_ptr(card_ptr, worker_i)) {
165 if (consume) {
166 size_t new_index = DirtyCardQueue::index_to_byte_index(i + 1);
167 assert(new_index <= buffer_size(), "invariant");
168 node->set_index(new_index);
169 }
170 return false;
In your version it seems like the index is set to the same entry.
Perhaps, instead of a "break", you wanted
162 for ( ; i < limit && result; ++i) {
I think this would make the setting of the new index work the same as
the old version of the code.
In
111 void ConcurrentG1RefineThread::run_service() {
It took me a while to notice the "break" after the call to
apply_closure_to_completed_buffer.
Perhaps there is a way to restructure the control flow to make this a
bit more obvious?
One variant could be to save the result of
apply_closure_to_completed_buffer in a boolean and check boolean in the
while() loop header.
/Mikael
>
> Testing:
> JPRT, RBT GC Nightly, local specjbb2015.
>
>
More information about the hotspot-gc-dev
mailing list