Interesting...I'll have to check that out. Honestly, though, it doesn't sound like
much of a solution for something like JBoss or even most infrasructural items. I
figured any fine-grained memory monitoring would require native code.
-----Original Message-----
From: Anatoly Akkerman [mailto:[EMAIL PROTECTED]]
Sent: Wed 7/10/2002 5:02 PM
To: [EMAIL PROTECTED]
Cc:
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
<<winmail.dat>>
