Disk IO as 2-Space GC

A while back, probably 6 months to a year ago, I was studying garbage collectors with the intent of using one in a small programming language I was building. I had recently discovered the two space collector model, and admired the simplicity in the design. Then, an unholy idea occurred to me.

The variant

Instead of two memory spaces, I realized I could use one memory space + hard disk storage. Instead of memory-to-memory copies, live objects would be serialized to disk, and during deserialization, would simply overwrite the “active” memory space.

The idea is a bit ludicrous, but I went ahead and made a list of pros and cons,
since I found the idea interesting.

– Free program persistence. A program could resume from the point when the last GC occurred.
– Larger memory space (well, larger than the active space of a traditional two-space collector).

– High CPU and memory usage during collection. Unless done incrementally, serialization would likely eat up a good deal of resources. Same for deserialization.
– Disk IO is typically slow, thus, GC would be slow.

Where would something like this collection strategy be useful?

I suppose in an embedded situation, where memory is scarce, and the CPU is not terribly fast, but disk space is plentiful, and IO costs are reasonable, I
could see a strategy like this being worthwhile.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s