+1
David
On 29/11/2017 4:14 AM, Doug Lea wrote:
On 11/28/2017 01:11 PM, Roger Riggs wrote:
Hi,
So this thread died out a while ago with some alternatives discussed and
no clear short term solution.
I'd be happy if someone closer to the ThreadPoolExecutor would be able
to take another look at
On 11/28/2017 01:11 PM, Roger Riggs wrote:
> Hi,
>
> So this thread died out a while ago with some alternatives discussed and
> no clear short term solution.
> I'd be happy if someone closer to the ThreadPoolExecutor would be able
> to take another look at the issues.
> For the time being, it is l
Hi,
So this thread died out a while ago with some alternatives discussed and
no clear short term solution.
I'd be happy if someone closer to the ThreadPoolExecutor would be able
to take another look at the issues.
For the time being, it is lower down on my priorities.
Thanks, Roger
[1] 81903
Hi David,
On 11/1/2017 10:30 PM, David Holmes wrote:
On 2/11/2017 5:07 AM, Stuart Marks wrote:
On 10/31/17 6:58 PM, David Holmes wrote:
I'm not sure why you say this isn't helpful. It's clearly not
helpful to *clients* of TPE; but since finalize() is protected, the
warning is clearly directed
w over any
ExecutorService and there may be multiple views over same instance.
Regards, Peter
From: core-libs-dev on
behalf of Peter Levart
Sent: Thursday, November 2, 2017 10:23 AM
To: David Holmes; Roger Riggs
Cc: core-libs-dev
Subject: Re: ThreadPoolEx
: ThreadPoolExecutor and finalization
Hi,
On 11/02/2017 01:47 PM, David Holmes wrote:
public class CleanableExecutorService implements ExecutorService {
private final ThreadPoolExecutor tpe;
public CleanableExecutorService(ThreadPoolExecutor tpe) {
CleanerFactory.cleaner
, November 2, 2017 10:23 AM
To: David Holmes; Roger Riggs
Cc: core-libs-dev
Subject: Re: ThreadPoolExecutor and finalization
Hi,
On 11/02/2017 01:47 PM, David Holmes wrote:
>> public class CleanableExecutorService implements ExecutorService {
>> private final ThreadPool
Hi,
On 11/02/2017 01:47 PM, David Holmes wrote:
public class CleanableExecutorService implements ExecutorService {
private final ThreadPoolExecutor tpe;
public CleanableExecutorService(ThreadPoolExecutor tpe) {
CleanerFactory.cleaner().register(this, tpe::shutdown);
On 11/02/2017 01:47 PM, David Holmes wrote:
On 2/11/2017 7:26 PM, Peter Levart wrote:
On 11/02/2017 03:34 AM, David Holmes wrote:
On 2/11/2017 3:46 AM, Peter Levart wrote:
On 11/01/17 13:34, David Holmes wrote:
On 1/11/2017 10:20 PM, Peter Levart wrote:
On 11/01/17 10:04, David Holmes wrot
On 2/11/2017 7:26 PM, Peter Levart wrote:
On 11/02/2017 03:34 AM, David Holmes wrote:
On 2/11/2017 3:46 AM, Peter Levart wrote:
On 11/01/17 13:34, David Holmes wrote:
On 1/11/2017 10:20 PM, Peter Levart wrote:
On 11/01/17 10:04, David Holmes wrote:
On 1/11/2017 6:16 PM, Peter Levart wrote:
On 11/02/2017 03:34 AM, David Holmes wrote:
On 2/11/2017 3:46 AM, Peter Levart wrote:
On 11/01/17 13:34, David Holmes wrote:
On 1/11/2017 10:20 PM, Peter Levart wrote:
On 11/01/17 10:04, David Holmes wrote:
On 1/11/2017 6:16 PM, Peter Levart wrote:
On 11/01/17 02:49, David Holmes wrote
On 2/11/2017 3:46 AM, Peter Levart wrote:
On 11/01/17 13:34, David Holmes wrote:
On 1/11/2017 10:20 PM, Peter Levart wrote:
On 11/01/17 10:04, David Holmes wrote:
On 1/11/2017 6:16 PM, Peter Levart wrote:
On 11/01/17 02:49, David Holmes wrote:
Hi Roger,
On 31/10/2017 11:58 PM, Roger Rig
On 2/11/2017 5:07 AM, Stuart Marks wrote:
On 10/31/17 6:58 PM, David Holmes wrote:
I'm not sure why you say this isn't helpful. It's clearly not helpful
to *clients* of TPE; but since finalize() is protected, the warning
is clearly directed at subclasses, and it provides information about
migr
On 10/31/17 6:58 PM, David Holmes wrote:
I'm not sure why you say this isn't helpful. It's clearly not helpful to
*clients* of TPE; but since finalize() is protected, the warning is clearly
directed at subclasses, and it provides information about migrating away from
finalization. Should say so
On 11/01/17 13:34, David Holmes wrote:
On 1/11/2017 10:20 PM, Peter Levart wrote:
On 11/01/17 10:04, David Holmes wrote:
On 1/11/2017 6:16 PM, Peter Levart wrote:
On 11/01/17 02:49, David Holmes wrote:
Hi Roger,
On 31/10/2017 11:58 PM, Roger Riggs wrote:
Hi Peter,
Only native resources t
On 1/11/2017 10:20 PM, Peter Levart wrote:
On 11/01/17 10:04, David Holmes wrote:
On 1/11/2017 6:16 PM, Peter Levart wrote:
On 11/01/17 02:49, David Holmes wrote:
Hi Roger,
On 31/10/2017 11:58 PM, Roger Riggs wrote:
Hi Peter,
Only native resources that do not map to the heap allocation/gc
On 11/01/17 10:04, David Holmes wrote:
On 1/11/2017 6:16 PM, Peter Levart wrote:
On 11/01/17 02:49, David Holmes wrote:
Hi Roger,
On 31/10/2017 11:58 PM, Roger Riggs wrote:
Hi Peter,
Only native resources that do not map to the heap allocation/gc
cycle need any kind
of cleanup. I would w
On 1/11/2017 6:16 PM, Peter Levart wrote:
On 11/01/17 02:49, David Holmes wrote:
Hi Roger,
On 31/10/2017 11:58 PM, Roger Riggs wrote:
Hi Peter,
Only native resources that do not map to the heap allocation/gc cycle
need any kind
of cleanup. I would work toward a model that encapsulates the
On 11/01/17 02:49, David Holmes wrote:
Hi Roger,
On 31/10/2017 11:58 PM, Roger Riggs wrote:
Hi Peter,
Only native resources that do not map to the heap allocation/gc cycle
need any kind
of cleanup. I would work toward a model that encapsulates the
reference to a native resource
with a cor
Hi Stuart,
Jumping to the end ...
On 1/11/2017 6:37 AM, Stuart Marks wrote:
On 10/30/17 10:21 AM, Martin Buchholz wrote:
The initiative is to identify and remediate existing uses of
finalization
in the JDK.
I've been skeptical about this initiative as stated. I would not have
deprecated fi
Hi Roger,
On 31/10/2017 11:58 PM, Roger Riggs wrote:
Hi Peter,
Only native resources that do not map to the heap allocation/gc cycle
need any kind
of cleanup. I would work toward a model that encapsulates the reference
to a native resource
with a corresponding allocation/release mechanism as
On 10/30/17 10:21 AM, Martin Buchholz wrote:
The initiative is to identify and remediate existing uses of finalization
in the JDK.
I've been skeptical about this initiative as stated. I would not have
deprecated finalize(). We will never remove finalize() from the JDK, and I
don't see how sw
Hi Peter,
Most of the discussion is in: https://bugs.openjdk.java.net/browse/JDK-6399443.
The linked issue in that report then links to the CI mail thread.
Jason
>I'm trying to understand the purpose of finalize() in TPE, but can't.
>I'm surely missing something. If the pool is no longer refe
Hi Peter,
Only native resources that do not map to the heap allocation/gc cycle
need any kind
of cleanup. I would work toward a model that encapsulates the reference
to a native resource
with a corresponding allocation/release mechanism as you've described
here and in the
thread on zip.
For
Hi David,
On 10/31/2017 12:37 AM, David Holmes wrote:
Hi Roger,
On 31/10/2017 12:43 AM, Roger Riggs wrote:
Hi David,
On 10/30/2017 3:31 AM, David Holmes wrote:
Hi Andrej,
On 30/10/2017 5:02 PM, Andrej Golovnin wrote:
Hi David,
On 30. Oct 2017, at 01:40, David Holmes
wrote:
Hi Roger,
On 10/31/2017 04:55 AM, David Holmes wrote:
>
> In 2006 we added the docs about it being unreferenced and no remaining
> threads - which I guess is a necessary condition for finalization to now
> occur. But as you noted at that point shutdown() is pretty much a no-op.
>
> Maybe Doug (cc'd) can r
Hi,
Here are some of my thoughts...
On 10/31/17 05:37, David Holmes wrote:
Hi Roger,
On 31/10/2017 12:43 AM, Roger Riggs wrote:
Hi David,
On 10/30/2017 3:31 AM, David Holmes wrote:
Hi Andrej,
On 30/10/2017 5:02 PM, Andrej Golovnin wrote:
Hi David,
On 30. Oct 2017, at 01:40, David Holmes
Hi Peter,
cc'ing Doug Lea
On 31/10/2017 6:25 PM, Peter Levart wrote:
Hi David,
On 10/31/17 08:45, David Holmes wrote:
The docs for TPE cover this in detail: [1]
Finalization
A pool that is no longer referenced in a program AND has no
remaining threads will be shutdown automatically. If
Hi David,
On 10/31/17 08:45, David Holmes wrote:
The docs for TPE cover this in detail: [1]
Finalization
A pool that is no longer referenced in a program AND has no
remaining threads will be shutdown automatically. If you would like
to ensure that unreferenced pools are reclaimed even if
On 31/10/2017 5:36 PM, Peter Levart wrote:
On 10/31/17 05:12, David Holmes wrote:
On 31/10/2017 1:02 AM, David Lloyd wrote:
On Mon, Oct 30, 2017 at 9:43 AM, Roger Riggs
wrote:
ThreadPoolExecutor has a responsibility to cleanup any native
resources it
has allocated (threads) and it should be f
Hi,
On 10/31/17 05:12, David Holmes wrote:
On 31/10/2017 1:02 AM, David Lloyd wrote:
On Mon, Oct 30, 2017 at 9:43 AM, Roger Riggs
wrote:
ThreadPoolExecutor has a responsibility to cleanup any native
resources it
has allocated (threads) and it should be free to use whatever
mechanism is appro
Hi Roger,
On 31/10/2017 12:43 AM, Roger Riggs wrote:
Hi David,
On 10/30/2017 3:31 AM, David Holmes wrote:
Hi Andrej,
On 30/10/2017 5:02 PM, Andrej Golovnin wrote:
Hi David,
On 30. Oct 2017, at 01:40, David Holmes
wrote:
Hi Roger,
On 30/10/2017 10:24 AM, Roger Riggs wrote:
Hi,
With the
On 31/10/2017 1:02 AM, David Lloyd wrote:
On Mon, Oct 30, 2017 at 9:43 AM, Roger Riggs wrote:
ThreadPoolExecutor has a responsibility to cleanup any native resources it
has allocated (threads) and it should be free to use whatever mechanism is
appropriate.
I wonder though whether TPE.finaliz
On Mon, Oct 30, 2017 at 8:27 AM, Roger Riggs wrote:
> Hi,
>
> There is a test /test/jdk/java/util/conc
> urrent/Executors/AutoShutdown.java
>
> It only tests it for Executors of newSingleThreadExecutor, not for the
> others
> so I wondered if there was some open issue.
>
I wrote that test long a
Hi,
There is a test
/test/jdk/java/util/concurrent/Executors/AutoShutdown.java
It only tests it for Executors of newSingleThreadExecutor, not for the
others
so I wondered if there was some open issue.
Roger
On 10/30/2017 11:02 AM, David Lloyd wrote:
On Mon, Oct 30, 2017 at 9:43 AM, Roger
On Mon, Oct 30, 2017 at 9:43 AM, Roger Riggs wrote:
> ThreadPoolExecutor has a responsibility to cleanup any native resources it
> has allocated (threads) and it should be free to use whatever mechanism is
> appropriate.
I wonder though whether TPE.finalize() is ever actually hit in
practice: TP
Hi David,
On 10/30/2017 3:31 AM, David Holmes wrote:
Hi Andrej,
On 30/10/2017 5:02 PM, Andrej Golovnin wrote:
Hi David,
On 30. Oct 2017, at 01:40, David Holmes
wrote:
Hi Roger,
On 30/10/2017 10:24 AM, Roger Riggs wrote:
Hi,
With the deprecation of Object.finalize its time to look at its
Hi Andrej,
On 30/10/2017 5:02 PM, Andrej Golovnin wrote:
Hi David,
On 30. Oct 2017, at 01:40, David Holmes wrote:
Hi Roger,
On 30/10/2017 10:24 AM, Roger Riggs wrote:
Hi,
With the deprecation of Object.finalize its time to look at its uses too see if
they can be removed or mitigated.
So
Hi David,
> On 30. Oct 2017, at 01:40, David Holmes wrote:
>
> Hi Roger,
>
> On 30/10/2017 10:24 AM, Roger Riggs wrote:
>> Hi,
>> With the deprecation of Object.finalize its time to look at its uses too see
>> if they can be removed or mitigated.
>
> So the nice thing about finalize was that
Hi Roger,
On 30/10/2017 10:24 AM, Roger Riggs wrote:
Hi,
With the deprecation of Object.finalize its time to look at its uses too
see if they can be removed or mitigated.
So the nice thing about finalize was that it followed a
nice/clean/simple OO model where a subclass could override, add
Hi,
With the deprecation of Object.finalize its time to look at its uses too
see if
they can be removed or mitigated.
The ThreadPoolExecutor overrides finalize to shutdown the pool.
A simple but incomplete step is to retain the shutdown on finalize but
remove it from
the specification of Thre
41 matches
Mail list logo
