This doesn't seem to return any result from Netbeans (which has the same heap analysis tools as VisualVM):
select x.name from java.security.Principal x
The query works if I put the name of a concrete class implementing Principal, but I'd need all implementations.
Tried the same in Eclipse Memory Analyzer, same results.
Any clue?
Heap dump does not have the information which classes implement particular interface. The only information available in the heap dump is about superclass. NetBeans Profiler can overcame this shortcoming - if you take a heap dump, while profiling or monitoring NetBeans project, it can compute the classes implementing particular interface from the project.
JHAT OQL 'instanceof' operator does not work with interface types BUG closed as Won't fix because current heap dump format have no such info. There are:
BT2:WORK AROUND
Manually find all implementing classes available in the heap snapshot (e.g. by searching through JAR
files). Besides the difficulty and unreliability of finding all the possible impl classes, the
result will not be very satisfactory because you are forced to either
Run a separate OQL query for each implementing class, making it hard to see all results in one
place.
or
Use 'from Object o' and filter the results by checking the type, which is likely to be
prohibitively slow since it would traverse every object in the heap.
If you have some guess about class names or packages you may use query like this to find appropriate candidates:
filter(heap.classes(), "/org\\.hibernate\\.cfg\\.naming/(it.name)")
You can save search result via:
x = toArray(filter(..., ...))
and then query detail info without waiting for original query:
map(x, "{cl: it, sub: it.subclasses(), sup: it.superclasses()}")
Related
I was analyzing a Java heap dump when one of our application servers ran out of memory. I was using Eclipse Memory Analyzer. It reported the following.
One instance of "akka.dispatch.Dispatcher$$anon$1" loaded by
"sun.misc.Launcher$AppClassLoader # 0xc5602128" occupies 675,632,768
(73.50%) bytes.
What do the $$anon and $1 in the class name mean?
What exactly is the object that's taking 73.5% of heap space? What could be the cause?
First anonymous class. Looking at source code I guess it is the Mailbox: https://github.com/akka/akka/blob/master/akka-actor/src/main/scala/akka/dispatch/Dispatcher.scala#L89 (Scala objects created with traits are compiled to anonymous classes)
The tool you are using should be able to tell which objects are directly hold/referenced by Mailbox and are actually using memory. Probably actors are simply not processing messages fast enough.
My web application is running in apache tomcat.
The classloader/component org.apache.catalina.loader.WebappClassLoader # 0x7a199fae8 occupies 1,70,86,32,104 (88.08%) bytes.
The memory is accumulated in one instance of java.util.concurrent.ConcurrentHashMap$Segment[] loaded by <system class loader>.
I got this problem while analyzing Heapdump. How to analyze it further ?
You provide very little information so I only can provide very little advice… ;-)
First you need to find out who is using the largest objects (the HashMap in your case). Try to look at the contents of the HashMap so you may find out what it is used for. You should also try to look at where this objects are referenced.
Than you can try to limit its size. Depending on whether it is used by a framework you use or by your own code this can be easy (e.g. configuration change for a frameworks cache), medium (e.g. you need to refactor your own code) or difficult (e.g. it is deeply buried in a library you have no control over).
Often the culprit is not the one you expect: Only because an object instance (in your case the HashMap) accumulates a lot of memory does not mean the "owner" of this object is the root cause of the problem. You might well have to look some levels above or below in the object tree or even in a completely different location. In most cases it is crucial that you know your application very well.
Update: You can try to inspect the contents of a HashMap by right clicking it and selecting Java Collections, Hash Entries. For general objects you can use List objects, with incoming references (to list all objects that reference the selected object) or with outgoing references (to list all object that are referenced by the selected object).
Memory analysis is not an easy task and can require a lot of time, at least if you are not used to it…
If you need further assistance you need to provide more details about your application, the frameworks you use and how the heap looks like in MAT.
I need to customise a generic Internal block diagram to show customer specific variants. A simple tag based discrimination mechanism is used to suppress non relevant flows and allocated operations.
I have written a Java plug-in to iterate over the IBD’s encapsulated IRPGraphElements, examining their associated type and acting appropriately.
Manipulation of the flows is working fine, but I am having a lot of problems with the allocated operations – in summary I have 2 problems…
I cannot get a handle to the “AllocatedFrom” compartment
And therefore I cannot get to the IRPCollection containing the references to the actual operations.
Problem 1.
I have examined both the Rhapsody Java api documentation (!!!) and Java objects at runtime trying to discover the appropriate method(s) to invoke.
As it is a purely presentational issue (I do not want to suppress underlying allocations between model elements) I guess it is some kind of graphical property & I had thought it would be ObjectModelGe oriented.
I have looked at the properties mentioned in the Diagram package of the SysML profile.
Within General::Graphics I can see the AdditionalCompartments property mentions (amongst other things) AllocatedFrom
However within ObjectModelGe::Object I see that the Compartments property only mentions Operation – do I need to add AllocatedFrom to this property?
Problem 2.
Even if I get access to the compartment I am not sure what methods will be available to access the collection – there appears no interface defined for compartments. Looking in the .sbs file I can see that it is of type IRPYRawContainer but I cannot find any documentation on this.
I have a large number of Java bean classes in my web application, and I am trying to find a simple way to implement the toString() methods in these beans. The toString() method would be used for logging throughout the application, and should print the attribute-value pairs of all attributes in the bean.
I am trying out two alternatives:
1. BeanUtils.describe() (Apache commons-beanutils)
2. ReflectionToStringBuilder.toString() (Apache commons-lang)
Since this is a web application expected to have high traffic, the implementation has to be lightweight and should not impact performance. (Memory use, processor use, etc are main considerations).
I'd like to know which of these performs better according the criteria mentioned above. As far as I know, reflection is a heavy operation, but more details and insight into both these options would help me choose the optimal solution.
We use ToStringBuilder.reflectionToString() in our objects' toString() methods. We have not had any issues running like this in a production environment. Granted, we rarely use the toString() method.
We also use BeanUtils.describe(), but for another purpose. BeanUtils uses PropertyUtilsBean which keeps an internal cache of beans for which it has performed introspection. It would seem that this would give it a performance advantage over the other, but a little poking around in the reflectionToString source and it seems that since it ultimately relies on the implementation of java.lang.Class, caching comes into play there as well.
Either looks like a viable choice, but BeanUtils.describe() will return a Map of properties where reflectionToString will return a formatted String. I guess it depends on what you want to do with the output.
I would suggest that if your application is heavily dependent on calling toString() on your objects, having a specific implementation might be more beneficial.
Personally, I prefer to generate the toString() method using Eclipse/IntelliJ and then modify it as necessary (only include important fields).
Right click -> Source -> Generate toString(). Select fields. Done.
It takes less time than even writing the Builder code.
It will execute faster.
It doesn't use permgen space (reflection can tend to eat up permgen)
That's the path I would go if you're concerned about performance.
Be careful, as this is reflection based it will be slow.
In a recent web project our Base entity toString() method was ToStringBuilder.reflectionToString(this)
This method is called in hibernate during save (via Spring Data JPA respository). We have quite a large object tree with nested lists, leading to a large in memory and CPU hit during save.
It almost sank the project.
Just use code generator in your IDE to generate toString() method. This way you will avoid the overhead caused by using reflections. In real production system your toString() method can be called very often (100/sec) causing garbage collector to work hard and pause your JVM. These pauses can be seconds or tens of seconds.
I would like to get a reference to all objects in the Java heap, even if I don't immediately have a reference to those objects in my active thread. I don't need non-referenced objects (those "queued" for garbage collection), but would like to get anything that's still in use.
The goal is to serialize and store all the objects to implement a poor-man's persistence of execution state. I realize that the rabbit hole goes deep when it comes to different types of transient state, but simply persisting objects & loaded class definitions would be useful to me.
Is there a way to access the heap in order to make this happen? Am I overlooking a more straightfoward approach?
I'd look into the the instrument package. Instrument the classes you are interested in so the ctor registers the created instance. You might be able to do this via AspectJ should you not want to use the java.lang.instrument or if the objects are created via something you can control (an IoC container or factories) then you can do something a good chunk less magical.
If you want to take a heap dump programmatically, you'll not find suitable APIs in the java.* or javax.* namespace. However, the Sun runtime comes with the HotSpotDiagnosticMXBean which will enable you to take a heap dump by writing the contents of the heap on to a specified file in disk.
I suggest you take a heap dump and then inspect it using the Eclipse Memory Analyser.
The views available allow you to drill down to instance level, view object properties. You can even query objects using OQL - and SQL-like query language for objects.
The left panel in the below screenshot demonstrates inspecting field values.
screenshot http://img181.imageshack.us/img181/4013/dominatortreegrouped.png