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

[David Daney <ddaney at avtrex dot com>]

Andrew Haley wrote:
> 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.
>   
Well I'm not Anthony, but I am concerned about the overhead for systems 
that have an executable stack.  I am thinking small embedded systems.  
It would be nice to have some sort of configure option that would allow 
us to build it the old way, or close to the old way if desired.  That 
said, I have not measured the size of the dlmalloc and other additions 
to know if it really makes a difference.  I am trying to put an entire 
Linux/GNU system with an application statically linked to libgcj into a 
16MB flash memory.  Adding more code to libgcj does not make it any easier.

David Daney