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

["Boehm, Hans" <hans dot boehm at hp dot com>]

I'm still missing the big picture with respect to the finalization
changes.

Normally, the GC's intended usage model is that if I have an object P
whose finalizer accesses other referenced objects R, then I register P
with something like the "normal" finalization mark procedure, so that
the referenced objects R don't get finalized until P is done with them.
I think you are proposing to somehow have the objects R know that they
might be referenced by another finalizable object, and hence postpone
their own finalization by a cycle.  That seems fundamentally backwards
and brittle.  This just isn't R's business.

Can't we just register the referring object (P, the class in the real
case, I think) correctly?

Hans

> -----Original Message-----
> From: Andrew Haley [mailto:aph@redhat.com] 
> Sent: Wednesday, January 24, 2007 7:47 AM
> To: Alexandre Oliva
> Cc: green@redhat.com; Boehm, Hans; gcc-patches@gcc.gnu.org; 
> java-patches@gcc.gnu.org
> Subject: Re: Get libffi closures to cope with SELinux execmem/execmod
> 
> Alexandre Oliva writes:
>  > On Jan 22, 2007, Alexandre Oliva <aoliva@redhat.com> wrote:
>  >
>  > > Now, if I'm reading you correctly, it's not the object 
> itself that  > > determines whether its finalizer can run 
> while there are other  > > pointers to it, but rather the 
> object that points to it.  Is this  > > correct?
>  >
>  > It was, so I added an option to get the other behavior, 
> that appears  > to be generally desirable for Java 
> system-level resource disposal,  > through objects whose 
> finalizers should only run when the  > corresponding objects 
> are unreachable even from other finalizable  > objects.  It 
> was quite easy to add, after I figured out how it worked.
>  >
>  > > As it turned out, this wasn't enough, but adding a 
> second layer of  > > indirection to the closure list, such 
> that both levels of indirection  > > involve finalizers 
> registered with the traditional (!= Java)  > > semantics, it 
> should work, right?
>  >
>  > No.  Especially if one allocates the doubly-indirect 
> pointer as not  > containing pointers.  *blush*  :-)  >  > 
> Fixing that enabled things to work until I added finalizers 
> that would  > resurrect objects, perhaps even multiple times 
> (consider a finalizer  > that optionally creates another 
> instance of the same class, bringing  > back to life the 
> class and the class loader).
>  >
>  > At that point, after scratching my head for a while trying 
> to figure  > out a way to implement the needed semantics with 
> the existing  > primitives, I concluded it couldn't be done, 
> and so I came up with new  > finalizer semantics option 
> described above.
>  >
>  > Is this ok to install?  Tested on x86_64-linux-gnu.
> 
> Mmm, this looks good.  
> 
> OK, Hans?
> 
> Paging Anthony Green ... any comments?
> 
> Andrew.
>