From what I know, one can use JVMPI hooks to do fine-grained memory monitoring (http://java.sun.com/j2se/1.3/docs/guide/jvmpi/jvmpi.html). But this would involve writing some C, JNI, helper Java classes to query your custom profiling library for collected info. Depending on how well you design your library and how many profiling events you end up collecting, this may substantially slow down the JVM (just imagine the fact that you would have to call into the library every time an object is allocated or deleted, yikes). Also, once you load your library, you cannot debug this jvm remotely or profile anything in it using the standard profiling tools.
------------------------------------------------------------------------- Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 ------------------------------------------------------------------------- Rhett Aultman wrote: > I've thought about doing this in some of the other architectures I've written from >time to time. It's possible to keep an eye on memory usage and track its stats over >time, so you can know when memory's becoming scarce and start telling different parts >of the system "Memory's tight. Can you do what you can do to lighten the load?" >That wasn't all that hard to do- every time this architecture deployed a "job" to >run, it kept a handle to them and would asynchronously call a method on them that >contained "best effort" code to lighten up the load and call the GC. That works fine >when you just know that you're using more and more memory and just want to politely >ask deployed code to attempt to help out. > > The real issue with what you're asking is, though, that I don't know that there is a >way to, within a Java runtime, break down memory usage at a fine-grained level to >spot a memory hog. One possible tack to take would be to make each classloader keep >tabs on how many times it gets requests for object creation, but even that doesn't >get you what's needed, because I'm not aware of a mechanism in place to actually >chart how much memory is getting consumed by the classes instantiated out of that >classloader. As far as I see, the API does not support this. The memory reporting >methods are for the entire JVM, and breaking down that aggregate information by >subsystem in the JVM would be tricky, if not downright impossible. > > -----Original Message----- > From: Hunter Hillegas [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 10, 2002 4:12 PM > To: JBoss Dev > Subject: [JBoss-dev] Implementing a Resource Protection System? > > > How hard would it be to implement some kind of resource protection system > for deployed JBoss apps? > > I'm thinking mainly memory... Not allowing an app to continue to grab memory > until the container dies, instead, shutting down that app and sending > notification to an admin... > > Could be useful for a hosting environment... Possible? > > Cheers, > Hunter > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Two, two, TWO treats in one. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Two, two, TWO treats in one. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
