Re: Get libffi closures to cope with SELinux execmem/execmod

[Alexandre Oliva <aoliva at redhat dot com>]

On Jan 19, 2007, Hans Boehm <Hans.Boehm@hp.com> wrote:

> The collector can register finalizable objects in a way that
> either does or doesn't prevent objects they reference from being
> finalized in the same cycle,  The default is to prevent such
> finalization.  But Java requires that objects normally be registered
> the other way, so that they can be finalized in any order.  And we
> do that.

> If you are taking this into consideration, please ignore this message ...

I wasn't.  Thanks for pointing this out.  I've come up with a testcase
that crashes with my previous patch, it's attached below.

Now, if I'm reading you correctly, it's not the object itself that
determines whether its finalizer can run while there are other
pointers to it, but rather the object that points to it.  Is this
correct?

I ask because I reasoned I could create a GC-managed pointer to the
closure list, and register a finalizer for that pointer such that the
closure list would only get deallocated when the class that held the
pointer to it was collected.

As it turned out, this wasn't enough, but adding a second layer of
indirection to the closure list, such that both levels of indirection
involve finalizers registered with the traditional (!= Java)
semantics, it should work, right?  The pointer to pointer to the
closure list could get finalized in the same cycle as the class, but
the pointer to the closure list would be saved for another cycle, and
everything would work, right?

Well, too bad, it doesn't.  And it's not even because I'm
re-registering objects, which might cause the pointer to pointer to
remain live but without a finalizer, thus presumably enabling the
pointer to be finalized at the same time as the class that holds on to
it.  Yuck.  This is getting out of hand.

The problem is more subtle than this, although I can't quite figure
out how to deal with it.  AFAICT something is getting messed up such
that, when we try to run the finalizer for an object, some data
structures associated with that class are already gone, and that
includes something in the vtable that would have enabled the finalize
method to be called.

I don't see how it is even possible that we could have a live object
with a finalizer yet to be run that wouldn't keep its class object
alive along with all other data structures, but this is what appears
to be going on.

ATM I'm considering doing away with the closure list and creating a
finalizable pointer for each closure, storing the pointer just next to
the pointer to the closure.  This would probably waste a lot of
memory, but it would at least take us back to where we stood in terms
of keeping closures around long enough.

I'll get back to banging my head against this wall after getting some
sleep, but if any of you have any insights to offer, I'm all ears.

Thanks,

Attachment: testGC.java
Description: Binary data

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}