[jmm-dev] ECOOP, JVMLS

[Hans Boehm]

The lack of a super.finalize() call is a bug.  I might argue it's a second
order one, since the lack of finalization ordering pretty much requires
that you understand what else might be getting finalized in your general
vicinity.  But I agree that the call should have been there.

I also agree that it would be possible to use synchronized methods instead
of empty synchronized blocks, especially for the finalizer.  IIRC, that was
purely a stylistic choice to expose the symmetry with keep_alive, and to
make it clearer that this is not sufficient for replacing whatever other
synchronization may be required to protect the resource pool that the
finalizer is adding to.  And I wanted to suggest a seperate keep_alive
call, so that it could be easily replaced once we fixed the spec.  It also
hopefully alerts the reader that this is not your average critical section;
it's intentionally doing something weird, and deleting it without
understanding why it's there might be a mistake.


On Thu, Aug 7, 2014 at 3:24 PM, Ludwig, Mark <ludwig.mark at siemens.com>
wrote:

>  Thanks.  I didn’t mean it as a criticism, just an observation.  (I
> didn’t get to JavaOne in 2005.)  I’m still digesting the presentation,
> because the reachability problem is a lot more subtle that any of us
> realized  (and a few of us in my group like to think of ourselves as
> “systems” guys, not just “application programmers”).
>
>
>
> When you wrote about synchronized(this) {} I had no idea you meant that
> literally; I thought you just omitted the implicit “…” between the braces.
> When I first read the presentation and saw you *did* mean it literally,
> it blew my mind … but now it makes sense as coordinating with the
> synchronized method keepAlive().
>
>
>
> Once upon a time (this code dates from Java 1.1, ca. 1997), the finalize
> method in this class was marked as synchronized.  It’s not now (through
> maintenance over the years) because we thought there was a performance
> problem with that (i.e., unnecessarily slowing down the Finalization thread
> with the lock overhead for something that could never be locked).  The
> performance impact of marking the finalize method synchronized should be
> the same as synchronized(this) {} at the top of the method since one
> thread is involved.  (That is, it’s not as though any other finalize
> method can run while this class’s finalize method is running, so it’s not
> as though there is any throughput increase by not marking the whole method
> as synchronized, is there?  I have the impression, though, that there
> must be a reason not to just mark the finalize method synchronized.  What
> is it?
>
>
>
> I’m also surprised there is no attempt to invoke super.finalize() in your
> example.  Isn’t that a good idea (even required?), pro forma?
>
>
>
> Cheers,
>
> Mark
>
>
>
> *From:* Hans Boehm, Monday, August 04, 2014 2:42 PM
>
> That's probably a valid criticism.  I did give a 2005(?) JavaOne talk on
> the subject, which was attended by about 1000.
>
>
>
> There are currently several possible variants of the pattern, all ugly.
>  One variant is at slide 35 in
> http://hboehm.info/misc_slides/java_finalizers.pdf (essentially the
> slides from that ancient JavaOne talk, which no longer seem to be available
> from a more official site, but were for a number of years).
>
>
>
> Hans
>
>
>
>
>
>
>
> On Mon, Aug 4, 2014 at 12:21 PM, Ludwig, Mark <ludwig.mark at siemens.com>
> wrote:
>
> > From: Hans Boehm, Monday, August 04, 2014 2:04 PM
>
> >
> > We've been telling people since 2005 that
> > you need synchronized(this){} all over the place in code with finalizers,
> > and I have yet to see a single piece of code "in the wild" that actually
> > does this.
>
> How has this message been distributed?  (The message certainly
> has not been effectively conveyed....)
>
> What is the pattern, exactly?  I assume I don't need a synchronized
> block inside a synchronized method....
>
> Thanks,
> Mark Ludwig
>
>
>