2009/9/8 Tamas K Papp <tkpapp@...>:
> Is stopping the GC on some objects with sb-sys:with-pinned-objects a
> costly operation in itself? (on Linux, X86, if I need to be specific).
> I can't benchmark it separately (I always get zero/immeasurably small
> time if I do nothing in the body, maybe the compiler is very smart?).
> An intuitive feel would be good enough, eg "this is a very cheap
> operation, just setting a few bits", or "this is a major thing for the
> gc, don't do it 30 times in a simple function call".
Pinning an object itself is quite cheap, essentially just pushing a
word on stack -- sometimes not even that if the compiler figures out
the requisite pointer is on stack anyways.
The secondary cost of pinning comes from GC needing to scavenge the
entire pinned page, assuming all objects on the page are live. The
cost of this depends on a number of factors: if most of those objects
would be live anyways, the cost is neglible. If GC doesn't run at all
while the object is pinned there is no cost. If the page contains a
root of a deep object tree that would otherwise be garbage... that
costs. If the pinned object was stack-allocated in the first place,
there is no secondary cost. If you pin multiple objects that have been
allocated sequentially, the chances that they are all on the same page
are good. In this case the secondary cost is paid only once.
When pinning is needed the only real option tends to be copying the
object to be pinned into immobile memory: where performance is a
concern you can always try it both ways and measure the difference.