How about a PhD sub-project, Mr Akkerman, that would be a nice mbean in our system.
It would have a little bit of everything, Some C, some JNI, java classes and mbean, You broadcast the information for the VM, Trust me, you will look like a king, marcf > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On > Behalf Of Anatoly Akkerman > Sent: Wednesday, July 10, 2002 5:02 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Implementing a Resource Protection System? > > > 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 > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases & more http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
