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

[Alexandre Oliva <aoliva at redhat dot com>]

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

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

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

Indeed, you're right.  I was basing my reasoning not on the code, but
on what I thought would be the right thing to do.

It wouldn't be too hard to make it match the behavior I expected:

1. enqueue all unmarked Java-finalization objects for finalization
(new loop)

2. run the loop over other finalization-enabled objects that runs
their mark procedure (like before, but Java objects have already been
enqueued for finalization)

3. enqueue unmarked objects for finalization (like before)

4. mark Java objects enqueued for finalization (as in my proposed
change)

5. dequeue non-Java objects that are marked, and mark them otherwise
(as in my proposed change)


The reason I like this design is that it respects the properties that
each object requested: Java objects get finalized even if other
objects (of any kind) point to them; other objects only get finalized
when no other objects (of any kind) point to them.

The new loop would be as simple as a copy of the loop that follows:
  /* Enqueue for finalization all objects that are still		*/
  /* unreachable.							*/

except that it would be enclosed in an if (GC_java_finalization), and
instead of:

	    if (!GC_java_finalization) {
              GC_set_mark_bit(real_ptr);
	    }

it would do:

 	    if (curr_fo -> fo_mark_proc != GC_null_finalize_mark_proc) {
              continue;
            }
  

Sounds sound? ;-)


Then we could change GC_null_finalize_mark_proc() such that it
abort()s if it's ever called (such that, if you use Java finalization,
you have to set GC_java_finalization; if you don't, things just don't
quite work as expected) and tweak GC_register_finalizer_no_order() to
set this variable.  Makes sense?

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