Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Before Implementing Garbage Collector Algorithms for MMTk

DZone's Guide to

Before Implementing Garbage Collector Algorithms for MMTk

Free Resource

Sensu is an open source monitoring event pipeline. Try it today.

Jikes RVM comes bundled with multiple plans, allowing us to build it with a preferred garbage collection algorithm, either concurrent such as concurrent mark and sweep (CMS), or the stop the world implementations that are not concurrent. When implementing a concurrent garbage collector, it is recommended to benchmark it against CMS collector, as it is the complete concurrent collector in production, where all the other collectors operate in the stop-the-world manner, where the program threads are halted.

Testing whether a new collector will work with the current build is a good starting point before actually starting with the coding.

[1]. First build Jikes RVM, with MarkSweep garbage collector
bin/buildit -j $JAVA_HOME localhost BaseBase MarkSweep

[2]. Test the GC
bin/buildit -j $JAVA_HOME localhost -t gctest BaseBase MarkSweep

[3]. Dummy Compressor GC.
Before testing the real implementation of the new GC algorithm Compressor, we will test that it will work.

Copy the package org.mmtk.plan.marksweep in MMTk/src as org.mmtk.plan.compressor and rename the package names accordingly.

In build/configs, copy BaseBaseMarkSweep.properties as  BaseBaseCompressor.properties

[4]. Test the dummy compressor GC
bin/buildit -j $JAVA_HOME localhost -t gctest BaseBase Compressor

You should be able to see the [echo] ... SUCCESS as seen above in [2], upon a successful build. Now this is time to check the implementation of the new algorithm.




Sensu: workflow automation for monitoring. Learn more—download the whitepaper.

Topics:

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}