In summary, system.gc works fine unless you've deliberately done something like setting the -XX:-DisableExplicitGC flag.
On Thu, May 26, 2011 at 5:58 PM, Konstantin Naryshkin <konstant...@a-bb.net> wrote: > So, in summary, there is no way to predictably and efficiently tell Cassandra > to get rid of all of the extra space it is using on disk? > > ----- Original Message ----- > From: "Jeffrey Kesselman" <jef...@gmail.com> > To: user@cassandra.apache.org > Sent: Thursday, May 26, 2011 8:57:49 PM > Subject: Re: Forcing Cassandra to free up some space > > Which JVM? Which collector? There have been and continue to be many. > > Hotspot itself supports a number of different collectors with > different behaviors. Many of them do not collect every candidate on > every gc, but merely the easiest ones to find. This is why depending > on finalizers is a *bad* idea in java code. They may well never get > run. (Finalizer is one of a few features the Sun Java team always > regretted putting in Java to start with. It has caused quite a few > application problems over the years) > > The really important thing is that NONE of these behaviors of the > colelctors are guaranteed by specification not to change from version > to version. Basing your code on non-specified behaviors is a good way > to hit mysterious failures on updates. > > For instance, in the mid 90s, IBM had a mode of their Vm called > "infinite heap." it *never* garbage collected, even if you called > System.gc. Instead it just threw away address space and counted on > the total memory needs for the life of the program being less then the > total addressable space of the processor. > > It was *very* fast for certain kinds of applications. > > Far from being pedantic, not depending on undocumented behavior is > simply good engineering. > > > On Thu, May 26, 2011 at 4:51 PM, Jonathan Ellis <jbel...@gmail.com> wrote: >> I've read the relevant source. While you're pedantically correct re >> the spec, you're wrong as to what the JVM actually does. >> >> On Thu, May 26, 2011 at 3:14 PM, Jeffrey Kesselman <jef...@gmail.com> wrote: >>> Some references... >>> >>> "An object enters an unreachable state when no more strong references >>> to it exist. When an object is unreachable, it is a candidate for >>> collection. Note the wording: Just because an object is a candidate >>> for collection doesn't mean it will be immediately collected. The JVM >>> is free to delay collection until there is an immediate need for the >>> memory being consumed by the object." >>> >>> http://java.sun.com/docs/books/performance/1st_edition/html/JPAppGC.fm.html#998394 >>> >>> and "Calling the gc method suggests that the Java Virtual Machine >>> expend effort toward recycling unused objects" >>> >>> http://download.oracle.com/javase/6/docs/api/java/lang/System.html#gc() >>> >>> It goes on to say that the VM will make a "best effort", but "best >>> effort" is *deliberately* left up to the definition of the gc >>> implementor. >>> >>> I guess you missed the many lectures I have given on this subject over >>> the years at Java One Conferences.... >>> >>> On Thu, May 26, 2011 at 3:53 PM, Jonathan Ellis <jbel...@gmail.com> wrote: >>>> It's a common misunderstanding that system.gc is only a suggestion; on >>>> any VM you're likely to run Cassandra on, System.gc will actually >>>> invoke a full collection. >>>> >>>> On Thu, May 26, 2011 at 2:18 PM, Jeffrey Kesselman <jef...@gmail.com> >>>> wrote: >>>>> Actually this is no gaurantee. Its a common misunderstanding that >>>>> System.gc "forces" gc. It does not. It is a suggestion only. The vm >>>>> always >>>>> has the option as to when and how much it gcs >>>>> >>>>> On May 26, 2011 2:51 PM, "Jonathan Ellis" <jbel...@gmail.com> wrote: >>>>> >>>> >>>> >>>> >>>> -- >>>> Jonathan Ellis >>>> Project Chair, Apache Cassandra >>>> co-founder of DataStax, the source for professional Cassandra support >>>> http://www.datastax.com >>>> >>> >>> >>> >>> -- >>> It's always darkest just before you are eaten by a grue. >>> >> >> >> >> -- >> Jonathan Ellis >> Project Chair, Apache Cassandra >> co-founder of DataStax, the source for professional Cassandra support >> http://www.datastax.com >> > > > > -- > It's always darkest just before you are eaten by a grue. > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
