[Vm-dev] Is it possible to suspend the garbage collector?

[Eliot Miranda]

Hi Max,

    pre-Spur to avoid GC one has to a) grow memory by enough to do all the
processing you're going to do and b) change the shrinkage parameter so the
Vm won't shrink the heap back down before the processing is complete.  To
do b) I suggest you modify setGCParameters.  vm parameters 24 sets the
shrinkage threshold; see vmParameterAt:put:: "24 memory threshold above
whichto shrink object memory (read-write)".  growMemory.  Hmmm, I had
thoguht that there's a growMemoryBy: primitive in v3, but it appears there
isn't.  So simply allocate a ByteArray of the desired size and then GC to
get rid of it.  That should leave that much free space and then your load
should proceed without needing to GC.

Anyway, it's worth a try.

On Sat, Jan 9, 2016 at 3:03 AM, Max Leske <maxleske at gmail.com> wrote:

>
> Hi,
>
> I have a rather annoying problem. I’m running a time critical piece of
> code that reads a big (~90MB) image segment from a file. I’ve optimized
> loading as far as possible and now GC takes far longer than the loading
> itself (see the MessageTally output below).
> I’m wondering if there’s any possibility to defer garbage collection
> during the load.
>
> For completeness, here’s the use case: the process is socket activated,
> which means that the first request coming in will start the process. When
> the image starts it will load the segment to restore the last state of the
> application and, once that’s done, serve the request. The critical time
> includes vm startup, image startup, starting the server in the image and
> loading the snapshot. With a big snapshot the loading time of the snapshot
> is the most significant contributor.
>
> Maybe I could preallocate the needed memory to prevent the garbage
> collector from running?
>
> I’d appreciate any ideas you have.
>
>
> Cheers,
> Max
>
>
> PS: This needs to run on a Squeak 4.0.3 VM (no JIT)
>
>
>
>
> Output from MessageTally:
>
>  - 1624 tallies, 1624 msec.
>
> **Tree**
> --------------------------------
> Process: (40s)  592969728: nil
> --------------------------------
> 4.4% {72ms} CBImageSegment class(NSImageSegment
> class)>>basicSnapshot:from:do:
>   4.4% {72ms} CBImageSegment class(NSImageSegment
> class)>>installSegmentFrom:andDo:
>     4.4% {72ms} CBImageSegment class(NSImageSegment
> class)>>readSegmentFrom:
>       4.4% {72ms} NSSegmentStream>>readObject
>         4.4% {72ms} SmartRefStream>>nextAndClose
>           4.4% {72ms} SmartRefStream>>next
>             4.3% {70ms} SmartRefStream(ReferenceStream)>>next
>               4.3% {70ms} SmartRefStream(DataStream)>>next
>                 3.2% {52ms}
> NSImageSegment(ImageSegment)>>comeFullyUpOnReload:
>                   3.2% {52ms} NSImageSegment>>restoreEndiannessAndRehash
> **Leaves**
> 3.2% {52ms} NSImageSegment>>restoreEndiannessAndRehash
>
> **Memory**
>         old                     +92,704,656 bytes
>         young           -8,008,252 bytes
>         used            +84,696,404 bytes
>         free            +1,287,768 bytes
>
> **GCs**
>         full                    2 totalling 954ms (59.0% uptime), avg
> 477.0ms
>         incr            5 totalling 165ms (10.0% uptime), avg 33.0ms
>         tenures         1 (avg 5 GCs/tenure)
>         root table      0 overflows




-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160110/c0a64c28/attachment.htm