Get libffi closures to cope with SELinux execmem/execmod

[Hans Boehm]

On Fri, 9 Feb 2007, Alexandre Oliva wrote:

> 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.
If B uses ordered finalization, it's finalization mark procedure will
mark A as not being ready for finalization this cycle, as it should.
Thus neither A nor B will get finalized, I think.

The basic issue is that in the most general case, client code needs
to let the collector know which fields are needed for finalization.
The way you do that currently depends on whether the object in question
uses ordered finalization.  With the simpler scheme, that breaks.

I will admit that there is little code for which this is an issue.

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

Sounds good to me.

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