[squeak-dev] FFI pinning examples?

Eliot Miranda eliot.miranda at gmail.com
Fri Aug 25 14:10:50 UTC 2017


Hi Ben,



_,,,^..^,,,_ (phone)
> On Aug 24, 2017, at 9:53 PM, Ben Coman <btc at openinworld.com> wrote:
> 
> 
> 
>> On Fri, Aug 25, 2017 at 6:06 AM, 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:.
> 
> Sorry I haven't looked at the implementation (and no Image near me right now) but a random query crosses my mind,
> does/can the function called externally return the new location, rather than having to do this in two steps.
> This might help ensure people are aware the new address should be dealt with.

Right.  pinObject: either answers the possibly moved oop of the pinned object or answers 0 if the pinning attempt failed.  So one can indeed do things in one step. 

> 
> cheers -ben
>  
>> 
>> 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/20170825/46563304/attachment.html>


More information about the Squeak-dev mailing list