Hi,
On 05/11/18 16:13, Alan Bateman wrote:
On 08/05/2018 16:07, Tony Printezis wrote:
Hi all,
Following the discussion on this a few weeks ago, here’s the first
version
of the change:
http://cr.openjdk.java.net/~tonyp/8202788/webrev.0/
I think the consensus was that it’d be easier if the exit hooks were
only
available within java.base. Is it enough that I added the
functionality to
the jdk.internal.misc package? (And is jdk.internal.misc the best
place for
this?)
I’ll also add a test for the new functionality. But let’s first come up
with an approach that everyone is happy with. :-)
Peter's approach in early April was clean (and we should come to the
getIfPresent discussion) but it adds a field to Thread for the
callback list. If I read your approach correctly, you are avoiding
that by maintaining an array of hooks in ThreadLocalExitHooks.
Another approach to try is a java.base-internal ThreadLocal that
defines a method to be invoked when a thread terminates. Something
like the following:
http://cr.openjdk.java.net/~alanb/8202788/webrev/index.html
-Alan
From the API perspective, Alan's suggestion is the most attractive one
as it puts the method to where it belongs - into the ThreadLocal
instance. But the implementation could be improved a bit. I don't like
the necessity to iterate over all ThreadLocal(s) to filter out
JdkThreadLocal(s). There might be a situation where there's plenty of
ThreadLocal(s) registered per exiting thread which would produce a spike
in CPU processing at thread exit.
The way to avoid this would be to maintain a separate linked list of
entries that contains just those with JdkThreadLocal(s). Like in this
modification of Alan's patch, for example:
http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.01/
(Only ThreadLocal class is modified from Alan's patch)
What do you think?
Regards, Peter
