RFR: JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit

Peter Levart peter.levart at gmail.com
Fri Jun 22 11:11:50 UTC 2018


Hi Tony,

On 06/21/2018 07:39 PM, Tony Printezis wrote:
> Peter,
>
> The changes to TestMaxCachedBufferSize.java look fine. One point 
> though: Why do you need the TmpDirectBuffersReclamation.java test? In 
> TestMaxCachedBufferSize.java you just call checkDirectBuffers(0, 0); 
> after you the main thread calls join() on the workers?

This could work, but I'd rather keep it like this so that each test 
tests just its own aspect. TestMaxCachedBufferSize takes a long time and 
only runs on big machines (@requires sun.arch.data.model == "64") while 
TmpDirectBuffersReclamation is quick and can run anywhere.

Regards, Peter

>
> Tony
>
>
> —————
> Tony Printezis | @TonyPrintezis | tprintezis at twitter.com 
> <mailto:tprintezis at twitter.com>
>
>
> On June 21, 2018 at 1:29:38 PM, Peter Levart (peter.levart at gmail.com 
> <mailto:peter.levart at gmail.com>) wrote:
>
>>
>>
>> On 06/21/2018 07:01 PM, Tony Printezis wrote:
>>> I’m trying exactly that. :-)
>>
>> Sorry, I didn't know. Here's my attempt:
>>
>> http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.07/
>>
>> I also added @run main/othervm to TempDirectBuffersReclamation test.
>>
>> Peter
>>
>>>
>>>
>>> —————
>>> Tony Printezis | @TonyPrintezis | tprintezis at twitter.com 
>>> <mailto:tprintezis at twitter.com>
>>>
>>>
>>> On June 21, 2018 at 12:59:58 PM, Peter Levart 
>>> (peter.levart at gmail.com <mailto:peter.levart at gmail.com>) wrote:
>>>
>>>>
>>>>
>>>> On 06/21/2018 06:17 PM, Tony Printezis wrote:
>>>>> I was saying: I looked at TestMaxCachedBufferSize and, 
>>>>> unfortunately, I don’t think the test makes a lot of sense right 
>>>>> now as it checks the number / size of direct buffers after all the 
>>>>> threads terminate and, with this change, that should always be 0.
>>>>
>>>> You're right. The test makes no sense now. As I understand, the 
>>>> test checked that number/size of allocated temporary buffers did 
>>>> not exceed the estimated calculated size by checking the MXBean 
>>>> immediately after threads terminate. This will never happen after 
>>>> the change as they will all be freed before checking, regardless of 
>>>> how many were and how much was allocated.
>>>>
>>>> Perhaps the test should be modified to include a latch so that 
>>>> threads wait until the measurement is made and only then are 
>>>> allowed to exit...
>>>>
>>>> Regards, Peter
>>>>
>>



More information about the core-libs-dev mailing list