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

[Tony Printezis]

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?

Tony


—————
Tony Printezis | @TonyPrintezis | tprintezis at twitter.com


On June 21, 2018 at 1:29:38 PM, Peter Levart (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


On June 21, 2018 at 12:59:58 PM, Peter Levart (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