This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Get libffi closures to cope with SELinux execmem/execmod
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Hans Boehm <Hans dot Boehm at hp dot com>
- Cc: Andrew Haley <aph at redhat dot com>, green at redhat dot com, gcc-patches at gcc dot gnu dot org, java-patches at gcc dot gnu dot org
- Date: Fri, 09 Feb 2007 16:27:21 -0200
- Subject: Re: Get libffi closures to cope with SELinux execmem/execmod
- References: <ork5zkiz8v.fsf@redhat.com> <17839.26733.654885.743254@zebedee.pink> <ortzynbre6.fsf@redhat.com> <Pine.GHP.4.58.0701190016420.29118@tomil.hpl.hp.com> <orhcuizr8q.fsf@redhat.com> <or7ivcx6qe.fsf@redhat.com> <17847.32655.463484.236251@zebedee.pink> <BDA38860DCFD334EAEA905E44EE8E7EF697A40@G3W0067.americas.hpqcorp.net> <orhcuegqc8.fsf@redhat.com> <BDA38860DCFD334EAEA905E44EE8E7EF697D38@G3W0067.americas.hpqcorp.net> <ory7np0w20.fsf@free.oliva.athome.lsd.ic.unicamp.br> <BDA38860DCFD334EAEA905E44EE8E7EF6DD868@G3W0067.americas.hpqcorp.net> <or4pq0r8hj.fsf@free.oliva.athome.lsd.ic.unicamp.br> <Pine.GHP.4.58.0702082151420.14492@tomil.hpl.hp.com>
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}