[squeak-dev] Pinning Objects in Pharo

Ben Coman benjamin.t.coman at gmail.com
Wed Aug 30 21:30:23 UTC 2017

Thx Eliot for that detailed description. What might be the impact of a
default-pin every object passed to FFI?

Cheers -ben

On 30 Aug 2017 11:46 PM, "Eliot Miranda" <eliot.miranda at gmail.com> wrote:

Hi Torsten, Hi All,

   re pinDuring:

> On Aug 28, 2017, at 9:17 AM, Torsten Bergmann <astares at gmx.de> wrote:
> As some of you are aware of Spur added memory pinning and in Pharo 6.1
(#60510) as well as Pharo 7
> we currently have
> Object>>pin
> Object>>unpin
> Object>>isPinned
> and also Object>>setPinned:.
> Object pinning is explained by Eliot here [1].
> I would propose two changes (at least for Pharo but ideally also for
> 1. IMHO #setPinned: should be moved to a private protocol
> 2. Provide a #pinDuring: aBlock method like:
>      pinDuring: aBlock
>          [ self pin.
>            aBlock value ] ensure: [ self unpin ]
>    so we can ensure that a pinned object is unpinned after an operation.

>From an implementation perspective, I suspect this is unnecessary.  There
are two reasons, one to do with collecting pinned objects and the other to
do with compaction.

Pinning an object forces it into oldSpace if it was not there already, but
does not prevent it being garbage collected. So any un references pinned
object in oldSpace will be collected at the next full GC.

It is possible (but in implemented) to move not large objects back to
newSpace but the forwarder left in oldSpace will prevent its collection
until the next full GC so trying to move an object back into newSpace is
pointless.  Conclusion, there is no point unpinning for garbage

The compactor does a good job of moving unpinned objects around pinned
objects, typically leaving very small gaps before pinned objects.  [One can
observe how much free space exists in an image file to get an idea of how
much free space this causes.  It's low]. The number of uncollectable pinned
objects in an application, which will be objects that are long-lived that
have been passed through the FFI, is likely to be small.  Conclusion there
is little to be gained in avoiding fragmentation by unpinning long-lived
objects pinned on an FFI call.

In summary, collectible ones objects will be collected anyway, and the few
long-lived pinned objects should not cause significant fragmentation.  So
pinDuring: is unlikely to provide any benefit.  Simply pin and leave it to
the GC and its compactor to clean up afterwards.

> What do you think?
> Also I wonder why FFICallbackTests>>#testCqsortWithByteArray is sending
#pin but not
> #unpin afterwards. Maybe that is the reason why there is a flag in this
method that it
> is crashing on Windows.
> Bye
> T.
> [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170831/6f8d4039/attachment-0001.html>

More information about the Squeak-dev mailing list