Eliot,

That sounds very straightforward and logical.  I had only taken a quick
glance in a recent image and didn't notice anything obvious in FFI so I
thought I'd just ask before going further.

Thanks for the tip re: making sure to keep a reference in the image to
avoid gc as I'm sure that would have bitten me at some point since my plan
is to try creating some reusable buffers see if I can speed up some things
re: text and image processing. (i.e. I might not have thought to hang onto
it once it had been passed to FFI which I'm sure would not have been fun to
track down)

Also just FYI, I'm also looking forward to your threaded FFI work as I'm
hoping to be able to create a persistent rendering thread for OpenGL (this
could be a performance gain of up to 80-90% for heavy rendering code) which
should also benefit from pinning.

Thanks,
Phil


On Aug 24, 2017 6:06 PM, "Eliot Miranda" <eliot.miranda at gmail.com> wrote:

Hi Phil,

On Thu, Aug 24, 2017 at 1:36 PM, Phil B <pbpublist at gmail.com> wrote:

> I remember reading a while back that Spur added memory pinning and was
> curious if any Squeak packages has made use of it yet? (Looking for an
> example or two to get me started)
>

The protocol i in Object, with the selectors pin, unpin and isPinned.  You
can send any of these to any non-immediate object.  It is your
responsibility to avoid calling unpin until external code no longer holds
references to any pinned object.  It is your responsibility to arrange that
the objects are still accessible within the system so that they are not
GCed while external code holds onto them.  Pinning is orthogonal to GC.  It
prevents the GC from moving objects, but does not prevent them from being
GCed if no references to them exist in the Smalltalk system.  Note that
also pinning may cause an object to move from newSpace to oldSpace, as
objects are only pinball in oldSpace.  Pinning a new object causes it to
become a copy of the object in oldSpace, so do not pass an object to
external code and then pin it; it may move.

 So the idea is
- create some objects you want to share with external code and pin them
- pass them to that external code through the FFI
- allow that external code to run (e.g spawn a thread in the external code,
or make subsequent call though the FFI exercise the code)
- shut down the external code
- unpin your objects, or merely allow them to be GCed.

Alternatively external code can pin the objects it is given, providing it
updates their location afterwards.  See pinObject:.

Note that you should use the interpreterProxy accessors
firstIndexableField: and firstFixedField: to find out the start of the body
of an object (pinned or otherwise).  byteSizeOf:, instanceSizeOf:,
slotSizeOf: and stSizeOf: can all be used to find out various sizes.  See
platforms/Cross/vm/sqVirtualMachine.h, which also provides pinObject: and
unpinObject:.

Clearly some work is needed to add documentation in the right places.  LMK
where you looked, where you would expect to find such information, etc.
-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170824/782a400c/attachment.html>