Can I also add that, when a buffer in the cache needs to be replaced with a
new (and typically larger) one, the old buffer is explicitly freed. So, the
code already assumes that buffers that are in the cache should not be
reachable from anywhere else. Explicitly freeing them when the thread exits
i
On 21/06/2018 21:13, Florian Weimer wrote:
* Tony Printezis:
There are a few obvious ways to mitigate this, e.g., cause a Full GC /
concurrent GC cycle at regular intervals. However, the best solution IMHO
is to explicitly free any direct buffers that are still in the cache when a
thread exits.
* Tony Printezis:
> There are a few obvious ways to mitigate this, e.g., cause a Full GC /
> concurrent GC cycle at regular intervals. However, the best solution IMHO
> is to explicitly free any direct buffers that are still in the cache when a
> thread exits.
Why is this safe? Couldn't these di
On 09/04/2018 11:26, Peter Levart wrote:
If adding a field to Thread class is a concern, I can modify this to
use a special ThreadLocal instance to keep registered callback(s) per
thread.
Thanks for the prototype, that is along the lines of what I was
thinking. I also think it would be good t
On 04/09/18 12:21, Peter Levart wrote:
On 04/09/18 10:33, David Holmes wrote:
After thread exits, ThreadLocal values associated with it are no
longer reachable from its Thread object.
The problem Tony faces is that by the time this happens, direct
ByteBuffer's that were cached using such
On 04/09/18 10:33, David Holmes wrote:
After thread exits, ThreadLocal values associated with it are no
longer reachable from its Thread object.
The problem Tony faces is that by the time this happens, direct
ByteBuffer's that were cached using such ThreadLocal value, are
already moved to o
Hi Peter,
On 9/04/2018 5:50 PM, Peter Levart wrote:
On 04/09/18 08:25, David Holmes wrote:
On 7/04/2018 3:11 AM, Tony Printezis wrote:
—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
On April 6, 2018 at 12:16:10 PM, David Lloyd (david.ll...@redhat.com)
wrote:
On Fri, Ap
On 04/09/18 08:25, David Holmes wrote:
On 7/04/2018 3:11 AM, Tony Printezis wrote:
—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
On April 6, 2018 at 12:16:10 PM, David Lloyd (david.ll...@redhat.com)
wrote:
On Fri, Apr 6, 2018 at 8:57 AM, Tony Printezis
wrote:
ThreadLo
On 7/04/2018 3:11 AM, Tony Printezis wrote:
—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
On April 6, 2018 at 12:16:10 PM, David Lloyd (david.ll...@redhat.com) wrote:
On Fri, Apr 6, 2018 at 8:57 AM, Tony Printezis
wrote:
ThreadLocal clearing
Could you clarify what you me
On Fri, Apr 6, 2018 at 1:02 AM, Alan Bateman
wrote:
> On 05/04/2018 22:45, Tony Printezis wrote:
>
>>
>> We recently hit another interesting issue with the NIO thread-local
>> DirectByteBuffer cache. One of our services seems to create and drop
>> threads at regular intervals. I assume this is du
On 06/04/2018 18:17, Tony Printezis wrote:
Hi Alan,
Ah, I hadn’t realized that there’s already some tight coupling between
Thread and nio. OK, I’ll just call into sun.nio directly and see what
the reviewers say. :-) Is there a CR for this already? Or should I
create one?
I think it should b
Hi Alan,
Ah, I hadn’t realized that there’s already some tight coupling between
Thread and nio. OK, I’ll just call into sun.nio directly and see what the
reviewers say. :-) Is there a CR for this already? Or should I create one?
Tony
—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.co
—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
On April 6, 2018 at 12:16:10 PM, David Lloyd (david.ll...@redhat.com) wrote:
On Fri, Apr 6, 2018 at 8:57 AM, Tony Printezis
wrote:
>> ThreadLocal clearing
>
> Could you clarify what you mean by ThreadLocal clearing?
I mean calling
On 06/04/2018 15:08, Tony Printezis wrote:
Hi Alan,
Calling sun.nio directly from java.lang seemed a bit dodgy to me,
which is why I proposed some type of exit hook (maybe I overthought
this?). But that’d be OK, could make this change a lot simpler. :-)
And, yes, I came across the issue of no
On Fri, Apr 6, 2018 at 8:57 AM, Tony Printezis wrote:
>> ThreadLocal clearing
>
> Could you clarify what you mean by ThreadLocal clearing?
I mean calling ThreadLocal#remove().
> I like the suggestion to add an overridable exit() method to ThreadLocal. If
> you want to avoid calling user code by
Was there a reason why this was not introduced in the first place?
Tony
—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
On April 6, 2018 at 8:49:17 AM, Peter Levart (peter.lev...@gmail.com) wrote:
On 04/06/2018 10:02 AM, Alan Bateman wrote:
> On 05/04/2018 22:45, Tony Printez
Hi Alan,
Calling sun.nio directly from java.lang seemed a bit dodgy to me, which is
why I proposed some type of exit hook (maybe I overthought this?). But
that’d be OK, could make this change a lot simpler. :-) And, yes, I came
across the issue of not being able to query whether a ThreadLocal exis
Hi David,
Thanks for your thoughts. Please see inline.
—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
On April 5, 2018 at 6:24:11 PM, David Lloyd (david.ll...@redhat.com) wrote:
On Thu, Apr 5, 2018 at 4:45 PM, Tony Printezis
wrote:
> Would proposing to introduce thread exit h
Hi David,
ThreadLocals getting cleared is not enough. The threadLocals field is
cleared by Thread::exit:
private void exit() {
...
threadLocals = null;
...
}
but this doesn’t really do anything. The GC has to run, find the direct
buffer in the ThreadLocal unreacha
On 04/06/2018 10:02 AM, Alan Bateman wrote:
On 05/04/2018 22:45, Tony Printezis wrote:
Hi all,
We recently hit another interesting issue with the NIO thread-local
DirectByteBuffer cache. One of our services seems to create and drop
threads at regular intervals. I assume this is due to a threa
On 05/04/2018 22:45, Tony Printezis wrote:
Hi all,
We recently hit another interesting issue with the NIO thread-local
DirectByteBuffer cache. One of our services seems to create and drop
threads at regular intervals. I assume this is due to a thread pool
dynamically resizing itself.
Let's say
On Thu, Apr 5, 2018 at 4:45 PM, Tony Printezis wrote:
> Would proposing to introduce thread exit hooks be reasonable? Or is
> everyone going to freak out? :-) The hooks can be either per-Thread or even
> per-ThreadLocal. And it's OK if the hooks can only be used within java.base.
User-accessible
Hi Tony,
On 6/04/2018 7:45 AM, Tony Printezis wrote:
Hi all,
We recently hit another interesting issue with the NIO thread-local
DirectByteBuffer cache. One of our services seems to create and drop
If it's in a ThreadLocal then aren't you just asking for thread-locals
to be cleared at thread
23 matches
Mail list logo
