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. 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. It might be useful to have a hook for when the GC system will explicitly freeze most threads, but then you run into the in-process issue, which I'll get to. However, because GC research is leading away from this, it seems silly to put effort into adding a runtime library when you'll probably have no need for it in the next version. The in-process issue is also very relevant: It is very difficult to streamline things inside a single JVM such that code running in the JVM can inspect status info about that same instance of the JVM. This is why the various java profiler stuff must be run in a completely separate process. Garbage Collection info suffers from similar problems. Let's say that memory is pretty much full, and generational GCing doesn't cut it anymore, and the VM actually needs to freeze most threads in order to let a full GC run commence. However, there's a hook. The VM can't, of course, start GCing before calling this hook, so it calls the hook - and promptly the hook fails due to an OutOfMemoryException. Because of this, the hook should optimally register along with the amount of memory it thinks it needs to handle business. Do you have any idea how much memory it would take for some chunk of java code to run? For the execution of that hook, the garbage collector is essentially off-line. It'd be meaningless if it wasn't. This is starting to get very ugly. The solution is simple: Two processes. Solves everything. Granted, the JVMTI (or what's it called?) are more focused on raw networking and C code - it would be nice if there was a java library so that you can boot a second VM and let it control another one, but work is ongoing on that, I believe (see JMX). Then, a second 'control VM' can tell the main loadbalancer that the actual VM handling its share of the calls is undergoing some serious GC work. Now there are no problems whatsoever - each VM has its own chunk of memory, you explicitly configure the second VM to go easy on memory, and it does its own, completely separate (and probably much lighter) garbage collection. Everybody happy. So, you see, blake - there are no hooks for garbage collection in java because it would severely hamper the ability of sun to write better garbage collectors. On Sep 19, 6:03 am, blake <[EMAIL PROTECTED]> wrote: > This seems so obvious that, either there's some way to do it already > or I'm totally overlooking something and it is a really horrible idea. > > Why doesn't a JVM provide some means of getting notifications that a > GC has started/completed. I looked at the JMX interface (quickly I > admit) but I didn't see any such thing. > > In the big-server realm, it might be nice to point a load balancer > away from some box, while it was running its 10 sec GC. > > -blake --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
