The challenge of garbage collection is almost as old as Java itself. Java Virtual Machines (JVMs) store programs' objects in a heap that is cleared from time to time to free up memory. The process was inserted so that programmers did not have to manually program the need to free up allocated memory. It provides an automated, …
Innacuracy in the very first sentence!
Garbage Collection has been around way longer than Java, its accredited to a John McCarthy in 1959 regarding Lisp, and I find it hard to believe he didn't think about the various algorithms and efficiencies within them.
I personally became familiar with how horriffic GC can be with an old language on the Atari ST, called STOS Basic (AMOS on the Amiga) back in 1988. It used to slow the program down to a crawl depending upon what you're dealing with!
Young whippersnappers don't know about LISP
...or Prolog for that matter.
McCarthy was actually not concerned with the Lisp implementation at all.
"As servers with hundreds of gigabytes of memory have become the norm"
When did that happen?
Hundreds of GBs of memory
Notice that it is not said RAM, but memory.
I suspect that the article concerns disk space at that point.
Especially since that is the only way that "in-process, off-heap memory" makes any sense.
So there is a general confusion in the article between RAM memory and HDD memory.
No wonder people have trouble understanding how computers work.
Why's GC have to be done in one go, rather than as an ongoing process or at least lots of smaller steps, each clearing up parts of garbage, rather than everything in one big jolt?
The question is...
...why am I not using the -Xingc option?
...it's "-Xincgc"? :-)
Like those fringgin' pointless exam questions:
"Which option alters garbage collection?
e) It is not possible to alter garbage collection"
What is the point of this product?
I'm struggling to see it - other than solve a problem that existed a good few years ago. With either a modern JVM or a decent design you would never need this app.
For example -> (Use Gencon gc!) http://www.nearinfinity.com/blogs/aaron_mccurry/tuning_the_ibm_jvm_for_large_h.html
quote --> " finally settled on 100G heap with 50% a nursery, and the full GCs are now in the 400-600ms range. I can live with that, because this gives us a huge ceiling for load, and capacity."
This was two years ago... Will have been some performance improvement from there.
If you are doing something daft on your 'social networking' website or whatever the proposed use cases are and caching vast amounts of data or using humongous session objects then I'd suggest using a java key-value pair object grid or some such.
or an appliance that manages a 160Gb cache per box ->
... As you may have guessed I'm an IBM drone so only able to propose solutions using our products but I'm sure any quick google will provide a myriad of free open source options. (like memcached, not java but plenty of clients)