Hans Boehm - 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]

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}

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