FFI Issues (was Re: [GOODIE] SDL + Cairo + Morph)

[Brian Rice]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Dec 10, 2005, at 2:24 PM, Todd Fleming wrote:

> Brian Rice wrote:
>> I notice that you're concerned about the lack of locking by the  
>> GC.  The current GC does provide "pinning" to keep objects from  
>> being  moved around, but it's not sufficiently exposed and may not  
>> be  suitable for the kind of callback-like functionality you'd  
>> need.  There IS a way around this that I've been considering:  
>> basically by  using mmap() results as an ExternalResource which  
>> act like a File.  Like File's recent change, it'll support at:/ 
>> at:put: as a ByteArray.  I do have some local files as scratch  
>> surface for this code, with a  plugin and an attempt to integrate  
>> with the VM-internal file support.  What do you think of that  
>> possibility?
>
> PSObjectHeap_garbageCollect() clears the current pins.  It looks  
> like the only cards that get pinned are ones that have objects that  
> are referenced by the C stack.

You're right, the pinning feature is only used for the C stack and is  
internally managed by the GC currently.

> The bitmaps most likely will not be referenced by the C stack when  
> garbage collection occurs.  rootStack also doesn't work because  
> it's a stack and has a fixed size. Imagine this: pass bitmap A to  
> Cairo. pass bitmap B to Cairo. release bitmap A from Cairo.

Okay, I read into your cairo_patch and it makes more sense to me. But  
I need to know: when Cairo releases a bitmap, does it just call free 
() itself, or is there some way that you know that it's done with the  
memory area? If it tries to own the memory area, then we'll probably  
just have to make a memory pool manager in the C-side plugin - even  
with fixed-offset memory allocations, Slate and Cairo can't afford to  
fight over the ownership of memory areas.

> mmap() sounds like a better workaround than what I currently do,  
> but only if the mmap files work like a heap.  i.e. several hundred  
> in-memory bitmaps should not translate to several hundred mmaped  
> files.

Well, that's why mmap() can be called in various ways:
http://www.opengroup.org/onlinepubs/009695399/functions/mmap.html

About protocol, by default they are going to look like ByteArrays, or  
at least that's the easiest Slate API to provide. Making it look  
transparently like a heap would be extremely tricky.

I was going to make an argument about using mmap() in a way that the  
file is never touched or sync'd, or to try the typed memory object  
approach, but it occurred to me that this may not be that portable  
(the spec says as much). What may really be needed is something as  
simple as an ExternalResource for malloc() results, which would  
obviously need finalizers but would get us our functionality without  
as many portability problems.

What we're talking about here could make our FFI interface much  
different, so we should put some thought into the implications either  
before or after implementing it.

> Here's another memory-related problem: is there a way to create  
> destructors that get called when an object is garbage collected?   
> Right now Context will leak memory from the C heap if it gets  
> garbage collected without the user sending the destroy message.

No, we don't have a finalization hook yet, although it would be  
pretty easy to make #finalize an entry in the SpecialOopsArray so the  
VM can signal it when objects die. Ordinarily, I'd say that something  
more flexible like a block would help, but Slate's model shouldn't  
make #finalize methods any less flexible than keeping a block around.  
I guess that's just me shedding some Smalltalk background.

I'll step back and list our missing three important memory-management  
features: weak references/arrays, finalizers (and then weak-ref safe  
finalizers such as ephemerons), and immutability. There is a word- 
size field (accessible and settable from Slate as a SmallInteger  
"flags") in Maps that we are currently only using for marking object- 
meta lookup boundaries; that data could be used for weak/immutable  
markers, and we could even use a marker there to say if the memory  
manager needs to finalize the object at all. This would avoid a  
finalization call most of the time.

What opportunity we do have is the fact that vm/gc/mark-compact.slate  
could be replaced by another GC with a similar API and so forth as  
the existing one, and it may in fact be helpful to consider that to  
get these new features.

- --
- -Brian
http://tunes.org/~water/brice.vcf

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFDm2v5PVkAvLW1zf4RAvuyAKCE5R6ZNg+GWm5Q7Xq/7W7+0wrTJgCdEGSC
kxntNbnSEj+Rmv2zdgcrAP8=
=7W9g
-----END PGP SIGNATURE-----