This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Feb  9, 2007, Hans Boehm <Hans.Boehm@hp.com> wrote:

> Now assume A has another field f2 that (possibly indirectly) points to a
> (ordered) non-Java-finalizable object B.  Assume for the case of argument
> that it points back to A since B and Bs finalizer needs A.

> In case 2:  B is reachable from A, and the author of A had no reason to
> avoid that, since unordered finalization is used.  But now if I let
> that inhibit finalization of B, I have a finalization cycle, and neither
> can get finalized.  That seems wrong.

Err...  If B is part of a cycle and it requires ordered finalization,
it must not get finalized.  It doesn't matter if other objects in the
cycle have ordered or unordered finalization, or even no finalization
at all.  This is the case in both the current implementation and with
the alternate implementation I've suggested, so I'm not sure what
you're getting at.

This won't stop A's finalizer from running, and if A's finalizer
clears the reference to B, B will eventually be finalized.  But if A
doesn't, B will be forever part of a cycle, which sounds like correct
behavior to me, even if undesirable.

> I think the solution below incurs a slight risk of breaking something,
> if e.g. Mono relied on the current behavior someplace.  But I could
> also live with the variant in which this was a global (initialization
> time) option, and the code below were wrapped in a suitable conditional.
> The GC already has some such options.

> Otherwise, the original patch seems fine.

If you see that the potential distinction can be put to good use, then
let's go with the original patch.

Ok to install?

-- 
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}


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]