Andrew Haley - Re: Get libffi closures to cope with SELinux execmem/execmod (original) (raw)

This is the mail archive of the gcc-patches@gcc.gnu.orgmailing 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]

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.

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