Martin's law of object pools in the presence of finalizers:
Resurrecting a pooled object with a finalizer can be disastrous as it
can be finalized later while in active use. Returning an object to
the pool is a common thing to do in close() methods, and close()
methods are reasonable thin
g discussion when we touched that part of the code last time.
> just
> for your reference:-)
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/thread.html#6545
>
> -sherman
>
>> My static reference was finalized because it used to be unreachable,
>
part of the code last
time. just
for your reference:-)
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/thread.html#6545
-sherman
My static reference was finalized because it used to be unreachable,
not because it is now weakly reachable!
On Mon, May 16, 2016 at 11:49 PM, Peter
Thanks, Peter.
My current theory is indeed that I made a mistake, and have
encountered my first real finalization resurrection bug.
ZipFile + Inflater have 4 finalize methods and a WeakHashMap in play!
My static reference was finalized because it used to be unreachable,
not because it is now
Hi Martin,
On 05/17/2016 05:19 AM, Martin Buchholz wrote:
I have some evidence that an object's finalize method can run while a
weak reference pointing to it is not yet cleared, which surprised me.
E.g.
class F { protected void finalize() { assert wref.get() != this; } }
static WeakReference w
I have some evidence that an object's finalize method can run while a
weak reference pointing to it is not yet cleared, which surprised me.
E.g.
class F { protected void finalize() { assert wref.get() != this; } }
static WeakReference wref = new WeakReference(new F());
If this is a bug, I can try
On 26/08/15 20:01, Aleksey Shipilev wrote:
> On 08/26/2015 06:07 PM, Doug Lea wrote:
>> On 08/26/2015 10:12 AM, Andrew Haley wrote:
>>> On 08/26/2015 03:01 PM, Doug Lea wrote:
This is an issue of large importance to a small audience,
and is at the moment an orphan. To work out, I think it
On 08/26/2015 06:07 PM, Doug Lea wrote:
> On 08/26/2015 10:12 AM, Andrew Haley wrote:
>> On 08/26/2015 03:01 PM, Doug Lea wrote:
>>> This is an issue of large importance to a small audience,
>>> and is at the moment an orphan. To work out, I think it
>>> requires at least some involvement from comp
On 08/26/2015 10:12 AM, Andrew Haley wrote:
On 08/26/2015 03:01 PM, Doug Lea wrote:
This is an issue of large importance to a small audience,
and is at the moment an orphan. To work out, I think it
requires at least some involvement from compiler and/or IDE
developers. If you are or know of some
On 08/26/2015 03:01 PM, Doug Lea wrote:
> This is an issue of large importance to a small audience,
> and is at the moment an orphan. To work out, I think it
> requires at least some involvement from compiler and/or IDE
> developers. If you are or know of someone who might be interested
> in pursui
. The second part seems to escape scope of these JEPs:
Supporting an annotation (most likely named @Finalized) that would
enable tools and/or compilers to convert methods of classes in
danger of premature finalization from
{ body }
to
try { body } finally { Reference.reachabilityFence(this); }
And
11 matches
Mail list logo
