[Vm-dev] Is it possible to suspend the garbage collector?
Max Leske
maxleske at gmail.com
Sat Jan 9 11:03:55 UTC 2016
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
More information about the Vm-dev
mailing list