Sorry, if I am missing something here, but a few points: 1. "System.gc() triggers a full gc." --> Not true, this code requests a GC, it is up to Java to decide when to grant it.
2. If you just want to see when GC is happenning, and get some statistics, you can add the -verbose:gc argument to the command line of the Java java process you are using to start your server. This will give you basic information. There are a variety of other -D arguments you can also add that will give you more in depth statistics (there is even one, that will trigger a dump, right before your Java process goes down). ex. JAVA_HOME\bin\java -verbose:gc server 3. There are a variety of tools you can use to instrument your GC cycles, which will give you a very clear understanding of what is happenning. Check out Samurai, or GCStat, or ... (there are more, I just can't think of the complete list right this second). On Sep 20, 12:23 am, kirk <[EMAIL PROTECTED]> wrote: > Reinier Zwitserloot wrote: > > Java doesn't give it to you for the same reason they really dislike > > finalizers. > > > It cramps their style. > > > Specifically, there's not currently any rule in the garbage collection > > rulebook that says that GCing must be an event with an explicit start > > and an explicit end. In fact, cutting edge GC research will basically > > be garbage collection slowly and almost all the time. > > The next collector that you'll see is G1. GC will still be a discrete > event. However, just as is the case with concurrent, there will be only > two stop the world events, pre-mark and re-mark. Tenured space will be > collected incrementally by the young generational collector having some > *extra* work tagged on the end of it's collection cycle. This should > eliminate long pauses that ones experiences when tenured must be > compacted. However, even this strategy may not keep up with some > applications ability to create objects.> Trying to still > > support an API for when GC starts and stops would be kind of strange. > > Incidentally, this is also why System.gc() doesn't actually do much > > and specifically states that it is only a hint and not a guarantee. > > thats what the spec says.. however System.gc() is never ignored. I've > not fiddled with this but I do believe from other conversations that > System.gc() is *never* ignored. I believe that RMI makes calls to > System.gc() in order to have it's references cleaned up. > > > It > > might be useful to have a hook for when the GC system will explicitly > > freeze most threads > > System.gc() triggers a full gc. > > > Granted, the > > JVMTI (or what's it called?) > > Tools Interface (profiler interface)> are more focused on raw networking and > C > > code - > > this is a C level library because most of the information you need is > not available directly in Java. This is changing somewhat with the > instrumentation library however. The JVMTI does not specify a networking > protocol as evidenced by the reference implementations, prof and hprof. > > > it would be nice if there was a java library so that you can > > boot a second VM and let it control another one, > > You can already do this with JMX though if what you really mean, I don't > need to write any custom code to have this happen, then point taken. > However I'm not quite seeing the value in this. > > What maybe nice to have is a load balancing oriented API that could give > you some value of busyness. Any load balancer could then use that > information to understand how to distribute work (latency concerns aside). > > Regards, > Kirk --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
