> On Aug 13, 2016, at 4:20 AM, Peter Levart <peter.lev...@gmail.com> wrote:
>
> Hi Mandy,
>
> On 08/13/2016 01:55 AM, Mandy Chung wrote:
>>> On Aug 8, 2016, at 6:25 PM, Kim Barrett <kim.barr...@oracle.com>
>>> wrote:
>>>
>>> full:
>>> http://cr.openjdk.java.net/~kbarrett/8156500/jdk.04/
>>>
>>>
>>> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.04/
>> This looks very good.
>>
>> Have you considered having JVM_WaitForReferencePendingList method to return
>> the pending list? i.e. make it a blocking version of
>> getAndClearReferencePendingList rather than two operations.
>>
>> waitForReferenceProcessing is really wait for pending reference(s) enqueued
>> (additionally cleaner gets invoked). What do you think to rename this
>> method to “waitForPendingReferencesEnqueued”?
>>
>
> I think the split is intentional. It's a clever way to avoid an otherwise
> inevitable race that could otherwise cause DBB allocating thread to fail with
> OOME prematurely.
>
> waitForReferencePendingList() is invoked out of synchronized block so that it
> does not prevent the progress of thread(s) invoking
> waitForReferenceProcessing(), while getAndClearReferencePendingList is
> non-blocking and is invoked inside the synchronized block that also sets a
> boolean flag. Code in waitForReferenceProcessing() checks both the
> non-emptiness of reference pending list and the boolean flag while holding
> the lock.
>
> The following sequence of actions (as used in NIO Bits):
>
> System.gc();
> Reference.waitForReferenceProcessing();
>
> ...therefore either:
>
> - completes immediately after System.gc() returns without discovering any
> pending Reference, returning false; or
> - completes after System.gc() discovers at least one pending Reference and
> ReferenceHandler thread processes at least one Cleaner, returning true; or
> enqueues all pending Reference(s), returning false.
>
> When waitForReferenceProcessing() returns false consecutively even after a
> series of exponentially increasing pauses, the DBB allocating thread(s) can
> be sure they have exhausted all options to allocate the direct buffer and
> must fail with OOME.
Thanks for answering Mandy’s questions for me. That all looks right.
> I have a feeling that these pauses are now unnecessary. Will try to check
> with some experiments…
I found that the DirectBufferAllocTest will sometimes fail if the pauses are
taken out.
I think what’s going on is that the multiple threads are competing for
resources, and
some threads in that test lose out if all of them are waiting and wake up at
the same
time. The exponentially increasing back-off scatters the threads enough for
that to
become very unlikely, though with sufficiently bad luck… But I think the current
implementation could also fail that test with similarly bad luck. It just
requires *very*
bad luck, so we’re not seeing it as a problem. And that test is a pretty
extreme stress
test.
>
> Regards, Peter
>
>> Grammar question:
>>
>> "there are no more references”
>> "If there aren't any pending {@link Reference}s"
>>
>> - This is the case with zero pending reference, shouldn’t it use “is” such
>> that:
>>
>> "there us no more reference”
>> "If there isn't any pending {@link Reference}”
>>
>> Please update the synposis of JDK-8156500 to make it clear what this fix is
>> (it’s nothing related to JDI). Maybe something like “Move the pending
>> reference list to VM”
>>
>> Mandy
