If you follow the Java world, you'd have a hard time missing the announcements about Terracotta's BigMemory over the past few days. The module, a part of the open source Ehcache caching library, bypasses the traditional Java garbage collection mechanism and creates its own memory, which can be much bigger (thus the name!) than Java's GC heap. Access to data in this store isn't as quick as accessing the standard Java heap, but the elimination of traditional garbage collection will supposedly make up the difference.
Terracotta is of course touting this as a breakthrough. And to be sure, garbage collection's impact on performance has been a somewhat vexing issue since the earliest days of the platform, with elaborate support documents explaining how to tune your garbage collection just so. Terracotta's solution seems to cut this Gordian Knot.
On the other hand, most Java shops have already learned how to tune their apps for Java's GC. Thus, adopting BigMemory might well mean losing a lot of the work that went into building an application in the first place. In the end, BigMemory seems to fall into that category of tool that sacrifices finesse for ease of use. It will be interesting to see if new projects are more likely to start with it than old ones adopt it.
I'm off on vacation next week -- I'll be back on the 27th, perhaps with exciting news from JavaOne!
This story, "BigMemory a 'breakthrough' -- or a solution looking for a problem?" was originally published by JavaWorld.