How does BigMemory hide objects from the Java garbage collector?

Consider a Java HashMap, which allows you to store and later access information by key (see IDictionary in .NET for equivalent). While there is a "bucket array" in the HashMap, that is only one object, and only consumes about 6-7 bytes on average per entry. The real killer is this: Each item placed into the HashMap holds at least three objects that the GC has to look at and subsequently decide to ignore: (1) the HashMap.Entry object, (2) the key, and (3) the value. If the key and the value are Strings, then that is actually 5 objects, since each String also has a reference to its own char[] object. If the key and/or value are complex business objects, they may represent hundreds of objects per entry! So, if you can "serialize" objects and store them in a series of ByteBuffer objects, you can reduce the number of objects necessary to keep that data in memory by somewhere between 95 - 100%. Since GC pauses are largely a function of the (a) the number of objects and (b) the amount of inter-connectedness of those objects, reducing the number of objects will decrease GC time. Unfortunately, to pull them back onto the heap so that you can use them as objects, you do have to "deserialize" them, so this won't be as fast as the HashMap, for example, and the deserialization will produce garbage of its own. (Note that such garbage tends to be localized, and thus cleaned up very efficiently by a young generation GC.) The concept of BigMemory is very similar to the old (2002) off-heap storage feature in Coherence (see BinaryMap on http://tinyurl.com/m6kp8bw), which was the precursor for the Elastic Data feature for RAM & flash storage that is in Coherence today (see http://tinyurl.com/oz3dend). For  the sake of full disclosure, I work at Oracle. The opinions and views   expressed in this post are my own, and do not necessarily reflect the    opinions or views of my employer.