[Larceny-users] How to lock down Larceny memory

[David Rush]

2009/7/13 Felix Klock <felixluser at pnkfx.org>:
> On Jul 13, 2009, at 8:05 AM, David Rush wrote:
>
>> [...] I will need to keep a bytevector pinned at the address it
>> has when I first push it through the FFI across many different calls
>
> The short answer: the Larceny FFI has to do this too (my Scheme Workshop
> 2008 paper [1] talks a bit about why), so we have some support for it; look
> in lib/Ffi/memory.sch.

Ok :)

> The long answer:
(re: allocating bytevectors that won't ever be collected)

This is relatively easily to manage by using an old-style free-list in
my user-space.  Obviously, this is less than ideal.

> Having said that, I *want* to fix the implementation of the procedures used
> by the FFI and offer it via the same API.  I have thought of ways to use
> tricks similar to footnote [2] to get nonrelocatable objects that can still
> be reclaimed by garbage collection.  I cannot spend time on the problem in
> the short term, but if you need better support for this feature than is
> currently present, let us know.  (If you were to offer to help test
> alpha-quality implementations of the feature, that might act as a catalyst
> towards getting them implemented.)

Hmmm...well better support would definitely help out a lot. I have
embarked on skunkworks project re-implementing a 90s-era financial
application (currently a monolithic windoesn't app using ODBC) as a
server farm to go into a high-volume OLTP environment. I would be
happy to test alpha code, assuming that I can transport a bootstrap
larceny heap image from a 32-bit debian build because I don't have a
properly configured environment for building Larceny on Win32. Past
experience leads me to believe that the heaps are fairly portable -
unless you know better, of course.

ATM, I am trying a hack using foreign-stdlib. That should still leave
me close to the kind of interface you would need for pinnable
bytevectors because, regardless of the solution you choose for
Larceny's implementation, at some point you have to finalize the
pinned extent. This is isomorphic to a manual free so it seems like it
would be all good.

> Part 2. How to replace one previously allocated object with another newly
> allocated object

> I hope you don't actually need to do this

No. And I remember the issue in Smalltalk, and it involved ugly hacks
there which are essentially equivalent to the solution you proposed.

> We may offer proper support for object pinning in the future; I know Will
> has told me that he sees it as the right direction.

Yay. Between the workarounds you suggested and the prospects of future
features, I'm good to go :)

> [2] The other way is to allocate the object to the Large Object Space (LOS); the

Evil hack :) But I will remember it if I ever get back around to my
soft synthesizer work. For that one I need big buffers to hand off to
windows...

david rush
-- 
GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt