On Tue, 10 Nov 2020 21:01:21 GMT, Daniel D. Daugherty <dcu...@openjdk.org>
wrote:
>> So why not use a local semaphore and wait with safepoint check instead?
>
> Sorry my preference is for Monitors instead of semaphores. Let's
> take that discussion off this PR and you can explain why you dislike
> the Monitor so much and think the local semaphore is the way to go.
Yes
>> Currently there is no issue with ThreadBlockInVM since there is no code
>> inside those scopes.
>> This adds code there which assumes the timer will be 'resumed', and logs
>> "resume" when it actually could be going to a safepoint.
>
> So if I narrow the scope around the ThreadBlockInVM, then it would be fine?
>
> {
> // Honor block request.
> ThreadBlockInVM tbivm(self);
> }
>
> I can make that change before I integrate...
Yes that avoids it!
>> Yes that's why I said you can release it during deflation instead.
>>
>> (not saying you should do this in this feeature change-set)
>
> What does this "you can do this entire loop while blocked instead" mean?
>
> Releasing during deflation kind of messes with the life-cycle I was trying
> to enforce since deletion is the nature end-of-life for these... But to think
> about that I need to know what you mean by "you can do this entire loop
> while blocked instead"...
If you only need to free CHeap memory, you can do:
size_t deleted_count = 0;
ThreadBlockInVM tbivm(self);
for (ObjectMonitor* monitor: delete_list) {
delete monitor;
deleted_count++;
}
}
-------------
PR: https://git.openjdk.java.net/jdk/pull/642
