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 -~----------~----~----~----~------~----~------~--~---
