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

Max Leske maxleske at gmail.com
Sat Jan 9 11:03:55 UTC 2016


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.


PS: This needs to run on a Squeak 4.0.3 VM (no JIT)

Output from MessageTally:

 - 1624 tallies, 1624 msec.

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
3.2% {52ms} NSImageSegment>>restoreEndiannessAndRehash

	old			+92,704,656 bytes
	young		-8,008,252 bytes
	used		+84,696,404 bytes
	free		+1,287,768 bytes

	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