Re: [hoc-devel] Issue 27 in hoc: Updates for 64-bit and Objective-C 4

[<cod...@go...>]

Comment #4 on issue 27 by james.c...@usma.edu: Updates for 64-bit and  
Objective-C 4
http://code.google.com/p/hoc/issues/detail?id=27

Oh, sorry I forgot to mention the poor usage of mmap - thanks for reminding  
me.  Glad to see you've looked at the changes though ;)

I'm planning to implement a light-weight allocation scheme where the  
closures are allocated, say, pagesize / sizeof(ffi_closure) at a time and  
then we just take the next one when we need one.  Either that or if it's  
not too difficult (and available on gnustep) I might set up an  
NSAllocationZone or whatever it's called, but that seems like overkill  
since AFAIK we never actually free any ffi_closures.

Am I correct in thinking that if we wanted to we could even allocate them  
in batches of a few thousand without problems?  mmap should return memory  
that isn't actually backed until used, right?  Not that it's a big deal,  
but I'm pretty sure that sizeof(ffi_closure) doesn't usually divide the  
page size evenly, and an easy way of avoiding a bit of waste per page would  
be to just allocate a number of closures equal to the number of bytes per  
page.

Regarding the issue tracker - Google's is pretty nice, but Github does also  
provide an issue tracker - do you have any opinions about the relative  
merits of the two?

PS - an IRC discussion about this stuff broke out last night and a few  
other potential collaborators surfaced.  We've created #haskell-objc on  
freenode and a few interested parties are now lurking there.  If anyone is  
interested, feel free to join us (I'm "mokus" on IRC).