Summary of 1st week was: ReferenceQueue.remove to allow GC of the queue itself

Dear all. On Fri Jul 25, 2014: > So, let’s start with the problem, rather than the solution. Could you start > with writing up what issue you’re trying to address, and then we can > proceed to evaluating whether the proposed solution is the right one? Thanks for the encouragement, thanks for you

Re: Benefits of activeReferenceQueue was: ReferenceQueue.remove to allow GC of the queue itself

Hi Peter, Thanks for the detailed explanation. It is an interesting problem. But at this stage my only conclusion is that we are nowhere near the point of deciding to add a new method to a public API. I think the fundamental flaw of activeReferenceQueue is in trying to hide the thread manage

Re: Benefits of activeReferenceQueue was: ReferenceQueue.remove to allow GC of the queue itself

On 07/29/2014 04:16 AM, David Holmes wrote: Hi Jaroslav, So ... activeReferenceQueue is a reference queue that embodies a thread that does the polling and implements a psuedo-finalization mechanism. This works fine in the normal case where the lifetime of the queue is the lifetime of the "ap

Re: Benefits of activeReferenceQueue was: ReferenceQueue.remove to allow GC of the queue itself

Hi Jaroslav, So ... activeReferenceQueue is a reference queue that embodies a thread that does the polling and implements a psuedo-finalization mechanism. This works fine in the normal case where the lifetime of the queue is the lifetime of the "application". In the WAR case (and I don't know

Re: Benefits of activeReferenceQueue was: ReferenceQueue.remove to allow GC of the queue itself

Hello Jaroslav, Regardless of where it is implemented (in JDK or in NetBeans) it would be impossible to create something that doesn't do polling in a single thread and yet wait for two ReferenceQueues at the same time - one is the queue of Runnable references which you run() and the other is t

Benefits of activeReferenceQueue was: ReferenceQueue.remove to allow GC of the queue itself

Hello David, thanks for being patient with me. I'll do my best to describe the original context. Dne Po 28. července 2014 21:07:45, David Holmes napsal(a): > I read the issue and still did not understand the nature of the problem. > The netbeans bugs also did not shed any light on things for me.

Re: ReferenceQueue.remove to allow GC of the queue itself

On 28/07/2014 5:23 PM, Jaroslav Tulach wrote: Thanks for your reply. Dne Pá 25. července 2014 12:45:02, Brian Goetz napsal(a): So, let’s start with the problem, rather than the solution. That is always better start. Could you start with writing up what issue you’re trying to address, I be

Alternative is repeated polling was: ReferenceQueue.remove to allow GC of the queue itself

One thing I should add is that an alternative solution to the WAR-leak problem[2] is repeated pooling. The reason NetBeans did not use it, is that our performance team dislikes repeatedly executed tasks (you know, when various parts of the IDE wake up every 15s each you end up, due to # of

Re: ReferenceQueue.remove to allow GC of the queue itself

Thanks for your reply. Dne Pá 25. července 2014 12:45:02, Brian Goetz napsal(a): > So, let’s start with the problem, rather than the solution. That is always better start. > Could you start > with writing up what issue you’re trying to address, I believe I did that in the issue description.

Re: ReferenceQueue.remove to allow GC of the queue itself

So, let’s start with the problem, rather than the solution. Could you start with writing up what issue you’re trying to address, and then we can proceed to evaluating whether the proposed solution is the right one? On Jul 24, 2014, at 7:29 AM, Jaroslav Tulach wrote: > Hi. > I'd like to add

ReferenceQueue.remove to allow GC of the queue itself

Hi. I'd like to add one new method into java.lang.ref.ReferenceQueue. Can anyone help me go through the review process? I've reported https://bugs.openjdk.java.net/browse/JDK-8051843 but that probably is not enough, right? Thanks in advance for your help. -jt