4 ms·
Well, Sun's JVM has been generational for a long time. It's the incremental & compacting implementation that is new.
by oconnor0 18y ago
Well, Sun's JVM has been generational for a long time. It's the incremental & compacting implementation that is new.
- calambrac 18y agoOf course. I was pointing out that the parent comment was just a bunch of gc buzzwords strung together in a meaningless way.
- stcredzero 18y agoI may have got the terminology wrong, but I was a part of the Smalltalk group when Visualworks was pushing out a VM enabling both generational and incremental GC -- with both in operation on the same image.
- calambrac 18y agoI'm surprised, then, that you would so flippantly dismiss this with such an ignorant statement. Java has had a generational gc for the majority of its existence, since version 1.2 (released '98, only 2 years after Oak dropped), which, of course, implies that its had an incremental or concurrent collector (or more appropriately, collectors - you can pick which one you want to use in Java-land, too) since at least then, as well. If you had clicked past the pretty terrible article title and actually read up on this collector, you'd realize that isn't the "generational" or "incremental" that's important, it's the "compacting" part that, along with some implementation details, cuts down on management overhead and reduces fragmentation, and the effort to provide soft real-time behavior, along with some cool configuration parameters where you can specify how much of a given timeslice you're willing to give up for gc. There are a lot of things that you can be critical of Java for, but slouching on the vm isn't really one of them.