[jmm-dev] Non-core-model issues status

[Hans Boehm]

The other alternative is to run a sufficiently complete GC when you get low
on "native" resources.  Since we seem to be using the GC to manage more
than just Java memory, triggering it only based on the Java heap looks more
and more like an (admittedly universal) implementation misfeature to me.

I think the solution that Andrew proposed doesn't quite work, particularly
if the code uses "finalizer guardians", as is often recommended.  The
objects that refer to a finalizable object can still be promoted to the old
generation, thus retaining the finalizable objects.  But there exist
implementation solutions, so I don't think this requires a spec change.

Hans


On Mon, Sep 8, 2014 at 2:11 AM, Andrew Haley <aph at redhat.com> wrote:

> On 07/09/14 06:55, Hans Boehm wrote:
> > I think the
> > premature finalization issue we're talking about is the most serious
> > problem we have in this area.
>
> I don't think so.  There is a related problem in that finalizers don't
> necessarily run.  This is particularly so with generational collectors
> when an object is moved into the old generation, and the old
> generation isn't scanned until the heap runs very low.  I have seen
> cases where the old generation is never scanned, and the system
> eventually runs out of native resources.
>
> This is true of the PKCS11 crypto provider.  It is part of OpenJDK,
> and I have been unable to fix it despite working on it for some time.
>
> I have been thinking about a workaround: when a class is annotated as
> finalizable, modify the garbage collectors so that its instances are
> never placed in the old generation.  My reasoning is that if a class
> is finalizable, it probably has some native resource that should be
> recycled, and it is best to do so as soon as possible.  And this is
> "probably" cheaper than the cost of not moving this object to the old
> generation.
>
> But even though I believe this would solve some current problems, it's
> still not what I'd call "correct".
>
> Andrew.
>
>
> https://bugs.openjdk.java.net/browse/JDK-6913047
>