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

[Andrew Haley <aph at redhat dot com>]

Alexandre Oliva writes:
 > On Jan 31, 2007, "Boehm, Hans" <hans.boehm@hp.com> wrote:
 > 
 > > I still think this is really ugly in principle, but I'm now inclined to
 > > agree that we need such a mechanism.  (This is not a statement about
 > > Alexandre's implementation, which is quite clever and clean.)
 > 
 > Thanks
 > 
 > > We have an object O1 which is finalizable, and indirectly points to O2.
 > > O2 is the last member of class P, and the representation of class P
 > > includes a resource R that must be explicitly reclaimed when P is
 > > collected.  (Which presumably happens when P's class loader is also
 > > collected?)
 > 
 > Yep
 > 
 > > Thus R has a finalizer.  O1 sometimes resurrects itself from its
 > > finalizer.  (Or it might resurrect some other object on the chain to
 > > O2; it doesn't matter.)  Since Java finalization is unordered, R may
 > > be finalized, even though it will be needed again after O1
 > > resurrects itself.
 > 
 > I'd state it even more generally without involving objects and
 > classes.  Multiple objects O_n point, directly or indirectly, to R.
 > Although the objects are configured for unordered finalization, R is
 > configured for traditional finalization, such that, when its finalizer
 > runs, it knows no other finalizer can resurrect it.
 > 
 > > The way the GC was originally designed, this should be impossible
 > > because R won't be considered for finalization after O1 has run.
 > 
 > Exactly.  And this is the very property I'm trying to restore.  The
 > way the GC was originally designed, it held that:
 > 
 >   terminally_unreachable(O_j) => O_j is finalizable
 > 
 > but as it turned out this could be implemented with a simpler, more
 > local test:
 > 
 >   O_i reaches O_j => O_j is not finalizable
 > 
 > and in the stage of preparation for finalization i only had to iterate
 > over other potentially-finalizable objects, because other live objects
 > would have already made O_j ineligible.
 > 
 > But then, when Java finalization was introduced, this conceptual model
 > fell apart, because Java finalizers can (and should) run even for
 > objects that are reachable (from other finalizable objects).
 > 
 > However, it also broke the implementation above for mixed cases.  It
 > no longer holds that, if for every j such that O_j is a finalizable
 > object with normal semantics and terminally_unreachable(O_j), there
 > exists some i such that O_i is also a finalizable object with normal
 > semantics and O_i reaches O_j.  O_j may be reachable from a Java
 > object, and that's what breaks the original property.
 > 
 > The change I proposed restores the property, but in a more localized
 > way: only if you say "hey, I really care about that original property"
 > will it enforce it.  In other cases, we'd use the implementation that
 > worked to enforce the property for non-mixed cases but that fails to
 > enforce it in border cases.  This sounds broken to me.
 > 
 > > Thus we need a way for R to protect itself without cooperation from O1,
 > > which we don't control.  Alexandre's patch does that by allowing objects
 > > to declare themselves to not be finalizable while reachable from other
 > > finalizable objects, overriding other instructions to finalize objects
 > > out of order.
 > 
 > > The reasons I don't feel enthusiastic about including this:
 > 
 > > - It doesn't fit well with the GCs original design.  It feels like a
 > > hack on the interface, even more so than the Java finalization
 > > extension.
 > 
 > I agree.  That's why I've been hinting that, instead of adding a new
 > finalization type, we should modify the non-Java finalization types
 > such that they enforce the original property even in Java mode.
 > 
 > I haven't been able to think of any case in which it could possibly be
 > useful for a finalizer to want to run only if no other finalizers with
 > normal semantics reach it, even if other finalizers with Java
 > semantics do.
 > 
 > What I have in mind is something like this (untested) patch.  How do
 > you feel about it?

Is there any reason (to do with correctness) why we can't commit your
existing patch as is?

Andrew.