On Thu, 31 Aug 2017, Ben Coman wrote:

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

Slowdown. On each call all passed objects would be moved to oldSpace if 
they were not there already. Objects already in oldSpace would have their 
header rewritten (pinning). More frequent Full GCs because the garbage 
would accumulate in oldSpace.

Levente

> 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 Squeak):
> >
> > 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 collectability.
> 
> 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-August/195129.html
> 
> 
> 
>